AI Coding 最贵的不是写代码，而是决定什么值得验证
从 OpenAI 的数学突破，到 ETF Agent 几次真实的工程误判
AI Coding 正在让代码和候选答案变得越来越便宜，但可信的判断并不会随生成速度等比例增长。
我越来越觉得，工程师真正昂贵的能力，正在从“如何实现一个方案”，转向三个更重要的问题：
什么问题值得解决？什么假设必须被验证？什么程度的证据足以让我们作出决定？
这不是说人类要永远负责检查 AI 写出的每一行代码。恰恰相反，真正的进步应该是让机器承担越来越多能够自动验证的工作，把有限的专业判断留给那些真正决定系统价值与风险的地方。
最近两个月开发 ETF Agent 的经历，让我对这一点有了更深的认识。
一、当 AI 能够批量产生答案，我们真的更接近正确了吗？
2026 年 10 月，OpenAI 连续公布了大量 AI 生成的数学研究成果。
10 月 26 日，OpenAI 又发布了涉及 Kakeya 猜想、指数时间假设（ETH）和量子场论的研究成果。部分证明已经使用 Lean 进行形式化检查，但这些结果仍需要数学界进一步理解、审查和吸收。
在官方公告中，OpenAI 把模型生成的研究成果称为 Raw Research Data（原始研究数据），并邀请外部专家参与后续研究。
这个表述让我印象很深。
过去，一位数学家可能花费数年寻找一种证明方法。现在，AI 能够快速探索大量可能性，甚至生成复杂的完整证明。
但生成证明、检查形式化逻辑，与确认它证明了原本想证明的命题，仍然是不同的工作。
软件工程正在发生类似的变化。
Coding Agent 可以迅速实现功能、提出架构方案、补充测试，甚至让另一个 Agent 对实现进行评审。
原来因为开发成本太高而被放弃的想法，现在可能几个小时就能得到可运行的版本。
但我们是否因此更容易做出正确的技术决策？
最近两个月，我一直在集中使用 Agent 开发自己的 ETF Agent。随着功能越来越完整，我反而越来越明显地感受到一个变化：
我们越来越不缺少实现方案，却越来越需要判断一个看起来正确的方案，究竟有没有解决真正的问题。
而且，真正麻烦的往往不是 AI 生成了明显的错误。
是它生成了一个非常合理、甚至经过多项检查，却依然站不住脚的结论。
当生成答案越来越便宜时，识别关键假设、发现决定性反例，以及判断一个结果是否值得采用，就成了新的工程瓶颈。
二、一次真实投研：为什么报告完成了，结论却要撤回？
10 月 26 日，我们完成了一次 ETF Agent 的真实研究验证。
这次研究涉及后台执行、用户中途纠偏和并发对话。整个研究最终正常完成，原问题没有被其他短问题干扰，用户追加的要求也进入了后续模型请求。
从工程角度看，这是一次值得肯定的进展。
但人工复核最终报告时，我们发现模型根据两份文件的措辞，推断出一个结论：
某项跟踪约束比另一项严一倍。
这句话读起来很专业，甚至可能让人觉得模型进行了深入比较。
可问题是，原始材料并没有提供足够的同口径数据，来支持这个倍数判断。
两份文件描述了不同约束，不代表它们可以直接进行数量比较。
后续我们让 Agent 重新阅读一手文件，并撤回了这个推断。原始报告没有被悄悄覆盖，更正内容作为独立结果保存下来。
这次经历特别有代表性。
因为模型并不是没有查资料，也不是代码执行失败，更不是没有完成报告。
它真正出错的地方，是把两份材料中看起来可以比较的描述，变成了一个并没有得到证明的数量关系。
真正困难的是发现隐藏的前提
假设一份基金报告说“严格控制跟踪误差”，另一份报告给出了某项偏离度上限。
模型可能很自然地把它们放在一起，试图比较哪一个管理得更严格。
但熟悉金融指标的人会先问：它们是不是同一个指标？计算周期一样吗？一个是目标值，还是实际观测结果？
如果这些前提尚未确定，后面的计算再精确，也无法证明比较结论成立。
我们此前的持仓周报开发中，也遇到过类似问题：模型把子集收益率和全组合贡献百分点相互比较，甚至因为数值不同就怀疑供应商数据错误。
后来我们没有为这些错误额外建立一个万能的金融语义校验器，而是调整已有的金融研究指导，让模型先核对对象、时间窗口、分母和计算方法，再进行比较。
对于缺乏可比条件的资料，允许保留未知，而不是强行得出结论。
这项调整有过限定范围的真实模型验证，但没有因此宣布所有金融解释问题都已经解决。
这件事给我的启发是：
当 AI 给出一个结论时，先不要急着检查计算过程，应该先检查它用来推理的前提是否成立。
对于金融、医疗、法律等领域，这一点尤其重要。
有时候，真正昂贵的不是重新算一遍，而是知道哪些东西根本不应该放在一起计算。
三、再增加一个 Reviewer，真的能解决问题吗？
面对这种错误，最直观的工程方案是增加独立 Reviewer。
让一个 Agent 写报告，另一个 Agent 找错误。还不放心，就再增加几个专家，从不同角度讨论。
这当然可能有效。
但我们在 ETF Agent 中踩过另一个很有意思的坑。
10 月 18 日，我们在 Research Reviewer 的受控集成验证中发现：主 Agent 已经读取了完整资料，但传给 Reviewer 的摘要省略了重要的比较日期。
Reviewer 本身有独立上下文，也拥有读取原始结果的能力。
问题是，实际交接过程中，系统虽然调用了原始资料读取工具，却没有把读取出的完整材料交给 Reviewer，最终送进去的仍然是那份不完整的摘要。
换句话说：
我们建立了一个看起来独立的审查者，却没有真正为它提供独立审查所需要的信息。
如果 Reviewer 和原 Agent 都依赖同一份遗漏关键条件的摘要，即使它们给出一致意见，这种一致也不代表结论经过了充分验证。
后来我们的修复很简单：让原来已经读取且获准使用的材料真正进入 Reviewer 的输入，而不是重新发明一套数据获取和验证系统。
这次改动解决的是原始资料交接问题，不能直接推导为 Reviewer 的真实语义判断能力已经提高。
但它改变了我们对“验证是否有效”的理解。
过去，我们可能会问：
Reviewer 有没有调用成功？有没有输出评审意见？
现在，我们还需要问：
Reviewer 到底看到了什么？它有没有机会发现我们真正担心的那种错误？
这是两个完全不同的问题。
为什么我们后来没有让所有研究都强制经过 Reviewer？
10 月 21 日，我们又将引用与金融语义的事后评审设计为一种独立、按需使用的能力。
普通研究不必默认增加一轮审查。需要进一步复核时，可以针对一份明确的报告和原始材料，生成独立的评审结果。
评审可以指出疑点，却不直接修改原报告，也不自动取得发布和投资决策的权限。
这里其实有一个很现实的取舍。
如果用户只是查询某只基金的管理费，原始资料清楚、字段明确，增加多轮模型评审未必能带来相称的收益。
但如果 Agent 正在比较两个复杂的投资方案，并且其中某项结论会明显影响用户的资产配置，那么进一步复核关键假设就可能值得投入。
不是验证越多越好，而是验证需要与不确定性、错误代价和实际用途相匹配。
好的验证体系，不应该要求所有正常任务都证明自己绝对正确，而应该能够识别哪些判断真正值得额外检查。
四、但也不是所有验证，都应该交给人类
讨论到这里，很容易得出另一个极端结论：
AI 负责写代码，人类负责验证。
我并不赞同把它理解成一种永久分工。
因为验证能力本身也在被 AI 和自动化技术不断提高。
我们在 ETF Agent 的金融计算中，就遇到过一个很具体的例子。
对于一笔假设费用，137 元乘以 1.5% 的精确结果是 2.055 元。按照约定的舍入规则，应当得到 2.06 元。
但受控测试发现，旧的浮点计算路径曾经得到 2.05 元。
这类问题并不需要一个金融专家逐笔审核，也不需要调用更聪明的大模型重新判断。
我们需要做的是明确金额精度与舍入规则，让原始计算模块采用正确的十进制处理方式，再通过确定性测试检查。
这与前面的“跟踪约束严一倍”有本质区别。
一个问题已经有明确的数学规则，另一个问题连比较是否成立都需要判断。
如果一律使用 Reviewer，前者可能浪费成本，后者也不一定得到可靠结论。
真正合理的做法，是让容易形式化的正确性尽量交给机器，让有限的专业判断集中在难以直接形式化的问题上。
这也不是说金融语义永远只能由人处理。模型已经可以帮助提出反例、检查材料和识别不一致。
只是我们不能因为它能够给出审查意见，就把意见自动当成已经得到证明的事实。
五、对研发和架构师来说，工作方式应该怎样改变？
经历这些问题之后，我越来越倾向于改变 Code Review 和架构评审的起点。
过去，我们经常先看一个改动实现了什么，有哪些代码变化，补充了多少测试。
这些仍然重要。
但 AI Coding 时代，可以把更早的一步做得更明确。
先问：我们到底在证明什么？
比如一次需求叫“优化 Reviewer 的资料交接”。
这个说法太宽泛了。
换一种表达：
“Reviewer 在评估两份材料是否可比之前，必须实际收到原始比较日期。”
这样一来，真正值得验证的行为就清楚了。
我们不需要先写几十项检查，也不需要把完整研究重复运行很多次。
先构造一个摘要遗漏日期、但原始资料包含日期的场景，检查 Reviewer 实际收到的内容，就能直接检验这次修改的关键假设。
再问：什么反例能推翻这个方案？
这是我认为 Coding Agent 非常适合参与的一步。
人可以提出设计目标，Agent 则可以帮助寻找边界条件、生成反例、探索不同输入，甚至给出与当前方案相反的建议。
如果一个架构方案声称“多个 Reviewer 可以提高研究可信度”，我们就可以主动追问：
如果所有 Reviewer 都看到同一份错误摘要，会怎样？
如果它们引用了同一个过期来源，会怎样？
如果 Reviewer 无法取得关键原文，它会承认材料不足，还是继续生成自信的评审？
这些反例比简单要求 Agent “充分考虑各种情况”更有价值。
因为它们直接挑战方案赖以成立的前提。
最后问：证据到什么程度，就值得作出决定？
有些问题可以通过确定性测试直接解决。
有些问题需要在真实模型和相同输入条件下做对照。
还有些问题，例如某项投资分析是否足以支持具体行动，必须结合真实业务约束、风险和责任要求。
这三类验证不需要采用同一套标准。
真正重要的是知道：我们当前做出的决定，会产生什么后果？现有证据是否足以承担那个后果？
对一项低风险、可回退的内部研究功能，可以允许有限不确定性。
涉及资金执行、访问权限等高后果操作时，则必须保留明确的授权和执行保护，不能由模型一句“已经验证”来代替。
成熟的工程判断，不是要求所有事情都被验证到没有疑问，而是知道哪些疑问可以接受，哪些疑问必须在行动之前解决。
六、AI Coding 真正昂贵的，是判断力与验证资源
回到 OpenAI 最近的数学研究。
最让我受到启发的，不是 AI 生成了多少份证明，而是这些成果已经多到值得认真思考：应该怎样组织研究人员理解它们、核查关键假设，并把有价值的部分转化为可以继续使用的知识。
软件工程可能也会经历这样的变化。
以前，很多好的想法因为实现成本太高而没有机会验证。现在，我们可以快速得到越来越多的候选方案，但每一个方案都可能携带尚未发现的假设，也可能需要新的验证工作。
当答案的生产速度超过理解和判断的速度，继续提高代码产量，未必能让团队同比例地提高交付质量。
最近两个月 ETF Agent 的开发经历，让这个问题变得非常具体。
一份已经完成的金融报告，因为比较前提不成立而需要撤回结论；一个看起来独立的 Reviewer，因为缺少原始材料而失去了有效审查的基础；而一个精确计算错误，却可以在明确规则后交给确定性程序解决，根本不需要增加模型评审。
它们带来的启发是一致的：
不是所有问题都值得增加一层 AI，不是所有错误都需要更多测试，也不是所有正确性都必须依赖人的判断。
真正重要的是找到正确的验证方式，并让验证成本与问题的重要程度相匹配。
我认为，AI Coding 时代，工程师和架构师尤其需要把注意力放在三个地方。
第一，定义什么才算正确。 不只是把需求写成任务，而是识别业务目标、隐藏假设和必须保护的行为。一个比较是否成立，往往比比较公式是否算对更重要。
第二，知道怎样有效地推翻错误方案。 与其让 AI 不断生成支持现有设计的论据，不如让它寻找决定性反例。一个能够暴露关键错误的反例，可能比大量没有触及核心假设的测试更有价值。
第三，决定验证资源应该投入到哪里。 能用确定性方法解决的，交给工具；依赖复杂语义的，结合原始材料与独立审查；涉及资金、权限等高后果操作的，保留必要的授权、保护和责任机制。
这并不是让人类永远成为 AI 的最终裁判。
恰恰相反，随着模型、形式化方法和自动化技术进步，人类需要亲自完成的验证工作也会逐渐减少。
但只要软件系统仍然服务于现实中的用户和业务，就必须有人或一套具有明确责任的机制，决定我们究竟要实现什么、什么风险可以接受，以及什么时候值得采取行动。
AI Coding 降低了产生方案的成本，却不会自动降低作出错误决定的代价。
所以，未来优秀工程师的竞争力，可能越来越不体现在他能够亲自编写多少代码，而在于他能够让多少有价值的判断，被准确表达、有效验证，并最终转化为可靠的系统能力。
我们不应该再把研发效率简单理解成单位时间内生成多少代码、完成多少 PR，或者运行多少次测试。
真正值得追求的，是用更少的无效验证、更清晰的判断和更可靠的决策，持续解决更重要的问题。
当代码和答案越来越便宜，最昂贵的不是继续生产更多答案，而是能够回答：
什么值得做，什么值得怀疑，以及凭什么相信我们已经做对了。
这才是我认为 AI Coding 时代，软件工程能力真正需要升级的方向。
延伸阅读
- 代码越来越便宜，为什么系统却越来越难升级？：讨论创造、维护与架构演化的长期成本。
- 为什么 AI 明明有很多引用，回答还是不够可靠？：进一步讨论资料、引用和结论之间的关系。
- 金融 AI 最危险的“专业感”：金融数值、方法口径和可复算性的工程实践。
更多工程实践见 ETF Agent Engineering Notes。欢迎 Star 或分享能够挑战这些判断的工程反例。