Gen Zhihu Article

---
name: gen-zhihu-article
description: Generate Zhihu article in the style of 22-庖丁解牛专题页-知乎图文终版.md
user-invocable: true
---

# 知乎文章生成器

根据指定主题生成知乎风格文章。

## 风格规则

不要把所有文章都写成同一种模板。生成前先判断最适合的风格，并在同批次文章里避免连续重复同一种开场和收束。

## 去 AI 味规则

知乎发文时，要主动压低 AI 味，尤其避免那种过度整齐、过度解释、像模板机生成的对照句。

默认禁用或强烈避免这类句式：

- `不是 xxx，而是 xxx`
- `不只是 xxx，而是 xxx`
- `真正重要的不是 xxx，而是 xxx`
- `它看起来像 xxx，但本质上是 xxx`

除非用户明确要求保留这种修辞，否则优先改写成更自然的表达：

- 直接下判断
- 先给结论，再解释原因
- 把对照拆成两句
- 用场景或问题切入，而不是用模板化反转句切入

可优先在这些风格里选一类：

### 1. 庖丁解牛 / 深拆型
- 适合源码解构、系统拆解、架构阅读
- 开头强调“为什么值得拆”
- 主体偏分层、控制点、运行链路

### 2. 工具手账 / 上手型
- 适合新工具、新页面、新插件
- 开头强调“解决什么问题、怎么快速上手”
- 主体偏场景、能力点、注意事项

### 3. 工作流配方 / 方法型
- 适合 loop、发布链路、自动化流程
- 开头强调“这套链路如何串起来”
- 主体偏步骤、决策、边界、失败回退

### 4. 热点快评 / 情报型
- 适合 changelog、新发布、对比观察
- 开头强调“最近发生了什么，为什么值得注意”
- 主体偏判断、影响、位置、下一步

### 5. 研究摘记 / 论文解读型
- 适合论文专题、方法综述、方向盘点
- 开头强调“论文在解决什么问题”
- 主体偏问题、方法、结果、启发

### 6. 纯干货 / 原理型
- 适合 runtime、架构、协议、源码、调试、实现机制
- 开头直接抛技术问题或核心结论，不先夸页面或网站
- 主体偏原理、分层、链路、边界、实现要点、适用条件
- 允许只在结尾附上相关阅读链接，不必把全文写成推荐文

## 文章结构规范

参考 `wemedia/zhihu/articles/22-庖丁解牛专题页-知乎图文终版.md`，但不要机械复制这一个模板。

### 标题格式
```
# 找到一个不错的 [主题名]：[一句话价值点]
```

也可以根据风格切换成：
- `最近看到一个值得拆的 [主题名]：...`
- `如果你正想解决 [问题]，这套 [主题名] 值得先看`
- `把 [主题名] 这条链路走通之后，我觉得最值得记住的是 ...`

### 开头段落
- 不要求每篇都固定三段
- 但需要先给出一个清晰抓手：
  - 这是什么
  - 为什么值得看
  - 适合谁
- 可以根据风格选择：
  - 直接抛结论
  - 从痛点切入
  - 从最近发布/对比观察切入

### 正文结构（编号小节）
```
一、[第一个价值点]
内容 + 图片引用

二、[第二个价值点]
内容 + 图片引用

...
```

不要每篇都硬套完全相同的节奏。允许根据题材切换成：
- `问题 -> 方案 -> 价值 -> 适用人群`
- `背景 -> 拆解 -> 判断 -> 建议`
- `发布点 -> 关键变化 -> 影响 -> 实操建议`
- `论文问题 -> 方法 -> 结果 -> 启发`

### 结尾
- 结尾也不要完全固定
- 常见可选收束：
  - 适合谁继续看
  - 我最建议先从哪一页开始
  - 这一条线对我们自己的系统意味着什么
  - 在线地址 / GitHub / 相关文章入口

### 图片引用格式
```
![图片描述](../images/[图片名].png)
```

### 代码证据格式

如果文章的判断依赖仓库实现、脚本逻辑、协议细节或源码结构，不要只写文件路径。

默认做法：

