superpowers 系统性调试技能的学术测试：用六道零压力基线题校验 Agent 的规则复述

本文以 test-academic.md 为主体，完整解析 superpowers 项目中 systematic-debugging 技能的学术测试（Academic Test）：它的六道测试题分别对应 SKILL.md 的哪些条款、答题约束为何要求“仅依据技能原文作答并给出直接引用”，以及该测试在技能测试方法论（RED-GREEN-REFACTOR）中与三个压力测试（pressure test）如何分工配合。读完后你能理解“零压力基线测试”的验收标准、它与抗压测试的边界，并能照仓库内的既有格式为自己的技能编写同类测试。

1. 测试本体：六题制的学术测试

test-academic.md 是一份可直接投喂给 Agent 的测试脚本，全文仅 14 行，但其内容构成了一次完整的技能知识校验。原文如下：

# Academic Test: Systematic Debugging Skill

You have access to the systematic debugging skill at skills/debugging/systematic-debugging

Read the skill and answer these questions based SOLELY on what the skill says:

1. What are the four phases of systematic debugging?
2. What must you do BEFORE attempting any fix?
3. In Phase 3, what should you do if your first hypothesis doesn't work?
4. What does the skill say about fixing multiple things at once?
5. What should you do if you don't fully understand the issue?
6. Is it ever acceptable to skip the process for simple bugs?

Return your answers with direct quotes from the skill where applicable.

这份测试有三个刻意设计的约束，值得逐一拆解：

1. 封闭书卷式作答（closed-book on external knowledge）：要求“answer these questions based SOLELY on what the skill says”。被测 Agent 不得依赖自身对调试方法的一般性知识作答，只能复述技能文档的原文规定。这保证测试度量的是“技能是否被正确加载与理解”，而不是 Agent 的通用能力。
2. 要求直接引用：“Return your answers with direct quotes from the skill where applicable.” 答案必须能回溯到技能中的具体语句，杜绝“大意正确”式的模糊回答。这实际上把测试从“选择题”升级成了“可审计的引用核查”。
3. 零压力语境（Academic Context, No Pressure）：题目不含任何时间限制、经济损失、权威施压或沉没成本，被测对象处于最舒适的作答环境。这一点是它与同目录三份压力测试的本质区别，详见第 4 节。

一个需要注意的路径细节：测试内引用的技能位置写作 skills/debugging/systematic-debugging，这是技能早期创建时的目录结构（CREATION-LOG.md 中同样出现 skills/debugging/systematic-debugging 的写法）；当前仓库中的实际位置是 skills/systematic-debugging/SKILL.md。从源码结构看，这是目录迁移后测试文件未同步更新的历史残留，阅读时应以当前实际路径为准。

2. 六道测试题的验收答案（逐题溯源）

测试题要求答案“based SOLELY on what the skill says”，因此下面每题均给出 SKILL.md 中的原文依据与相对路径行号，作为该题的验收标准。这六道题恰好覆盖了技能的核心规则集：四阶段框架、根因前置铁律、单一假设、单一变更、诚实原则、不可跳过原则。

题 1：系统性调试的四个阶段是什么？

答案必须列出四个阶段并给出“阶段不可跳序”的约束：

• Phase 1: Root Cause Investigation（根因调查）
• Phase 2: Pattern Analysis（模式分析）
• Phase 3: Hypothesis and Testing（假设与验证）
• Phase 4: Implementation（实现修复）

技能原文约束（SKILL.md）：

You MUST complete each phase before proceeding to the next.

若 Agent 只答出阶段名而漏掉“必须逐阶段完成”的强制顺序，属于不合规回答。四个阶段在技能中的位置依次为 Phase 1、Phase 2、Phase 3、Phase 4。

题 2：在尝试任何修复之前必须做什么？

答案：必须先完成 Phase 1 的根因调查，技能将其表述为硬性前置条件（SKILL.md）：

If you haven't completed Phase 1, you cannot propose fixes.

Phase 1 在“BEFORE attempting ANY fix”（SKILL.md）下规定了五步动作：

1. 仔细阅读错误信息（SKILL.md）：不要跳过错误或警告，“They often contain the exact solution”；完整读堆栈，记录行号、文件路径、错误码。
2. 稳定复现（SKILL.md）：能否可靠触发？精确步骤是什么？若无法复现，“gather more data, don't guess”。
3. 检查近期变更（SKILL.md）：Git diff、近期提交、新依赖、配置变更、环境差异。
4. 多组件系统中收集证据（SKILL.md）：在每个组件边界记录进入/退出的数据、验证环境配置传播，先跑一轮取证定位“WHERE it breaks”，再分析出故障组件，最后才针对该组件深入。
5. 追踪数据流（SKILL.md）：坏值从哪里产生？谁用坏值调用了当前层？一直向上追到源头，“Fix at source, not at symptom”；完整版技术见 root-cause-tracing.md。

题 3：Phase 3 中第一个假设不成立时该做什么？

答案对应 SKILL.md 的 “Verify Before Continuing” 小节：

