很多人以为，写公众号最难的是“下笔”。
但真正做过一整套内容生产的人都知道，最耗时间的，往往不是写，而是写之前的搜集、写完后的审稿、排版、配图，以及最后发到公众号后台时的一堆细节处理。
你可能也经历过这些场景：
○ 选题有了，但资料散在各个网页、文档、论坛和公众号里，根本不成体系；
○ 初稿写出来了，总觉得像在“堆信息”，逻辑不够稳，语气也不够像公众号；
○ 好不容易改完了，还要重新找图、做图、排版、转 HTML；
○ 最后临门一脚，发布到公众号草稿箱时，又要处理 AppID、IP 白名单、封面图 media_id 这些问题。
所以我做了一个技能：zhy-article-writing。
它不是单纯“帮你写一篇文”，而是把公众号内容生产拆成一套可执行、可复跑、可追溯的工作流。你只要给它一个主题，它就能从搜集资料开始，一路帮你走到文章落入公众号草稿箱。
它不是写作助手，而是一条完整的写作流水线
zhy-article-writing 的核心思路很简单：把公众号写作拆成清晰步骤，让每一步都有输入、有输出、有痕迹可追。
整个流程被拆成了 Phase 0 + Steps 1-8：
1. 先做预处理，确定目录和产物路径
技能启动后，第一件事不是直接生成正文，而是先创建稳定的工作目录。
比如一次写作任务，会把内容落在：
articles/<slug>/...
这里面会包含文章正文、素材证据池、审稿报告、插图版文章、微信 HTML 等文件。这样做的好处，是后续你想回看、重跑、局部修改，都有路径可追，不会变成“一次性输出”。
2. 搜资料，而且不是随便搜
很多 AI 写作最大的毛病，是“看起来像知道很多，实际上没有证据链”。
所以这个技能最重要的一步，是先建立证据池。
它会优先从多类来源去抓素材：
○ 官方资料
○ 社区讨论
○ 工程实践
然后把结果整理成 evidence.md，每条都带上：
○ 标题
○ URL
○ 发布时间
○ 来源类型
○ 关键要点
○ 可信度
这意味着文章里真正有价值的结论，不是“凭感觉写”，而是能追溯到原始信息来源。
3. 初稿不是终点，审稿才是关键
写公众号最容易忽视的一点，是“写完不等于能发”。
zhy-article-writing 在初稿之后会再做一轮智能审稿，重点看四件事：
○ 逻辑是否成立
○ 表达是否顺畅
○ 数据和案例是否靠谱
○ 结构与节奏是否适合公众号阅读
而且它不是只说一句“还不错”，而是会输出单独的 review.md，把问题和评分留存下来。
这一步的价值非常大。因为很多文章问题并不在某一句话，而是在“标题承诺了一个价值，正文却没真正兑现”。如果不做这一步，文章很容易显得散、虚、空。
4. 它会继续润色，把文章从“能看”拉到“能发”
在审稿之后，技能还会继续打磨正文。
它会重点处理这些问题：
○ 去掉明显 AI 痕迹
○ 优化句子节奏
○ 增强公众号语感
○ 修复审稿中发现的逻辑和结构问题
最后得到的是一篇更接近真实公众号作者风格的成稿，而不是停留在“像一篇说明文”的层面。
真正让我满意的，是它把配图也纳入了系统里
我后来又把 zhy-article-illustrator 接进了这套流程里，所以现在写完文章之后，还能继续自动配图，还可以选择上传到oss，我使用的七牛云，这个可选，如果告诉AI将图片上传到七牛云，就会调用七牛云接口，将图片上传到七牛云，然后拿回图片链接地址。
这一步不是简单“随便生成几张图”，而是走一套更像编辑流程的机制：
1. 先生成 visual bible，再决定每张图怎么画
配图时，它不会一张图一个风格乱飞，而是先为整篇文章生成一份 visual-bible.md。
你可以把它理解成整篇文章的视觉总纲：
○ 这篇文章整体是什么风格
○ 用什么主色和辅色
○ 图形语言是什么
○ 中文文字怎么展示
○ 哪些英文术语允许保留
这样做的结果是：同一篇文章里的图，会明显是同一组，而不是东拼西凑。
2. 再生成 outline 和 prompts，把图像规划结构化
在视觉总纲之后，它还会生成：
○ outline.md
○ prompts/
outline.md 决定每张图放在哪里、解决什么信息表达问题；prompts/ 则是每张图的结构化提示词。
我专门把这部分优化成了更适合中文公众号的方式：
○ 默认中文可见文字
○ 同篇统一风格
○ 优先做高完成度编辑视觉
○ 尽量减少英文 UI 残留
3. 默认使用第三方接口 Nano Banana 模型
现在这套配图流程，默认使用的是 Gemini 兼容接口：
○ image_provider: xxx
○ image_model: gemini-3.1-flash-image-preview
○ image_size: 1K
这意味着你在大多数情况下，不需要自己手动改 provider，就能直接进入默认生图链路。
文章写完以后，还能一键转成微信公众号 HTML
如果你做过公众号排版，就知道一件事：普通 Markdown 不能直接等于公众号可用内容。
公众号环境对 HTML 很挑，尤其是样式必须尽量内联化，否则后台会吃掉样式或者排版走样。
所以我又接了 zhy-markdown2wechat。
这一步的作用是：把文章 Markdown 转成微信环境更友好的 HTML，并注入主题样式。
最后会产出：
article.zhy.html
这份 HTML 不是随便导出的网页，而是专门为了公众号粘贴或上传而准备的版本。
最后一步，是把它真正送进公众号草稿箱
很多流程做到这里就停了：文章有了、图有了、HTML 也有了，但最后还是要人手动打开公众号后台再操作一遍。
我不太喜欢这种“还差最后一步”的半自动状态，所以又接了 zhy-WeChat-Publish。
只要配置好公众号凭据和运行环境，它就可以把 HTML 文章直接送进公众号草稿箱。
这里有几个必要条件：
○ WECHAT_APP_ID
○ WECHAT_APP_SECRET
○ 机器公网 IP 已加入公众号后台白名单
○ 可用的封面图 media_id
满足这些之后，整条链路就真的闭环了：
从一个主题开始，到公众号后台看到草稿结束。
这套技能最适合什么人？
如果你只是偶尔写一篇随笔，那它可能显得有点重。
但如果你属于下面这几类人，它会非常合适：
1. 持续做公众号更新的人
你需要稳定产出，而不是偶尔灵感写作。那“可复跑、可追溯、可复用”的流程价值会非常高。
2. 既要内容质量，又要效率的人
很多人想提效，最后牺牲的是质量；很多人想保质量，最后牺牲的是时间。
这套技能真正想解决的，是把这些环节系统化，让效率和质量不必完全对冲。
3. 需要团队化协作的人
因为产物会完整落盘，所以它也适合拿来做多人协作：
○ 有人负责选题
○ 有人复核证据池
○ 有人审稿
○ 有人最后确认发布
每一步都有对应文件，不会全靠口头传达。
它最终产出的，不只是一篇文章
一次完整执行后，通常会得到这些文件：
○ article.md
○ sources/evidence.md
○ sources/review.md
○ article.illustrated.md
○ illustrations/<slug>/visual-bible.md
○ illustrations/<slug>/outline.md
○ illustrations/<slug>/prompts/
○ article.zhy.html
从这个角度看，zhy-article-writing 真正交付的不是“文章文本”，而是一整套公众号生产资产。
而这也是我为什么一直在打磨它：
因为我想要的，不是一个只会写字的工具，而是一条能真正落到生产中的内容工作流。
如果你也在做公众号，这套方式可能会很适合你
现在很多人谈 AI 写作，讨论的还是“它能不能替我写一篇文章”。
但我越来越觉得，更值得做的方向，其实是：
把写作、审稿、配图、排版、发布这些环节，真正连成一套可执行系统。
zhy-article-writing 就是沿着这个方向做出来的。
它不追求一句话惊艳，而是追求整条链路都省心。
如果你也在折腾公众号内容生产，欢迎试试看。你可以从一个主题开始，让它把整条流程跑完，再看这套方式是不是你想要的那种“稳定写作系统”。
