一

上一章的结尾，我说了一句话：我们编好了全企业的词典。现在，该让那些规章制度，也真正"活"起来了。

这一章，就讲那个让规章制度"活"起来的东西——Skill。

在展开之前，我想先让你看一个东西。它不是什么深奥的架构，也不是一段复杂的代码。它只是一段话。一段用中文写的、讲清楚"一件事该怎么做"的话。

【示例：差旅报销审批Skill（简化版）】

触发条件：员工提交差旅报销单

审批规则：

1. 报销金额 < 500元，且发票齐全 → 系统自动通过，无需人工审批
2. 报销金额 500~5000元 → 转部门主管审批
3. 报销金额 > 5000元 → 转部门主管 + 财务经理联合审批

检查点：

• 发票张数与申报明细必须一致
• 出差日期必须在报销单的出差日期范围内
• 超出标准的住宿费，需要附带超标说明

输出：审批通过的报销单进入财务付款队列；被驳回的报销单退回申请人并注明原因。

这一段话，就是我要讲的Skill。

它看起来像什么？像一份流程说明，像一张制度摘要，像一个HR发的通知。但请记住此刻你的感受——你觉得它"简单""清楚""一看就懂"。这正是我要的。

因为接下来我要告诉你：这一段看起来平平无奇的中文，机器也能看懂，而且能直接执行。

这不是比喻，不是畅想，是现在就能做到的事。

二

我们先给Skill一个正式的定义。

Skill，是面向AI Agent的、可版本化、可测试、可治理、可执行的业务能力单元。它以自然语言表达业务意图和裁量框架，以工具接口连接数据与系统，以验收标准和执行轨迹支撑审计与复盘。

拆开来看，这个定义里有几个关键词：

• 业务能力单元
  ：它不是一个命令、一句话，而是一个完整的、有边界的业务能力——有输入、有输出、有规则、有角色
• 自然语言表达
  ：它由人用中文（或任何自然语言）写成，不需要学习任何语法
• 可版本化、可测试、可治理
  ：它有版本、能验证、有Owner——它是一份能被企业管理的资产，而不是一段随手写的文字
• AI Agent可执行
  ：AI读到这段文字，就知道要做什么，不需要翻译
• 以验收标准支撑审计
  ：它定义"做到什么程度算合格"，并记录"实际做得怎么样"——这两样，是它和企业审计、复盘接轨的接口

你可能觉得这个定义有点绕。让我换个说法。

Skill，就是把企业里那些"当……时，做……"的规则，从藏在代码里的if/else、从挂在墙上的流程图里解放出来，变成一份人和机器都能看懂的工作合同——它告诉AI三件事：做什么（目标）、在什么边界内做（规则与不确定性边界）、做到什么程度算完成（验收标准）。

如果只允许用一句话记住Skill，那就是：它既不是提示词，也不是流程图，而是一份可执行、可治理、可验收的工作合同。

我为什么说它是"流程数字化的天然载体"？因为上一章我们定义过，业务逻辑数字化的目标是：让业务逻辑变成结构化、可审计、可被AI理解的形态。而Skill恰好满足这三条：

• 结构化
  ：Skill有清晰的边界——它描述一个完整的业务场景，有触发条件、有规则、有检查点、有输出
• 可审计
  ：Skill以文本形式存在，谁写的、什么时候改的、改了什么，都可以追溯（版本管理，后面第13章会讲）
• 可被AI理解
  ：这是最关键的一条——AI可以直接读取并执行Skill，不需要人肉翻译

你可能会问：就这么一段中文，AI真的能执行吗？

真的能。这正是大语言模型带来的变化：机器第一次能理解人类的自然语言。它不是靠"看懂语法"来执行，而是靠"理解语义"来执行——它读懂了"报销金额超过5000要财务经理审批"这句话，它就知道该把这张报销单转给谁。

三

现在，我们要触及这一章最核心的论证了。

