change-meeting-brieflisted

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