Program-of-Thoughts

prompt提示词2026年6月7日1

Program-of-Thoughts（PoT，Chen et al., 2023d）的核心是：让模型把推理过程写成“可执行的代码”，再由代码解释器/运行环境执行代码得到结果，而不是让模型纯用自然语言一步步算。

你可以把它理解为一种“把推理外包给程序执行”的方法：

LLM 负责：把问题翻译成算法/代码（规划步骤、写公式、写循环、处理边界）
解释器负责：精确计算与运行（避免手算错误）
最终答案来自：代码运行结果（更可靠、可复现）

它通常在 数学、算术、统计、数据处理、编程题上特别强；但在 语义/常识/主观理解类任务上不一定更好（因为代码很难“执行”语义推理，且数据/知识不在代码里）。

1) PoT 与 CoT 的区别

CoT：模型用自然语言写推理过程 → 容易算错、漏情况、受“幻觉”影响
PoT：模型写代码作为中间步骤 → 由解释器做精确运算/枚举/搜索 → 错误率通常更低

PoT 的关键前提是：你有一个可运行代码的环境（如 Python 解释器、JS 沙盒、或工具调用：Code Interpreter / Function calling）。

2) PoT 提示词怎么写（中文模板）

PoT 的提示词通常要明确三点：

用什么语言（一般 Python）
代码输出格式（便于提取执行）
运行后如何返回答案（只输出最终值或带解释）

模板A：最常用（输出代码块 + 最终答案）

请使用 Program-of-Thoughts：先写可执行的 Python 代码来完成计算/推理，再根据代码运行结果给出最终答案。

要求：
1) 先输出一段 Python 代码（放在 ```python ... ``` 代码块中）。
2) 代码应包含必要的注释，但不要输出无关内容。
3) 代码最后把关键结果打印出来（print）。
4) 在代码块之后，用中文给出“最终答案”（简洁）。

题目：{题目内容}

模板B：更工程化（只输出代码，方便系统执行）

你是一个代码生成器。请把推理写成可执行 Python。
只允许输出 JSON，格式如下：
{
  "language": "python",
  "code": "...",
  "expected_output_description": "打印最终答案"
}
题目：{题目内容}

工程建议：如果你要自动化执行，让模型只吐代码/JSON，不要夹杂自然语言，最稳。

3) 实际例子 1：数学/算术（PoT 的强项）

题目：
“一个等差数列首项 3，公差 5，第 20 项是多少？前 20 项和是多少？”

PoT 提示词（中文）

请使用 Program-of-Thoughts：用 Python 代码计算答案。
输出格式：
1) 先给出 Python 代码块（包含计算并 print 结果）
2) 代码块后用中文给出最终答案

题目：等差数列首项3，公差5，第20项是多少？前20项和是多少？

模型理想输出（示意）

a1 = 3
d = 5
n = 20
a20 = a1 + (n-1)*d
s20 = n*(a1 + a20)/2
print(a20, s20)

运行得到精确数值，然后再输出中文答案。

4) 实际例子 2：需要枚举/搜索的题（PoT 更能体现优势）

很多“靠人脑推理”容易漏的题，PoT 用代码枚举很稳。

题目：
“用 1、3、4、6 通过加减乘除和括号得到 24，给出一种表达式。”

PoT 提示词

请用 Program-of-Thoughts：生成 Python 代码，枚举 1、3、4、6 的所有运算组合（+ - * / 与括号结构），找到能得到 24 的表达式并打印出来（打印一个即可）。
最后用中文给出该表达式。

代码可以系统性搜索，找到表达式（如 (6/(1-3/4)) = 24 这类），比纯 CoT 更不容易卡死。

5) 实际例子 3：数据处理/统计（PoT 非常常见）

题目：
“给你一组数：2, 4, 4, 4, 5, 5, 7, 9。请计算均值、方差（总体方差）、标准差。”

PoT 提示词

使用 Program-of-Thoughts：用 Python 计算均值、总体方差、标准差。
要求打印三项结果，保留 4 位小数。
最后用中文汇报结果。
数据：2,4,4,4,5,5,7,9

用代码能避免方差公式手算出错、四舍五入不一致等问题。

6) 为什么 PoT 对“语义推理”不一定有效

你引用的结论“对语义推理较弱”常见原因：

语义任务缺少可执行的客观验证器：例如“这段话的隐含立场是什么”，写代码也难执行验证。
知识不在代码里：比如历史常识、语用理解，仍依赖模型内部知识或外部检索。
代码把问题形式化的成本高：强行形式化可能引入错误假设。

因此：

数学/编程/可形式化问题：PoT 往往显著提升稳定性
观点分析/写作/道德判断/开放问答：PoT 可能不如直接用 CoT/ToT/RAG

7) PoT 的工程落地建议（初学者最实用）

让模型“先写代码，再给答案”：避免它先拍脑袋给结论。
固定语言与库：如 Python + 标准库（必要时允许 math, statistics）。
强制可运行：要求“不要省略导入、变量定义；不要伪代码”。
输出可解析：只输出代码块/JSON，便于你的程序提取并执行。
加验证：让代码里包含简单断言/边界检查（例如除零、输入合法性）。

如果你告诉我你准备把 PoT 用在什么场景（做数学题、财务测算、数据清洗、写算法、还是解 LeetCode），我可以给你一套更贴近你业务的 PoT 模板：包括代码输出协议、执行返回格式、以及如何在失败时自动重试/修复。