我说Skill是"流程数字化的天然载体"，这个"天然"二字，不是修辞，是有具体内容的。它的依据是：Skill的构成要素，和企业流程的经典定义，是一一对应的。

让我们把企业里一个标准流程的定义拆开看。无论什么行业、什么系统，一个完整的业务流程，都有这么几个要素：

注意最后三行——不确定性边界、验收标准、执行轨迹。它们是流程的经典定义里没有明说、但数字化时代必须有言在先的三个要素：流程文档默认"人去判断合不合格"，而Skill必须把"合格"量化成可以验证、可以审计的标准。更精确地说：Skill的定义 ⊇ 企业流程的经典定义——它承载了流程的全部要素，并额外扩展了这三样，使流程从"给人看的文档"升级为"可验收、可审计、可回滚的资产"。

现在，让我们再看一眼第一节那个差旅报销Skill。它里面有：

• 规则
  ："<500元自动通过，500~5000元主管审批，>5000元联合审批"
• 方法/步骤
  ：提交→审批→付款/退回
• 工具
  ：报销系统（隐含在触发条件里）
• 输入
  ：报销单、发票、出差日期
• 输出
  ：审批通过的报销单进入付款队列，或退回并注明原因
• 角色
  ：申请人、部门主管、财务经理
• 检查点
  ：发票一致性、日期范围、超标说明
• 不确定性边界
  ：金额判断属于"严格执行"，AI不得自行放宽；超标住宿费是否合理，属于"裁量执行"，AI可结合出差城市标准判断
• 验收标准
  ：发票齐全、日期吻合、超标有说明 → 通过；任何一项不符 → 驳回并注明原因
• 执行轨迹
  ：谁提交、谁审批、依据哪条规则、结果如何，每一步留痕

看出来了吗？Skill的每一个要素，都精确对应企业流程的每一个要素。

这不是"类似"，不是"比喻"，是结构上的同构。

我在第四章讲过这个发现。那天晚上我躺在床上，突然意识到：我写给AI的那套"开发规矩"——规则、步骤、工具、输入、输出、交付标准——和企业里定义的"流程"，是同一个东西。

但当时我只看到了"它们是同一个东西"。这一章，我要把这句话论证完整：为什么说Skill是流程数字化的"天然"载体？因为它不是我们发明的新容器，它就是流程本身的数字化形态。 流程长什么样，Skill就长什么样。你不需要改造业务流程去适应Skill——你只需要把流程已有的要素，用自然语言写出来。

这就是"天然"二字的含义：不是我们发明的新容器，是流程本身的数字化形态。

但"同构"还有第二个层面。这个层面，比"要素对应"更接近"天然"二字的本质——因为它回答了一个更深的问题：企业流程，为什么需要模板？

想一想企业里每天都在发生的事：两个人写同一份项目报告，内容绝对不一样；两个会计填同一张报销单，备注栏的写法各不相同。人的执行，天然带着不确定性——同一个人，上午和下午的状态都不一样。

企业流程面对"人的不确定性"，已经几十年了。它从来没有试图消灭这种不确定性——那不可能。它的办法，是四个字：约束结构，容忍内容。

这套机制从第一天起就没指望"两个人写同一份报告会一模一样"，它只保证三件事：该有的内容都有了，关键判断有人把关，改了有记录。这就是企业几十年验证过的治理智慧。

现在，把这个智慧翻译到AI时代，你会发现：Skill不是发明了新治理，而是把这套治理智慧，变成了机器可执行的形式。 模板规定"该有哪些内容"，Skill规定"该有哪些步骤、谁批准、输出什么"；模板容忍"人写什么内容"，Skill容忍"AI在框架内怎么发挥"。Skill继承了"约束结构、容忍内容"，新增的只有一条——机器可执行。

