技能使用指南

文档合著工作流程Skill 用法详解

文档合著工作流程Skilldoc-coauthoring
12 个章节 约 16 分钟阅读 AI 智能生成

文档合著工作流程Skill（doc-coauthoring）：用三阶段协作流程，把"写文档"变成可复用的产出流水线

  • 它解决的是"写不顺"而不是"写不出"：把文档写作拆成上下文收集、精炼与结构、读者测试三个阶段，让 AI 从"代笔"变成"陪写教练"。
  • 三阶段闭环：先把你脑子里的隐性上下文倒干净，再逐段头脑风暴+策展+精炼，最后用一个"没有上下文的读者视角"做盲测，提前发现别人看不懂的地方。
  • 不是一次性生成：全程用增量编辑推进，每个部分都经过澄清问题、选项筛选、起草、迭代精炼四道工序，避免"AI 一口气吐一大段正确但没用的话"。
  • 适用范围明确：PRD、技术规格、决策文档、RFC、提案等结构化文档最合适；随手写个便签、发条消息则不必动用这套流程。
  • 最大价值在于"可交付"：产出的文档不只是作者自己看得懂，而是能被同事、评审人甚至另一个 AI 正确理解。

该技能叫什么？如何一键安装 AI 技能提升开发效率？

技能中文名：文档合著工作流程Skill 技能英文名：doc-coauthoring 技能ID：12040

这个技能要解决的问题非常具体：团队里的文档大多是"作者自嗨型"。写的人以为讲清楚了，读的人一头雾水；决策文档缺背景，技术规格缺权衡，提案缺反面意见。传统做法是写完再找人评审，成本高、周期长，而且评审意见往往停留在措辞层面。

doc-coauthoring 的思路是把写作过程本身结构化——在你动笔之前先把上下文掏干净，在写作过程中用"选项策展"代替"自由发挥"，在交付之前用"无上下文的读者"做压力测试。它是一套流程型技能，而不是一个"文档生成器"。

一键安装的思路与步骤

安装类操作以官方说明为准，这里的通用路径适用于大多数支持 Skill 机制的 AI 客户端：

  1. 确认前提：你的 AI 客户端或 IDE 插件需要支持技能（Skill）加载机制，并已完成账号登录、工作区授权。若技能依赖外部集成（如 Slack、Teams、Google Drive、SharePoint 等 MCP 连接器），建议一并开启，以便流程中直接拉取上下文。
  2. 进入技能入口：打开客户端内的技能市场 / 技能库 / 插件面板，在搜索框输入英文名 doc-coauthoring 或技能ID 12040。
  3. 一键添加：在技能详情页点击安装或启用按钮，具体按钮文案与是否收费以官方说明为准。
  4. 验证是否生效：新开一个对话，直接说"帮我写一个技术规格文档"或"起草一个提案"。如果技能已生效，AI 不会立刻开始生成正文，而是先向你介绍"上下文收集 → 精炼与结构 → 读者测试"三个阶段，并询问你是否按此流程进行。看到这段引导语，就说明安装成功了。
  5. 选择模式：此时你可以接受流程，也可以拒绝并改为自由形式写作。技能在设计上就允许你随时跳出，不会强制锁定。

