Vibe Coding 基于Spec DD和TDD的实践指南

一、为什么 Vibe Coding 需要方法约束？

Vibe Coding 通常指开发者通过自然语言与 AI 编程工具协作，快速生成、修改和运行代码。它降低了实现代码的门槛，但并没有自动解决软件开发中最难的两个问题：需求是否理解正确，以及实现结果是否真的正确。

当我们只给 Coding Agent 一句"开发一个小红书内容和评论分析助手"，它可能很快生成页面、接口、数据结构和模型调用。但在动手之前，还有很多决定没有明确。为让后面的示例可落地，本文假设第一版由用户手动粘贴笔记标题、正文、话题标签和评论，或导入自己有权使用的数据文件；链接解析、自动采集等能力不默认纳入范围，需单独确认数据来源是否可用以及是否符合平台规则。比如：

• 是否支持按时间筛选？如果源数据没有可靠的评论发布时间，界面应如何说明？
• 重复导入同一条评论时，应该保存多份还是去重？
• 提交分析后才新导入的评论，是否应该混入本次分析？
• 没有评论、模型调用失败或输入过长时，界面应该怎样反馈？
• AI 回答引用了不在本次分析范围内的评论，怎样发现并阻止？

这些问题如果没有提前讨论，AI 仍然可以继续写代码，只是它会根据自己的推测填补空白。结果可能看起来完整，却和真正的业务预期不一致。

Spec DD 和 TDD 可以分别应对这两个问题：

• Spec DD 先明确"要做什么、做到什么程度"。
• TDD 通过先写测试、再实现代码，持续检查"做出来的东西是否符合预期"。

它们不要求所有事情都文档化，也不要求每个页面都先写大量测试。核心是把影响结果的关键决定说清楚，并让重要行为可以被验证。

二、先理解两个概念

2.1 Spec 和 Spec DD 是什么？

Spec 是 Specification 的简称，可以理解为对软件预期行为的具体说明。它需要回答：在什么场景下，谁提供什么输入，系统应该完成什么操作、产生什么结果，有哪些限制和异常情况，以及怎样判断功能已经完成。

Spec DD 通常指 Specification-Driven Development，也常写作 SDD，即规格驱动开发。基本思路是：先把预期行为和验收条件明确下来，再依据这些约定进行设计、编码和验证。

对于 AI 编程来说，Spec 还是一份可持续维护的上下文。它把之前散落在聊天记录里的关键决定沉淀成项目文件，开发者和 AI 都可以据此讨论、实现和检查。

Spec 不等于把所有技术细节都提前决定好。它应优先写清业务行为、输入输出、限制和验收标准；除非架构或技术约束会影响结果，否则函数叫什么、内部如何拆分等细节，可以留给 Agent 根据项目现状决定。

一份实用的 Spec 通常包含：

内容	要回答的问题	小红书内容和评论分析助手示例
目标与使用场景	谁在什么情况下使用？解决什么问题？	用户查看笔记内容和导入的评论，并针对选定范围提问
功能范围	本次做什么、不做什么？	分析单篇笔记，输出内容总结、表达特点和评论洞察；不自动发布笔记或评论、不检索站外资料
输入与输出	系统收到什么，返回什么？	输入笔记标题、正文、话题标签、评论和分析问题；输出内容总结、评论主题、常见问题及可追溯的原文依据
关键行为	哪些规则必须始终成立？	同一条评论不重复保存；每次分析固定使用一批评论；分析结论不能把输入中没有的信息当成事实
边界与异常	数据缺失或操作失败时怎么办？	没有评论时不生成评论洞察，但仍可按需分析笔记正文；模型失败后保留问题和输入范围供重试
验收条件	通过什么步骤和结果确认完成？	检查模型实际收到的笔记正文与评论是否符合选定范围，结论是否能追溯到输入材料
约束与待确认项	有哪些已知限制，哪些问题还没决定？	源数据没有评论发布时间时，不把导入时间伪装成评论发布时间

一个很有用的自检问题是：如果只让另一个开发者或 AI 读取这份 Spec 开发，哪些重要地方还需要靠猜？ 需要靠猜的地方，往往就是后续返工的来源。

2.2 TDD 是什么？