所以，如果有人问："Skill约束了AI，会不会把AI的灵活性消灭了？"答案是：不会。Skill和模板一样，只约束结构，不约束内容。AI在Skill的框架内发挥，和人按模板发挥，是同构的——企业管了人几十年，从来不觉得"模板"是束缚；现在管AI，Skill同样不是束缚，而是让AI的发挥有边界、可追溯、可治理。

但"容忍内容"有一个前提：企业必须能判断，AI在框架内发挥出来的内容，到底合不合格。 这就是流程的经典定义里没有明说、而企业级Skill必须有言在先的东西——验收标准。

企业里的验收，从来分三层：

回到第一节那个差旅报销Skill。如果它是一份"企业资产"，它的完整形态应该长这样——注意多出来的部分，正是它和"提示词"的区别：

【示例：差旅报销审批Skill（企业资产版）】

触发条件：员工提交差旅报销单

审批规则：

1. 报销金额 < 500元，且发票齐全 → 系统自动通过
2. 报销金额 500~5000元 → 转部门主管审批
3. 报销金额 > 5000元 → 转部门主管 + 财务经理联合审批

不确定性边界：

• 金额判断、日期校验、发票核对：严格执行区，AI不得自行放宽
• 超标住宿费是否合理：裁量执行区，AI可结合出差城市标准、会议安排综合判断，但必须给出依据
• 大额、异常报销：人工决策区，必须升级到人

验收标准：

• 自动验收：字段完整、发票张数与明细一致、金额计算正确 → 自动通过
• 模型辅助验收：超标住宿说明是否与出差事由吻合 → AI判断，附依据
• 人工验收：异常报销、大额报销 → 财务经理最终裁决
• 不合格：驳回并注明原因，申请人可修改后重新提交

执行轨迹：提交人、审批链、每条规则命中记录、每次审批人、审批意见、结果流转，全部留痕，可审计、可回放

版本与Owner：版本1.2，Owner：财务部流程负责人；变更需经财务与IT联合评审

看出来了吗？第一节那个"平平无奇的一段话"，只是这份资产的一个"简化视图"。企业真正管理的不是那段话，而是这份完整的工作合同——它告诉AI在什么边界内做、做到什么程度算完成、做完留下什么证据。 提示词不需要这些。企业资产需要。

这份完整形态里出现的"不确定性边界""验收标准""执行轨迹"，就是本章开头那个正式定义里说的"以验收标准和执行轨迹支撑审计与复盘"——它们不是理论装饰，是一个企业级Skill的必填项。

四

不过，如果你以为Skill只是一个"用中文重写的流程文档"，那就把它看小了。

Skill和流程文档之间，有一个决定性的区别。这个区别，我在第四章也提到过，现在值得放大来看：

流程文档是给人看的，Skill是给人看、也给机器执行的。

还记得上一章那条翻译链吗？业务主管的一句话，要经过流程专员、IT产品经理、开发人员三次翻译，才变成机器能执行的代码。每一次翻译都有损耗，最终产出的代码，业务人员看不懂。

Skill跳过了整条翻译链。

我们用中文写下一段规则："报销金额超过5000元，转部门主管和财务经理联合审批。"

这句话，业务人员看得懂——不需要培训，不需要学语法。

这句话，AI也看得懂——它读到"超过5000元"，就知道该比较金额；读到"转部门主管和财务经理"，就知道该路由给谁。理解即执行。

这就是Skill的本质特征，我称之为"所见即所得"：

文档即规则，规则即执行。你看到的，就是机器做的。

传统流程文档，是"告诉你该怎么做"，执行要靠人。系统代码，是"机器直接做"，但你不知道它在做什么。Skill是第一次出现的形态：它同时是"告诉你该怎么做"和"机器直接做"。

这三者的区别，值得用一张表看清楚：

看到最右边那一列了吗？人可读 + 机器可执行 + 改文字即改逻辑，这三个特性，在Skill之前，从来没有同时出现在同一种形态里。

