从一篇文章到一套内容资产：我们怎样把公众号写作做成工程流水线

一篇文章写完了，不等于它已经能发。

7 月 14 日到 17 日，筑见实验室连续发布了四篇文章。主题从 AI 独立复核、年轻工程师的学习重点，一直延伸到 AI 看图纸实测和规范版本治理。每篇文章背后的资料、图片和事实边界都不同，最后却要进入同样的公众号、头条和网站发布流程。

这几天的工作让我们再次确认：技术团队做内容，最容易失控的地方往往出现在“写完以后”。事实有没有过期，图片是否齐全，标题和摘要是否一致，发布稿与源稿是否还是同一版，任何一项出错，都会削弱文章的可信度。

因此，我们给内容发布加了一道门禁。文章必须先成为一份可检查的交付物，再进入平台排版和发布。

但门禁只是表面。更重要的是，我们把写作从一次性的文案任务，变成可继续使用的内容资产：选题依据、事实来源、图片、修改决定和发布副本都能被下一篇文章、产品记录、培训材料或客户交流复用。

写作完成以后，才是错误高发区

富文本编辑器适合排版，却不擅长管理长期内容资产。

文章在聊天记录、文档副本和平台草稿箱之间来回流转，很快就会出现几个常见问题：作者改了正文，排版的人仍拿着旧版；一张图片被替换，正文引用却没有同步；标题改了，摘要和封面还停在上一版；平台里已经发出的内容，团队找不到当时对应的源稿和事实依据。

技术文章还多一层风险。产品版本、规范状态、测试结论和线上地址都可能变化。文字写得顺，不代表事实已经核对；图片看起来完整，也不代表它对应当前版本。

这类问题靠“发布时再仔细看一遍”很难稳定解决。人会疲劳，也会在临近发布时间时优先处理最显眼的格式问题。更稳的做法，是把容易重复检查的事项写进流程，让机器先拦住确定性错误，把人的注意力留给观点、事实和责任边界。

先把每篇文章变成一个完整交付单元

我们的做法很朴素：一篇文章对应一个独立的内容单元。

正文、元数据、写作记录和本地素材放在一起管理。正文只保留文章本身；标题、日期、作者、分类、标签、摘要和发布渠道单独记录；事实来源、待核事项和发布决策写进笔记；图片跟随文章保存，并用稳定的相对关系引用。

这样做的价值不在目录形式，而在职责清楚。

正文可以持续修改，元数据不会散落在不同平台；图片和文字一起迁移，不依赖某个人的桌面或聊天记录；发布后仍能回到当时的源稿，知道哪些结论经过核对，哪些边界被明确保留。

流程里的五个环节并不复杂：选题与定位、源稿写作、图片治理、发布预检、排版发布。真正起作用的是每一步都有明确产物，下一步不用靠口头猜测上一环节做到了哪里。

一篇文章在仓库里到底长什么样

我们愿意把这部分具体做法公开。每篇文章在内容库里都是一个独立目录，最小结构如下：

2026-07-18-文章标题/
├── article.md
├── meta.yaml
├── notes.md
└── assets/
    └── images/
        ├── 00_cover.png
        ├── 01_topic_diagram.png
        └── 99_about.png

article.md 是唯一正文源稿，不在里面混放平台配置；meta.yaml 记录标题、日期、作者、标签、摘要、渠道和状态；notes.md 记录事实来源、图片出处、删改理由和发布待办；assets/ 保存随文章迁移的本地素材。

元数据不追求复杂，先把会影响发布身份的字段管住。例如：

title: "文章标题"
date: 2026-07-18
author: "团队名称"
status: ready
channels:
  - wechat
  - toutiao
tags:
  - "核心主题"
summary: "这篇文章解决什么问题，以及读者能获得什么。"

状态只保留三个：draft 表示仍在写，ready 表示已经完成审校、等待发布，published 表示外部平台已经实际发布并完成归档。生成了网页不等于已经发布，状态也不会因为工具执行成功而自动升级。这个约束看似保守，却能避免团队把“产物生成成功”误当成“读者已经看到”。

发布门禁，具体检查什么

我们目前把发布前检查分成四层。

第一层是内容身份。标题、日期、作者、分类、标签、摘要和渠道要完整，草稿状态也要明确。它解决的是“这篇文章是谁、准备什么时候发、发到哪里”。

第二层是素材完整性。正文引用的本地资源必须存在，图片文件要能被正常读取。正文图片按首次出现顺序连续编号，封面和文末关注图片使用固定名称。编号规则主要靠编辑规范约束，工具负责检查资源引用和文件可用性。

第三层是发布目标。微信公众号、头条和网站对链接、图片与富文本的处理并不相同。发布前需要提前发现非安全链接、本地附件以及不适合目标平台的地址。对于产品发布或更新文章，体验入口也不能只写在内部笔记里；读者必须能在正文中找到它。

第四层是发布产物。源稿通过检查后，再生成供平台使用的 Markdown、HTML 和网站页面，同时保留图片映射与发布清单。发布副本可以做尺寸压缩，源素材不被破坏。这样一来，源稿、图片、发布稿和最终页面之间有了可以核对的关系。

这四层减少的，不只是发布时的低级错误，还包括错误进入下一环节后的返工。标题和日期在排版前发现，只需改一次元数据；进入三个平台后才发现，就要逐一替换。图片引用在生成发布稿前断开，只需补齐路径；文章发布后才发现事实版本不对，团队还要更正文案、解释原因，并重新建立读者信任。

这套门禁不会判断文章是否精彩，也不会替我们核实所有行业事实。它主要拦截缺字段、缺图片、无效引用和产物不一致这类确定性问题。事实是否可靠、结论是否克制、案例能否公开，仍然需要人工审校。

门禁之后，交付的是一套发布包

