workflow_iterative_expanding_research

道-方法 · 道层 skill 全文

本页是 <code>rules/skills/drafts/workflow_iterative_expanding_research.md</code> 的逐字投影（仅隐私清洗，零改写）。

Skill: 迭代扩张调研（Iterative Expanding Research）

元数据

• 类型: Workflow
• 适用场景: 对某主题已完成首轮调研，需要后续轮次发现不同、更深、更广的内容
• 前置依赖: workflow_deep_research_survey.md（单轮调研执行）
• 输出位置: contexts/survey_sessions/
• 创建日期: 2026-04-06
• 状态: Draft

解决什么问题

workflow_deep_research_survey 是单轮调研的完整流程：扫描、并行深入、交叉验证、出报告。但现实中，很多主题需要多轮调研。现有模式下，第二轮调研容易重复第一轮已有的内容，或者只是在相同方向上"搜更多"而非"搜不同"。

本 skill 提供的是 Round N 到 Round N+1 的过渡协议。核心问题：如何结构性地保证每轮调研都在扩张认知边界，而非在已知区域打转。

核心模型：覆盖矩阵 + 空白格驱动

每轮调研结束时，维护一张覆盖矩阵。行是子主题，列是信息源类型和视角。空白格就是下一轮的起点。

                  │ 官方文档 │ 社区讨论 │ GitHub │ 学术论文 │ 跨域类比 │ 反面证据 │
─────────────────┼─────────┼─────────┼────────┼─────────┼─────────┼─────────┤
子主题 A          │   R1    │   R1    │        │         │         │   R1    │
子主题 B          │   R1    │         │   R1   │         │         │         │
子主题 C（新发现）│         │         │        │         │         │         │
边界条件          │         │         │   R1   │         │         │         │
替代方案          │         │   R1    │        │         │         │         │

R1 = 第一轮已覆盖。空白格 = 下一轮可探索。后续轮次的 agent 只需要看这张表就知道往哪走。

六种扩张策略

每轮调研结束后，从以下六个方向中选择 2-3 个作为下一轮的主轴。不是全部执行，而是根据覆盖矩阵的空白分布来选。

S1. 信息源轮换（Source Rotation）

上一轮主要来源是什么？下一轮刻意避开，换一类来源。

S2. 视角翻转（Perspective Shift）

同一个主题，换一个提问角度。

• Round 1 问"X 是什么" → Round 2 问"谁在批评 X，为什么"
• Round 1 问"X 怎么用" → Round 2 问"X 用错了会怎样"
• Round 1 问"X vs Y" → Round 2 问"从 X 迁移到 Y 的人踩了什么坑"
• Round 1 从使用者视角 → Round 2 从维护者/贡献者视角
• Round 1 关注功能 → Round 2 关注成本、运维、扩展性

S3. 时间轴扩展（Temporal Expansion）

在时间维度上找变化。

• 追溯 X 的前身或早期版本（"X 之前大家用什么"）
• 追踪 X 的趋势（"X 是在增长还是在被替代"）
• 对比不同时间点的社区态度（2023 年的 HN 讨论 vs 2026 年）
• 寻找 X 的路线图或即将到来的变化

S4. 跨域同构检索（Cross-Domain Isomorphism）

这是用户的核心思维模式：如果 X 在领域 A 解决了某个结构性问题，领域 B 是否有类似的结构性问题？

操作方式：

1. 从当前调研中提取核心抽象（"X 本质上是一个 [抽象描述] 的解决方案"）
2. 搜索这个抽象描述在其他领域的实例
3. 检查那些领域的解决方案是否能反哺当前问题

例子：

• "git worktree 本质是工作空间隔离" → 搜索 "workspace isolation" 在 Docker/VM/IDE/浏览器 profile 中的实现
• "研究扩张本质是信息检索多样性" → 搜索 推荐系统的 diversity-aware retrieval 算法

S5. 深度钻取（Depth Drilling）

从上一轮中挑出置信度最低或争议最大的发现，把它变成下一轮的核心主题。

选取标准：

• 只有单一来源支撑的 claim（脆弱）
• 多个来源互相矛盾的 claim（未解决）
• 标注了"仅 vendor source，未独立验证"的 claim
• 用户读后追问最多的部分

S6. 邻域扩展（Adjacency Expansion）

从当前主题向相邻但未覆盖的主题移动。

操作方式：

1. 列出当前主题的上游依赖和下游消费者
2. 列出与当前主题经常并提的其他主题
3. 从中选取关联度最高但当前报告中零覆盖的 1-2 个主题

例子：git 版本控制 → Docker 隔离 → tmux 终端管理 → sandbox 沙箱。每一步都是邻域扩展。

轮次过渡协议

Round N 结束时

在最终报告末尾追加一个 ## 扩张建议 章节，内容包括：

1. 覆盖矩阵快照（上面的表格格式）
2. 空白格分析：哪些格子是空的，哪些最值得填
3. 推荐的 2-3 个扩张策略（从 S1-S6 中选）
4. 具体的搜索方向：不是"进一步调研"这种泛指，而是具体到搜索关键词、目标信息源、期望发现什么

