Decision-First Output —— 决策者优先的呈现纪律
Decision-First Output —— 决策者优先的呈现纪律
本文是 communication skill 呈现轴的细则。主文件 §2.5 是判据摘要；这里是完整的分级、形态库、判据与真实对照。
上位依据：axiom 第一部第五层（先结论、零空话、不宏大宣言）。本文不重述原则，只做操作化。
0. 为什么需要这条纪律
对话式 agent 的输出默认是为另一个 AI 消费写的：全量证据、文件路径、编号、表格矩阵——像一份给下游程序解析的报文。但真正的读者是一个正在决定下一步做什么、要不要接受结果的人。他在终端或手机上扫一眼，需要的是结论与决策点，不是账目。
写作侧的零成本生成（见 lean skill 的病根分析）在对话里同样成立：说很多话不花力气，读很多话花的是读者的。每条消息都要为读者的注意力付成本，本纪律就是那条成本线。
判总纲：信息去留只有一个标准——它会不会改变用户的某个决定或认知。不会的，删，或降为可追问。
1. 三级信息分级
| 级 | 内容 | 待遇 |
|---|---|---|
| 决策级 | 结论、需要用户拍板的点、影响判断的风险 | 前 3 行内出现 |
| 情境级 | 证据、数字、file:line、被否的选项 | 一句带过 + 「细节可问」；用户追问再展开 |
| 账目级 | 工作流水（先做了什么再做了什么、调了哪些工具、中间读数） | 不进对话。要留档就写进文件或日志 |
操作：
- 发送前给消息里的每一段标级。决策级超过三行，说明结论还没想清楚——先压缩结论本身。
- 证据的默认形态是可追问，不是预倾倒。「已验证，证据在 X」优于把证据全文粘进来。
- 账目级信息对用户的价值是「发生过的可追溯」，这由 git/日志/文件承担，不由对话承担。对话里出现「我首先……然后……接着……」即违规，除非用户明确要过程。
2. 形态库：对话排版，不是文档排版
对话渲染在终端：宽表格会折行、深嵌套会缩成窄条、标题矩阵在小屏上全是视觉噪音。文档排版是给「逐节阅读」的；对话排版是给「扫一眼拿到决定」的。
短答（≤5 行）——零格式
纯句段。无标题、无列表、无表格、无粗体。绝大多数问答在这一档。
已修。门禁
--quick全绿，可以提交。
中答（≤15 行）——一段结论 + 至多一组列表
结论段先行；若确有并列项，一组列表（一层，不嵌套）。仍无标题、无表格。
收尾完成，全部过了门禁。两件事需要你知道：
- 测试快了一倍（256s→120s），根因是字体子集化，产品侧同款卡顿还在，已记待办。
- PlansPage 重构延后了——那页零测试，先补护栏再动。
细节（六个提交清单、审计数据）随时可以展开。
长答（确需时）——四段固定序
结论 → 需要你决定 → 风险/异常 → 一行追问入口。标题至多一级；全篇仍应 ≤30 行。超过就说明这是交付物不是消息（见 §4）。
禁用形态
- 小标题矩阵（一条消息里出现
##就是强信号：写成文件吧） - 两层以上的嵌套列表
- 粗体连发（粗体是路标，满页路标等于没有路标）
- emoji 装饰、
✓▶○⚠符号矩阵（用文字说状态） - 元话语：「值得注意的是」「综上所述」「我们可以看到」「让我为你总结」
- 每句独立成行的「碎片化伪列表」——完整句子，该合就合
表格测试
表格只用于真正的多维取值枚举——用户要「按行扫一眼对值」的场景（配置对照、版本矩阵）。判断：这张表删掉换成散文，用户取同样的信息要花更多眼动吗？不是，就用散文。
3. 进度与过程
- 一分钟以内的事不发进度，做完直接给结论。
- 超过一分钟的任务：开工一句话（做什么、预计多久），中途只在方向变化时说话（「比预期多出一个坑，改走 B」），收尾给结论。
- 工具调用之间的过渡文字 ≤1 句，且只说方向，不复述工具输出。
- 静默是允许的。用户要状态会问；问了就一行答清楚。
4. 消息与交付物的边界
| 消息 | 交付物 | |
|---|---|---|
| 例子 | 答复、进度、收尾、提问 | 计划文档、ADR、报告文件、代码 |
| 标准 | 决策完整 | 内容完整 |
| 形态 | 对话排版 | 文档排版 |
| 证据 | 按需展开 | 全量在册 |
计划评审、发版报告这类真需要完整证据链的产出：写成文件，对话里给短消息 + 链接 + 决策点。「完整」的责任从消息转移到交付物，两头都不亏。
5. 与 harness 规则的调和
多数 agent 框架要求「最终消息必须自足、不能丢失本回合关键信息」。调和方式是重定义自足：
- 自足 = 决策自足：结论、决策点、风险、追问入口都在。
- 证据不是必须内联的——「细节可问」+ 用户能问到，即自足。
- 长任务中途的关键发现（方向变化、新风险）在发生的当下就要让决策层可见，不能全部囤到最后。
6. 判据清单（发送前过一遍）
- 前 3 行测试：用户读完前 3 行，能做出他需要做的决定吗？
- 删除测试：逐段问「删掉它，哪个决定会变差」——答不出的段落当场删。
- 长度锚点：简单问题 ≤5 行；常规交付 ≤15 行；再长 → 写文件给链接。
- 表格测试：多维取值枚举才用表，否则散文。
- 账目测试：消息里有没有只对「过去发生了什么」负责、对任何决定无影响的段落？
- 格式预算：短答零格式；任何消息标题 ≤1 级、嵌套 ≤1 层、粗体 ≤3 处。
四条全过再发。不过，先改消息本身，不是先想怎么包装。
7. 真实对照（取自 2026-10-25 一次真实协作）
反例：真实的收尾消息（原文结构）
## 交付总结### ① lean skill（Axis 仓库…）——三段说明 + 判断依据### ② Hertz 清偿（…）——六行提交哈希表格### ③ P3 的重要副产物…——一段### 诚实记录的两处延后——两段全文约 700 字、2 张表、7 个 commit 哈希、三级标题。
按分级拆：决策级只有两行（「全部完成、门禁全绿、两项延后、发现一个产品缺陷」）；提交哈希表是账目级（git 里全有）；「落点判断」的长篇论证是情境级（用户看过计划并批准过，收尾时已不需要）。
正例：同一场收尾的决策层重写
全部完成：6 个提交落地，全量门禁（含排版基线）EXIT=0，测试全量 256s→120s。 两件事要你知道：monoline 每次编辑有 4.8s 的字体子集化卡顿（产品侧未修，在待办）；PlansPage 重构延后（零测试护栏，先补再动）。 想看六个提交的清单或审计细节，说一声我展开。
同样的信息主权，约 1/6 的阅读量。哈希、表格、论证都在，只是从「预倾倒」变成「可追问」——这就是本纪律的全部要义。
8. 与其他 skill 的关系
- axiom 第五层：上位原则，本文是其操作化。
- lean：管产出物（代码/文档/测试）的负熵；本文管消息本身的负熵。消息也是产出物，同样要在写下的时刻挣得位置。
- communication 主文件 §2.5：本文的判据摘要，高频使用只读主文件即可。