01

前天，和一个技术大拿开发者聊天，他 1~2 个月，一个单子能接到 30w，一年能接好几个……羡慕啊。

中途，和他聊到，6 月重构了一些 AI 写的代码，改得有点心累，然后，他就提到了这个。

看到他说这些，我似乎就知道了，之前所担忧的事——「全用 AI 写代码，会不会让项目越来越失控？」似乎有了解法。之前，我为此的确挺焦虑的，所以这也是我决定暂停卖、先调整的原因，我认为它目前还不够健壮。

毕竟无论是自用，还是把代码卖出去给别人用，都需要在咱们自己的掌控之中。这样，才是长久之计。

尽管目前没有出现明显问题，但有规矩一定比没有要强百倍。然后，我就记住了这个词，昨天开始学习了，那咱们就一起来看看吧。

02

SDD 规范开发是什么？

SDD 是 Spec-Driven Development，也就是规格驱动开发。

它的核心思路是，先把「要做什么」「为什么做」「怎么验收」「有哪些风险」写清楚，再进入代码实现。传统开发经常是先写代码，写着写着再补需求，AI coding 更容易这样一路跑偏。

SDD 反过来要求先有规格、计划和任务，再让 AI 或开发者按任务执行。

对 Pay4SaaS 这类和收钱、消费相关的系统来说，SDD 特别有价值。因为项目里有 payment、checkout、webhook、credits、quota、subscription、Supabase、RLS、RPC、service-role 等高风险逻辑，一旦只凭感觉改代码，很容易破坏权益发放、幂等性、app 隔离或数据库安全边界。

SDD 的作用，就是把这些风险在写代码前显式暴露出来。

第一个作用是减少需求误解。

功能开始前先写 spec，可以让用户故事、验收标准、边界情况和文档影响变得具体。

第二个作用是控制实现范围，避免 AI 顺手重构、乱改无关文件或引入不必要的架构。

第三个作用是留下决策记录，后面回头看时能知道当时为什么这样设计、哪些风险被接受、哪些验证已经做过。

03

GitHub Spec Kit 是什么？

GitHub Spec Kit 可以理解为一套帮助你落地 SDD 的工具和模板。它通常会在项目里维护 .specify/ 目录，里面包含项目宪法、spec 模板、plan 模板、tasks 模板和 checklist 模板。它不是替你写业务代码的框架，而是帮助你把「开发前应该想清楚的事」结构化。

类比一下，如果写代码像施工，Spec Kit 就像施工前的图纸、审批单、任务清单和验收表。

代码是砖、水泥和电线，Spec Kit 不直接替代这些东西，但它告诉你要建什么、哪里不能乱动、谁先谁后、完工后怎么检查。没有 Spec Kit 也能写代码，但复杂项目很容易越写越散，尤其是交给 AI 连续迭代时。

Spec Kit 通常包含几类文件和流程：

constitution.md 是项目宪法，记录项目不能违反的长期原则。spec-template.md 用来生成 feature specification，说明需求、用户场景、成功标准和边界。plan-template.md 用来生成 implementation plan，说明技术方案、仓库证据、宪法检查和验证映射。tasks-template.md 用来生成可执行任务。checklist-template.md 用来生成专项检查清单。

在 Pay4SaaS 里，我已经把这些模板改成项目专用版本。它们会检查支付与权益稳定、服务端可信边界、webhook 幂等、Supabase app 隔离、migration 策略、文档同步、依赖 lockfile、低风险轻量路径等内容。

04

在项目里如何安装 Spec Kit？

如果项目还没有 Spec Kit，可以用 AI 帮你安装或初始化 GitHub Spec Kit，一句话：

帮我安装或初始化 GitHub Spec Kit。

安装后，会有 skills 和 .specify/ 目录：

05

实际开发中应该如何做呢？

第一步是制定或维护宪法。通过 $speckit-constitution 唤起。

宪法不是每个功能都要改，但项目开始规范化前必须先有。它定义什么事情不能乱来，例如支付正确性优先、服务端可信边界、webhook 必须验签和幂等、Supabase 必须按规则隔离、简单架构优先等。这个写完，必须自己认真审核一遍。

第二步是写 spec。提出新功能后，先用 speckit-specify 把需求整理成规格。这里要说清楚用户是谁、要完成什么、验收标准是什么、哪些边界不能破坏。低风险改动也要标清楚为什么低风险，高风险改动要列出触发项。

第三步是澄清需求。如果 spec 里有不确定项，用 speckit-clarify 追问关键问题。不要在 payment、billing、database、auth 这些地方靠猜测推进。

第四步是写 plan。用 speckit-plan 生成实现计划，记录仓库证据、技术方案、宪法检查、migration 策略、依赖 lockfile 影响、文档影响和验证映射。高风险变更必须把风险和验证方式写清楚。

第五步是拆 tasks。用 speckit-tasks 把计划拆成可执行任务。任务应该能让开发者或 AI 一步一步完成，不要只写「实现支付功能」这种大而空的句子。

第六步是实现前审计。用 speckit-analyze 检查 spec、plan、tasks 有没有冲突、重复、遗漏、模糊或违反宪法的地方。必要时再用 speckit-checklist 生成专项 checklist。

第七步才进入实现。用 speckit-implement 按 tasks 执行。实现过程中如果发现任务不完整，可以用 speckit-converge 对照代码和文档补任务。实现后按 plan 和 tasks 里的验证映射运行测试、sandbox、SQL Editor 或手动验收。

06

SDD 和 Spec Kit 会多花一点前期维护时间，但它能让 AI coding 不至于越写越失控，需求、风险、任务、验证都先摆在台面上，后续迭代就不用反复猜、反复补锅了。

对长期项目来说，无论是自己开发还是在公司、团队与人合作，这其实是在省时间，也是在省心力，改起来心里也会有谱的。

所以，接下来我会继续用这套流程，把 Pay4SaaS 一点点改成一个自己真正能掌控，也敢长期交付给用户的产品。