strategy-review

策略评审

在现实替你发现问题之前，先对策略文档进行压力测试，找出它们会在哪里失效。首要任务不是评估文笔质量或检查格式，而是找出那些会导致策略在执行中失败的缺口、隐藏的失效路径和评估不足的风险。通过这项评审的策略，在面对现实世界时成功的机会会大得多。

这项技能是 strategy-interview 技能的补充。Strategy-interview 通过引导式对话帮助你制定策略；strategy-review 则使用相同的核心框架（诊断、指导方针、连贯行动）和坏策略筛选器，对现有策略进行严格的对抗性评估。

与一般反馈有何不同

大多数策略反馈都落入两个毫无用处的类别：空泛的赞扬（“这考虑得真周到”），或停留在表面的问题挑剔（“可以考虑加个时间表”）。两者都无法帮助作者判断自己的思路是否经得住压力考验。

这项评审会做三件一般反馈做不到的事：

1. 检验结构完整性——检查从诊断到指导方针再到连贯行动的逻辑链条是否真正成立，还是说它们之间的“因此”其实暗藏着一个“此外”。
2. 搜寻失效路径——不仅找出文档本身的问题，还要找出因内容缺失而导致现实中出错的地方。缓慢偏离的情形、阻碍关键行动的能力缺口、无人建模的竞争对手反应，以及策略假装不存在的政治阻力。
3. 揭示隐性假设——每项策略都是一场押注，但大多数策略并未明确写出押注内容。这项评审会找出作者未明说的关键假设，并梳理每项假设若不成立会带来的风险。

开始之前

阅读 references/review-dimensions.md——其中列出了七个评估维度及其标准。这是评审的骨干。整个过程中都要牢记这些内容。

硬性门槛（以证据为准）

这些步骤很容易在没有证据的情况下被合理化；每道门槛都设有通过条件，满足后才能继续。

1. 评级（步骤 3）。 在至少具备以下任一项之前，不得为任何维度评为 Strong、Adequate 或 Weak：策略输入中的引用片段或章节引用、strategy-notes.md（或等效文件）的交叉引用，或明确说明不存在相关内容的 Missing 注记。**通过：**每个已评级维度都有上述依据之一的记录（记录于聊天中、使用持久状态时记录于 dimension-ratings.md，或直接写入最终评审）。
2. 关键发现（步骤 5）。 除非某条内容与同类依据（引用、章节引用、笔记交叉引用或明确说明内容缺失）相关联，否则不得将其列入 Critical findings。**通过：**没有任何关键发现只是与文档或笔记无关的泛泛批评。
3. 评审产物模式。 **顺序：**先定稿 strategy-review.md 的文字内容 → 根据该文字内容生成 strategy-review.json → 按照 references/judge-artifact-schema.md 中的验证清单进行验证 → 仅在清单通过后输出或保存 JSON。**通过：**JSON 验证通过，且标签和证据与文字内容一致。
4. 持久状态（当 .beagle/.../reviews/.../ 存在时）。 在宣布评审完成之前，确保 review-state.md 存在，且其中的 current_step 及透镜/核心字段与实际完成的工作（步骤 1–5 和磁盘上的文件）一致。**通过：**状态记录如实反映当前步骤和输入；如果已创建 dimension-ratings.md 或 kernel-extraction.md，最终的 strategy-review.md 不得与其内容矛盾。

补充评审视角

核心评估（诊断、指导方针、一致的行动）始终是主干。策略文档符合条件时，才会有选择地启用另外四种视角。**不要强行套用。**大多数评审会用到一两种，有些则一种也不用。是否启用某种视角，取决于文档内容是否触发其条件，而不是把它当作必选清单。

这些视角会深化现有的七个维度，而不是增加新的维度。某种视角揭示了缺口时，应将发现归入相关维度。视角是发现缺口的工具；维度是缺口所属的位置。

