应用卷术语表

教材第二卷术语汇总表。此处重复列出定义,目的是在正文中不再出现术语歧义。如果术语已在第一卷中引入,本卷给出 production(生产环境)层面的补充说明,并指向第二卷中该术语实际工作的章节。

开始阅读第二卷前,无需通读本术语表。第一遍通读时,只需理解 capstone/ 和第一遍必读的十个产物(完整列表见 README 章节«第一遍必读产物»)即可。其余术语在你需要填写具体文件或理解可运行示例时再查阅。

阅读规则很简单:文件名或 YAML/JSON 键名可以保留为英文,但在解释时选择一个稳定的中文含义。例如,judgment.md 是争议决议文件;tribunal 是文件级仲裁,不是独立产品,也不是 Qwen Code 的内置命令。

正文里默认推荐使用的主要表述形式(英文键名仅在代码块和首次出现时的括号中给出):

• 正文使用「静默 P0」;代码、YAML/JSON 键、命令和指标签名中一律使用 silent_p0、silent_p0_cap、silent_p0_ratio;
• 正文使用「Spec CI」或「规范门禁(Spec CI)」;spec_gate 仅作为 .github/workflows/spec-ci.yml 中的 job 名称;
• 正文使用「文件级仲裁」;tribunal 仅作为 examples/tribunal/ 目录及其脚本的命名;
• 正文使用「紧急模式」;「红色按钮」作为简短别名;red_button、red_button_mttr_blindness 仅作为 YAML 中不变量(invariant)名称。

关键术语翻译对照表

第二卷正文中默认使用术语的中文等价物,并在该章节首次出现时在括号中给出英文键名,例如:「佐证标记(evidence_ref)」。本表是一份工作速查表:列出哪些术语需要翻译,哪些作为技术名称保留为英文,哪些作为中英复合术语共存。如果某章只使用中文写法,可以回到本表核对背后对应的英文键。

类别「技术名称」指的是 YAML/JSON 中的标识符、CLI/脚本名、状态名或配置键——不改动。类别「双写法术语」指的是作为流程复合标记使用的英文借词;正文引入中文等价物,但两种写法都可使用。类别「正文术语」指的是完全中文化,在正文中只保留中文形式。

正文和表格中均不翻译、原样保留的技术名称:YAML/JSON 键(immutable_principles、mutable_rules、governance_protocol、incident_type、pipeline_phase、permitted_actions、max_scope、rollback_condition、decision_hash、parent_version、change_log、audit_trace、prompt_hash、decision_source、next_guard 等)、文件名(QWEN.md、requirements.md、plan.md、validation.md、mission.md、tech-stack.md、roadmap.md、constitution.md、judgment.md、precedents.md、genealogy.md)、CLI 命令和脚本名(qwen -p、python3 scripts/...、git、npm、rg)、自定义命令名(/sdd:specify、/plan、/review)、状态(标准 / 推荐 / 前沿)、块标记([runnable]、[project script])、缩写(MCP、CI、LLM、API、KPI、MTTR、SLO、SLA、SRE)。

术语首次引入位置

下表帮助你快速定位每个术语首次获得工作定义和应用场景的章节。指标(silent_p0、audit_trace_coverage、manual_review_floor)和记忆键(shadow-scorebook.json、shadow-candidates.yaml、precedents.md、judgment.md)分开列出:指标用于度量系统,记忆键用于保存系统历史。

如果一个术语出现在多个章节,表中给出的是它首次获得工作定义和可运行场景的那一节。production 层面的补充说明和术语之间的关联见 第 12 章 和 第 13 章。

与第一卷术语表的关系

本术语表是 第一卷术语表 的补充,而非替代。SDD 的基础术语——QWEN.md、mission.md、tech-stack.md、roadmap.md、requirements.md、plan.md、validation.md、Qwen Code 技能、MCP、ACP、EARS、Given/When/Then——在第一卷中定义,此处不重复。

production 层面的补充说明叠加在这些基础术语之上:

• 第一卷的 validation.md 包含允许合并的事实;第二卷中,同一文件还补充对决中的失败用例、反 Goodhart 检查、漂移字段和追踪记录。
• 第一卷的 QWEN.md 保存 Agent 的持久上下文;在第二卷中,它成为放置影子规范拍卖所得少样本提示及其复审期限的位置。
• 第一卷的 Constitution 固定 mission.md + tech-stack.md + roadmap.md;在第二卷中,它扩展为显式的 constitution.md 章节,包含 immutable_principles、mutable_rules 和 governance_protocol。