（精确地说：翻译层没有消失，而是被机器内化了——面向业务人员，翻译层不存在了；但企业级可靠执行需要的约束、测试与审计，一样都不能少。翻译从"人的劳动"变成了"系统的机制"，这是第9章和第10章要展开的事。）

五

现在，我们把视角拉高一点。

你可能会说：Skill听上去不错，但它和BPM、规则引擎、低代码这些"老前辈"有什么区别？它们不也是想让业务逻辑变得可配置、可执行吗？

这个问题问得好。上一章我们分析过，这些前辈方案为什么失败了——因为它们都要求人把逻辑"翻译"成机器能懂的严格形式。翻译成本太高。

但那是从"为什么失败"的角度看。这一章，我们从"它和Skill到底差在哪"的角度，把区别摆清楚。

这张表，浓缩了Skill和前辈方案的本质区别。但我想特别强调其中两行。

第一行：描述语言。

BPM用图形，规则引擎用DRL，低代码用拖拽。它们都在试图"降低门槛"，但门槛再低，也是一道需要学习的门槛——你得先学会BPMN的符号、DRL的语法、平台的组件，才能开始描述你的业务。

Skill没有这道门槛。它的描述语言，就是你平时说话用的语言。上一章的翻译链里有三次翻译，Skill把这三次翻译全部消灭了——因为描述和执行用的是同一种语言。（面向工程师的精确说法：翻译在"人这一侧"消失了，但在"系统这一侧"转化成了形式化约束、测试验收与审计轨迹——没有这三者，一段自然语言就只是提示词，不是资产。这一点，上一章结尾我们已经说过了。）

第二行：能否处理模糊判断。

这是Skill和所有前辈方案之间，最深刻的一道分水岭。

BPM、规则引擎、低代码，处理的都是"确定性逻辑"——条件明确、结果明确。但真实的业务世界，充满了模糊判断："这个供应商的信用，综合评估一下""这个异常，看看情况升级处理""这个客户，按惯例给个折扣"。

这些判断，规则引擎表达不了——因为它要求"如果A且B，则C"的精确形式。BPM也表达不了——因为流程图的每个分支，都要求一个明确的判断条件。

但Skill可以。因为Skill背后是理解语义的AI。你写"综合评估一下"，AI知道要收集信息、权衡因素、给出判断；你写"按惯例处理"，AI知道要去查历史惯例、参考先例。

不是Skill本身会判断，而是Skill背后的AI会判断。 但这是后话（第15章讲AI Agent时展开）。这一章，你只需要记住：因为Skill用自然语言，所以它能描述那些"说不清但做得出来"的业务逻辑。这是之前所有方案都做不到的。

六

我们已经知道Skill是什么了。但"知道一个概念"和"能用这个概念解决实际问题"之间，还差一个东西：Skill应该长什么样？

这一节，我想给你看三个完整的Skill。它们不是空想，是我在写这本书的过程中，实际用过、或认真设计过的。

第一个：作者在第四章写的"开发Skill"。

这是全书所有Skill的"原型"。我把它完整地写在这里——因为它是真实的，是我在Vibe Coding中实际使用的：

【示例：开发Skill（作者实际使用）】

触发条件：收到一个开发任务

规则：

1. 不要直接写代码。先建一个子任务，写需求说明，列出验收条件——什么情况下算"做完了"
2. 再建一个子任务，写设计文档：数据结构、API设计、技术栈。写完先给我看，确认后才能动手。开发中设计要改，先跟我说，改完设计文档再改代码
3. 按设计写代码
4. 按验收条件自己验证，不通过的自己修，修完再验
5. 验证通过后部署到本地，启动服务，跑起来。交付的不是代码文件，而是我能直接打开、直接用的环境

检查点：设计文档需作者确认后才能开发；验收条件全部通过才算完成

输出：一个可运行、可验证的功能环境

