harzva 知乎文章生成器
根据指定主题生成知乎风格文章。
风格规则
不要把所有文章都写成同一种模板。生成前先判断最适合的风格，并在同批次文章里避免连续重复同一种开场和收束。
去 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- OpenHarnesssite/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 味道
- 去掉模板化、机械化、过度整齐的表达
- 严格压低
不是……而是……/不只是……而是……/真正重要的不是……而是……
- 更专业化
- 让表述更像技术作者，而不是营销文案或口播稿
- 术语要准，判断要稳，少用夸张词
- 对能讲原理的主题，优先写原理，不要把篇幅浪费在泛泛夸赞上
- 更自然可读
- 减少过度解释、过密转折、重复引导
- 句子能短就短，能直接下判断就别绕
- 更证据化
- 结论要能回指页面、仓库、脚本、论文或已验证结果
- 不要出现证据不足却说得很满的判断
- 当证据来自代码时，优先给“路径 + 摘录 + 一句解释”的组合，而不是只给路径