如果本术语表中的某个术语看起来陌生,请先从第一卷查基础定义,再回到此处阅读 production 层面的补充说明。

教学项目 AgentClinic

应用卷中的 production 场景,在心智模型上部署在第一卷的教学项目 AgentClinic 之上:TypeScript、Hono、服务端 JSX、SQLite、Vitest。Python 属于第二卷的可运行示例:它是用于本地检查的小型标准库脚本,而不是主应用栈。领域实体——患者 Agent、症状、疗法、预约、评价、反馈——在 第一卷附录 B 中描述。教学代码与 production 事故的对应关系记录在 应用卷附录 A 的表格中。

形象化命名

正文中偶尔会使用形象化的命名。它们作为辅助别名使用,而不是流程的主名称。其工程等价物如下:

• 规范挖掘——从遗留代码、日志、事故和决策历史中恢复需求;「规范复活术(Spec-некромантия)」仅作为辅助别名使用。
• 投毒规范——故意带有一个可控缺陷的练习用规范。
• 验证器接种——针对规范和检查的变异测试(mutation testing)。
• 影子规范拍卖——在将非形式化启发式纳入工作上下文之前,对其评估和排序。
• 争议变更的文件级仲裁——见下文「文件级仲裁」一节;tribunal 在文件和目录名中作为示例的技术别名保留。
• 模型分层路由——在不同成本和质量的模型之间分配任务。
• 诱饵指标——容易以损害系统为代价进行优化的 KPI;工程层面的防护是成对的守护指标(guard metrics)。
• 紧急模式(red button)——在危险动作(部署、回滚、迁移或自动修复)之前的正式安全门禁;「红色按钮」是口语化别名。

Agent 角色

验证者(Verifier)——其唯一任务是查找不变量、契约和事实违反的 Agent 或会话。无权编写代码或修改产物,只能以依据为由给出 approve / reject / abstain 裁决。详见 第 4 章 和 第 8 章。

实现者(Implementor)——在规范获批后,以 auto-edit 模式执行计划的 Agent。在文件级仲裁中,对修正案在剧本中的适用性进行投票,但无权绕过验证者或 Safety 角色的裁决。

协调者(Coordinator)——根据文件级仲裁结果作出最终决策、记录先例并发布 judgment.md 的角色(人、CI 任务或外部编排器)。不与验证者、实现者和 Safety 同等投票;负责流程,而非内容。

Safety——governance_protocol 中的独立角色,负责检查影响半径、隐私、备份保护和回滚条件。在 critical_risk 时具有否决权:即使验证者和实现者均给出 approve,修正案也会被驳回。详见 第 3 章。

**模型层级(tier,local-coder / frontier-reviewer)**——分层路由中的模型级别。local-coder 是用于生成代码和草稿的廉价本地模型;frontier-reviewer 是昂贵的前沿模型,仅在关键评审、争议裁决和红色按钮验证时使用。详见 第 9 章。

预算守护者(budget keeper)——按层级监控每日 token 配额,在超出限额时阻止访问前沿模型的外部服务或脚本。Qwen Code 自身不管理预算。

规范和产物

影子规范(shadow spec)——用于不可形式化细节的规范:语气、未明文写出的优先级、未能进入主 requirements.md 的历史决策等。单独存储,在基于评分册的拍卖中胜出,但不替代主规范。详见 第 6 章。

评分册(scorebook)——影子规范的评分册:公式、权重、预算、阈值,以及每位候选的 mttr_gain、early_signal、coverage、false_escalation 组件。文件形如 .specify/memory/shadow-scorebook.json;由一次拍卖运行创建或更新。

投毒规范(poisoned spec)——故意引入一个缺陷的练习用规范:升级循环、优先级冲突或隐藏的超出范围(hidden out-of-scope)。用于训练验证者和验证器。详见 第 2 章。

隐藏的超出范围(hidden out-of-scope)——规范在形式上未禁止,但也未描述,且 Agent 倾向于「顺手」执行的动作。示例:规范要求修改告警路由,Agent 顺便修改了 SLA 策略。防护措施是显式的「超出范围」一节和 Spec CI 门禁。

Override 规则——constitution.md 中的可变规范,允许 Agent 在狭义上下文中绕过标准行为:针对特定的 incident_type、在特定的 pipeline_phase、具有有限的 max_scope 和强制的 ttl。没有这些限制时,该规则会开始与不变量竞争。