Round N+1 开始时

1. 必须先读 Round N 的完整报告（不只是扩张建议，要理解已有内容的全貌）
2. 检查覆盖矩阵，确认目标是填空白格而非重复已有格
3. 设定本轮的新颖性约束：任何与 Round N 重复的内容不计入本轮产出
4. 按 deep_research_survey workflow 执行（Phase 1-4），但 sub-agent 的 prompt 必须包含：
• Round N 的核心结论（1 段摘要）
• 本轮的扩张方向
• 禁止搜索的关键词或来源（已经覆盖过的）

报告命名

<主题>_<YYYYMMDD>_round<N>_<skill后缀>.md

例如：

• git_infra_20260406_round1_deep_research.md
• git_infra_20260408_round2_deep_research.md

Round 1 可以省略 _round1，从 Round 2 开始必须标注。

收敛判断

不是"搜完了就停"，而是基于以下信号判断是否需要继续：

可以停止的信号：

• 覆盖矩阵的关键格子（用户关心的子主题 × 高可信来源）已填满
• 最近一轮的新发现率 < 20%（大部分搜索结果与已有内容重复）
• 用户的决策不再受未知信息阻塞
• 跨域同构检索没有找到新的类比

需要继续的信号：

• 存在高影响的 claim 仍然只有单一来源
• 覆盖矩阵的"反面证据"列大面积空白
• 最近一轮发现了新的子主题（扩张成功，但新主题本身还没深入）
• 用户明确感觉"还差点什么"

与现有 Skill 的关系

workflow_deep_research_survey    ←  单轮执行引擎（Phase 1-4）
        ↑
        │ 每轮调用一次
        │
workflow_iterative_expanding     ←  本 skill：轮次间的过渡协议
        │
        │ 迭代结构借鉴（历史）Modify→Verify→Keep/Discard 探索策略
        ↓
workflow_knowledge_flywheel      ←  笨数据+笨方法+笨模型=精知识

本 skill 不替代 deep_research_survey，而是包装它。每轮调研仍然走 Phase 1-4，本 skill 只管"轮次之间发生什么"。

迭代的终态：报告不是终点

从 62 份调研报告和 23 天对话日志的回顾分析中得出的关键发现：

调研报告是 Skill/Rule 生成管线的中间节点，不是最终产出。至少 5 个主题链（冰岛旅行 10 份、OpenRouter 3 份、Git 管理 2 份、Text Extraction 3 份、OpenClaw 4 份）有明确的多轮迭代。后续迭代的典型动作不是"补充更多信息"，而是：

• 反转前次结论：Git 调研 Round 2 直接反转了 Round 1 的核心结论（"worktree 不是答案"→"worktree 是答案"）
• 抽象出通用模式：codebase-explorer 的项目复盘被提炼为（历史）Modify→Verify→Keep/Discard 探索策略 skill

每轮调研结束时，除了"扩张建议"，还要问一个问题：本轮发现是否足以生成一个 Skill 或 Rule？ 如果是，写 Skill 就是这轮的收敛动作。如果不是，下一轮的目标不只是"填空白格"，还包括"积累到可以提炼 Skill 的程度"。

已验证的迭代成功模式

从对话日志中提取的三个高效迭代模式：

1. 先暴露决策点再动手（WeClaude 重写案例）：调研后识别出 6 个需要用户拍板的边界问题，主动停下等用户决策，而不是猜测后直接实现。核心特征是把不确定性显式化。

1. 修基础设施再跑迭代（codebase-explorer V5 案例）：先识别出被表面现象（"上下文耗尽"）遮盖的根因（MCP bug + Skill 文档缺陷），修复根因后才进入 metric-verify-fix 循环。不做这一步，迭代会在同样的问题上反复失败。

1. 调研发现可复用资产（WeClaude 案例）：调研阶段发现目标系统已有 50%+ 的基础设施，避免了从零重写。"先看有什么再决定做什么"比直接设计方案节省总工作量。

反模式

示例：Git 基础设施调研的扩张路径

Round 1: Git worktree + hook + commit 自动化
  覆盖: 官方文档、社区讨论、GitHub workflow
  空白: Docker 隔离、tmux 管理、学术论文中的 workspace isolation
  扩张策略: S4(跨域同构) + S6(邻域扩展)

Round 2: Docker/tmux 作为 worktree 的补充隔离层
  覆盖: Docker 官方文档、tmux 实践、dev container 规范
  空白: 安全沙箱（gVisor/Firecracker）、CI/CD 中的隔离模式
  扩张策略: S2(视角翻转: 从"怎么隔离"到"隔离失败会怎样") + S5(深度钻取: dev container 的实际采用率)

Round 3: Agent 可观测性 + review-then-land 工作流
  覆盖: OpenTelemetry for agents、审查机制设计
  空白: 用户实际的 TODO 执行场景、WeChat 推送集成
  扩张策略: S1(信息源轮换: 实际用户案例) + S3(时间轴: 这类工具的演化趋势)

变更日志