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