AI 编程进入下半场：从 Vibe 到 Spec
type
status
date
slug
summary
tags
category
icon
password
wechat_gate
最近在看“从 Vibe Coding 到 Spec Coding”这组资料时，我最有共鸣的一句话是：
Code is a lossy projection of intent.代码是意图的有损投影。
这句话的价值在于，它把很多团队正在经历的问题说透了：
我们不是不会“写代码”，而是经常没有把“为什么这样写”变成可验证、可协作、可演进的规范。
本文默认你使用
Node.js 20 + TypeScript + Vitest + Claude Code，目标不是做一个 Demo，而是把 AI 辅助开发拉到生产级。问题分析：Vibe Coding 为什么总在后期失速
Vibe Coding 的优势是快，尤其适合探索期。但它在生产阶段常见 4 个问题：- 意图丢失：Prompt 只保留“怎么做”，很难沉淀“为什么这样做”。
- 结果漂移：多人协作时，每个人的 Prompt 风格不同，输出标准不一致。
- 验证滞后：先写代码再补测试，返工成本高。
- 经验不可复用：一次性对话很难迁移到下一个项目。
所以关键不是否定
Vibe，而是给它一个更稳定的“骨架”——Spec Coding。
解决方案：Spec Coding 的三层规范模型
把规范当成
source of truth，代码当成实现产物。推荐用三层结构：- 功能规范（What） 定义用户故事、验收标准、边界条件。
- 架构规范（How - 语言无关） 定义数据模型、API 契约、安全约束、性能目标。
- 实现规范（How - 语言相关） 定义技术栈版本、测试框架、编码约束、发布要求。
在 Claude Code 中，对应关系通常是：
CLAUDE.md：项目级总规范
.claude/rules/：分层规则
specs/*.md：功能级规范
/plan：把规范拆成可执行任务
实战示例：用规范驱动通知系统（可运行）
下面给一套最小可运行样例，体现“先规范，后实现，再验证”。
步骤 1：先写 specs/notification.md
步骤 2：实现 src/notification-service.ts
步骤 3：验证 tests/notification-service.test.ts
运行方式：
在 Claude Code 中的推荐指令
这条指令的重点是：把“生成代码”变成“执行规范 + 验证规范”。
最佳实践与常见陷阱
最佳实践：
- 规范与代码同仓库同版本管理，PR 同时审查。
- 每个规范都带验收标准和非功能性要求。
- 规范变更必须触发自动化测试，防止实现漂移。
常见陷阱：
- 规范只写 happy path，漏掉错误处理与边界条件。
- 把“实现细节”误写成“需求事实”，导致规范过早僵化。
- 只让 AI 生成，不做验证，把草稿当成成品。
渐进迁移：从 Vibe 到 Spec 的可执行路径
- 第 1 阶段（探索）
用
Vibe Coding在 30 分钟内验证想法是否成立。
- 第 2 阶段（沉淀）
把有效结论抽成
specs/*.md，补齐验收与约束。
- 第 3 阶段（重建） 基于规范重做生产实现，并强制测试与审查。
这个路径的核心是：速度来自 Vibe，质量来自 Spec。
总结
Spec Coding 不是替代 Vibe Coding，而是把 AI 编程从“会写”推进到“可交付”。当你开始认真维护
CLAUDE.md、rules、specs，你已经在做工程化的 AI 开发。一句话收尾：
规范不是文档附属品，规范本身就是代码。
如果你也在把 AI 从“会写”推进到“可交付”，欢迎留言说说你团队现在最卡的是规范、测试，还是协作流程。
参考资料
2026.04.09 17:26
沪 · 赵巷KFC
📌 声明：本文由 AI 辅助完成