AI 与机器学习2025arxiv.org
Program-of-Thought 提示比 Chain-of-Thought 高出 15%（2022）
Program-of-Thought Prompting Outperforms Chain-of-Thought by 15% (2022)
进阶 · 约 35 分钟读完前置知识：大语言模型基础、Chain-of-Thought 提示、Python 代码执行
导读
这篇论文（PoT，2022）提出让大模型把推理过程写成可执行的程序（如 Python 代码），把计算和逻辑执行交给外部解释器，从而把「推理」和「计算」解耦。作者在数学和符号推理类任务上报告了相对 chain-of-thought 约 12–15% 的准确率提升。
HN 关注点：这种「让模型写代码来推理」的做法如今已被 GPT-5.x、Claude 4.x 的工具调用内建，并且引发关于中间表示、token 成本和沙箱安全的讨论。
后来怎么样
PoT 将“生成可执行程序并交给解释器计算”引入大模型推理，成为后续代码解释器式推理与程序化工具调用方向的重要先导；如今主流 LLM 的代码执行辅助推理可视为其思路的工程化延续。
HN 评论精选
这几条评论里：质疑 1 补充 3
补充该方法已被主流模型的代码执行功能内建。
这似乎已经被现在的 LLM 生成能力吸收了——当开启代码执行时，GPT-5.x 和 Claude 4.x 好像都会自动执行 Python 代码来辅助推理步骤。
jey查看英文原文
This seems to be incorporated into current LLM generations already -- when code execution is enabled both GPT-5.x and Claude 4.x automatically seem to execute Python code to help with reasoning steps.
质疑批评 PoT 跳过半形式化规格层，主张 chain-of-spec 的中间表示。
Chain-of-code 比 chain-of-thought 更好，因为它更接地气、更具体，压缩效率也高。但我认为 PoT 太具体了：从「非常模糊的规格」直接跳到「非常具体的代码」，跳过了中间地带，于是没有迭代空间——要么烧掉大量 token，要么陷在查找和修复翻译表示中新引入的错误里。换句话说，出错时你分不清是代码本身错了，还是代码本应表示的场景错了。很多人早就直觉地认为「规格就是新的代码」，这没错；但认为规格可以用自然语言和 markdown 列表很好地表达，那太疯狂了。我们需要 chain-of-spec：利用某种半形式化的表示并对其迭代，最好还有来自其他层的反馈。自然语言提供约束，猜—验式代码生成属于实现层面，但两者都不是规格本身，而规格才是问题核心。理想的中间语言很可能是某种熟悉的东西，融合模型检查器、逻辑、博弈、离散仿真、图、UML 等形式化方法——因为在压缩上很难打败这些。
robot-wrangler查看英文原文
Chain-of-code is better than chain-of-thought because it's more grounded, more specific, and achieves a lot of useful compression. But my bet is that the proposed program-of-thought is too specific. Moving all the way from "very fuzzy specification" to "very concrete code" skips all of the space in the middle, and now there's no room to iterate without a) burning lots of tokens and b) getting bogged down in finding and fixing whatever new errors are introduced in the translated representations. IOW, when there's an error, will it be in the code itself or in the scenario that code was supposed to be representing? I think the intuition that lots of people jumped to early about how "specs are the new code" was always correct, but at the same time it was absolutely nuts to think that specs can be represented in good ways with natural language and bullet-lists in markdown. We need chain-of-spec that's leveraging something semi-formal and then iterating on that representation, probably with feedback from other layers. Natural-language provides constraints, guess-and-check code generation is sort at the implementation level, but neither are actually the specification which is the heart of the issue. A perfect intermediate language will probably end up being something pretty familiar that leverages and/or combines existing formal methods from model-checkers, logic, games, discrete simulations, graphs, UML, etc. Why? It's just very hard to beat this stuff for compression, and this is what all the "context compaction" things are really groping towards anyway. See also the wisdom about "programming is theory building" and so on. I think if/when something like that starts getting really useful you probably won't hear much about it, and there won't be a lot of talk about the success of hybrid-systems and LLMs+symbolics. Industry giants would have a huge vested interest in keeping the useful intermediate representation/languages a secret-sauce. Why? Well, they can pretend they are still doing something semi-magical with scale and sufficiently deep chain-of-thought and bill for extra tokens. That would tend to preserve the appearance of a big-data and big-computing moat for training and inference even if it is gradually drying up.
补充指出运行生成代码的安全风险，需要沙箱。
我称之为「自毁式提示」——你用 AI 输出程序，而程序未来会取代调用 AI。论文似乎表明这也能带来更好的结果。但它容易被攻击，因为运行生成的代码通常不安全，必须使用沙箱；主要的 agentic AI 厂商已有方案，比如今年早些时候发布的 Langchain sandbox。
eric-burel查看英文原文
I call that self-destructive prompting in the sense that you use AI to output programs that replace calling the AI in the future. The paper seems to indicate that this also brings much better results. However it's subject to attacks as running generated code is usually unsafe. A sandbox has to be used, major agentic AI players are providing some solutions, like Langchain sandbox released earlier this year.
补充补充产业落地案例：Anthropic 的 Programmatic Tool Calling 与 Lutra AI。
Anthropic 最近把这个加进了 API（见其 advanced tool use 文档中的「Programmatic Tool Calling」）。另外有一家 AI 生产力创业公司 Lutra AI 也做过类似的事，不过后来转向了某种 MCP 基础设施。
mgraczyk查看英文原文
Anthropic recently added this to the API: https://www.anthropic.com/engineering/advanced-tool-use See "Programmatic Tool Calling" And there was an AI productivity startup called Lutra AI doing this, although they've since pivoted to some kind of MCP infra thing: https://lutra.ai/
相关资源
从这篇论文所有 HN 讨论帖的全部评论里整理出来的链接。
历次讨论
- 2025Hacker News 讨论帖136 分 · 36 评
同领域还值得读
DeepSeek-R1：通过强化学习激励 LLM 的推理能力
DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via RL
研究如何用强化学习激励大语言模型的推理能力，提出 DeepSeek-R1，并探讨 RL 训练对模型推理表现的影响。
AI 与机器学习2025 · 1,351 分 · 1,056 评 · 引用 30进阶 · 约 80 分钟编辑精选1-bit LLM 时代：面向低成本计算的三值参数
The Era of 1-bit LLMs: ternary parameters for cost-effective computing
提出用三值参数 {-1, 0, 1} 替代 LLM 中的浮点权重，即所谓“1-bit LLM”。
AI 与机器学习2024 · 1,040 分 · 447 评 · 引用 19进阶 · 约 45 分钟编辑精选DeepSeek-V3.2：推进开放大语言模型的前沿
DeepSeek-v3.2: Pushing the frontier of open large language models
这是 DeepSeek-V3.2 的技术报告，延续了 DeepSeek 开源权重模型的路线，目标是让开放模型继续逼近甚至追平前沿闭源模型。
AI 与机器学习2025 · 982 分 · 465 评进阶 · 约 90 分钟编辑精选通过自我对弈与通用强化学习掌握国际象棋和将棋（AlphaZero）
Mastering Chess and Shogi by Self-Play with General Reinforcement Learning
DeepMind 的 AlphaZero 论文：用通用强化学习算法（自我博弈 + MCTS + 神经网络），从零开始仅数小时训练便在国际象棋和将棋上击败了世界顶级引擎 Stock…
AI 与机器学习2017 · 539 分 · 270 评 · 引用 13进阶 · 约 90 分钟编辑精选用强化学习发现更快的矩阵乘法算法
Discovering faster matrix multiplication algorithms with reinforcement learning
论文提出 AlphaTensor，用强化学习搜索矩阵乘法算法。
AI 与机器学习2022 · 518 分 · 111 评专业 · 约 90 分钟编辑精选