Immutable principle——constitution.md 的 immutable_principles 一节中的规则,无法被自动禁用:禁止在无备份时重启生产数据库、禁止删除备份、禁止绕过 security-critical 命名空间。仅通过团队显式公投修改,而不是通过 Agent 投票。

Mutable rule——constitution.md 的 mutable_rules 一节中的规则,必填字段为 incident_type、pipeline_phase、permitted_actions、max_scope、ttl、rollback_condition。在累积了未预见到的事故后,经公投演化。

**proposal.md**——针对 constitution.md 的修正案独立文件,按风险契约的变更处理。包含 version、parent_version、论证、对 mutable_rules 的修改、预期效果和 rollback_condition。模板见 [examples/templates/proposal.md](examples/templates/proposal.md);公投程序见 第 3 章。

**precedents.md**——文件级仲裁的先例日志:每个已解决的分歧都记为一条 case_ref、违反的规则、最终裁决和对 judgment.md 的引用。用作重复争议的最短决策路径;格式见 第 8 章。

**genealogy.md**——恢复后规范的出处(provenance):针对每条需求——来源列表、置信度(confirmed、inferred、hypothesis)和未决问题。从继承的上下文恢复规范时创建;详见 第 1 章。

规范门禁(spec gate)——一种 CI 检查,在规范未被计划覆盖、计划未被任务覆盖或任务未在 validation.md 中落实事实时阻止合并。具体示例见 spec_gate,位于 第 7 章。

期末大作业包(capstone dossier)——第 13 章 中给出的文件集合,展示对单一事故的完整 production SDD 路径:需求来源、投毒缺陷、修复、宪法、验证、裁决、预算、反 Goodhart 限制器、就绪度和反模式审计。

免疫力指标和 Goodhart 防护

免疫力指标(immunity score)——验证器的评估向量,而不是单一汇总数字。由三个分量组成:strict_reject_rate、depth_of_diagnostics、recovery_time_p95_ms。在规范变异测试中,作为验证器回路的门禁。

**strict_reject_rate**——在 Given/When/Then 的预期步骤上被严格拒绝的退化用例(变异体)占比。若该指标上升而 depth_of_diagnostics 下降,意味着验证器变严格了,但「变盲了」。

**depth_of_diagnostics**——拒绝前解释的有用深度:验证器在返回裁决前走了多少步追踪。深度 1 是「已拒绝」,深度 3+ 是「已拒绝,因为步骤 Y 中的字段 X 违反了规则 Z」。

**recovery_time_p95_ms**——规范变更后,验证器返回稳定裁决和诊断路径所需的 p95 时间(毫秒)。超过阈值(例如 1200ms)会催生绕路做法并拖慢 CI。

**silent_p0**——在无人为确认且无审计记录的情况下,通过自动化的 P0 级别事故占比。反 Goodhart 指标:如果 MTTR 下降而 silent_p0 上升,自动修复以隐藏风险为代价加速。详见 第 10 章。

**manual_review_floor**——即使自动化在形式上能处理,也必须经过人工评审的决策最低占比。防止单向优化:禁止 Agent 将人完全「挤出」回路。

**audit_trace_coverage**——已保存完整证据链的 Agent 动作占比:输入 payload、规范版本、宪法版本、投票日志、决策哈希。目标值为 100%;下降会阻止合并和红色按钮。

Anti-Goodhart(反古德哈特)——成对设计指标配合反制措施的通用方法。每个目标指标(MTTR、edge_drift)都配对一个守护指标(silent_p0、manual_review_floor、audit_trace_coverage),且 CI 门禁仅在两者同时满足时通过。

变异与压力测试

变异算子(mutation operator)——接受正确规范并精确引入一个已知类别缺陷的函数。每个变异体都分配有 mutation_id、预期 expected_failure 和 halt_before 步骤。详见 第 5 章。

Nullify——将必填字段(service_id、owner、timestamp)置零的算子。预期失败——EMPTY_REQUIRED_FIELD,在 SLA 计算之前触发。

FutureTime——将 response_timestamp 设为未来时刻或造成负响应延迟的算子。预期错误码——INVALID_TIME_ANCHOR、NEGATIVE_RESPONSE_LAG、STALE_INCIDENT_WINDOW。

EscalationCycle——在升级路由图中加入反向边的算子(在已存在 edge_oncall → traffic_sre 的情况下,加入 traffic_sre → edge_oncall)。预期失败——CYCLE_ESCALATION,诊断中包含最小环路。

