词汇表
教材术语汇总列表。作为任何部分的支撑——定义在此重复,以避免文本中出现不同解读。
SDD 工件
项目宪法 — specs/ 中的三个文件,记录长期决策:mission.md(为什么以及为谁)、tech-stack.md(如何)、roadmap.md(什么以及按什么顺序)。仅在重新规划阶段更改。
**mission.md** — 目的、受众、基调、成功定义。
**tech-stack.md** — 语言、环境、框架、数据库、测试、限制。如果此处未记录决策,代理可能会自行推断。
**roadmap.md** — 带状态的排序阶段。每个阶段都是单独功能分支的候选。
功能规范 — 文件夹 specs/YYYY-MM-DD-feature-name/,包含三个文件:
- **
requirements.md** — 边界、不包含的内容、此功能的具体决策、上下文。 - **
plan.md** — 用于实现的分组编号任务。 - **
validation.md** — 事实和就绪标准集合(见下文)。
**QWEN.md** — Qwen Code 的持久上下文:代理在此仓库中的行为规则。
**AGENTS.md** — 任何 AI 代理的通用契约。如果两个文件都存在,Qwen Code 会同时读取两者。
**CHANGELOG.md(项目级)** — 学习项目的变更日志。在合并前由 changelog 技能更新。
修复规范 — 文件夹 specs/YYYY-MM-DD-bugfix-name/,包含文件 bugfix.md、plan.md、validation.md。当任务是修复已有行为而非添加新功能时,替代常规功能规范。bugfix.md 必须包含「当前行为」「预期行为」「根本原因证据」「不应更改的内容」「回归场景」章节。validation.md 必须包含事实复现:修复前失败、修复后通过的命令或场景。详见第 11 部分。
否定需求 — 规范中描述功能或修复实现时不应更改什么的章节:哪些路由、契约、行为和数据保持不变。常规功能中为「边界之外」,修复规范中为「不应更改的内容」。防止代理容易做出的「顺手改进」,当边界未明确写出时。
事实生命周期
事实 — 可执行或明确可验证的陈述,可得出明确的「通过/未通过」裁决。通过命令、测试、HTTP 状态、数据库不变量。
validation.md 中的事实级别:
- 示例 — 具体的输入-输出对。
- 不变量 — 始终为真(动作后、任何数据库状态等)。
- 属性 — 验证一类情况。
- 契约 — 形式化的「在条件 X 下,动作 Y 导致 Z」绑定。
事实状态:
- draft — 已提出,但尚未接受。
- spec — 已接受为功能必需。
- implemented — 有测试、命令或手动确认。
- deferred — 有意识地推迟到未来阶段。
证据包 — 附在合并请求上、证明分支已就绪的工件集合:功能规范链接、validation.md 中自动检查的完成标记、手动检查日志、必要时还有截图、请求转储、日志摘录。不是单独文件,而是合并请求评论的结构。免除审查者从零开始复现整个场景的义务。详见第 9 部分。
流程
重新规划 — 功能之间的单独分支,更新 mission.md、tech-stack.md、roadmap.md、测试策略、变更日志。不实现产品功能。
MVP 阶段 — 从多个阶段立即构建最小可行版本。规范成熟度的压力测试;比普通功能风险更高。
AI 疲劳(早期曾作为 AI fatigue 的借词出现)—— 人类因代理产生变更的速度超过人类能够审查的速度而感到的疲惫。SDD 通过小阶段、明确边界和事实检查来降低它。
偏离(英文 drift)—— 实现与规范之间的分歧。可能出现在代码中、事实中以及规范本身中(当项目规则已更改而功能未更改时)。
升级规则 — 记录在 QWEN.md 或技能中的情况列表,代理在这些情况下必须停止并将控制权交还人类:模糊需求、validation.md 中缺少所需事实、与 specs/tech-stack.md 冲突、需要破坏性命令、新依赖。没有这些规则,代理倾向于默默做出之后必须回滚的决策。详见第 14 部分。
SDD 成熟度等级 — 描述团队流程状态的简短等级,从 0(「氛围编码」)到 4(「可学习流程」)。不声称权威;用作镜子,以注意当前哪一步收益最大。教材目标是在教学项目上带领团队达到 2 级。详见第 21 部分。
Qwen Code 工具
技能(Skill) — 包含 SKILL.md 的目录,描述代理何时以及如何应用特定流程。个人级(~/.qwen/skills/)或项目级(.qwen/skills/)。
钩子(Hook) — Qwen Code 在事件发生时执行的 shell 命令(SessionStart、UserPromptSubmit、PreToolUse、PostToolUse、Stop 等)。用于日志记录、添加上下文、守护边界。
MCP — Model Context Protocol;通过 settings.json 中的 mcpServers 或 qwen mcp add 连接到代理的工具和数据源外部层。
ACP — Agent Client Protocol;代理与 IDE/客户端的通信协议。例如,在 JetBrains 中使用 Qwen Code 时。
无界面模式(英文 headless)— qwen -p "...";无需交互会话启动代理,用于自动化和 CI。
上下文退化(英文 context rot)— 研究中观察到的现象:随着输入增长,模型回答质量下降——在长且不相关的上下文中,相关片段比短且聚焦的上下文中更难找到。教材中的实际后果:角色之间使用 /clear,仅在 QWEN.md 中注入相关记忆记录,限制混入上下文的长度。详见第 14 部分和第 19 部分。
外部 SDD 框架
GitHub Spec Kit — 开源框架,标准循环为 /constitution → /specify → /clarify → /plan → /tasks → /analyze → /implement。
AWS Kiro — 具有自己 SDD 模型的 IDE:规范(requirements.md + design.md + tasks.md)、转向文件、代理钩子。
教材与 Spec Kit 和 Kiro 的对应关系见附录 A。
反模式(见第 20 部分)
- 代码后的规范 — 工件为报告而写,而非为控制而写。
- **巨型
requirements.md** — 50 项的规范,没人执行。 - **没人运行过的
validation.md** — 事实是理论性的。 - 错误后弱化事实 — 重写事实而非修复代码。
- **仪式性的
/clear** — 不理解实际作用就清除上下文。 - 技能作为魔法按钮 — 团队调用技能而不阅读
SKILL.md。 - **
QWEN.md作为垃圾堆** — 变成不可读的巨幅文本,代理不再遵循主要规则。 - 默默修改项目的钩子 — 没有日志记录,没有人类反馈。
- 记忆作为隐藏真相来源 — 强制规则只存在于 SQLite 中,而非规范中。
- 无目的的 MCP — 因为可以就连接。
- 过大的 MVP — 没有规范成熟度。