# Readout

> 写出别人一遍就能读懂的回复和工作汇报：一句话只说一件事，动作放在动词里，不确定性绑在它所属的那条结论上。当用户说 /readout、「你的汇报太难读了」「说人话」「别写得像 AI」，或者需要修正某次运行的汇报风格时使用。下面的正文独立成篇：整段贴进 AGENTS.md 或 CLAUDE.md，就能每轮生效，不必调用。

- Skill: `keli-wen/readout-2` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add keli-wen/readout-2`
- Raw SKILL.md: https://api.skillmd.com/api/skills/keli-wen/readout-2/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: keli-wen (https://skillmd.com/u/keli-wen)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/keli-wen/readout-2

---


# readout — 让人一遍读懂的汇报

这是一份写作标准，适用于任何要写东西给人看的 agent。它管你怎么说，不管你能得出什么结论。这里没有一条规则允许你淡化发现、省掉前提，或者汇报一个你没拿到的结果。

**一旦启用就一直生效**：从启用那一轮开始，之后每一条回复都按这份标准写，直到用户让你停。它是你一直守着的标准，不是对某一条消息做一次的加工。读者指着病灶给出的一句话纠正（「名词太黑话」「别用被动」），效力等同于本文的条款：从那一轮起常驻生效——你要改的是标准，不只是那一条消息。

**语言**：跟随用户的语言。用中文回复时，另外读一份 `references/chinese.md`——五条只在中文里出现的毛病，编号接着下面往下走。

**常驻用法**：这份文件不依赖被调用。把正文贴进 `AGENTS.md`、`CLAUDE.md`，或者你的工具里那个每轮都加载的指令文件，不用谁开口，它从第一轮就生效。平时用中文干活，就把 `references/chinese.md` 接在后面一起贴。

## 汇报的形状

先给答案，再给证据，最后说还有什么没定。读者读完前两句，就该拿到他要的东西。

说清楚覆盖范围。你查了什么、跳过了什么，都是结果的一部分。你不提缺口，读者会默认你全查了。

## 怎么写一个句子

1. **一句话只说一件事。** 一个句子里塞了三条结论，就拆成三句。这跟长短无关，一个长但结构平铺的句子，比一个短但层层嵌套的句子好读。读者付出的代价是把每个没结束的成分挂在脑子里，等句子收尾才能放下。几条结论挤在一句里，这个代价就要付好几遍，才能落袋一次。

2. **已知的放前面，新的放后面。** 句子开头用读者已经能对上号的东西，新信息放句尾。开头就是读者接不上的成分，他得先搭一座桥，才能把后面的话挂上去。

3. **动作写在动词里，谁做的写在主语里。** 说清楚谁对什么做了什么。「对配置进行了修改」和「配置被修改了」都把动作从动词位置搬走了，读者要再还原一次。「我改了配置」不用。

4. **每一行都要是一句可能被证伪的话。** 列表里也一样。「测试——基本通过」这种残句，不管结果如何都成立。「24 个测试过了 23 个，失败的是 `test_retry`」可以被核对，也可能是错的。列表读起来空洞，问题出在残句，不在列表本身。

5. **不确定性绑在它所属的那条结论上。** 先说你验证了什么、怎么验证的，再说什么没验证、为什么。把对冲词均匀撒在全篇，比一个都不用更糟。读者会分不出哪条结论硬、哪条软。「可能」这个词，不同的人读出来的分量，从五五开到几乎确定都有。

## 别从别的文体里搬东西

6. **类比要有对应关系，还要有真的需要它的读者。** 你能说出「A 相当于 B，C 相当于 D」，而且读者手里还没有你要映射过去的那个模型，才用类比。否则直接说事。读者本来就懂这个领域，类比对他就只是多一道翻译，翻过去没有新东西。

7. **是汇报，不是说服。** 「不是 X，而是 Y」这类对仗、反问句、层层递进的排比，都是用来推动还没拿定主意的人的。你的读者问的是发生了什么，这些东西对他而言是要先剥掉的包装。

8. **删掉之后依然成立的部分就删掉。** 开场白预告你接下来要做什么，总结段复述读者刚读完的内容，评价词换个结果也照样能用。这三种都是读了没有回报的东西。一句话在事情走向完全不同时依然成立，它就没在汇报任何东西。

9. **名词是黑话藏身的地方——干活时自造的标签，不能直接写进汇报。** 分析过程中你会把一类现象压缩成一个名字（「引用可解引用性」「单例文件所有权」）。这些词对你是索引，对没跟着你干活的读者是谜语：他得先猜出词指什么，才能开始读句子。一句大白话能说清的，就写那句话；读者在这场对话里没用过的词，第一次出现要么当场展开，要么删掉。检验：当面讲给同事听，这个词你说得出口吗。

10. **写你会说出口的话。** 电报式的省略给你省了几下键盘，把展开的活留给了读者。「测试过了。修好了。发了。」逼他自己补上主语、宾语和这几件事之间的关系。当面跟人说话不会这么说，那写下来时就把省掉的部分放回去。

## 对照

同样的内容，三种写法。只有第三种是 readout。

- ❌ **塞得太满**：「已完成对重试机制的全面排查，定位到指数退避的实现在并发压力下未能遵守配置的上限，该问题表现为 #412 中反馈的间歇性超时，并提示修复位置应位于调度器而非客户端。」
- ❌ **拆得太碎**：「重试机制——已排查。退避：高负载下有问题。上限没生效。相关：#412。修复位置：调度器（大概）。」
- ✅ **readout**：「#412 里的重试 bug 是真的，问题在调度器，不在客户端。并发压力下，指数退避没有遵守你配置的上限，重试堆积起来，请求就超时了。我用 20 个并发请求复现了。单线程下会不会走到同一条路径，我还没验证。」

## 发出去之前

把回复当成收信人读一遍。三个问题：他能不能说出发生了什么，能不能说出你要他做什么，有没有哪句话需要读第二遍才能解析。把第三个问题里没通过的句子重写一遍。那些就是一句塞了不止一件事的句子。另外把名词单独扫一遍：哪个词是你干活时自己造的？那对读者是代号——展开它，或者删掉。