Output Readability

---
name: output-readability
description: 输出可读性规范｜专家团所有对外产物的强制写作约束。用户来这里是求方案和解法的，不是来学框架的——所以产物必须做到结论先行、不自造术语、分层交付、不暴露写作规则本身。任何成员产出面向用户的报告、方案、清单、档案前，都必须按本规范自查。
---

# 输出可读性规范（Output Readability）

**这是全队的强制约束，不是建议。** 任何面向用户的产物（报告、方案、清单、档案、改写建议）在交付前都要过一遍本规范。

## 为什么需要这条规范

用户来这里是**求方案和解法**的。他要的是"我该怎么做"，不是"你用了什么分析框架"。

一个真实的劣化案例：团队早期产出的起号方案，全文零个内部术语，用户直接就能照做。而经过多轮深入讨论后产出的方法论报告，出现了上百处内部概念——**讨论用的分析语言被当成了交付语言**。这是典型的作者视角污染：我们讨论得越深，越容易忘记用户没参与这场讨论。

⚠️ 团队已有「术语保密铁律」约束**对话层**（不对用户说"底牌卡"这类内部词），但那条管不到**交付层**。本规范补上这一层。

---

## 四条硬规则

### 规则一：结论先行，概念后置

用户不需要跟着走一遍推导。**先给判断和做法，让愿意深究的人再往下看依据。**

| ❌ 不要这样 | ✅ 改成这样 |
|---|---|
| "转化路径形态判定为冲动型 → 所以分享型指标离转化最近 → 所以收藏是延迟信号" | "**你的用户看完就能下单，所以「转发」比「收藏」重要得多**——有人收藏，往往意味着他想再考虑考虑，而考虑就容易忘。" |
| "基于三层可迁移度分析，L2 形态层需要重做" | "**抖音那套开头 3 秒抓人的做法，搬到小红书要换成封面和标题**——小红书没有"前 3 秒"这回事。" |

概念去掉了，判断还在，而且更好懂。**如果去掉概念之后意思没损失，那这个概念本来就是多余的。**

### 规则二：不自造术语；已经造了的，翻译成大白话或删掉

自造概念会制造理解成本，然后我们还要花篇幅去化解它——这是净负担。

**常见自造词的替换（持续补充）**：

| 自造术语 | 改成 |
|---|---|
| 跨池衰减 | 换个场子打，成绩会不一样 |
| 双引擎判定 | 火的内容分两种：让人想转发的、让人想收藏的 |
| 深层真相三层 | 痛点有三层，越往下越是真心话 |
| 均值回归 / 右尾极端值 | 那条爆款是偶然，不是常态 |
| 六因子连乘 | 五六个地方各差一点，乘起来就差一大截 |
| 北极星指标 | 你最想要的那个结果 |
| 转化路径形态 | 用户从看到内容到下单，要走几步 |
| 操作型 / 冲动型 / 决策型 / 认知型 | 要跟着操作的 / 看完就能买的 / 要比较很久的 / 只求让人记住的 |
| 可转述引擎 / 可照做引擎 | 让人想转给朋友的 / 让人想存下来照做的 |
| 入口矩阵 | 可以从哪几个角度切进去 |
| 分发身份层 | 平台怎么看待这条内容 |
| 可信度分级 / L0 / L1 / L2 / [样本归纳] | 见规则四下方的"出处怎么说" |
| 归因 | 到底是什么造成的 |
| 反向校验 | 反过来验证一下 |
| 正交 | 互不影响 / 是两件事 |
| 置信度 | 有多靠得住 |
| 语境 | 上下文 / 前后怎么说的 |

**保留的例外：用户在自己工作中真实会遇到的行业词。**

这类词该用就用，还可以顺带说明一句它是什么——因为这是**帮用户认识他本来就要面对的东西**，不是我们制造概念。

| 判断 | 例子 |
|---|---|
| ❌ 自造概念还要解释 | "跨池衰减（指内容从自然流量池迁移到商业流量池时的效果损失）" |
| ✅ 行业实词顺带说明 | "蒲公英（小红书官方的达人接单平台）" |
| ✅ 行业实词直接用 | 完播率、薯条、DOU+、互选、星图、处方粮 |

### 规则三：分层交付

用户的阅读顺序应该是：**能用的 → 具体怎么做 → 为什么这么建议 → 什么情况下不适用**。

```
① 结论摘要      3-5 条，每条都能直接执行。用户只看这一段也能开工
② 具体方案      表格 / 清单 / 模板 / 日历 / 逐条卡片
③ 判断依据      为什么这么建议（愿意深究的人看）
④ 风险与边界    什么情况下这套不成立
```

**方法论的严谨性应该体现在结论可靠上，不是逼用户跟着走一遍推导。**
样本体检、推导过程、可信度说明这类内容属于 ③，不要放在开头。

### 规则四：不暴露写作规则本身

把幕后过程写到台前，本身就是一种黑话。**用户不需要知道我们有写作规范，他只该感觉到"这个答案我看得懂"。**

| ❌ 禁止 | ✅ 改成 |
|---|---|
| "人话版：……" | 直接就那么写 |
| "翻译成人话就是……" | 直接说结论 |
| "用大白话讲……" | 直接讲 |
| "简单来说 / 说白了" | 多数情况直接删，不影响意思 |
| "为了便于理解，我们把它叫做……" | 直接用那个名字 |
| "专业上叫 XX，也就是 YY" | 只说 YY |
| "结论先行：……" | 把结论放前面就行，不用宣告 |
| "以下是我的分析框架" | 直接给分析结果 |
| "接下来我将从三个维度展开" | 直接展开 |

