AI 研发：我为什么推荐大家使用 SDD

如果你经常用 AI 写代码，可能遇到过这些情况：需求还没想清楚就开始实现，做到一半才发现边界遗漏；刚确认的方案，换一轮对话又得重新解释。

代码生成得很快，你却一直守在对话框旁边，补充条件、纠正方向。功能做完了，需求和取舍还散落在聊天记录里。

这也是我推荐 SDD 的原因：开发前澄清需求，实现时持续推进，完成后留下可复用的项目知识。

为什么你总要介入 AI 开发

先区分两种调整：产品有了新想法，开发需要跟着变化；还有一些调整，是原本应该明确的要求没有说清楚，写到一半才被发现。

后一种情况，很容易让人陷入反复接管。

比如一句“支持导出”，究竟导出当前页还是全部筛选结果？一句“优化这个模块”，能不能修改对外接口？这些问题如果没有答案，AI 就可能在实现时自行选择。

等你看到结果，再补一句“我说的不是这个意思”，已有代码就需要回头修改。

还有一种反复来自历史信息断档：上一次为了兼容旧接口保留了某段逻辑，下一次 AI 只看到代码，觉得可以简化，顺手就改了。

在这些场景里，继续增加几轮提醒只能解决眼前的问题。更值得做的是把要求、约束和决策整理成后续任务能够读取的依据。

当然，如果任务本身需要探索，途中提出新问题很正常。我们希望减少的是重复解释、遗漏要求后的补救，以及每走一步都需要人来维持方向。

SDD 是什么，规范要写到什么程度

SDD 是 Spec-Driven Development，通常译为规范驱动开发。在 AI 研发中，它强调先明确系统应该具备的行为，再围绕这些要求制定方案、实现和验证，并在需求变化时继续维护规范。GitHub 的 SDD 介绍

一份有用的规范，应该让人能回答：要实现什么，哪些情况需要处理，哪些行为必须保留，以及怎样判断结果符合要求。

例如，“用户可以切换分类，并在刷新后恢复所选分类”，就比“做好筛选体验”明确得多。它描述的是可观察的行为，后续可以直接对照检查。

发现新约束或原方案不成立时，需要更新要求和设计，再继续实现和验证。

规范可以由 AI 整理初稿，人负责检查它有没有误解目标、遗漏边界，或者把未经确认的猜测写成要求。

SDD 可以融入现有流程。除了代码风格，本次功能的行为、变化范围和验收条件也需要写清楚。

为什么我希望实现阶段少介入对话

在我的实际开发中，需求澄清并确认之后，实现阶段基本不需要我再介入对话。

我看重的是让 AI 拿到完整的任务依据之后，能够连续推进，而不是写一点、问一点，再等一句“继续”。

这需要在开始前把几个问题说透：本次做到哪里，哪些地方必须保持兼容，如何判断完成，遇到什么情况需要重新讨论。

比如，某项测试暴露了实现错误，AI 可以依据已经确定的预期行为继续排查和修正；如果发现原需求与现有业务规则冲突，就应该把这个冲突带回来，让人判断。

两种问题需要的处理方式不同。已经有判断依据的实现问题，可以继续推进；尚未确定的业务选择，需要补充决策。

持续执行也依赖编码 Agent 和运行环境具备读取项目、推进任务、运行测试等能力。SDD 为这些动作提供依据，规范文件本身不会自动执行代码。

我希望把精力用在需求判断、关键取舍和最终验收上。实现过程中能依据规范解决的问题，就交给 AI 连续处理。

具体怎么用：从一句需求开始

假设一个项目已有文章列表和分页，现在要增加分类筛选。这个例子只用来说明方法。

如果直接说“帮我加一个分类筛选”，AI 很快就能给出一个可点击的页面。但刷新后是否保留状态、切换分类后如何处理页码，仍然可能没有想清楚。

我建议先让它读取相关代码和已有规范，再找出需要澄清的问题：

