大家都在用 AI 编程，为什么有的人更快，有的人只是在制造烂代码

同样用 AI 编程，有的人是在加速交付，有的人是在加速制造技术债。

过去一年，很多程序员的工作方式都变了。

以前接到一个需求，我们先读代码、看文档、画流程、写方案、改代码、跑测试。现在很多人的第一反应变成了：把需求丢给 Codex 或 Claude Code，让它先写一版。

这件事本身没有问题。

AI 确实能帮我们更快地读代码、生成样板、补测试、改接口、查问题。对一个熟悉业务、熟悉代码库、有工程判断的人来说，它像一个很强的加速器。

但问题也在这里。

同样都在用 AI，有的人一天能推进过去两三天才能做完的任务；有的人看起来提交得更快了，但代码 review 变得更痛苦，bug 更隐蔽，改动范围更不可控。

差距不在于谁用了 Codex，谁用了 Claude Code。

真正的差距在于：你有没有一套能稳定定义任务、约束 AI、验证结果、沉淀经验的工作流。

会让 AI 写代码，不等于会让 AI 交付任务

很多人以为 AI 编程就是“把需求说清楚，让 AI 写代码”，但真实工程里，最难的从来不是生成代码，而是定义什么叫正确完成。

我见过一种很典型的用法。

需求来了，开发打开 AI 工具，直接输入：

帮我实现这个功能。

或者：

帮我修一下这个 bug。

AI 很快开始工作。它读了一些文件，改了几个类，顺手补了点逻辑，最后告诉你：

已完成。

如果这是一个脚本、demo、一次性页面，也许问题不大。但放到真实业务系统里，这种方式很容易出事。

因为真实系统不是一堆孤立代码，而是一组长期演进出来的边界和约定。

一个字段可能同时出现在数据库、DO、DTO、VO、转换器、查询条件、导出逻辑和测试断言里。一个状态可能不只是枚举值，而是影响审批、通知、账务、风控和运营后台。一个公共方法可能被很多链路复用，改一处就会影响一片。

AI 并不是不知道怎么写代码。它的问题是：如果你没有告诉它边界在哪里，它会自己猜。

于是 bad case 就出现了。

让 AI “优化一下这段逻辑”，它顺手重构了一个公共方法。当前需求看起来没问题，但另一个老链路被影响了。

让 AI “修一个 bug”，它没有先复现问题，而是猜了一个原因，改了表现层，让测试通过了，但业务语义仍然是错的。

让 AI “加一个字段”，它只改了接口返回，漏了数据库字段、转换逻辑、查询条件和测试用例。上线后才发现某个列表能展示，某个导出却还是空的。

这类问题的本质不是 AI 太弱，而是人把一个没有边界的任务交给了 AI。

真正会用 AI 的工程师，不会一上来就让它改代码，而是先让它理解任务。

他会先问：

• 这个需求涉及哪些模块？
• 哪些文件可能需要修改？
• 哪些已有行为不能被影响？
• 哪些地方只是读取，哪些地方可以改？
• 这个功能做到什么程度才算完成？

当这些问题没有被回答时，AI 写得越快，风险反而越大。

速度快不等于效率高，可验证才是效率

AI 让代码出现得更快，但只有验证链路完整，速度才会真正变成效率。

很多人刚开始用 AI 编程时，会被一个体验迷惑：代码真的出来得很快。

以前要半小时写完的接口，现在几分钟就有了。以前懒得补的测试，AI 也能很快生成一堆。以前要翻半天代码才能定位的调用链，AI 读完后能马上给你总结。

这当然是效率提升。

但问题是，生成速度不是交付速度。

真实工程里的“完成”，不是 AI 回复“已完成”，也不是本地编译暂时通过，而是至少要回答几个问题：

• 需求主路径是否覆盖？
• 边界条件是否处理？
• 异常路径是否合理？
• 原有行为是否没有被破坏？
• 测试是否能证明这些结论？
• 代码 diff 是否控制在合理范围内？

如果这些问题没有答案，AI 生成得越快，后面返工也可能越快。

一个常见 bad case 是：AI 写了测试，但测试只覆盖 happy path。

比如新增一个回调处理逻辑，AI 很快补了一个“回调成功时状态更新”的测试。但真实场景里更重要的可能是：

• 重复回调怎么办？
• 回调状态晚于系统状态怎么办？
• 金额不一致怎么办？
• 订单不存在怎么办？
• 下游账务处理失败怎么办？

如果这些测试没有覆盖，代码看起来完成了，实际只是覆盖了最容易的一条路。

另一个更危险的 bad case 是：测试失败后，AI 为了让测试通过，去改测试断言。

这在 AI 编程里很常见。你把报错丢给它，它会努力“修到绿”。但它不一定知道，应该修的是业务逻辑、测试数据、断言语义，还是需求理解。

如果人不控制方向，AI 可能会把一个暴露真实问题的测试，改成一个不再暴露问题的测试。

