什么是spec-driven coding
我们正常的开发流程中，撰写产品需求文档（PRD）来指导开发，创建设计文档来告知实现细节，然后进行代码开发。
规范驱动开发（SDD）模拟了这一流程，但在SDD中，产品需求文档（PRD）不再是实现的指南，而是生成实现的源头。技术方案不再是指导编码的文档，而是生成代码的精确定义。因为现在AI能够理解和实现复杂的规范，并创建详细的实现方案。但没有结构的过程会让AI生成会产生混乱。SDD通过精确、完整且足够明确的规范，足以生成可运行的系统。
开发团队的意图通过自然语言可以生成相应的规范，代码只是最后一公里的实现方式。
spec-kit原理简介
spec-kit仓库地址：github.com/github/spec… (安装可以参考这个地址)
从上面的地址可以看到，spec-kit通过一系列自定义slash command来生成对应的规范文件，最终根据这些规范文件生成代码
| 顺序 | Slash command | 作用 |
|---|---|---|
| 1 | /speckit.constitution(如有则不需要执行) | 生成项目规范 |
| 2 | /speckit.specify | 生成需求文档 |
| 3 | /speckit.clarify (可选) | 让AI识别可能需要澄清的最重要的5个问题 |
| 4 | /speckit.plan | 生成设计文档 |
| 5 | /speckit.task | 生成实施任务文档 |
| 6 | /speckit.implement | 实施代码 |
这些自定义的 slash command 其实是利用了vscode copilot的自定义prompt文件，参考：code.visualstudio.com/docs/copilo…
执行 slash command命令实际上是将 .github/prompts/${命令}.prompt.md 的提示词及相关设置发给AI。比如
执行/speckit.constitution命令，实际上是让AI遵循 .github/prompts/speckit.constitution.prompt.md。
因此，实际上执行的每一个命令就是依据作者的思想，通过作者预置的提示词与AI交流，按照流程生成对应的规范文件，最终利用这些规范文件来指导AI写出符合要求的代码。通过这样一步步的规范，提高AI写出“好的”代码的概率。如果你有自己的一套开发规范，那么你也可以有自己的spec-driven development流程，写一个自己的spec-kit！
用spec-kit实践一个后台管理需求
要做的是什么？
实际查看：c-ai-admin.xiaopeng.com/#/ai/entry
这是一个常见的后台管理新增tab需求，包含列表查看、搜索，编辑、新增、复制、删除的功能。弹窗中，选择场景热门问题由全部配置中而来。
怎么做？
接下来，我们就按照spec-kit的流程来实现这个需求。
/speckit.constitution 生成项目规范
项目是第一次用spec-kit来进行spec-driven coding，因此需要先生成项目规范文件 .specify/memory/constitution.md，这个文件在后续的流程中都会用到，是非常重要的。
生成这个文件的时候，会参考工作区内的README.md, docs/quickstart.md，prompt输入，之前的constitution.md，仓库上下文等等……。因此，我们在这之前补充一些我们期望的项目规范信息是非常必要的，当然，你可以让AI帮你生成，你需要review一下生成的内容，并且补充一些必要的规范。
在这里我生成好了一份README.md【字数限制不放上来了】
同时，我希望在项目规范里面增加一些vue2的 best practice。
生成的的规范我们需要review一下是否满足要求，如果还有别的要求，可以继续通过命令+要求去更新。
最终的.specify/memory/constitution.md【字数限制不放上来了】
Tips: 如果下次开发已经存在了.specify/memory/constitution.md，那么就不需要再次重新生成。但我们在上次开发时发现的一些AI容易误解或者遗漏的地方，我们可以重新更新到.specify/memory/constitution.md，来更好地指导AI。
/speckit.specify 生成需求文档
这个阶段prompt一定要详细描述清楚你要做什么，这要求我们先要缕清产品的需求。要求产品把需求文档写清楚可以减少我们很多工作量，然后我们稍作整理就可以。
在这个阶段，重点在what和why，而不是how，不要涉及到技术相关的描述
我们先整理prompt，将prompt整理到一个feature.md文件中【字数限制不放上来了】。
开始生成需求文档
生成的的规范我们需要review一下是否满足要求，如果还有别的要求，可以继续通过命令+要求去更新。
最终的需求文档：specs\002-scenario-config\spec.md【字数限制不放上来了】。
/speckit.clarify (可选) 澄清不清楚的问题
我们可以看到，上面生成的 specs\002-scenario-config\spec.md 里面有个 Edge Cases 板块，里面列举了一些边界情况，大部分是一些影响细节交互的问题，如果你希望做出来的系统更加人性化，可以使用 /speckit.clarify 帮你列出AI认为的最需要澄清的5个问题，并给出建议，同时会帮你写回到spec.md中。
执行命令后
交互式澄清5个问题并更新到spec.md中，按照你想要的答案选择选项或者输入新的解决办法。
/speckit.plan 生成概要设计
这一步在我们要着重在如何实现它，重点在how，因此需要将足够的实现信息给AI，如后端接口文档，这样AI可以帮我们做准确合适的概要设计。
我这个需求里，我从后端提供的接口信息（最好让后端的概要设计做详细，包含接口的各种信息），整理了一份后端接口文档：可以看到，后端没有提供响应数据格式，因此后续字段对接这块可能会存在一些问题。
执行 /speckit.plan
生成了以下文件：
在这里，我们主要review plan.md，里面可能有一些需要确认的事项，根据需要进行删减更改。前面有提到我们提供的后端接口信息文档没有提供响应数据格式，但在contracts/api-endpoints.md文件中可以看到，AI自动根据我们提供的接口请求参数信息补充了接口返回信息！还是挺聪明的。
最终的plan.md【字数限制不放上来了】
/speckit.task 生成任务
生成分阶段的、独立的任务，汇总到 tasks.md
可以看到，这一步将我们要实现的需求分为了7个阶段，并按增量的形式划分为了4个执行期，非常清晰。
终版task.md【字数限制不放上来了】
结果怎么样？
我总结了一下：
- 代码生成效果不错，90%以上的代码可用
- 逻辑部分几乎完全没问题，阻碍流程的地方几乎都是上下文错误或者上下文不够完全，AI偶尔有幻觉，见上表问题7
- 一些UI问题，UI交互优化通过AI能非常快速地修复
有什么心得？
-
后台管理重简单逻辑、轻UI，这种类型的开发任务非常适合spec-driven development流程来开发
-
提供的需求上下文，接口上下文信息越准确，越完善，生成的代码质量越高
-
AI偶尔会出现幻觉，但从上面的例子来看，是可接受的范围内
-
我们可以采用sDd开发+手动测试的方式，发现的问题可以通过人工+AI排查的方式来修复，其中轻UI的修复可以全部交给AI来做，逻辑部分AI+人工的方式更加高效
-
修复问题阶段最优模式是：
- 新建一个chat(而不是在原来的sdd开发chat上，上下文过长，影响生成效率)
- 采用edit方式(agent方式适合高难度的任务，会搜集各种信息，时间长)，效率更高，且可以直接编辑文件。edit模式下给出的上下文越准确，AI修复问题越准确。
-
当对某次修改不满意时，利用chat的restore Checkpoint功能会非常方便，点击restore Checkpoint，AI会回撤这次的所有更改。这样你就可以在上次更改的基础上重新更改。
或者直接点击问题进入编辑模式，和上面的效果也是一样的
