主题：应用部分 2. 规范缺陷诊断
难度级别：中级
预计学习时间：3-5 小时
先决条件： 了解否定需求概念（第一卷第7部分）
理解 SDD 反模式（第一卷第20部分）
具备 YAML 和 JSON Schema 的基础操作技能
对软件开发生命周期和变异测试概念有总体理解
学习目标： 能够在规范中故意引入恰好一个可控缺陷以检验系统（变异测试）。
识别并分类主要缺陷类型：循环、优先级冲突和隐藏越界。
使用 ask_storm、stage_regress 和 phase_context_loss 指标识别 AI 代理或系统卡死的症状。
通过覆盖规则（override）形式化冲突修复，并通过 JSON Schema 进行验证。
执行完整的 SDD 回路反向回归（Specify → Plan → Tasks → Implement）以确认缺陷已消除。
概述：本主题介绍一种称为"可控缺陷规范"（或需求变异测试）的工程化规范处理技术。该方法的本质是在规范中故意引入一个严格定义的缺陷，以检验系统（或 AI 代理，如 Qwen Code）如何进行诊断。主要目标是学会可控地触发故障、读取其痕迹并在需求中修复根本原因，使冲突不再重复。该方法要求严格的纪律：一次变异、一个预期的卡死症状、一个明确的恢复标准，以 Given/When/Then 格式和 JSON Schema 记录。
关键概念： 可控缺陷规范（poisoned spec）：在需求（规范）中故意植入预先已知的缺陷，以检验系统、AI 代理或分类流程的稳定性。核心规则：每次迭代只引入一个缺陷。
缺陷类别（变异）：主要注入错误类型：'cycle'（状态之间的循环依赖）、'priority_conflict'（两条优先级相同但导向不同操作的规则）和 'hidden_out_of_scope'（迫使违反既定约束的操作）。
卡死指标（诊断特征）：用于定位 AI 代理行为问题的启发式方法：'ask_storm'（重复提问但无新数据）、'stage_regress'（无原因回退到先前阶段）、'phase_context_loss'（丢失当前阶段上下文）。
需求形式化（yaml + json schema）：将争议需求以可执行格式（带优先级的 YAML）记录，并通过 JSON Schema 严格描述允许行为的边界，消除自然语言的歧义。
SDD 回路反向回归：通过完整执行 Specify → Plan → Tasks → Implement 循环来验证修复后的规范（fixed-spec）。如果原始冲突不再在任务和实现中复现，则视为成功。
实践练习： 标题：为事件创建 poisoned/fixed 配对
问题：教学案例 appointment_latency。需要创建一个规范，其中"30秒内升级 P0"的要求与"任何升级都需要人工确认"冲突。创建 poisoned-spec.md 和 fixed-spec.md 文件。
解答：1. 在 poisoned-spec.md 中创建两条 priority=100 的规则，在负责人不可用时相互阻塞。2. 记录预期症状（例如，尝试创建计划时出现 stage_regress）。3. 在 fixed-spec.md 中添加 p0_time_critical_override 规则，其优先级高于人工确认，并设置 human_audit_required=true 标志用于事后检查。
难度：中级
标题：在 validation.md 中记录恢复行
问题：需要将升级优先级冲突的成功修复标准形式化，记录到 validation.md 文件中。
解答：在 validation.md 中添加一行：priority_conflict=false && escalation_path_resolved=P0 && audit_required=true。这将确保机器可读的检查：冲突已消除、升级路径已确定、审计已保留。
难度：初级
标题：为覆盖规则编写 JSON Schema
问题：需要禁止 AI 代理在关键事件上回退到隐藏协商。描述要求 P0 在负责人无响应时自动升级的 JSON Schema。
解答：使用 if/then 结构。在 if 块中指定条件：severity=P0 和 owner_unresponsive=true。在 then 块中指定必填字段：auto_escalation_channel=critical_phone、human_audit_required=true 和 reason_code=time_critical_override。
难度：高级
案例研究： 标题：appointments-api 延迟增长的诊断
场景：生产环境中 appointments-api 路由的延迟（latency）急剧增长。事件分类系统应自动处理 P0 事件，但规范包含由压力负载引起的相互矛盾的要求。
挑战：规范中同时存在两条相同最大优先级的规则："30秒内升级 P0"和"任何升级前等待人工确认"。如果负责人不可用，AI 代理（Qwen Code）陷入无限循环（ESCALATE_EVENT → WAIT_APPROVAL → VALIDATE_ESCALATION），导致 stage_regress 指标和问题无法解决。
解决方案：应用可控缺陷规范方法。'priority_conflict' 缺陷在 YAML 中形式化。修复方案是引入覆盖规则'p0_time_critical_override'，在 severity=P0 和 owner_unresponsive=true 时激活。人工检查移至事后审计（human_audit_required=true）。为验证编写了严格定义允许行为走廊的 JSON Schema。
结果：重新执行 Specify → Plan → Tasks → Implement 回路时，循环被打破。延迟不再被等待审批阻塞，审计痕迹得以保留。stage_regress 指标降至 0，validation.md 中的恢复行成功通过验证。
经验教训： 规范缺陷应该是显式的（在代码和优先级中），而非隐藏在注释中。
消除冲突应该改变可执行规则（需求）本身，而不仅仅是文本说明。
任何修复都必须通过完整的 SDD 循环反向回归进行验证。
相关概念： 优先级冲突
卡死指标（stage_regress）
JSON Schema 验证
学习建议： 从最小半径开始：每次回归只引入一种缺陷类型。同时引入多种缺陷（循环+冲突）会使追踪轨迹与混乱无法区分。
在初期阶段手动在笔记本或 validation.md 中记录'ask_storm'和'stage_regress'指标，以培养对 AI 代理行为的直觉。
始终在启动分析前记录预期症状，而非事后根据结果倒推。
将争议点从自然语言转换为 Given/When/Then 格式——这将立即暴露缺失的逻辑分支。
将解决方案迁移到主项目（capstone）时，只携带缺陷类别、补丁本身和恢复行，以免污染仓库。
附加资源： Github spec kit quickstart: https://github.github.io/spec-kit/quickstart.html — Specify → Plan → Tasks → Implement 各阶段的说明。
本地示例目录 spec ci：examples/spec-ci/README.md — 基本规范网关的可运行示例。
第7部分. 否定需求：第一卷材料中系统行为约束的基本概念。
第20部分. SDD 反模式：经典规范错误目录，缺陷注入基于此构建。
总结：使用可控缺陷规范是一种强大的保护需求免受歧义影响的方法。该技术将 AI 代理的随机失败转化为可控的实验室变异。诊断的成功建立在四大支柱之上：每次迭代一个缺陷、通过 ask_storm 和 stage_regress 精确测量卡死症状、形式化冲突解决（JSON Schema + override）以及强制的完整 SDD 回路反向回归。