该技能的主要功能和特点

  • 三阶段结构化流程：上下文收集（缩小"你知道的"和"AI 知道的"之间的差距）、精炼与结构（逐部分头脑风暴与迭代）、读者测试（用无上下文的 AI 验证可读性）。
  • 元上下文五问：开工先问清文档类型、目标受众、期望影响、是否有模板格式、其他约束，把"写给谁看"锚定下来。
  • 信息转储机制：鼓励用户以"想到哪写到哪"的方式倾倒背景、团队讨论、被否决的替代方案、组织政治、时间压力、技术依赖、利益相关者关注点，不要求提前组织语言。
  • 澄清问题生成：在信息转储后自动生成 5-10 个编号问题，允许用户用简写回答（如"1: 是，2: 见某频道，3: 不因为向后兼容"），大幅降低沟通成本。
  • 头脑风暴 + 策展：每个章节先抛出 5-20 个候选要点，由用户指示"保留哪几条、删掉哪条、合并哪两条"，并附简短理由，让 AI 逐步学习优先级偏好。
  • 增量编辑而非整篇重写：所有修改通过 str_replace 局部替换完成，避免每次反馈都把整篇文档重打一遍。
  • 结构脚手架：先按文档类型建议 3-5 个章节并生成带占位内容的骨架（有工件能力时用 create_file 创建，无工件能力时在工作目录生成 markdown 文件），再逐段填充。
  • "未知最多优先"排序：建议从信息最不确定的部分写起（决策文档先写核心提案、规格文档先写技术方案），摘要类章节留到最后。
  • 全文连贯性复审：完成 80% 以上章节后，通读全文检查跨章节流程、冗余、矛盾，以及"看起来很像通用填充"的段落。
  • 读者盲测：有子代理能力时（如 Claude Code）自动调用无上下文的子代理回答预测问题；无子代理能力时（如网页界面）给出浏览器端的测试指令，让你手动验证。
  • 可解释的劝退机制：如果用户想跳过某阶段或表现出不耐烦，技能会给出更快的替代方案，并始终把调整流程的决定权交还给用户。

和普通 AI 写作功能的差别在哪：普通工具是"你说需求，它出全文"，你是审稿人；doc-coauthoring 是"它问你问题，你挑选项，它改局部"，你是作者兼主编。前者快但容易跑偏，后者慢一点但产出可控、可追溯。

如何使用该技能？

以下按技能的三阶段流程给出可操作步骤。

阶段一：上下文收集

  1. 触发技能。在对话中输入类似"帮我写一份技术规格文档"“起草一个提案”"写个 RFC"的请求。
  2. 回答元上下文五问。例如：
    • 文档类型：技术规格
    • 受众：后端团队与 SRE，共 8 人，都熟悉现有架构
    • 期望影响：评审通过后两周内启动开发
    • 模板：有，公司内部技术规格模板
    • 其他约束：不能改动现有数据库 schema
  3. 提供模板（如有）。可分享链接或直接上传文件，技能会读取模板结构作为骨架依据。
  4. 信息转储。把背景、讨论记录、被否决的方案、组织情况、时间压力、技术依赖一次性倒出来，不必整理。示例：“我们现在的鉴权是 session 方案，去年 Q3 出过两次跨域问题，运营侧不希望用户重新登录……”
  5. 回答澄清问题。AI 会给出 5-10 个编号问题，可以用简写回复，例如"1: 是，2: 见 #infra 频道，3: 不，因为要向后兼容"。
  6. 确认进入下一阶段。当 AI 能直接讨论边缘案例和权衡取舍、不再追问基础概念时，本阶段自然结束。

阶段二：精炼与结构

  1. 确认章节结构。AI 会建议 3-5 个章节（如"背景与问题 → 方案设计 → 备选方案对比 → 风险与回滚 → 里程碑"），你可以调整顺序或增删。
  2. 生成骨架。技能会创建带"[待写]"占位符的文档骨架并给出链接（或在本地生成 markdown 文件）。
  3. 逐章节推进，每个章节重复以下五步：
    • 澄清问题：AI 就本节内容提出 5-10 个具体问题；
    • 头脑风暴：AI 列出 5-20 个候选要点，包含你可能遗漏的角度；
    • 策展：你回复"保留 1、4、7、9，删掉 3（与 1 重复），合并 11 和 12"；
    • 差距检查：AI 反问本节是否还有重要内容缺失；
    • 起草：用实际内容替换占位文本，并给出更新后的链接。
  4. 反馈方式很关键。技能明确建议：不要自己动手改文档，而是告诉 AI 改什么，例如"删掉第三条要点，已被第二条覆盖"“第三段再精简一些”。这样 AI 能在后续章节学习你的风格。
  5. 质量闸门。连续三次迭代没有实质性改动后，AI 会主动问"有没有哪段内容删掉也不损失信息"，帮你做减法。
  6. 全文复审。完成 80% 以上章节后，AI 通读全文，检查跨章节流程、矛盾与注水段落，并给出最终建议。

