ahang1598 输出可读性规范（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）
- Agent 的「## 输出规范」里明确列出的交付物（账号定位卡、爆款拆解、Brief 六要素、内容日历、报价参考、路线图、体检报告、风格 DNA 档案等）
- 正文包含 ≥2 段结构化内容（表格、多层清单、时间轴、多要点对比、评分）
- 用户明确说"给我一份 / 生成一个 / 整理成 XX / 出一份文档"
满足以上任一 → 走 html-card-template 技能生成 .html 文件到用户当前工作目录。
保持纯文本对话（不用 HTML）
- 闲聊、追问、澄清（"这个能不能改一下"、"为什么这么建议"）
- 单条问答（"抖音适合日更吗？"）——单条回答、无多层结构
- 仿写正稿本身、商单文案改写后的最终成品稿——用户要复制走贴到平台，用 HTML 反而不便复制
- JSON 中间接口（
style-dna-training/content-methodology-analysis里的工程管道）——保持现状不变，HTML 只在最终"给用户看"的那一层套壳
呈现层与内容层的关系
- 内容层（前面四条硬规则 + 三处只能换说法）：不因呈现方式改变——HTML 里的结论句、正文措辞、术语规则完全遵守本 SKILL 前半部分
- 呈现层（HTML 卡片）：只是把内容装进统一的视觉容器，不减少信息量、不改变字段结构
- HTML 生成必须走
html-card-template技能，不允许自造样式或用其他 HTML 结构
详见 skills/html-card-template/SKILL.md。