Zhangs-11 改动会议简报
目标是让第一次听到这个需求的人，在 20～40 秒内明白：解决了什么问题、原逻辑为什么会出问题、这次怎么处理。不是复述开发过程，也不是念 PR 文件清单。
输入优先级
优先读取用户提供的事实材料：
review-handoff生成的 Review 说明；- 需求/缺陷文档和 PR；
- 用户口述的背景、问题、根因与方案；
- 当前仓库真实 diff、测试和可用运行时证据。
能从材料中确认的事实先自行确认。输入存在矛盾时，以当前代码、不可变 diff、运行时事实和权威需求为准；无法核验时使用保守表达或指出缺失，不把猜测包装成已解决。
默认输出
只输出三句或一小段，默认约 100～180 个汉字：
问题：<什么场景下出现什么问题，造成什么影响>。
改之前：<系统原来按什么逻辑处理，缺少什么条件或状态，为什么会产生问题>。
这次修改：<现在在哪个关键节点做了什么，使结果恢复正确；必要时说明正常流程不受影响>。
用户要求“只要一段”时合并为连续段落：
这次解决的是……问题。原来的逻辑在……时会……，因为……，导致……。现在改为……，从而……，同时保持……不变。
不要在默认输出前加标题、总结、注意事项或验证清单。不要额外生成 Markdown 文件，除非用户明确要求保存。
压缩方法
1. 找业务主语
先确定听众需要认识的功能，不从函数名或仓库名开场。例如：
- 写“定时任务完成状态”，不写“
update_task_status()”； - 写“下线资产的访问门禁”，不写“
LoadStatusByResource”； - 写“模型选择理由展示”，不写“
fa_model_policy.guidance”。
只有技术名词是团队统一称呼且删除后会失真时才保留，并在首次出现时补半句人话。
2. 保留一条因果链
每部分只承担一个职责：
- 问题：场景、偏离、影响；
- 改之前：原机制、缺口、为什么触发偏离；
- 这次修改：改动节点、新机制、为什么能解决。
删掉排查过程、候选方案、文件清单、逐步测试、提交历史和没有改变听众理解的边界案例。
3. 避免空话
不要只写：
- “优化了相关逻辑”；
- “提升了稳定性和用户体验”；
- “增加了一些判断”；
- “从根本上彻底解决”。
改成可观察表达，例如：“任务结束时统一以最终执行结果回填状态，避免请求已发出但实际未完成时被提前标记成功。”
4. 控制确定性
- 已由测试或运行证据证明时可以说“解决”；
- 只有静态代码和方案时说“这次改为……，用于避免……”；
- 根因尚未闭合时不要编造“因为”，应先指出还缺哪项关键事实，或在用户只需临时口径时使用“当前判断是……”。
可选口径
用户说明听众后调整词汇，不改变三段结构：
- 面向产品/管理者：突出用户影响、状态变化和结果；
- 面向研发：可保留一个关键机制名，但不讲代码实现；
- 上线会议：补一句影响范围或正常路径保持不变；总长度仍控制在约 40 秒内；
- 日报/周报：使用书面语，但不扩展成完整 Review 文档。
完成检查
交付前只问四件事：
- 第一次听的人知道是哪块功能吗？
- 能听出原逻辑为什么会造成问题吗？
- 能听出这次改动截断了哪一步吗？
- 是否删掉了不会改变理解的技术细节？
若答案都是“是”，立即交付，不再扩写。