CoverAI AI 工作流实测

从生成正文到真实发布

文章导读

先说结论

Codex 负责生成，我负责在关键节点确认。

这篇复盘第一篇文章如何从初稿走到微信公众号 v5 发布。

**核心问题｜**AI 生成后，怎样真正发布

**真实案例｜**第一篇公众号完整试跑

**关键返工｜**本地正常，粘贴到后台后变样

**最终方法｜**逐节确认，放进真实后台验收

01｜工作流起点

我原本只是想让 Codex 帮我写一篇公众号文章

最开始，我并没有打算搭一套微信公众号工作流。

当时的想法很简单：我平时已经在用 Codex 开发产品、修改网站和整理内容，那么写公众号文章时，能不能也让它帮我分担一些工作？

给它一个主题，让它列出大纲、生成正文。我检查一下，再复制到微信公众号后台。

听起来，一个足够详细的提示词就能解决。

但真正开始第一篇文章以后，我才发现，生成正文只是最前面的一步。

第一版很快就出来了，粗看很顺，但细看就会发现不少内容不能直接使用。有些话虽然没有明显错误，却不是我的真实经历；有些判断写得很确定，却缺少可以核对的来源。这些内容都要重新确认、删改，不能直接复制到公众号后台。

我原本以为，把正文里的这些问题改清楚，文章就差不多完成了。实际往下走才发现，定稿之后还有封面、配图、排版和手机预览；等到真正复制进微信公众号后台，又会遇到新的兼容问题。

第一篇最后虽然成功发布了，过程却比我预想的多了很多来回。正文需要逐节修改，事实需要单独核对，排版也经历了多次返工。最折腾的是微信公众号兼容结构，前四版都出现过不同的问题，直到第五版才通过后台验收。

到这里我才确定，自己需要的不是一个“自动写完全文”的按钮，而是一套能把选题、写作、核验、排版和发布串起来的流程。

而这套流程的第一条规则，恰好和“全自动写作”相反：

不要让 Codex 一次写完整篇文章。

图片

一篇文章的八步工作流：Codex 可以连续执行，但关键节点仍由人工确认。

02｜逐节确认

我做的第一个决定，是不让 Codex 一次写完整篇文章

有了第一篇的经历，我先改掉了最初的做法：不再给 Codex 一个主题，让它直接生成全文。

因为全文一旦铺开，修改起来很容易失去边界。

开头不合适，可能会影响后面的叙述；某一节技术内容太多，删减时又会牵动前后的过渡。等几千字全部写完再调整，看起来省了一次确认，实际上更容易大段返工。

所以，我把写作过程拆成了几个阶段。

先确定选题角度，再整理大纲。大纲确认后，每次只写一个小节。当前这一节的内容、篇幅和语气通过了，再继续下一节。

第一篇的第 3 节就经历过一次这样的修改。初稿虽然把技术口径解释清楚了，但内容太长，放在整篇文章里显得很重。

问题是在逐节确认时发现的，所以这次只需要删减第 3 节中过多的技术说明，没有牵动前面已经确认的内容，也避免了全文完成后再回头调整。

全文完成后，Codex 再统一检查重复结论、术语和段落节奏。涉及真实经历、事实来源和最终取舍的部分，则留给我确认。只有正文正式定稿，流程才会继续进入排版、封面和发布预检。

现在，这套流程被拆成了八个阶段：

选题 → 大纲 → 逐节初稿 → 风格改写 → 人工打磨 → 排版 → 封面 → 发布预检

它并没有让写作完全自动化，反而增加了几个需要我停下来确认的节点。

但这些停顿不是在拖慢进度，而是为了尽早发现问题。大纲不对，就不要急着写正文；当前小节不对，就不要把问题带到后面；事实还没有确认，就不要提前进入排版。

我后来发现，和 Codex 一起写文章时，真正省时间的不是让它一口气写得更多，而是在每个关键节点停下来确认，发现问题就及时修改。

图片

第二篇的真实修改过程：发现问题、局部修改、放回全文，再由人工确认。

03｜人机分工

Codex 可以继续写，但哪些内容能留下，由我决定

就拿正在写的这篇文章来说。

我先给了 Codex 一个主题：我用 Codex 搭建了一个微信公众号工作流。

