如果放在几年前，真正同时认真审查 15 个软件项目，对我来说会显得很不现实。我说的不是打开 15 个 repository 随便看几眼，而是持续检查真实项目里的 Bug、错误假设、SEO 问题、翻译错误、本地化不一致、缺失测试、回归问题，以及已经和系统其他部分不再一致的旧代码。
真正的限制从来不是打字速度，而是注意力。每个项目都有自己的历史、约定、edge case，以及一些看起来不对、其实是有意保留的代码。严肃的 review 需要阅读、搜索、比较、执行检查，然后才能决定到底什么值得修改。
Codex 改变了这种重复工作的成本结构。它可以先对 repository 做第一轮检查，追踪 references，阅读相关文件，找出可疑 pattern，提出测试思路，并帮助我调查过去必须一个文件一个文件手动查看的区域。这并没有让最终决定自动化，只是让“做决定之前最昂贵的调查阶段”快了很多。
我现在最重要的一条规则很简单：我不是用 Codex 把自己从 review loop 里拿掉，而是用它扩大我能够覆盖的 review 范围。
真正的瓶颈是重复，不是写代码
只维护一个项目时，人可以记住非常多上下文。项目一多，这种方式就不再能扩展。同类工作会不断重复出现：
- 在不同 component 中寻找相似 Bug；
- 检查 refactor 后是否还留着旧 call site；
- 行为变化后重新检查 tests；
- 查找 metadata、语言规则、heading、internal link 的不一致；
- 比较 localization key 和翻译内容；
- 寻找缺失的 error handling 和 edge case；
- 确认一个“小改动”是否意外影响了更多文件；
- 阅读单个很简单、但累积起来极其耗时的 diff。
这些事情都不炫酷，但每一项都重要。当同一种 review 需要在多个 codebase 中反复进行时，成本会迅速放大。
这正是 AI coding agent 对我最有价值的地方：它可以吞掉搜索空间中重复的部分，让我把更多注意力留给判断。
我先让它检查，而不是直接允许“全部重写”
最容易得到坏结果的方法之一，就是给 agent 一个巨大任务：“检查整个项目并修复所有问题。”这听起来高效，却把 discovery、优先级、架构、实现和 validation 混成了一个失控任务。
把阶段拆开后，我得到的结果要好得多。
inspect → explain findings → prioritize → change → validate → review diff首先，我希望 agent 理解相关区域，并解释它到底发现了什么。我需要具体文件路径、受影响的代码、为什么它认为这里可疑、可能造成什么影响。修改应该发生在这之后。
原因很简单：AI 可以非常自信地犯错。某段代码看似多余，却可能是为了旧浏览器、某个支付 edge case、迁移路径，或者只看一个文件无法理解的业务规则。先检查再修改，可以让我在错误假设变成巨大 diff 之前把它拦住。
我把 AI 的 finding 当作线索，而不是判决
好的 Codex review 不应该停在“发现 17 个问题”。数字本身几乎没有意义，我更关心证据。
一个真正可执行的 finding，我希望知道：
- 问题在哪里；
- 为什么这是问题；
- 什么行为可能失败；
- 这个结论应该有多大可信度；
- 什么检查可以证明或否定它；
- 最小而安全的修复是什么。
这对 security、SEO 和业务逻辑尤其重要。Agent 可以指出值得调查的地方，但一段听起来很像安全报告的解释，并不等于已经证实的漏洞。SEO warning 不一定就是 ranking 问题。一个奇怪条件也不一定就是 dead code。
AI 降低的是“发现候选问题”的成本。最终什么是真的，仍然由验证决定。
真正让 workflow 可信的是 validation loop
代码生成是 AI-assisted development 最显眼的部分，但 validation 才是让它可以进入 production 的关键。
修改之后，我希望 codebase 自己“回答”。根据项目不同，这可能包括：
- TypeScript 或其他 compiler/type checker；
- lint；
- unit test 和 integration test；
- build check；
- 针对旧名称或 call site 的定向搜索；
- 人工阅读最终 diff；
- 手动验证用户可见行为。
具体命令没有这个 loop 本身重要。Agent 做出假设，repository 返回证据，下一步决策建立在证据上。
这也是为什么我很喜欢在强类型项目里使用 AI。我另外写过一篇文章，讲 为什么 TypeScript 在真实软件交付中和 Codex 配合得很好：类型系统能把很多错误假设立刻变成机器可读的反馈。
有些 review 类型特别适合 AI
Bug 和回归
Agent 可以跨文件追踪一个值、检查 callers、比较相似实现、寻找互相不一致的 branch。这很适合缩小问题来源。但在接受结论之前，我仍然会重现或用其他方式验证真实行为。
测试
AI 很适合发现“行为变了但 test coverage 没跟上”的地方，提出 edge case，并解释一个已有 test 实际保护了什么。它也能帮助发现只测试实现细节、却没有测试真实用户行为的测试。
SEO
Technical SEO 有大量一致性工作：metadata、语言 alternate、indexability、internal link、页面 template、sitemap generation、redirect 和 page-level rule。Agent 可以在大型 codebase 里比我手动打开每条 route 更快地比较这些规则。但我始终把技术正确性和更难的问题分开：内容本身到底值不值得获得排名。
本地化和翻译
这是多语言产品中最重复的领域之一。AI 可以比较 key、找到缺失值、发现明显的语言混用、检查 placeholder，并指出一个 locale 在结构上和其他 locale 的偏差。它比手动扫巨大的翻译对象快得多，但重要 copy 仍然需要人来判断。
Refactor 后的一致性
大型 refactor 经常因为很无聊的原因出问题：一个旧 import 没删，一条 route 还在使用旧字段名，一个 test fixture 保留了旧 shape。Repository-wide search 加上理解变更意图的 agent，在这里非常有价值。
并行工作只有在任务独立时才真正有用
很容易产生一种冲动：启动很多 agent，让它们同时修改所有东西。这可以增加 throughput，也同样可以放大 conflict 和互相矛盾的假设。
我把 parallelism 看成协调问题。独立 audit 很适合并行：一个项目检查 localization，另一个 review tests，或者不同 repository 同时被检查。两个 agent 在没有共同计划的情况下重写同一套 architecture，则完全是另一回事。
并行度越高，边界越重要：明确的 project、明确的 task、明确的 definition of done，以及可以单独 review 的结果。
目标不是让最多数量的 agent 同时运行，而是让有用且可验证的进展最大化。
有些事情我不会盲目交给 AI
- 架构决策：模型可以提出选项，但长期 trade-off 经常依赖 repository 之外的上下文。
- Security 结论：finding 需要验证、threat context，很多时候还需要专门工具。
- 业务规则：代码可以内部完全一致，却实现了错误的产品行为。
- 大型破坏性 refactor：diff 越大越难理解，也越容易被草率通过。
- Production deployment：测试通过并不等于运营风险消失。
- 最终 review：在我为一次改动负责之前，我想知道它到底改了什么。
不是因为 AI 在这些领域没用，而是因为这里“看起来很合理但其实错了”的答案代价特别高。
AI review 不是静态分析的替代品
我也不把 Codex 当作 compiler、linter、tests、scanner 或 monitoring 的替代。那些工具有 AI 没有的优势：范围窄、确定性强、可重复。
最强的 workflow 是把它们组合起来。Codex 可以基于上下文推理并建议从哪里调查。静态工具可以强制执行精确规则。测试验证行为。日志和 monitoring 显示真实系统发生了什么。人工 review 则把所有这些信号和产品意图连接起来。
如果没有这些 feedback systems，我对 AI 的信任只会更低，不会更高。
最大的生产力提升，其实是注意力分配变好了
最简单的说法是“Codex 帮我省时间”，但我觉得这低估了真正的变化。
软件开发里最稀缺的不是 keystroke，而是高质量注意力。在 AI coding agent 之前，大量注意力消耗在重复 discovery 上：反复搜索相同 pattern、阅读类似文件、追踪 reference、确认一个改动是否传播到所有位置，然后在另一个 repository 重新做同样的 audit。
现在我可以把更多 first-pass work 交给 agent，把自己的注意力留给更难自动化的判断：这个 finding 真的重要吗？fix 符合架构吗？用户体验会更好吗？风险可以接受吗？我真的想把它 ship 出去吗？
这就是为什么现在维护和 review 多个项目的感觉完全不同。我不是 review 得更少。很多时候恰恰因为机械工作不再耗光全部预算，我反而能 review 得更多。
我信任的 workflow
- 定义一个窄而清晰的 review 目标。 Bug、tests、SEO、localization、refactor 或其他具体问题。
- 先 inspect，再 edit。 我先要证据和受影响位置。
- 给 findings 排优先级。 并不是每个理论问题都值得改代码。
- 控制改动范围。 小而连贯的 diff 更容易验证。
- 运行机器检查。 Typecheck、lint、tests、build、search 或项目特定验证。
- 人工阅读 diff。 检查不必要 rewrite、错误假设、遗漏 edge case 和 scope 外改动。
- 验证重要行为。 尤其是用户、金钱、security、SEO 和 production infrastructure。
- 确认之后再进入下一个项目。 Parallelism 有用，但未解决的不确定性不应该悄悄扩散。
15 个项目已经不再像 15 倍的 review 工作量
Codex 没有让 15 个项目变简单，也没有替我承担责任。它改变的是规模和重复劳动之间的关系。
我可以要求更深入的 first pass、更广的 consistency check、更多 test idea 和更系统的 audit，而不必把每一分钟都花在每个文件里自己搜索。然后，我可以把节省下来的注意力用在仍然需要开发者判断的事情上。
这就是我认为有价值的 AI-assisted development：不是 autopilot，不是盲目信任，也不是“不断生成代码直到某个检查变绿”。而是让机器规模的 inspection 和人类规模的 judgment 形成更短、更紧密的循环。
对我来说，这才是 Codex 真正的 leverage。它没有取消 review，而是让严肃的 review 可以扩展到以前很难持续维护的范围。