RecursiveDependency——在计算字段间构造间接递归的算子:owner 依赖于 priority,priority 依赖于 blast_radius,blast_radius 又依赖 owner。预期失败——RECURSION_LIMIT,包含字段链。可运行示例 examples/stress-mutator/ 中未实现——在第 5 章中描述为未来扩展。

PriorityContradiction——一条规则将 P1 降为 P2,而另一条规则在没有 tie_breaker 的情况下将 P2 升回 P1 的算子。预期失败——PRIORITY_REVERSAL;防护来自冲突解决策略,而非路由图。

文件级仲裁

**争议变更的文件级仲裁(示例中名为 tribunal)**——对争议性修正或事故进行合议决策的程序:验证者、实现者和 Safety 按固定协议投票,协调者整理出 judgment.md。不是 Qwen Code 的内置命令;由 /review、脚本和规则的组合实现。

先例(precedent)——precedents.md 中针对重复冲突类型及其已采纳解决方案的记录。用作 governance_protocol 中的平局打破规则 latest_matching_precedent,并降低下次仲裁的成本。

**争议决议(judgment.md)**——文件级仲裁的最终产物:投票日志、decision_hash、对规范、宪法和事故的引用、活跃的 ttl 和 rollback_condition。作为不可变痕迹存放在仓库中。

谱系(genealogy)——宪法 change_log 和决议日志中的 parent_version → version 链。允许复现 Agent 在事故发生时刻是否有权执行特定动作,并在事后重算决策。

执行控制

紧急模式(red button)——在 production 中执行潜在危险动作(回滚、迁移、大规模配置更新)之前的正式门禁。在口语化文本中可以称为「红色按钮」,但在产物中应固定模式的触发条件。仅在所有反 Goodhart 指标都满足时才触发;第 10 章 中的示例为 red_button = BLOCKED (MTTR=4:50, silent_p0=18%, manual_review_rate=12%)。

影响半径(blast radius)——单个 Agent 动作的最大可能影响区域:节点数、命名空间数、用户数、数据量。在 mutable_rules 中以 max_scope 给出,并在执行前由门禁检查。

生存时间(TTL)——可变规则或临时例外(override)的生存时间。没有 ttl 时,修正案成为永久有效,并实质上变成不变量的隐藏部分。

回滚条件(rollback condition)——撤销可变规则的条件:重复事故数上升、Safety 否决、silent_p0 超过阈值。必须是可自动检查的,而非停留在文字描述层面。

证据基础

证据链(evidence chain)——绑定到 Agent 决策的结构化产物链:输入 payload、规范版本、活跃的宪法规则、仲裁投票日志、已应用变更的 diff、后置条件检查。production SDD 的最低要求。

出处(provenance)——争议需求或规则的来源:作者、来源(工单、事故、监管文件)、日期、不确定度级别。允许区分「团队这样约定」与「需求来自审计」。

重放(replay)——通过当前验证器和当前宪法重放历史事故。用作 Goodhart 指标中的门禁:新版本不应在已解析的案例上降低裁决质量。详见 第 10 章。

漂移(drift)——规范、实现与 Agent 在 production 中实际行为之间的偏差。应用卷中区分三种:spec_drift(规范过时)、code_drift(实现偏离计划)、edge_drift(验证器开始以不同方式响应边界情况)。

流程反模式

**ask_storm**——Agent 陷入反复追问细节的循环,而不是停下来。第 2 章 中的判定行:cycle_count > 0 && ask_storm >= 4 && escalation_path_resolved=false。投毒或内部矛盾规范的征兆。

**stage_regress**——在没有显式原因的情况下回退到 SDD 循环的前一阶段:implement 回到 plan,plan 回到 specify。通过将每个阶段绑定到 validation.md 中的事实,并固定阶段切换标准来治愈。

**phase_context_loss**——阶段之间的上下文丢失:specify 固定了某决策,plan 未继承,implement 按草稿行动。防护措施是显式的 @specs/... 引用,以及检查阶段间继承关系的项目级技能。

外部 SDD 框架

GitHub Spec Kit——采用标准 /constitution → /specify → /clarify → /plan → /tasks → /analyze → /implement 循环的开源框架。在第二卷中作为 Spec CI 和规范门禁的参考。

AWS Kiro——自带 SDD 模型的 IDE:规范(requirements.md + design.md + tasks.md)、steering 文件、Agent 钩子。与本教材的对应关系见 第一卷附录 A。