先阅读相关实现、已有规范和测试。
说明当前行为与本次需求的影响范围。
列出模糊要求、冲突和边界条件，给出建议及理由。
将已确认的结论整理成行为要求和验收场景。
待这些内容确认后，再拆解任务并实现。

比如，确认后的要求可以包括：切换分类时回到第一页；分类和页码保存在 URL 中；刷新时恢复对应状态。

图中的要求还需要继续落实成场景。比如：用户在 Java 分类的第四页切换到 Spring 分类后，页面应展示 Spring 的第一页，URL 中的分类和页码也必须同步更新。

分类不存在、页码超出范围、没有匹配内容时怎么处理，也应该讨论清楚。不能因为正常路径能点通，就把这些情况全部留给实现阶段猜测。

接着再确定技术方案和任务。完成后，用准备好的数据实际检查切换、刷新和链接恢复，并执行适合自动化的测试。

这套方法也适用于其他研发任务：

• 修复 Bug：记录复现条件、预期行为和回归检查，避免修好一个入口，却遗漏另一个入口。
• 重构代码：先明确必须保持不变的外部行为，再讨论内部实现怎样调整。
• 跨会话继续开发：先读取当前规范、相关决策、任务进度和验证结果，再决定下一步。

落地时，可以根据项目现有习惯选择方式：

• 自建流程：沿用需求文档、设计记录和测试体系，约定好 AI 在什么阶段读取、更新哪些材料。
• Spec Kit：借助现成的规范、计划、任务和实现流程组织工作。官方文档
• OpenSpec：围绕一次变更组织提案、行为增量、设计和任务，并维护当前规范与变更记录。官方文档

我实际开发中使用的是 OpenSpec。它与我的工作方式比较契合，但本文讨论的方法也可以用其他工具或自己编排的流程实现。

选择时可以检查：要求是否明确，材料能否持续更新，AI 是否能找到相关依据，结果有没有验收方式。具体文件名和命令不是判断这套方法是否有效的标准。

文件齐全之后，仍然需要检查代码和验证结果。任务清单打了勾，只能说明进度被标记了；验收场景是否成立，要看实际证据。

研发结束后，怎样沉淀成项目知识

如果一次研发只留下代码，下一次接手的人或 AI 仍然可能不知道：为什么这样设计，哪些约定不能随便改，当时排除了哪些方案。

我希望每次需求完成之后，项目都能多留下一些可继续使用的理解。

一次变更结束后，可以把仍然有效的行为要求维护到当前规范里，把当时的技术取舍和原因保留到历史记录中。下一轮开发既能知道现在应该怎样工作，也能理解为什么形成这样的设计。

两类记录的用途要分清。当前规范告诉后续开发需要遵循什么；历史记录解释当时为什么做出某个选择。已经废弃的方案，可以留作背景，但不能继续被当成当前要求。

这个过程也需要维护。文档与代码冲突时，要检查是实现偏离了要求，还是规范已经过时，不能只凭文件所在的目录判断谁一定正确。

更不需要把全部历史记录塞进每一次对话。为相关材料提供清楚的入口，让下一项任务按需读取即可。Anthropic 的上下文工程文章也介绍了按需检索，以及把结构化笔记保存到会话之外、后续重新读取的做法。Anthropic 工程文章

以 OpenSpec 为例，当前规范与本次变更分开管理，行为增量可以同步，变更材料可以归档。无论使用哪种工具，维护记录、验证实现和发布上线都需要分别核对。

从下一次真实需求开始

从下一项真实、边界适中的变更开始，只整理这次需要的要求和上下文。OpenSpec 的已有项目指南也建议逐步采用。OpenSpec 已有项目指南

小改动用简短说明和适当验证；涉及多个模块、兼容行为和历史决策时，再补充更完整的规范。

采用后，观察返工和重复解释是否减少，跨会话能否接着推进，历史决策是否更容易找到，再衡量维护成本。

规范写错了，错误也可能传到实现和测试里，需求澄清与最终验收仍然重要。

代码会继续变化，但每一轮开发都应该能接着上一轮的理解往前走。