改动会议简报

目标是让第一次听到这个需求的人，在 20～40 秒内明白：解决了什么问题、原逻辑为什么会出问题、这次怎么处理。不是复述开发过程，也不是念 PR 文件清单。

输入优先级

优先读取用户提供的事实材料：

1. review-handoff 生成的 Review 说明；
2. 需求/缺陷文档和 PR；
3. 用户口述的背景、问题、根因与方案；
4. 当前仓库真实 diff、测试和可用运行时证据。

能从材料中确认的事实先自行确认。输入存在矛盾时，以当前代码、不可变 diff、运行时事实和权威需求为准；无法核验时使用保守表达或指出缺失，不把猜测包装成已解决。

默认输出

只输出三句或一小段，默认约 100～180 个汉字：

问题：<什么场景下出现什么问题，造成什么影响>。

改之前：<系统原来按什么逻辑处理，缺少什么条件或状态，为什么会产生问题>。

这次修改：<现在在哪个关键节点做了什么，使结果恢复正确；必要时说明正常流程不受影响>。

用户要求“只要一段”时合并为连续段落：

这次解决的是……问题。原来的逻辑在……时会……，因为……，导致……。现在改为……，从而……，同时保持……不变。

不要在默认输出前加标题、总结、注意事项或验证清单。不要额外生成 Markdown 文件，除非用户明确要求保存。

压缩方法

1. 找业务主语

先确定听众需要认识的功能，不从函数名或仓库名开场。例如：

• 写“定时任务完成状态”，不写“update_task_status()”；
• 写“下线资产的访问门禁”，不写“LoadStatusByResource”；
• 写“模型选择理由展示”，不写“fa_model_policy.guidance”。

只有技术名词是团队统一称呼且删除后会失真时才保留，并在首次出现时补半句人话。

2. 保留一条因果链

每部分只承担一个职责：

• 问题：场景、偏离、影响；
• 改之前：原机制、缺口、为什么触发偏离；
• 这次修改：改动节点、新机制、为什么能解决。

删掉排查过程、候选方案、文件清单、逐步测试、提交历史和没有改变听众理解的边界案例。

3. 避免空话

不要只写：

• “优化了相关逻辑”；
• “提升了稳定性和用户体验”；
• “增加了一些判断”；
• “从根本上彻底解决”。

改成可观察表达，例如：“任务结束时统一以最终执行结果回填状态，避免请求已发出但实际未完成时被提前标记成功。”

4. 控制确定性

• 已由测试或运行证据证明时可以说“解决”；
• 只有静态代码和方案时说“这次改为……，用于避免……”；
• 根因尚未闭合时不要编造“因为”，应先指出还缺哪项关键事实，或在用户只需临时口径时使用“当前判断是……”。

可选口径

用户说明听众后调整词汇，不改变三段结构：

• 面向产品/管理者：突出用户影响、状态变化和结果；
• 面向研发：可保留一个关键机制名，但不讲代码实现；
• 上线会议：补一句影响范围或正常路径保持不变；总长度仍控制在约 40 秒内；
• 日报/周报：使用书面语，但不扩展成完整 Review 文档。

完成检查

交付前只问四件事：

• 第一次听的人知道是哪块功能吗？
• 能听出原逻辑为什么会造成问题吗？
• 能听出这次改动截断了哪一步吗？
• 是否删掉了不会改变理解的技术细节？

若答案都是“是”，立即交付，不再扩写。