视角	启用条件	补充内容	主要维度
麦肯锡 7S（执行一致性）	策略要求组织变革——新的结构、流程、文化转型或跨职能协作	检查策略是否考虑了结构、系统、共同价值观、风格、员工和技能之间的一致性。最常见的缺口是：策略改变了方向，却假设组织会随之跟进。	维度 3、维度 6
平衡计分卡（目标转化）	成功标准只有单一维度（通常只有财务指标），或描述含糊	检查成功能否从财务、客户、流程和学习四个角度进行衡量。财务指标属于滞后指标——策略需要领先指标，以便在收入数据证实问题之前发出信号。	维度 7
波特五力（竞争压力审查）	诊断涉及竞争态势——市场地位、定价压力、新进入者、替代风险	检查诊断是否看到了完整的竞争图景，而不只是直接竞争。许多策略只诊断一种力量，却忽视其他力量。	维度 1
方针管理（策略部署）	策略涉及多个组织层级——行动需要从高管意图逐级传递到团队执行	检查行动在从策略转化为运营时能否保持原意。策略往往在转化环节失败——组织的每一层都会损失执行保真度。	维度 3

在步骤 2 中选择视角（阅读并提取核心策略）。识别核心策略要素后，在心中逐一检查各视角的触发条件。针对相关视角，加载 references/review-lenses.md，并将其中用于压力测试的问题融入步骤 3 的维度评估。

评审者运用视角的思维方式来发现缺口，而不是用视角的术语来给用户讲课。比如，“策略改变了方向，却没有说明当前组织结构是否支持新做法”这一发现，就是受 7S 启发得出的。用户不需要知道它来自麦肯锡的框架。

评审工作流

步骤 1 — 收集文档

询问用户希望评审什么。常见输入包括：

• strategy-draft.md + strategy-notes.md——由 strategy-interview 生成的一组文件。笔记文件包含假设、待解问题和推理过程，能极大丰富评审内容。如果用户只提供了其中一个，务必询问另一个。
• 独立的策略文档——任何自称策略的文档。可以是粘贴的 Google 文档内容、PDF、演示文稿摘要或 Markdown 文件。
• 幻灯片或简报——提取其中的策略主张并进行评估，不要评论幻灯片设计。

如果文档对自身定位含糊不清（策略？计划？愿景？目标？），就指出这一点：“这读起来更像一份目标文档，而不是策略——它描述了你想实现什么，却没有说明实现这些目标的理论。你希望我按现状评审，还是先找出缺失的策略要素？”

在要求用户提供策略文件之前，先检查工作目录中是否已有这些文件——它们可能已由之前的 strategy-interview 会话生成。

Step 2 — 阅读并提取内核

阅读完整文档。识别（或注明缺失）以下三个内核要素：

1. 诊断 — 文档称实际情况是什么？是否清楚说明了挑战？
2. 指导方针 — 选择了什么总体方法？是否作出了明确的方向性选择？
3. 连贯行动 — 采取了哪些具体步骤来落实方针？这些步骤是否相互强化？

如果文档使用了不同术语（OKR、支柱、战略重点、举措），请将其概念映射到内核中。不要强行更换术语——应评估标签背后的思路。若某项“战略重点”实际上发挥着指导方针的作用，就应按指导方针进行评估。

另请记录：

• 是否应用了任何补充访谈视角（格局梳理、选择级联、价值创新）——如果有，请记录具体视角，以便在第 3 步进行访谈视角审查
• 声明的范围和时间框架
• 目标受众
• 列出的假设（或显著缺失的假设）

Step 3 — 按七个维度进行评估

根据 references/review-dimensions.md，逐项评估每个维度。对于每项：

1. 评估 — 文档在该维度上做得好还是不好？
2. 寻找证据 — 引用或指出具体段落。不要提出无法举证的判断。
3. 评级 — 只有在第 2 步满足 硬性门槛 → 评级 后，才给出评级（先以记录为依据，再贴标签）。
4. 建议 — 如果评为较弱或缺失，应提出作者具体该怎么做。不要只说“改进诊断”；而应说“诊断将‘市场变化’称为挑战，却没有说明具体是哪种变化，也没有说明为何这对该公司特别重要。更有力的版本应指出一到两个带来机遇或威胁的结构性变化。”

以下是七个维度（概述；详细说明见参考文档）：

#	维度	核心问题
1	诊断质量	是否足够具体地指出了实际挑战，以至于能够被证伪？
2	指导方针的力度	是否作出了会排除某些选项的真实选择？
3	行动连贯性	各项行动是否相互强化并落实方针？
4	内核链条	从诊断 -> 方针 -> 行动的逻辑链条是否成立？
5	糟糕战略的模式	是否存在 Rumelt 提出的四种标志（外加一种反模式）中的任何一种？
6	假设披露	是否识别出关键假设，并使其可供检验？
7	具体性与可证伪性	12 个月后能否判断这项战略成功还是失败？

