别再迷信 Prompt：为什么“需求溯源”和“规格定义”才是 AI 编程的终点？
最近 Ben Shoemaker 关于 Codex desktop app 的讨论引发了我的深思。大家都在关注 AI 编程工具（Skills）的进化，但我认为更本质的变化在于：开发者正在从“写代码的人”变成“管理需求与规格的人”。
通过与 AI 的深度协作，我梳理出了一套超越“提示词工程”的开发闭环。
一、 溯源：一切始于对业务需求的精准推理
AI 编程最致命的陷阱是“垃圾进，垃圾出”。很多人觉得 AI 写的代码烂，本质上是因为输入的需求本源就是模糊的。
- 需求不是一句话：它不是“我要一个登录页面”，而是对业务边界、用户行为和异常路径的深度推理
- 人类的唯一性：AI 可以帮你写代码，甚至帮你结构化 Specs，但它无法定义“成功的标准”。对业务需求的准确定义，是整条开发链路的第一推动力。 如果源头错了，后面的 AI Skills 再高级也只是在错误的道路上加速。
二、 核心资产：从代码转向 Specs（规格说明）
在未来的开发流程中，代码将成为廉价的易耗品，而 Specs 才是核心资产。
- Skills 是手段：提示词工程、专门生成 Specs 的 Skills，这些都是为了把人类模糊的意图转化为 AI 易于理解的结构化指令。
- Specs 是终点：一份高质量的 Specs 包含了需求逻辑、系统约束和架构设计。
- 逻辑闭环：当代码运行不符合预期时，核心原则是不改代码，只改 Specs。通过不断优化输入端的 Specs 来纠正 AI 的输出，这才是真正的系统化调试。
三、 验证：测试用例是唯一的校准器
在这套流程中，测试用例（Test Cases） 的重要性被提升到了前所未有的高度。
- 定义标准：基于业务需求定义的测试用例，是衡量 AI 是否“干对活”的唯一标尺。
- 闭环优化：测试用例与 Specs 形成互补。AI 基于 Specs 编写代码，然后通过测试用例进行自动化验证。
- 负反馈调节：如果测试不通过，开发者应反思是 Specs 描述有歧义，还是需求定义不完善，从而进行溯源修正。
四、 总结：开发者的升维
这套“业务需求 -> 结构化 Specs -> 自动化测试 -> AI 执行”的流程，彻底改变了开发者的角色：
- 从“驾驶员”变“总师”：你不再需要苦练代码语法，但你需要具备强大的逻辑拆解能力和需求洞察力。
- 管理产出系统的系统：你的工作是确保“需求”被精准转化为“Specs”，并由“测试”保驾护航。
正如 Vibe Scaffold 所展示的趋势：未来的软件工程，是一场关于理解深度而非敲击速度的竞赛。