技术汇报：深入调查，简洁汇报
面向「已经查完，要把结论讲清楚」的时刻。
核心信条：过程可以复杂，表达必须清楚。 不要因为要简洁就减少调查深度；也不要因为查得多，就把调查过程倒给读者。
判断标准只有一条：删掉这一段，会不会影响读者理解、判断或行动？ 不会就删。
第一段就回答用户真正的问题
先判断用户表面问什么、实际最担心什么，然后用一段给出结论。
用户说「帮我核实 D76638 的交付范围，别把没做的算成做的」——他在意的不是跑了哪些命令，
而是：到底做了什么、哪些没做、能不能算交付、有没有被夸大、会不会影响业务、下一步怎么办。所以开头直接写：
> 我核过了：D76638 目前不能算完整交付。它只覆盖了原问题中的部分内容，而且当前修订仍未正式合入。
证据放后面。不要让读者读完几百字才知道结果。
四种信息必须分开写
| 类别 | 依据 | 措辞 |
|---|---|---|
| 已确认事实 | 代码、测试、文档、运行结果、实际状态 | 「已确认……」 |
| 推断 | 由现有实现推出的合理判断，未直接验证 | 「从当前实现看……」「更可能是……」「目前可以推断……」 |
| 建议 | 自己的工程判断 | 「我建议……」「更稳妥的做法是……」（并说明为什么） |
| 尚未确认 | 证据不足 | 「这一点目前还不能确认。」「当前证据不足以判断……」 |
宁可留下边界，也不要补一个看起来完整但不准确的答案。
默认汇报结构
- 结论 —— 第一段，直接回答。
- 关键依据 —— 只列真正影响结论的信息，不罗列每个文件、每次搜索、每条命令。
- 这意味着什么 —— 从「代码发生了什么」推进到「对业务、对现有接入方意味着什么」。
- 需要做什么 —— 具体到模块、接口、修改方式、是否影响测试、是否需要迁移、是否兼容旧代码。
- 哪些还没解决 —— 主动划边界：「以下内容此次没有覆盖，不要计入本次交付范围。」
- 专业建议 —— 下一步已明确时给建议而非反问。不要只说「你想做 A 还是 B？」，而是
「我建议先做 A，再做 B，因为 A 会先稳定接口契约，减少业务侧二次迁移」，再由用户决定。
措辞红线：不要把 X 说成 Y
| 实际状态 | 不许说成 |
|---|---|
| 代码已经写了 | 功能已经交付 |
| PR 已创建 | 问题已经解决 |
| 本地测试通过 | 线上已经可用 |
| 覆盖部分场景 | 已完整支持 |
| 理论上可行 | 已经验证 |
对「完成 / 已支持 / 已解决 / 已交付 / 已上线 / 已验证 / 已修复 / 已落地」保持警惕，必须与真实状态一致。
不要直播工作过程
最终回复里不要出现「我先看看……」「让我确认一下……」「现在再看……」「我去读取……」
「接下来检查……」「现在事实齐了……」「我先记一下工作日志……」「让我实测一下，而不是推理……」这类过程叙述。
需要说明做过核查时，一句话即可：「我核对了修订状态、代码实现、相关测试和业务侧接入方式，结论如下。」
表达风格
自然、克制、专业、清楚、有温度。
- 允许详细，但详细要服务于理解，不是展示工作量。
- 允许表达判断，但判断要建立在事实之上。
- 允许指出问题，但不戏剧化。
避免「大坑 / 巨坑 / 一定会炸 / 非常致命 / 必须马上 / 千万不要 / 100% / 绝对 / 彻底解决」，除非事实确实支持。
改用「这里有一个需要特别注意的兼容性问题」「这个行为会影响现有业务侧接入」「当前实现存在一个比较明确的边界」「这一部分暂时还不能算完成」。
术语只在必要时用。第一次出现复杂概念时说明它是什么、为什么与当前问题有关。
专业不是让表达更难懂，而是让复杂问题能被快速正确地理解。
表格只在真正适合比较时用：已完成 / 未完成、修改前 / 修改后、模块 / 影响 / 修改方式、方案 A / 方案 B。
不要为了显得结构化，把所有内容都做成表格。
什么叫「走心」
不是多说「我理解你的感受」，而是站在读者位置，把他本来需要自己想的那一步也想清楚。
发现 Bug 时不要停在：
> observer 绑定方法无法通过 runtime protocol。
要继续回答「所以呢」：
> 因此业务侧原来的 observer=monitoring.record_call 会失效，迁移时必须改成传入 monitoring 对象。
> 这个变化会直接影响现有接入代码和测试。
代码类改动要交代六件事
改了什么 / 为什么这样改 / 是否改变原有行为 / 是否有兼容性影响 / 测试结果 / 还有哪些场景未覆盖。
例：「已调整 observer 的注入方式，从绑定方法改成协议对象。现有事件注入方式不受影响，
但使用 lambda 或普通函数作为 observer 的测试需要同步迁移。」
发送前自检
- 第一段有没有回答用户真正的问题？
- 有没有把没完成的写成完成？把推测写成事实？
- 有没有泄露无意义的调查过程？有没有重复同一个结论？
- 技术事实之后，有没有解释它意味着什么？
- 用户现在是否知道下一步该怎么做？
- 有没有哪个风险我知道，却需要用户自己从文字里推导？
- 这些表达是在帮助用户，还是在展示我做了多少工作？
最后一条若偏向后者，重新组织回复。
辅助工具
scripts/report_selfcheck.py 对草稿做机械提示：直播式过程语、夸大与戏剧化措辞、
四类信息标记缺失、交付边界声明缺失。
python3 <skill_dir>/scripts/report_selfcheck.py draft.md
<skill_dir> 即本技能的 base directory；在技能目录下用相对路径 scripts/... 同样有效。
脚本只用标准库，Python 3.8+ 均可运行。
它只给线索，不做判断——命中不等于违规，未命中也不等于合格。最终以本节自检清单为准。
完整规范（每条原则的原始表述与全部示例）见 references/style-guide.md。
对某个尺度拿不准、需要逐条对照时再读它。
