（4736期）Doc Coauthoring Anthropic – 结构化协作文档编写工作流

结构化协作文档编写工作流 结构化协作文档编写工作流，通过上下文收集、迭代精炼和读者测试三阶段，帮助用户高效产出高质量技术文档、提案或决策文档。 使用说明 核心用法 doc-coauthoring 是一款面向技术写作场景的协作式文档编写工作流。它采用三阶段结构： Context Gathering（上下文收集）：通过开放式问题引导用户倾泻背景信息，Claude 主动追问澄清，确保双方信息对齐 Refinement & Structure（精炼与结构化）：分章节头脑风暴→筛选整合→起草→迭代打磨，逐节构建文档 Reader Testing（读者测试）：用全新的 Claude 实例（无上下文污染）测试文档可读性，捕获盲区 该工作流特别适用于技术规范（spec）、决策文档（decision doc）、产品需求文档（PRD）、RFC 等结构化内容创作。 显著优点 对抗"知识的诅咒"：通过读者测试阶段，主动暴露作者 assumed knowledge，避免写出只有作者能懂的文档 低摩擦输入设计：支持信息倾泻（info dump）、速记回答、文档链接等多种输入方式，降低启动门槛 迭代式质量控制：每节经过头脑风暴→筛选→起草→精炼的完整循环，避免一次性写就的粗糙感 可验证的完成标准：Reader Testing 提供客观的"文档是否可用"检验标准，而非主观感觉 潜在局限 时间成本较高：完整三阶段流程明显长于自由写作，对简单文档可能过度工程 依赖用户配合度：信息倾泻和迭代反馈需要用户持续投入，若用户中途失去耐心，效果大打折扣 工具链依赖：最佳体验需要 artifacts、sub-agents 等高级功能支持，基础环境功能受限 模板化风险：严格遵循工作流可能让部分文档风格趋同，缺乏个性化表达 适合人群 技术团队需要撰写影响范围大的决策文档或架构规范 跨部门协作场景下需要确保多方理解的提案文档 写作经验较少、需要结构化指导完成复杂文档的用户 文档将被长期维护、需要高可读性和低误解风险的场景 常规风险 上下文污染风险：若 Reader Testing 未严格执行"无上下文"隔离，测试结果失真 过度精炼陷阱：迭代阶段可能陷入对措辞的过度打磨，偏离内容实质 模板错配：工作流假设用户需要结构化文档，若用户实际需要自由散文式内容，体验不佳 集成可用性波动：依赖外部集成（Slack、Drive 等）读取团队上下文，集成失效时流程受阻 安全等级 S（内部工作流，无外部数据泄露风险），来源可信度 T1（官方 skill 文档）。 原始说明 Guide users through a structured workflow for co-authoring documentation. Use when user wants to write documentation, proposals, technical specs, decision do...