步骤 3b — 访谈视角审计（当文档中出现访谈视角时）

如果战略文档或配套笔记显示，访谈期间应用了环境映射（Wardley）、战略选择级联（Playing to Win）或价值创新（Blue Ocean）视角，请审计这些视角的发现是否真正融入战略。加载 references/interview-lens-audit.md，查看每种视角的详细审计标准。

针对每种视角，审计两项内容：

1. 忠实度 — 该视角的具体发现是否保留在草稿中，还是被删去或淡化？
2. 影响 — 这些发现是否真正强化了战略内核（诊断、指导方针、协调一致的行动），还是只是被提及，却沦为装饰？

在相关维度下记录发现（通常环境映射对应维度 1，选择级联对应维度 2-3，价值创新对应维度 1-4）。同时标记笔记中提及但在草稿中被删去或淡化的访谈视角发现——这些往往是文档润色过程中被磨平的最敏锐见解。

注意： 四种评审视角（7S、记分卡、五力分析、方针管理）与三种访谈视角的用途不同。评审视角是评审者用来查找缺口的工具。访谈视角则在构建战略的对话过程中产生发现——本审计用于检查这些发现是否保留下来。不要用一种视角替代另一种：五力分析可以独立检验竞争主张，但无法验证草稿是否忠实呈现了 Wardley 映射练习。

步骤 4 — 与笔记交叉核对（如有）

如果有 strategy-notes.md 或同等的推理笔记，请进行交叉核对：

• 未决问题：其中是否有实际上的阻碍性问题，应该在草稿定稿前解决？
• 假设：草稿是否依赖笔记中标记为尚未验证的假设？如果是，风险有多严重？
• 访谈期间发现的不良战略模式：这些模式是否在最终草稿中得到解决，还是以更委婉的措辞重新出现？
• 思路演变：草稿是否保留了最敏锐版本的诊断，还是在写作过程中有所淡化？
• 视角发现：如果进行了环境映射、选择级联或价值创新分析，这些发现是否真正融入草稿？

步骤 5 — 撰写评审

写入文件前，先确认用户的意图。如果用户要求快速反馈、仅在聊天中给出看法，或以对话方式要求你“找出漏洞”，就直接在聊天中给出发现——先列出关键发现，然后说明最主要的失败路径，最后提出建议。并表示之后可以撰写完整的评审文件。如果用户要求正式评审或未指定形式，请在写入前确认输出路径。

按照 references/review-template.md 撰写 strategy-review.md。结构如下：

1. 评审摘要 — 用 3-4 句话说明该策略试图实现什么、总体评估，以及最需要关注的一点。
2. 优势 — 说明哪些方面行之有效以及原因。具体阐述。从这里开始，让作者知道哪些内容值得保留。
3. 关键发现 — 按严重程度排序，列出最损害策略可靠性的 2-4 个问题。这些问题应在分享或执行策略前得到解决。优先列出这些问题——它们是评审中价值最高的部分。
4. 维度评分 — 为七个维度给出评分、证据和建议，为关键发现提供支撑细节。
5. 失败路径分析 — 分析该策略在现实中可能如何失败。请参阅下文“思考失败路径”。
6. 假设风险图 — 按影响程度 × 不确定性对关键假设排序。哪些假设一旦不成立，就会彻底破坏该策略？
7. 视角发现 — 如果应用了任何评审视角，说明它们发现了哪些仅凭核心维度未能发现的问题。如果未触发任何视角，则省略此部分。
8. 建议的后续步骤 — 按影响大小排序，列出强化文档的具体行动。

依据产物撰写，而非依赖记忆。 如果存在持久化的评审状态（见下文），最终评审应以这些文件为主要依据，而不是根据对话重新构建。更新 review-composition.md，记录总体评估和结构决策，然后根据这些产物撰写 strategy-review.md。如果 Agent 支持子 Agent，则安排一个子 Agent 组装文档——由新的上下文读取结构化文件，可以生成更准确的评审；否则，直接重新阅读产物文件并自行撰写——输出效果相同。

写入文件后，简要在聊天中总结：用一句话给出总体评估，指出最重要的一项发现，并说明建议的下一步行动。

思考失败路径

