写文档是工程师最容易被偷走时间的地方。想法在脑子里清清楚楚，落到纸上就糊成一团，别人读完还是抓不住你要干什么。你以为写完了，其实只是把混乱从脑袋搬到了文件里，下次自己回看也得重新脑补一遍上下文。
这类工作流技能我见过不少，大多本质是一份提示词模板，换层皮就敢叫写作助手。doc-coauthoring 不一样，它把写文档重新定义成一场有引导的协作，而不是丢给模型一句帮我写个 PRD 就完事。那些模板顶多保证格式不丑，真正难的不是排版，是把你脑子里没说出来的前提和权衡逼出来。doc-coauthoring 盯的正是这一步。
它来自 Anthropic 在 Smithery 上托管的技能库，定位是给 Claude 用的主动引导者。只要是需要给别人看的结构化内容，它都能接：
-
文档与提案 -
技术规范 -
决策文档 -
RFC 与设计文档
这篇文章我会拆开它的三阶段工作流，讲清楚每一步到底在干什么，也直说它在哪些场景下其实帮不上忙。它不是万能药，但那个核心设计确实戳中了写作者最容易忽略的盲区，值得认真看一遍。
工作流拆解
第一阶段叫 Context Gathering，目标是先抹平你和 Claude 之间的认知差。它会先问几类地基信息，答得越具体后面越顺：
-
文档类型 -
主要受众 -
期望影响 -
模板格式 -
其他约束
地基打完，它最反直觉的一步来了：鼓励你信息倾倒。别筛选，先把这些都倒出来：
-
背景讨论与被否决的备选方案 -
组织政治和时间线 -
技术架构 -
利益相关者的担忧
倒得越彻底，后面的文档越不容易漏掉关键前提，也不会等到评审会上才被人问住，等于提前把评审会搬到了写作阶段。
你倒完，它再反向生成 5 到 10 个编号问题补齐缺口。这一步的意义在于，模型不再靠猜，而是拿着你给的原材料去问该问的，而不是问它自己以为该问的。你自己写的时候往往意识不到哪些信息还没交代，因为那些前提对你而言太理所当然。让模型先穷举问题，反而帮你照见自己的盲点。
第二阶段 Refinement & Structure 才是主菜。它先建脚手架：有 artifact 就用 create_file 生成带占位符的骨架，没有就建一个 markdown 文件。脚手架长这样：
# Decision Doc
## Context
[To be written]
## Proposal
[To be written]
## Alternatives Considered
[To be written]
脚手架上的每一节都用同一个六步循环推进，从澄清问题一直走到迭代精炼，下面这张图把这套循环画出来了。
起草不用整文重印，它让你用 str_replace 替换占位符，一段一段填。连续三次没有实质改动，它会主动问你能删什么，逼你把冗余挤出去，而不是帮你把水越掺越满。
质量到了八成以上，它会通读全文查流畅性、冗余和矛盾，专门找那些 AI 最爱塞的 slop 填充句。这点比大多数写作工具都狠，因为大多数工具巴不得你多写点。
第三阶段 Reader Testing 是它真正的护城河。文档写完了不代表写对了，它用一只没有上下文的新 Claude 来当读者，预测 5 到 10 个读者会问的问题，逐题测试文档扛不扛得住。比如读者会不会误解某个术语，会不会找不到决策依据，会不会在某个分支上卡住。这些坑在作者视角里几乎永远看不见，因为作者早已知道答案。
架构解析
把整个机制拆开看，其实是四角关系：
-
你（提供背景和决策） -
Claude 引导者（提问和起草） -
文档 artifact（被 create_file 和 str_replace 操作） -
可选的外部连接器
artifact 的管理规则很硬：所有编辑都走 str_replace，绝不允许整篇重印。每次改动后它给你一个可点的链接，头脑风暴的列表只留在对话里，不污染文档本体。这条纪律的副作用很实用：文档始终是一份干净的产物，你随时能单独发给别人，而不必把一堆内部脑暴也夹带过去。
下面这张架构图把四角的协作关系画了出来。注意连接器那一侧：如果你的环境接了协作工具，它能直接把上下文拉进来。
没有连接器也不怕，它让你手动粘贴或开 Claude 连接器。设计上一点不傲慢，缺什么就问，不偷偷攒缺口，这是它和一堆假装懂你的助手最大的区别。
Reader Testing 在 Claude Code 这类有子代理的环境里能全自动跑：
-
预测读者会问的问题 -
派子代理逐题测试 -
额外查歧义和矛盾 -
出报告再修复
网页版 claude.ai 没有子代理，就让你自己开新会话手动测。
使用场景
最该用它的场景是决策文档和 PRD。这类文档的读者往往和你不在同一个信息层，你以为写清了，对方看到的却是大量没说出口的假设。引导式提问正好把这些假设逼到台面上。决策文档最怕的不是写错，是写了半天对方根本不知道你在建议什么，然后默默按自己的理解去执行。
RFC 和设计文档也一样。技术方案里最值钱的部分常常是被你否掉的那些备选，自由写作时你懒得写，读者也就无从知道为什么走这条路。信息倾倒环节专门收这些。
如果你团队已经在用协作工具沉淀讨论，它直接把上下文拉进文档，省掉你重新复述的功夫：
-
Slack 或 Teams 的频道记录 -
Drive 与 SharePoint 的共享文档 -
任意 MCP server 的上下文
这比从零拼背景强太多，也大幅减少了转述带来的信息损耗。
它的短板也很直接：在没子代理的纯网页环境里，Reader Testing 要你手动开新会话粘贴文档自测。自动化那层价值直接掉了一半，文档质量上限回到你自己的耐心和细心。
洞察与反思
我用过不少 AI 写作工具，大多数把你当成填空题的作答者，给个模板你往里塞。doc-coauthoring 的态度相反：它当你是合作者，自己当那个不断追问、不断挑刺的编辑。
Reader Testing 这个点我越想越觉得对。我们写文档从不考虑一个毫无背景的人能不能照着做，但文档被粘贴进 Claude 跑工作流时，恰恰就是这种处境。它提前把你文档当程序来测。
当然它也有边界。它需要 Claude 来当那个引导者，一旦你选了自由形式，价值就塌了。它治的是写不顺，不治没东西写，素材空的时候它也只能陪你在原地转圈。另外它强依赖 Claude 当引导者这件事，意味着换到能力弱的模型上，提问质量会明显下滑，方法论还在，执行的人不行了。
传统写法和引导式写法的差别，在读者盲点捕获这一项上最明显。下面这张对比图把它俩摆在一起看，差距不在文笔，在流程有没有逼你换位思考。
说到底它更像一套可迁移的方法论，不绑死在某个模型上。你今天用 Claude 跑这套流程，明天换个人工引导、或者换 Gemini，骨架依然成立。这点比技能本身更值钱。
资源地址
| 资源 | 地址 |
|---|---|
| Smithery 技能页 | https://smithery.ai/skills/anthropics/doc-coauthoring |
总结
如果你经常要写给别人看的结构化文档，又总在写完才发现别人看不懂上栽跟头，这个技能值得一试。它最值钱的是 Reader Testing，把文档当程序测一遍。尤其是跨团队、跨时区的文档，你写完就走，半年后接手的人全靠这份文档活，盲点代价极高。
但它不是万能药。没有子代理环境时，Reader Testing 退化成手动活；素材本身空的时候，再强的引导也救不了。它不是用来替你想，是用来逼你想清楚。如果连你自己都说不清要写什么，任何工具都只是把混乱包装得更漂亮。
文档的本质是和未来的读者对话，而你最不客观的读者恰恰是自己。让一个没有上下文的 Claude 先读一遍，比你自己通读三遍都管用，因为那才是读者真实的处境。写作最大的幻觉，是以为写完了就等于说清了。