最开始，我只是想让 AI 帮我把一篇文章改写成多个平台版本。
这个需求听起来很小，但做着做着，它演变成了一套完整的系统——有原文管理、有平台适配、有发布前审查、有发布记录、有数据快照、有复盘回路。过程中最有意思的不是技术实现，而是我对"AI 工作流"这个概念的认知变化。
背景：从一个简单需求开始
我有一些文章，想发到不同平台。公众号要完整一点，知乎要有讨论感，掘金要偏技术，小红书和抖音又不能照搬长文。既然 AI 能改写，那就让 AI 帮我把一篇 Markdown 适配成多个平台版本。
最初我只是做了一个 platform-publisher skill，让它围绕一篇 source.md 生成多个平台的发布版本。效果不错——AI 确实能改写。
但问题很快出现了。
问题：生成的下一步是什么？
AI 生成了五份文件，然后呢？这些文件有没有发布？什么时候发布的？数据表现怎么样？复盘结论在哪里？下一篇文章生成时有没有吸收上一次的反馈？
如果这些都靠人自己记，那系统很快就会变成一堆散落的 Markdown 文件。
这才是 AI 工作流的核心矛盾：AI 解决了生成问题，但它放大了管理问题。
解法：把内容变成生命周期对象
我引入了一个本地系统——「创作星图」。核心思路是把文章从"一个 Markdown 文件"变成"一个生命周期对象"：
| 概念 | 职责 |
|---|---|
| source.md | 原文 |
| platform variants | 平台版本 |
| variant-manifest.json | 版本清单 |
| PublishRecord | 真实发布记录 |
| MetricSnapshot | 数据快照 |
| ReviewReport | 复盘结论 |
关键约束链条：
生成了 ≠ 已发布
导入系统 ≠ 已发布
发布了 → 才登记发布记录
有发布记录 → 才录入数据快照
有数据快照 → 才有意义做复盘
这不是过度设计。AI 生成能力越强，人越需要知道"自己已经生产到了哪里"。不然生成速度只会变成负担。
架构：职责驱动的 skill 拆分
随着链路变长，系统里出现了多个角色：
- source-precheck：分析原文适合哪些平台形态，输出推荐目标
- platform-publisher：按推荐目标生成平台版本
- prepublish-review：发布前审查风险
- performance-review：发布后复盘
- orchestrator：串联整个流程
每个 skill 的边界被严格定义：
source-precheck: 只分析，不生成正文
publisher: 按目标生成，不做发布判断
prepublish-review: 只审查，不生产
orchestrator: 只调度，不替每个环节做判断
这是我刻意做的设计选择。一个什么都能做的 Agent 容易边界模糊。我更相信小而清晰的角色：输入清楚、输出清楚、职责清楚、不能越界。
一个具体的演进：标题门禁
标题是很好的例子来说明为什么职责拆分比"万能 Agent"更可靠。
最初生成的标题经常像内部文件名——"AI 协作工作流复盘"、"认知备忘录"。这些问题不是 AI 写不好标题，而是工作流里缺了一道门禁。
我把标题判断拆到三个 skill 中：
- source-precheck：提前给出标题方向的硬性约束（禁止内部归档词、必须有外部读者入口）
- publisher：生成标题时根据约束自检
- prepublish-review：发布前判断标题是否合格
每个 skill 只做自己职责范围内的事。如果要靠一个"万能 Agent"既分析内容又生成正文又审查风险，边界会越来越模糊。
另一个教训：格式校验是工程纪律
我花了很多精力优化标题质量，结果因为标题里出现了一个英文双引号，JSON 解析失败，整个导入链路中断。
这个教训是：AI 工作流中，只要产物会进入系统，就不能靠"看起来对"。
工程规则变成了：
- 生成 JSON 必须用序列化，不能手写拼接
- 生成后必须 JSON.parse 校验
- 标题里的双引号、换行、反斜杠，都不能破坏产物格式
- 校验失败不能继续进入导入流程
总结：从 prompt 到工作流
我现在理解的 AI 工作流，至少需要这些要素：
- 稳定输入 — contentId、source.md、平台配置
- 明确职责 — 每个模块做什么、不做什么
- 结构化产物 — manifest、JSON、HTML 报告
- 人工决策点 — 发布、取舍由人决定
- 格式校验 — 进入系统前必须校验
- 复盘回路 — 数据反哺下一次生成
- 克制 — 不是能做就每篇都做
AI 协作的关键不是让 AI 一次回答得多完美，而是把反复发生的工作沉淀成可运行、可检查、可回滚、可复盘的流程。从提示词到工作流，不是把事情变复杂，而是承认：如果我们想长期依赖 AI，就必须把它当成工程系统的一部分来治理。
讨论问题：
- 你在自己的项目里是怎么给 AI 划职责边界的？是让一个 Agent 管到底，还是拆成多个职责清晰的模块？
- 当 AI 生成的产物要进入你的工程系统时，你是怎么做校验的？
