research

深度研究

通用深度研究，具备多源综合、置信度评分、来源支持审计和防幻觉验证功能。其设计遵循当前深度研究模式：先规划再检索，先广泛搜索再逐步聚焦，由主导 Agent 协调并行工作者，审计引用来源是否确实支持相应论点，通过扩展视角拓宽研究范围，并综合形成报告，而不是简单罗列来源。

规范术语

在计划、日志、委派任务提示词和最终报告中，必须准确使用以下规范术语。

术语	定义
query	用户的研究问题或主题；调查的基本单位
claim	需要核实的独立断言；从来源或用户输入中提取
source	信息的具体来源：URL、文档、数据库记录或 API 响应
evidence	支持或反驳某个 claim、且有来源依据的数据；始终具有出处信息
provenance	从 evidence 到 source 的链路：使用的工具、URL、访问时间戳、摘录
confidence	每个 claim 的 0.0-1.0 分值；基于 evidence 的强度和交叉验证结果
cross-validation	通过 2 个或更多独立来源核实某个 claim；防止幻觉的核心机制
triangulation	使用 3 个或更多方法各异的来源确认某项发现
contradiction	两个可信来源提出相互矛盾的 claim 时的情况；必须明确指出
synthesis	最终研究成果：不是摘要，而是结合分析对 evidence 进行全新整合
plan gate	在分诊之后、大规模检索之前生成的简洁且便于审核的研究计划
source-support audit	对每个引用进行逐项核查，确认其确实支持所附的 claim
support matrix	将每个 claim 与每个引用来源对应起来的表格，标记为 supports、partial、contradicts 或 irrelevant
citation anchor	用于将来源与 claim 关联起来的具体摘录、章节或数据行
support status	针对每个 claim/每个来源的分类：supports、partial、contradicts 或 irrelevant
effort budget	有界的搜索/委派计划，涵盖预期工作者数量、来源数量、研究深度和停止条件
journal	研究会话的 Markdown 记录，保存在 `~/.{gemini
sweep	第 1 波：使用多种工具和来源进行广泛并行搜索
deep dive	第 2 波：针对 sweep 中发现的特定线索进行后续深入调查
lead	sweep 期间发现的、有望深入调查的来源或线索
tier	复杂度分类：Quick（0-2）、Standard（3-5）、Deep（6-8）、Exhaustive（9-10）
finding	经核实的 claim，包含 evidence 链路、置信度分值和出处信息；输出的基本单位
gap	evidence 不足、相互矛盾或缺失的领域
bias marker	标注在 finding 上的明确标记，指出潜在偏差（时效性、权威性、大模型先验等）
degraded mode	研究工具不可用时的运行模式；将应用置信度上限
capability	研究能力，例如网络搜索、文档查找、信息提取或子 Agent 委派；工具名称是首选实现方式，但不作保证

分发

$ARGUMENTS	操作
问题或主题文本（含动词或 ?）	调查 — 判定复杂度，执行分波流程
模糊输入（少于 5 个词，不含动词或 ?）	受理 — 提出 2-3 个澄清问题，然后判定类型
check <claim> 或 verify <claim>	事实核查 — 使用 3 个以上搜索引擎核实声明
compare <A> vs <B> [vs <C>...]	比较 — 进行结构化比较，并输出决策矩阵
survey <field or topic>	综述 — 绘制领域全景图，提供注释书目
track <topic>	追踪 — 加载先前的日志，搜索上次会话后的最新进展
resume [number or keyword]	继续 — 恢复已保存的研究会话
list [active, domain, tier]	列表 — 显示日志元数据表
archive	归档 — 移动超过 90 天的日志
delete <N>	删除 — 在确认后删除日志 N
export [N]	导出 — 为日志 N 生成 HTML 仪表板（默认为当前日志）
空	示例库 — 展示主题示例 +“随便问我”提示

自动检测启发式规则

如果没有匹配任何模式关键词：

1. 以 ? 结尾，或以疑问词（who/what/when/where/why/how/is/are/can/does/should/will）开头 → 调查
2. 在名词短语之间包含 vs、versus、compared to 或 or → 比较
3. 陈述句形式，包含事实性声明，不含疑问句式 → 事实核查
4. 宽泛的领域名称，不含具体问题 → 提问：“要调查一个具体问题，还是综述整个领域？”
5. 模糊不清 → 提问：“你想让我调查这个问题、核实这项声明，还是综述这个领域？”

计划关卡

对于标准、深度和穷尽级研究，在进行大量检索之前，先生成分诊包：

1. 重述研究问题、受众、假设、限制，以及高风险或私有来源风险。
2. 展示复杂度评分、层级、模式、来源难度、核实复杂度和工作量预算。
3. 列出子问题、来源类别、计划中的工作通道、检索/提取能力，以及降级模式限制。
4. 说明来源支持审查策略，包括如何检查引文锚点和支持状态。
5. 说明是立即继续执行，还是暂停以供用户审核。

暂停条件优先于继续条件。如果主题风险较高、分诊后仍有歧义、要求访问私有或需凭据的来源，或用户明确要求审核计划，则暂停并等待用户输入。如果暂停是由于用户对范围或受众的关键不确定性，应遵循 instructions/global.md 中的深度路由，并在大量检索前调用 /grill-me。事实或证据缺口应留在研究计划关卡处理，而不是交由 grill-me。在非交互式运行环境中，对于这些暂停情形，应输出计划关卡及阻碍因素，并在大量检索前停止。只有在问题清晰、无敏感性且不存在暂停条件时，才无需等待即可继续。快速级可跳过正式关卡，但答案中必须附上一段简短的方法说明。

示例库（参数为空）

展示涵盖多个领域的研究示例：

#	领域	示例	可能的层级
1	技术	“当前 LLM Agent 架构有哪些最佳实践？”	深度
2	学术	“间歇性禁食对延长寿命的证据现状如何？”	标准
3	市场	“向量数据库的竞争格局有何异同？”	深度
4	事实核查	“90% 的初创公司会在第一年内倒闭，这是真的吗？”	标准
5	架构	“什么时候应该选择事件溯源，而不是 CRUD？”	标准
6	趋势	“2025-2026 年有哪些新兴编程语言获得关注？”	标准

选择一个编号、粘贴你自己的问题，或输入 guide me。

技能识别

开始研究前，先检查是否有其他技能更适合：

信号	转向
代码审查、PR 审查、差异分析	建议使用 /review
涉及对手的战略决策、博弈论	建议使用 /wargame
多视角专家辩论	建议使用 /host-panel
提示词优化、针对特定模型的提示词编写	建议使用 /prompt-engineer

如果用户确认需要一般性研究，则继续。

对于仓库自带的 CLI 技能优先路由（/ffmpeg、/yt-dlp、/trafilatura、/pentest），请参阅 references/source-selection.md 中的 Repo CLI skills 表格。

复杂度分类

从 5 个维度为查询评分（每项 0-2 分，总分 0-10）：

维度	0	1	2
范围广度	单一事实／定义	多面向，涉及 2-3 个领域	跨学科，涉及 4 个以上领域
来源难度	顶部搜索结果足够	需要专业数据库或多种来源类型	付费墙、来源分散或相互矛盾
时效敏感度	稳定／历史内容	不断发展的领域（以月为单位变化）	快速变化（以天／周为单位），存在争议
核实复杂度	易于核实（官方文档）	需要 2-3 个独立来源	主张有争议、专家意见不一、没有共识
综合要求	答案是事实或列表	比较／对照不同观点	整合相互冲突的观点，形成新见解

总分	级别	策略
0-2	快速	内联回答，搜索 1-2 次，直接完成
3-5	标准	启动子 Agent 工作波，使用 3-5 个并行搜索器，交付报告
6-8	深入	创建 Agent 团队（TeamCreate），安排 3-5 名队员，进行交互式协作
9-10	详尽	创建 Agent 团队，安排 4-6 名队员并启动嵌套子 Agent 工作波，进行交互式协作

对于标准、深入和详尽级别的工作，须通过 Plan Gate 呈现评分。用户可以使用 --depth <tier> 覆盖级别。

扩展策略

根据查询复杂度和可用的编排能力调整工作规模：

范围	策略	委派
快速（0-2）	搜索 1-2 次后内联回答	不使用子 Agent
标准（3-5）	并行广泛探索 2-5 个子问题	使用可用的子 Agent 原语；否则分批顺序执行
深入（6-8）	由主 Agent 主导的团队工作流，并拓展不同视角	如有团队／子 Agent 原语则使用；否则通过有限的串行工作波执行
详尽（9-10）	深入工作流，并增加对抗性分析和嵌套工作波	如支持则进行嵌套委派；否则明确说明处理能力受限

能力解析： 将指定工具和编排 API 视为首选能力。Claude Code 可以使用 Task／TeamCreate；Codex 可以使用动态子 Agent 或并行工具调用；其他 Agent 可以使用其原生委派能力，或按顺序运行工作波流水线。如果没有等效的委派方式，则采用降级编排：保持工作波顺序、缩小范围，并在方法说明中报告限制。仅当来源或检索能力不可用时，才根据 references/source-selection.md 限制置信度上限。

工作量预算： 在检索之前，为每次标准级及以上的运行设定工作量上限。说明目标工作者数量、预期来源数量、搜索深度、提取深度和停止条件。先广后窄：第 1 波最大限度覆盖来源和视角；第 2 波只对高价值线索深入研究；第 3 波将核实预算用于可能通过综合分析保留下来的主张。

工作波流水线

所有非快速级别的研究都遵循这套 5 波流水线。快速级别则将第 0、1 和 4 波合并后内联执行。

第 0 波：分诊（始终在行内执行，不并行）

1. 运行 !uv run python scripts/research-scanner.py "$ARGUMENTS" 进行确定性预扫描
2. 将查询拆分为 2-5 个子问题
3. 根据 5 维评分标准评估复杂度
4. 检查工具可用性——探测关键的检索、提取和委派能力；根据 references/source-selection.md 设置降级模式标记和置信度上限
5. 根据领域信号选择工具——阅读 references/source-selection.md
6. 检查是否存在已有日志——如果是 track 或 resume，则加载先前状态
7. 运行计划关卡——展示：复杂度评分、子问题、来源类别、工作者通道、支持审计策略、工作量预算、预计层级，以及是否立即继续执行或暂停。用户可以覆盖此设置。

第 1 波：广泛扫描（并行）

按层级调整规模：

快速（行内）： 依次调用 1-2 个工具。不使用子 Agent。

标准（子 Agent 波次）： 使用平台可用的委派原语，分派 3-5 个并行子 Agent：

Subagent A → brave-search + duckduckgo-search for sub-question 1
Subagent B → exa + g-search for sub-question 2
Subagent C → context7 / deepwiki / arxiv / semantic-scholar for technical specifics
Subagent D → wikipedia / wikidata for factual grounding
[Subagent E → PubMed / openalex if academic domain detected]

深入（Agent 团队）： 使用平台可用的团队原语创建研究团队：

Lead: triage (Wave 0), orchestrate, judge reconcile (Wave 3), synthesize (Wave 4)
  |-- web-researcher:       brave-search, duckduckgo-search, ddgs, exa, g-search
  |-- tech-researcher:      context7, deepwiki, arxiv, semantic-scholar, package-version-check-mcp
  |-- content-extractor:    fetcher, trafilatura, docling, wikipedia, wayback
  |-- [academic-researcher: arxiv, semantic-scholar, openalex, crossref, PubMed]
  |-- [adversarial-reviewer: devil's advocate — counter-search all emerging findings]

如果领域信号包含学术/科学内容，则启动 academic-researcher。如果为穷尽级，或验证复杂度 >= 2，则启动 adversarial-reviewer。

穷尽： 深入团队 + 每位队友在支持的情况下在内部运行嵌套子 Agent 波次；否则使用串行批次，并将运行标记为“编排降级”。

每个子 Agent/队友返回结构化发现：

{
  "sub_question": "...",
  "findings": [{
    "claim": "...",
    "confidence": 0.6,
    "evidence": [{"tool": "brave-search", "url": "https://...", "timestamp": "2026-04-24T12:00:00Z", "excerpt": "..."}],
    "cross_validation": "unknown",
    "source_support": [{"url": "https://...", "support_status": "supports|partial|contradicts|irrelevant", "citation_anchor": "...", "support_note": "..."}],
    "bias_markers": [],
    "gaps": []
  }],
  "leads": ["url1", "url2"],
  "gaps": ["could not find data on X"]
}

第 1.5 波：视角扩展（仅限深入/穷尽级）

采用 STORM 风格的视角引导式对话。启动 2-4 个视角子 Agent：

视角	关注点	提问方式
怀疑者	可能有哪些错误？遗漏了什么？	“什么证据可以推翻这一结论？”
领域专家	技术深度、细节差异、边缘情况	“从业者实际会遇到什么？”
实践者	现实应用、权衡取舍	“实际构建时，什么最重要？”
理论家	第一性原理、抽象概念、框架	“什么底层模型可以解释这一点？”

每个视角 Agent 审查第 1 波的发现，并从其视角提出 2-3 个额外子问题。这些子问题将纳入第 2 波。

第 2 波：深入研究（并行、定向）

1. 按潜在价值对第 1 波的线索排序（引用频率、来源权威性、相关性）
2. 分派深度阅读子 Agent——优先在 shell harness 上使用 /trafilatura，否则使用 fetcher/trafilatura MCP/docling 从优先线索中提取完整内容
3. 沿引用链追踪——如果来源引用了其他来源，则获取原始来源
4. 填补空白——针对第 1 波发现的每个空白，分派定向搜索
5. 为每项有来源支持的发现构建初步的论点到来源支持表格行
6. 使用思考类 MCP：
   • cascade-thinking：对复杂发现进行多视角分析
   • structured-thinking：追踪证据链和矛盾
   • think-strategies：对复杂问题进行拆解（仅限标准级及以上）

第 3 轮：交叉验证与来源支持审查（并行）

反幻觉环节。阅读 references/evidence-chain.md、references/confidence-rubric.md 和 references/self-verification.md。

对于第 1—2 轮后保留的每项主张：

1. 独立性检查 — 支持来源是否真正独立？相互引用的来源不算独立。
2. 反向搜索 — 使用不同的搜索引擎，明确搜索反对每项主要主张的证据
3. 时效性检查 — 确认来源是否为最新（时效性较强的主题若来源超过 1 年，则标记出来）
4. 矛盾扫描 — 阅读 references/contradiction-protocol.md，识别并分类分歧
5. 来源支持审查 — 将每项主张与来源的对应关系归类为 supports、partial、contradicts 或 irrelevant
6. 引文锚点验证 — 尽可能获取引用的 URL，并确认所引段落支持的是确切主张，而不只是大致相关的主题
7. 置信度评分 — 按照 references/confidence-rubric.md 为每项主张评定 0.0-1.0 的分数；若支持不完整、仅有单一来源、存在矛盾或证据质量下降，则下调置信度上限
8. 偏见扫描 — 按照 references/bias-detection.md，对照 10 类偏见（7 类核心偏见 + 3 类 LLM 特有偏见）检查每项发现

自我验证（保留 3 项或更多发现时）： 按照 references/self-verification.md 启动一名唱反调的子 Agent：

尝试逐项推翻每项发现。搜索反驳论据。检查证据是否过时。验证主张是否确实能从引用的证据中推出。标记 LLM 编造的内容。

调整置信度：经检验仍成立 +0.05；被削弱 -0.10；被推翻则设为 0.0。 调整受硬性上限约束——即使检验后仍成立，单一来源的主张置信度上限仍为 0.60。

第 4 轮：综合（始终由主 Agent 内联完成）

生成最终研究成果。阅读 references/output-formats.md 以查看模板。

综合不是摘要，必须：

1. 直接作答 — 清楚回答用户的问题
2. 梳理证据 — 列出所有经过验证的发现及其置信度和引文
3. 展示来源支持情况 — 总结引文锚点状态，以及缺少支持或仅获部分支持的陈述
4. 呈现矛盾 — 指出来源意见不一之处，并分析原因
5. 展示置信度全貌 — 说明哪些内容有充分把握、哪些不确定、哪些未知
6. 审查偏见 — 列出研究中发现的偏见
7. 指出证据缺口 — 说明缺少哪些证据，以及进一步研究可带来的帮助
8. 提炼要点 — 列出 3-7 项编号的关键发现
9. 引用来源 — 提供带有来源溯源信息的完整参考书目

输出格式根据模式调整：

• Investigate → Research Brief（Standard）或 Deep Report（Deep/Exhaustive）
• Fact-check → 带有结论和证据的 Quick Answer
• Compare → Decision Matrix
• Survey → Annotated Bibliography
• 用户可通过 --format brief|deep|bib|matrix 覆盖
• 仅当图表、矩阵或仪表板能阐明数值、比较、时间或来源覆盖情况时，才添加相应内容。

置信度评分

分数	依据
0.9-1.0	官方文档与 2 个独立来源意见一致，且不存在矛盾
0.7-0.8	2 个或更多独立来源意见一致，仅有细微限定
0.5-0.6	单一权威来源，或 2 个来源仅部分一致
0.3-0.4	单一非权威来源，或证据相互冲突
0.2-0.3	多个非权威来源仅部分一致，或单一来源存在重要保留条件
0.1-0.2	仅有 LLM 推理，未找到外部证据
0.0	证据明确反驳该主张

硬性规则：

• 除非有 2 个或更多独立来源支持，否则不得报告置信度 >= 0.7 的主张
• 无论来源权威性如何，单一来源主张的置信度上限均为 0.6
• 降级模式（所有研究工具均不可用）：置信度最高为 0.4，所有发现均标注为“未经验证”

合并置信度（适用于多个来源支持的主张）： c_merged = 1 - (1-c1)(1-c2)...(1-cN)，最高不超过 0.99

证据链结构

每项发现均包含以下结构：

FINDING RR-{seq:03d}: [claim statement]
  CONFIDENCE: [0.0-1.0]
  EVIDENCE:
    1. [source_tool] [url] [access_timestamp] — [relevant excerpt, max 100 words]
    2. [source_tool] [url] [access_timestamp] — [relevant excerpt, max 100 words]
  CROSS-VALIDATION: [agrees|contradicts|partial] across [N] independent sources
  SOURCE SUPPORT SUMMARY: [verified|partial|unsupported|contradicted] derived from per-source `support_status` rows
  BIAS MARKERS: [none | list of detected biases with category]
  GAPS: [none | what additional evidence would strengthen this finding]

使用 !uv run python scripts/finding-formatter.py --format markdown 进行规范化。

来源选择

在第 0 波期间阅读 references/source-selection.md，了解完整的工具与领域映射。摘要如下：

领域信号	主要工具	次要工具
库/API 文档	llms.txt/llms-full.txt、context7、deepwiki、package-version-check-mcp	brave-search
学术/科学	arxiv、semantic-scholar、PubMed、openalex	crossref、brave-search
时事/趋势	brave-search、exa、duckduckgo-search、ddgs、g-search	fetcher、trafilatura
GitHub 仓库/开源软件	deepwiki、repomix	brave-search
通用知识	wikipedia、wikidata、brave-search	fetcher
历史内容	wayback、brave-search	fetcher
事实核查	条件允许时必须使用 3 个以上搜索引擎	对结构化声明使用 wikidata
PDF/文档分析	docling	trafilatura

多引擎协议： 对于任何需要核实的声明，至少使用 2 个不同的搜索引擎或独立来源系列。事实核查模式在条件允许时要求使用 3 个以上搜索引擎。如果可用的搜索引擎较少，请报告检索能力降级，使用 references/source-selection.md 中的备用置信度上限，并说明缺失的检索能力。

渐进式披露

仅加载下一步所需的参考资料：

1. 从此文件开始，了解路由、分类和波次顺序。
2. 仅在第 0 波期间加载 references/source-selection.md。
3. 仅在第 3 波期间按需加载验证参考资料：证据链、置信度、矛盾、自我核验和偏见文件。
4. 仅在生成最终输出或导出内容时加载 references/output-formats.md 或 references/dashboard-schema.md。
5. 切勿预加载所有参考资料；应总结工具限制，而不是用未使用的映射填充上下文。

偏见检测

对照 10 类偏见检查每项发现。完整的检测信号和缓解策略请阅读 references/bias-detection.md。

偏见	检测信号	缓解措施
大模型先验	符合常见训练模式，缺少新证据	标记；要求新来源确认
时效性偏见	过度重视近期结果，忽视历史背景	搜索历史视角
权威偏见	不加批判地接受知名来源	对权威声明进行交叉验证
确认偏见	构造查询以确认初始假设	使用中立查询；搜索反方观点
幸存者偏差	只找到成功案例	搜索失败案例/反例
选择偏差	搜索引擎信息茧房、仅使用英语	使用多个引擎；注明覆盖范围的限制
锚定效应	第一来源对解读产生不成比例的影响	单独记录第一来源；寻找对照来源

状态管理

• 日志路径： ~/.{gemini|copilot|codex|claude}/research/
• 归档路径： ~/.{gemini|copilot|codex|claude}/research/archive/
• 文件名约定： {YYYY-MM-DD}-{domain}-{slug}.md
  • {domain}：tech、academic、market、policy、factcheck、compare、survey、track、general
  • {slug}：3-5 个词的语义摘要，使用 kebab-case
  • 冲突时：追加 -v2、-v3
• 格式： YAML frontmatter + Markdown 正文 + `` 块

保存协议：

• 快速：在结束时保存一次，使用 status: Complete
• 标准/深度/详尽：第 1 轮后保存，使用 status: In Progress；每轮后更新，并在综合分析后完成定稿

恢复协议：

1. resume（无参数）：查找 status: In Progress 的日志。找到一个 → 自动恢复；找到多个 → 显示列表。
2. resume N：恢复 list 输出中的第 N 个日志（按时间倒序）。
3. resume keyword：在 frontmatter 的 query 和 domain_tags 中搜索匹配项。

所有日志操作均使用 !uv run python scripts/journal-store.py。

状态快照（每轮保存后追加）：

会话内命令（深度/详尽）

可在活跃的研究会话期间使用：

命令	作用
drill <finding #>	使用更多来源深入研究特定发现
pivot <new angle>	将研究转向新的子问题
counter <finding #>	明确搜索反驳某项发现的证据
export	生成 HTML 仪表板
status	显示当前研究状态，但不推进研究
sources	列出截至目前查阅的所有来源
confidence	显示各项发现的置信度分布
gaps	列出已识别的知识空白
?	显示命令菜单

完整协议请阅读 references/session-commands.md。

参考文件索引

文件	内容	阅读时机
references/source-selection.md	工具与领域的映射、多引擎协议、降级模式	第 0 轮（选择工具）
references/confidence-rubric.md	评分标准、交叉验证规则、独立性检查	第 3 轮（分配置信度）
references/evidence-chain.md	发现模板、溯源格式、引用标准	任意轮（整理证据）
references/bias-detection.md	10 种偏差类别（7 种核心类别 + 3 种 LLM 特有类别）、检测信号、缓解策略	第 3 轮（偏差审查）
references/contradiction-protocol.md	4 种矛盾类型、解决框架	第 3 轮（检测矛盾）
references/self-verification.md	反方论证协议、幻觉检测	第 3 轮（自我验证）
references/output-formats.md	全部 5 种输出格式的模板	第 4 轮（格式化输出）
references/team-templates.md	团队类型、子 Agent 提示词、视角 Agent	第 0 轮（设计团队）
references/session-commands.md	会话内命令协议	用户发出会话内命令时
references/dashboard-schema.md	HTML 仪表板的 JSON 数据契约	执行 export 命令时

加载规则： 按照“阅读时机”列的说明，每次只加载一个参考文件。不要预先加载。

停止钩子

运行时钩子处于激活状态时，必须执行研究模式停止验证。research_hook.py research-stop-verifier 会委托给 verify.py stop，后者会检查会话期间 skills/research/ 下受跟踪的文件是否在 git 中保持干净状态。源文件写入由 research-readonly-write-guard 单独阻止。如果停止验证失败，请报告确切原因，且不要声称运行已完成。

验证契约

在声明更改已完成之前，请从仓库根目录运行：

(cd skills/research && uv run python scripts/check.py)
uv run pytest tests/test_wagents_hook.py -q -k "readonly_guard or stop_verifier or shell_write_guard"

完成标准：

1. scripts/check.py 在运行当前检出版本中可用的技能验证、评估验证、软件包试运行和仓库审计检查后，以状态码 0 退出。
2. 随附的验证器报告技能元数据和评估清单有效。
3. 随附的软件包试运行报告 portable: true。
4. 研究钩子的冒烟测试通过只读保护和停止验证器行为测试。
5. 可移植软件包检查中不得包含绝对路径，也不得要求使用仓库控制平面 CLI。

关键规则

1. 没有 2 个或更多独立来源支持时，任何声明的置信度不得达到 0.7 或更高——仅有单一来源时，置信度上限为 0.6
2. 绝不捏造引文——如果无法核实 URL、作者、标题或日期，应使用模糊的归属表述（例如“这一研究传统中的一项研究”），而不是编造具体信息
3. 始终明确指出矛盾——绝不默默消解分歧；应提供双方观点及证据
4. 开展实质性研究前，始终先进行分流评分——用户必须能看到并可更改复杂度等级；仅当计划门要求批准或澄清时才等待
5. 在深度/穷尽模式下，每轮研究后都要保存日志——以便在中断后恢复
6. 标准/深度/穷尽等级绝不能跳过第 3 轮（交叉验证和来源支持审计）——这是防止幻觉的机制
7. 条件允许时，事实核查必须使用多引擎搜索——至少使用 3 种不同的搜索工具（例如 brave-search + duckduckgo-search + exa）；如果可用工具少于 3 种，则进入降级模式并降低置信度上限
8. 每次并行分派后都要应用核算规则——在进入下一轮之前，已分派数量 N 必须全部核算完毕
9. 所有输出都要区分事实与解读——事实性声明必须附有证据；解读性声明必须明确标注为分析
10. 标记所有基于大模型先验的发现——与常见训练数据相符但缺乏新证据的声明必须加上偏见标记
11. 降级模式下的置信度上限为 0.4——当所有研究工具都不可用时，将所有发现标记为“未经验证——基于训练知识”
12. 一次只加载一个参考文件——不要将所有参考文件预先加载到上下文中
13. 跟踪模式必须在搜索前加载先前的日志——避免重复研究已知内容
14. 综合分析不等于总结——必须将发现整合为新的分析，识别来源之间的模式，并揭示任何单一来源都未呈现的新兴见解
15. PreToolUse 写入保护不可妥协——research_hook.py research-readonly-write-guard 会阻止写入源文件；日志应保存在 ~/.{gemini|copilot|codex|claude}/research/ 下
16. 停止钩子必须通过——research_hook.py research-stop-verifier 会调用 verify.py stop，并确认受 Git 跟踪的 skills/research/ 文件保持干净
17. 综合分析前先规范化旧版发现——必须将顶层的 source_url、source_tool 和 confidence_raw 转换为规范的 evidence[] + confidence 结构
18. 引文本身不能作为证据——引用的来源文本必须支持确切的陈述；不支持陈述或仅与主题相关的引文会降低置信度，并记录在来源支持审计中