一句话定义
程序思维（Program-of-Thought，PoT）是一种让大模型解题的范式：模型不直接给出答案，而是把解题过程写成一段可执行的程序，交给解释器运行，用运行结果当答案。
为什么需要它
模型擅长理解题意、拆解步骤，却不擅长在参数里精确地做多位数乘法、累加一长串小数、处理几万行表格。它"读得懂"题目，但"算不准"数值——这两件事本来是两种能力，硬塞给同一个环节就会出错。
PoT 的思路就是分工：模型只负责把自然语言翻译成代码（表达式、循环、条件判断、表处理），真正的计算交给 Python 之类的解释器。
打个比方：会计拿到一堆账目，不会在心里默算，而是把公式写进 Excel，让表格去算。写公式要懂业务，按计算器只是执行。PoT 就是把这两件事交给不同的"人"。
举例：问"原价打三次折后是多少"，模型直接口算可能在某个小数点上翻车；但让它写成 price * 0.9 * 0.8 * 0.85 再执行，结果一定是准的。
和相邻概念的区别
| 概念 | 谁负责算 | 特点 |
|---|---|---|
| 直接回答 | 模型心算 | 最快，数值题最容易错 |
| 思维链（AI 词典：Chain-of-Thought">Chain-of-Thought, CoT） | 模型心算，但写出步骤 | 推理更透明，仍会算错 |
| 程序思维（PoT） | 解释器执行代码 | 数值精确，能处理大数据和字符串 |
| 工具调用（Tool Use） | 外部工具或接口 | 范围更广，不限于写代码 |
思维链让人看到"思路"，程序思维让人看到"可运行的思路"。CoT 输出一段自然语言，PoT 输出一段代码，可以把 PoT 理解为 CoT 在"需要精确计算"场景下的加强版。另外，学术界还有一个高度相似的概念 PAL（Program-Aided Language Models），内核一样，都是"模型出题、程序解题"，看到时不必当成两回事。
对从业者和普通人的意义
从业者：只要答案涉及算术、日期推算、单位换算、表格统计，就应该把计算外移给代码沙箱，而不是指望模型口算。很多"数据分析助手"之所以靠谱，靠的正是这套机制。
普通人：AI 报出一个数字时，可以先看它有没有真的在算。与其追问"你确定吗"，不如说"写段代码跑一下再告诉我"——后者往往有效得多。
也要注意边界：PoT 解决的是"算得准"，不解决"题意理解错"。题目理解偏了，代码跑得再对也是错的。至于各家产品具体支持到什么程度，以官方页面为准。