KEEL · 龙骨 · A CURRICULUM FOR THE AI ERA
03 · 场景 B：从 0 到 1 新建项目 — keel 龙骨
这一章回答：怎么让 AI 产出的新项目不只是"能跑"，而是半年后还活得下去。
这一章回答：怎么让 AI 产出的新项目不只是"能跑"，而是半年后还活得下去。
全新项目里 AI 的输出最爽：没有历史包袱，想怎么设计就怎么设计。风险也在这里——它可以一路顺畅地做出一个跑不起来的漂亮项目，或者一个能跑但注定要重写的半成品（业内称为"原型悬崖"）。
一、技巧：把"想清楚"变成可执行的规格
vibe coding 到 2026 年最主流的补药叫 SDD（Spec-Driven Development，规格驱动开发）。它的核心命题只有一句：先把"要做成什么样"写成一份可校验的规格，再让 AI 据此生成代码，并用自动化机制把它当作执行契约。 传统文档是给人看的，SDD 的规格是要能跑起来当闸门的。
不必一上来就全套流程，先记住一份合格规格的六个要素：
| 要素 | 内容 |
|---|---|
| 预期结果 | 做完之后能看到什么 |
| 范围边界 | 做什么、不做什么 |
| 约束条件 | 技术栈、性能、合规、不可违反的原则 |
| 已定决策 | 选了什么、放弃了什么、为什么 |
| 任务拆分 | 可逐步验证的步骤 |
| 验证标准 | 怎么判定它做对了（而不是"跑起来了"） |
对应到落地节奏，推荐这个六步循环（含实践演化出的第 6 步 Verify）：
Constitution（项目宪法）→ Spec（规格）→ Plan（实现计划）
→ Tasks（任务清单）→ Implement（Red-Green 循环）→ Verify（逐条验收）
- Constitution：写死不可违反的原则。"代码要高质量"是口号，"金额一律用 Decimal 不用 float"才是原则——它明确了什么不能做，以及愿意付出什么代价。这就是第 06 章里
AGENTS.md的上位概念。 - Spec：用"给定-当-则"把验收场景写到不能更细。一条验收场景对应一个测试用例，写完 Spec，测试数量和覆盖范围就定了。
- Plan：写代码前确定方案，重点是记录为什么，以及做 Constitution 合规检查。
- Tasks：从 Spec + Plan 机械推导的执行清单，每个任务遵循测试先行。
- Implement：Red-Green 循环。RED 不可跳过——一个写出来就通过的测试不是在验证代码，是在自欺欺人。
- Verify：逐条对照 Spec 的验证标准出验收报告。Vibe coding 止步于"能跑"，SDD 止步于"逐条验收通过"。
关于投入程度：Thoughtworks 的 Birgitta Böckeler 把它分成三层——
| 层级 | 做法 | 建议 |
|---|---|---|
| spec-first | 写规格指导开发，之后丢弃 | 从这里开始，先养成习惯 |
| spec-anchored | 规格与代码一起维护，改代码必须改规格 | 多数团队最终的落点 |
| spec-as-source | 规格是主产物，代码生成后不手工改 | 激进，工具尚不成熟 |
高频迭代的产品不必每次走满六步，可用轻量 SDD：保留 Constitution，Spec 简化为关键验收场景，Plan/Tasks 合并，但必须保留 Red-Green 循环和 Verify 两步。
二、其他五条实操技巧
- 先让它交"骨架"，不要直接要成品：第一轮只做三件事——目录结构、数据模型（类型/schema）、一条端到端主链路。审阅这三者，比审阅三千行代码省十倍力气。
- Walking skeleton：第一步就要能跑。第一个里程碑不是"功能完成"，而是"能在本地启动、能走完一条最简路径、能看到结果"，哪怕这条路上全是硬编码。能跑的系统比完美的设计文档更能暴露问题。
- 给它一个真实参照物：参考某个开源项目或官方脚手架的目录结构与配置方式。有真实参照，依赖版本、配置格式、构建命令都不会跑偏。
- 一次一层地加料：骨架 → 数据层 → 接口层 → 业务规则 → 边界与错误 → UI/CLI。每加一层跑一次验证，让它始终保持可运行。
- 让它写下决策理由：每个重要选型输出一句"为什么选它、放弃了什么、什么情况下该换"。这份记录是日后维护时最值钱的东西，也是对幻觉选型的一次自查——编不出理由的选型，通常意味着它只是随大流。
三、注意点
| 维度 | 做法 |
|---|---|
| 依赖选型 | 让它报出包名 + 版本 + 许可证；你确认存在且被维护后再安装。一次只加一个依赖，加完立刻跑通 |
| 版本锁定 | 从第一个 commit 就锁定版本（lock 文件、固定版本号），不要让"最新版"进来 |
| 约定一次定死 | 目录命名、文件命名、导出方式、日志格式、错误类型、配置来源，写进 Constitution / AGENTS.md |
| 工程底座第一天就要有 | README 三条命令（装、跑、测）、格式化/lint、一条冒烟脚本。补底座的成本随项目规模指数上升 |
| 错误处理从第一个模块开始 | 不要"先把功能跑通，错误处理后面补"——后面永远不来 |
| 安全默认值 | .gitignore 先建；密钥只走环境变量；对外接口默认鉴权，而不是"先开放方便调试" |
四、避雷清单
- ❌ 一口气生成整个项目：几十个文件看着完整，实则依赖冲突、入口没接、配置缺失。分阶段，每阶段必须可运行。
- ❌ 幻觉依赖：包名不存在、API 是旧版的、参数是它想象出来的。反制只有一个：真的安装、真的跑起来，失败立刻让它换。
- ❌ 跳过 RED：直接生成代码再补测试，测试会退化成"描述现状"而非"验证行为"。
- ❌ 过度抽象：AI 喜欢上接口、工厂、策略模式的层层封装。三层以下的项目先写直白代码，等第二处真的需要复用再抽。
- ❌ 只有 happy path：0→1 项目最常见的半成品形态——演示时一切顺利，一断网、一空值、一并发就崩。每个对外接口都要求它显式列出失败场景。
- ❌ 缺测试与日志：全新项目没有历史包袱，恰恰是建立习惯成本最低的时候。
- ❌ 许可证与合规盲区：依赖的 license、第三方 API 条款、用户数据怎么处理——AI 不会主动提醒，必须你亲自过一遍。
- ❌ 把 demo 当产品：缺配置管理、缺迁移脚本、缺部署方式。"能跑"到"能交付"之间的距离，要在第一轮就摊开讨论。
动手：可观察结果
用 SDD 起一个小项目（例如"带鉴权的 TODO API"），交付这五样产出：
| 产出 | 判断标准 |
|---|---|
CONSTITUTION.md |
至少 5 条有取舍的原则（不是口号），每条写明代价 |
spec.md |
核心功能每条验收场景都是 Given-When-Then，且能直接对应到测试 |
tasks.md |
每个任务可在 30 分钟内完成并独立验证 |
| Red-Green 记录 | 有新写的测试先失败的证据（贴第一次运行的失败输出） |
| Verify 报告 | 逐条对照 Spec 的 PASS/FAIL，附原始命令输出而非 AI 的总结 |
做完这个项目你会明显感觉到：前两个小时的产出比直接开写慢，但从第三天开始，返工次数会低一个数量级。
故障注入
| 注入方式 | 观察 |
|---|---|
| 不给 Constitution，直接说"做个记账本" | 看它默默替你做了多少技术选型，其中几个是你不接受的 |
| 让它"直接实现，测试后面补" | 检查补出来的测试是否只断言了状态码、是否描述现状而非验证行为 |
| 允许它用最新版依赖 | 一周后重新装依赖，看有没有因为上游升级而崩掉 |
| 不要求列失败场景 | 数一数有多少接口在参数为空、依赖超时时直接 500 |
自测题
- 一份"合格规格"的六个要素是什么？少了哪一个最容易出问题？为什么？
- 为什么 Red-Green 循环里 RED 阶段不可跳过？一个写出来就通过的测试意味着什么？
- spec-first / spec-anchored / spec-as-source 三层承诺，你现在的项目处在哪一层？要不要往下一层走？
- "把 demo 当产品"通常体现在哪三样东西的缺失上？
- 举一个你项目里"如果有 Constitution 就能避免"的技术决策。