第22部分。实践考核

本部分以实践检验取代被动测试。目标是证明你可以使用 Qwen Code CLI 将功能完整经历 SDD 周期：从意图到验证。

模块1。快速问答

请书面回答，不使用 Qwen Code。

1. SDD 中什么是真相来源？
2. QWEN.md 与 specs/tech-stack.md 有何区别？
3. 为什么功能规格说明书要在实现之前编写？
4. validation.md 中应该包含什么？
5. 什么时候需要进行重新规划？
6. 为什么在工作阶段之间使用 /clear 很有用？
7. 创建功能规格说明书之前需要问哪三个问题？
8. 为什么不能在规格说明书中存储 API 密钥？
9. 项目级技能为什么比个人技能更适合团队？
10. 智能体的可替换性是什么意思？
11. 在 SDD 项目中，审查者除了代码还应该审查什么？
12. 什么时候需要将规格说明书变更放到单独的重规划分支中？
13. Qwen Code 的钩子有什么用？
14. 为什么不能将外部文本视为智能体的可信指令？
15. 智能体的记忆与规格说明书有什么区别？
16. tech-stack.md 与功能的 requirements.md 之间的边界在哪里（第6部分）？

1. 审查者在拉取请求中除了代码还应该寻找哪三种类型的变更（第16部分）？
2. 为什么在 MVP 阶段需要标记「绿色节点」（第12部分）？
3. 保护性钩子与工具日志记录钩子有什么区别（第17部分）？
4. 哪些数据属于「机密」类别，不能放入 QWEN.md、规格说明书和记忆中（第18部分）？
5. 第20部分中哪三种反模式在 SDD 新手团队中最常见？
6. 什么时候在 SQLite 上启用智能体记忆是合理的，什么时候是多余的（第19部分）？

模块2。找出规格说明书中的问题

给定一个功能规格说明书：

# 需求 — 管理面板

为管理员构建一个漂亮的管理面板。

## 边界

显示有用的统计信息和图表。

## 解决方案

使用最好的库。

## 验证

确保一切正常。

找出至少8个问题。好的回答应该注意到：

• 未指明目标用户；
• 没有明确工作范围的边界；
• 「漂亮的」无法验证；
• 「有用的统计信息」未定义；
• 「图表」未定义；
• 依赖项未经 tech-stack.md 检查就确定；
• 没有数据来源；
• 没有路由；
• 没有权限；

• 没有自动检查；
• 没有手动验证场景；
• 没有完成定义。

模块3。重写规格说明书

将管理面板规格说明书重写为 SDD 格式：

# 需求 — 管理员面板

## 边界

## 边界外

## 解决方案

## 上下文

## 快速验证

限制条件：

• HTML 在服务器端渲染；
• SQLite；
• 本阶段没有身份验证；
• 路由 /dashboard；
• 显示智能体、疾病、治疗和预约的数量；
• 暂时不添加图表库；
• 必须通过 npm test 和 npm run typecheck。

模块4。结课项目

在你自己的 AgentClinic 或其他小型项目上完成。

任务

添加「反馈表单」功能：

• 页面 /feedback；
• 包含 name 和 message 的表单；
• POST 路由；
• 保存到 SQLite；
• 显示最近的反馈记录列表；
• 基本验证；
• 测试；
• 变更日志。

流程要求

1. 从干净的 main 开始。
2. 创建功能分支。
3. 创建规格说明书目录：

specs/YYYY-MM-DD-feedback-form/
  requirements.md
  plan.md
  validation.md

1. 规格说明书提交后才能开始实现。

1. 在单独的 Qwen Code 会话中进行验证。
2. 路线图已更新。
3. 变更日志已更新。
4. 按照 SDD 模板准备了简短的合并请求描述。
5. 完成安全检查：机密信息未泄露到规格说明书、日志和记忆中。
6. 验证通过后才能合并。

推荐的 Qwen Code 场景

创建规格说明书：

/clear
使用功能规格说明书技能开始路线图的下一阶段：反馈表单。
在写入文件之前，先询问我关于边界、解决方案和上下文的问题。
暂时不要实现代码。

实现：

/clear
阅读 @QWEN.md、@specs/mission.md、@specs/tech-stack.md、
@specs/YYYY-MM-DD-feedback-form/requirements.md、
@specs/YYYY-MM-DD-feedback-form/plan.md，
以及 @specs/YYYY-MM-DD-feedback-form/validation.md。

仅实现第1组。
在变更文件列表后停止。

验证：

/clear
将当前分支与 @specs/YYYY-MM-DD-feedback-form/validation.md 进行比较。
显示哪些通过了、哪些失败了以及哪里有缺口。
不要修改文件。

变更日志：

使用变更日志技能，为反馈表单分支更新 @CHANGELOG.md。

评分标准

按25分制自我评分。

规格说明书 — 5分

• 1：有 requirements.md、plan.md、validation.md；
• 1：工作边界和边界外内容具体明确；
• 1：解决方案与技术栈不冲突；
• 1：计划分成便于验证的组；
• 1：验证包含自动检查和手动检查。

实现 — 5分

