# 拆doc-coauthoring：交稿前先过盲测——官方货架最轻的流程件，怎么管住最重的活 ## 概述 ## 评测对比表 口径沿用本栏目惯例：功能 25%、设计 25%、实战 20%、上手 15%、社区 15%。首评是门牌级黑箱判断，本期基于三重印证的设计拆解复分——骨架有 5 月照录与硬四件家风档案背书，部分※可摘，但逐字复核仍缺，设计分给满的前提在此声明。 | 件 | 维度 | 功能 25% | 设计 25% | 实战 20% | 上手 15% | 社区 15% | 加权 | |---|---|:---:|:---:|:---:|:---:|:---:|:---:| | doc-coauthoring | 写作·过程 | ★★★★ | ★★★★★ | ★★★ | ★★★★★ | ★★★★ | **4.20** | | 首评存档（09-18） | — | ★★★★※ | ★★★★ | ★★★※ | ★★★★ | ★★★★ | 3.80 | 复分动了三处：设计五星——盲测回路加渐进披露，是官方货架里流程设计的上限；上手五星——随包在册、零配置零依赖，四步装机成本为零；实战压三星不动的理由在第五节细说——**它的效果上限取决于用户肯不肯陪跑，流程件的天花板是人的耐心**。 再把官方已拆的六件摆一张桌上看物种差异（历史评分出自本站存档）： | 件 | 物种 | 交付物 | 门面大小 | 核心手段 | |---|---|---|---|---| | docx | 文件件 | .docx 文件 | 中 | 拆包改 XML，脚本背书 | | pdf | 文件件 | .pdf 文件 | 小 | 表单填充，脚本最薄 | | pptx | 文件件 | .pptx 文件 | 中 | 先渲染看图再交稿 | | xlsx | 文件件 | .xlsx 文件 | 大 | 公式重算与格式规范 | | webapp-testing | 验证件 | 测试结论 | 中 | 教你别读代码、直接跑 | | **doc-coauthoring** | **流程件** | **一篇定稿** | **约 1500 token** | **三阶段流程加盲测回路** | ## 一、门牌拆字：一个 -ing，把话在命名层挑明 `doc-coauthoring` 三个词素：doc、co、authoring。9 月 18 日首评已经点出关键——**收尾是 -ing，动名词，过程进行时**。对照硬四件：docx、pptx、xlsx、pdf 全是名词收尾，名字就是交付物本身；这件的名字是一个动作，交付的是动作的完成态。官方在命名层面就把货架分成两排：管「那一刻」的和管「那一段」的。 中间的 `co-` 前缀是最容易被略过、其实最值钱的两个字。它把路由关键词直接焊进门牌：用户嘴里说出「一起写」「帮我共同打磨」「咱们把这份文档过一遍」时，co 就是命中点。写作类请求是所有 Skill 触发面里最宽的一类——从「写个周报」到「翻译这篇稿子」都沾写作的边，**官方用 co 把「代写」和「共写」切开了**：你要一份成品，那是别的件的活；你要的是「陪着我把这份东西磨到能交」，这才是它的门。 这也是为什么它不该被译成「文档工具」。5 月横评给它的定位今天依然准确：**不是格式转换器，是写作流程编排器**。 ## 二、描述与触发词：过程件的路由难题，官方怎么解 文件件的触发词好写——用户说「转成 PDF」就是 pdf 的事，「改个 Word」就是 docx 的事，动词后面跟着格式名，路由天然清晰。过程件没这个便宜：用户不会说「请对我执行 co-authoring 流程」，只会说「帮我写份方案」。 官方的解法是本站多次记录过的**What/When 两段式家风**※：描述先说这件做什么，再说什么时候用，把场景词成串地铺进 When 段——起草、修改、审阅、润色、共同编辑。这套堆栈对长句请求命中率不低，但它有一个文件件没有的副作用，值得每个想写流程件的人记下来： **过程件的描述是在抢路由，不是在等路由。** 「帮我写份方案」这种宽请求，落进它还是落进别的写作件，取决于描述里谁的关键词更贴近用户原话。硬四件抢错顶多格式不合，重新跑一次就是；流程件抢错了，用户会被拉进一场三轮问答——体验损失完全不同量级。所以官方给它的描述必然是收着写的※，而且名字里的 co 本身就是第一道闸门：你的请求里没有「共同、一起、打磨」这层意思，它就不该接。 给写件人的启示一句话：**文件件靠名词路由，过程件靠动词路由，动词比名词难写十倍——描述里每个场景词都是在替用户翻译他嘴里会说的那句话。** ## 三、三阶段工作流逐段拆：信息倾倒、逐节精炼、盲测回路 流程骨架出自本站 5 月 19 日横评的照录，两重来源（存档加注册表）互相印证，这部分可以不带※： **阶段一：Context Gathering（摸底）。** 不动笔，先倾倒。读者是谁、拿去做什么用、有什么模板和硬约束、哪些话不能说——这些信息在一次集中问答里收齐，打包成「模板与约束」传给下一阶段。这一段对应的是所有写作事故的总根源：**作者从头到尾没搞清楚读者是谁**。传统写法的补救是回头返工，它的做法是把这道闸焊在最前面。 **阶段二：Refinement（逐节精炼）。** 先交提纲再动笔，然后一节一节写、一节一节确认。注意这里的反直觉设计：模型完全有能力一口气吐出全文，但流程明确禁止这么干※——因为全文直出的修改成本是指数级的，而逐节确认把分歧消灭在每一节还在「便宜」的时候。这是流程件和「会写」的区别：**会写是能力，流程是把能力用在便宜的位置。** **阶段三：Reader Testing（盲测）。** 全件最有洞察力的一段。初稿完成后，起一个**没有任何先前对话上下文**的空白实例来读这份稿子，模拟真实读者的信息不对称——真实读者不知道你脑子里那些没写进稿子的前提，空白实例恰好也不知道。作者以为写了其实没写的盲点，在这个环节被批量捕获；发现盲点就回到阶段二改，改完再测，循环到没有新盲点为止。据 5 月横照录，这一段约占总 token 消耗的三成——**验收是这件最贵的环节，也是它最不可替代的环节**。 ```mermaid flowchart TD U["用户一句写作请求"] --> R["co 前缀路由命中"] R --> S1["阶段一：摸底"] S1 --> A["问清读者与用途"] A --> B["收齐模板与约束"] B --> S2["阶段二：逐节精炼"] S2 --> C["先交提纲再动笔"] C --> D["一节一节确认"] D --> E["拼出完整初稿"] E --> S3["阶段三：盲测"] S3 --> F["空白子代理读稿"] F --> G{发现盲点} G -->|有| S2 G -->|无| OK["定稿"] OK --> X["接力docx出文件"] ``` ## 四、资源与脚本：官方最轻的门面，和它省掉的东西 5 月横评的 token 表照录了这件事的家底：**SKILL.md 门面约 1500 token**，对照 xlsx 的约 3500、docx 的约 2800，是当时官方货架最轻的一档。轻不是穷，是物种差异： - **硬四件背后是代码。** docx 拆包改 XML 要脚本，pptx 先渲染后交稿要渲染链，xlsx 公式重算是纯工程——这些件的知识量大半是「库怎么用」的知识，必须写进文件、配好脚本，所以门面重。 - **流程件背后只有话术。** 它不调库、不碰格式、不生成二进制，全程只做两件事：提问和编排。它需要的全部知识——什么阶段问什么、按什么顺序、什么条件下打回——都是提示词工程，压缩率天然就高。 这也是渐进披露的极端案例※：正文短，意味着常驻上下文成本几乎可以忽略；细节按需加载，不碰到的段落一次 token 都不花。硬四件装十件要掂量门面，这件装一百件也不心疼——**流程件是 Skills 生态里第一个「可以忘掉它在装着」的物种**。代价同样清楚：没有脚本背书，就没有硬产物校验，定稿是文本不是文件，最后一公里还得接力 docx 或 pdf 出货。流程件管过程，文件件管交付，这条接口线官方画得很清楚。 ## 五、适用与不适用：三星实战分的完整理由 **该用它的场景**：要给客户、领导或全组传阅的正式长文档——方案书、需求文档、公告、白皮书。共同特征是**读者不是你自己、返工成本高、盲点代价大**，恰好是盲测回路的主场。写成这几类东西时，三轮问答的耐心值得花。 **不该用它的场景**，比适用面更能看清它的边界： | 场景 | 该找谁 | 为什么不是它 | |---|---|---| | 随手一段消息、一封快信 | 裸聊模型 | 流程税超过产物价值 | | 把 md 转成正式文件 | docx、pdf | 那是格式转换，不是共写 | | 幻灯片 | pptx | 过程不同，交付物不同 | | 去掉 AI 味、调文风 | 去AI味专件 | 它管结构盲点，不管语域 | | 代码注释、技术短文 | 不用件 | 读者就是同行，盲测是空转 | 实战压三星的账现在能算清了：一是**流程的完成度取决于用户陪跑的耐心**，三次确认加一轮盲测，赶时间的人会在阶段二就喊「直接给我全文」，流程一破，这件就退化成一个啰嗦的代笔；二是**中文长文档场景未经实测**※，盲测环节对「信息不对称」的模拟是否跨语言成立，存档里没有证据，只能说骨架上没有语言依赖；三是 token 账确实比裸写贵——照录值是同规模文档裸写成本的数倍，买的是返工率下降，对一次性的小文档，这笔账是亏的。 ## 六、安装与使用 ```bash # 已装 example-skills 插件包的，doc-coauthoring 已在册，无需任何安装 # 从官方仓库手动取用（目录层级以仓库实际为准）： git clone --depth 1 https://github.com/anthropics/skills # 在仓库内定位 doc-coauthoring 目录，拷入 ~/.claude/skills/ 后重启会话 ``` 触发姿势按路由成本从低到高三种：直接点名（「用 doc-coauthoring 帮我过这份方案」）；场景词触发（「我们一起把这份文档打磨到能交」）；宽请求触发（「帮我写份方案」）——第三种不保证命中它，原因见第二节。开跑之后你要做的只有一件事：**别嫌阶段一问得多，那些问题省的是阶段三之后的最贵的返工。** ## 推荐排行榜 - **设计榜（官方货架内）**：doc-coauthoring（盲测回路）＞ pptx（先看图再交稿）＞ webapp-testing（别读代码直接跑）＞ docx（拆包）＞ pdf（薄脚本直出）。管过程的压过管文件的，验收回路段位最高。 - **门面轻盈榜**：doc-coauthoring（约 1500 token）＞ pdf ＞ docx ＞ pptx ＞ xlsx。越轻越适合常驻。 - **上手榜**：软四件全员随包在册并列第一，doc-coauthoring 是其中唯一建议人人开箱的（首评判词，本期维持）。 - **谁该装、谁该路过**：经常产出正式长文档的顾问、产品经理、技术写作者，必装；天天只写消息和周报的，路过；团队有 brand-guidelines 的，双装旁挂——约束件管调性，流程件管过程，接力 docx 出货，官方在软四件里埋的就是这条流水线。 ## 结语 四个月犁完一个官方货架，真正值得单独开箱的其实只有这一件。硬四件回答的是「AI 能不能产出合格文件」，webapp-testing 回答的是「AI 产物谁来验」，doc-coauthoring 回答的是更前面的一个问题：**在动笔之前和定稿之后之间，那些没人管的过程，能不能也被工程化**。它的答案是一套约 1500 token 的话术：先摸底，再逐节，最后请一个什么都不知道的评审员来读——把「作者以为读者懂了」这个写作最古老的病，变成了流程里的一站。九月的新货们开始把这个思路搬去视频和三维赛道，而范本一直躺在每个人的插件包里，轻到可以被忽略。 ## 参考来源 > [!tip] 51学通信知识星球 > **星主：爱卫生**（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 > **星球定位**：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 > **当前规模**：5200 篇主题 / 990 个回答，198 元/年。 > **加入福利**：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 > **AI 加持**：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。