第三部分：流程概述

SDD 流程可以表示为多个记忆层。顶层是项目宪法。中间层是功能规格说明。底层是实现和验证。功能之间存在重新规划：当新工作表明旧决策不准确时，您需要更新上层。

基本循环：

flowchart TD
  A["宪法<br/>mission.md<br/>tech-stack.md<br/>roadmap.md"] --> B["功能规格说明<br/>requirements.md<br/>plan.md<br/>validation.md"]
  B --> C["实现<br/>代码、测试、迁移"]
  C --> D["验证<br/>自动和手动事实"]
  D --> E{"事实通过了吗？"}
  E -- "是" --> F["合并"]
  F --> G["重新规划<br/>更新规则和路线图"]
  G --> A
  E -- "否" --> B

宪法的角色

宪法回答那些不应在每个功能中重新决定的问题：

• 项目为何存在；
• 为谁而创建；

• 使用什么技术栈；
• 已接受哪些架构限制；
• 哪些阶段已计划、进行中或已完成。

在 Qwen Code 中，这一层由 QWEN.md 文件补充。区别在于：QWEN.md 告诉代理如何在仓库中行事，而 specs/*.md 告诉代理要构建什么产品。

结构示例：

agentclinic/
  QWEN.md
  specs/
    mission.md
    tech-stack.md
    roadmap.md

功能规格说明的角色

为路线图的每个阶段创建一个单独的文件夹：

specs/
  2026-05-10-feedback-form/
    requirements.md
    plan.md
    validation.md

requirements.md 确定边界、不包含的内容、决策和上下文。

plan.md 将工作分解为任务组。

validation.md 描述如何理解分支可以合并。

这些文件比聊天记录更重要。新的 Qwen Code 会话只需阅读仓库即可继续工作。

分支的角色

每个功能阶段应该存在于单独的 Git 分支中：

git checkout -b phase-1-hello-hono

这降低了与代理一起工作时的认知负担。如果代理更改了太多内容，您有一个明确的边界：此分支的所有更改都应与特定规格说明文件夹相关。

/clear 的角色

在 Qwen Code 中，新鲜上下文有助于验证规格说明是否充分。如果代理在 /clear 后能够实现功能，则意味着所需知识已记录在文件中，而不是隐藏在聊天记忆中。

示例：

/clear

阅读 @QWEN.md、@specs/mission.md、@specs/tech-stack.md
和 @specs/2026-05-10-feedback-form/plan.md。
仅实现任务组 1。在文件更改列表后停止。

如果清除后代理提出合理的澄清问题，这是正常的。如果它开始猜测，则规格说明不完整。

与代理合作的四种模式

1. 访谈模式。代理提问并帮助编写规格说明。
2. 实现模式。代理实现特定的任务组。
3. 验证模式。代理查找代码与规格说明之间的不一致。
4. 重新规划模式。代理更新宪法、路线图、变更日志和流程。

除非必要，不要混合这些模式。当在一个会话中您先讨论产品，然后要求代码，再要求验证时，代理开始将旧上下文拉到应该由文件工作的地方。

「计划—实现—验证」循环

在一个功能内部，模式 2 和 3 可以方便地表示为「计划—实现—验证」循环（在英语资料中称为 Plan-Act-Verify）。该循环设定三个阶段以及每个阶段的明确限制：

• 计划。 代理列出打算做什么、将触及哪些文件、将运行哪些检查。在此步骤中，代理不编写代码也不更改文件。如果计划包含 requirements.md 中没有的更改，这是需要澄清规格说明的信号，而不是「让我们试试」。
• 实现。 代理在批准的计划范围内更改代码。禁止在实施过程中扩展计划：新想法要么变成单独的任务组，要么变成规格说明的修正。
• 验证。 代理将结果与 validation.md 进行比较，列出哪些通过了、哪些失败了、哪些未检查。在此步骤中，代理不修复代码——它只写报告。

在构建请求和阅读代理响应时，将这三个阶段牢记在心是很有用的：如果响应混合了「我计划」和「我已经做了」，您就失去了控制点。在第 8 部分中，这些限制将转化为每个阶段的具体请求。

三种规格说明模式

并非所有工作都以相同方式描述。区分三种模式很方便：

• 需求优先（Requirements-First）。 教程的默认模式。用于主要关注应该出现什么的功能：评论页面、反馈表单、新路由。

• 设计优先（Design-First）。 当需求早已明确，而主要风险在于如何具体实现时应用：模式迁移、公共 API 更改、模块重组。这里先写 plan.md 或单独的 design.md，然后再写详细需求。
• Bugfix 规格说明。 修复的单独模式：不是「应该出现什么」，而是「什么复现了 bug」、「预期结果是什么」、「修复时不应改变什么」。详见第 11 部分。

在 AgentClinic 教学项目中，您几乎总是以「需求优先」模式工作。其他模式的名称是为了避免将第一个模板拉伸到它妨碍的地方。

Qwen Code 项目概述请求示例

你正在帮助我按照 SDD 工作。
暂时不要写代码。
阅读 @README.md 并查看仓库结构。
建议初始的 specs/ 目录：
- mission.md
- tech-stack.md
- roadmap.md

在写入文件之前，恰好提出三个分组问题：
1. 使命和受众
2. 技术栈和限制
3. 路线图和第一阶段

实践

在教学项目中创建空结构：

mkdir -p specs

touch specs/mission.md specs/tech-stack.md specs/roadmap.md

暂时将文件留空。在下一部分中，我们将配置 Qwen Code 使其理解项目规则，然后有意识地填写宪法。

检查问题

1. 为什么功能规格说明最好与代码放在一起，而不是放在单独的文档中？
2. 什么时候需要重新规划？
3. /clear 后的成功实现表明了什么？