| 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 / 相关文章入口
图片引用格式

代码证据格式
如果文章的判断依赖仓库实现、脚本逻辑、协议细节或源码结构,不要只写文件路径。
默认做法:
- 先给路径,说明证据来自哪里
- 再给 3 到 12 行最关键的代码摘录
- 用 Markdown fenced code block 展示
- 代码块后用 1 到 3 句解释“这段代码证明了什么”
推荐写法:
在 tools/foo.py 里,关键逻辑是:
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 之前,默认再做一次最终文案审核。至少检查这四项:
- 去 AI 味道
- 去掉模板化、机械化、过度整齐的表达
- 严格压低
不是……而是…… / 不只是……而是…… / 真正重要的不是……而是……
- 更专业化
- 让表述更像技术作者,而不是营销文案或口播稿
- 术语要准,判断要稳,少用夸张词
- 对能讲原理的主题,优先写原理,不要把篇幅浪费在泛泛夸赞上
- 更自然可读
- 减少过度解释、过密转折、重复引导
- 句子能短就短,能直接下判断就别绕
- 更证据化
- 结论要能回指页面、仓库、脚本、论文或已验证结果
- 不要出现证据不足却说得很满的判断
- 当证据来自代码时,优先给“路径 + 摘录 + 一句解释”的组合,而不是只给路径