它给出了五个角度，我从中选定一个。大纲出来以后，我觉得方向没问题，就让它开始写第一节。

第一版写得太长，我让它压缩。压缩以后，有几句话读起来还是很像 AI，我又把具体位置指出来，让它重新改。

有时问题不在某一个词，而是两段话接不上；有时一句话意思没错，但正常聊天时我根本不会这样说。遇到这种情况，我不会让 Codex 猜我的意思，而是直接告诉它哪里不自然、为什么不能用。

你现在读到的这一段，也是这样一轮轮改出来的。

Codex 可以很快给出角度、大纲和初稿，也能根据反馈继续修改。但它并不知道哪一句像我，哪一段写得太满，哪个结论虽然正确，却不适合放在这里。

这些事情只能由我来判断。

第一篇里写到了应用版本、额度接口和公开安装包，我让 Codex 回到项目文件、官方文档和 Release 页面逐项核对。至于第一版到底开发了多久，因为没有留下可靠记录，最后就没有写进正文。

所以，我在这套工作流里做的并不是最后看一眼，而是一直参与选题、修改和确认。

Codex 负责把内容写出来，我负责决定什么能留下。

等正文全部确认以后，我们才开始处理排版。

而第一篇文章真正复制进微信公众号后台时，又出现了新的问题。

04｜兼容返工

本地预览正常，复制进微信公众号以后却变了样

第一篇正文定稿后，Codex 根据文章生成了 HTML。

我先在浏览器里检查了一遍。电脑端没有出现横向溢出，手机尺寸下的文字、图片和表格也能正常显示。确认排版没有明显问题后，我把它复制进微信公众号后台。

结果刚粘贴进去，页面就变了。

顶部原本分开的几项内容挤在了一起，蓝色背景没有完整保留，有些边框和间距也消失了。本地预览里已经调好的版式，到了公众号编辑器里，只剩下文字还是对的。

问题不在正文，而在公众号后台会重新处理粘贴进去的 HTML。

第一版里用了 flex、gap 和一些较复杂的样式。这些写法在浏览器里没有问题，进入公众号后台后却不够稳定。

接下来，Codex 负责修改本地文件，我负责把每个新版本重新粘贴到后台检查。

有一版解决了文字挤在一起的问题，但背景和边框还是会丢；另一版调整了复制方式，本地按钮可以正常工作，粘贴后的效果仍然需要继续改。

后来，我提供了一份以前成功复制到公众号的 HTML，Codex 按照它的结构重新做了第四版。新版本不再追求复杂布局，只保留简单的块级结构和内联样式。

在这个基础上，我们又继续压缩导读区域，调整首尾模块和人机分工卡片，最终做到了第五版。

第五版只使用六类标签：

section、p、strong、span、img、br

没有 flex，没有 grid，正文里也不再保留可能发布后失效的外部链接。

我把第五版重新导入微信公众号后台，检查排版后保存草稿，最后用它完成了正式发布。

这次返工让我补上了工作流里原本缺少的一步：

浏览器里的预览只能用来发现本地问题，真正的兼容结果，必须放进微信公众号后台再检查。

图片

本地预览正常不等于公众号兼容，最终版本必须放进真实后台验收。

05｜复用资产

第一篇留下来的，不只是一篇文章

第一篇发布完成后，我重新看了一遍项目目录。

里面不只有最终正文，还有来源记录、审核记录、文章信息、封面、正文配图、不同版本的 HTML 和最后的发布记录。

这些文件并不是一开始就全部设计好的。很多都是遇到具体问题以后才补上的。

比如，正文改了很多轮以后，我需要一份不会再被后续修改覆盖的定稿，于是保留了 final.md。

文章里出现了版本号、接口和公开下载地址，我需要知道这些内容从哪里来、什么时候核验过，于是有了 sources.md。

风格改写时，有些技术名称和风险说明不能被改掉；排版完成后，还要记录哪些内容已经检查、哪些仍在等待确认，这些都放进了 review.md。

到了发布阶段，我又需要记录最终使用的是哪一版正文、哪张封面、“阅读原文”指向哪里，以及文章是否已经发布，于是补上了 metadata.json 和 publication-record.md。

微信公众号的五个兼容版本也全部保留了下来。