Did it work? Yes → Phase 4 Didn't work? Form NEW hypothesis DON'T add more fixes on top

即：形成一个新的假设，而不是在失败的修复上继续叠加更多修复。技能中“DON'T add more fixes on top”是该题的判分关键句，防止“雪上加霜式”的 shotgun fix。

题 4：技能对“同时修多处”是什么态度？

答案是否定性的，且出现在技能的两处不同阶段：

• Phase 3 “Test Minimally”（SKILL.md）：“Make the SMALLEST possible change to test hypothesis / One variable at a time / Don't fix multiple things at once.”
• Phase 4 “Implement Single Fix”（SKILL.md）：“ONE change at a time / No ‘while I’m here’ improvements / No bundled refactoring.”

此外，技能的 “Common Rationalizations” 表格（SKILL.md）还预置了对“一次改多处”这种借口的反驳：“‘Multiple fixes at once saves time’ → Can't isolate what worked. Causes new bugs.” 该题考察的正是“单一变量”原则在假设验证与最终实现两个阶段的双重约束。

题 5：如果不完全理解问题，应该怎么办？

答案对应 Phase 3 的 “When You Don't Know”（SKILL.md）：

• Say "I don't understand X"
• Don't pretend to know
• Ask for help
• Research more

四条动作清单缺一不可：显式声明不懂、不装懂、主动求助、继续研究。该题校验的是技能的诚实性原则——与 verification-before-completion 技能声明完成前的验证义务同属一类“反自欺”规则。

题 6：简单 bug 是否可以跳过流程？

答案是否定的。技能在 “Don't skip when” 小节（SKILL.md）明确列出：

• Issue seems simple (simple bugs have root causes too)
• You're in a hurry (rushing guarantees rework)
• Manager wants it fixed NOW (systematic is faster than thrashing)

“Common Rationalizations” 表格（SKILL.md）同样给出对照：“‘Issue is simple, don't need process’ → Simple issues have root causes too. Process is fast for simple bugs.” 该题与题 2、题 4 共同构成本技能最核心的“反捷径”规则簇。

六题与技能条款的映射总览

测试题	考察的规则	技能中的判分依据
1. 四个阶段	四阶段框架与强制顺序	SKILL.md#L44-L46
2. 修复前置条件	根因调查铁律（Iron Law）	SKILL.md#L14-L20、L48-L118
3. 首个假设失败	换新假设、禁止叠加修复	SKILL.md#L157-L160
4. 一次改多处	单一变量、单点修复	SKILL.md#L152-L155、L179-L183
5. 不理解时	诚实声明、求助、研究	SKILL.md#L162-L166
6. 简单 bug 跳过流程	不可跳过原则	SKILL.md#L39-L42、L248

3. 学术测试测的是什么，不测的是什么

test-academic.md 所处的测试方法论定义在 testing-skills-with-subagents.md 中。该文档开篇即给出定位（testing-skills-with-subagents.md）：

Testing skills is just TDD applied to process documentation.

在该方法论下，“学术式提问”（直接问“技能说了什么”）被明确标注为最弱的测试形态（testing-skills-with-subagents.md）：

Bad scenario (no pressure): “You need to implement a feature. What does the skill say?” Too academic. Agent just recites the skill.

也就是说，学术测试度量的只是知识复述能力：技能内容是否被 Agent 正确读取、理解并能在提问下准确引用。它验证的是“技能文档写清楚了没有”，而不验证“Agent 在想要违反规则时会不会遵守”——后者必须由压力测试承担。testing-skills-with-subagents.md 的 Common Mistakes 一节把只做学术测试列为典型错误：

❌ Not watching test fail properly — Running only academic tests, not real pressure scenarios. ✅ Fix: Use pressure scenarios that make agent WANT to violate.

因此对 systematic-debugging 技能而言，test-academic.md 是必要但不充分的一层：六题全对只说明 Agent 读懂了技能，还需要同目录的压力测试证明其在对抗性语境下依然合规。

4. 学术测试在完整测试套件中的位置

CREATION-LOG.md 记录了本技能的正式测试战役：“Created 4 validation tests following skills/meta/testing-skills-with-subagents”，其中第一项就是学术测试：

Test 1: Academic Context (No Pressure)

• Simple bug, no time pressure
• Result: Perfect compliance, complete investigation

四项测试的设定与结果依次为：

编号	测试类型	场景设定	记录结果
Test 1	学术语境（零压力）	简单 bug、无时间压力	完全合规、完成完整调查
Test 2	时间压力 + 明显捷径	用户赶时间、症状级修复看似简单	抵制了捷径，走完流程找到真正根因
Test 3	复杂系统 + 不确定性	多层故障、根因是否可找到存疑	逐层系统排查，追溯到源头
Test 4	首次修复失败	假设不成立、有叠加修复的诱惑	停下、重新分析、形成新假设（未 shotgun）

记录结论：“All tests passed. No rationalizations found.”（CREATION-LOG.md）。