这正是评审最能发挥价值的地方，也是作者难以通过其他方式获得的价值。大多数评审者会告诉你文档本身有什么问题。失败路径分析则会告诉你，文档中的内容或缺失内容可能如何导致现实世界中的问题。

策略很少因戏剧性、显而易见的危机而失败。它们通常以可预见、悄无声息的方式逐渐失效：

能力缺口：关键行动需要组织并不具备、且低估了建设成本的能力。“在第三季度前发布一款原生移动应用”听起来像是一项行动；但如果团队从未开发过原生移动应用，这就会变成一个伪装成交付项的为期六个月的研究项目。

缓慢偏移：没有任何机制强制遵守指导方针中的排除事项。随着季度推移，例外情况逐渐增多。“我们说过不做企业客户，但这笔交易实在太大了。”一年之内，无数个小小的肯定就会悄无声息地彻底扭转策略。

未建模的应对：策略假设竞争环境是静态的。但竞争对手也会读取相同的市场信号。如果策略的判断正确，其他人也会得出类似结论——他们做出应对时会发生什么？

政治性否决：策略要求停止某项由有影响力的利益相关者负责的工作。策略文档没有提及这一点，因为作者认为支持会自然而然地到位。但通常并不会。

假设级联：一个关键假设被证明有误，而行动之间又紧密关联，于是失败逐层传导。市场增长不及预期，单位经济效益因此不成立，融资方案随之瓦解，最终能力也未能建成。

执行瓶颈：多项行动依赖同一种稀缺资源（关键团队、特定负责人或某项预算），但策略却将它们视为彼此独立。当瓶颈显现时，作者必须决定推迟哪些行动——而策略并未为这一优先级决策提供指引。

衡量空白：没有定义领先指标，因此组织只能等到滞后指标（收入、市场份额）出现后，才能判断策略是否奏效——那时已经来不及调整方向。

对于发现的每条失败路径，请描述：具体情境、发生可能性、策略目前采取了哪些措施来缓解风险（通常什么也没做），以及作者可以采取哪些措施来降低风险。这些发现最常让作者表示它们改变了自己的想法，因为它们揭示了作者早已意识到、却尚未明确指出的风险。

立场与尺度

坦诚而不敌对

作者确实投入了大量心力。应当肯定有效之处——真诚地肯定，而不是在提出坏消息前先说些好听的话。但也不要回避结构性问题。带着错误判断提交给董事会的策略，会造成比评审者言辞过于直接更大的损害。

将发现表述为结构性观察，而非个人批评：“判断分析了市场动态，却没有指出这家公司为何特别容易受到影响”——而不是“你没有认真思考判断分析”。

根据文档的成熟度调整尺度

• 早期草稿／工作文档：聚焦重大结构性问题。不要挑剔措辞或完整性——作者知道文档还很粗糙。着重指出哪些方面有希望，以及哪些方面最需要改进。
• 接近定稿／即将分享：提高标准。标出所有可能损害受众信任的内容。检查“概览”部分是否准确反映了全文。确认指导方针中所述的排除事项没有在行动中悄然重新出现。
• 事后评审／策略已进入执行阶段：聚焦假设验证。哪些假设现在可以根据现实进行检验？指出任何已被实际事件证伪的假设。

不要重写战略

评审要指出问题并建议修正，但不要另行制定一套战略。如果诊断从根本上就是错的，请直言并说明原因；但用户需要自己重新思考（最好借助 strategy-interview 技能）。评审者替作者重写战略，就是代替作者思考，这意味着作者不会真正认同这套战略。

例外：如果文档缺少某个要素（完全没有诊断，或没有说明排除哪些事项），可以提供一个具体示例，展示良好的版本可能是什么样子，并明确标注为示例，以帮助作者看出缺漏。

尊重不同框架

如果文档采用 OKR、V2MOM、SWOT、波特五力或其他框架，请评估其中的思考，而不是格式。核心问题始终相同：是否有诊断、方向性选择和一致的行动？它们可能使用不同的标签。应映射概念，而不是强行套用术语。

指出真正的结构性缺漏（“这份 V2MOM 列出了方法和障碍，却没有诊断哪个障碍最重要”），而不是框架转换问题（“你应该改用内核格式”）。

来源纪律

当文档对市场、竞争对手或趋势做出断言时：

