会后不再追问：把讨论稿整理成可确认的行动单

会议结束后，最容易出现的分歧不是“聊过什么”，而是“到底决定了没有”。让 AI 整理记录时，可以把交付目标从摘要改成行动单：每一项都能找到依据，说明谁需要确认、何时需要处理，以及缺少什么条件。

先把发言分成三种状态

建议是供讨论的方向，决定是会议已明确采用的安排，待确认事项则还没有形成结论。请模型分别整理，避免把“可以考虑下周上线”写成“下周上线”。若原记录缺少明确确认语句，就保留为待定。发言者提出某件事，也不代表他已被分配为执行人。

“优化体验”范围太大，难以判断结束；“整理登录失败的三类反馈，提交一页排查清单”则有可验收的产物。行动名称应包含动作和对象，必要时补交付物。不要让模型为了显得具体而擅自添加范围，只能在材料已支持的内容中提炼，不够清楚的部分转成问题。

如果有人说“我们这边看看”，先记录团队层面的承接意向，再询问具体负责人。期限也要区分“本周讨论”“本周提交”和“本周完成”。原文只有相对日期时，需结合会议日期解释，并检查跨月或节假日的歧义。无法确认时保留原说法，让参会者做最终确认。

假设设计修改需要先拿到业务规则，清单应标明依赖，而不是只写一个截止日。再把尚未获得的材料或授权列成单独待办，避免负责人在无法开始的情况下被认为没有推进。模型可以帮助发现文本中的依赖关系，但不能把它推断出的顺序当成参会者已经同意的安排。

初稿应让相关人员核对各自条目，尤其是新增责任、期限和费用。修订时保留状态变化，例如由待确认变为已确认，并注明实际确认时间。不要在旧记录里悄悄覆盖分歧，让后续读者以为会议当时已经达成一致。涉及外部发送时，还需按你的授权范围执行。

跟进时可以列出已完成产物、仍受阻的条件和需要重新决定的事项。把原记录与本周状态分开，避免每次汇报重新改写历史。对于完成状态，检查实际文件或确认记录，不凭模型的乐观表述标记完成。这样行动单既能用于推进，也能解释为什么某项任务需要调整。