# Tech Design To Zhihu

> Write a Zhihu 专栏 from a technical design or architecture analysis. Speak human Chinese, walk 是什么/不是什么 then the thread then 树根→主干→分支→树叶, lead with real project screenshots as PNG figures (RenderDoc capture frames, running app / game highlight frames — Zhihu has no mermaid/SVG), open with a TL;DR and a first-person hook, close with 收获和结论 plus a discussion prompt and optional PS/PPS/PPPS. Use when the user asks 写成知乎文章, 技术设计稿转知乎, 知乎长文, 知乎没有 mermaid, 说人话, 去 AI 味, 多图, TL;DR, 收获和结论, or PS PPS. Not a design skill.

- Skill: `yhyu13/tech-design-to-zhihu` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx get-skill add yhyu13/tech-design-to-zhihu`
- Raw SKILL.md: https://api.skillmd.com/api/skills/yhyu13/tech-design-to-zhihu/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: yhyu13 (https://skillmd.com/u/yhyu13)
- Updated: 2026-11-12
- Page: https://skillmd.com/skills/yhyu13/tech-design-to-zhihu

---


# 技术设计稿 → 知乎专栏

这是**写作 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` 上传。

## 逻辑脉络（写作顺序）

上一步没钉住，后面段落会散。

1. **读源** — 抽出主线、是什么/不是什么、树（树根 → 主干 → 分支 → 树叶）。源是采石场，不是逐句脚本。
2. **TL;DR** — 标题下立刻给 3–5 条。扫完能走。每条一句人话，可与收获对应，但更短。
3. **作者开场** — 紧接 TL;DR，给一句第一人称钩子（「我维护这套系统时…」）。知乎读者靠「谁在讲」决定信不信，亲历感是最有效的信任武器。skill 只搭位置、留 `[作者补一句：…]` 占位，不替作者编经历。开头句要够惊人、尽量晚开始（不铺背景、不端帽子）；没灵感就快速脑暴 10 个候选再挑，别接受平庸开头——开头句是读者对全文的第一次信任。
4. **为什么 / 验证哪条能力** — 架构类必写，正文第一块（作者开场那一句不算正文）。这篇设计是为了压哪条运行时承诺（插件接缝、模型可见⟺已落日志、不改 loop…）。不是待办说明书。配一张探针图。不要先铺错路再补为什么。
5. **错路对照** — 读者的第一反应往往是错的。先画错路，再画正路。开口的那句主线可以落在这里。
6. **脉络图** — 需求 → 接缝 → 树根 → 主干 → 切开。每步口头说「是什么 / 不是什么」。
7. **整棵树** — 每层回答一个问题。「不是什么」最多标 1–2 处红字。
8. **按枝往下讲** — 每根分支：短段人话 → 一张图 → 必要时再补一张「人话放大图」（CAS、两本账、证据先行…）。
9. **收获和结论** — 必写。收获是能搬走的判断（通常 5–7 条，配总图）。结论把主线再说一遍，落到读者能用的切割上。不要新开论点。
10. **讨论口** — 结论之后抛一个可争辩的问题或开放判断（「如果是你，会把这一刀切在哪？」）。知乎排序吃互动，结尾留个评论落点，别封死。
11. **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 目录无本机绝对路径