| name | docx-coauthoring |
| description | 文档共创协议:写作/大改类任务的三阶段工作法(补上下文→逐节精修→读者盲测),把"帮我写/重写这篇"变成可审阅的分批协作 —— 起草/重写/扩写类请求先加载。 |
| formats | ["word","docx"] |
| keywords | ["写作","起草","共创","重写","扩写","初稿","帮我写","文案","报告撰写"] |
文档共创协议(写作/大改类任务)
写作类请求的失败模式不是写得差,是信息差:你不知道读者是谁、哪些方案被否过、哪句话有政治敏感。先补齐信息差,再谈聪明的建议。
阶段一:补上下文(动笔前)
- 用 ask_user 一次问清五件套:文档类型 / 目标读者 / 读完希望对方做什么 / 有无模板或范例 / 硬约束(篇幅/语气/截止)
- 鼓励用户不加整理地倾倒背景(项目来龙去脉、被否的方案、干系人顾虑)——速记式回答就够
- 收集够了的判据:你能追问出边界情况和取舍,而不是还在问基础事实
阶段二:骨架先行,逐节精修
- 先用一批 edits 立全文骨架(各级标题 block=h1/h2/h3 + 每节一句占位),交用户审阅定结构,再逐节填充——绝不整篇一次成稿
- 每节的节奏:澄清 → 给 5-10 个编号候选要点让用户 keep/remove/combine(理由记下来,那是他的风格信号)→ 起草替换占位 → 手术式微调
- 从未知最多的节开工(决策文档=核心提案节;规格书=技术方案节);摘要/导语永远最后写
- 用户自己动手改过的句子 = 最强风格样本,后续各节照此校准语气
- 收敛信号:连续几轮只有微调时,主动做减法检查——"哪些内容删了也不损失信息?"
阶段三:读者盲测(交付前建议)
- 预测读者会问的 5-10 个问题,建议用户拿"只看文档、无背景"的视角自测:文档本身答得上来吗?
- 三查:歧义句、只有作者自己懂的隐含假设、跨节矛盾;不达标回炉对应节
- 作者盲区(自己懂所以没写清)只有零上下文测试能抓出来
与审阅机制的配合
- 每节一批 edits,plan 里说明"先立骨架/本批第 N 节",用户逐条接受——分批协议天然适配
- 头脑风暴候选放在 plan/回答里讨论,不要写进文档本体
- 修改一律 quote 锚定的局部替换,绝不重印整篇
反例
- 不问读者是谁就开写;一口气产出全文让用户"看看行不行"
- 把候选清单/思考过程写进正式文稿
- 用户说"差不多了"之后还在大改结构