前四版虽然没有成为最终发布版本，但它们记录了哪些结构在后台出现过问题。第五版则成为第二篇可以继续使用的排版基础。

当然，现在还不能说这套工作流已经完全通用了。

负责生成微信极简版的脚本里，仍然写着第一篇文章的标题、关键文案和 Release 地址。第二篇不能直接运行，还需要先把这些只属于第一篇的内容拆出去。

这也是我开始第二篇文章的另一个目的。

第一篇证明了这套流程可以走到正式发布；第二篇要继续检查，哪些部分真的能够复用，哪些地方只是刚好适用于上一篇文章。

比起重新准备一段更长的提示词，我更愿意把这些已经验证过的文件、规则和失败记录留下来。下一篇开始时，至少不用再从同一个坑里走一遍。

图片

第一篇留下的不只是一篇正文，还有来源、审核、排版版本和发布状态。

06｜发布边界

最后一步，我没有交给 Codex 自动完成

文章、封面和配图都准备好以后，我也考虑过让 Codex 继续操作，把内容放进微信公众号后台。

但真正执行时，浏览器在进入公众号后台的阶段就被安全策略拦截了。

Codex 没有换一种方式绕过去，也没有通过命令读取登录状态。操作到这里就停止了，文章、封面和配图都还留在本地。

后面的步骤由我手动完成。

我用第五版复制工具把正文导入编辑器，检查标题、封面、图片和手机预览，确认没有问题后保存草稿。

保存草稿以后，文章也没有马上发布。正式发表是另外一次确认，我完成最后检查后，才手动点击发布。

文章上线后，我又检查了公开页面、正文样式、五张图片和“阅读原文”的跳转结果。确认都正常，发布记录才更新为 published_verified。

这几个步骤在项目里是分开的：

本地发布包准备完成 → 后台草稿已保存 → 文章已经发布 → 线上结果已经确认

这样记录虽然麻烦一点，但不会因为生成了 HTML，就提前把文章写成“已经发布”；也不会因为我说已经发布，就假装 Codex 自动检查过公开页面。

整套流程里，Codex 可以完成本地检查，也可以帮我整理需要确认的项目，但公众号后台的登录状态、草稿保存和正式发布仍然由我控制。

我没有为了追求“全自动”，把账号凭据交给脚本，也没有让工作流在未经确认的情况下执行公开发布。

对我来说，这不是自动化没有做完，而是这一步本来就应该保留人工确认。

07｜第二次试跑

跑通第一篇以后，我开始用第二篇检查这套流程

第一篇正式发布，说明这套流程至少可以走完一遍。

从选题、大纲和逐节初稿，到事实核验、排版、封面、公众号兼容和正式发布，每个环节都有了实际结果。

但只完成一篇，还不能说明它已经成熟。

有些做法可能真的适用于下一篇，有些只是为了处理第一篇的具体问题。只有继续使用，才能把它们区分开。

现在这篇文章，就是第二次试跑。

第一篇验证了微信公众号第五版结构可以正常使用，第二篇会继续使用这套排版基础，但不会复制上一篇的故事、配图和结论。

写作过程也在继续接受检查。

这一次，Codex 仍然先提供选题角度和大纲，再按小节生成初稿。我会指出篇幅过长、前后没有过渡和表达太像 AI 的地方，修改通过后再继续下一节。

这些来回不会被当成多余步骤。它们会告诉我，哪些问题可以提前写进规则，哪些内容每次都需要人工判断。

接下来，我还会用同样的方法继续完成更多文章，并记录每一次返工的原因和结果。等到连续跑通 5 到 10 篇，再决定哪些环节适合做成更稳定的脚本，或者封装成 Codex Skill。

现在，这套工作流还远没有到“一键生成、一键发布”的程度。

但和第一篇开始时相比，我已经不需要从一个空白对话重新摸索。选题在哪里确认，事实在哪里记录，排版应该使用哪种结构，发布前还缺哪些检查，都已经有了固定的位置。

第一篇留下了答案，第二篇正在检查这些答案是否真的有用。

这也是我现在理解的工作流：不是提前设计出一套看起来完整的步骤，而是在一次次真实使用中，把有效的部分留下来。

CoverAI 工作流复盘

先跑通，再自动化。

把每次真实返工留下来，下一篇才有可以复用的规则。