- 先给路径，说明证据来自哪里
- 再给 3 到 12 行最关键的代码摘录
- 用 Markdown fenced code block 展示
- 代码块后用 1 到 3 句解释“这段代码证明了什么”

推荐写法：

在 `tools/foo.py` 里，关键逻辑是：

```python
def should_resume(task_state):
    return task_state in {"active", "blocked"}
```

这里真正说明的是：系统会优先续跑未完成任务，而不是每轮随机挑新任务。

避免这种写法：

- 只列 `tools/foo.py`
- 只说“源码里有实现”
- 用路径代替代码证据

## 输出位置

文章保存到 `wemedia/zhihu/articles/` 目录，文件名格式：
```
NN-[主题关键词]-知乎图文.md
```

## 主题来源

文章主题来自以下专题页面：
- `site/topic-paoding-jieniu.html` - 庖丁解牛专题总页
- `site/topic-cc-unpacked-zh.html` - Claude Code 解构
- `site/topic-superset-unpacked.html` - Superset 解构
- `site/topic-sourcemap.html` - Source Map 源码专题
- `site/topic-source-derived.html` - 源码反推思想
- `site/topic-cc-buddy.html` - Buddy 彩蛋
- `site/topic-openharness.html` - OpenHarness
- `site/topic-cc-release-watch.html` - 发版监督
- `site/s01.html` ~ `site/d12.html` - S/D 课程讲义

## 使用方式

```
/gen-zhihu-article [主题名或页面路径]
```

例如：
```
/gen-zhihu-article topic-superset-unpacked
/gen-zhihu-article S01 Agent Loop
/gen-zhihu-article 源码反推思想
```

## 生成要求

- 生成前先检查 `wemedia/zhihu/articles/STYLE-AUDIT.md`
- 如果 `STYLE-AUDIT.md` 已经指出最近 2 到 5 篇存在明显的开头、正文节奏或结尾重复，优先换一种风格再写
- 生成前至少做一次最小避重判断：
  - 这篇是否又在使用和最近 2 篇相同的开头句式
  - 这篇是否又在使用和最近 2 篇相同的正文节奏
  - 这篇是否又在使用和最近 2 篇相同的结尾模板
- 如果三项里有两项相同，默认必须切到另一种风格再生成
- 默认先判断最适合的文章风格，再写内容
- 如果最近几篇知乎稿开头和结构过于相似，主动换一种表达
- 默认做一次 `去 AI 味` 自检，特别检查是否出现了模板化的 `不是……而是……` 连续对照句
- 保持站内证据和链接完整，但不要让文风变成流水线模板
- 对站内专题改写成知乎稿时，默认不要写成整篇“推荐站点 / 推荐页面”口吻
- 允许推荐段落存在，但正文主体必须有真材实料：原理、机制、实现、工作流、源码点、决策依据，至少占主文大头
- 如果主题本身更适合讲技术而不是导览，优先切到 `纯干货 / 原理型`
- 只有当专题已经成熟、结构清晰、图文完整、经得起外部点击时，才适合走更明显的专题推荐写法
- 如果正文依赖代码做判断，默认至少展示 1 到 3 个关键代码摘录；不要只给路径而不展示实现片段

## 发布前文案审核（诊断）

在交给 `zhihu-publish` 之前，默认再做一次最终文案审核。至少检查这四项：

1. 去 AI 味道
- 去掉模板化、机械化、过度整齐的表达
- 严格压低 `不是……而是……` / `不只是……而是……` / `真正重要的不是……而是……`

2. 更专业化
- 让表述更像技术作者，而不是营销文案或口播稿
- 术语要准，判断要稳，少用夸张词
- 对能讲原理的主题，优先写原理，不要把篇幅浪费在泛泛夸赞上

3. 更自然可读
- 减少过度解释、过密转折、重复引导
- 句子能短就短，能直接下判断就别绕

4. 更证据化
- 结论要能回指页面、仓库、脚本、论文或已验证结果
- 不要出现证据不足却说得很满的判断
- 当证据来自代码时，优先给“路径 + 摘录 + 一句解释”的组合，而不是只给路径