TDD 是 Test-Driven Development，即测试驱动开发。它的核心不是"开发完成以后补上测试"，而是让测试参与实现过程：先为一项行为编写测试，确认测试能够暴露目标行为尚未实现的问题，再写最小实现让测试通过，最后在测试保护下整理代码。

经典 TDD 循环叫作 Red → Green → Refactor：

1. Red（红灯）：写出下一项行为的测试并运行，确认它因为目标行为尚未实现而失败。
2. Green（绿灯）：编写足以满足当前测试的最小实现，重新运行并确认通过。
3. Refactor（重构）：在行为不变的前提下改善代码结构，然后再次运行相关测试。

Martin Fowler 对 TDD 的介绍也强调了这三个重复步骤，并建议先列出候选测试，再逐项选择和推进。参考：Test-Driven Development

TDD 中的测试应当有明确的预期，而不是只验证"接口没有报错"或"页面能打开"。例如，"重复导入同一条评论后，系统中仍然只有一条记录"，比"导入功能正常"更具体，也更容易验证。

需要注意：测试通过不等于软件绝对正确。 测试只能证明它实际检查过的内容符合预期。断言过于宽松、关键场景遗漏，或者测试根本没有真正运行，都可能造成"绿色但不可靠"的结果。

三、Spec DD 和 TDD 如何配合？

两者解决的是相互衔接、但不同的问题：Spec DD 明确目标，TDD 约束实现过程。中间需要把规格中的关键行为转成具体的测试用例（Test Cases）。

一个简单的协作链路是：

原始需求
   ↓
Spec：明确场景、范围、规则、异常和验收条件
   ↓
Test Cases：把关键规则拆成可检查的测试场景
   ↓
TDD：红灯 → 绿灯 → 重构，逐项实现
   ↓
功能验收：检查集成后的真实使用流程
   ↓
发现问题后，回到对应的 Spec、测试或实现进行修正

例如，Spec 里写着"本次分析只使用用户选定的评论"。这句话还需要被拆成测试用例：

• 选定范围内的评论应当进入本次分析输入。
• 范围之外的评论不应进入本次分析输入。
• 提交分析之后新导入的评论，不应自动加入已经提交的分析。
• 回答引用的评论 ID 必须属于本次分析输入。

这些用例固定了可以通过程序检查的行为。至于模型能否准确归纳评论主题，还需要另外使用真实模型和代表性样本进行效果验证。

Spec、Test Case 和代码应该保持可追溯关系：一条重要规则可以找到相应的测试用例；一个测试用例也应该说明自己在保护哪条规则。这样，当需求调整时，才知道需要同步修改哪些测试和实现。

GitHub 的 Spec Kit 也采用类似的规格驱动流程，将工作组织为 Specify、Plan、Tasks、Implement，并在进入后续阶段前审阅规格与计划。参考：GitHub Spec Kit Quickstart 这是一种可参考的流程实现，并不意味着每个项目都必须安装该工具；用 Markdown 文件和现有 Coding Agent，同样可以实践这套思想。

四、日常 Vibe Coding 的实操流程

建议把开发分成几个可检查的阶段。小需求可以合并步骤，大需求则可以把每一步单独完成；关键不是流程形式，而是不要让 AI 在重要规则尚未确认时，就直接进入大规模实现。

第一步：明确本次要完成的范围

先把一个大目标缩小为一个可以独立开发、独立验证的功能切片。不要一开始就要求 AI"一次性把整个系统全部做完"。

例如，"开发小红书内容和评论分析助手"可以先拆成：

1. 导入一篇小红书笔记的标题、正文、话题标签和评论，并正确展示；
2. 根据可用字段筛选评论，并固定本次分析输入；
3. 提交问题并展示模型回答；
4. 展示回答依据的原评论，并处理模型失败。

第一轮可以只实现第一个闭环。拆分范围时同时说明明确不做的事情，例如暂不支持多篇笔记批量分析、不自动发布笔记或评论、不做站外搜索。明确边界能够减少 AI 顺手扩展功能的情况。

第二步：让 AI 生成 Spec 草稿，但不要立即写业务代码

可以先用自然语言描述想法，再要求 Agent 只整理规格，不进行实现。这样可以集中审查业务行为，不会一边看大量代码、一边才发现需求问题。

可复制提示词：生成 Spec 草稿

