一份活动介绍交给三个人看，有人回复“第二段要改”，有人直接发回新文件，还有人只说“还是上一版好”。负责合稿的人很快就会遇到两个问题：大家看的是否同一份，以及哪些修改已经被采纳。嗨信可以承载讨论，稿件本身仍需要一套简单的人工约定。下面以一份虚构的社区活动介绍为例，说明怎样把一轮改稿做完整。
一、开始前固定本轮稿件和反馈范围
发起人先发出本轮唯一的参考稿，写明文件名、日期、轮次和反馈截止时间，例如：“请看《秋日阅读活动介绍_20261020_R1》，本轮只核对活动事实和报名说明，请于10月21日18:00前反馈，措辞润色放到下一轮。”时间均指同一时区；跨地区协作时应补充时区。
同时指定一名合稿人。其他参与者提交意见，合稿人汇总后再发下一轮，能减少几份修改稿同时流转的情况。文件名中的轮次用来区分讨论对象；它不会自动证明哪份有效，仍须在消息里明确说明。
二、把“哪里不好”写成可处理的意见
一条意见最好包含四部分：位置、原文短句、问题、建议。页码会随着排版改变，单用“第2页”不够稳妥；可以加上小标题或段落开头几个字。引用原文只取定位所需的短句，避免把整篇文稿反复贴进聊天。
例如：“意见A｜报名说明，第2段，‘现场领取材料’：没有说清是否提前预约。建议改为‘报名成功后，活动当天凭确认信息领取材料’；预约规则请负责人核实。”如果事实尚未确定，就标为“待核实”，不要直接改成肯定表述。用A、B、C这样的短编号，后续回复即可准确指向同一问题。
反馈先定位到原文，再解释原因和建议（原创示意图）。
三、合并意见时区分冲突和遗漏
合稿人可按“编号—处理结果—原因”回复：A已按负责人确认结果修改；B暂不采纳，因为本轮不调整宣传语；C待核实，暂保留原文并列入待办。未采纳不等于忽略，写出原因能避免同一建议在下一轮重新出现。
遇到互相冲突的意见，不要把两个版本机械拼在一起。例如一人希望报名说明更短，另一人要求增加领料条件，可先确认必须告知的规则，再压缩其他语句。涉及事实、对外承诺或活动规则，由对应负责人给出依据；纯表达偏好再由约定的定稿人决定。
逐条回应意见，保留清楚的处理结果（原创示意图）。
四、发新稿时附一份简短的变化说明
下一轮文件可命名为《秋日阅读活动介绍_20261021_R2》，并说明：“R2替代R1；已补充预约条件、调整领料说明；集合时间未改；意见C仍待负责人确认。”不要只发一个附件再说“更新了”。变化说明帮助核对者把注意力放在本轮真正发生变化的地方。
如果有人在旧稿上继续反馈，先确认其参考轮次，再把仍有效的意见转入当前轮次。不要直接认定对方看漏，也不要为了合并一个小改动重新传播旧文件。个人保存的旧稿可保留作对照，但对外使用哪一份必须另行说清。
五、定稿前回读关键事实和待办
定稿人把活动名称、时间地点、参加条件、联系方式等关键事实回读一次，并确认所有“待核实”项已有结论。对外发布前还应检查附件是否对应当前文稿、链接是否能打开，以及示例人物和内部批注是否已经移除。
收尾消息可以写：“R3已定稿，用于本次活动介绍发布；A至D均已处理，无待确认项。后续如规则改变，请先说明变更，再重新确认稿件。”如果仍有未决事项，就明确它们会阻碍哪一步，不急着标“最终版”。一轮改稿完成的标志，是当前稿、处理结果和使用范围都能被参与者准确指出。
定稿确认同时覆盖内容、待办和使用范围（原创示意图）。
这套方法依靠文件命名和文字确认即可实施，不预设嗨信提供在线协同编辑或自动版本合并功能。