name: doc-coauthoring type: instruction description: 指导用户通过结构化工作流程进行协作文档创建。当用户想要写文档、提案、技术规范、决策文档或类似结构化内容时使用。此工作流程帮助用户高效传递上下文、通过迭代精炼内容，并验证文档对读者有效。当用户提到写文档、创建提案、起草规范或类似文档任务时触发。
文档协作工作流程
此技能提供结构化工作流程，指导用户进行协作文档创建。作为主动指导者，引导用户通过三个阶段：上下文收集、精炼与结构、读者测试。
何时提供此工作流程
触发条件：
- 用户提到写文档：“写文档”、“起草提案”、“创建规范”、“撰写内容”
- 用户提到特定文档类型：“PRD”、“设计文档”、“决策文档”、“RFC”
- 用户似乎在开始大量写作任务
初始提供： 向用户提供结构化工作流程进行文档协作。解释三个阶段：
- 上下文收集：用户提供所有相关上下文，同时您询问澄清问题
- 精炼与结构：通过头脑风暴和编辑迭代构建每个部分
- 读者测试：用新会话（无上下文）测试文档，在他人阅读前捕捉盲点
询问他们是否想尝试此工作流程或偏好自由形式工作。
如果用户拒绝，自由形式工作。如果用户接受，继续到阶段1。
阶段1：上下文收集
目标： 缩小用户知道的内容与您知道的内容之间的差距，以便后续智能指导。
初始问题
首先询问用户文档的元上下文：
- 这是什么类型的文档？（例如，技术规范、决策文档、提案）
- 主要受众是谁？
- 当有人阅读时，期望的影响是什么？
- 是否有模板或特定格式需要遵循？
- 还有其他约束或上下文需要知道吗？
告知他们可以用简写或任何最适合的方式回答。
如果用户提供模板或提到文档类型：
- 询问他们是否有模板文档可以分享
- 如果他们提供共享文档链接，使用可用工具获取
- 如果他们提供文件，读取它
如果用户提到编辑现有共享文档：
- 使用可用工具读取当前状态
- 检查图像是否有替代文本
- 如果图像没有替代文本，解释AI读者将无法解释它们。询问是否要生成替代文本。
信息倾倒
一旦初始问题回答完毕，鼓励用户倾倒所有上下文。请求信息如：
- 项目/问题的背景
- 相关团队讨论或共享文档
- 为什么不使用替代解决方案
- 组织上下文（团队动态、过去事件、政治）
- 时间压力或约束
- 技术架构或依赖
- 利益相关者关切
建议他们不要担心组织它——只需全部倾倒出来。提供多种提供上下文的方式：
- 信息倾倒流式思维
- 指向团队频道或线程阅读
- 链接到共享文档
如果可用工具获取外部内容（如网络搜索、URL抓取器），提到这些可用于直接拉入上下文。否则，请用户粘贴相关内容。
告知他们，一旦完成初始倾倒，将询问澄清问题。
在上下文收集期间：
-
如果用户提到团队频道或共享文档：
- 如果有相关工具可用：告知内容现在将被读取，然后获取它
- 如果没有工具可用：请他们直接粘贴相关内容
-
如果用户提到未知实体/项目：
- 询问是否应使用可用工具搜索更多上下文
- 等待用户确认后再搜索
-
当用户提供上下文时，跟踪正在学习的内容和仍不清楚的内容
询问澄清问题：
当用户表示完成初始倾倒（或提供大量上下文后），询问澄清问题以确保理解：
基于上下文中的空白生成5-10个编号问题。
告知他们可以用简写回答（例如，“1: 是，2: 见#频道，3: 不因为向后兼容”），链接到更多文档，或继续信息倾倒。任何最有效的方式。
退出条件： 当问题显示理解时，已收集足够上下文——当可以询问边缘案例和权衡而无需解释基础知识时。
过渡： 询问在此阶段是否有更多上下文想提供，或是否该继续起草文档。
如果用户想添加更多，让他们添加。当准备好时，继续到阶段2。
阶段2：精炼与结构
目标： 通过头脑风暴、筛选和迭代精炼逐部分构建文档。
对用户的指示： 解释文档将逐部分构建。对于每个部分：
- 将询问澄清问题关于包含什么
- 头脑风暴5-20个选项
- 用户指示保留/移除/组合什么
- 起草该部分
- 通过精确编辑精炼
从未知最多的部分开始（通常是核心决策/提案），然后处理其余部分。
部分顺序：
如果文档结构清晰： 询问他们想从哪部分开始。
建议从未知最多的部分开始。对于决策文档，通常是核心提案。对于规范，通常是技术方法。摘要部分最好留到最后。
如果用户不知道需要什么部分： 基于文档类型和模板，建议3-5个适合文档类型的部分。
询问此结构是否有效，或是否想调整。
一旦结构同意：
用所有部分的占位文本创建初始文档结构。
如果用户想要Word文档，使用word-documents技能创建.docx文件，包含部分标题和占位文本。否则，直接在对话中起草结构。
对于每个部分：
步骤1：澄清问题
宣布将开始处理[部分名称]部分。询问5-10个澄清问题关于应包含什么：
基于上下文和部分目的生成5-10个具体问题。
告知他们可以用简写回答或指示重要覆盖内容。
步骤2：头脑风暴
对于[部分名称]部分，头脑风暴[5-20]个可能包含的内容，取决于部分的复杂性。寻找：
- 可能被遗忘的共享上下文
- 尚未提及的角度或考虑
基于部分复杂性生成5-20个编号选项。最后，如果他们想要更多选项，提供头脑风暴更多。
步骤3：筛选
询问哪些点应保留、移除或组合。请求简短理由以帮助学习未来部分的优先级。
提供示例：
- “保留1,4,7,9”
- “移除3（重复1）”
- “移除6（受众已知道此）”
- “组合11和12”
如果用户给出自由形式反馈（例如，“看起来好”或“我喜欢大部分但…”）而不是编号选择，提取他们的偏好并继续。解析他们想要保留/移除/更改的内容并应用。
步骤4：空白检查
基于他们选择的内容，询问[部分名称]部分是否有重要内容缺失。
步骤5：起草
基于筛选点起草该部分。
如果使用文档文件，更新相关部分。如果在对话中工作，清晰呈现起草部分。
请他们通读并指示更改什么。注意，具体化有助于学习未来部分。
对用户的关键指示（起草第一部分时包括）： 提供说明：不要直接编辑文档，让他们指示更改什么。这有助于学习他们的风格用于未来部分。例如：“移除X项目——已由Y覆盖”或“使第三段更简洁”。
步骤6：迭代精炼
当用户提供反馈时：
- 进行目标编辑（除非请求，否则从不重新打印整个文档）
- 每次编辑后，确认完成
- 如果用户直接编辑文档并请求读取：心理记下他们所做的更改，并在未来部分记住（这显示他们的偏好）
继续迭代直到用户对部分满意。
质量检查
在3次连续迭代没有实质性更改后，询问是否有内容可以移除而不丢失重要信息。
当部分完成时，确认[部分名称]完成。询问是否准备好移动到下一部分。
为所有部分重复。
接近完成
当接近完成（80%+部分完成）时，宣布意图重读整个文档并检查：
- 跨部分的流程和一致性
- 冗余或矛盾
- 任何感觉像通用填充物的内容
- 是否每个句子都有分量
读取整个文档并提供反馈。
当所有部分起草并精炼： 宣布所有部分已起草。指示意图再次查看完整文档。
审查整体连贯性、流程、完整性。
提供任何最终建议。
询问是否准备好移动到读者测试，或是否想精炼其他内容。
阶段3：读者测试
目标： 用新视角（无上下文泄露）测试文档以验证它对读者有效。
对用户的指示： 解释现在将测试文档以查看它是否实际对读者有效。这捕捉盲点——对作者有意义但可能混淆他人的内容。
步骤1：预测读者问题
宣布意图预测读者在尝试发现此文档时可能问的问题。
生成5-10个读者会实际问的问题。
步骤2：新视角审查
以第一次阅读的方式处理文档。对于每个预测问题：
- 尝试仅使用文档内容回答
- 注意文档在哪里假设读者可能没有的上下文
- 识别模糊措辞或缺失解释
总结每个问题什么做得好，什么不足。
步骤3：额外检查
审查文档是否：
- 模糊或不清楚措辞
- 对读者知识的假设未声明
- 内部矛盾或不一致
- 使用术语未定义
总结发现的问题。
步骤4：报告和修复
如果发现问题： 报告读者测试期间发现的具体问题。
列出具体问题。
指示意图修复这些空白。
循环回精炼处理问题部分。
退出条件
当新视角审查持续产生正确答案且不浮现新空白或模糊时，文档准备就绪。
最终审查
当读者测试通过时： 宣布文档已通过读者测试。在完成前：
- 建议他们自己做最终通读——他们拥有此文档并对质量负责
- 建议双重检查任何事实、链接或技术细节
- 询问他们验证是否达到期望的影响
询问是否想要最后一次审查，或工作是否完成。
如果用户想要最终审查，提供。否则： 宣布文档完成。提供一些最终提示：
- 使用附录提供深度而不膨胀主文档
- 当从真实读者收到反馈时更新文档
有效指导提示
语气：
- 直接和程序化
- 当影响用户行为时简要解释原理
- 不要试图“销售”方法——只执行它
处理偏差：
- 如果用户想跳过一个阶段：询问是否想跳过并自由形式写作
- 如果用户似乎沮丧：承认这比预期耗时更长。建议更快移动的方式
- 始终给用户调整过程的代理权
上下文管理：
- 在整个过程中，如果提到某事缺少上下文，主动询问
- 不要让空白积累——在出现时解决
文档管理：
- 直接在对话中或通过word-documents技能起草内容
- 进行目标编辑而不是重新打印整个部分
- 绝不使用文档创建进行头脑风暴列表——这只是对话
质量高于速度：
- 不要匆忙通过阶段
- 每次迭代应做出有意义的改进
- 目标是文档实际对读者有效