作为长期与代码为伴的开发者,近期最深的体会是:AI 编程并非简单的提示词工程,而是一套全新的工作流。
当前许多实践仍停留在'凭感觉'阶段——想到哪说到哪,让 AI 随意生成,只求跑通。这种模式被称为 Vibe Coding(氛围编程)。
其显著特征在于:
- 靠直觉、靠模糊意图驱动
- 写小 Demo、独立脚本特别快
- 但一到复杂业务,立刻暴露问题:AI 幻觉、逻辑跑偏、代码不可预测、后期根本没法维护
简言之,Vibe Coding 适用于快速验证想法,却撑不起企业级、可维护的真实项目。
这就引出了一个问题:如何让 AI 编程变得可靠、可控且可审计?
解决方案是 Spec Coding(规范驱动编程)。
这相当于为 AI 编程确立了一部'宪法'。不是让 AI 自由发挥,而是先定义精确、无歧义的规范(Spec),再让代码严格服从契约。
两者核心差异一目了然:
- 依据不同 Vibe 靠感觉,Spec 靠结构化文档、接口定义、业务规则。
- 可靠性不同 Vibe 结果不可控,容易堆技术债;Spec 行为可预期、可验证。
- 成本分布不同 Vibe 前期爽,后期维护爆炸;Spec 前期花点时间写规范,后期极稳、成本极低。
核心结论:
Vibe Coding 是玩原型,Spec Coding 才是做工程。
Spec Coding 的四步标准化流程
我把这套方法拆解成了标准化流程,任何人都能直接照搬:
-
Specify(产品定义) 先把'做什么'写清楚,像产品经理一样输出类 PRD 文档:目标用户、核心功能、边界、要解决的痛点,把需求锁死。
-
Plan(技术规划) 进入技术方案:确定技术栈、系统架构、接口契约、代码规范,把'怎么做'定下来。
-
Tasks(任务拆解) 把大方案拆成原子化任务,每个小任务都配上明确的验收标准(AC),AI 不许跑偏。
-
Implement(AI 执行) 把
requirements.md、design.md、tasks.md一起交给 AI。接下来你不用盯着、不用反复改提示词,只负责最终验收。
这才是 AI 时代高效、稳健的开发方式。
支持该流程的工具生态
我也关注了目前支持这套流程的工具:
- Spec-Kit:GitHub 上很火,让 Claude、Codex 无缝跑 Spec 工作流
- Amazon Kiro:亚马逊推出的 IDE,原生支持'先写 Spec 再写代码'
结语
AI 不是来替代程序员的,而是在倒逼我们从'敲代码的人'升级为'定规范、控质量、管系统的人'。
还在靠 Vibe Coding 碰运气?想把 AI 真正用进企业级项目里?希望代码可预测、可审计、可维护?
Spec Coding,就是你要找的答案。
未来的资深工程师,将不再比拼手速,而是擅长定义规则与契约的人。

