建Skill先定框架，结果业务根本不配合：两种“主管”模式选错了，活该白忙活

先讲个真事。

我们团队之前做“做课讲师”Skill，一开始的方案是这样的：

· 用户说“帮我做一节关于XX的课”
· 然后一路走到底：诊断→选题→大纲→PPT→讲稿→品控
· 全流程线性执行，顺序锁定

结果上线后发现一个问题：很多用户只需要其中一段。

有人只想生成大纲，不想做PPT；有人只要讲稿，不需要大纲。但我们那个Skill一触发就必须从头走到尾，用户想跳跳不过去，想单独用某个功能也用不了。

用户反馈：“我就想写个讲稿，你非得让我先走大纲、再走PPT，太麻烦了吧？”

我们赶紧改成另一种模式：用户说什么就进什么入口。“帮我生成大纲”走大纲管线，“帮我写讲稿”走进讲稿管线。各自独立，互不干扰。

不是说线性模式不好，是业务形态根本不长那样。你硬套上去，用户用起来像穿了一双不合脚的鞋。

两种主管模式，本质上就是两种“把不确定性关进笼子”的方式

编排主管：锁定流程顺序

· 先做什么、后做什么，按步骤锁死
· 控制点放在“顺序”上——必须走完第一步才能走第二步
· 适合流水线式业务，步骤固定、不可跳跃
· 代价是不灵活：用户想跳步或只用其中一段就会很麻烦

调度主管：锁定入口路由

· 用户说什么，就进哪条线
· 控制点放在“意图”上——判断用户要什么，分发到对应管线
· 适合多窗口服务台式业务，入口分散、各办各事
· 代价是入口多：每个入口都要写清楚识别规则

业务形态决定架构形态

康威定律说：系统架构是组织沟通结构的镜像。套到Skill上也一样：

· 业务是一条龙流水线——原料进来，一步一步加工，成品出去。顺序固定，不可跳跃。这种业务就该用编排主管，流程锁死，步步把关。
· 业务是多窗口服务台——有人来办A事，有人来办B事，各办各的，互不影响。这种业务就该用调度主管，分发路由，各自独立。

先看业务长什么样，再决定架构长什么样。反过来，先定架构再套业务，一定别扭。

没有“既简单又灵活”的免费午餐

一个业务流程的总复杂度是固定的，你只能选择把它藏在哪里：

· 藏在顺序里（编排）→代价是不灵活，用户想跳步就麻烦
· 藏在路由里（调度）→代价是入口多，每个入口都要写清规则

选编排，是拿“灵活”换“可控”；选调度，是拿“可控的简单”换“灵活”。

混合态才是常态

现实中几乎没有纯粹的编排或调度：

· 编排主管内部也可以有分支——比如“只做大纲”和“完整做课”是两条不同路径，走到分支点各自拐弯
· 调度主管内部每条管线也可以严格按步骤执行——比如“生成大纲”这条线内部是1→2→3不可跳跃

别纠结“我到底是哪种”。问两个问题就够了：

· 对外，用户从哪进？（决定调度）
· 对内，每件事怎么做？（决定编排）

答案往往是：外调度+内编排。

最后说句大实话

建Skill之前，先想清楚你要解决的是什么形态的业务。

· 用户进来说一句话，你带他走一条固定长路——用编排
· 用户进来说不同的话，你带他走不同的短线——用调度

选错了，用户别扭，你也别扭。用户觉得“怎么这么麻烦”，你觉得“怎么业务这么不配合”。谁的问题？一开始架构就没选对。

你现在在做Skill，是编排还是调度？评论区说说你的业务形态，我帮你判断skill开发 Skill教程 PPT定制化 Skill优化 HR实战指南 业务目标拆解 hr流程图 skill开发 Skill教程 PPT定制化 Skill优化 HR实战指南 业务目标拆解 hr流程图