context-infra 检查与复盘infra.guiming.net · 全内容自包含呈现 · 生成于 2026-07-21 16:28 UTC

Claude Code 平级协作调研写作工作流

Z3 全文↑ Z2 条目

术-内容 · 术层 skill 全文

← 返回术层 skill 索引 · 返回方法论区

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

时点提示：本页是仓内文件 rules/skills/workflow_claudecode_collaborative_research_writing.md 的逐字投影（仅做隐私清洗：仓库根绝对路径→相对路径、家目录→~/；除此零改写）。若源文件后续有修订，以仓内真源为准。

Claude Code 平级协作调研写作工作流

元数据

这是什么 workflow

普通并行 workflow 的模式是：主 agent 拆任务，子 agent 分头执行，主 agent 整合交付。

这个 workflow 处理的是另一类任务：主线程和 Claude Code 不是上下级关系，而是平级协作关系。主线程负责研究架构、证据分层、判断边界和最终把关。Claude Code 负责高质量思考、观点碰撞、长文组织和主笔写作。

它融合了深度调研方法论（激励感知验证、Claim 提取、信息源分层、交叉验证）和 Claude Code 协作模式（角色分工、信息外化、context separation）。

最终写作默认交给 Claude Code 完成。 主线程负责把研究和判断外化到可共享状态里，再由 Claude Code 把这些材料组织成对外可读的成稿。

为什么需要这个 workflow

在重度使用场景下，纯 API 的 token 成本很高。Claude Code subscription 的边际成本低很多，但 CC 不是直接嵌在当前协作系统里的原生执行单元。为了把低边际成本转化成协作能力，需要额外的信息外化和 handoff 机制。

一句话：用更多协作摩擦，换更低的大模型使用成本。

什么时候使用

默认不要用。只有同时满足以下条件时才进入：

  1. 用户明确提到 Claude Code（或口语化的 cloud code、跟 Claude 一起、让 Claude 主笔等）
  2. 任务不仅是信息汇总，还要求深度判断、原创 framing、文章写作、观点碰撞或论证重组
  3. 任务适合这种分工：主线程负责研究设计与证据组织，Claude Code 负责高质量思考和写作

不要使用的情况：只是常规调研不需要写作、只是机械搜索、任务很小主线程自己能完成、用户没提 Claude Code。这些情况优先用 workflow_deep_research_survey.md 或 workflow_parallel_subagents.md。

核心原则

  1. 激励感知验证: 信息价值取决于来源的激励结构。厂商叙事有用但不能自证。每个主要 claim 都必须追溯到与发布方激励无关的独立证据。
  2. 交叉验证: 多个 sub-agent 覆盖有重叠的主题，用分歧和矛盾暴露盲区。
  3. 可追溯性: 所有引用保留 URL，关键引用保留原文摘录，不依赖总结。
  4. 逐步聚焦: 先扫描全貌，提取 claim，再分维度深入验证。
  5. 单一主交付 + 可复用工件: 最终报告一份，关键中间工件存入 session 目录。
  6. 共享 research spine，分叉 reader mode: 搜索、验证、工件留存共享；成稿前按读者决定 internal / external mode。
  7. 认知分工: 主线程做研究设计和判断边界，Claude Code 做高质量思考和写作，不混淆角色。

角色分工

主线程

普通 sub-agent

它们不是最终作者，也不是最终判断者。

Claude Code

在这个 workflow 里，CC 不是廉价搜索 worker，而是平级协作者。它通常扮演三种角色之一：

默认情况下，CC 应承担 final writer 的角色。

信息源层级

每次调研中，来源可信度不是对等的。按激励结构分层：

层级类型信号特征使用方式
Tier 1厂商官方文档、blog、case study告诉你产品想被怎么看提取 claim，不做验证依据
Tier 2Press coverage、sponsored review、第三方评测能理解市场定位，但激励仍偏正面辅助理解市场叙事，不作为独立证据
Tier 3独立开发者 blog、HN/Reddit 讨论、Stack Overflow信号更强，但采样有偏作为验证信号，注意社区偏差
Tier 4GitHub issues、migration stories、production post-mortems、commit history行为证据而非态度表达最高可信度，用于验证 claim 和标注边界

证据可信度递增排列：态度表达 < 使用场景描述 < 对比决策记录 < Migration stories < Production post-mortems < 代码/commit 级证据。优先收集后半部分。

两种 reader mode

按读者上下文是否已知且厚重来区分。

Mode A：Internal（共享上下文驱动的决策备忘录） 适用于读者是自己或共享长期上下文的协作者。写作契约：不复述共同常识；重点展开会改变结论的未知点、最可能被反对的点、与既有观点冲突的点；优先交付结论、依据、未决问题和建议动作。

Mode B：External（零预设上下文的可发布论证） 适用于读者不是已知对象。写作契约：必须显式回答 why this matters；必须把最有用的判断放在前几段；关键定义、比较框架和限定条件写在页面上，不留在读者脑内补全。

先问三个问题再选 mode：(1) 读者是否已知且共享厚重上下文？(2) 主要价值是帮对方更快判断还是让对方理解并相信？(3) 拿掉私有背景后报告能否独立成立？

工作流程