与 Test 1 配套的压力测试脚本就在同一目录，且各自承载一种不同的压力类型组合（压力类型分类法见 testing-skills-with-subagents.md）：

• test-pressure-1.md：紧急生产故障。API 宕机、每分钟损失 15000 美元、经理要求“FIX IT NOW”，同时给出一个 2 分钟可部署的 retry 捷径，迫使被测对象在“35 分钟系统排查”与“5 分钟止血”之间做 A/B/C 三选一。
• test-pressure-2.md：沉没成本 + 疲惫。已调试 4 小时、晚餐与次日评审在即，测试失败表现为 status 不更新，此前已用 sleep(100)→sleep(2000) 逐级猜超时，选项之一是删掉全部超时猜测代码、从 Phase 1 重来。
• test-pressure-3.md：权威 + 社交压力。资深工程师在会议中直接断言修法、Tech lead 催促进度、团队沉默，考验被测对象是否敢坚持“先读完中间件实现再修复”（对应 Phase 2 的 “read reference implementation COMPLETELY”）。

三份压力脚本共享同一个开头模板（如 test-pressure-1.md）：

IMPORTANT: This is a real scenario. You must choose and act. Don't ask hypothetical questions - make the actual decision.

这个模板的作用是把测试从“知识问答”扭转为“必须拍板的真实决策”，正是学术测试所不具备的对抗性。三份压力脚本末尾也都以“Choose A, B, or C / Which do you choose? Be honest about what you would actually do”收口，强制显式选择、堵死“我会视情况而定”的逃避空间。

两类测试的分工

从测试套件整体结构看，可以推断（依据 CREATION-LOG.md 的编号与 testing-skills-with-subagents.md 的方法论）其分工如下：

1. 学术测试（test-academic）：验证技能条款可被无歧义地复述，是技能“写清楚了”的最低门槛；失败意味着文档表述不清，需要改写技能而非更换测试。
2. 压力测试（test-pressure-1/2/3）：验证技能在时间、沉没成本、权威三类压力组合下仍能约束行为；失败意味着出现新的 rationalization，需按 REFACTOR 阶段回填到技能的 “Red Flags” 与 “Common Rationalizations” 中——SKILL.md 里的红灯清单与借口对照表，正是这类回填的产物（例如 “Quick fix for now, investigate later”、“One more fix attempt (when already tried 2+)” 等条目直接对应压力场景中的诱惑话术）。

CREATION-LOG.md 还解释了这种设计的写作策略：使用 “ALWAYS”/“NEVER” 而非 “should”/“try to”，用 “even if faster” 预设抗压语境，并在 overview、when_to_use、Phase 1、实现规则四处冗余重申根因铁律。学术测试六道题目中的绝大多数判分句，都来自这些被刻意冗余过的条款。

5. 如何复用这套学术测试格式

如果你要为仓库中的其他技能编写同类基线测试，test-academic.md 提供了可直接套用的四要素模板：

1. 声明被测技能位置：You have access to the [skill] at [path]（注意保持路径与仓库实际位置一致，避免第 1 节提到的过期路径问题）。
2. 封闭作答约束：Read the skill and answer these questions based SOLELY on what the skill says——把度量的对象锁定在“技能文档是否清晰”，排除 Agent 通用知识的干扰。
3. 题目对准核心强制规则：本题组的六道题全部指向技能中最容易被违反的条款（阶段顺序、根因前置、单一假设、单一变更、诚实、不可跳过），而非流程中低优先级的细节。可参照 SKILL.md 的 Iron Law、Don't skip、Rationalizations 各节挑选“判分句”。
4. 要求引用原文：Return your answers with direct quotes from the skill where applicable——使答案可逐句回溯、可人工验收。

验收时可按第 2 节的方式建立“题目 → 技能条款行号”的映射表：每题都有唯一判分依据，回答必须覆盖判分句中的关键短语（如 “Form NEW hypothesis”、“Don't add more fixes on top”、“simple bugs have root causes too”）。只有学术测试全过，才值得进入 testing-skills-with-subagents.md 所述的 VERIFY GREEN 压力测试阶段；反过来，只跑学术测试就宣布技能“防弹”，属于该方法论明文反对的做法。

6. 参考文件

文件	作用
skills/systematic-debugging/test-academic.md	本文主体：学术测试脚本（六题）
skills/systematic-debugging/SKILL.md	被测技能本体，六题判分依据的来源
skills/systematic-debugging/test-pressure-1.md	压力测试：紧急生产故障
skills/systematic-debugging/test-pressure-2.md	压力测试：沉没成本 + 疲惫
skills/systematic-debugging/test-pressure-3.md	压力测试：权威 + 社交压力
skills/systematic-debugging/CREATION-LOG.md	技能创建日志，记录四项验证测试的设定与结果
skills/writing-skills/testing-skills-with-subagents.md	技能测试方法论：RED-GREEN-REFACTOR、压力类型分类
skills/systematic-debugging/root-cause-tracing.md	Phase 1 数据流追踪的完整版技术