夜雨聆风系列二之后，就会有一个疑问：
“道理我懂了，那我该用哪个工具？”
有人刚准备搭一个新项目，有人面对的是跑了几年的老系统；有人希望每一步都检查清楚，有人只想让 AI 别改错现有功能。
项目不同，合适的工具自然不同。
所以这篇不比谁的功能多，只回答三个问题：
它怎么用？ 适合什么项目？ 又要付出什么代价？
虽然各家工具的命令、文件和界面不一样，但做的事情都差不多：
先把需求写清楚，再想好怎么改，最后让 AI 动手。
真正的区别，是这套流程要走多细。
一种做法比较完整。项目规则、功能需求、技术方案和任务清单都要写下来，中间还会安排检查。
好处是稳，适合从零开始、需要长期维护的项目；代价是慢，小需求也容易生成一堆文件。
另一种做法更轻。它不要求先把整个项目讲清楚，只围绕眼前这次修改来写：为什么改、改哪些地方、做完怎么确认。
好处是容易接进老项目，代价是很多事情仍要靠人把关。
如果不想自己维护这些命令和文件，也可以直接使用 Kiro、Trae SOLO 这类已经把流程做进产品里的工具。
用起来省心，但会更依赖厂商规定的工作方式。
小结：先判断项目需要多重的流程，再选择具体工具。
如果项目刚起步，而且打算维护很长时间，我会先看 GitHub 的 Spec Kit。
它最有价值的地方，不是命令多，而是能先把项目规矩定下来。
比如：数据库访问必须统一封装；新增第三方依赖前必须先确认；关键功能必须有测试。
以后 AI 每次做需求，都要参考这些规则，而不是想到哪改到哪。
接下来才是具体功能。你先告诉 AI 要做什么，它帮你补充需求、整理实现方案、拆出任务，然后检查前后有没有矛盾。
确认没问题，再开始写代码。
整个过程并不神秘，可以理解成把团队平时开需求会、做技术评审、拆开发任务的步骤搬进 AI 对话里。
区别是这些内容会写进项目文件，下一次还可以继续参考。
Spec Kit 也不绑定某一个 AI 编程工具，可以配合 Claude Code、Copilot、Cursor、Gemini 等工具使用。
将来更换模型或编辑器，已经写下来的规则和需求仍能保留。
它的缺点同样明显：流程偏重，生成的文档也多。
做一个影响多个模块的大功能，这些检查很有价值；只改一个按钮文案还走完整流程，就纯属给自己加班。
小结：新项目、多人协作、维护周期长，优先考虑 Spec Kit。
如果代码已经跑了几年，每次需求都是在现有功能上修改，我更倾向于 OpenSpec。
老项目最大的问题，是你很难在开始之前把整个系统重新说明一遍。
文档可能过期，代码里还有很多历史包袱。强行补齐一套完整规格，成本很高，也未必准确。
OpenSpec 的做法更直接：只围绕这一次变更，把为什么要改、准备改什么、需要完成哪些任务写清楚。
确认后让 AI 实施，完成后再把这次记录归档。
它不要求你重写整个项目的说明书，更像每次改动前先开一张施工单。
AI 知道这次要动哪里、哪些地方不能动，人在执行前也能先检查方向。
这也是我觉得它比 Spec Kit 轻量的地方。它不需要额外接入 API 或 MCP，原有项目不用大改，就可以从一个需求开始尝试。
对于持续迭代的存量项目，这种方式更容易落地。
但轻量不等于自动正确。
如果写下来的需求和真实代码对不上，还是要由人发现；开发过程中改变了方案，也要及时更新记录。
工具只能帮你把事情写下来，不能替你理解整个老系统。
小结：OpenSpec 适合在老项目里逐步引入规格驱动。
有些人不想维护命令、模板和目录，只想打开一个工具，按照界面提示把需求交给 AI。
这时可以看 Kiro 或 Trae SOLO。
先说明一点：它们不是开源工具，只是提供了另一种选择。
Kiro 会引导你依次整理需求、设计方案和任务，再开始实现。你也可以写下项目长期遵守的规则。
它的优点是步骤完整，不用自己拼装；缺点是商业闭源，而且小改动也可能产生好几份文件。
Trae SOLO 更像一个主动干活的 AI 助手。
你可以先给它需求和设计材料，让它列出计划，确认之后再执行。它也能从零搭项目或修改现有代码，但并不强制每次都先写完整规格。
所以，Trae SOLO 严格来说不能算完整的 SDD 工具。
它只是吸收了“先计划、再执行”的做法，核心仍然是让 AI 更主动地完成任务。
这一类工具的好处是省心，代价是选择少。流程怎么走、文件怎么组织，主要由厂商决定。
团队代码如果要交给这类产品，还需要先确认数据和隐私政策是否能接受。
小结：厂商工具更省心，但也意味着更少的流程选择。
无论选哪个工具，如果只写一句“帮我做个登录功能”，AI 还是会自己猜。
登录方式有哪些？失败几次要不要锁定？旧账号怎么办？哪些页面必须登录才能访问？
这些问题不写清楚，换十个工具也没用。
与其反复比较功能，不如先练习把需求说清楚。工具可以换，清楚的需求到哪里都能用。
使用 SDD，单看一次任务，确实会多花一些时间。
你要写需求、看计划，还会生成一些过程文件。
但不走这些步骤也不等于没有成本。AI 如果一开始就理解错了，代码写得越快，返工越多。
项目越大、改错的代价越高，越值得先把方向确认清楚。
一次性脚本或很小的修改，则没必要把流程走满。
大功能可以把需求、方案和任务都写清楚，小改动写几句话说明目标和边界就够了。
如果改一个提示文字也要生成好几份文件，流程很快就会变成负担。
工具是用来降低出错概率的，不是用来证明团队做事正规。
这个问题不只出现在 OpenSpec，Spec Kit、Kiro 等工具多少都有。
每做一个需求，项目里就会多出需求说明、实施计划和任务清单。时间一长，文件越来越多。
我重度使用 OpenSpec 时，对这一点感受很明显。
它比 Spec Kit 轻量很多，但一个变更归档后，那组过程文件对后续需求通常没有多少复用价值。用久了，仓库很容易变成历史档案馆。
留下文档，不等于留下了有用的知识。
真正值得长期保留的，是以后仍然要遵守的项目规则、重要的设计决定，以及当前还有效的功能说明。
只服务于某一次需求的计划和任务清单，可以归档，也可以按照团队约定定期清理。
小结：流程要按需求大小调整，过程文件也要定期整理。
回到开头的问题：
“我该用哪个 SDD 工具？”
如果是从零开始、需要长期维护的新项目，先看 Spec Kit；如果是在老项目上持续迭代，OpenSpec 更容易接入；如果不想自己搭流程，并且能接受厂商绑定，再看 Kiro 或 Trae SOLO。
但不管选谁，里面都是同一件事：
先把要做什么讲清楚，再想好怎么做，最后才让 AI 动手。
工具在变，做事的顺序没有变。
先问项目是什么，再问工具选哪个。需求说不清楚，再强的工具也救不了。
工具选定只是开始。
后续持续更新 AI 编程实战技巧。
往期文章请查看：AI 编程系列
关注本号，不错过 AI 编程干货，转发收藏，开发遇到问题随时翻阅。
