这篇文章是怎么被 AI 写进官网的

你正在读的，不是一篇介绍“AI 自动化可以做什么”的概念文章。

它本身就是那条流程跑出来的结果。

这篇文章先出现在选题池里，随后被整理成内容原子和唯一母稿，经过事实与结构校验，导出到 Astro 官网，完成生产构建，再通过 Git 进入发布链路。

如果其中任何一道检查失败，你现在就不应该在官网看到它。

所以这次我想公开的，不是一个提示词，而是一篇内容从想法到公开页面之间，究竟经过了什么。

第一步：AI 没有从空白开始写

这篇文章对应内容编号 FSI-2026-004。

它来自内容运营仓库 20-Topics/选题池.md 中 P4“Skills 与公开实践”下的选题：

一条内容背后的 AI 工作流

在真正动笔前，AI 先读取了品牌定位、发布体系、已经发布的文章，以及当前能够公开的技术证据。它没有自己决定品牌要说什么，也没有补造一个“全自动内容工厂”的故事。

人先给出了两个关键约束：

• 就写这条选题；
• 只使用当前真实存在的内容运营、校验、Astro 构建和 Git 发布记录。

AI 的第一个作用，不是代替选题判断，而是把已经确定的意图放进现有系统。

第二步：先写内容原子，再写公开母稿

这套内容系统没有把一篇文章只保存成一个孤立的 Markdown 文件。

AI 先创建内容原子：

30-Content-Atoms/FSI-2026-004-这篇文章是怎么被AI写进官网的.md

内容原子不直接发布。它记录用户问题、唯一核心主张、真实证据、边界、用户行动、平台标题，以及下一步要核对的结果。

然后才创建唯一母稿：

40-Source/FSI-2026-004-这篇文章是怎么被AI写进官网的.md

母稿是公开内容的事实源。以后标题、观点或证据发生变化，应该先回到母稿修改，而不是分别去改官网、公众号和短视频文案。

这一步解决的不是“AI 会不会写”，而是另一个更实际的问题：

当同一主题出现多个平台版本时，哪一份内容对事实负责？

第三步：证据不完整，流程就应该停

写完不等于可以发布。

内容运营仓库提供了一条明确的校验命令：

pnpm content:validate FSI-2026-004

它会检查：

• 内容 ID 的格式，以及内容原子和唯一母稿中的 ID 是否一致；
• 状态是否已经允许进入生成流程；
• fact_status 是否为 checked；
• 内容原子是否真的包含一条核心主张、至少一项真实证据和一个用户行动；
• 唯一母稿是否包含标题和必要的 Frontmatter；
• source_file 是否指向实际存在的母稿。

如果把 fact_status 改成 unchecked，生成会被拒绝。仓库测试里也专门保留了这个失败场景。

但这里必须说明一个边界：

checked 不是“AI 认证为真”。它只表示发布者已经回到代码、文件或原始记录核对过证据。事实是否值得公开、解释是否准确，责任仍然在人。

第四步：生成发布工作区，但不覆盖人工记录

校验通过后，AI 调用：

pnpm content:generate FSI-2026-004

这条命令会生成平台发布包、发布清单，以及素材目录：

50-Platform-Packages/FSI-2026-004-发布包.md
70-Publishing/FSI-2026-004-发布清单.md
60-Assets/FSI-2026-004/{raw,working,final}

这里有一个我认为比“自动生成”更重要的设计：脚本只管理带有生成标记的区块。

真实发布链接、人工备注和复盘数据不在自动覆盖范围内；如果已有文件没有生成标记，脚本会把它视为人工维护文件并保留。

自动化应该减少重复工作，但不能因为再次运行，就擦掉一个人已经填写的真实结果。

第五步：公开正文进入 Astro，而内部记录留在内容仓库

进入官网使用的是另一条命令：

pnpm content:export:website FSI-2026-004 \
  --slug how-ai-wrote-this-article-into-website

