我搭建了编辑流水线，后来又把暂停放了回去

AI 有一个惊人的特点：它从不吝惜再写一段，再来一段。自动化足够多时，总有一天会发现，编辑团队最大的限制，是人能否读完团队已经生产出的内容。

在早期 Content OS 中，我探索从 Custom GPT 到结构化内容包的路径。ContentPack 的想法是把准备好的字段、内容块和本地化文本传下去，而不是传一堆聊天回复。

下面是 Publisher 的存档界面，使用虚构材料。原始故事集中在一个编辑器中；这是早期实验画面，并非 nevsky.ae 当前的发布系统。

原始材料编辑器

归档界面 · 演示数据

内容包要知道自己改了什么

这种格式与源版本关联很有用。如果内容包准备后文本又被修改，旧提议就不能悄悄覆盖新工作。实验流程通过源指纹和选择性应用变更来处理这一点。

这里按发布平台把材料拆成卡片。可以查看准备好的英语版本与分发编辑器结构。这份演示不会发送任何发布内容。

不同平台版本

归档界面 · 演示数据

结构验证回答内容包的格式是否正确。语义检查回答各部分是否属于这篇材料。两者之间有距离：JSON 可以完美无缺，却包含虚构传记、丢失的说明或别篇文章的翻译。

矩阵展示虚构材料在不同发布方向上的状态。这是另一种看清内容包哪些部分仍需编辑工作的方式。

就绪状态矩阵

归档界面 · 演示数据

内容包是变更提议。它不该仅因通过语法检查，就自动变成公开页面。

这个屏幕展示用于后续交接的 JSON 包。可以检查结果结构；内容包存在不代表获准自动发布。

ContentPack 交接

归档界面 · 演示数据

我现在怎样工作

对于 nevsky.ae，我选择更直接的顺序：准备并确认俄语文本、翻译、图片和呈现方式；交给 Codex；修改 content 中的文件；本地查看结果；再单独决定是否发布。

这就是当前流程。ContentPack 仍是设计编辑交接的有用经验，不是现在暗中自动发布我博客的工具。

乍看，手工交接像是在倒退。但它把暂停放在正确的位置：别人看到署我名字的文章之前。在这个暂停中，可以发现旧原型被称为成品、技术词只为装饰，以及作者据说经历了根本没发生的事。

我从早期 Content OS 保留了结构化材料和变更检查。今天的博客使用自己的准备流程和人工确认文本。文中的 Publisher 界面展示旧工具，而不是另一个正在运行的 Nevsky.ae 编辑部。

相关故事：Nevsky.ae 的历史 · Contra MCP Starter · Source 与 Operator。