AI Coding 真正的瓶颈，不是技术，是需求
AI Coding 走到今天，一个常见的误解是：把它的瓶颈定位在"AI 还不够会写代码"。
这个判断两年前可能成立，今天已经不成立。
让一个稍微像样的模型写一段功能模块、设计一份接口、选一个技术栈、排查一个报错——只要你能把场景描述清楚，它在绝大多数情况下都能给出合理的方案。它会的语言比你多，看过的代码比你多，遇到过的错误也比你多。在"实现能跑的代码"这件事上，AI 已经越过了大部分工程师的水平线。
真正卡住 AI Coding 的，是另一件事：AI 没法替你想清楚你到底要什么。
一边是 vibe coding，一边是 spec 重得没人用
行业目前对这件事的两种极端做法都有问题。
一端是 vibe coding——凭感觉、聊几句、让 AI 直接干。短期效率很高，长期代码会变成"屎山"：结构混乱、模块耦合度高、完全不符合软件工程的要求。
有人会说，AI 编码不需要符合软件工程，把 AI 写的代码当黑盒就可以——只关心需求有没有实现，不必关心代码怎么写。但软件工程要解决的是可维护性、稳定性、性能。当项目规模过了某个临界点，维护复杂度呈指数级攀升，缺陷往往根植于底层架构而非孤立片段。在这种"技术债累积"的情境下，AI 同样会陷入"牵一发动全身"的脆弱性——新需求引入会让整个系统松动，bug 修复也会顺手挖更多坑。
软件工程仍然必要，不是一种"对老派工程师的妥协"，是一条客观规律。
另一端是 spec-heavy 工具，主张走完整的产品流程：PRD、原型图、架构设计、技术方案、测试用例。从工程的角度无可挑剔，但对绝大多数实际开发者，这种工具用一次就不会再用第二次——回报率太低。我自己能明确告诉 AI 要改哪里、怎么改，为什么要先写 PRD？
两种极端各自漏掉了一半真相。vibe coding 漏掉了"工程仍然必要"；spec-heavy 漏掉了"工程必要不等于工程要做满"。
把瓶颈定位准确
把 AI Coding 的所有挑战拆开看，可以归到三类：
- 架构与可维护性——软件工程的核心议题
- 技术方案与实现——选什么库、用什么模式、怎么排查 bug、怎么写一段具体的代码
- 需求理解——用户脑子里那张图，到底是什么样
这三类里，真正没被模型能力进化抹平的，只剩第三类。
第二类——技术方案——AI 已经做得很好。你只要把场景描述清楚，它通常能给出合理选型、合理结构、合理实现。排查 bug 同理——你把现象贴过去、报错贴过去，它会自己写调试语句让你抓信息回来，loop 已经形成。这件事一年前还是难题，现在不是。
第一类——架构与可维护性——AI 没有完全做好，但它能做好。前提是把工程意识喂给它：通过项目级别的规范文件（CLAUDE.md / AGENTS.md 之类）、明确的目录结构约定、预先写好的模式约束。这些东西不需要每次对话重述，写一次就长期生效。
第三类——需求理解——是 AI 自己没法解决的部分。它不知道你为什么想要这个功能、不知道这个功能在你脑子里长什么样、不知道你嘴里说的"差不多就行"是宽到什么程度。这部分卡点不在 AI，在用户那边。
Spec 模式应该只保留需求那一节
由此可以反推一种更轻量的最优做法：spec 的各个环节可以都保留，但用户的注意力应该极度倾斜——只在需求侧深度投入，其他交给 AI 自己跑通。
- PRD / 需求文档：要写得足够细，且这是你唯一需要认真投入的部分。这是 AI 没法替你做的事。你需要在动手前把脑子里的图尽可能具体地写下来——这个功能服务什么场景、用户怎么进、边界条件有哪些、什么样的产出算合格。这一步做得越扎实，AI 后续干得越好。
- 技术方案：让 AI 出，但不需要你认真审核。它自己能选型，且选得不比你差。你扫一眼方向不歪就行，不用像传统 code review 那样逐项推敲。把这部分注意力省下来，留给需求。
- 架构设计：通过规范文件长期生效，而不是每次写设计文档。项目的工程约定写在 CLAUDE.md / AGENTS.md 里——目录结构、命名约定、依赖偏好、不允许的写法——让模型每次自动 follow，而不是每次对话重新讲。
- 测试用例：让 AI 写，但靠真实运行验证。不要因为"工程化"而强求覆盖率——这件事的回报率在个人项目里几乎为零。重点是关键路径能跑通。
这套做法的核心姿势是：Spec 不需要被砍掉，但需要被重新分配权重。把工程意识做成"环境"而不是"流程"——前者是一次性投入、长期生效，后者是每次都要走、消耗的是你最稀缺的注意力。而这点稀缺注意力，应该全部留给需求。
Kiro 那种工具失败的不是 spec 这件事本身，而是它把所有 spec 环节都当成了等价的、都需要用户认真投入的工作。真正需要用户深度参与的只有一节——需求。其他环节 AI 已经能跑通，硬要用户每一项都"认真审核一遍"，纯属把注意力浪费在错误的地方。
几个推论
第一，写 PRD 的能力，是 AI Coding 时代被严重低估的技能。它表面上是"产品经理的活"，本质上是"把脑子里模糊的图变清晰"的能力。这件事没有模板，也没法被自动化——它就是"用户知道自己要什么"和"用户能说清楚自己要什么"之间那条 gap，对话产品里、AI 编程里，是同一条 gap。
第二，工程素养仍然必要，但它的存在形式变了。它不再表现为"工程师亲手写架构"，而是"工程师把工程意识沉淀进环境"。中级工程师的具体执行工作被模型吃掉了大部分，但"判断什么是好架构、把约束写成规范"这件事仍然是工程师的事。
第三，AI Coding 真正的护城河，正在从"代码能力"迁移到"需求能力"。谁能更清晰、更具体、更不偷懒地描述自己要做什么，谁就能从 AI 这里拿到更好的产出。这件事和编程经验只是部分相关——一个会写代码但不擅长想清楚需求的程序员，和一个不会写代码但擅长想清楚需求的产品经理，今天的差距比一年前小了很多。
收尾
AI Coding 的中心问题，正在从"让 AI 写出能跑的代码"迁移到"让 AI 写出符合你脑子里那张图的代码"。
前者是工程问题，后者是认知问题。
工程问题在退潮——因为模型越来越聪明，因为环境越来越成熟，因为工具链越来越自动化。但认知问题不会退潮——它取决于一个人能不能在脑子里把一件事想清楚，再把它说清楚。
这是 AI Coding 真正难的部分，也是它真正区分人的部分。