从 Vibe Coding 到 Spec Coding：AI 编码该有的样子

两种编码风格#

Vibe coding（凭感觉编码）： 打开 AI，把需求一股脑丢过去，让它”帮我写个 XXX”。AI 生成什么你就用什么，不顺再让它改。爽在即时反馈，像在飙车。

Spec coding（规范编码）： 写代码之前，先把项目规范、任务进度、上下文、经验教训沉淀到项目结构里，再让 AI 基于这些事实干活。

vibe coding 不是”错”，它在 demo、原型、一次性脚本里效率极高。但一旦项目长期化、需要多人协作或持续迭代，vibe coding 必崩——因为 AI 记不住上次怎么做的，每次都重新猜。

为什么 vibe coding 会崩#

根因是会话失忆：

• 今天和 AI 说”这个项目用 camelCase 命名”，明天新开会话它又给你 snake_case
• 上周定下的”错误码用数字枚举”，这周它给你写字符串
• 你踩过的坑，下次它会让你再踩一遍

vibe coding 把所有”应该怎么做”放在临时对话里。对话一结束，这些事实就蒸发了。你被迫每次重新传递上下文——传少了 AI 乱来，传多了 token 爆炸。

Spec coding 的核心：把事实从对话搬到结构#

spec coding 不是”把每件事都流程化”（那是官僚主义）。它的重点是：

沉淀长期有复用价值的项目事实，不在于把每件事都流程化。

什么是”项目事实”：

• 规范：命名约定、代码风格、技术栈选型、禁止行为清单
• 架构决策：为什么选 A 不选 B、哪些边界不能破
• 任务进度：做到哪了、下一步是什么、哪些坑已踩
• 经验教训：bug 根因、修复方案、踩过的陷阱

这些事实原来散在对话里，spec coding 把它们搬到项目结构里——README、ARCHITECTURE、规范文件、CLAUDE.md、任务清单、bug 日志。AI 每次干活前先读这些，自动对齐，不用你每次重讲。

三个具体做法#

1. 规范文件：项目根目录放一份规范（比如 CLAUDE.md），写清”这个项目该怎么做、不该怎么做”。AI 每次进来先读。

2. 架构先行：动手前先让 AI 输出功能解析 + 架构图 + 边界清单，确认无误再写代码。比直接让它”写”慢 5 分钟，但少走 2 小时弯路。

3. 经验闭环：修完 bug、做完决策，立刻沉淀到 wiki/文档里，以稳定引用（不是裸行号）记录。下次同类问题 AI 先查历史，不重踩。

它和 Harness 是一回事#

spec coding 是 Harness 在编码流程里的具体形态。Harness 是”让模型稳定干活的工程约束系统”，spec coding 是”工程师怎么用这个系统”。

我之前那套”永不遗忘系统”（对话记忆 + 代码图谱 + wiki 知识库）就是 spec coding 的工程实现——让我能跨会话、跨项目保留项目事实，AI 进来 5 秒就能对齐上下文。

结论#

vibe coding 适合一次性，spec coding 适合长期主义。判断标准很简单：

这个项目/任务一周后还要不要继续？ 要 → spec coding；不要 → vibe coding 随便爽。

从 vibe 到 spec 的转变，本质是给 AI 编码补上”项目事实”这一层。模型会升级，工具会更迭，但”把事实沉淀好”这件事会一直值钱。