Autoresearch Probe 深度解析：8 人格对抗式需求审讯引擎与饱和收敛机制

• AI 技能
• 人工智能
• AI 评测
• 开发工具

本文基于 plugins/autoresearch/skills/autoresearch/probe.md 命令定义，结合 guide/autoresearch-probe.md 完整指南与 SKILL.md 路由框架，全面讲解 Autoresearch 的:probe子命令——一个让 8 个对抗式人格持续拷问需求与代码库、直到约束产出达到"饱和"才停止的需求审讯引擎。读完本文，你将掌握 probe 的全部参数、九阶段轮次循环、饱和判定算法、输出产物结构以及--chain链式交接协议，并能直接把它接入probe → plan → 经典迭代循环的完整工作流。

1. 为什么需要 probe：单次提问收集不到真正的需求

传统的一次性需求采集（"你的目标是什么？"）只能收集到用户当下能说出口的内容，而非工作实际要求的内容。模糊的意图会逐层放大——每一次建立在未言明假设上的迭代，都会成倍放大后期返工的成本。

:probe的解法是：让 8 个对抗式人格（personas）同时审讯用户与代码库，一轮轮收割原子化约束（atomic constraints），直到"继续提问不再产生新约束"时机械地停止。这正是 Autoresearch 体系中唯一一个以"饱和度（saturation）"而非"迭代次数"为终止依据的子命令，被 CONTEXT.md 术语表归类为典型的饱和循环（Saturation loop）：不断迭代，直到净新增输出连续 N 轮低于阈值。

从 SKILL.md 的子命令总表可见，probe 的默认迭代上限为 15 轮，定位是"8 personas interrogate requirements until saturation"。而在编排器（Orchestrator）路由中，probe 同样承担着关键的前置角色——explore（探索）与ship-ready（上线就绪）两类目标原型的预设管线都以 probe 为第一步（见 references/orchestrator-routing.md）。

2. 命令入口与参数解析（Parse Arguments）

命令的 frontmatter 声明了完整的参数提示：

[Topic: <text>] [Scope: <glob>] [--depth shallow|standard|deep] [--personas N] [--mode interactive|autonomous] [Iterations: N] [--evals]

执行时从$ARGUMENTS中按以下规则解析：

需要注意的优先级关系：Iterations: N是硬性上限，会覆盖--depth设定的轮次上限；而Iterations: unlimited则允许 probe 一直跑到饱和为止。这一点与 README.md 中"所有循环命令默认有界、unlimited 需要显式开启"的安全不变量一致。

3. Setup：主题缺失时的四项交互引导

如果调用时没有提供Topic，probe 会通过request_user_input进行**单批（single batch）**四项提问，全部回答后跳过引导：

1. Q1 (Topic)："要审讯什么？"——自由文本描述功能、需求或设计；
2. Q2 (Scope)："哪些文件作为上下文？"——建议 glob 加上整个代码库；
3. Q3 (Depth)："要多深？"——shallow（5 轮）、standard（15 轮）、deep（30 轮）、unlimited；
4. Q4 (Mode)："如何回答人格提问？"——interactive（你来回答）或autonomous（agent 从代码推断）。

这也是 Autoresearch 所有命令的统一交互风格：不带参数直接调用命令，agent 会结合代码库给出智能默认值并补齐缺失项（见 README.md 的命令交互说明）。

4. 8 个人格：对抗式审讯的视角矩阵

probe 的核心机制是 8 个各具攻击面的人格，来自 plugins/autoresearch/skills/autoresearch/probe.md 的定义：

默认激活前 6 个；当传入--adversarial时，将Skeptic + Contradiction Finder + Edge-Case Hunter轮换到队列最前，让最具攻击性的人格先行发难。

作为补充视角，guide/autoresearch-probe.md 记录了这套人格机制的另一种对抗式命名（Skeptic、Edge-Case Hunter、Scope Sentinel、Ambiguity Detective、Contradiction Finder、Prior-Art Investigator、Success-Criteria Auditor、Constraint Excavator），并注明其默认激活为前 6 个、--adversarial将 Skeptic、Contradiction Finder、Edge-Case Hunter 前置——两处文档对"敌意三件套"的描述完全一致，可见这三个角色是 probe 对抗性的核心承重墙。

5. 九阶段轮次循环：从种子到饱和的完整流水线