你看，这个Skill有规则、有步骤、有检查点、有输出。它和企业里任何一份"开发流程规范"长得一模一样。但它不是一份给人看的规范——它是一份AI直接执行的指令。AI读到"写需求说明，列出验收条件"，它就真的去写；读到"写完先给我看，确认后才能动手"，它就真的停下来等我确认。

这就是"文档即规则，规则即执行"最直接的一次演示。

第二个：一个跨系统的业务Skill——"合同续签提醒Skill"。

这是我在CRM领域最熟悉的场景。一个真实的企业业务逻辑：

【示例：合同续签提醒Skill】

触发条件：客户服务合同到期前30天

规则：

1. 系统自动生成续签提醒，推送给负责该客户的客户经理
2. 客户经理需在收到提醒后7天内，在系统中更新续签跟进状态
3. 若7天内未更新，提醒升级到客户经理的直接主管
4. 若客户合同已到期且未续签，服务状态自动标记为"待续签"，并通知财务部门评估欠费风险

方法/工具：调用CRM系统的合同对象API（查到期日）、消息服务（发提醒）、组织架构API（查主管）

检查点：续签跟进状态必须在规定时间内更新；升级通知必须发送成功

输出：续签提醒记录、跟进状态、升级通知日志

你注意看"方法/工具"那一行——这里调用了CRM的合同API、消息服务、组织架构API。这意味着Skill不是"凭空执行"的，它需要调用系统的能力。Skill负责"判断该做什么"，工具负责"实际去做"。 这个分工，第11章讲架构时会完整展开。现在你只需要知道：Skill里可以声明"用什么工具做什么"。

第三个：一个需要裁量的Skill——"客户授信评估Skill"。

这个Skill，体现的是Skill和前辈方案最大的不同——处理模糊判断。

【示例：客户授信评估Skill】

触发条件：客户申请授信额度，或已有授信需要年度复审

评估框架：

1. 硬性门槛
   （任一不满足，直接拒绝）：
• 客户无重大法律纠纷记录
• 客户无严重逾期历史（过去12个月逾期超过60天≥2次）
• 客户工商状态正常（非注销、非吊销）
2. 综合评估因素
   （AI在框架内综合判断）：
• 历史合作记录：过去两年订单金额、回款及时率
• 行业与市场：客户所在行业景气度、市场地位
• 财务健康度：公开财报或授信材料中的负债率、现金流
• 合作深度：客户是否为我方战略客户、合作年限
3. 授信建议
   ：
• 综合评估结果良好 → 建议维持或提升授信
• 综合评估结果一般 → 建议维持原额度，加强回款监控
• 综合评估结果不佳 → 建议降低授信或改为预付款模式

检查点：

• 硬性门槛的判定必须严格执行，AI不得自行放宽
• 综合评估结论需输出评估依据（参考了哪些因素、如何权衡）
• 最终授信决定必须由授信委员会审批，AI只提供评估建议

输出：授信评估报告（含硬性门槛检查结果、综合评估依据、授信建议）

你看这个Skill，它和前面两个完全不一样——它没有"如果A则B"的机械规则，它有一个评估框架，让AI在框架内综合判断。

这背后是本书的一个核心原则（第9、10章会详细展开）：裁量边界由Skill定义，不由AI自行决定。 Skill告诉AI：什么必须严格执行（硬性门槛）、什么可以自主判断（综合评估）、什么必须交给人类（最终决定）。

这才是"AI承担判断"的正确姿势——不是让AI自由发挥，而是给它画好跑道。

七

看完三个例子，你可能已经感觉到了：Skill不是一种单一的东西，它有"深浅"。

有的Skill很简单，像一条规则："金额超过5000元要财务审批。"有的Skill很复杂，像一个决策系统："综合评估客户的信用风险。"

我把Skill按照"复杂度"和"确定性"，分为四个层次：

规则层最像传统规则引擎——"超过5000要审批"，条件明确，结果确定。这一层，传统技术早就解决了。