阶段三：读者测试

  1. 预测读者问题。AI 生成 5-10 个"读者在试图了解这份文档时真正会问的问题"。
  2. 执行测试。
    • 有子代理能力时：AI 自动为每个问题调用一个无上下文的子代理，仅凭文档内容作答，并汇总哪些答对、哪些答错。
    • 无子代理能力时：AI 给出操作指令——新开一个对话、粘贴文档、逐个提问，并额外追问"这份文档哪里含糊"“它假设读者已经知道什么”“是否存在内部矛盾”。
  3. 修复差距。根据测试结果回到对应章节继续精炼，直到读者 AI 能稳定答对且不再暴露新的模糊点。
  4. 人工终审。技能会提醒：文档最终由你负责，请自行核对事实、链接与技术细节，并考虑在附录中链接本次对话、用附录承载深度内容而不臃肿正文。

同类型竞品对比分析

方案名称 定位 核心功能 安装/使用门槛 适用场景 优势与不足
doc-coauthoring（文档合著工作流程Skill） 流程型写作教练 三阶段流程、元上下文五问、头脑风暴+策展、读者盲测、增量编辑 需支持 Skill 机制的客户端，搜索技能名或ID一键启用；是否收费以官方说明为准 PRD、技术规格、决策文档、RFC、提案 优势：产出可交付、过程可追溯、能沉淀作者风格；不足：流程偏重，短文档显得繁琐
通用大模型自由对话写作 通用文本生成 直接根据提示词生成整篇文档 打开对话即用，零门槛 草稿、便签、邮件、灵感整理 优势：快、零配置；不足：一次性生成难控质量，容易注水，无读者验证环节
在线协作文档的 AI 写作助手（如 Notion AI、Google Docs 智能撰写类能力） 文档内嵌辅助 续写、改写、摘要、润色、翻译 依赖具体平台的订阅与权限，以官方说明为准 已有文档的润色与扩写 优势：与文档环境无缝集成；不足：偏"句子级"辅助，缺乏跨章节结构与读者视角验证
模板 + 人工同行评审 传统组织流程 固定模板约束结构，评审会发现问题 无技术门槛，但协调成本高 大型决策文档、合规文档 优势：责任清晰、评审权威；不足：周期长（常以天计），评审意见易停留在措辞层面

选择建议：如果是几十字的便签或社媒文案，直接用自由对话即可；如果是要发给团队评审、会被反复引用的结构化文档，doc-coauthoring 的三阶段流程收益最明显；如果文档已经在协作文档平台里成型、只差润色，用平台自带的 AI 助手更顺手。

该技能的典型应用场景与实际体验情况

场景一：后端工程师写技术规格 角色：负责新鉴权模块的后端工程师。痛点：方案在心里很清楚，但写出来总被质疑"没讲清为什么不用现成方案"。使用方式：把历史故障、被否决的方案、兼容性约束全部倒给 AI，在"备选方案对比"章节用策展方式筛出 4 条关键权衡。实际体验：上下文收集阶段最费时间，但也最值钱——很多"说不清"其实是"没想清"，被追问 8 个问题后方案本身就变清楚了。注意：技术细节仍需自己核对，AI 不会替你验证性能数据。

场景二：产品经理写 PRD 角色：To B 产品经理。痛点：研发总说需求文档"缺场景"。使用方式：先用模板导入既有 PRD 结构，在"用户场景"章节让 AI 头脑风暴 15 个候选要点，挑出 7 个此前没写到的边缘场景。实际体验：头脑风暴的"补盲"效果超出了预期，尤其适合长期做同一产品线、视角容易固化的作者。注意：策展时要给理由，否则后续章节的推荐会失准。

场景三：技术负责人写架构决策文档（ADR/RFC） 角色：架构师。痛点：决策文档写完没人看，或者看完还在会上重复问同样的问题。使用方式：进入读者测试阶段，用无上下文的子代理模拟"新入职工程师"，看它能否仅凭文档回答"为什么不用消息队列"。实际体验：这是整套流程里最有"aha"的一步——作者觉得写清楚的地方，读者 AI 常常答错或答偏，直接暴露隐藏假设。注意：网页端需要手动完成测试，有几步操作成本。

