发生了什么

掘金社区的一篇帖子因指出一个真实问题而备受关注：Vibe Coding，即在没有书面规范的情况下迭代式地向 AI 发出提示。作者提出了规范驱动开发（SDD）作为结构化替代方案。SDD 要求在编写任何代码之前先创建三个工件：解释“为什么”的 proposal.md、包含版本化验收标准的 specs/ 目录，以及锁定范围的 tasks.md 清单。文中引用的一支内部团队数据显示，在 Vibe Coding 模式下，每个功能变更平均产生 2.3 个意外副作用。而在 SDD 模式下，AI 仅被限制执行 tasks.md 中列出的内容——规范之外的任何内容均不被触碰。

为何重要

使用 AI 编码助手的独立开发者和小型团队正面临因范围未受控变更而累积的技术债务。典型的失败模式是：要求 AI“优化登录”会导致整个认证模块被重写，包括无人要求修改的密码恢复流程。SDD 通过四步工作流解决此问题：起草提案 → 审查并达成一致 → AI 依据锁定规范执行 → 归档更新后的主规范。关键约束在于 AI 不得修改 tasks.md 中未明确列出的任何内容。这使得回归行为可预测，并为团队提供了存储在版本控制系统中的单一事实来源。

  • 规范以 Markdown 文件形式存在于 specs/ 中，包含可勾选的验收标准
  • 每次变更拥有独立文件夹：changes/feature-name/，内含提案、任务及规范差异
  • AI 角色从创意协作者转变为合同执行者
  • 回滚变为规范还原，而非代码考古

亚太视角

为中国及东南亚开发者而言，他们常以小型团队构建面向全球市场的 SaaS 产品，其中一名开发者往往同时负责产品决策与实现。SDD 在此尤为有用，因为规范文件可兼作面向国际用户和潜在投资者的产品文档——用英文编写，无需现场演示即可传达功能行为。使用 Cursor 或 Claude 进行代码生成的团队可将整个 specs/ 目录作为上下文粘贴，相比对话式提示，这显著提升了输出质量。此外，当向越南、印度尼西亚或菲律宾的自由职业者外包时，规范文件即合同，有效减少了因语言和时区差异导致的沟通误解。

本周行动项

挑选一个你当前正借助 AI 构建的功能。在下一次提示会话前，创建 changes/your-feature/ 文件夹，包含三个文件：proposal.md（两句话说明为何需要此变更）、specs/feature.spec.md（包含三至五个以复选框形式书写的验收标准），以及 tasks.md（列出 AI 被允许修改的每个文件）。在 AI 会话开始时粘贴这三个文件作为上下文，并指示模型仅触碰 tasks.md 中列出的文件。