你写：「先给我大纲，我确认后再写正文。」模型却直接甩出大纲+全文+总结三件套。你想控过程，它想一次做完。结果你要大段删改，分步的意义全无，还浪费上下文。
一次性倒完，是因为提示里「分步」只是愿望，没有闸门协议。必须写清：本轮只准输出某部分、结尾等待确认词、未确认不得续写。
直接结论
分步输出要靠「闸门式协议」：声明当前步骤编号、允许输出的范围、停止条件、确认口令。例如「只输出第1步大纲，末尾写 WAIT_FOR_OK，在我回复 OK 前不要写正文」。把禁止事项写进硬规则，比礼貌请求有效。
具体做法
我们按步骤协作。硬规则：
- 当前只做步骤1：输出大纲（不超过8条）。
- 禁止输出正文、案例扩写、总结陈词。
- 输出结束后单独一行：WAIT_FOR_OK
- 只有当我回复「OK」或「修改：…」后，你才进入步骤2。
- 若你越权输出，我会要求重来，请严格遵守。
步骤1主题：{…}
步骤2再贴规则摘要，防止它把全文补上。
对爱一次做完的模型可加：字数上限 + 「超出即失败」。
API 场景用 stop 序列或工具调用拆分更稳。
注意点
第一，「可以先……」是软语气，模型常忽略；改用「只准/禁止」。
第二，同轮提太多目标，分步必然失败，一次一事。
第三，确认后不重申边界，它仍可能把后续步骤一次性写完。
把闸门协议做成团队提示词片头，写长文、写方案、写代码评审都能复用。若模型仍越权，立刻新开对话并只贴当前步骤，比在污染上下文里继续劝它更省时间。分步的本质是保留你的决策权，不是让模型表演礼貌。
可直接套用的完整提示词
协议：多步骤任务管理器。
步骤清单：{1大纲 2例证 3正文 4检查}
当前步骤：{N}；只输出该步；结束写 WAIT_FOR_OK。
用户确认词：OK / 修改：… / 跳到步骤X
越权处理：自我删除越权部分并道歉一行，等待确认。
现在执行当前步骤，主题：{…}
一次性倒完有时是因为你在同一条消息里既说「先大纲」又说「全文要包含案例与总结」——模型会理解为最终形态。把最终形态放到步骤清单总览，当前消息只暴露当前步。确认词尽量短且唯一，避免「好的请继续写漂亮一点」被理解成放开限制。
对必须长文的任务，分步仍建议：大纲 → 第一节 → 反馈 → 其余，而不是大纲后直接全文。你的修改权，建立在它还没写完的时候。
闸门协议也可用于代码：先接口草案，确认后再实现。同一套肌肉记忆，跨任务复用。
若网页版总抢跑，把步骤1的提示单独收藏，每次新开聊天只跑一步，物理隔绝最有效。
分步被一次倒完，也常见于你把「最终验收标准」写得太完整，模型以为你要最终件。验收标准可以放在步骤清单注释，当前步只引用「本步完成标准」。例如步骤1完成标准是「8条内大纲且无正文」。完成标准越可检查，越权越少。
协作型写作里，你的确认也要专业：不要只回「继续」，要回「OK，步骤2请写第1节，仍不要写后面」。确认消息同样是提示词。把确认句式固化，团队任何人接手都能控场。