Phase 1: Seed（种子播种）

• 将主题解析为初始约束集；
• 若提供了--scope，读取代码库上下文；
• 初始化约束注册表（constraint registry）（初始为空）。

Phase 2: Persona Activation（人格激活）

每轮从 8 个人格中轮转选取 2–3 个（保证遍历全部 8 个），每个人格从其视角生成3–5 个审讯问题。

Phase 3: Codebase Grounding（代码库锚定）

将问题与现有代码对照验证，并给每个问题标注：相关file:line、现有行为、缺口（gaps）。这一步是 probe 区别于普通头脑风暴的关键——问题不能脱离代码事实凭空存在。这也解释了为什么 guide/autoresearch-probe.md 的 probe vs plan 对比表中，代码库锚定（Phase 3）在 probe 中是强制环节，而在 plan 中是可选环节。

Phase 4: Answer Capture（答案采集）

• 交互模式：通过request_user_input呈现问题、收集回答；
• 自治模式：从代码库上下文推断答案，并给每条答案标注置信度high / medium / low。

Phase 5: Constraint Extraction（约束抽取）

将回答解析为原子约束，每条约束包含五个要素：id、来源人格（source persona）、描述（description）、置信度（confidence）、证据（evidence）。新约束需与注册表中已有约束去重。

术语对照：根据 CONTEXT.md，probe 产出的Constraint被定义为"从人格审讯中提取的需求。原子化、去重、带有置信度与证据。约束是产品绝对不能违反的东西"——它与 predict/security 的 Finding（描述当前状态"是什么"）有本质区别。

Phase 6: Cross-Check（交叉校验）

将新约束与既有约束交叉比对，检查冲突并标记待解决矛盾：交互模式下询问用户，自治模式下记录不确定性。

Phase 7: Saturation Check（饱和检查）

统计本轮净新增约束数（net-new constraints）。若连续3 轮净新增均低于saturation_threshold（默认 2），则判定SATURATED并退出循环。同时持续跟踪：约束总数、本轮新增数、饱和窗口计数。

Phase 8: Log（记录）

向输出追加：轮次号、激活的人格、提问数、抽取的约束、净新增数。

Eval Checkpoint（评估检查点）

若指定--evals：当当前轮次 % interval == 0时触发检查点（interval 计算见第 8 节）。

Bounded Check（有界检查）

若设置了轮次上限且当前轮次 >= max_iterations，退出循环。

6. 饱和判定：让数学决定何时该停

饱和是 probe 的机械终止条件，guide/autoresearch-probe.md 给出了完整的判定数学：

saturation_threshold = 2 （默认——每轮净新增原子数） window_K = 3 （默认——连续低于阈值的轮数） Round 1: 14 atoms Round 2: 9 atoms Round 5: 2 atoms —— 进入窗口 Round 6: 1 atom Round 7: 1 atom —— window=[2,1,1] 全部 < 阈值 → SATURATED

probe 的终止状态共有四种（另有 guide 补充的第五种）：

从 CONTEXT.md 的循环形态分类可以看出，probe 是典型的饱和循环：迭代的停止依据不是目标距离，而是"净新增输出是否持续低于阈值"——这与核心 metric 循环（按指标方向 keep/discard）是两种完全不同的收敛语义。

7. Phase 9: 综合与输出

循环结束后，probe 创建输出目录：

autoresearch/probe-{YYMMDD}-{HHMM}/

依次写入三类核心产物：

1. constraints.md—— 按类别组织的完整约束注册表；
2. conflicts.md—— 未解决的矛盾清单；
3. summary.md—— 内含一份可直接运行的 Autoresearch 配置：由约束推导出Goal、Scope、Metric、Verify，并以代码块形式内嵌。

随后打印：总轮次、发现的约束数、饱和状态、未解决的冲突数。最后输出摘要：总轮次、总约束数、净新增趋势、饱和状态、影响力最高的 Top 5 约束。

guide/autoresearch-probe.md 给出了更细的输出结构（对应probe/{YYMMDD}-{HHMM}-{slug}/），可作为工程化参考：