流程层是BPM的地盘——步骤编排、分支判断。BPM失败在"形式化成本"，而Skill用自然语言描述了同样的编排，却不需要画图建模。

决策层是Skill真正超越前辈的地方——多因素综合判断，带着模糊性。就像那个授信评估Skill，"综合评估客户的信用"，BPM和规则引擎都表达不了，但Skill可以。

目标层是最高级也最前沿的——不给步骤，只给目标，让AI自己规划路径。"优化本月库存周转率"，AI会自己去分析库存结构、识别滞销品、提出促销方案、跟踪执行效果。这一层已经不是"执行规则"，而是"承担目标"。

这四个层次，恰好对应了一个企业里真实存在的四类业务逻辑：制度里的硬规则、流程里的步骤、专家脑中的判断、管理层心中的目标。 Skill的目标，就是把这四类逻辑，全部变成可执行、可编排、可治理的数字化形态。

但层次，只是Skill的一个维度。还有一个维度，同样重要：Skill不是单点规则，而是可组合的体系。

在企业里，一个业务问题往往不是单个Skill能回答的。客户投诉"订单交付延迟"——是销售承诺了做不到的交期？是生产排产落后？还是供应链缺料？要回答这个问题，需要先把问题分类，再组合调用销售、生产、供应链相关的多个Skill联合诊断。

这就产生了一种新的Skill形态——路由类Skill。它自己不处理业务，它只做三件事：分类问题、决定组合、按需加载。

这不是纸上谈兵。已经有工程师把自己的行业经验组织成了几十个Skill，入口就是一个总控路由Skill——先判断"这是什么问题"，再按需加载对应的领域Skill。它证明了一件事：Skill的可组合性，不是理论推演，是已经有人在用的工程形态。

路由与组合的意义，在于它让Skill从"单点规则"变成了"体系"——就像企业不会为每个问题单独设一个部门，而是有流程把各部门串起来。Skill中台的"编排能力"，第11章会完整展开。这一章你只需要记住：Skill不仅分深浅，还分单点和体系；真正的企业级Skill，是组合着用的。

八

这一章，我们从"一段平平无奇的中文"开始，讲了Skill的定义、它与企业流程两个层面的同构、它和前辈方案的区别、它的层次与组合形态。

让我用三句话收束这一章：

第一，Skill是流程的数字化形态，不是新发明。 它的要素和企业流程的经典定义一一对应——这不是类比，是同构。你不需要改造业务流程，只需要把流程已有的要素用自然语言写出来。

第二，Skill消灭了翻译链。 它是人类历史上第一次出现的、同时"人可读"和"机器可执行"的业务逻辑形态。所见即所得：文档即规则，规则即执行。

第三，Skill能承载从硬规则到软目标的所有逻辑。 从"超5000要审批"到"优化库存周转率"，从确定性到模糊性，Skill都能表达——因为它背后是理解语义的AI。

第四，Skill是可组合的体系，不是孤立的规则。 它分深浅（规则、流程、决策、目标），也分单点和组合——一个路由Skill在前，多个领域Skill在后，像企业的流程一样，把各部门串起来。

不过，在读者你开始兴奋之前，我要先泼一盆冷水：Skill要真正在企业里运转，还需要一套完整的架构来支撑它——谁来管理Skill？Skill之间冲突了怎么办？AI执行Skill出错谁负责？Skill怎么和现有的系统对接？

这些问题，是接下来三章的内容（第10、11、12章讲架构）。但在此之前，还有一个更根本的问题没有回答：

如果Skill承载了所有的业务逻辑，如果AI是执行引擎——那"软件"这个东西本身，应该长什么样？

这个问题，就是下一章的主题。而它的答案，比Skill还要大。

我们编好了词典。Skill让规章制度"活"了起来。但真正让这一切运转起来的，是一种全新的软件形态。