场景四：跨团队提案与资源申请 角色：项目负责人。痛点：提案需要说服非技术背景的管理层，但作者习惯用技术语言。使用方式：在元上下文环节明确"受众是管理层、期望影响是批准预算"，AI 在措辞与结构上会更偏向结论先行。实际体验：流程对"受众锚定"的强调很有效，写之前先想清楚"读完希望对方做什么"，比事后润色有效得多。

整体上手难度：中等偏低。技能本身不需要学习命令，难点在于"愿不愿意先花 20 分钟倒上下文"。跳过这一步，后续所有环节的质量都会打折。

该技能能为用户带来的价值

1. 把隐性知识显性化。 大多数文档质量问题不是文笔问题，而是"作者忘了读者不知道这件事"。上下文收集与读者盲测这两个环节，本质是在强迫你把脑子里的默认前提说出来。

2. 缩短"写完到能用"的往返次数。 传统流程是写完 → 发出去 → 收到"看不懂"的反馈 → 改 → 再发。doc-coauthoring 把读者验证前移到交付之前，把多轮异步往返压缩成一到两次内部迭代。具体节省的时间因文档复杂度而异，但减少的评审往返轮次是可直接感知的。

3. 降低写作启动门槛。 面对空白页最难的是"第一句写什么"。技能的骨架生成与逐章节推进把"写一篇文档"拆成"回答 8 个问题、从 12 个选项里挑 6 个"，心理负担显著下降。对不擅长写作的工程师尤其友好。

4. 让 AI 逐步学会你的风格。 因为所有反馈都以"改什么、为什么改"的形式给出，AI 在后续章节的推荐会越来越贴合你的偏好。这是一个越用越顺的过程，而不是每次都从零开始提示。

5. 沉淀可复用的文档资产。 附录机制、对话链接回溯、模板复用，让一次写作的产出不只服务一个文档，而是形成团队可参考的写作范式。长期看，这是对团队文档质量基线的抬升。

6. 可控性优于自动化。 技能不追求"一键成文"，而是把控制权留在作者手里——每一步都可以拒绝、跳过、调整。对于需要为内容质量负责的场景，这种设计比全自动生成更实用。

常见问题 FAQ

Q1：这个技能怎么安装？装完怎么知道有没有生效？ 在支持技能机制的 AI 客户端里打开技能市场或技能库，搜索英文名 doc-coauthoring 或技能ID 12040，点击安装/启用即可，具体按钮与收费策略以官方说明为准。验证方法：新开对话说"帮我写一份技术规格文档"，如果 AI 先介绍"上下文收集、精炼与结构、读者测试"三个阶段并征询你的意见，就说明已生效。

Q2：用这个技能收费吗？需要额外配置吗？ 技能本身是否收费、是否包含在订阅内，以官方说明为准。基础使用无需额外配置；但如果想让它在流程中自动拉取 Slack、Teams、Google Drive、SharePoint 等平台的上下文，需要先在客户端设置中启用相应的连接器（MCP 服务），并完成授权。没有连接器也不影响使用，你可以直接粘贴内容。

Q3：适合谁用？写个短消息也要走三个阶段吗？ 最适合经常产出 PRD、技术规格、决策文档、RFC、提案的工程师、产品经理与架构师。不建议用于短文本——一条便签、一封邮件、一段社媒文案，自由对话更快。技能本身也允许你随时拒绝流程转为自由写作，不存在"被锁死"的问题。

Q4：和直接用大模型写文档、或者用协作文档自带的 AI 助手有什么区别？ 自由对话式写作是"你提需求、它出全文"，你快但质量不可控；文档平台自带的 AI 助手强在句子级润色与续写，缺跨章节结构与读者验证。doc-coauthoring 的差异点在流程：先倒上下文、再用选项策展代替自由生成、最后用无上下文的读者视角做盲测。它更慢，但产出的文档更接近"可以直接发出去"的状态。

Q5：读者测试那一步必须做吗？会不会很麻烦？ 不是强制步骤，但它是这套流程里最能暴露盲点的环节。如果你在 Claude Code 这类支持子代理的环境中使用，测试会由 AI 自动完成，基本无感；如果在网页界面使用，需要按提示新开一个对话、粘贴文档并逐条提问，大约多花几分钟。建议至少对会被多人引用或用于决策的文档跑一遍，普通周报类文档可以跳过。