probe/{YYMMDD}-{HHMM}-{slug}/ ├── probe-spec.md 叙事化需求文档 ├── constraints.tsv (round, persona, atom, type, flag, source) ├── questions-asked.tsv (round, persona, question, answer, atoms_extracted) ├── contradictions.md Contradiction Finder 发现的跨回答冲突 ├── hidden-assumptions.md 悄然否定既有约束的隐藏假设 ├── autoresearch-config.yml 开箱即用的 Goal/Scope/Metric/Direction/Verify ├── summary.md 复合指标、终止原因、人格贡献度 └── handoff.json 链式交接文件（与 predict 的 handoff.json 同构）

其中autoresearch-config.yml是 probe 的主交付物，可以直接喂给下一个命令，例如：

goal: "Add OAuth2 password-grant flow to /api/v1/auth" scope: "src/api/auth/**, src/middleware/auth.ts, tests/auth/**" metric: "auth_score = passing_tests * 10 + zero_secrets_in_logs * 50" direction: "minimize" verify: "npm test -- auth/ && npm run lint" guard: "no new dependencies; no breaking changes to /api/v1/users" iterations: 25

注意这里已经包含了经典循环所需的全部五个原始要素（Goal/Scope/Metric/Direction/Verify）外加可选的 guard 与迭代数——probe 的输出本质上就是下一阶段 Autoresearch 循环的"启动弹药"。

8. Eval Checkpoint：中途评估（--evals）

当--evals存在时，probe 会在循环中途插入评估检查点：

• 间隔计算：floor(max_iterations / 3)，最小为 1；若为unlimited则固定为 10；
• 打印格式：

  --- Eval Checkpoint (rounds {X}-{Y}) --- Constraints: {total} (+{new}) | Saturation: {window_count}/3 {recommendation} ---

• 早停建议：若连续3 个以上检查点都处于饱和状态，则推荐提前停止；
• 最终汇总：循环结束时输出完整 evals 汇总到evals-summary.md。

该机制与 SKILL.md 的通用--evals标志语义一致：所有循环类子命令都支持中途检查点 + 最终汇总，且--evals-interval N可覆盖默认频率。

9. Chain Handoff：链式交接协议

probe 通过handoff.json与下游命令交接，交接内容：

• version:"2.1.0"
• source:"probe"
• timestamp：时间戳
• status：COMPLETE | SATURATED | USER_INTERRUPT | BOUNDED | ERROR
• findings：约束集
• config：推导出的 Autoresearch 配置

随后按--chain指定的顺序调用下一个目标，并将--evals标志向下游传播。

这一协议正是 guide/chains-and-combinations.md 所描述的 Autoresearch 链式设计的基石：每个命令的输出通过handoff.json直接喂给下一个命令，零复制粘贴、零上下文丢失。在 CONTEXT.md 中，Chain 被定义为"子命令之间通过 handoff.json 的顺序交接"；probe 的 handoff 结构与 predict 同构，意味着它可以无缝接入任何下游。

10. 两种模式：交互式与自治式

交互模式（默认）

每轮 probe 将最多 5 个问题批量打包为一次request_user_input调用，你每轮只需回答一次。这是人机协同需求澄清的最优形态，适合模糊需求的人工参与。

自治模式（--mode autonomous）

由 agent 从代码库 + 人格推理自答，每条原子标记confidence: low|med|high。典型适用场景：

• 继承代码库（inherited codebases）：先向人类提问之前，先从代码中反推意图；
• CI/CD 门禁：用当前代码审视过期的规格文档，发现矛盾即失败；
• 引导启动（bootstrapping）：自动生成一份供评审的初始配置。

probe vs plan：什么时候用哪个

判断准则很直接：如果你能一句话说清 Goal/Scope/Metric，用plan；如果大概率要连续三轮"对，但是……"才能说清楚，用probe。

11. 实战用法与链式模式

基础调用

# 无界——一直审讯到饱和 /autoresearch:probe # 有界——精确 10 轮 /autoresearch:probe Iterations: 10 # 内联主题 + 标志 /autoresearch:probe --depth deep --personas 8 --adversarial Topic: Migrate session storage from Redis to Postgres # 代码库锚定（强烈推荐用于继承代码） /autoresearch:probe --scope src/auth/** Topic: Tighten OAuth2 token validation # 自治模式（无用户提示） /autoresearch:probe --mode autonomous --scope src/checkout/** Topic: Identify race conditions in checkout flow # 链式——probe 合成配置后直接跑 Autoresearch 循环 /autoresearch:probe --chain plan Topic: Add rate limiting to /api/v1/*