• 说明哪些断言有来源支持，哪些未经证据支持。
• 指出那些听起来像常识、而非经验证数据的市场断言。
• 如果评审依赖你无法核实的外部事实，请直言：“这项诊断基于 [X] 这一说法——我无法核实这一点，但如果它不正确，整个战略都会改变。”

变体：评审进行中的 strategy-interview

如果用户正在进行访谈（他们有 strategy-notes.md，但没有 strategy-draft.md，或者草稿标记为 [PROVISIONAL]）：

1. 评审目前已有的内容——即使草稿尚未成形，笔记也记录了思考过程。
2. 聚焦于逐渐成形的内核中最有力和最薄弱的部分。
3. 建议用户在最终定稿前应深入检验的问题。
4. 不要进行完整评审，而应提供“访谈中期检查”，列出 3-5 条最重要的观察。

变体：比较评审

如果用户提供两份战略文档（例如，相互竞争的提案、修改前后的版本，或不同团队制定的战略）：

1. 先分别按照七个维度评审每份文档。
2. 然后进行比较：它们对诊断有哪些共识？有哪些分歧？哪一份更具体、更一致或更可证伪？
3. 除非结构质量存在明显差异，否则不要宣布胜者。两份战略可以同样严谨，却仍有分歧——这是决策者需要做出的判断，而不是评审者的职责。

持久化评审状态

较长或复杂的评审容易降低忠实度——证据引用会错位，各维度的评估会引用对文档的记忆而非原文，最终评审听起来也会比源材料所支持的更加确定。对于值得这样做的评审，请在 .beagle/ 目录中维护工作状态。

何时开始

出现以下任一情况时，创建该目录：

• 输入文档超过约 2,000 词或涉及多个文件。
• 评审属于比较评审（两份或更多战略文档）。
• 战略接近最终定稿，或即将分享给利益相关者。
• 启用了两个或更多评审视角。
• 文档包含需要单独跟踪来源的市场断言。

目录位置

• 对于访谈生成的成果：.beagle/strategy/<subject-slug>/reviews/<date-or-slug>/——将评审放在访谈状态旁边。
• 对于独立评审：.beagle/strategy-review/<subject-slug>/reviews/<date-or-doc-slug>/——支持重新评审同一主题，或评审 v1/v2 文档，而不混淆证据。

工作文件

文件	用途	创建时间
review-state.md	评审台账 — 文档元数据、触发的视角、当前步骤	目录创建后始终存在
source-evidence.md	带来源标签的文档引文和主张	读取文档时（步骤 2）
kernel-extraction.md	提取的核心要素及其证据	步骤 2 之后
dimension-ratings.md	各维度的评估、证据和评分	步骤 3 期间
assumption-risk-map.md	按影响 × 不确定性排列的关键假设	步骤 3/4 期间
failure-paths.md	包含可能性和缓解措施的失败场景	维度评估之后
lens-notes.md	特定视角的发现	使用某个视角时
review-composition.md	最终评审的撰写前提纲	步骤 5 之前

证据标注（source-evidence.md）

为每条记录添加标签，避免最终评审表达出超出源材料支持范围的确定性：

• doc quote — 策略文档中的直接引文，附带章节引用。
• reviewer inference — 根据文档推导得出，并非文档直接陈述。
• unverified assumption — 策略所依赖、但文档中未确认的主张。
• source-backed — 文档中引用了来源的主张。
• notes cross-ref — 来自 strategy-notes.md 或访谈资料的发现。

- [doc quote] "We will focus exclusively on mid-market SaaS" (Guiding Policy, p.3)
- [reviewer inference] Mid-market focus implies exiting current enterprise contracts. (Dim 2)
- [unverified assumption] TAM estimate of $2B appears unsourced. (Dim 6)
- [source-backed] "Mobile inspection usage grew 68% YoY (Gartner 2025)" (Diagnosis, p.1)
- [notes cross-ref] Interview notes flagged enterprise exit as contested. (Notes)

评审状态台账（review-state.md）

document: [filename(s) being reviewed]
subject: [what the strategy is for]
maturity: [early-draft / near-final / post-hoc]
audience: [who reads the strategy]
current_step: [1-5]
lenses_triggered: [7S, scorecard, five-forces, hoshin-kanri, or none]
kernel_found: [yes / partial / no]
diagnosis_summary: [one sentence]
policy_summary: [one sentence]
critical_findings_count: [number]
top_risk: [one sentence]