在我们的内容库里，正式发布前会先运行严格预检：

python tools/publish/publish.py --check --strict-check --draft <文章目录名>

--strict-check 会把警告也当成失败。通过后，再从当前源稿生成 Markdown、HTML 和网站页面：

python tools/publish/publish.py --target md,web --emit-html --draft <文章目录名>

这两条命令来自我们当前使用的内容库，不要求读者照抄，也不代表工具已经对外开放。真正值得复用的是这份契约：输入必须是完整内容单元，检查失败就不生成正式副本，检查通过后一次生成各渠道需要的产物和追溯记录。用 Python、Shell、CI 或现有 CMS 实现都可以。

最终交付的不只是一个可以复制粘贴的正文，还包括：

• article.publish.md：供 Markdown 排版和平台发布使用的当前副本。
• article.publish.html 与 index.html：HTML 发布稿和网站页面。
• assets/：从源素材生成的发布期图片副本，源图不被破坏。
• image-map.json：记录图片的源路径、发布路径和公网地址。
• publish-manifest.json：记录这次发布包来自哪篇源稿、包含哪些图片、当前是什么状态。

图片映射和发布清单并不是为了增加文件数量。它们解决的是发布之后最难回答的问题：页面上的这张图来自哪里，这一版正文由哪份源稿生成，重新发布时应该复用哪一批素材。对需要多平台运营、多人协作或长期维护技术内容的团队，这种追溯关系比某一次排版速度更重要。

发布前，先做一张十分钟复核卡

门禁不必一开始就很复杂。每次进入平台排版前，先用十分钟把下面五件事答清楚：

1. 文章身份：标题、日期、摘要、渠道和当前状态是否对应同一篇源稿？答不清就停在源稿阶段，不进入排版。
2. 事实边界：版本、规范、测试结论和线上地址是否已按当前状态核对？还不能确认的，标为待核或删去该判断。
3. 素材关系：每张正文图、封面和二维码是否都有明确来源，并与正文一致？缺图就补图、替换或移除引用。
4. 发布副本：本次要粘贴或上传的，是否由当前源稿生成？不是，就重新生成，不复用旧副本。
5. 人工责任：谁确认事实，谁确认公开边界，谁执行最终发布？没有明确责任人，就暂缓发布。

这张卡的作用不是增加一道形式流程。它让“能不能发”从临发布时的感觉，变成几个可以回答、可以交接的问题。任何一项答不清，文章就先不进入平台；宁可晚一点，也不要让一篇没有来源、没有当前版本或没有责任人的内容先跑出去。

工具门禁之外，还要有人接住责任

检查项写进工具以后，责任并不会自动消失。一条稳定的内容发布链，至少要区分三种角色：

• 作者确认来源、版本和原始材料，交出一份可追溯的源稿。
• 复核者确认事实边界、公开范围和高风险表述，给出能否发布的判断。
• 发布者确认渠道适配、当前副本和最终快照，留下这次实际发布的记录。

小团队里，这三种角色可以由同一个人承担，但三个动作不能混在一起。写作时关注表达，复核时主动找错，发布时只认当前通过门禁的副本。把动作分开，才能减少“刚改完就顺手发出”的盲区。

连续发布，检验的是流程稳定性

最近四篇文章恰好覆盖了不同的内容类型。

AI 独立复核文章需要区分模型自检、第二模型挑错、确定性工具验证和最终责任；年轻工程师文章需要把观点落到可执行的学习动作；AI 看图纸文章要保留测试条件、原始记录和方法缺口；规范版本文章则必须核对官方状态、数据治理边界和人工审查条件。

这些文章不能套用同一套论证模板，但可以共用同一套交付纪律：先确定读者问题，记录事实来源，准备本地素材，完成审校，再通过发布检查生成产物。发布完成后，源稿归档，发布快照保留，文章索引同步更新。

连续输出时，这种纪律比临场发挥更有价值。它让团队知道哪里可以复用，哪里必须重新核对；也让下一位接手的人不需要从聊天记录里还原整篇文章的来龙去脉。

AI 可以参与写作，但不能替代门禁

AI 已经进入我们的选题整理、初稿撰写和文字审校。它可以帮助压缩材料、发现重复表达、提出结构问题，也能根据检查结果修正格式。

但 AI 生成得越快，越需要明确的事实来源和发布边界。模型可能把过期信息写得很顺，也可能在修改一段文字时悄悄改变原来的限定条件。没有源稿、修改记录和人工复核，速度只会让错误更快进入发布端。

我们的分工是：AI 帮助生产和检查，人负责事实判断、公开边界与最终发布。工具门禁管确定性问题，编辑审校管文章是否值得发。

如果你的团队想照着做，先交付三个东西

不必先建设内容平台，也不必复制我们的工具。第一阶段只需要交付三个结果：

1. 一个内容单元：每篇文章只有一份源稿，元数据、笔记和图片跟随它保存。
2. 一张放行清单：写清哪些问题由工具检查，哪些事实由人确认，什么条件下必须暂缓发布。
3. 一份发布快照：保存当时实际使用的正文、图片和来源关系，发布后仍能追溯。

运行一段时间后，再记录三个数字：每篇文章发布前发现多少问题，跨平台修改一次需要返工多少份副本，发布后能否在十分钟内找到对应源稿。数字持续下降，说明流程在产生价值；如果只是多填表、多开会，却没有减少返工，就应删掉无效步骤。

内容工程化不是把写作变成流水账。它把重复、确定的工作交给规则，把需要判断的部分留给人，让团队有更多精力处理真正困难的事情：形成值得公开的观点，把复杂问题讲清楚，并对说出的每一句话负责。

关注我们

欢迎搜索并关注 筑见实验室，获取更多建筑 AI、结构计算与工程数字化实践：