我想开发一个小红书内容和评论分析助手。第一版由用户手动粘贴或导入一篇笔记的标题、正文、话题标签和评论数据，并在自己的界面查看。用户选择笔记内容和评论范围后，可以向 Agent 提问，界面展示内容总结、评论主题、用户关注点、常见问题及相关原评论。不默认实现自动抓取；数据来源和可用字段需要在规格中说明。

本轮只整理 Spec 草稿，不编写业务代码。请读取项目现有说明和相关规则，然后输出：
1. 使用场景、用户目标和功能范围；
2. 本次明确要做与明确不做的内容；
3. 主要操作流程；
4. 输入、输出、关键行为和状态变化；
5. 正常场景、边界情况和异常处理；
6. 可操作、可观察的验收条件；
7. 已知技术限制、待确认问题。

请明确区分：用户原始要求、你的建议、尚未确认的假设。不要把建议直接写成已确认需求。把草稿写入 spec/behavior_spec.md，并在末尾列出最需要我决定的问题。不要写业务代码。

初次生成的 Spec 是草稿，不是最终答案。AI 可能会提出合理建议，也可能在没有依据的情况下补充业务规则。因此下一步应当审读，而不是直接批准。

第三步：审查 Spec，优先追问会影响结果的问题

审读时不要只看文档是否完整、格式是否漂亮，而要找出"如果选择不同，最终行为就会不同"的问题。

针对小红书内容和评论分析助手，可以重点确认：

• 如果支持时间筛选，时间字段来自哪里？源数据没有可靠的评论发布时间时，是否隐藏该筛选或提示无法按时间筛选？
• 怎样识别同一条评论？如果导入数据没有稳定的评论 ID，去重能力有哪些限制？
• 发起分析时，是否固定本次笔记内容和评论快照？分析提交后新导入的评论是否只显示、不加入当前分析？
• 空数据、模型超时、模型返回不符合结构的数据、输入过长时分别怎么办？
• 模型回答要展示哪些引用信息？怎样判断引用没有超出本次输入范围？

可以请 AI 为每个待确认项提供具体例子和不同选择的影响。然后由开发者决定规则，并将决定写回 Spec。

可复制提示词：审查与更新 Spec

本轮只审查和更新 spec/behavior_spec.md，不写测试代码，也不实现业务功能。

请从以下几个方面检查当前规格：场景与范围、关键行为、异常处理、输入输出和验收条件。逐条标记哪些内容来自我的明确要求，哪些是你的建议，哪些仍待确认。

重点检查：时间口径、评论身份与去重、分析输入何时固定、空范围、模型失败与重试、输入过长、回答引用和页面状态是否有歧义。

对每个会影响实现结果的待确认问题，请给出一个正常例子、一个异常例子，并说明不同决策会带来什么影响。不要自行替我决定业务规则。

根据我确认的内容更新 Spec。已确认内容、建议和待确认项要明显区分。完成后列出仍未解决的问题，暂不编码。

对于小改动，不必做一轮冗长的规格评审。例如修改一个已有明确规则的字段校验，可能只需在任务说明中写清输入、期望结果和不在本次范围内的内容。Spec 的深度应与任务风险和复杂度相匹配。

第四步：从 Spec 推导 Test Cases

Spec 确认后，不要立刻让 AI 一次性实现所有功能。先把其中重要、容易出错、影响业务结果的规则转换成测试用例。

一个清楚的 Test Case 至少应包括：

字段	说明
关联规则	对应 Spec 中的哪条行为
前置条件	测试开始前系统处于什么状态
输入与操作	输入什么数据，执行什么动作
预期结果	应得到的返回、数据变化或界面状态
不应发生的事	不应重复保存、越权操作、错误覆盖或额外调用等
检查方式	通过断言、数据库检查、接口响应或实际操作来核实
状态	待确认、已确认、已实现、已验证等

例如，针对"同一笔记、同一条评论重复导入时不重复保存"：

• 前置条件：数据库中已经保存评论 C01。
• 输入与操作：再次导入 C01，同时导入新评论 C02。
• 预期结果：最终只有 C01、C02 两条记录；C01 不增加副本，C02 正常保存。
• 检查方式：检查记录数量、评论 ID、原文和来源信息。
• 不应发生的事：不能因为 C01 再次出现而覆盖原文或产生重复记录。

