夜雨聆风我把自己正在使用的全套 10 个公众号写作 Skill，连同 3 套自用 HTML 模板 Skill，一起开源了。
但真正难的从来不是让 AI 写出一篇文章，而是让选题、审稿、排版和发布不失控。
这套项目如何把一篇文章稳稳推进到公众号草稿箱？关键就在下面这套分阶段流程里。
项目名叫hu-wechat-article，覆盖选题、大纲、草稿、审稿、Markdown 格式化、HTML、封面和草稿箱发布。
每一步都有明确的输入、输出和确认节点，换个会话也能接着上次的进度继续。
项目地址：
https://github.com/lihu-001/hu-wechat-article
这套项目有一个核心规则：一次只执行用户明确确认的步骤。
推荐选题后，先等用户选择；选题确认后，只生成大纲；大纲确认后，才开始写草稿。
草稿完成后，审稿、格式化、HTML、封面和发布也分别执行。
这样做可以尽早发现问题。
选题不合适，就停在选题阶段调整；大纲逻辑不清楚，就先改大纲；草稿观点没讲透，就只处理正文。
不会等到 HTML 和封面都生成后，才发现文章方向错了。
小结：AI 负责执行当前任务，用户保留关键节点的决定权。
项目中的 Skills 按公众号文章的生产过程分工：
article-topic-ideation负责候选选题。它会参考系列定位和已有文章，避免重复已经写过的内容，并为下一篇找到合适角度。 article-draft-writing负责根据确认后的大纲撰写草稿。这个阶段先覆盖要点、形成完整正文，不要求一步达到发布标准。 article-review-refine负责审稿，检查结构、逻辑、重复内容和表达问题。 article-format负责 Markdown 格式优化，调整段落、小标题、重点标记和阅读节奏，不重新改变文章观点。 article-context负责扫描 Skills 和系列文章，生成上下文索引，让系统知道有哪些系列、写过哪些内容，以及每篇文章处于哪个阶段。
项目还包含三套 HTML 模板 Skill、封面生成和草稿箱发布能力，负责文章完成后的视觉呈现与发布衔接。
职责分开后，修改范围也更清楚。内容有问题就改内容，排版有问题就改排版，不会在一个步骤里反复牵动整篇文章。
series/归档每个系列的内容资产只在聊天窗口里写文章，内容很容易散落。
大纲在一次对话中，正文复制到另一个文档，HTML 和封面又放在其他位置。时间久了，很难确认哪个版本最新。
这个项目用series/统一管理正式文章。每个系列都有独立目录，并按内容类型划分：
series/ 系列名称/ drafts/ published/ images/drafts/保存 Markdown 源文件，从大纲、草稿、审稿到格式化，都在同一个文件上推进； published/保存生成后的 HTML； images/保存封面和正文图片。
每篇 Markdown 还通过 frontmatter 记录标题、系列、状态、创建和更新时间、字数、封面、HTML 路径及发布信息。
一个系列写了哪些文章，每篇走到哪一步，对应文件放在哪里，都能在series/中找到。
以后修改旧文、整理合集或复用内容，不必重新翻历史对话。
.context/保存可重建的上下文索引series/解决文章资产放在哪里，.context/解决 Claude Code 怎样快速了解这些资产。
article-context会扫描项目中的 Skills 和系列文章，在.context/中生成索引。
索引会记录已有系列、文章数量、主题、状态和最近进度。Claude Code 不需要每次遍历所有文件，就能判断当前应该继续哪篇文章。
这能减少两个常见问题：
- 选题重复
：开始新文章前，系统先参考系列定位和已有主题，不再只根据当前一句话发散； - 上下文丢失
：换个会话后，不需要重新解释“上次写到哪里”，系统可以根据索引和文章状态判断当前是在等待大纲确认、草稿审阅，还是准备格式化。
.context/不是文章正文的唯一存储，也不需要手工维护。
它只是根据 Skills 和series/中的文章扫描生成的派生索引。即使删除，也可以从现有文件重新生成。真正的文章内容仍然保存在series/中。
项目内置了三套 HTML 模板 Skill。
它们不是为了演示而制作的通用样例，而是我自己日常发布公众号文章时正在使用的模板。
html-black-gold：黑金科技风，用于 Claude Code、开发工具等科技类文章； html-blue-cyan：蓝青科技风，用于 AI 编程系列和技术教程； html-green-editorial：暗绿编辑风，用于公众号实战系列和经验总结类文章。
维护不同系列时，我不想每写一篇文章都重新调整字体、颜色、间距、引用块和代码块样式。
把已经使用稳定的模板封装成 Skill 后，同一系列可以保持统一的视觉风格，也减少了重复调整 CSS 的时间。
三套 Skill 会保留标题层级、段落、加粗、列表、引用、代码块、表格、图片和链接等语义，再转换成适合微信公众号复制和阅读的单文件 HTML。
Markdown 仍然是文章源文件，HTML 只负责最终展示。内容修改和视觉样式不会混在一起。
模板采用微信兼容的单文件 HTML，并保留关键节点的内联样式，同时检查移动端宽度、横向溢出、图片路径和文字对比度。
这能降低复制到公众号后台后背景丢失、长代码撑破页面或图片失效的概率。
小结：这三套模板不只是三种配色，而是我自己验证过的公众号排版方案。
文章正文完成后，还要生成 HTML、准备封面，并把标题、摘要、正文和图片放进公众号后台。
这些步骤单次不复杂，持续更新时却很容易遗漏或混乱。
cover-image负责生成公众号封面，draft-publisher负责把准备好的文章提交到公众号草稿箱。
HTML、封面和发布分别执行，用户可以在每个节点检查结果。
发布前先处理正文图片并回写微信托管地址，用户确认后才上传封面并创建草稿。它只进入草稿箱，不会直接群发。
文章状态中会保留封面、HTML 和草稿箱相关信息。以后查看文章时，可以知道它是否已经生成 HTML、是否有封面，以及是否提交过草稿箱。
从选题到发布，每一步都有明确的输入、输出和状态。对持续写公众号的人来说，这比一次性“全自动生成”更稳定。
我开源这套公众号文章 Skills，不是想做一个“一句话生成爆款”的工具。
它解决的是更具体的问题：避免流程混乱，保留人工确认，保存文章状态，延续系列上下文，分开内容与排版，并减少文章进入草稿箱前的重复工作。
AI 可以参与每一步，但不会替用户决定所有事情；文章可以随时停下来修改，也可以在新的会话里继续。
每次创作的结果都会沉淀成文件，而不是只留在聊天记录中。
项目地址：
https://github.com/lihu-001/hu-wechat-article
后续持续更新 AI 编程实战技巧。
往期文章请查看：公众号历史文章合集
关注本号，不错过 AI 编程干货，转发收藏，开发遇到问题随时翻阅。