链式模式一：probe → autoresearch（最常见）

/autoresearch:probe Topic: Reduce p95 latency on /search to under 50ms # 约 12 轮后饱和，产出 autoresearch-config.yml /autoresearch Goal: (from probe-spec.md) Scope: (from autoresearch-config.yml) Metric: (from autoresearch-config.yml)

链式模式二：probe → predict

/autoresearch:probe --chain predict Topic: Add multi-tenant isolation to the database layer

链式模式三：probe → scenario,debug,fix

/autoresearch:probe --chain scenario,debug,fix --scope src/payments/** Topic: Harden checkout against partial-failure modes

probe 揭示约束 → scenario 枚举情境 → debug 追猎缺陷 → fix 修复，逐级放大上下文（见 guide/chains-and-combinations.md 的probe → scenario,debug,fix详解）。

链式模式四：probe → improve

/autoresearch:probe --improve Topic: Improve checkout conversion for enterprise B2B SaaS

probe 的约束作为种子喂给 improve，improve 随后研究 ICP 挑战与竞品缺口、产出 PRD（improve 是终端发射器，PRD 交由外部工具消费）。

在编排器（Orchestrator）体系中，这些链式用法被进一步自动化：explore原型的预设管线为probe → scenario → plan，ship-ready为probe → debug → fix → regression → ship——probe 始终站在探索与上线管线的第一棒位置（见 references/orchestrator-routing.md）。

12. 反模式：probe 最容易踩的四个坑

这四条反模式本质上是同一件事的四个侧面：probe 的价值密度取决于问题是否逼迫出可验证的原子约束、人格是否保持对抗性、代码库是否持续提供证据。

13. 从源码视角看 probe 在体系中的位置

从仓库结构可以交叉印证 probe 的定位与实现边界：

• 命令定义：plugins/autoresearch/skills/autoresearch/probe.md 与 claude-plugin/commands/autoresearch/probe.md 是同源的两份部署副本（后者面向 Claude Code 命令目录，交互原语为AskUserQuestion；前者为通用技能形态，使用request_user_input），内容覆盖参数解析、8 人格表、Phase 1–9、饱和检查、Eval Checkpoint 与 Chain Handoff；
• 路由总表：SKILL.md 将 probe 登记为默认 15 轮的饱和循环命令，并支持全部通用标志（Iterations、--evals、--chain、--<subcommand>简写）；
• 编排路由：references/orchestrator-routing.md 将 probe 编入explore、ship-ready的预设管线首步，且预设只是先验，路由器会根据handoff.json的实际状态（errors、regression verdict、untested_gaps）动态调整后续跳数；
• 术语契约：CONTEXT.md 定义了 Constraint（"产品绝对不能违反"的原子需求）与 Saturation（净新增连续 N 轮低于阈值）的权威语义，所有子命令共享同一词汇表。

从代码结构看，probe 本身不修改代码——它的全部产出是需求侧的结构化知识（约束、矛盾、隐藏假设）与一份可执行的起始配置，真正的修改动作由链条下游的 debug/fix/经典循环完成。这与 README.md 中"Autoresearch = 约束 + 机械指标 + 自主迭代"的整体哲学一脉相承：probe 负责把"约束"这一要素从隐性变为显性、从模糊变为原子化、从口头变为可验证。

14. 小结

:probe是 Autoresearch 体系中把"模糊意图"转化为"结构化约束"的第一站：8 个对抗人格轮番审讯、代码库全程锚定、每轮抽取原子约束、连续 3 轮净新增低于阈值（默认 2）即机械饱和，最终输出约束注册表、矛盾清单与一份开箱即用的autoresearch-config.yml（Goal/Scope/Metric/Direction/Verify），并通过handoff.json无缝衔接 plan、autoresearch、scenario、debug、fix、improve 等任意下游。无论你是面对继承代码库想反推意图，还是在 CI/CD 中校验规格与代码的一致性，probe 提供的都是同一套答案：让对抗与证据代替直觉，让饱和阈值代替"差不多了"。

进一步阅读：完整使用指南 · 链式组合总览 · 编排器路由 · 领域术语表 · 入门指南

• AI 技能
• 人工智能
• AI 评测
• 开发工具