导出工具不会把整份内部母稿原样搬到公开网站。

它会先执行同一套内容校验，再自动移除“源内容事实记录”等内部段落，把公开正文写入官网的文章集合：

src/content/articles/how-ai-wrote-this-article-into-website.md

文章的 sourceId、标题、发布日期、作者、主张、行动和状态会进入 Frontmatter。Astro 的 Content Collection 使用 Zod Schema 检查这些字段，缺字段或格式错误都会让构建失败。

随后执行的是一次真正的生产构建：

pnpm build

文章列表和首页“最新文章”都读取同一个已发布集合，并按发布日期和内容编号排序。因此新增文章不需要再手工修改一个首页数组。

到这里，AI 不是把文字“粘贴”进网页，而是提交了一份必须通过网站编译器检查的内容源。

第六步：构建通过之后，Git 才负责发布记录

本地 Astro 构建通过后，发布工具依次执行：

git add .
git commit -m "Publish: 这篇文章是怎么被 AI 写进官网的"
git push

如果没有新增变更，它不会制造空提交；如果提交或推送失败，工具会明确报告“内容已经导出，但 Git 提交或推送失败”，而不是把本地成功冒充成线上发布。

推送到 main 后，GitHub Actions 还会在新的环境中重新完成一次：

检出代码
→ 安装锁定依赖
→ Astro 构建
→ 把 dist 静态产物提交到 deploy 分支

这条链路在本篇之前已经留下真实记录。官网仓库中可以核对三条 Publish 提交：48e18c2、62ca3c3、4f4e2da；最近一次对应的部署提交是 ab65336。

这篇文章的首次 Git 发布也已经留下了自己的记录：官网源码提交是 80ebe8f，提交标题是 Publish: 这篇文章是怎么被 AI 写进官网的；GitHub Actions 生成的静态产物提交是 fa4192d，提交标题明确指向完整的 80ebe8f。

但这次实测也暴露了发布链路的最后一个边界：deploy 分支生成后，公开文章 URL 仍然返回 404，官网服务器还停留在更早的静态产物。

因此，Git 发布成功不等于域名已经上线。在宝塔服务器同步最新 deploy 产物、公开 URL 返回 200 之前，内容运营状态仍然保留为 ready，而不是提前改成 published。

这也是“可核验”最朴素的含义：不是相信一张工作流示意图，而是能顺着文件和版本记录找到它实际发生过。

AI 做了什么，人又做了什么

把整条流程回看一遍，人机分工其实很清楚。

AI 完成了：

• 读取选题和已有事实；
• 把信息整理成内容原子和母稿；
• 按仓库规则创建文件；
• 调用校验、生成、构建和 Git 发布命令；
• 读取错误，并在失败时停止。

人仍然负责：

• 为什么现在写这个选题；
• 哪些内部信息可以公开；
• 证据是否足以支撑主张；
• 文章是否符合自己的真实判断；
• 是否最终允许它进入公开官网。

所以，我不会把这套流程称为“AI 替我运营了内容”。

更准确的说法是：

AI 缩短了从选题到可发布版本的距离，而内容结构、校验闸门和 Git 记录，让这段距离没有变成黑箱。

一条真正的 AI 内容工作流，至少应该留下什么

如果你也准备让 AI 把内容写进官网，不必先复制这套目录或技术栈。

先为下一篇内容留下三个东西：

唯一内容 ID
证据核验状态
发布提交记录

唯一 ID 让多个版本指向同一来源；证据状态防止生成结果伪装成已确认事实；提交记录回答“公开页面到底来自哪一次修改”。

少了其中任何一个，都可以生成文章，但还很难称为一条可追溯的发布流程。

这篇文章的内容编号是 FSI-2026-004。

你可以从页面底部看到它，也可以沿着这个编号回到内容原子、唯一母稿、官网文章和版本记录。

这一次，文章本身就是证据。