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 里，关键逻辑是：

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. 更证据化

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