再例如，两条评论文本相同但评论 ID 不同，应依据已确认的规则分别保留，不能只根据文本相同就合并。测试是否去重、按什么字段去重，必须来源于规格，不能让 AI 在实现时自行决定。

可复制提示词：从 Spec 生成测试用例清单

读取 spec/behavior_spec.md 中已经确认的规则，本轮只整理测试用例，不写测试代码和业务代码。

请把关键行为拆成可独立验证的 Test Cases。每条用例包括：关联规则、前置条件、输入与操作、预期结果、状态变化、不应发生的事情、检查方法和状态。

至少检查正常场景、边界值、空数据、失败重试、重复操作、非法输入以及与当前功能相关的权限或状态限制。避免只重复编写相似的成功场景。

预期结果必须来自已确认的 Spec。对规格尚未明确、无法合理推导的场景标记为"待确认"，不要擅自编造规则。将清单保存到 spec/test_cases.md，并说明当前最重要的测试缺口。

测试用例清单也需要审查。尤其要检查预期是否正确、断言是否足够具体、是否真的覆盖了关键行为。只检查接口状态码为 200，并不能证明数据没有重复、返回内容没有错，或权限控制没有漏洞。

第五步：按照 TDD 小步实现

当规则和当前用例的预期已经确认，再开始针对一个行为进行 TDD。不要把"先让 AI 写完全部功能，最后生成一些测试"当成 TDD。

推荐的节奏是：

1. 选一个足够小的行为。 例如先实现评论数据重复导入时不重复保存，而不是一口气实现完整的数据导入、内容分析、评论分析和前端交互。

2. 先编写测试并实际运行。 测试应当能够检查目标行为，并因为该行为尚未实现而失败。若测试因为依赖未安装、模块导入失败或运行环境错误而失败，这还不是有效的业务红灯，应先处理环境问题。

3. 编写最小实现。 让 AI 只实现满足当前测试和已确认规格所需的代码，不要趁机引入与本次需求无关的大型重构。

4. 重新运行测试。 确认测试真正通过，而不只是 Agent 在对话里说"应该没问题"。要求它报告实际执行的命令、结果以及未运行的检查。

5. 重构并复测。 在外部行为保持不变的前提下整理代码，再运行当前和相关的既有测试。

可复制提示词：按 TDD 实现一个行为

读取 spec/behavior_spec.md 和 spec/test_cases.md，只处理其中一项已确认的行为：同一笔记、同一条评论重复导入时不重复保存。

请严格按 TDD 推进：
1. 检查现有代码和测试环境；
2. 编写能明确验证该行为的测试并实际运行；
3. 确认失败确实对应目标行为，而非环境或导入问题；
4. 编写满足测试的最小实现；
5. 再次运行测试并报告实际结果；
6. 在行为不变的前提下重构，再运行相关测试。

不要通过删除断言、跳过测试或随意更改预期来追求通过。若测试预期与 Spec 冲突，先说明冲突和依据，暂停并请求确认。

完成这一项后停止，汇报关联规则、测试命令、失败与通过结果、修改文件、尚未验证的内容。不要顺手实现其他功能。

如果某项测试第一次运行就通过，不需要故意修改代码来制造红灯。先确认现有实现是否已经满足行为、测试是否真正覆盖目标；如果确实已经实现且测试有效，可以保留测试并继续下一项。TDD 的重点是测试驱动开发决策，而不是机械地追求每次都显示一次红色输出。

第六步：做功能验收，确认测试通过不等于整个功能完成

单元测试和集成测试只能覆盖它们实际检查的内容。涉及页面状态、数据导入、网络请求、真实模型调用等环节时，还要按用户的真实使用流程检查。

对于小红书评论助手，可以从头走一遍：

1. 导入笔记和评论数据，确认标题、正文、话题标签及评论列表展示正确。
2. 再次导入同一批数据，确认不会产生重复记录；如果导入失败，界面应显示明确原因。
3. 使用当前数据实际支持的筛选条件，核对页面展示的数量与实际选中的评论。
4. 发起分析，确认传给模型的输入就是本次选定的评论集合。
5. 检查回答引用的评论是否属于本次输入，引用内容是否真正支持回答；检查内容总结是否忠实于笔记正文。
6. 模拟没有评论、模型失败和输入过长，确认系统按规格处理：没有评论时仍可分析笔记正文，但不生成评论洞察。
7. 在当前分析提交后再导入一批新评论，确认新评论不会意外混入已经提交的分析快照。

