前两篇把 workflow 和 skill 讲清了。这篇是最实在的一篇——我自己的「内容自动发布」就是典型的多步流程（审核 → 配图 → 发布 → 归档），按理是 workflow 的绝佳场景。 但我没用 workflow。我用的是「几个 skill + 一个状态机」。这不是不知道 workflow，是想清楚之后的主动取舍。这篇把我的考量摊开，对你判断「我该用哪种」会有参考价值。

一、先把我的流程摆出来

我的「AI 工具人 PM」内容发布，完整流程是这样：

写文章 → 人工确认 → 配图 → 人工确认 → 脱敏+传图 → 发布 → 归档

拆成职责，是三个 skill 各管一段：

• article-writing：管「怎么写文章」——标题怎么起、frontmatter 怎么填、脱敏红线
• article-illustrations：管「怎么配图」——中文手账风、图放哪个目录
• publish-workflow：管「怎么发布」——审核、调用平台接口、归档

注意看流程里那两处「人工确认」——这是关键，后面会讲它为什么直接改变了选型。

二、什么是「状态机」？我用什么当状态

我没写 workflow 编排脚本，那流程靠什么流转？答案是：靠文件夹和 frontmatter 当「状态」。

我的文章在不同阶段，物理上放在不同目录、status 字段取不同值：

待AI审核/   (status: 待审核)   ← 写完先放这
   ↓ 审核通过
待发布/     (status: 待发布)   ← 确认后移到这
   ↓ 发布成功
已发布/     (status: 已发布)   ← 脚本归档到这

这就是一个状态机：文章的「状态」由它所在的位置和 status 字段唯一确定，状态之间的迁移（待审核→待发布→已发布）由明确的动作触发。

发布脚本 publish.py 干的事，本质是读状态、按状态行动：

• 扫 待发布/ 目录（只发这个状态的）
• 发布成功的，status 改成已发布、文件移到 已发布/
• 已发布的，下次自动跳过，绝不重发

流程的「流转」不靠一个中心脚本编排，而是靠「每个动作改变状态、下一个动作读状态」串起来的。

三、那为啥不用 workflow？四个真实原因

这是核心。workflow 和「skill+状态机」都能跑这个流程，我选后者，是这四条权衡出来的：

原因 1：流程里有两个「人工卡点」，workflow 的「自动流转」用不上

workflow 最大的价值是「多 agent 自动接力、一气呵成」。但我的流程恰恰不能一气呵成——写完要人工确认内容、配完图要人工确认图片，这两个卡点是必须停下来等我点头的。

一个要在中间反复「停下来等人」的流程，用 workflow 的「自动流转」反而是错配：它的强项（自动接力）我用不上，我的刚需（人工介入）它还得专门绕道支持。

而「状态机 + 手动触发下一步」天然适配人工卡点：我确认完了，说一句「配图」，才把状态往前推一格。人在流程里，而不是流程跑完人才看结果。

原因 2：流程不是「一次性跑完」，而是「跨好几天、跨多个会话」

workflow 默认是「一次触发，从头跑到尾」。但我写一篇文章是跨好几天、跨好几个会话的：今天写初稿，明天确认，后天配图，大后天发布。

这种长周期、强断续的流程，用「文件状态」记录进度，比用「一个常驻的 workflow 脚本」靠谱得多——文件躺在硬盘上，关电脑、换会话都不丢，下次进来一看 status 就知道上次进行到哪。 这就是状态机的「持久化」天然优势。

原因 3：每个环节差异大、要独立演进，skill 更灵活

审核、配图、发布这三件事，内部逻辑完全不同，且各自在快速演进：配图 skill 我这两天还在调风格，发布 skill 前几天刚修过平台接口的坑。

如果用 workflow 把它们编排进一个脚本，改其中一环就要动整个编排。而拆成独立 skill 后，改配图只动 article-illustrations，改发布只动 publish-workflow，彼此不干扰，各自演进。这符合「高内聚低耦合」。

原因 4：workflow 的「并行/多 agent」能力，我这个流程用不上

workflow 的另一个杀手锏是「并行扇出 + 多 agent 验证」。但我这个发布流程是强串行的：必须先写完才能配图，必须配完才能发布，没有可以并行的环节，也不需要多 agent 交叉验证。

workflow 的两大看家本领（自动接力、并行扇出），我这个流程一个都用不上。 那它的「重」（要写编排脚本、要定义 agent 分工）就纯粹是负担了。

四、一张表看懂我的取舍逻辑

看最后一行——workflow 唯一占上风的是「顺序强制保障」。但我的顺序靠「目录约定 + 状态字段 + skill 里写死步骤」也够用了，用不上 workflow 那种脚本级的强制。

五、什么时候我会回头用 workflow

说清楚，我不是否定 workflow。如果我的流程变成这样，我会立刻换 workflow：

• 要一次性批量处理：比如「把这 30 篇存量文章全部重新配图发布」——一次性、高并发、无人工卡点，workflow 的并行扇出就香了
• 要多 agent 交叉验证：比如「每篇文章发布后自动检查三平台是否都成功、失败自动重试」——需要编排和验证
• 流程定型且高频自动跑：不再需要人工卡点，每天定时无人值守地跑

workflow 适合「无人值守的批量自动化」，skill+状态机适合「有人在环节里的半自动流程」。 我的内容发布是后者——我要亲自审稿、亲自看图，人在闭环里，所以选后者。

六、写在最后

回到标题的问题：为什么没用 workflow？

因为我诚实对照了自己的流程：它有人工卡点、跨多天、强串行、各环节独立演进——这四个特征，每一个都指向「skill+状态机」，而不是 workflow。

选型的关键从来不是「哪个更高级」，而是「哪个的特征匹配你流程的特征」。workflow 很强，但强在「无人值守的自动流转」；我的流程偏偏「人在环节里」，那状态机就是更合身的那件工具。

这三篇都在讲「怎么组织 AI 干活」——skill 管单点、workflow 管流转、状态机管进度。但这些都建立在「AI 是个能自己干活的 agent」之上。那 agent 到底是什么？它是怎么从「你的一句话」变成「一连串动作」的？ 下一篇《什么是 Agent：输入、意图、规划、执行、反馈、推理》拆开讲。

你手头有没有「看着该用 workflow、其实 skill+状态机更合身」的流程？评论聊聊你的取舍；觉得这个系列讲透了就关注看下一篇；有用就收藏备用。