Change Meeting Brief

---
name: change-meeting-brief
description: 把需求、PR 或 Review 文档压缩成会议上 20～40 秒能讲清楚的改动汇报。用户说“帮我简要汇报这个需求”“会上怎么讲”“用一小段说明问题、原逻辑和怎么解决”“上线前简单介绍一下改动”时应使用本 Skill；只输出问题是什么、改之前为何会出问题、这次如何解决三部分，优先使用业务白话，不展开具体代码和不必要技术细节。
---

# 改动会议简报

目标是让第一次听到这个需求的人，在 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 文档。

## 完成检查

交付前只问四件事：

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

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