8.0
热点
AI SCORE
编程提效2026-10-10 03:03
AI 写代码比人理解还快：工程瓶颈已转向代码审查
dev.to · AI#AI编程#工程流程#代码审查
Editor brief · 编辑速览
AI 编程工具大幅加速代码生成，但人工理解代码成为新瓶颈；作者提出传统开发流程需重构，应对 AI 生成代码的审查与设计验证挑战。
AI coding Agent 大幅改变了软件开发的速度。
过去需要一个团队花几周完成的任务，现在有时几个小时就能实现。AI Agent 可以探索代码仓库、理解现有模式、编写代码、运行测试，再发起 pull request——而此时，人类可能还在努力读懂最开始的几个文件。
这带来了一个新的工程问题：
瓶颈不再是写代码，而是理解正在构建的东西。
许多工程团队采用 AI 编程工具，目标很明确：加快开发速度。
但这也带来了一个令人不安的副作用。
工程师需要审查的代码量，增长速度可能远远超过他们理解代码的能力。
在系统迁移或采用不熟悉的框架时，这个问题尤其棘手。你可能既要学习新的架构，又要审查 AI 生成的代码，还要理解其他人的改动，同时还被要求比以前交付得更快。
单纯靠阅读更多代码来解决这个问题，无法应对不断增长的规模。
我们需要一种不同的工作流程。
传统的工作流程大致是：
任务单 → 开发者理解问题 → 开发者设计方案 → 开发者编写代码 → 审查
有了 AI Agent，流程很容易变成：
任务单 → Agent 探索代码仓库 → Agent 设计方案 → Agent 编写代码 → Pull request
实际上，人类已经被排除在一些最重要的推理环节之外。
更好的工作流程是：
任务单 → AI 调研 → 架构提案 → 人类理解 → AI 实现 → 人类审查
在让 Agent 写代码之前，先让它解释清楚：
这项功能目前位于哪里？
这项功能目前位于哪里？
现有系统是如何工作的？
现有系统是如何工作的？
涉及哪些组件、服务、API 或数据流？
涉及哪些组件、服务、API 或数据流？
具体需要改动什么？
具体需要改动什么？
最小且合理的改动是什么？
最小且合理的改动是什么？
应该遵循哪些现有模式？
应该遵循哪些现有模式？
这次改动可能破坏什么？
这次改动可能破坏什么？
我们应该如何测试？
我们应该如何测试？
目的不是让 AI 慢下来。
目的是确保在代码开始大量增加之前，工程师已经理解了这次改动。
你不需要理解 AI 生成的每一行代码。
你需要对系统有足够的理解，能够回答五个问题：
这个功能位于哪里？
这个功能位于哪里？
它周围的架构是什么样的？
它周围的架构是什么样的？
为什么这个实现是正确的？
为什么这个实现是正确的？
如果你能回答这些问题，就能审查一个大型改动，而不必逐行手动还原代码的逻辑。
你的价值未必还在于亲手敲出每一行代码。
它越来越体现在理解问题、做出好的技术决策，以及验证 AI 的产出上。
AI 编程 Agent 也是强大的学习工具。
遇到不熟悉的代码时，不要只问：
“这段代码是做什么的？”
“教我理解这个实现。假设我了解旧架构，但刚接触这个框架。请把其中的概念对应到我已经熟悉的知识上。”
“为什么选择这种方案？”
“还有哪些替代方案？”
“这段代码基于哪些假设？”
“这个实现可能出错的三种方式是什么？”
这样一来，AI 就从代码生成器变成了坐在你身边的资深工程师。
如果 AI 只是替你写代码，你对它的依赖就会增加。
如果 AI 在写代码的同时，还帮助你理解系统，你的工程能力也会随之提升。
采用新框架时，很容易想从头开始，把所有内容都学一遍。
但在快速推进的项目中，这通常不切实际。
更好的做法是，找出一小组核心概念，让它们能够解释你实际接触到的大部分代码。
对于一个新的 UI 框架，这可能意味着先重点学习：
然后，再学习你所在组织的架构如何使用这些概念。
你不需要先成为框架专家，才能参与开发。
你需要的是足够的理解，以便建立正确的心智模型。
当所有东西都在同时变化时，不要依赖记忆。
为你的应用维护一份简单的系统地图：
Application
│
├── Platform
│
├── UI
│ ├── Components
│ ├── State
│ └── Routing
│
├── Backend
│ ├── APIs
│ └── Services
│
├── Data
│
└── Testing
针对每个主要领域，记录四件事：
它是什么？我们为什么使用它？数据如何流经它？代码位于哪里？
让 AI 帮你随着系统的演进持续维护这份文档。
久而久之，它就会成为你对应用的心智地图，也让之后每一次 AI 生成的改动都更容易理解。
目标是形成能够预测系统行为的理解。
最终，你应该能够看到一张任务单，就想到：
“我大致知道这项改动应该放在哪里。”
接着，看到提出的实现方案，就想到：
“我理解 Agent 为什么选择这种方案。”
最后，看到 pull request，就想到：
“我能识别出哪些地方可能出问题。”
你可能并不理解每一行代码。
但你的理解已经足以预测系统的行为。
在 AI 辅助的工程环境中，这是一项更能应对规模增长的能力。
面对 AI 带来的开发提速，最大的错误就是一味要求自己也干得更快。
在生成代码这件事上，你无法与 AI Agent 竞争。
你应该把自己的工作重心向更上游移动：
理解问题 → 塑造架构 → 让 AI 实现 → 验证结果 → 从实现中学习。
在这种环境中表现出色的工程师，未必是写代码最多的人。
他们会是那些能够理解系统、做出正确决策，并在 AI 以机器速度运转时，仍然让人类掌握控制权的人。
部分评论可能仅对已登录的访客可见。登录后可查看全部评论。
如需采取进一步措施，你可以考虑屏蔽此人和／或举报滥用行为。