| name | doc-coauthoring |
| description | 引导用户通过结构化工作流协作撰写文档,包含上下文收集、迭代优化和读者验证三个阶段。适用于用户想要编写文档、提案、技术规格、决策文档或类似结构化内容时触发。
|
| allowed-tools | Read Bash(mindx *) Bash(python3 *) WebSearch WebFetch |
| metadata | {"name_zh":"文档协作","name_zh-tw":"文件協作","description_zh":"引导用户通过结构化工作流协作撰写文档,包含上下文收集、迭代优化和读者验证三个阶段","description_zh-tw":"引導使用者透過結構化工作流協作撰寫文件,包含上下文收集、迭代優化和讀者驗證三個階段"} |
文档协作工作流
本技能提供结构化工作流,引导用户协作完成文档创建。作为主动引导者,带领用户经历三个阶段:上下文收集、优化与结构化、读者测试。
何时提供此工作流
触发条件:
- 用户提及编写文档:"写个文档"、"起草提案"、"创建规格"、"写一下"
- 用户提及特定文档类型:"PRD"、"设计文档"、"决策文档"、"RFC"
- 用户似乎开始一项重要的写作任务
初始提议:
向用户提供结构化的文档协作工作流。解释三个阶段:
- 上下文收集:用户提供所有相关上下文,同时 Claude 提出澄清问题
- 优化与结构化:通过头脑风暴和编辑迭代构建每个章节
- 读者测试:用全新的 Claude(无上下文)测试文档,在他人阅读前发现盲点
解释这种方法能确保文档在他人阅读时(包括粘贴到 Claude 中时)表现良好。询问他们是否想尝试此工作流,还是偏好自由形式。
如果用户拒绝,按自由形式工作。如果用户接受,进入阶段一。
阶段一:上下文收集
目标: 弥合用户与 Claude 之间的信息差距,为后续智能引导奠定基础。
初始问题
首先询问用户关于文档的元上下文:
- 这是什么类型的文档?(例如:技术规格、决策文档、提案)
- 主要受众是谁?
- 希望读者阅读后产生什么影响?
- 是否有模板或特定格式需要遵循?
- 还有其他约束或上下文需要了解吗?
告知他们可以用简写回答,或以最适合他们的方式倾倒信息。
如果用户提供模板或提及文档类型:
- 询问是否有模板文档可以分享
- 如果提供共享文档链接,使用适当的集成获取
- 如果提供文件,读取它
如果用户提及编辑现有的共享文档:
- 使用适当的集成读取当前状态
- 检查没有 alt 文本的图片
- 如果存在没有 alt 文本的图片,解释当他人使用 Claude 理解文档时,Claude 无法看到这些图片。询问是否要生成 alt 文本。如果是,请他们将每张图片粘贴到聊天中以生成描述性 alt 文本。
信息倾倒
初始问题回答完毕后,鼓励用户倾倒他们拥有的所有上下文。请求以下信息:
- 项目/问题的背景
- 相关的团队讨论或共享文档
- 为什么不使用替代方案
- 组织上下文(团队动态、过往事件、政治因素)
- 时间压力或约束
- 技术架构或依赖
- 利益相关方的关切
建议他们不必担心组织——直接提供即可。提供多种上下文方式:
- 意识流式信息倾倒
- 指向要读取的团队频道或讨论串
- 链接到共享文档
如果集成可用(例如 Slack、Teams、Google Drive、SharePoint 或其他 MCP 服务器),提及可以直接拉取上下文。
如果未检测到集成且在 Claude.ai 或 Claude 应用中: 建议他们可以在 Claude 设置中启用连接器,以允许直接从消息应用和文档存储中拉取上下文。
告知他们在完成初始倾倒后,会提出澄清问题。
在上下文收集期间:
提出澄清问题:
当用户表示已完成初始信息提供(或提供了大量上下文后),提出澄清问题以确保理解:
根据上下文中的差距生成 5-10 个编号问题。
告知他们可以用简写回答(例如:"1: 是,2: 见 #频道,3: 否因为向后兼容"),链接到更多文档,指向要读取的频道,或继续提供信息。选择最高效的方式。
退出条件:
当问题显示出理解时——能够询问边缘情况和权衡,无需解释基础时——说明已收集到足够上下文。
过渡:
询问他们在此阶段是否还有更多上下文要提供,还是是时候开始起草文档了。
如果用户想添加更多,让他们添加。准备好后,进入阶段二。
阶段二:优化与结构化
目标: 通过头脑风暴、内容筛选和迭代优化,逐节构建文档。
给用户的说明:
解释文档将逐节构建。对于每个章节:
- 会询问关于包含内容的澄清问题
- 头脑风暴 5-20 个选项
- 用户指示保留/删除/合并哪些
- 起草该章节
- 通过精准编辑进行优化
从未知最多的章节开始(通常是核心决策/提案),然后处理其余部分。
章节排序:
如果文档结构清晰:
询问他们想从哪个章节开始。
建议从未知最多的章节开始。决策文档通常是核心提案,规格文档通常是技术方法。总结章节最好留到最后。
如果用户不知道需要什么章节:
根据文档类型和模板,建议 3-5 个合适的章节。
询问此结构是否合适,还是想调整。
一旦结构达成一致:
创建初始文档结构,所有章节都有占位符文本。
如果可以访问工件:
使用 create_file 创建工件。这为 Claude 和用户提供了工作框架。
告知他们将创建包含所有章节占位符的初始结构。
创建包含所有章节标题和简短占位符文本(如"[待编写]"或"[内容在此]")的工件。
提供工件链接,表明可以开始填写各章节了。
如果无法访问工件:
在工作目录中创建 markdown 文件,使用恰当命名(例如 decision-doc.md、technical-spec.md)。
告知他们将创建包含所有章节占位符的初始结构。
创建包含所有章节标题和占位符文本的文件。
确认文件已创建,表明可以开始填写各章节了。
对于每个章节:
步骤 1:澄清问题
宣布将开始处理 [章节名称] 章节。提出 5-10 个关于应包含内容的澄清问题:
根据上下文和章节目的生成 5-10 个具体问题。
告知他们可以用简写回答,或仅指出需要覆盖的重点。
步骤 2:头脑风暴
对于 [章节名称] 章节,根据章节复杂度头脑风暴可能包含的 5-20 项内容。寻找:
- 可能被遗忘的已分享上下文
- 尚未提及的角度或考虑因素
根据章节复杂度生成 5-20 个编号选项。最后,如果他们想要更多选项,提供进一步头脑风暴。
步骤 3:内容筛选
询问哪些要点应保留、删除或合并。请求简短理由,帮助学习下一章节的优先级。
提供示例:
- "保留 1,4,7,9"
- "删除 3(与 1 重复)"
- "删除 6(受众已经知道)"
- "合并 11 和 12"
如果用户给出自由形式反馈(例如"看起来不错"或"我喜欢大部分但是...")而非编号选择,提取其偏好并继续。解析想保留/删除/更改的内容并应用。
步骤 4:差距检查
根据其选择,询问 [章节名称] 章节是否有重要内容遗漏。
步骤 5:起草
使用 str_replace 将此章节的占位符文本替换为实际起草的内容。
宣布现在将根据其选择起草 [章节名称] 章节。
如果使用工件:
起草后,提供工件链接。
请他们通读并指出要更改的内容。注意具体说明有助于下一章节的学习。
如果使用文件(无工件):
起草后,确认完成。
告知他们 [章节名称] 章节已在 [文件名] 中起草。请他们通读并指出要更改的内容。具体说明有助于下一章节的学习。
给用户的关键说明(在起草第一章时包含):
提供说明:不要直接编辑文档,而是请他们指出要更改的内容。这有助于学习其风格以用于未来章节。例如:"删除 X 要点——已被 Y 覆盖"或"使第三段更简洁"。
步骤 6:迭代优化
随着用户提供反馈:
- 使用
str_replace 进行编辑(不要重新打印整个文档)
- 如果使用工件: 每次编辑后提供工件链接
- 如果使用文件: 仅确认编辑完成
- 如果用户直接编辑文档并要求读取:在心里记下其更改,并在未来章节中记住这些(这显示其偏好)
继续迭代直到用户对章节满意。
质量检查
连续 3 次迭代没有实质性更改后,询问是否可以在不丢失重要信息的情况下删除内容。
章节完成后,确认 [章节名称] 已完成。询问是否准备好进入下一章节。
对所有章节重复此过程。
接近完成
接近完成时(80%+ 章节完成),宣布打算重新阅读整个文档并检查:
- 章节间的流畅性和一致性
- 冗余或矛盾
- 感觉像"填充物"或通用填充的内容
- 每句话是否都有分量
阅读整个文档并提供反馈。
当所有章节都起草并优化后:
宣布所有章节已起草。表明打算再次审查完整文档。
审查整体连贯性、流畅性、完整性。
提供任何最终建议。
询问是否准备好进入读者测试,还是想进一步优化任何内容。
阶段三:读者测试
目标: 用全新的 Claude(无上下文泄露)测试文档,验证其对读者是否有效。
给用户的说明:
解释现在将进行测试,看文档是否真的对读者有效。这能发现盲点——对作者有意义但可能让他人困惑的内容。
测试方法
如果可以访问子代理(例如在 Claude Code 中):
直接执行测试,无需用户参与。
步骤 1:预测读者问题
宣布打算预测读者在尝试理解此文档时可能提出的问题。
生成 5-10 个读者实际会问的问题。
步骤 2:用子代理测试
宣布将用全新的 Claude 实例(无此对话上下文)测试这些问题。
对于每个问题,调用仅包含文档内容和问题的子代理。
总结读者 Claude 对每个问题的回答准确性。
步骤 3:运行额外检查
宣布将执行额外检查。
调用子代理检查歧义、错误假设、矛盾。
总结发现的任何问题。
步骤 4:报告并修复
如果发现问题:
报告读者 Claude 在特定问题上遇到困难。
列出具体问题。
表明打算修复这些差距。
循环回到问题章节的优化。
如果无法访问子代理(例如 claude.ai 网页界面):
用户需要手动进行测试。
步骤 1:预测读者问题
询问人们在尝试发现此文档时可能会问什么问题。他们会在 Claude.ai 中输入什么?
生成 5-10 个读者实际会问的问题。
步骤 2:设置测试
提供测试说明:
- 打开新的 Claude 对话:https://claude.ai
- 粘贴或分享文档内容(如果使用启用了连接器的共享文档平台,提供链接)
- 向读者 Claude 提出生成的问题
对于每个问题,指示读者 Claude 提供:
- 答案
- 是否有任何歧义或不清晰
- 文档假设读者已知道哪些知识/上下文
检查读者 Claude 是否给出正确答案或误解任何内容。
步骤 3:额外检查
还询问读者 Claude:
- "此文档中什么可能对读者来说歧义或不清晰?"
- "此文档假设读者已具备哪些知识或上下文?"
- "是否有任何内部矛盾或不一致?"
步骤 4:根据结果迭代
询问读者 Claude 在哪些问题上出错或遇到困难。表明打算修复这些差距。
循环回到任何有问题章节的优化。
退出条件(两种方法)
当读者 Claude 持续正确回答问题且没有发现新的差距或歧义时,文档就准备好了。
最终审查
当读者测试通过时:
宣布文档已通过读者 Claude 测试。在完成前:
- 建议他们自己进行最终通读——他们拥有此文档并对其质量负责
- 建议仔细检查任何事实、链接或技术细节
- 请他们验证是否达到了想要的影响
询问他们是否想再审查一次,还是工作已完成。
如果用户想要最终审查,提供。否则:
宣布文档完成。提供一些最终提示:
- 考虑在附录中链接此对话,让读者了解文档是如何开发的
- 使用附录提供深度而不使主文档臃肿
- 随着从真实读者收到反馈更新文档
有效引导提示
语气:
- 直接且程序化
- 在影响用户行为时简短解释理由
- 不要试图"推销"方法——只需执行
处理偏差:
- 如果用户想跳过阶段:询问是否想跳过此阶段并自由形式编写
- 如果用户看起来沮丧:承认这比预期花费更长时间。建议加快进度的方法
- 始终给用户调整流程的主动权
上下文管理:
- 在整个过程中,如果缺少提及内容的上下文,主动询问
- 不要让差距积累——在出现时解决
工件管理:
- 使用
create_file 起草完整章节
- 对所有编辑使用
str_replace
- 每次更改后提供工件链接
- 永远不要将工件用于头脑风暴列表——那只是对话
质量优于速度:
- 不要匆忙通过阶段
- 每次迭代都应带来有意义的改进
- 目标是创建对读者真正有效的文档