这就是为什么我越来越觉得，AI 编程的核心不是“会不会写 prompt”，而是“有没有验收体系”。

这也是 SDD 值得引入的地方。

我理解的 SDD，不是为了写一堆漂亮文档，也不是让开发流程变慢。它真正的价值，是在写代码之前，先把“什么叫完成”说清楚。

一个更好的 AI 编程流程应该是：

1. 先写清需求边界。
2. 再写清设计和影响范围。
3. 再拆成可执行任务。
4. 每个任务都有验收标准。
5. 最后才让 AI 进入实现。

没有 spec 的 AI 编程，常常是在用生成速度掩盖需求不清。

真正的效率，不是 AI 一次生成多少代码，而是它生成的代码有多少可以放心合并。

真正稳定的不是 prompt，而是 workflow

Prompt 能提升一次输出的质量，workflow 才能提升长期交付的稳定性。

很多人在讨论 AI 编程时，会把重点放在 prompt 上。

比如怎么描述角色，怎么给上下文，怎么写约束，怎么让 AI 输出更完整。

这些当然有用。

但如果只停留在 prompt 层面，很容易遇到一个问题：这次效果很好，下次又不稳定。

因为真实开发不是一次问答，而是一条链路。

它包括：

• 理解需求。
• 阅读代码。
• 确认边界。
• 拆分任务。
• 编写代码。
• 补充测试。
• 定位失败。
• 审查 diff。
• 验证结果。
• 总结沉淀。

任何一个环节失控，最后都会体现在代码质量上。

这也是我觉得 Superpowers 这类 workflow 有价值的地方。

它不是给 AI 一段更长的提示词，而是把优秀工程师本来就应该有的习惯，变成更硬的流程约束。

比如 using-superpowers 的价值，是提醒模型在执行前先检查有没有适用流程，而不是看到任务就直接开干。

brainstorming 的价值，是在需求不清时先澄清问题、提出方案、确认设计，而不是凭感觉实现。

writing-plan 的价值，是把任务拆小，明确每一步改什么、怎么验证、边界在哪里。

test-driven-development 的价值，是先定义失败用例，再写实现，而不是先写一堆代码再补一个能过的测试。

systematic-debugging 的价值，是遇到 bug 先复现、定位、验证，而不是靠猜测乱改。

verification-before-completion 的价值，是没有跑验证命令，就不能轻易说“完成”。

这些东西听起来并不神秘。

甚至可以说，它们本来就是一个靠谱工程师应该做的事。

但 AI 编程的问题在于：模型天然倾向于给答案，倾向于满足用户，倾向于快速完成任务。它不会天然停下来问“需求是否清楚”，也不会天然坚持“没验证不能说完成”。

所以你需要 workflow。

高质量 AI 编程的核心，不是让 AI 更自由，而是让 AI 在正确的流程里发挥能力。

如果把这些问题整理一下，可以得到这样一张表：

常见 bad case	本质问题	workflow 防线
一句话让 AI 直接开干	任务边界不清	先做需求澄清和影响范围分析
AI 一次改了十几个文件	改动范围失控	先拆 plan，再限制每个任务的修改边界
测试失败后让 AI 修到变绿	没有定位失败原因	先复现、定位，再限定修复范围
AI 只补 happy path 测试	验收标准太弱	先定义边界条件和异常路径
每次都临场写 prompt	经验无法复用	把高频流程沉淀成 skill

体现AI 编程能力，我不会在意用了哪个工具

工具名字只能说明你接触过 AI，控制 AI 的方式才能说明你真的会用 AI。

如果现在面试一个候选人，他说自己深度使用 Codex、Claude Code 或 Cursor，我不会只问：

你用哪个工具？

这个问题价值不大。

因为工具会变，模型会变，命令行、IDE、插件也会变。真正值得问的是：你怎么控制它。

我可能会这样追问。

第一个问题：

你拿到一个中等复杂度需求后，会怎么交给 AI？

不太好的回答是：

我把需求贴进去，让 AI 先写一版。

更好的回答应该类似：

我会先让 AI 读需求和相关代码，列出影响范围。然后我会确认哪些模块可以改，哪些模块不能改，再让它给出实现方案和验收标准。方案确认后，才进入编码。

这个回答背后体现的是任务定义能力。

第二个问题：

AI 改了十几个文件，你怎么判断它有没有过度修改？

不太好的回答是：

能跑就行，review 时再看。

更好的回答是：

我会先看 diff 是否服务于当前需求，再按模块职责检查每个改动是否必要。公共方法、基础模型、核心流程的修改要特别谨慎。如果 AI 为了当前需求绕过了已有抽象，我会要求它收敛改动。

这个回答背后体现的是边界意识。

第三个问题：

AI 说已经完成了，你怎么验收？

不太好的回答是：

看它总结说完成了，再本地跑一下。

更好的回答是：