### 「开头那句重点」怎么写才不算宣告

规则四禁的是**宣告动作**（"结论先行："），不是禁**把重点放前面**——后者恰恰是规则一的要求。两者不矛盾：

| | 写法 | 判断 |
|---|---|---|
| ❌ | 「**结论：**主赛道锁定都市职场穿搭」 | 宣告了"这是结论"，多余 |
| ✅ | 「主赛道锁定**都市职场穿搭**，辅以少量职场干货破圈（8:2）」 | 直接给判断，读者自然知道这是重点 |

**HTML 卡片的 `.lead` 同理**：不加「结论：」「小结：」等固定前缀，直接写那句话。且**不是每节都要有**——
纯罗列（对标清单）、纯陈述（数据分布）、纯流程（排期表）如果没有增量信息，**省略 lead 直接上内容**，
不许用「以下是 5 个对标账号」这类复述标题的废话占位。

按 section 性质自适应写什么（判断型给结论 / 罗列型给共性或怎么用 / 流程型给关键节奏 /
风险型给最该先避开的一条），详见 `html-card-template/references/design-rules.md` 规则 2。

---

## 三处只能换说法、不能简化

有些内容说轻了会害人。这类**保留严谨度，但换成好懂的说法**。

| 内容 | 为什么不能简化 | 怎么换说法 |
|---|---|---|
| **从自然流内容提炼的方法论用于商业投放时的落差** | 不说清用户会照着投商单，然后把效果差归因为"执行不到位"——这是真实踩过的坑（有品牌方发现某自来水账号带来大量新客，立刻找博主接商单，之后再无效果） | 章节改叫「照着做之前，先知道这三件事」；用真实案例讲故事，不讲机制；三句话说完：不要按样本的数据定目标 / 数据差不是你们内容不行，是平台怎么派流量变了 / 抄结构抄不到人家当时那股真心 |
| **结论的出处与可靠程度** | 不标出处，用户会把十几条样本的归纳当成普遍规律 | 不用 L0/L1/L2 和 [样本归纳] 这类标签，改成一句话：「这条有官方文件依据」/「这条是从你这批内容里看出来的，换个品类不一定成立」/「这条是行业里大家的普遍经验，平台没公开说过」 |
| **合规红线** | 说模糊了会害人 | 保留原有严谨度与完整表述。**但只在合规章节保留，不要渗到其他章节** |

**核心原则：诚实不等于难懂。风险提示可以写得很好懂，只是不能写得很轻。**

---

## 篇幅约束

| 产物类型 | 核心内容上限 | 说明 |
|---|---|---|
| 方案 / 方法论报告 | **约 6000 字** | 超出部分放附录或另出文件。小团队不会读完一万多字 |
| 单项检查报告（如合规预检） | 约 4000 字 | 以清单和对照表为主 |
| 档案类（如风格档案） | 不限，但正文前必须有 200 字内摘要 | 档案是查阅用的，允许长 |

⚠️ **长不等于专业。** 用户读不完的部分等于没写。

---

## 交付前自查清单

- [ ] 开头 3-5 条结论能不能让用户直接开工？（只看这段够不够）
- [ ] 有没有自造术语？逐个检查：能删的删掉，要留的翻译成大白话
- [ ] 用户第一次读到的每个词，是不是他工作里本来就有的？
- [ ] 有没有"人话版""翻译成人话""结论先行"这类元话语？
- [ ] 推导过程、样本说明、出处标注是不是都在后半部分？
- [ ] 风险提示是不是既好懂又没被写轻？
- [ ] 核心内容有没有超篇幅上限？
- [ ] 通读一遍：如果用户是个第一次做这件事的人，他会不会中途放弃？

**最后一条最重要。** 判断标准不是"写得对不对"，是"用户能不能读完并用上"。

---

## 呈现层规则｜信息量大的产物统一走 HTML 卡片

前面四条硬规则管的是**写什么、怎么组织语言**，本节管的是**最终以什么形态给到用户**。

### 触发 HTML 卡片渲染（满足任一即用 HTML）

1. Agent 的「## 输出规范」里明确列出的**交付物**（账号定位卡、爆款拆解、Brief 六要素、内容日历、报价参考、路线图、体检报告、风格 DNA 档案等）
2. 正文包含 **≥2 段结构化内容**（表格、多层清单、时间轴、多要点对比、评分）
3. 用户明确说"给我一份 / 生成一个 / 整理成 XX / 出一份文档"

**满足以上任一 → 走 `html-card-template` 技能生成 .html 文件到用户当前工作目录。**

### 保持纯文本对话（不用 HTML）

1. 闲聊、追问、澄清（"这个能不能改一下"、"为什么这么建议"）
2. 单条问答（"抖音适合日更吗？"）——单条回答、无多层结构
3. **仿写正稿本身**、商单文案改写后的**最终成品稿**——用户要复制走贴到平台，用 HTML 反而不便复制
4. **JSON 中间接口**（`style-dna-training` / `content-methodology-analysis` 里的工程管道）——保持现状不变，HTML 只在最终"给用户看"的那一层套壳

### 呈现层与内容层的关系

- **内容层**（前面四条硬规则 + 三处只能换说法）：**不因呈现方式改变**——HTML 里的结论句、正文措辞、术语规则完全遵守本 SKILL 前半部分
- **呈现层**（HTML 卡片）：只是把内容装进统一的视觉容器，**不减少信息量、不改变字段结构**
- **HTML 生成必须走 `html-card-template` 技能**，不允许自造样式或用其他 HTML 结构

详见 `skills/html-card-template/SKILL.md`。