技术设计稿 → 知乎专栏
这是写作 skill。把一份技术设计 / 架构分析，改写成给人读的知乎专栏。
本 skill 不管「系统该怎么设计」，只管「怎么讲给知乎读者听」。设计判断本身（接缝、切法、取舍）住在源设计稿里，不在本 skill。
平台细则：references/zhihu-platform-rules.md。
概念 · 是什么 / 不是什么
| 是什么 | 不是什么 | |
|---|---|---|
| 这份 skill | 把设计稿改写成知乎专栏：说人话、多 PNG、按脉络带读者走、以收获和结论收束 | 设计 skill；翻译设计文档；LinkedIn / X 短帖；知乎 Open API 发布 |
| 文章 | 一篇有主线的人话。读者走完能搬走几句判断 | 12 条原则清单、文件索引、ADR 摘要、源码导读 |
| 图 | 每个论点一张 PNG，优先项目实拍截图（RenderDoc 截帧、运行画面、游戏高光帧），标题即论点；「不是什么」用红字标是可选的风格 | mermaid 围栏、SVG、纯说明性示意图当主图、装饰截图、「如图所示」空指 |
| 开头 | TL;DR：3–5 条可抄判断，扫完就能走；下一句作者开场（第一人称钩子） | 目录、摘要腔、「本文将介绍」 |
| 收束 | 收获和结论 + 一个讨论口；PS / PPS / PPPS 可选 | 「本文介绍了…」「更多细节见源码」 |
知乎不渲染 mermaid，也不显示 SVG。图必须是 PNG，且以项目实拍截图为主（RenderDoc 截帧 / 运行画面 / 游戏高光帧），说明性示意图只作配角。本地 images/ 粘贴后不会自动带上，人要按 PUBLISH.md 上传。
逻辑脉络（写作顺序）
上一步没钉住，后面段落会散。
- 读源 — 抽出主线、是什么/不是什么、树（树根 → 主干 → 分支 → 树叶）。源是采石场，不是逐句脚本。
- TL;DR — 标题下立刻给 3–5 条。扫完能走。每条一句人话，可与收获对应，但更短。
- 作者开场 — 紧接 TL;DR，给一句第一人称钩子（「我维护这套系统时…」）。知乎读者靠「谁在讲」决定信不信，亲历感是最有效的信任武器。skill 只搭位置、留
[作者补一句：…]占位，不替作者编经历。开头句要够惊人、尽量晚开始（不铺背景、不端帽子）；没灵感就快速脑暴 10 个候选再挑，别接受平庸开头——开头句是读者对全文的第一次信任。 - 为什么 / 验证哪条能力 — 架构类必写，正文第一块（作者开场那一句不算正文）。这篇设计是为了压哪条运行时承诺（插件接缝、模型可见⟺已落日志、不改 loop…）。不是待办说明书。配一张探针图。不要先铺错路再补为什么。
- 错路对照 — 读者的第一反应往往是错的。先画错路，再画正路。开口的那句主线可以落在这里。
- 脉络图 — 需求 → 接缝 → 树根 → 主干 → 切开。每步口头说「是什么 / 不是什么」。
- 整棵树 — 每层回答一个问题。「不是什么」最多标 1–2 处红字。
- 按枝往下讲 — 每根分支：短段人话 → 一张图 → 必要时再补一张「人话放大图」（CAS、两本账、证据先行…）。
- 收获和结论 — 必写。收获是能搬走的判断（通常 5–7 条，配总图）。结论把主线再说一遍，落到读者能用的切割上。不要新开论点。
- 讨论口 — 结论之后抛一个可争辩的问题或开放判断（「如果是你，会把这一刀切在哪？」）。知乎排序吃互动，结尾留个评论落点，别封死。
- PS / PPS / PPPS — 可选。结论之后三层附言，给读完的人，不给目录。
主干（四条写作纪律）
说人话，像人。 先比喻，后术语。一段一个意思。fold、CAS、activation 第一次出现就用大白话落地。仓库内部名能不出现就不出现；出现就带一句人话。警惕「口语里不会用的词」——不是真术语就是装权威，装权威的删。活人感靠三样：具体（场景、工具、版本、trace、路径）、取舍（为什么这么判、什么条件下成立）、不装（不把普通事实写成时代趋势）；没有具体对象、动作或证据的段，语气再顺也按 AI 味处理。
图先行，能多则多，优先实拍。 每个独立论点配一张 PNG，优先项目实拍截图（RenderDoc 截帧、运行画面、游戏高光帧）——这是项目「最好的一面」，比手画示意图更吸睛。宁多一张人话对照图，不少一张让读者空转的段。标题即论点。不要把 12 个意思塞进一张图。
是什么 / 不是什么钉概念。 用对比句钉住关键概念，但全文对比句 ≤ 3 处（一张总表算一处），不要每段都套——每段都套就滑成「二元对比假戏剧」的模板腔。表可以有一张总表；正文用对比句，不要整页 spec。
一个论点。 全文和每一张图只服务一条主线。核心观点全文只出现 2 次：定义处 + 总结处，中间直接用，不反复解释。写着写着想塞进「另一个也重要的想法」，就是 discursive disease——删，或另起一篇。
铁律：源头锚定 + 去 AI 味
源头锚定（不编造）
- 只搬运源里已有的事实、数字、quote、例子。缺材料就开口要，不许补（
[作者补一句：…]占位就是干这个的）。 - 数字带参照物：单位、测试条件、对比基线、样本范围、时间跨度。条件和数字不拆开——
p95 从 480ms 降到 160ms不能概括成「明显降低」。 - 事实关系不改写：
展示了云架构的潜力不能写成采用了云架构；「提升效率」不能扩成「省时间 / 降成本」；抽象信息不擅自具体化。范围、条件、否定、完成态、方向、强度都算事实，不随语气一起删。 - quote 加引号的前提是逐字出现在源里；改写的句子标
derived，不加引号。 - 无源引用（
研究表明 / 数据显示 / 专家指出）：论点能独立成立才留，否则删或标「缺来源」，不补虚构出处。 - 不编造 URL、API、类名、客户证言、截图。截图必须来自项目实拍（RenderDoc 截帧 / 运行画面 / 游戏高光帧），不 P 出不存在的效果；没有截图就开口要，不拿示意图冒充。没有 URL 就写
[LINK — 发布前替换]。 - 观点要有来源：作者、文档、issue、commit、trace、实验、读者反馈——不借「很多人」撑场。
去 AI 味（先保信息，再谈风格）
改语气之前先保事实、术语、责任主体。禁用词命中即删或换具体；结构反模式比单词更隐蔽，重点扫。
禁用词
| 类别 | 例 |
|---|---|
| 清嗓/开场套话 | 值得注意的是、事实上、实际上、说实话、有趣的是、这让我想到 |
| 总结腔 | 综上所述、总而言之、归根结底、总的来说 |
| 意义通胀 | 标志着、反映了趋势、奠定了基础、展现了潜力、意义重大、不可或缺 |
| 汇报腔/元叙述 | 先说判断、直奔主题、接下来我将、下面我们来看、众所周知 |
| 冗余确认副词 | 真正、真的、确实、实际上（无对照对象时删） |
| 商业黑话 | 赋能、抓手、闭环、颗粒度、护城河、打法 |
结构反模式（重点扫）
- 二元对比假戏剧
不是 X，而是 Y：正文已限 ≤ 3 处（见主干），超出就删前半句直接说Y。 - 三件套列举：凑三项装完整。按事实数量写，两项就两项。
- 同义词躲避：同一对象别换三种说法，关键词该重复就重复。
- 动词名词化：
进行了优化→改顺了；实现了提升→快了多少。 - 假口语/假现场感：硬塞网络梗、伪造细节（
凌晨三点，窗外下着雨）、戏剧化碎句。 - 节奏单调：每句差不多长、差不多落点。长句装信息、短句落锤。
- danger words：
interesting / quite / very及中文对应（有趣的 / 相当 / 非常）——靠内容打动读者，不靠「这很有意思」预告。
双向回读（交付前必做，两步分开）
- Pass 1 保真：protected spans 漂没漂；数字与修饰对象、主体与动作的配对对得上；范围 / 条件 / 否定 / 方向 / 强度逐项可追溯；术语不失真。
- Pass 2 残留：开场残留（
结论先说 / 值得注意的是）、总结残留（总的来说）、narrator 残留（解释「这说明了什么」）、空泛判断残留（方向是对的 / 意义重大）。只做轻修，不重写全文。
分支（文章长什么样）
标题
└── TL;DR 3–5 条，扫完能走
└── 作者开场 一句第一人称钩子（留占位）
└── 为什么 / 验证哪条 正文第一块，图（架构类必写）
└── 错路 / 正路 图 + 开口主线
└── 脉络 图 + 短表
└── 树全貌 图
├── 树根 / 主干 图
├── phase / activation
├── authority
└── round / 证据
└── 收获和结论 总图
├── 讨论口 抛一个可争辩的问题
└── PS / PPS / PPPS（可选）
树叶（文件路径、函数名）最多作点到为止的例子，不进目录，不进收获。
树叶（动手步骤）
读源
列出：主线、脉络步骤、每层是什么/不是什么、已有图、缺的图、读者未带上的概念。文件索引默认丢掉。
补图
图优先用项目实拍截图，把项目最好的一面摆出来（eye-catching）：
- 首选：RenderDoc 截帧（管线、纹理、网格、像素历史、GPU 计数器）、app 运行画面、游戏高光帧。这些是「真东西」，读者一眼看到项目长什么样、跑成什么样。
- 每个论点一张图；截图能表达论点就直接用截图，alt / 标题写成论点句。挑最吸睛的帧，别拿灰扑扑的调试中间态充数。
- 截图不足表达架构脉络（接缝、树、切开）时，才画示意 SVG 再栅格成 PNG（标题 + 4–8 个框，浅底，中文标签）；但示意图是配角，不能替代实拍截图。
- 截图必须真实：来自项目本身，不编造、不 P 出不存在的效果。没有截图就开口要（RenderDoc 截帧 / 运行截图 / 游戏高光帧）。
- 「不是什么」用红字标是可选风格，全文最多 1–2 张图用。已有 PNG 且论点已在图上，复制进
images/，改 alt 为论点。禁止留下```mermaid和.svg链接。
人话放大图优先补这些空洞：错路、同时写入、模型可见 ⟺ 已落账、两种记账法、证据先行、收获总图。
写正文
- 标题下第一块就是 TL;DR；下一句是作者开场（第一人称钩子，留
[作者补一句：…]占位）；架构类再下一块是 为什么 / 验证哪条。然后才错路。 - 短段。像对工程师说话，不像写 README。
- 每走一步：人话 → 是/不是 → 图。
- 能引用官方文档、开源仓库链接、可复现片段的地方，要求补上——不只是「不编造」，还要正向给证据。
- 标题最多
####。不要 GitHub admonition。 - 专栏大约 2500–6000 字。超过 8000 就砍或拆。
TL;DR（必写，放标题正下方）
给只想扫一眼的读者。3–5 条子弹，每条一句人话。
- 是：能抄走的判断，和收获同向、比收获更短。
- 不是：目录、摘要腔、「本文将介绍三点」。
- 读完 TL;DR 可以走；正文是给愿意走完的人。
收获和结论（必写）
文章在「收获和结论」之前不算完。
- 收获： 5–7 条读者能抄到自己系统里的判断。每条一句人话 + 半句「不是什么」。配一张总图。
- 结论： 一段，把开口的主线落地。告诉读者能搬走的是切割，不是文件名。
- 讨论口： 结论之后抛一个可争辩的问题或开放判断。知乎排序吃互动，结尾留个评论落点，别封死。
- 收获里不要出现路径、函数、包名。那些不是收获。
PS / PPS / PPPS（可选，放结论之后）
个人风格，不写不算缺失。给读完的人，不给目录。想写就写三层，一层一句到两句，不新开主干论点。
| 写什么 | 不是什么 | |
|---|---|---|
| PS. | 只带走一句时带走哪句（主线的人话版） | 又一篇收获清单 |
| PPS. | 最容易混淆的邻概念（这篇和「把模型训得更听话」不是一回事） | 新开一章 |
| PPPS. | 过时声明 + 读者自己系统里会裂开的那一刀 | 推销、关注、下期预告 |
交付包
<out>/
article.md 可粘贴正文（无 mermaid、无 SVG）
images/*.png 按文中出现顺序
PUBLISH.md 标题、导语、上传顺序
默认写在源旁边 <stem>-zhihu/，或用户指定路径。
完成标准
article.md无 mermaid、无 SVG 链接- 每个独立论点有一张 PNG 在
images/，数量按论点加，不按「最少几张」封顶；图以项目实拍截图为主（RenderDoc 截帧 / 运行画面 / 游戏高光帧），说明性示意图只作配角 - 开口主线 = 文章主线 = 结论主线 = TL;DR 第一条所服务的那句；核心观点全文只出现 2 次
- 标题下有 TL;DR（3–5 条）和一句作者开场占位；架构类有「为什么 / 验证哪条能力」；文末有收获和结论，结论后有一个讨论口
- 「是什么 / 不是什么」对比句全文 ≤ 3 处；红字「不是什么」≤ 2 张图
- 能引官方文档 / 开源链接 / 可复现片段的地方已补上；无 fake quote / fake URL / 无源数字
- 滑回扫描已过：
不是 X 而是 Y族 ≤ 3；真正/其实/实际上高频已压；标志着/反映了/奠定了后无具体影响的已删 - 双向回读已过：保真（数字带参照物、claim 能回指源、关系没改）+ 残留（无总结腔 / narrator 腔 / 空泛判断）
PUBLISH.md只列上传顺序，不自动发布——只暂存草稿交用户确认- 本 skill 目录无本机绝对路径