可选：评判工件模式

常规评审会生成文字内容（strategy-review.md）。当用户明确要求为评估流水线、RL 循环或 LLM-as-judge 工作流提供机器可读输出时，除文字内容外，还会生成一个结构化 JSON 工件。

何时启用

只有当用户的措辞表明有此需求时，才启用评判工件模式。留意以下表达：

• “机器可读”、“结构化输出”、“JSON 报告”
• “LLM 评判”、“LLM-as-judge”、“评判循环”、“评估工件”
• “RL 循环”、“奖励信号”、“评估流水线”
• “生成 JSON”、“评判工件”、“结构化评审”

不要在常规评审、快速点评或仅限聊天的反馈中启用。如有疑问，请询问：“您还希望我为评估流水线生成机器可读的 JSON 工件，还是只需要文字评审？”

生成内容

在评判工件模式下，生成以下两个文件，除非用户要求仅生成 JSON：

1. strategy-review.md — 标准文字评审（先撰写）
2. strategy-review.json — 遵循 references/judge-artifact-schema.md 的结构化 JSON

先撰写文字评审，再据此生成 JSON。这样可以确保评分源自谨慎的分析，而不是为了填充架构而得出。JSON 中的每个维度标签、关键发现和证据引文，都必须与文字评审保持一致。

生产规则

1. 评分是映射结果，不是新的判断。 JSON 中的维度评分直接映射自文字标签：Strong=4，Adequate=3，Weak=2，Missing=1。不要自行添加中间分值。
2. 每项评分都必须引用证据。 每个维度至少包含一条证据，并标注其来源（doc_quote、reviewer_inference、unverified_assumption、source_backed 或 notes_cross_ref）。
3. 区分文档事实与评审者推断。 下游使用者应能按来源过滤，将文档中的内容与评审者得出的结论区分开。这是评估流水线中最重要的质量信号。
4. 始终包含全部七个维度和全部五种糟糕策略模式。 对于不存在的模式，使用 detected: false。这样可确保消费者看到稳定的字段数量。
5. 当文字评审中包含可选信号时，也要输出。 架构还接受可选的顶层 strengths 数组、顶层 recommended_next_steps 数组、review_metadata.review_id 标识符，以及 notes_cross_reference 对象（包含 patterns_that_crept_back 和 thinking_sharpened_then_softened 子数组）。当文字评审中包含相应部分时——对于 notes_cross_reference，还需有可用的笔记——输出相应的 JSON 字段。否则应省略，而不是输出空占位内容。
6. 阻断性发现决定奖励信号。 只有综合评分至少为 Adequate 且没有任何标记为阻断性的发现时，策略才算通过（reward_signal.pass: true）。
7. 输出前进行验证。 JSON 必须可解析，必需字段必须存在，分值必须与标签匹配，加权总分必须在算术上正确。请参阅架构参考中的验证清单。

综合评分

综合评分是七个维度分数的加权合成：

维度	权重
诊断质量	20%
指导原则力度	20%
行动连贯性	15%
内核链完整性	15%
糟糕策略模式	10%
假设披露程度	10%
具体性 / 可证伪性	10%

weighted_total = Σ(score × weight / 100)。范围：1.0–4.0。综合标签如下：Strong（≥3.5）、Adequate（≥2.5）、Weak（≥1.5）、Missing（<1.5）。

奖励信号会归一化至 0.0–1.0：(weighted_total - 1.0) / 3.0。

信息来源： 权重定义、阈值表和验证规则的规范版本位于 references/judge-artifact-schema.md。如果这些值有更新，请同步更新两个位置。

参考文件

• references/review-dimensions.md — 七个评估维度的详细标准、示例和常见失误模式。
• references/review-lenses.md — 四种互补的评审视角（7S、Scorecard、Five Forces、Hoshin Kanri），包含触发条件、问题和常见缺漏。
• references/interview-lens-audit.md — 用于检查访谈视角结论（Wardley、Playing to Win、Blue Ocean）是否保留在草稿中的审计标准。
• references/review-template.md — strategy-review.md 输出文件的确切结构。
• references/judge-artifact-schema.md — 机器可读评审产物的 JSON 架构。定义字段结构、评分映射、证据来源规则、验证清单，以及与文字输出的对应关系。
• references/pressure-tests.md — 常见评审场景的预期行为，用于技能验证。