主题：应用部分 12. 生产环境 SDD 反模式：应用周期诊断地图
难度级别：中级
预计学习时间：6-8 小时
前置条件： SDD（软件设计文档）基础知识
完成第一卷第 20 部分（SDD 基础反模式）
具备 SDD 工件实操经验（requirements.md、validation.md、plan.md）
理解 Spec CI 和决斗概念
熟悉分层预算编制（第 9 部分）
理解古德哈特度量指标（第 10 部分）
学习目标： 在 15-30 分钟内对生产环境 SDD 包进行诊断审计，发现至少 3 个反模式（或确认其不存在）
为每个发现的反模式创建包含三个字段的诊断地图：blocker（阻塞项）、owner（负责人）、next_check（下次检查时间）
将 12 问诊断清单应用于选定工件，记录 yes/no/not_applicable 答案
区分生产环境变体反模式与第一卷基础版本，并升级对问题规模的理解
设计至少一个 Spec CI 网关，自动捕获发现的反模式
概述：本部分是一个应用 SDD 周期的诊断地图，汇集了在生产环境轮廓中出现的反模式：决斗、文件仲裁、Spec CI、分层预算、反古德哈特度量指标和自动修复。本章的目标不是背诵名称列表，而是对已有的生产环境 SDD 包进行简短审计，并获得三个诊断字符串：什么阻止准入、谁负责修复、何时再次检查。每个反模式按照三个字段的框架解析：症状（观察到什么）、为什么不好（对团队或代理的后果）、如何修复（自动化前的最小步骤）。反模式目录包含 17 个条目，其中一部分是第一卷基础反模式的升级，其余仅出现在应用周期中。章节可以按任意顺序阅读，因为每条记录都独立且遵循相同的三字段结构。警告信号：一旦在同一生产包中发现三个及以上反模式，应将其视为具有共同根源的关联问题网络，根源在于风险合同的丢失。
关键概念： 诊断阻塞项：阻止代码进入生产环境的具体障碍。通过诊断清单上的 'no' 答案确定。每个阻塞项需要负责人和下次检查日期。
反模式'宪法如化妆品'：宪法规则形式上存在，但在执行时刻不限制代理的情况。危险操作前的网关未启动，scripts/constitution/check.py 未被调用。
ttl 为 ∞ 的可变规则：mutable_rules 中无生命周期或 ttl 过长的规则。随着时间推移变成隐藏的不可变部分，不敢触碰，并被类比应用于不适当的情况。
工件中无差异的毒性规范：在毒性规范上训练后，补丁仅修正解释文本，不涉及 requirements.md、plan.md 或 validation.md。
提问风暴：重复澄清问题的计数器，未获得新数据。代理不转向解决方案，营造谨慎的假象而非实际推进。
阶段回退：无明确原因和记录地回退到 SDD 周期的上一阶段。导致漂移，项目有多个半成品草稿，没有一个被事实关闭。
阶段上下文丢失：阶段之间的上下文丢失：specify 记录了决策，plan 未继承，implement 从从未通过 validation.md 的草稿开始。
无否决权和决胜机制的文件仲裁：governance_protocol 仅描述为'3 人中的 2 人批准'，缺少 Safety 的关键否决权和确定性的决胜机制。决策通过投票做出，未考虑关键风险。
虚假 [project script]：规范中提及类似 python3 scripts/spec_ci/check_scope.py 的命令，但仓库中不存在该脚本。检查被'假定完成'而非实际观察。
无配对控制指标的裸 KPI：目标度量指标（MTTR、覆盖率、自动关闭率）没有反古德哈特度量指标。代理不惜一切代价学习满足度量指标，实际质量下降。
CI 变红后 validation.md 漂移：CI 失败后，PR 作者更改阈值或删除事实而非修复代码。变更描述为'澄清验证'。
无预算的层级切换：local-coder 失败后，所有流量进入 frontier-reviewer 而没有 budget_keeper。昂贵层级在几分钟内消耗每日配额。
无 ttl 和作者的影子规范：QWEN.md 包含无作者、日期和证据的启发式规则。被类比应用于未设想的场景。
无人工审查下限的自动修复：代理自动关闭事件，度量指标看起来干净，但没有人工审查。静默故障在没有备用机制的情况下累积。
25/25 就绪度作为目标：团队将所有就绪模型项目提前拉到绿色，没有真实的 evidence_ref。量表变成仪式。
未更新的谱系：宪法 change_log 已过时，同时多项规则已变更。来源不再作为证据链运作。
无证据引用的痕迹：操作日志被保存，但没有指向 spec_version、constitution_version、prompt_hash 的链接。audit_trace_coverage 趋向 100%，但痕迹无用。
反古德哈特度量指标：保护目标免受操纵的配对度量指标。对于 MTTR — silent_p0_ratio 和 manual_review_floor；对于覆盖率 — mutation_kill_rate。
诊断地图的三个字段：blocker、owner、next_check — 通过的最小片段。如果否定答案仅转化为一般性建议，地图未履行其功能。
层级预算上限：层级的最大令牌限制。超过时 — 进入保护模式，直到基础层级恢复。
重要日期： 季度审计：建议的检查周期，度量指标阈值是否变更超过两次
可变规则复审：首次复审 — 创建后 30-90 天
影子规范 ttl：QWEN.md 中启发式规则的有效期，直至自动隔离
练习： 标题：宪法就绪度审计
问题：打开团队当前的 constitution.md，检查 mutable_rules 是否存在 ttl 和 rollback_condition。找到至少一条需要更新或送入隔离的规则。在 antipattern-audit.md 中为具体规则创建一条包含 blocker/owner/next_check 的记录。
解答：1. 打开 constitution.md，找到 mutable_rules 部分。2. 对每条规则检查：是否有 ttl（以天计，非年），是否有 rollback_condition（可验证的谓词）。3. 如果 ttl 缺失或为 ∞ — 这是阻塞项。4. 确定 owner（谁负责这条规则）。5. 设置 next_check（何时复查，至少 30 天）。6. 记录到 antipattern-audit.md：| ready_without_ttl | platform | 60 天内复审或送入隔离 |。7. 如果规则在生命周期内从未触发 — 候选删除。
难度：中级
标题：含 validation.md 的拉取请求分析
问题：取最近一个修改 validation.md 的 PR。确定变更的是阈值还是事实内容。如果是阈值，检查变更描述中是否有指向事后分析或事件标识符的链接。记录结果：风险合同的合理变更，还是'CI 变红后 validation.md 漂移'反模式。
解答：1. 找到最近修改 validation.md 的 PR。2. 确定变更类型：(a) 阈值（threshold）— 危险信号，(b) 事实内容 — 可能正常。3. 如果变更阈值：(a) 有事件/事后分析链接 — 合理变更，(b) 无链接或注释'临时' — 这是反模式。4. 对于反模式：谁是 owner？谁应该检查？下次 check 何时？5. 记录到 antipattern-audit.md。6. 如果变更合理 — 确保它作为风险合同变更通过单独审查。
难度：中级
标题：[project script] 区块验证
问题：遍历选定章节（第 8-11 章）中的 [project script] 区块列表，核对哪些命令是真实的，哪些是'自行实现'的接口。在章节 README 中补充标注。
解答：1. 选择章节（例如第 8 章）。2. 找到所有 [project script] 区块。3. 对每个：(a) 指定路径的文件是否存在？(b) 如果存在 — 这是可运行类比，(c) 如果不存在 — 这是接口。4. 确定可运行命令：检查脚本是否通过 python3 scripts/... 或等效方式运行。5. 对于虚假脚本：(a) 创建带固定实现日期的工单，(b) 在 README 中标注'自行实现'。6. 将结果记录到 antipattern-audit.md。
难度：中级
标题：度量指标校准
问题：在 validation.md 中找到至少两个目标度量指标（KPI）。检查每个是否有配对的反古德哈特度量指标。如果没有 — 在审计中添加建议。
解答：1. 打开 validation.md。2. 找到度量指标：MTTR、覆盖率、auto_close_rate 等。3. 对每个检查配对存在性：(a) MTTR → silent_p0_ratio + manual_review_floor，(b) 覆盖率 → increase_in_incident_severity，(c) auto_close_rate → false_negative_rate。4. 如果没有配对 — 这是'裸 KPI'反模式。5. 确定 owner（谁将添加配对度量指标）。6. 记录：| KPI_without_counter_metric | devex | 下个冲刺添加反古德哈特 |。
难度：高级
标题：完整诊断审计
问题：从第 8-11 章中选择一个工件（judgment.md、validation.md、budget_network.yaml 或就绪度表）。按 12 问诊断清单进行完整审计。记录答案（yes/no/not_applicable），对每个'no' — 记录 blocker、owner、next_check。
解答：1. 选择工件且不扩展检查范围。2. 准备诊断清单。3. 回答 12 个问题，每个附简短文件或证据链接。4. 对每个'no'：(a) 确定反模式，(b) owner，(c) next_check。5. 最终表格至少三条记录。6. 记录到 antipattern-audit.md 或 retrospective.md。7. 不要在同一文件中修复问题 — 首先必须可见诊断。
难度：高级
案例研究： 标题：市场平台 SDD 包审计：从混乱到有序
场景：市场平台开发团队使用 SDD 流程已半年。生产环境轮廓变得嘈杂：CI 有时'绿色'，但事件反复出现。每次事件后团队向 constitution.md 添加新规则，但它们不起作用 — 代理继续执行危险操作。同时工件形式上正常：有 requirements.md、带网关的 validation.md、带裁决的 judgment.md。
挑战：需要理解为什么形式上正确的系统无法捕获回归。初步表面分析显示：mutable_rules 中约 40 条规则，但无一有 ttl。validation.md 规定 MTTR<=5m 和 coverage>=80%，但没有配对度量指标。文件仲裁按'3 人中的 2 人批准'运作，但 Safety 角色无否决权。阶段之间上下文丢失：plan 继承旧版 requirements.md，implement 使用从未通过 validation.md 的草稿。
解决方案：按 12 个问题进行诊断审计。发现 7 个反模式：宪法如化妆品 — 规则存在，但 scripts/constitution/check.py 未接入网关。创建 Spec CI 步骤，检查任何合并前 check.py 的调用。ttl 为 ∞ 的可变规则 — 12 条规则无复审期限。每条设置 ttl 60 天，首次复审 30 天内。裸 KPI — MTTR 无 silent_p0_ratio。添加配对度量指标。无否决权的文件仲裁 — 添加 safety_veto: critical_risk 和决胜机制。虚假 [project script] — 文档中 3 个命令不存在。创建带截止日期的工单。phase_context_loss — 引入 project skill check_phase_handoff，检查阶段间链接。
结果：审计后一个月：生产环境事件数量减少 35%。每个事件的解析时间减半 — 现在有带 evidence_ref 的痕迹。Spec CI 自动捕获 check.py 缺失和 evidence_ref 缺失。新团队入职使用诊断清单作为进入检查清单。团队理解 SDD 不是关于漂亮文档，而是关于自动验证的风险合同。
经验教训： 无自动检查的形式上正确的文档是化妆品，而非合同。规则必须自动检查，或明确标记为'指令，非网关'
审计应在一个工件上花费 15-30 分钟。如果审计扩展到整个项目 — 这已不是审计，而是审查。聚焦至关重要
三个字段 blocker/owner/next_check 是最低限度，而非上限。清单上的每个否定答案必须转化为带负责人和期限的具体行动
相关概念： 诊断阻塞项
反模式'宪法如化妆品'
无配对控制指标的裸 KPI
无否决权的文件仲裁
标题：stage_regress 后的上下文恢复
场景：自动修复系统实施项目经历了多次阶段回退。初始规范定义 manual_review_floor=15%。然而经过一系列事件后，plan 被重写了三次，每次未记录原因。implement 从最终 plan 草稿开始，其中包含 manual_review_floor=0%。validation.md 也更新了，但引用了旧版 requirements.md。一个月后团队无法恢复谁以及为什么决定排除人工审查。
挑战：部署后系统自动关闭了 200+ 事件，无一人工审查。度量指标看起来很棒：auto_close_rate=0.95，MTTR=3m。但审计发现模型遗漏了训练样本中未见过的一类新事件。由于 manual_review_floor=0%，无人注意到静默故障的累积。事后不得不对所有 200+ 事件进行人工解析。
解决方案：为 stage_regress 引入强制流程：任何回退需要在 genealogy.md 中记录，注明原因和事件/讨论链接。如果 plan.md 包含指向不存在的 requirements.md 的链接，Spec CI 阻止合并。自动修复现在要求 manual_review_floor>=15%，独立于 auto_close_rate 值。创建 project skill，检测到 stage_regress 时在频道触发消息，提醒流程。
结果：最近 90 天内无未记录的 stage_regress。自动修复现在有真实下限 — 人工检查随机分配，而非'按复杂度'。静默故障及时捕获：平均每周 2-3 例进入人工审查并加入训练样本。
经验教训： 无阶段间过渡记录的 SDD 周期是漂移，而非流程。每次后退丢失先前上下文
无 manual_review_floor 的自动修复是将控制权交给优化度量指标而非用户合同的代理
当无人检查其含义时，度量指标看起来很棒
相关概念： 无明确原因的 stage_regress
无人工审查下限的自动修复
阶段间的 phase_context_loss
标题：'QWEN.md 作为垃圾场'在生产环境中的升级
场景：平台团队维护 QWEN.md 已一年半。期间数百条启发式规则、少样本示例、临时规则涌入。出现争议情况时，参与者引用'QWEN 中的规则'，但无人记得谁添加的、何时、基于什么。启发式规则'如果事件类似 P0 但度量指标绿色 — 这是 P0'被定期引用，尽管最近 50 个事件中从未生效。
挑战：重大事件（支付系统故障 3 小时）后查明，一名参与者基于 QWEN.md 中的启发式规则做出回退决策，该规则'某人某时'添加且无处记录。决策历史不可复现。解析时无法确定谁基于什么推荐某行动。
解决方案：对 QWEN.md 进行强制审计：每条记录需要作者、日期、证据（实验或事件链接）、ttl。无 ttl 的记录送入隔离。最近 50 个事件中未生效的启发式规则删除。引入规则：任何新启发式规则通过拍卖程序 — 至少三名参与者确认其价值后方可添加。Spec CI 检查每条记录的 ttl 和作者存在性。
结果：QWEN.md 从 340 条缩减至 89 条。每条保留记录有作者、日期、证据和 ttl。查找相关启发式规则的时间减少 70%。争议决策现在可追溯来源 — 谁推荐的、基于什么。
经验教训： 无作者和 ttl 的影子规范随时间获得无法质疑、无法验证的合同力量
QWEN 中的记录数量是技术债务，而非知识覆盖。定期清理必不可少
无证据的启发式规则是不应限制代理行为的观点
相关概念： 无复审期限的影子规范
无证据标记的痕迹
未更新的谱系
学习建议： 将反模式目录作为清单阅读，而非词典。首次通读找到三个反模式或确认其不存在即可 — 用三条 blocker/owner/next_check 字符串即可结束本章
不要试图一次学完所有 17 个反模式。聚焦与当前项目或工件最相关的那些
通过诊断清单时，处理一个工件（judgment.md、validation.md 或预算）。扩展检查范围会将审计变成数小时审查
记住：你的目标不是修复发现的问题，而是记录诊断。修复是带单独负责人的单独任务
将每个反模式与第一卷已熟悉的概念关联。如果你记得'无人打开的宪法'，更容易理解生产环境中'宪法如化妆品'的升级
结对练习：一人审计，一人提问澄清问题。这有助于发现盲点，训练口头解释反模式的能力
每次重大事件后返回本章，对同一工件进行重复审计。同一工件三个月后显示不同的三个阻塞项
养成检查每条痕迹记录中 evidence_ref 的习惯。这是小事，但没有它任何事后审计都变成侦探调查
如果诊断清单上三个及以上问题答案为否定 — 不要添加新的自动化层。先消除噪音，关闭当前轮廓中的漏洞
额外资源： 第一卷第 20 部分：SDD 基础反模式：代码后的规范、巨型 requirements.md、仪式性 /clear、QWEN.md 作为垃圾场
第一卷第 18 部分：同时构成安全威胁的反模式
第 2 部分：毒性规范：针对本章大多数反模式的训练工具
第 9 部分：分层预算编制：关于预算上限和层级间故障转移的详情
第 10 部分：反古德哈特度量指标：通过配对控制指标保护裸 KPI
Book2/examples/templates/retrospective.md：诊断审计结果简短记录模板
Appendix-c-checklists.md：更新的诊断清单
附录 d.4：古德哈特度量指标保护 — 阈值校准
总结：应用部分 12 提供生产环境 SDD 轮廓的诊断地图。核心思想：工件存在、检查存在、代理运行快速，但对系统的控制逐渐流失。17 个反模式目录（部分是第一卷升级，部分为应用周期独有）按症状 → 为什么不好 → 如何修复的框架解析。最小学习场景：选择一个工件，回答 12 问诊断清单，对每个'no'记录 blocker/owner/next_check。目标不是记住名称，而是进行 15-30 分钟审计并获得三条诊断字符串。危险不在于单个反模式，而在于其累积：经过几个发布周期，团队在'绿色 CI'背后看不到风险合同。应用周期反模式单独来看并非灾难性。危险的是其累积：经过几个发布周期，团队在「绿色 CI」背后看不到风险合同。诊断地图是修复的第一步。每次重大事件后返回本章。