夜雨聆风[TechLoading ]产品解构室
AI 写代码已经不稀奇了。
真正的问题是：它写得越来越快，但不代表它审得越来越准。
很多人用 Claude Code、Codex、Cursor、OpenClaw 这类工具时，都会遇到一个很熟悉的场景：模型刚刚写完代码，你让它自己 review 一遍，它认真看了几秒，然后告诉你：
“整体逻辑没问题。”
结果一跑，问题全在。
这不是某一个模型不行，而是 AI 编程里一个很典型的盲区：自我 Review 往往是在复述自己当时写代码时的那套假设。
如果需求理解错了，代码会跟着错；代码错了，测试也可能按错误理解去写；最后模型再 review 一遍，只是在验证自己之前的判断。
于是，一个错误闭环就形成了。
单模型自审，最大的问题是“看不见自己的假设”
人写代码也有类似问题。
自己刚写完的代码，自己检查时往往看不到真正的问题，因为脑子里还保留着当时的设计路径。你不是在重新审代码，而是在顺着原来的思路确认“我应该没错”。
AI 也是一样。
尤其是现在的 Coding Agent，通常会在一个连续上下文里完成：
需求理解、方案设计、代码实现、测试生成、代码 Review。
这看起来很高效，但也带来一个风险：所有环节都来自同一套推理路径。
所以它很容易出现这种情况：
需求理解有偏差
代码实现继承偏差
测试用例覆盖偏差
Review 阶段继续确认偏差
最后表面上流程完整，实际上只是把错误包装得更完整。
这也是为什么很多 AI 写出来的测试能跑绿，但一上线就出问题。因为测试不是在验证真实需求，而是在验证模型自己以为的需求。
Claude 和 Codex 的差异，正好可以互补
从实际使用体验看，Claude 和 Codex 的能力偏好并不一样。
Claude 更擅长长上下文、架构梳理、跨文件重构、文档生成和整体方案设计。它像一个更偏 Staff Engineer 的角色，能把事情讲清楚，也能把系统结构搭起来。
但 Claude 的问题是，偶尔会抽象过头。它容易把一个小问题设计成一个完整框架，工程上看似优雅，实际落地成本偏高。
Codex 则更偏代码细节、Bug 定位、测试审查和底层逻辑。它更像一个抠细节的 Senior Engineer，能盯住边界条件、异常处理、接口兼容和测试有效性。
但 Codex 的问题是，有时容易陷在局部最优里，对产品目标、业务上下文和长期架构的把握不一定总是最稳。
所以二者的理想关系不是谁替代谁，而是：
一个主写，一个挑刺。
如果任务重点是架构、文档、跨文件改造，可以让 Claude 主写，Codex 审查细节。
如果任务重点是算法、调试、性能优化，可以让 Codex 主写，Claude 审查结构和可读性。
这背后的本质不是“哪个模型更强”，而是利用不同模型的训练分布、推理偏好和错误模式，制造一份低成本的第二意见。
最值得互审的不是代码，而是需求
很多人把 AI 编程理解成“让 AI 帮我写代码”。
但真正高价值的环节，往往在写代码之前。
尤其是需求文档、技术方案、接口设计、数据结构、异常流程这些内容，最应该拿去互审。
因为大部分代码问题，其实不是代码阶段才出现的，而是在需求阶段就埋下了。
例如一个需求文档里写：
“系统应支持失败后自动重试。”
听起来没问题，但 Codex 或 Claude 互审时可能会追问：
重试几次？
每次间隔多久？
哪些错误可以重试？
哪些错误不能重试？
重试期间状态如何展示？
重复请求如何幂等？
最终失败后资金、订单、通知如何处理？
这些问题如果不在 spec 阶段说清楚，后面写再多代码都只是补洞。
所以 AI 互审最重要的价值，不是合并前多找几个 Bug，而是在需求阶段就把含糊的地方打穿。
四个最值得固定下来的互审节点
第一，Spec 互审。
需求文档写完后，让另一个模型专门审：
有没有自相矛盾？
有没有“快速”“友好”“稳定”这类没定义清楚的词？
异常流程是否完整？
有没有隐含假设？
这是收益最高的一次 Review。
第二，测试互审。
测试一定要让没写实现的那一方来审。
重点看：
如果实现代码写错，这个测试会不会变红？
有没有测试只是验证“不报错”？
断言是不是太弱？
边界输入有没有覆盖？
很多 AI 生成的测试，其实只是“装样子”。测试跑绿，不代表系统真的可靠。
第三，Debug 二审。
遇到复杂 Bug 时，不要把一个模型的结论直接当答案。
更好的方式是：
先写出最小复现脚本，再让另一个模型在不看修复方案的前提下独立判断根因。
如果两个模型的判断一致，可信度会明显提高。
如果两个模型判断不一致，那反而是最值得深挖的地方。
第四，重要 Diff 互审。
合并前让另一个模型审最近一次 diff，重点看：
是否破坏公开接口？
是否偷偷吞掉异常？
是否和 spec 不一致？
是否引入并发、边界或兼容性问题？
这一步看似多余，但长期坚持下来，确实能拦下很多低级问题。
互审不是神坛，最终权威仍然是运行结果
需要强调的是，双模型互审不是万能的。
Claude 和 Codex 都可能错。两个模型意见一致，也不代表一定正确，只代表它们在这个问题上的盲区没有明显冲突。
所以真正可靠的流程应该是：
需求文档
技术方案
代码实现
测试用例
模型互审
真实运行
人工决策
模型可以提供第二意见，但不能替你承担最终判断。
尤其是在生产系统、支付系统、数据处理、权限控制、资金相关业务里，AI Review 只能作为质量控制的一环，不能作为上线依据本身。
Vibe Coding 的下一阶段，不是更快写代码，而是更低成本质检
过去半年，很多人对 Vibe Coding 的关注点都在“写得快”。
但写得快只是第一阶段。
当 AI 能快速生成代码之后，真正稀缺的能力变成了：
谁来审？
谁来挑刺？
谁来发现模糊需求？
谁来识别伪测试？
谁来阻止错误方案被自信地推进？
这也是 Claude 和 Codex 互审真正有价值的地方。
它不是让你少思考，而是让你更早看到问题。
AI 编程不是把人从工程流程里拿掉，而是把人的角色从“逐行写代码”推向“设定目标、约束边界、判断取舍、控制质量”。
未来真正稳定的 AI 开发流程，大概率不会是单个模型从头写到尾，而是多个模型分工协作：
一个负责规划。
一个负责实现。
一个负责审查。
一个负责测试。
最后由人来拍板。
这其实更接近真实的软件工程团队。
只不过团队成员从真人同事，变成了不同风格的 AI Agent。
结尾
单个 AI 写代码的问题，不是它不会写，而是它很难审自己。
自我 Review 是人和 AI 共有的盲区。
Claude 和 Codex 互审的核心价值，也不只是多发现几个 Bug，而是提供一份便宜、及时、相对独立的第二意见。
在 Vibe Coding 时代，代码生成能力正在变得廉价。
真正值钱的，是质量控制能力。
而让两个不同模型互相挑刺，可能正是普通开发者和产品团队最容易落地的一套 AI 质检机制。
TechLoading：科技加载中，持续记录 AI、消费电子与 Web3 的产品变化和行业信号。