工作流
发布时间 2026.06.17
单点组成的工作流,需要更可视化的进度
当多个 skill 组合成一条大工作流,真正需要管理的不是最终结果,而是每个原子步骤的状态、输入、输出和责任。进度必须可视、可调、可介入,否则组织者只能看见方向,看不见问题发生在哪里。
Thesis
由单点 skill 组成的工作流,不能只展示最终结果。它需要把每个原子步骤的状态、输入输出、分叉和责任都变得可视、可调、可介入,否则团队只能看见一个大方向,却无法真正解决过程里的问题。
最近看很多 AI 工作流时,我有一个越来越强的感觉:流程变长了,但进度反而变不清楚了。
表面上看,一个任务被拆成了很多 skill。每个 skill 都能做一段事,组合起来像是一条完整链路。但真正跑起来时,人能看见的往往只是开头的指令和最后的结果。
中间发生了什么、哪一步改变了判断、哪里等待了输入、哪个分支被跳过,常常都沉到系统底层里了。
Argument
从第一性原理看,工作流不是一串动作,而是一串状态变化。
一个任务从未开始到完成,中间会经历理解、拆分、调用、生成、校验、返工、确认、发布等很多状态。每个状态都不是装饰,它都决定下一步能不能继续、该由谁接手、风险是不是已经出现。
过去人在做流程时,这些状态很多是被人脑临时维护的。项目经理知道谁卡住了,设计知道哪一版没有过,开发知道哪个实现是临时方案。信息不一定完全写下来,但至少有人在场。
AI 工作流的问题是,执行速度变快以后,这些中间状态更容易被折叠。系统把许多动作包进一次调用里,skill 之间互相接力,最后给你一个看似完整的产物。
这很方便,也很危险。
方便在于,人不用盯着每个小步骤。危险在于,一旦结果不对,人不知道应该回到哪里。是目标理解错了,是上下文丢了,是某个 skill 的边界不清楚,还是中途某次判断已经把方向带偏了。
团队场景里,这个问题会更重。个人使用 AI 时,自己还能凭感觉追溯刚才发生了什么。团队组织者面对的是多个人、多套材料、多轮审核和多个 agent。只看最终结果,等于只看见了河流入海,却看不见支流在哪里改了方向。
所以大方向本身是不够的。方向只能告诉人要去哪里,不能告诉人为什么没到、哪里走错、下一步该改哪个变量。
真正需要被产品化的,是原子步骤的可见性。
所谓原子化,不是把流程拆得越碎越好,而是把每个影响结果的关键动作变成一个可观察对象。它至少应该有输入、输出、状态、耗时、依赖、责任方和可介入点。
输入告诉我们这一步吃了什么上下文。输出告诉我们它交出了什么。状态告诉我们它是在执行、等待、失败、跳过,还是需要人工确认。责任方告诉我们这一步该由谁拍板。可介入点则告诉我们,人可以在哪里暂停、改参、重跑、替换 skill,或者把任务交回人工。
如果没有这几层,工作流就会变成一个大黑箱。黑箱可以提高单次执行效率,但不能提高组织协作能力。因为组织需要的不只是完成,还需要诊断、调度、复盘和责任回流。
这也是为什么可视化不应该只是一个进度条。进度条只能告诉你走到百分之几,却不能告诉你哪一步的质量是否可靠。团队真正需要的是一张可操作的流程面板:能看见每个节点的状态,也能对节点做出调整。
更进一步,进度不只是给人看的。它也是 agent 之间协作的接口。一个 agent 如果知道上游节点为什么失败、哪些假设被确认、哪些输出还没有审核,它就能更稳地接下一步,而不是重新猜一次。
所以单点 skill 组合成大工作流之后,产品重点会从“能不能调用更多 skill”,转向“能不能管理 skill 之间的状态关系”。
这时,工作流的核心能力就不是自动化本身,而是让自动化保持可理解、可调整和可托付。
Implications
- ·AI 工作流产品不能只沉淀 skill 列表,还要沉淀每个 skill 在流程中的位置、输入输出、状态和责任边界。
- ·团队组织者最需要的不是更大的总览,而是能从总览下钻到原子节点,知道问题发生在哪里,应该改哪个变量。
- ·可视化进度应该支持人工介入:暂停、重跑、改参、替换、确认、回滚,而不是只展示一个不可操作的执行动画。
- ·真正可托付的工作流,必须把过程也变成资产。只有过程可见,复盘和优化才不是靠记忆。
Closing
单点 skill 让任务开始变快,但只有原子化的可视、可调和可介入,才会让工作流真正进入团队协作。