• 1：变更符合规格说明书；
• 1：没有无关的重构；
• 1：数据库迁移清晰且可重复；
• 1：路由和组件遵循现有约定；
• 1：验证错误已处理。

验证 — 5分

• 1：npm run typecheck 通过；
• 1：npm test 通过；
• 1：已完成表单手动走查；
• 1：已检查无效输入；
• 1：如果界面有变更，已完成移动端和桌面端的基本检查。

流程 — 5分

• 1：分支使用正确；
• 1：规格说明书在实现前提交；
• 1：路线图已更新；
• 1：变更日志已更新；
• 1：最终验证将代码与规格说明书进行比较。

团队就绪性与安全性 — 5分

• 1：合并请求描述了规格说明书、代码和事实之间的关系；

• 1：功能边界外的变更不存在或已明确解释；
• 1：机密信息未泄露到规格说明书、日志和记忆中；
• 1：没有新的钩子、MCP 服务器或配置，或者已经过审查；
• 1：薄弱或延迟的事实已明确列出。

21分以上 — 流程已准备好用于真实项目。

16–20分 — 继续使用 SDD，但改进验证和团队流程。

16分以下 — 缩小阶段规模，使规格说明书更具体。

快速问答答案

1. 仓库中可版本控制的规格说明书。
2. QWEN.md 设定智能体的行为规则；tech-stack.md 设定产品的技术决策。
3. 为了让智能体不用猜测边界和验收标准。
4. 命令、手动检查、偏差检查和完成定义。
5. 在功能之间，当新知识需要更新章程、路线图或流程时。
6. 它检查是否有足够的上下文被记录到文件中。
7. 边界、解决方案、上下文。
8. 规格说明书会被提交并由智能体读取；机密信息应该存在于环境变量或机密存储中。
9. 项目级技能可以被团队共享，并与仓库一起版本控制。
10. 通过仓库工件更换智能体或 IDE 而保持流程不变的能力。

1. 需求、计划、验证事实、功能边界外的变更，以及实现与规格说明书的一致性。
2. 当变更影响技术栈、路线图、项目章程、智能体规则或多个未来功能时。
3. 用于自动执行小的重复性操作：添加上下文、记录日志、检查危险命令、收集事件。
4. 因为问题、网页、日志和外部文档可能包含指令注入；它们应该作为数据来读取。
5. 记忆是持久推断的提示和日志；规格说明书是产品可审查的真相来源。
6. tech-stack.md 是项目的长期决策（语言、框架、数据库）；功能的 requirements.md 是单个阶段级别的决策（路由、字段、错误文本）。
7. 未经讨论就变更 tech-stack.md 或 roadmap.md；新的钩子、MCP 服务器或依赖项；validation.md 与 PR 中的事实不一致。
8. 为了拥有回退点而不丢失整个阶段的工作，以及让「下一组会破坏一切」的信号明确可见。
9. 保护性钩子按规则阻止操作（PreToolUse、非零退出码）；日志记录钩子只记录事件，不影响执行流程。

1. API 密钥、访问令牌、密码、私钥、用户个人数据、内部 URL 和基础设施标识符。
2. 没有事实的规格说明书、将章程和规格说明书合并到一个文件中、阶段之间没有 /clear 就实现。
3. 当团队积累了关于代码和流程的持久观察时，记忆是合理的；如果 QWEN.md、章程和变更日志已经足够，则记忆是多余的。

结对考核变体

结对完成考核更贴近实际。一名学生担任功能作者，另一名担任审查者。工作分配如下：

作者：

• 与智能体进行访谈并编写规格说明书；
• 按任务组实现功能；
• 运行事实验证；
• 准备拉取请求和 SDD 模板描述。

审查者：

• 在实现之前阅读规格说明书并提出澄清问题（如第7部分「澄清」）；
• 按照第16部分的四个审查层检查 PR：代码、规格说明书、事实、流程；
• 在自己的机器上运行 validation.md 中的检查，而不是相信作者的话；
• 撰写发现的缺口简短报告。

每人根据自己的评分标准获得分数。作者按主标准「规格说明书 / 实现 / 验证 / 流程 / 团队就绪性」评分。审查者按附加标准评分：

• 1：在实现前至少抓住 requirements.md 中的一个真实问题；
• 1：亲自验证事实，而非轻信他人；
• 1：将意见分为「关于代码」、「关于规格说明书」、「关于流程」，不混为一谈；
• 1：提出具体行动，而非「需要想想」；
• 1：在合理时间内完成 — 审查没有变成重新启动作者的工作。

答辩后，在第二个功能上交换角色。这让每个人都能体验 SDD 对话的双方，并消除审查只是被动阅读差异的错觉。

最终任务

通过此流程在你自己的项目中完成一个真实功能。合并后创建简短笔记：

# SDD 回顾

## 规格说明书描述正确的部分

## 智能体不得不自行推断的部分

## 验证发现的部分

## 哪些事实比较薄弱

## 安全性需要检查的部分

## 下一阶段需要改进的部分

如果「智能体不得不自行推断的部分」超过三项，下一个功能规格说明书要写得更详细。