目录
一、从一句话需求到具体的业务场景
现在AI的能力越来越强，在一些常见的小型项目中，一句话需求已经能够生成一个可以运行的初版。有的项目，如俄罗斯方块，贪吃蛇，鹈鹕骑车等项目可以在没有任何代码基础上，也不需要额外的约束和说明就可以完成。这是因为这些项目已经是通识性表达 （所谓的通识性表达，这种表达的背后相关的限定信息比较丰富，但同时又能够在很广泛的范围里达成共识）。
但是在实际项目中，比如做一个直播间评论助手，给谁用、在什么情况下用、需要哪些功能、做到什么程度才算符合预期。这些问题不理清楚，Agent 在生成代码时，会根据自己的理解补上这些内容。它补出来的内容可能合理，也可能偏离真实需求，所以关键的一步是：我们要有能力判断，它补出来的这部分理解，是否符合实际需要。
Coding Agent 可以参与其中很多工作，我们的目标是怎么用好它。一方面，我们需要把需求讲清楚（解决什么实际问题），另一方面，需要把开发结果检查清楚（效果是不是符合预期）。需求讲得越清楚，Agent 脑补的空间就越小；结果查得越严格，偏差点就越能及时被发现。
二、Spec和SpecDD
Spec 是 Specification 的简称 ，可以理解为对软件预期行为的具体说明。它需要讲清楚： 在什么场景下，接收什么输⼊，完成什么功能，产生什么结果，以及有哪些限制。
SpecDD （ Spec-Driven Development ，规格驱动开发，也常写作 SDD ）的基本思路是： 先把预期效果说清楚，再根据这些约定设计方案、编写代码和检查结果。他是一种思想。
我们以直播间评论助手这个项目来分析，首先我们将需求内容扩写一下：
这下就比单一的直播间评论助手，这个描述更加清晰。场景：抖音直播间（web地址），输入：直播时的观众评论，完成功能：AI助理，产生结果：监听评论，回答关于评论的问题。
经过上面的分析，我们可以开始实操：
Codebuddy打开一个空的文件夹，把上面的分析内容贴到聊天框中（选择plan模式）
在运行过程中，会有一些内容需要人去确认
我们需要根据实际需求来去做一个选择。之后会生成一个plan.md的文件。
重点关注核心功能部分，他是符合了我们输入的内容的要点（直播间接入，实时评论采集，AI混合问答）
创建Spec文件夹，将当前规划和后续spec文件都持续管理起来。这个文件夹是需要被保存和长期管理的。
Spec文件在不同的阶段关心的事情是不一样的：
除了在新功能的开发时需要Spec，在老功能升级及Bug修复上同样需要Spec来维护。而Spec不仅是给Coding Agent使用，指导，规范和约束后续的开发，也是给项目维护的人类使用，便于了解和规划项目的执行情况。
在上一步创建完Spec文件夹后，开始执行。这样就是利用规格说明书去确保开发是朝着我们期望的方向去走的（SpecDD）。
三、TDD
通过上一步的生成，如何确保最终开发出来的东西是符合我们约定的Spec所需要的呢？如果后续变更需求，如何保证不会影响之前已经约定好的未变更的功能？一般而言是通过测试。
测试用例（Test Cases）是用来说明：在什么条件下，输⼊什么或进行什么操作，预期得到什么结果，以及怎样检查这个结果。测试用例可以先用自然语言或表格表达，确认预期以后，再将适合自动检查的内容写成测试代码。测试由此参与开发过程，为每⼀步实现提供反馈。
TDD （ Test-Driven Development ，测试驱动开发）则是⼀种开发方法：先为一项行为写测试，观察它失败，再编写实现让测试通过，然后整理代码并保持测试通过。
TDD 用小循环推进实现（红转绿）：
-
红灯（ Red ）：写⼀条测试并运行，确认它因为目标行为尚未实现而失败。
-
绿灯（ Green ）：补充满足当前用例的最小实现，再运行测试确认通过。
-
代码整理（ Refactor ）：在行为不变的前提下改善代码组织，重新运行相关测试。
TDD是一种思想，一般有严格的TDD和宽松的TDD。严格的TDD：不允许在测试之前，先进行开发；宽松的TDD：通过测试约束实现结果，但是不一定严格遵循执行顺序。
Spec不仅可以指导开发，其实也是可以指导测试的。以本文直播间评论助手为例：
对于严格的TDD，测试在最开始就执行一次，由于什么开发都没做，所以我们验证的预期结果是全红，然后基于这个结果去做分析，如果缺少功能，就去开发新功能，然后再去走一遍测试；如果是实现的结果跟我们的预期不一致，那么就在做修改，修改完再去走测试；这样一轮一轮的执行，预期结果逐渐转绿。它的底层逻辑是我们通过定义好预期，不断的驱动现实去发生变更。一直到最后的现实的状态跟我们的预期达成一致。我们现在在做的是宽松的TDD，通过预期控制实现。
生成测试用例：
我们的测试用例要优先确保核心功能，再去确保主要流程稳定运行，再去考虑边界情况。
四、总结
通过上面的步骤：第一，我们构建了我们的spec的这样的一个管理池子。第二，我们会通过这样的一个测试用例的生成过程，去生成一个测试的一个测试池子。通过这两个方式，其实我们就在我们的项目两头去上了一层双保险。
如下，是我们的整个流程：
目前，开发的效率急剧提升，我们更需要外围的整体流程来保证项目的高质量交付。Spec做了事前确保，Test做了事后确保，给我们上了双重保险。
最终实现效果：