这一步不仅检查程序逻辑，也检查不同模块连接起来后的实际效果。一个接口的单元测试通过，不代表完整用户流程一定正常。

可复制提示词：最终验收与汇报

请对照 spec/behavior_spec.md 和 spec/test_cases.md 检查当前实现。本轮以验证和差距分析为主，不要擅自扩大功能范围。

请分别核对：
1. 已确认的 Spec 是否都有对应实现；
2. 关键 Test Cases 是否已实现并实际运行；
3. 前端、后端、存储与外部模型之间的真实流程是否可用；
4. 哪些验证使用固定测试数据或模型替身，哪些调用了真实模型或真实页面；
5. 仍有哪些功能、异常场景或真实使用效果未验证。

请列出每项的规则、检查方法、实际结果和证据。明确区分"已运行且通过""已运行但失败""未运行""无法验证"。不要把未运行的测试说成通过，不要仅为了让清单全绿而删除断言或降低验收标准。发现差距时先提出最小修复建议，再按我确认的范围处理。

五、AI 应用的特殊情况：程序逻辑与模型效果要分开验证

普通程序往往可以针对固定输入得到相对确定的结果；生成式模型则可能在措辞、归纳方式和细节上有所变化。因此，使用 TDD 开发 AI 应用时，不宜将所有验证都设计成"输出字符串必须完全相同"。应先区分要验证的内容。

验证对象	示例	合适的验证方式
程序逻辑	评论筛选是否正确、评论是否去重、没有评论时是否按规格跳过评论洞察	固定输入、自动化断言，不需要调用真实模型
输出结构	模型返回内容是否包含规定字段、引用 ID 是否有效	Schema/字段校验、集合成员检查、异常结果测试
输入边界	模型收到的评论是否全部属于所选范围	检查实际请求参数或分析快照
模型语义效果	是否准确归纳讨论主题、是否遗漏重要观点、是否添加原文没有支持的结论	准备有代表性的样本，按明确的评价标准审查真实模型输出；必要时重复运行并比较稳定性
真实用户流程	页面范围切换后，回答和引用是否同步更新	端到端操作、接口与页面联动检查

例如，模型回答"评论主要关注产品使用体验和购买顾虑"，可能是合理概括；但如果它进一步说"所有用户都认为产品不值得购买"，而输入评论并不支持这个结论，就属于过度推断。对此，程序可以验证引用的评论 ID 是否越界，却不能仅靠 ID 验证语义结论是否准确。语义效果需要独立的样本和评价标准。

模型替身（Mock）很适合验证程序如何处理超时、结构错误、引用了本次范围以外的评论等可控情况；它不能证明真实模型的归纳质量。反过来，真实模型偶尔给出一个好答案，也不能证明评论筛选、数据去重和异常处理都正确。两类验证解决的是不同问题，应在报告中明确区分。

六、日常使用中的几个常见误区

误区一：Spec 写得越长越好

不是。Spec 的目标是消除重要歧义，不是预测所有实现细节。一个明确的小改动可能只需几条规则；涉及多个状态、数据来源和失败处理的功能才需要更细的规格。过度设计的 Spec 反而可能增加阅读和维护成本。

误区二：把 AI 的建议直接当成已确认需求

Agent 可能提出看似专业的规则，例如"只分析带问号的评论"。如果用户没有要求、业务场景也没有明确依据，就应当标为建议或待确认。应该先讨论，再决定是否写入正式 Spec。

误区三：测试都是绿的，就说明功能正确

测试绿色只代表实际执行的断言通过。应检查测试是否真的覆盖关键规则、断言是否够具体、测试有没有被跳过，以及真实用户流程是否已经运行过。测试数量多不等于测试质量高。

误区四：让 AI 为了通过测试修改测试

当测试失败时，应先比较 Spec、预期与实际结果。如果实现错误，就修改实现；如果规格有歧义，就回到需求讨论；如果测试预期本身写错，则依据已确认规则修正并记录理由。不能为了让结果变绿而删除重要断言或放宽业务标准。

误区五：所有页面和改动都机械套用完整 TDD

