这半年我越来越确定一件事：AI Coding 拉平的是“写代码的速度门槛”，不是“做好软件的能力门槛”。
很多人以为用了 Codex、Claude Code、Cursor 之后，开发能力差距会快速消失。实际情况恰好相反。在简单任务上，差距确实会被压缩；但到了复杂系统、长期维护、架构演进、线上风险这些场景，人与人之间的差距反而更容易暴露。
原因很简单：AI agent 能执行，但它不会自动替你成为一个好工程师。
AI Agent 改变了编码方式，但没有取消工程判断
OpenAI 在讲 Codex 的 harness engineering 时提到一个很重要的方向：人负责 steering，agent 负责 execution。这个判断非常准确。
以前工程师的很多时间花在手写样板代码、查 API、改重复逻辑、补测试细节上。现在这些工作确实可以大量交给 agent。但更上层的问题没有消失：
这个需求是否应该做？
应该改哪一层？
边界怎么切？
测试怎么证明没破坏旧行为？
这段代码半年后别人还能不能维护？
这些问题，仍然主要取决于使用 agent 的人。
所以，同样一个 Claude Code，有人用它快速生成一坨“看起来能跑”的代码；有人用它完成小步修改、跑测试、做 review、补边界条件、删掉不必要的抽象。最后产物当然不一样。
AI 把体力活变少了，但把判断力放大了。
关键区别一：会不会把任务变成清晰的问题
GitHub Copilot 的官方实践文档里有一个很朴素但很关键的建议：给 agent 的任务要 well-scoped，要有清楚的问题描述、验收标准，以及最好知道哪些文件需要改。
这听起来像 prompt 技巧，其实不是。这是软件工程里的需求澄清能力。
差的人会这样用 agent：
“帮我优化一下这个模块。”
“这个页面有 bug，修一下。”
“把代码重构得优雅一点。”
这种输入的问题不是不礼貌，而是不可验证。Agent 只能自己猜：什么叫优化？bug 复现路径是什么？优雅是少文件、少抽象、还是类型更严？
强的人会把问题压缩成 agent 可以执行的形状：
“修复用户取消订阅后仍然收到 billing email 的问题。复现路径是 A、B、C。预期行为是 D。优先检查 billing/ 和 notification/，不要改动 payment provider 适配层。需要新增一个覆盖取消订阅状态的单元测试。”
这两种任务交给同一个模型，结果不会一样。
很多所谓“AI 写代码质量差”，本质上是人没有把问题定义清楚。模糊输入产生模糊实现，然后人再抱怨模型不懂业务。
关键区别二：会不会给对上下文，而不是给一堆上下文
Anthropic 在 context engineering 相关文章里反复强调，agent 的表现很大程度取决于上下文组织。OpenAI 也讲过类似观点：对 agent 来说，运行时拿不到的知识就等于不存在。
这句话对 AI Coding 太重要了。
很多项目真正的约束并不在代码里，而在人的脑子里、飞书文档里、Slack 讨论里、历史事故里、某个没人敢删的配置里。你不给 agent，它就只能从当前文件和局部搜索结果里猜。
但另一个极端也不对：把十几个文件、几万行日志、整份需求文档全塞进去，通常只会让模型在噪音里迷路。
强的人不是“给更多上下文”，而是给更高信号的上下文：
- 当前行为和期望行为
- 相关调用链
- 关键数据结构和状态流转
- 不能破坏的兼容性约束
- 已经试过但失败的方案
- 必须通过的测试或手工验证步骤
这就是为什么同样用 agent，有的人越用越准，有的人越用越乱。前者在做 context engineering，后者只是在复制粘贴。
关键区别三：会不会拆任务，而不是让 agent 一把梭
Anthropic 在 building effective agents 里有个很现实的建议：先从简单、可组合的模式开始，只有需要时再增加复杂度。复杂 agent 不是越自由越好，很多时候固定 workflow 反而更稳定。
这对写代码尤其明显。
低质量用法通常是：
“实现这个完整功能，顺便重构一下，顺便把测试补了，顺便修一下 lint。”
然后 agent 一次性改 20 个文件。表面上很爽，实际上 review 成本巨大。你不知道哪一处是必要修改，哪一处是模型顺手发挥，哪一处引入了未来的坑。
更可靠的用法是分阶段：
第一步，让 agent 只读代码并说明现有实现。
第二步，让 agent 提出最小修改方案。
第三步，只允许它改目标文件。
第四步，运行测试。
第五步，根据失败信息继续修。
第六步，让另一个 agent 或同一个 agent 做 diff review。
这不是保守，而是工程上的可控性。
AI agent 很擅长执行局部任务，但不代表你应该把所有不确定性一次性交给它。好的使用者会把大问题拆成一串小问题，让每一步都有反馈和校验。
关键区别四：有没有测试和验证闭环
AI Coding 最大的幻觉之一，是“代码看起来合理”就等于“代码质量不错”。
这非常危险。
DORA 关于 AI 辅助软件开发的报告里提到，AI 采用率提升和文档质量、代码质量、code review 速度提升存在正相关。但这类结果不能简单理解成“用了 AI 就自然变好”。真正起作用的，往往是团队有没有把 AI 放进已有工程流程里：测试、review、CI、文档、发布、回滚。
METR 2025 年那项针对经验丰富开源开发者的随机对照实验也很值得警惕。研究对象使用当时的 Cursor Pro 和 Claude 3.5/3.7 Sonnet，在自己熟悉的成熟项目上做真实任务，结果 AI 工具反而让完成时间平均增加了 19%。一个关键原因是：AI 输出需要理解、检查、返工，它并不会免费变成生产级代码。
这说明什么？
说明 AI 生成代码的速度不等于交付速度。真正决定质量的是后面的验证闭环：
- 单元测试有没有覆盖新行为
- 回归测试有没有跑
- 类型检查和 lint 有没有过
- 关键路径有没有手工验证
- diff 有没有被人认真 review
- 安全、权限、并发、幂等这些非功能问题有没有检查
差的人把 AI 当代码生成器。强的人把 AI 当一个需要被测试约束的 junior engineer。
关键区别五：工程品味会被放大，而不是被替代
这可能是最核心的一点。
AI 可以写出语法正确、局部合理的代码，但它很难自动知道一个团队真正想要什么样的代码。比如：
是要加一个抽象，还是先保持重复？
是要引入新依赖，还是用现有工具函数？
是要做完整通用方案，还是先修当前 bug？
是要追求类型极致严谨，还是保持调用方简单？
是要修改数据库 schema，还是先在应用层兼容？
这些都是工程品味。
没有品味的人用 AI，会更快地产生没有品味的代码。过去他一天只能写 200 行糟糕代码，现在 agent 可以帮他一天生成 2000 行。问题不是变小了，而是变大了。
有品味的人用 AI，则会更快地探索方案、验证假设、删除废代码、补齐测试。他不会因为模型给了一个复杂方案就接受，也不会因为代码能跑就合并。
所以 AI Coding 时代真正稀缺的，不是“会写 for 循环”的能力，而是：
- 判断什么不该做
- 控制变更范围
- 看懂系统边界
- 识别隐藏风险
- 设计可验证的方案
- 对代码可维护性有稳定标准
这些能力越强，agent 越像放大器。能力越弱，agent 越像噪音制造机。
关键区别六：会不会审查 AI，而不是崇拜 AI
Veracode 2025 年关于 GenAI 代码安全的报告给了一个很直接的提醒：AI 生成的代码即使功能上看起来可用，也可能在安全上有明显缺陷。它们测试了大量模型和任务，结论是安全问题并不会因为代码“看起来现代”就消失。
这件事和日常业务代码一样。
AI 很容易写出一种“表面正确”的代码：命名不错，结构完整，注释也像那么回事。但它可能漏掉鉴权、漏掉异常分支、漏掉并发条件、漏掉数据迁移兼容、漏掉多租户隔离。
差的人会被这种表面完整性骗过去。
强的人会反过来问：
这里为什么没有权限校验？
这个重试会不会造成重复扣费？
这个缓存 key 是否包含租户？
这个 migration 对大表安全吗？
这个 API 行为是否破坏旧客户端？
这个测试只测 happy path，有没有覆盖失败路径？
AI 越会写“像样的代码”，人越需要有审查能力。否则最危险的不是代码一眼很烂，而是代码看起来很好。
所以，真正的关键区别是什么？
我的结论很明确：AI Coding 时代，人与人的差距不再主要体现在“谁更会敲代码”，而体现在谁更会管理不确定性。
具体来说，是这六种能力：
第一，任务定义能力。能不能把模糊需求变成可执行、可验收的小任务。
第二，上下文组织能力。能不能给 agent 足够但不过量的信息。
第三，任务分解能力。能不能设计一个小步迭代、有反馈的工作流。
第四，验证能力。能不能用测试、CI、review、手工检查约束输出质量。
第五，工程品味。能不能判断什么代码值得留下，什么代码应该删掉。
第六，系统责任感。能不能意识到最终负责的是人，不是模型。
这也是为什么我不相信“AI 会让所有程序员水平差不多”这个判断。它会让很多基础编码动作变便宜，但不会让工程判断自动变便宜。
恰恰相反，当代码生成越来越容易，真正稀缺的会变成提出好问题、设定好边界、建立好反馈、做出好取舍的人。
以后怎么用 AI Agent 写出更好的代码
如果要给一个非常实用的工作流，我会建议这样做：
先让 agent 读，不要急着让它写。让它总结现有实现、调用链、相关测试和风险点。
然后让它给方案，不要急着让它改。要求它说明最小变更路径、影响范围、需要新增或修改的测试。
接着限制修改范围。一次只做一个明确目标，不要把功能开发、重构、格式化、测试修复混在一起。
再强制验证。能跑测试就跑测试，能跑 typecheck 就跑 typecheck，前端就截图看，后端就构造请求测。
最后做 diff review。重点看不必要的抽象、误删逻辑、边界条件、安全权限、兼容性和测试是否真的证明了行为。
这套流程不花哨，但有效。
AI agent 是一个很强的杠杆。杠杆不会替你决定方向，只会放大你施加的力。你给它清晰问题、关键上下文和严格反馈，它会放大你的工程能力。你给它模糊需求、错误上下文和松散标准，它也会放大这些问题。
所以，使用 Codex、Claude Code 之后，代码质量仍然不同，答案并不神秘。
区别不在于谁拥有 AI，而在于谁更像一个能驾驭 AI 的工程负责人。
参考资料
- OpenAI, Harness engineering: leveraging Codex in an agent-first world: https://openai.com/index/harness-engineering/
- Anthropic, Building effective agents: https://www.anthropic.com/engineering/building-effective-agents
- Anthropic, Effective context engineering for AI agents: https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
- Anthropic, Writing effective tools for AI agents: https://www.anthropic.com/engineering/writing-tools-for-agents
- GitHub Docs, Best practices for using GitHub Copilot to work on tasks: https://docs.github.com/en/copilot/tutorials/cloud-agent/get-the-best-results
- Becker et al., Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity: https://arxiv.org/abs/2507.09089
- DORA, The impact of generative AI in software development: https://dora.dev/ai/gen-ai-report/
- Veracode, AI-Generated Code Security Risks: What Developers Must Know: https://www.veracode.com/blog/ai-generated-code-security-risks/