我会按验收标准逐条检查，跑相关测试，必要时补测试。除了主路径，还要看异常路径、边界条件和已有行为有没有被破坏。最后会让 AI 自审 diff，但不会只相信它的总结。

这个回答背后体现的是验证意识。

第四个问题：

测试失败时，你怎么避免 AI 乱修？

不太好的回答是：

把报错继续丢给 AI，让它修到通过。

更好的回答是：

我会先确认失败能否稳定复现，再判断失败原因是实现问题、测试问题、环境问题还是需求理解问题。修复时会限定范围，避免 AI 为了让测试变绿去改断言或绕过业务逻辑。

这个回答背后体现的是 debug 方法。

第五个问题：

你有没有把一次成功经验沉淀成可复用流程？

不太好的回答是：

每次我都会写得更详细一点。

更好的回答是：

高频任务我会沉淀成 checklist、模板或 skill。比如需求分析要先读哪些材料，代码生成前要确认哪些边界，完成前必须跑哪些验证命令，遇到哪些 bad case 不能继续往下走。

这个回答背后体现的是工程化能力。

所以，面试里真正有价值的不是“我用 AI 提效了多少倍”。

更有价值的是你能不能解释清楚：

你如何让 AI 稳定地产出可 review、可验证、可维护的代码？

好的 Skill 不是提示词，而是一套可执行约束

一个好的 skill，不是告诉 AI 多做点什么，而是明确规定它在关键节点不能跳过什么。

很多人把 skill 理解成“更高级的 prompt”。

这只对了一半。

Prompt 更像是一次对话里的指令，而 skill 更像是一套可以反复执行的工作规程。

一个真正有用的 skill，至少要回答几个问题。

第一，什么时候触发？

比如遇到 bug 修复时，必须进入系统化 debug 流程。遇到需求不清时，必须先做 brainstorming。准备说“完成”之前，必须先做 verification。

如果没有触发条件，skill 就只是一段躺在文件里的建议。

第二，执行前必须读什么？

不同任务需要的上下文不一样。写业务代码要读需求、设计、相关模块、测试。修 bug 要读报错、日志、复现路径、最近变更。写文章要读定位、写作标准和历史风格。

如果不规定输入上下文，AI 很容易凭空补全。

第三，哪些事情不能跳过？

这是 skill 最重要的部分。

比如：

• 需求没澄清，不能直接写代码。
• 没有复现 bug，不能直接猜修复。
• 没有跑验证，不能声明完成。
• 没有看 diff，不能认为改动安全。
• 没有用户确认设计，不能进入大范围实现。

这些硬门禁，比“请你认真一点”更有用。

第四，怎么验证结果？

一个没有验证方式的 skill，很难证明它真的提升了质量。

好的 skill 应该告诉 AI：最后要产出什么，跑什么命令，看什么结果，哪些情况算失败，失败后怎么回退到前一步。

第五，记录哪些 bad case？

skill 不应该只写理想流程，也应该写反模式。

比如：

• 不要为了通过测试修改断言。
• 不要在没有边界确认时重构公共方法。
• 不要把一次性修复扩展成大范围架构调整。
• 不要只覆盖 happy path。
• 不要把“AI 总结完成”当成验收完成。

这些 bad case 其实就是经验。

一个工程师越成熟，他见过的失败模式越多，也越知道在流程里提前拦住它们。

所以我越来越觉得，skill 的本质不是提示词资产，而是把你的工程判断固化成可复用、可验证、可执行的工作流。

AI 编程时代，工程师更需要设计系统

AI 会写代码以后，工程师的价值不是消失了，而是从“亲手写每一行代码”转向“设计一套能稳定产出好代码的系统”。

未来，大家都会用 AI 编程。

工具差异会越来越小。模型会越来越强，生成代码会越来越快，很多过去需要手写的样板代码会变得不再值钱。

但这不代表工程师的价值变低了。

恰恰相反，工程师的判断会变得更重要。

因为 AI 越能写代码，越需要有人判断：

• 这个需求到底该不该做？
• 任务边界应该怎么切？
• 哪些模块不能动？
• 哪些异常路径必须覆盖？
• 哪些测试能证明它真的完成？
• 哪些改动会变成未来的技术债？
• 哪些经验应该沉淀成团队流程？

如果一个工程师只会让 AI 写代码，他得到的是一次输出。

如果一个工程师能把 AI 放进工作流，他得到的是一套可以持续放大的工程能力。

这才是 AI 编程真正拉开的差距。

不是你会不会用某个工具。

而是当工具越来越强时，你有没有能力把它纳入一套高质量的工程系统里。

后面我想继续展开两个问题。

第一个是：SDD + Superpowers 到底如何把 AI 编程变成可控流程。

第二个是：如何写一个真正有用的 skill，而不是写一段更长的 prompt。

因为到最后，AI 编程拼的不是谁更会许愿。

拼的是谁更能把需求、边界、验证和经验，变成一套稳定运转的工程流程。