数学推理能力是 LLM 通用推理能力的核心代理指标，直接关系到模型在科学研究、代码生成、定理证明等高价值场景的实用性。 这与人的思维能力很相似。因此，从某种程度上说，大模型的训练也是在研究人的学习过程。

—— 夜读 DeepSeekMath

能够实时获得反馈，本身就是一件并不常见的事。事实上，这才是自然界中极为罕见的情况。 因为很多人会忽略来自外部的激励信号，甚至会抗拒这些信号。如果一个人真的有自己的目标，他就应该非常清楚这些激励信号是什么样的，并且对它们足够敏感。但很多人在做事时，往往会因为种种原因而忽视这些激励信号。

关于为什么中间推理步骤能提升最终答案质量的一点思考：

• 固定深度的 Transformer（不输出中间 token）本质上更像一个固定层数的电路——它所能处理的问题复杂度是有上界的。
• 一旦允许输出中间 token，模型就变成了一个图灵完备的计算系统——理论上，只要给它足够多的中间步骤，就可以处理任意复杂的可计算问题。

因为任何算法都可以被分解为更小的原子单元，并通过逐步累积的方式实现，所以任何可计算的问题，本质上都可以用这种方法来解决。

从学习的角度看，更进一步的原因在于：模型在预训练阶段，已经见过这类推理过程。

比如，在多份材料中，往往会共同呈现一种通过多步骤分解来解决问题或生成回答的方式。因此，多步骤推理能够激活模型在预训练阶段习得的相关知识。

后续训练的作用，则是把这种在预训练中形成的能力进一步激发出来。

针对数学解题步骤设计的 Reward Model，能否具备足够的泛化能力，让它在其他领域的问题中也有很好的表现？

如果能的话，是因为模型从奖励信号中学到的是更抽象的东西。

最容易迁移的，并不是“会解二元一次方程组”，而是这些更抽象的能力：

• 是否能显式分解问题；
• 是否会检查中间步骤；
• 是否能指出隐含假设；
• 是否能避免跳步；
• 是否能做局部纠错；
• 是否具备较稳定的长链条信用分配能力。

通过数学这类任务，模型可以学到更底层的抽象能力。如上所述，这也是数学上的 Reward Model 能够泛化到其他领域的一个关键特性。

这里的核心概念就是“泛化”：你需要设计一种奖励信号，使其具备足够强的泛化能力——这才是最关键的，也就是信号本身要足够“能迁移”。

我觉得从这个角度来看，一个好的模型设计，和一个人培养良好的思维能力，本质上是一样的。

你要设计的信号要足够有泛化性，才能在各行各业、各个领域里都派上用场。我以前把这种道理叫作“零阶道理”。

举个例子：

1. 对自身想法的批判性反思
2. 好奇心

这些都属于“零阶道理”，它们作为信号的泛化力特别强。

A genuine problem-solving process involves repeatedly using available information to initiate exploration, which, in turn, reveals more information until a way to attain the solution is finally discovered.

— Allen Newell, J.C. Shaw, and Herbert Simon, “Report on a General Problem-Solving Program” (1959)

通过循环迭代地挖掘信息，再用新获得的信息去解决当下的问题。许多问题的本质，其实是信息不足。

一个事情能够 Scaling Up，它的上限会非常高，逼近上限的方式也就变得很简单：不停地堆叠算力，而这种堆叠算力，本质上也是一个很简单的过程——堆叠硅片。

所以这种发展模式是很简单的，因为它的发展路径是可预见的。这种模式背后遵循的，就是 Scaling Law；

按照《The Bitter Lesson》那篇文章里的观点，最能很好地实现 Scaling Law 的两类通用方法，就是 Search 和 Learning。 能否把 Search 和 Learning 结合起来？

基于 Agent，实现大规模、批量化、自动化的内容采集与生成。 不就是把 Search 和 Learning 结合在一起吗？

不停地试、不停地试，肯定会命中一个。现在要做的，就是造出更多“猴子”，让他们疯狂乱扔飞镖：谁命中，谁就是答案。

以前那套精细化打磨产品、精英式洞察用户需求，太慢了，它的 scaling law 太差了。最好的方法就是“大力出奇迹”。这个道理，我这几个月真的彻彻底底地信服了。

家族中的第一个人被捆在树上，最后一个人正被蚂蚁吃掉。

-百年孤独

在从 Vibe Coding 过渡到 Agentic Coding 之后，一个很明显的不争事实是：所有真正拥抱 Agentic Coding 的公司（那些同时拥有 Frontier Model 和 Coding 工具的公司），其代码目前都由 AI 生成。

在这个前提下，我们需要在思路上做一次转向。过去设计软件时，我们习惯用迭代的方式，一点点把它做大；但在 Agentic Coding 时代，这套思路可能不再适用。

更好的方式是：

1. 先把未来成功时的完整形态，以及对应的组织架构，一次性输入给 Coding 工具。
2. 让 AI 在上述上下文中生成代码，使其朝着最终成功的形态演化。
3. 在构建软件系统时，再逐步把功能加进去。

这就像一个 Rocket Booster：它会放大人的想象力与品位。因此，你的瓶颈将更多来自想象力，而不是落地时的工程约束。

所以，构思要往大处想；执行时，让 AI 工具沿着你的设想自动演化成你想要的状态。之所以目前还需要一步步推进，根本原因是：人一旦参与验收，就会遇到现实约束，只能逐步验证。

如果你能设计出一个完整、可自我验证的闭环负反馈系统，Agentic Coding 工具理论上可以自行演化成你想要的样子。但这极其困难，而且高度分领域、很挑场景。