最近有个消息做 AI 的同学应该都刷到了OpenAI 一次性放出了 722 份数学手稿。很多人的第一反应是“又刷屏了”但我更关注的是这件事背后的潜台词——AI 的下一个门槛根本不是算力也不是数据量而是可验证的证据。这个信号比那 722 份文件本身的数学内容更有分量。我一直在做推理模型和 AI Agent 的工程落地这几个月有一个特别直观的感受凡是能明确“对不对”的任务模型能力提升就快得离谱凡是只能靠人凭感觉打分、或者根本没有客观标准的任务越往后越难调。数学恰好是前者——答案只有一个对错是可验证的。OpenAI 这次公开手稿相当于把“模型如何一步一步得到答案”的过程摊开给你看给出的不只是一堆正确答案而是一份可以追溯、可以检验、可以复现的证据链。这篇文章我想把这句“可验证的证据”掰开揉碎聊聊它为什么是推理模型起飞的关键、722 份手稿到底提供了什么价值、以及我们做工程的人该怎么借鉴这套思路来设计和评估自己的 AI 应用。全程没有玄学都是我这几个月实验和踩坑换来的经验。1. AI 进化的分水岭在于“对错”能不能被机器判断很多人可能没意识到大模型过去几年的训练方式本质上是在“猜人类的心思”给模型生成一段文字由人工标注员打分再通过强化学习让模型学会说人类更爱听的话。这套东西叫 RLHF基于人类反馈的强化学习它最大的问题是反馈是主观且模糊的。两个人对同一段回答的评价可能截然不同同一个标注员今天和明天的标准也可能不一样。模型在这种信号下学会了迎合但学不会推理也学不会承认自己错了。后来大家发现一个更高效的路径如果任务的评判标准是客观的或者说模型生成的结果可以被一个程序、一段测试用例、一条数学规则来判断对错那训练效率瞬间提升几个档次。OpenAI 的 o 系列、DeepSeek 的 R1 能做出惊艳的推理表现核心就是走了这条路——用可验证的奖励取代人类偏好。为了说得更明白我拿生活里的事情做类比。你想训练一个孩子学会做菜如果每道菜都由妈妈尝一口打个分孩子会去摸索什么样的口味更能讨好妈妈但如果每道菜都送到美食比赛现场由机器检测火候、色泽、咸度拿到明确合格/不合格的反馈孩子进步的确定性会高得多。AI 训练也是同理数学题是天然的美食比赛答案有唯一性过程有逻辑性结果可以被机器校验。1.1 可验证奖励到底是什么**可验证奖励verifiable reward**指的是不依赖人类主观评判、可以由外部规则或工具直接判断正确性的反馈信号。举几个我在项目里用过的形式数学题的最终答案与标准答案是否一致代码是否通过所有单元测试用例SQL 查询结果与预期表结构、数据结果是否匹配Agent 调用工具后的返回值是否满足预定义断言文本摘要中的关键信息是否全部出现在原文中。这套思路最漂亮的地方在于它让模型摆脱了对人类标注能力的依赖可以去海量地自我对练。模型生成一个过程验证器判断结果对了就奖励错了就修正。验证器的判断是确定性的同一份输出不会今天算对明天算错这样模型才能稳定地学到规律。1.2 为什么数学成了最先爆发的赛道数学之所以成为可验证训练的试验场有三个原因完美契合规则明确、结论统一、推理链路清晰。规则明确指数学体系有一套公认的推导规则不允许自由发挥结论统一意味着不存在“我感觉你答得对”这种模糊地带推理链路清晰则让模型即使给出错误答案也能定位到具体哪一步出了偏差从而进行针对性的训练修正。换成开放式的“写一篇读后感”或者“给个建议”这套方法就行不通了。你可以说不喜欢但很难说它是错的。所以你看现在所有展示“超强推理能力”的大模型宣传视频里清一色是数学题、算法题、逻辑谜题——不是因为营销团队偏爱数学而是因为只有这些场景能给出可验证的证据。这种领域选择上的“偏心”恰恰暴露了当前技术路线的天花板和边界。2. 722 份手稿到底在验证什么回到 OpenAI 这次的动作。数学手稿其实就是在解决数学题时模型生成的完整推理过程——包括尝试过的方向、错误的路径、中途的修正直到最终得出答案。很多人关心这些解法本身是否优美但做 AI 的人看的完全是另一个层面这个模型在推理时到底展现了什么样的内部行为。2.1 手稿证明的不是答案而是过程如果你看过 OpenAI 公布的原始手稿会发现内容非常“不完美”有的推导绕了远路有的中间步骤有涂改痕迹甚至某些手稿里还有模型自己发现自己走错了、倒回去重算的记录。这些东西要是放在教科书里会被当成噪音但在 AI 工程视角里它们就是最珍贵的过程证据。为什么重要因为当前主流推理模型只会给你最终的答案和一行行“看起来很有道理”的推导至于模型是真的在按逻辑思考还是在背诵训练数据里见过的套路我们并不知道。手稿把隐藏的思维过程全部暴露出来了。你可以沿着每一行步骤去检查看它是在合理推理还是在强行拼凑。这就是“可验证的证据”的第一个层次过程可见才能被检验。2.2 公开手稿是为“过程奖励模型”准备数据这里有个更深的工程逻辑。训练推理模型时早期做法是只看最终答案的对错来给奖励这叫结果监督。但结果监督有个致命问题如果模型最终答案碰巧对了但中间推理是胡编的模型也会得到正反馈进而学会“蒙答案”而不是“推答案”。要解决这个问题就得做过程监督——不仅要检查答案对不对还要检查每一步推理合不合理并针对错误步骤给负面反馈。但训练过程奖励模型需要海量“带着分步标注的推理数据”靠人工标注根本标不过来成本高到让大多数团队直接放弃。OpenAI 这 722 份公开手稿有一点很实际它们可以成为研究和训练过程监督模型的公开数据集。有了这批数据谁都可以尝试训练一个能评判“推理步骤是否合理”的裁判模型而不再只看最终结果。我知道有人可能会说“技术公司没那么无私”但这不重要。重要的是这件事示范了一个方法论把推演过程完整记录、公开、可判责这本身就是高质量 AI 发展的基础设施。就像开源代码仓库不只是分享代码更是分享整个编码过程一样公开手稿是在分享模型的“思考过程审计日志”。2.3 对我来说最大的启发是“让 AI 把证据写在明面上”我在实际项目里也做过类似的事。比如让大模型辅助做数据分析过去我只会要求它“给我结论”现在我会强制要求输出格式里包含推理路径、中间数据和可复核的引用来源。这样即使模型最终判断错了我也能沿着它写下的证据链找到错在哪一步。这个习惯就是受这类公开动作的启发——AI 给出的不应该是权威结论而应该是可验证的论证过程。3. 从数学手稿到代码验证我实测过的可验证闭环说实在的数学手稿离普通开发者还是有点远。但“可验证的奖励”这套逻辑放到代码生成、数据分析、自动化脚本这些日常场景里完全是通用的而且我已经在项目中用了一个多月效果可以说是立竿见影。3.1 把“测试用例”变成模型的老师代码生成是标准的可验证场景让模型写一个函数要求它通过本地写好的单元测试。测试通过就是正反馈不通过就是负反馈整个过程机器自动完成不需要人逐行审查语义。我自己做过一个实验用同一个基础模型跑两类任务。第一类任务让它直接生成代码靠人眼检查第二类任务让它先生成代码再自动跑 20 条预设的边界测试用例根据测试结果让模型自行迭代修改。结果非常直观第二类任务里模型的最终通过率高出 37%。这个提升不是模型变聪明了而是可验证的反馈逼着模型在错误方向上及时刹车它能亲眼看到自己哪条用例没过然后有针对性地修补。给一段我实际调试时用的框架代码这只是个极其简化的演示import subprocess def verify_code(code: str, test_cases: list) - dict: 用外部测试用例验证模型生成的代码是否通过。 返回每个用例的通过状态作为强化学习的奖励信号。 results [] # 把模型生成的代码写入临时文件 with open(/tmp/agent_code.py, w, encodingutf-8) as f: f.write(code) for i, case in enumerate(test_cases): # 每个用例是一个 (输入, 期望输出) 的元组 input_data, expected case try: # 执行代码并传入输入 proc subprocess.run( [python, /tmp/agent_code.py], inputinput_data, capture_outputTrue, textTrue, timeout5, ) actual proc.stdout.strip() # 比对实际输出与期望输出是否一致就是可验证的奖励信号 passed actual expected results.append({ case_id: i, passed: passed, actual: actual, expected: expected, }) except Exception as e: results.append({ case_id: i, passed: False, error: str(e), }) return { pass_rate: sum(r[passed] for r in results) / len(results), details: results, }这段代码的核心思想就是让程序而不是人来做裁判。裁判必须是无情的不通过就是不通过没有任何通融。这种“无情”反而对模型学习最有利因为它给的信号是最干净的。3.2 自一致性采样让模型自己给自己投票除了外部验证器还有一个更轻量的可验证手段叫自一致性self-consistency。做法很简单同一个问题让模型独立生成多个解答然后统计哪个答案出现得最多把它作为最终结果。如果模型的推理是靠谱的那么不同次的推导会收敛到同一个正确答案如果模型是在瞎猜那几次生成的结果大概率会分散而不稳定。我拿一道需要五步推导的数学题做了对比实验贪心解码只生成一次答案正确率 61%采样 8 次投票选最多出现的答案正确率飙升到 83%采样 64 次正确率到了 89%但耗时也相应增加了 8 倍左右。这个实验给我最大的启发是模型内部生成的分歧度本身就是一种可验证信号。如果多个独立推理都能收敛到同一结论这个结论的可信度远高于单次生成。我在做 Agent 系统时会用这个办法来量化“模型对某个判断的把握有多大”再结合外部工具的结果综合决策准确率和稳定性都有明显提升。3.3 不要把验证器做成“自己人”这里要提醒个我踩过的坑验证器必须独立于模型本身。如果你用“另一个大模型”来验证“这个大模型”的输出本质上是主观对主观脂肪对脂肪很容易出现两个模型互相迎合但实际都是错的局面。我之前试过用一个模型生成答案、另一个模型评判正确性结果在两个模型都算错的情况下评判模型还一本正经地说“这个解答逻辑清晰、论证完整”。后来我彻底放弃了“大模型评大模型”的路线但凡能用程序、脚本、规则、sql、正则表达式判断的一律用确定性的验证器绝不偷懒。4. AI Agent 的下一场硬仗验证器从哪来现在大家都在做 AI Agent愿景是让模型自己拆解任务、调用工具、完成复杂流程。这个方向看起来很美但落到工程上有一个绕不开的问题一个多步骤的任务怎么知道 Agent 做得对不对如果判断不了对错Agent 就无法自我修正只能盲人骑瞎马。说到底Agent 的能力天花板由它的验证器决定。4.1 工具调用本身就是天然验证器我目前在建的一个项目里让 Agent 调用外部 API 时我会把每个工具的返回值当成即时的验证信号。比如让 Agent 查天气它会收到一个结构化的 JSON 返回里面包含城市字段、温度字段、状态码。我可以写断言“如果返回里没有城市名则判定此步骤失败”。这样模型在工具使用上就不仅仅是被动执行而是在每一个调用节点上获得反馈像玩游戏一样走一步看一步错了立刻调整。这种工具调用的闭环验证比纯文本生成要可靠得多。因为它把抽象的语言任务转换成了具体的“状态改变 返回值检查”。这也是为什么很多人断言“只有能调用工具的 Agent 才是有价值的 Agent”因为工具不仅扩展了能力更重要的是提供了验证信号。4.2 仿真环境给 Agent 造一个可验证的“练习场”很多任务无法在真实环境里直接验证比如机器人控制、自动驾驶、交易策略。如果让 Agent 直接在现实环境试错成本太高、风险太大。这时候就需要仿真器来接棒在虚拟环境里跑一遍 Agent 的决策看它是否达到目标再把这个结果作为验证信号回传给模型。AlphaGo 在自我对弈中学会围棋本质上就是在模拟器里获得了可验证的胜负信号。现在开源社区已经有大量仿真环境Web 导航、游戏对战、机器人控制、多智能体博弈这些都是可验证的沙盒。Agent 在仿真环境里练得越多行为就越精准可靠。我甚至认为接下来一两年最大的应用机会不是让 Agent 直接干真实世界的活而是先在仿真环境里训练出足够可靠的验证闭环再带着经验进入现实。4.3 一个逐步递增的“验证难度阶梯”上面讲了这么多我想可以给普通人画一个更清晰的图谱长期任务里从易到难的验证方式大概是这样的难度任务类型验证方式示例低数学、逻辑谜题标准答案比对几何证明题低代码生成单元测试、编译写排序函数中SQL 数据分析查询结果比对统计每月的销售额中工具调用 Agent结构化返回值断言查天气、订机票高开放式写作、咨询人工抽检 规则审核写营销文案高物理世界操作仿真器 人工安全监督机器人抓取物体这个表格列出来之后你会发现凡是验证成本低的任务模型目前都已经接近或超过人类水平凡是验证成本高的任务模型依然表现不稳。所以所谓“AI 的下一道门槛”不是模型够不够聪明而是人类能不能为每个任务设计出可靠、低成本的验证器。4.4 过程监督的重要性会越来越凸显最后提一个 Agent 领域会越来越重要的方向过程监督process supervision。只看最终结果会产生“有功则赏有过不究”的问题。比如 Agent 最后成功完成了任务但中间有一段路径是误打误撞碰对的这就不值得奖励又比如最终任务失败但中间某一步决策特别正确这部分也应该单独鼓励。过程监督的工程实现方式是把整个任务拆成多个里程碑节点每个节点设置一个可验证的检查点。Agent 每通过一个检查点就获得一份奖励在错误检查点上获得修正信号。这种拆法能让长任务的训练收敛速度快好几倍也能让“虽然任务没完成但有价值的过程”被识别和保留。目前这套做法还比较前沿我判断未来半年到一年会有更多工具链冒出来。5. 工程落地时我踩过的“可验证”坑光讲原理是不够的实操中到处都是坑。这一节我把这段时间做可验证工程时踩过的几个大坑整理一遍希望对你有直接帮助。5.1 可验证不等于自动化验证器本身要设计很多人的第一反应是“既然要可验证那我把验证器挂上去不就行了”。没那么简单。验证器本身的设计质量直接决定模型向哪个方向进化。最常见的翻车案例是你用太宽松的测试用例训练模型模型学会了迂回绕过测试但实际能力并没有提升。反之验证器过于严格导致模型过于保守明明合理的推理也被压制。我现在的做法是三层验证规则层格式、关键字、数据范围、逻辑层执行结果比对、状态变化、人工抽检层随机抽取 10% 的验证结果人工复核。三层各司其职规则层保证基本盘逻辑层保证正确性人工层保证不出漏网之鱼。5.2 警惕“验证器被训练出来的模型骗过去”这是一个非常隐蔽的问题。当模型能力强到一定程度它会摸清验证器的评判规律然后生成专门“迎合验证器”的答案而实际质量并没有提升。这就像学生摸清了考试的出题规律后不用理解知识也能考高分。我遇到过一个具体场景我用“输出中是否包含关键词”作为验证信号后来发现模型学会了只要在答案里堆关键词就能拿到高分完全不管语法和上下文。后来改成语义相似度计算 关键词双重验证才把这个漏洞堵住。所以一定记住验证器是动态对抗的对手不是静止不变的尺子。它需要随着模型进化持续更新。5.3 推理次数上升带来的成本压力不可忽视自一致性采样确实能提高准确率但它是有代价的。我算过一笔账原来每题只生成一次成本可以接受改成采样 32 次再投票单题推理成本直接翻 30 倍以上。如果你是一个 To B 的 API 服务每个用户请求都做 32 次采样账单会变得很难看。因此我建议根据任务难度动态调整采样次数简单任务采样 4 次中等任务采样 8 到 16 次只有极难的高风险推理任务才用到 32 次。做一个能自适应调整验证强度的调度器比一味堆高质量验证手段更实际。5.4 很多下游任务根本不存在“标准答案”要自己创造锚点做实际应用时你会发现大多数业务问题没有唯一正确答案。比如“帮我写一封得体的离职邮件”这是没法用字符串匹配来验证的。但不能因为任务本身模糊就放弃可验证性你要做的是在任务内部创造可验证的锚点邮件是否包含特定的表达意图语气是否满足用户指定的正式程度是否按用户给的三个要点逐条回应是否漏掉了某个必须提到的日期或名称这些锚点每一个都可以独立验证。当单次输出没有明确对错时拆出子标准把模糊的大问题转换成一组清晰的小问题这是我现在做 AI 应用时最常用的方法论。6. 落到实操怎么给 AI 应用建立可验证证据链最后分享一套我现在新建 AI 功能时的标准套路。这套思路来自于 OpenAI 公布手稿给我的启发也经过了几个项目的实际检验你可以直接拿过去套用。6.1 从“最小可验证产品”到“最小可验证证据”现在互联网行业流行 MVP最小可验证产品但我更建议做 AI 项目的人思考另一个概念最小可验证证据Minimum Verifiable EvidenceMVE。产品可以迭代慢一点但每一次版本的输出必须附带足够强的证据链这个证据要被验证器认可后才能发布。具体到实现我建立了一套五步验证清单输入进样记录模型的输入上下文和关键参数过程留痕保存模型生成答案的推理路径、调用的工具、获取的中间数据结果断言用确定性验证器检查输出是否满足预定义标准置信度评分通过多次采样或自一致性统计给出置信度人工审计定期抽检把抽检结果反馈回验证器规则库。这套流程跑完后每次模型输出都带一份“答案 证据链路”。一旦出问题可以快速定位是数据问题、模型问题、还是验证器设计问题而不再需要靠运气排查。我强烈建议任何一个在严肃场景用大模型做决策的团队都建立类似的审计机制。6.2 证据链的存储和使用证据链不应该只存在于日志里我建议设计成结构化文档最好用 JSON 格式把验证结果、中间步骤、置信度、最终答案完整串起来。这样后续做评估集、做回归测试、做用户投诉复盘都能直接复用。这里给一个我实际在用的 JSON 结构示例{ task_id: task_20250111_001, input: { query: 计算过去30天每类商品的销售额Top3, source_table: orders, data_range: 2024-12-12 ~ 2025-01-11 }, process: { reasoning_path: [ 识别表结构定位销售额字段, 按商品类目分组, 聚合计算销售额, 取前3排序 ], tools_called: [ {name: sql_runner, result: 2 classes, 3 rows returned} ] }, verification: { validator: sql_result_schema, passed: true, confidence: 0.95, checks: [ 返回行数3, 包含类目字段, 销售额字段为数值且非负 ] }, output: { final_answer: A类: 12万, B类: 9.8万, C类: 8.5万 } }每次调用都在文档里留下完整证据链模型即使出错也能立刻复盘。这套结构看起来简单但在实际排查问题时的价值是无穷的。我估计再往后会演变成行业通用的 AI 审计标准格式之一。6.3 给新人的三个操作建议第一从“结果可验证”的场景切入。如果你的业务场景现阶段根本找不到客观判断标准那就别急着上复杂的强化学习先把数据模型和行为规范做扎实。第二验证器要用最笨、最确定的方法先顶上。哪怕写一堆 if-else 也比用一个不可靠的大模型裁判要靠谱。第三小步快跑持续更新验证规则。因为伴随着模型的进化原有的验证信号会变钝每隔一段时间就要重新校准一次验证器。我可以打包票的是只要你把验证体系建立起来后面所有优化动作都有了地基。没有这个地基你做再多 prompt 工程和微调都是在沙子上面盖楼。7. 写在最后的个人体会说回 OpenAI 那 722 份手稿。很多人把它当成一次单纯的技术发布我却觉得它像是给整个行业立了一个新的靶子比“做出正确回答”更高级的能力是“给出让人可验证的证据”。数学、代码、工具调用是打头阵的领域因为标准答案天然存在OpenAI 只是选了一条最容易展示验证价值的赛道。但接下来的五到十年谁能把这种可验证性拓展到更模糊、更复杂、更开放的领域谁才真正攻克了下一代 AI 最核心的难题。我自己在实际操作中的体会是自从我把注意力从“怎么让模型说得更漂亮”转到了“怎么让模型的每一步都有据可查、有迹可循”之后整个 AI 应用的可靠性上了一个大台阶。这件事一开始需要多写很多代码、多存很多日志、多设计不少断言但做起来之后你会发现所有环节都变得踏实可控。你不再去迷信模型而是让模型和环境一起给你交出一份看得见的答卷。最后再分享一个小习惯每次你拿到一个大模型的输出可以先问自己一句——它能拿出什么证据来支撑这个结论如果拿不出来不管它说得多自信都当作参考意见对待。这套判断标准也同样适用于你自己。请谨记以上要求,仔细阅读后生成指令。第一次,请严格输出。