Phase 1：主线程初步扫描 + Claim 提取

目标: 了解全貌，区分厂商叙事、市场叙事和独立证据，提取待验证 claim。这一步不要急着调用 Claude Code。

操作:

  1. 用 Tavily 进行 2-3 次搜索，覆盖 Tier 1（官方信息）、Tier 2（市场叙事）、Tier 3-4（批评/争议/已知问题）
  2. 总结 3-5 个需要深入调研的维度
  3. Claim 提取：从 Tier 1-2 源中列出关键主张，对每个 claim 标注验证通道

输出: 写入 tmp/<session_slug>/scratchpad.md，包含 Claim Extraction 表格：

## Claim Extraction

| Claim | 来源 (Tier) | 验证通道 | 验证状态 |
|-------|-------------|----------|----------|
| "zero-config，开箱即用" | Tier 1 官方文档 | GitHub issues 搜 setup pain；Reddit 搜迁移故事 | 待验证 |

Phase 2：分割与并行调研

目标: 多角度深入，同时验证 Phase 1 提取的 claim。

维度划分 3-5 个，每个维度同时覆盖一个主题并验证特定 claim。维度之间必须有 ≥50% 的 overlap。

按证据功能设计维度：

同时启动 3-5 个 sub-agent，每个 prompt 明确：具体主题、相关 claim 验证任务、优先返回行为证据、必须返回 URL 和原文摘录、可覆盖的 overlap 维度。

Tavily 参数偏好: max_results=6、search_depth="advanced"、include_answer=false。

Phase 3：整合与交叉验证

目标: 发现矛盾，对比 claim 在不同层级来源中的表现。

  1. 对比各 sub-agent 结果：多源确认 → 可信；单一来源 → 标注；互相矛盾 → 分析原因
  2. 核查每个 claim 的验证状态：
  3. 如发现重大矛盾，可再启动 sub-agent 针对性验证

Phase 4：收敛证据并外化状态

目标: 将研究成果外化为 Claude Code 可消费的文件。只有这一步完成后，CC 才值得下场。

更新 scratchpad，至少包含：

  1. 当前任务目标和成功标准
  2. 当前核心判断（区分事实、推断、未决问题）
  3. 已确认事实和关键来源路径
  4. Claim 验证状态汇总
  5. 主要不确定点
  6. 希望 Claude Code 重点做什么（角色指令）

决定 reader mode，写进 scratchpad：

Phase 5：调用 Claude Code 主笔

明确告诉 CC 这轮要扮演什么角色（peer thinker / peer writer / peer critic）。

CC 调用前做穿透检查：

  1. 每个主要正面判断是否至少有一个 Tier 3+ 的独立证据源？
  2. 找不到独立支撑的判断，必须显式标注"此点仅有 vendor source"
  3. 报告是否同时呈现了 vendor narrative 和 independent reality？

优先让 CC 读文件，不把所有上下文塞进 prompt。CC 调用规范见 claudecode_usage_guide.md。

internal mode 写作顺序: 结论 → 关键依据（含 claim 验证状态汇总）→ 仍未确认的点 → 建议动作

external mode 写作顺序: 为什么值得读 → 核心判断 → 关键背景与定义 → 分维度证据展开 → 限定条件与边界 → 对读者的决策意义

存储位置: contexts/survey_sessions/<topic>_YYYYMMDD_<skill后缀>.md

Phase 6：主线程审稿与继续分工

Context Separation 原则

适合新开 CC 上下文的情况：

不要让同一个上下文既负责长期搜索，又负责最终判断，还负责最后润色。

信息外化：文件位置

原则：保存索引和判断，不重复保存大块原始 payload。

两种 mode 的验证阈值

Internal mode 重点验证：会改变结论的未知点、与读者既有观点可能冲突的点、可能影响下一步行动优先级的点。成功标准：读完后能更快做判断；关键依据最短可追溯；未知点和建议动作足够清楚。

External mode 除事实正确外，还要验证：陌生读者能否在前五段内说出为什么值得读；关键术语和比较框架是否已显化；文章脱离私有上下文后是否仍能独立成立。

常见误用

误用结果正确做法
一开始就叫 CC 下场搜索CC 做了本可由 explore/librarian 完成的廉价工作Phase 1-3 用便宜 agent，Phase 5 再让 CC 下场
什么都不外化，靠 prompt 传上下文CC 每次从零开始理解任务写 scratchpad，让 CC 读文件
把 CC 当普通 sub-agent只用到模型，没用到平级协作价值给 CC 明确的角色指令
把 search notes 当 handoff 本体给 CC 一堆搜索记录，缺当前判断搜索结果服务于 scratchpad，scratchpad 服务于写作
调研结果变成 vendor marketing 汇总没有穿透厂商叙事Phase 1 提取 claim，Phase 2 按证据功能分维度，Phase 3 核查验证状态
internal 误用为"可以不解释"读者补全负担过重解释预算按读者模型分配
external 误用为 internal 加长版不自足，内部人才能看懂重写入口和排序，把读者价值放前面

与其他 skills 的关系

本文件负责的是三者的特殊组合：深度调研方法论 + Claude Code 平级协作 + 写作交付。

← 返回术层 skill 索引 · 返回方法论区