AI没有杀死代码审查，而是让证明责任变得明确。发布变更时要附带手动验证和自动化测试等证据，然后利用审查来评估风险、意图和问责制。独立开发者依赖自动化来跟上AI的速度，而团队则利用审查来建立共享上下文和所有权。
如果你的拉取请求不包含证明其有效的证据，你并没有更快地发布——你只是把工作推给了下游。
到2026年初，超过30%的高级开发者报告称他们主要发布AI生成的代码。挑战在于：AI擅长草拟功能，但在逻辑、安全和边缘情况方面表现不佳——仅在逻辑错误方面就比人类高出75%。这导致了工作流的分化：独立开发者以“推理速度”凭感觉工作，依赖测试套件作为安全网；而团队则要求人工审查以确保上下文和合规性。如果处理得当，两者都将AI视为加速器，但验证——由谁、验证什么、何时验证——定义了差异。
正如我之前所说：如果你没有亲眼看到代码正常工作，那它就是无效的。AI放大了这一规则，而不是为其找借口。
根据你是独立开发者还是在团队中工作（其他人需要维护你的代码），工作流和思维方式会有显著差异。
独立开发者越来越“信任感觉”来接受AI生成的代码——通过仅审查关键部分并依赖测试来发现问题，从而快速发布功能。
这种工作流将编码助手视为强大的实习生，可以独立处理大规模重构。正如Peter Steinberger承认的：“我不再阅读太多代码。我观察代码流，有时查看关键部分，但大多数代码我不读。”瓶颈变成了推理时间——等待AI生成输出——而不是打字。
但有一个陷阱：如果没有强大的测试实践，感知到的速度提升就会消失。 先建立这些实践。如果你跳过审查，你并没有消除工作——你只是推迟了它。那些在高速度下成功使用AI的开发者，并不是盲目信任AI的人；而是那些建立了验证系统，在问题进入生产环境之前就能捕获问题的人。
这并不是说独立开发者会完全不顾风险。负责任的开发者会广泛使用自动化测试作为安全网——追求高覆盖率（通常>70%），并使用AI生成实时捕获错误的测试。现代编码助手在设计复杂的端到端测试方面出人意料地出色。
对于独立开发者来说，改变游戏规则的是语言无关、数据驱动的测试。 如果测试全面，它们可以让助手用任何语言构建（或修复）实现，并在过程中进行验证。我通常从AI草拟的spec.md开始项目，批准它，然后循环：编写→测试→修复。
关键的是，独立开发者仍然会对最终产品进行手动测试和批判性思考。运行应用程序，点击UI，自己使用功能。当涉及更高风险时，阅读更多代码并添加额外检查。尽管快速推进，但看到丑陋的代码时要修复它，而不是让混乱累积。