追问与迭代

第一条提示词不是最终合同。读完草稿后，把最重要的偏差指出来，通常比重新写一条更长的提示词有效。

把评价改成修改指令

一次优先改一类问题：先改事实与结构，再改语气和措辞。这样更容易判断变化是否有用。

只修改第二节。保留标题、所有金额和其他章节。
第二节先给结论，再给证据；不要增加新的事实。
完成后列出修改点。

拿到结果后，检查“没有要求修改的部分”是否真的保持原样。对关键文件可以用差异比较工具复核。

假设你让它写延期通知，草稿出现三个问题：把预计日期写成了承诺日期、原因解释太长、语气过于生硬。第一轮先纠正日期性质，第二轮压缩背景，最后再调整语气。事实未固定前反复润色，容易让错误以更自然的方式保留下来。

可以这样追问：

保留第一段的项目背景。把“保证周五交付”改为“目前预计周五交付，
最终时间周三确认”。不要新增赔偿或折扣承诺。
先只返回修改后的这一段，等我确认后再整合全文。

局部确认后再合并，适合有严格审核要求的邮件和文档。小任务则可以一次完成，不必机械增加轮次。

先挑选最接近目标的一版作为基准，明确列出它已经做对的地方，以及剩下的一两个缺口。不要把所有历史反馈重新叠加，因为前后要求可能冲突。例如“更详细”和“缩到一半”同时保留，就需要说明哪些内容优先。

如果连续修改都围绕同一个事实错误，应回到源材料核对，而不是继续换表达方式。迭代记录可以简化成“版本、变化、仍待解决的问题”，方便多人共同审阅。

定义完成标准，例如“两个方案、每个不超过 150 字、包含费用和缺点”。达到标准后审阅使用，而不是不断要求“再优化”，让输出逐渐偏离目标。

如果模型开始混用旧数据，先汇总当前已确认版本和不可变约束。必要时新建对话，附上干净的材料与交接摘要。不要把“它在前面答应过”当作一定能保留要求的保证。