将计算力投入正确性

对于完全拥抱AI代理的开发者而言，生产力已不再是瓶颈。代理生成代码的速度远超人类，且往往质量更优。真正的瓶颈在于正确性：代码是否真正解决问题？架构能否承载不断增长的功能集？实现是否编码了正确的先决条件？实践上的转变是，应将相当一部分代理计算力投入验证（测试、审查、范围检查），而非生成更多代码。

一年前，推崇代理编程的理由是吞吐量：代理让你用更少的时间交付更多代码。这一点如今已毫无争议。借助当前一代模型（如Claude Code、Codex等）构建的代理框架，一名开发者监督一个代理，其产出便能媲美一支小型手写团队。对于完全融入这种工作流程的人而言，问题不再是“如何产出更多？”，而是“如何确保产出是正确的？”。

正确性可能在三个层面失败。首先是产品层：代码是否符合用户需求？这仍需要人类判断。实际用户必须审视运行中的产品，确认其是否真正满足需求。没有代理计算能替代这一点。你能做的最高效工作是让这位人类的工作变得轻松：快速部署到真实环境，使用真实数据，以便用户能直接交互并反馈。

其次是架构层：代码结构是否合理？这是最难的一层，也是当前代理最薄弱的环节。经验丰富的软件工程师的许多工作是架构判断：如何组织代码以适应未来特性，而不预知具体需求；知道哪些特性不应实现；识别特性集何时超出原始架构的容量，需要在添加更多代码前重构代码库。代理在这些方面均不擅长——它们会愉快地按你的要求添加功能，却往往放在最不合适的位置，采用使后续三个功能更难实现的抽象。它们会实现你所要求的可配置性，而不会质疑你是否应该需要它。它们会不断扩展已超出假设的结构，因为每个单独的差异在孤立审视时仍然合理。这一层的补救措施是人类主导的架构审查，并由一个明确负责对照事实源文档检查每个差异的代理辅助。

第三是实现层：代码是否如其声称般运行？这种失败模式最容易被忽略：代码看起来正确，测试通过，但实际上却是错误的。其编码的前提稍有偏差；中间存在测试恰好未覆盖的变通方案；一个声称“处理边缘情况”的辅助函数实际上吞没了应传播的错误。这是编写代理自身无法察觉的失败模式，因为它继承了自己早期推理中的前提。它需要另一双眼睛（审查代理、新上下文子代理或完全不同的代理类型）来读取差异，而不带编写者的假设。

补救措施说起来简单，但更难坚持：将相当一部分代理预算用于验证。运行编码代理团队的目的不再是更快地生成更多代码，而是提高代码正确的概率。在实践中，验证包括多项内容：测试（包括昂贵的端到端测试、Playwright浏览器测试、代表性数据运行）；持续代码审查，而不仅限于PR阶段——在上下文中包含架构文档和任务列表的审查代理会读取每个差异；以及对照事实源文档的范围重检——差异是否偏离了原始要求？代理是否悄悄扩大了范围？是否实现了事实源明确禁止的内容？

错误在于将验证视为对生产力的税收。事实并非如此。一个经过验证的编码代理的产出，其价值远超两个未经验证的编码代理的产出之和。

有几种投入验证计算力的模式，它们并不互斥：同一代理内的代码审查子代理（Claude Code和Codex均内置了强大的代码审查子代理，编写者可在任务中途生成它，获得本地反馈并应用，捕获bug、缺失边缘情况和风格违规）；用不同代理类型审查编写者（让Claude Code生成Codex进行审查，反之亦然，不同训练和先验能捕获略有不同的问题）；以及持久化专业审查代理——每个重要任务配备两个代理，一个程序员一个审查员，它们持久存在、共享任务列表，并在每个TDD周期后交流。作者认为最后一种模式最有用，是上下文最丰富、成本最高但最具价值的验证计算形式。

转变在于：早期推崇代理编程的理由是每小时注意力能产生更多代码——这依然正确且有用。但对于已置身此种工作流程的人而言，更重要的理由是：如果你将计算力投入正确性，每小时注意力能产生更多正确的代码。瓶颈已经转移，预算也应随之而动。