TDD 尤其适合计算规则、状态流转、数据转换、权限、边界处理和容易回归的逻辑。对于纯视觉微调、探索性原型或很难自动断言的交互，可以根据风险采用轻量测试和人工验收。但只要功能会影响重要业务结果，就应考虑用自动化测试固定关键行为。

误区六：AI 说"已验证"就当作验证完成

要求 Agent 报告实际运行的命令、测试范围、结果和未覆盖内容。没有执行过的测试应标为未运行；用了 Mock 的测试不能说成真实模型效果已验证；只用固定样本测试，也不能说成真实数据导入场景已经验证。

七、如何根据任务大小灵活使用？

可以把 Spec DD 和 TDD 做成三个力度，而不是所有任务都走同一套重流程。

任务类型	Spec DD 做到什么程度	TDD / 测试做到什么程度
小修复、明确的字段校验	写清问题、预期行为和不在范围内的部分	补充或调整针对性测试，运行相关既有测试
普通业务功能	写清场景、范围、输入输出、关键规则、异常和验收标准	列出正常、边界和失败用例；按单个行为进行 Red-Green-Refactor
复杂或高风险功能	充分澄清关键假设，明确状态、权限、数据口径和非目标；必要时分阶段确认	优先验证高风险规则，分层执行程序测试、集成测试和真实流程验收

如果规格不清楚，先不要让 AI 大量编码；如果规格清楚但测试没有覆盖关键规则，也不应因为代码已经生成就直接交付。两者是互相补充的约束，而不是必须一次性完成的两份文档。

八、一个建议的项目文件组织方式

不必为了实践 Spec DD 和 TDD 引入复杂工具。对大多数日常项目，可以从少量 Markdown 文件开始：

project/
├── README.md
├── spec/
│   ├── behavior_spec.md   # 业务场景、关键行为、边界、验收条件
│   └── test_cases.md      # 与规则对应的测试用例及验证状态
└── src/                   # 业务代码

如果项目已经有 AGENTS.md、CLAUDE.md、CODEX.md 或其他 Agent 指引，可以在其中说明：开始任务前读取哪些文件；需求有歧义时先提问；测试失败时按什么规则处理；哪些检查必须实际运行。不要把每个功能的业务规则都堆进全局指引文件------通用协作要求和当前功能规格应分开维护。

项目文件的职责可以简单理解为：

• Agent 指引：告诉 AI 如何在这个仓库中工作。
• Spec：记录这个功能应该表现成什么样。
• Test Cases / 测试代码：记录如何检查这些行为。
• 代码：实现已确认的规则。
• 验收记录：说明哪些检查真实执行过，哪些仍有风险。

这是一种轻量做法，不是固定目录规范。可以按团队与项目实际调整，但最好让关键规则有明确、稳定、可被 Agent 重复读取的位置。

九、结语：先明确目标，再让测试给实现反馈

在 Vibe Coding 中，AI 可以很快生成大量代码，但代码生成速度并不能替代需求判断和结果验证。

Spec DD 帮助我们把模糊的想法变成可讨论、可确认的行为约定；Test Cases 把其中的重要规则变成具体的检查场景；TDD 再利用失败与通过的反馈，小步推进实现。最后还要根据真实使用流程检查模块集成、外部依赖和模型效果。

记住这几句话即可开始实践：

1. 先问清楚要做什么，不急着让 AI 写代码。
2. 重要规则要写出具体例子和验收方式，不能只写"正确处理"。
3. 测试预期来自已确认的 Spec，而不是当前代码碰巧做出来的结果。
4. 一次只实现一个可验证的小行为，按红灯、绿灯、重构推进。
5. 测试通过不等于所有风险消失；真实运行过什么，就如实报告什么。

Spec DD 让开发目标更清楚，TDD 让实现过程有反馈。两者结合，就能把 Vibe Coding 从"让 AI 尽快生成代码"，推进到"让 AI 按照清晰约定持续交付可验证的结果"。

参考资料

1. GitHub, Spec Kit Quickstart --- Spec-Driven Development : github.com/github/spec...
2. Martin Fowler, Test-Driven Development : martinfowler.com/bliki/TestD...
3. AWS Prescriptive Guidance, Adopt a test-driven development approach : docs.aws.amazon.com/prescriptiv...