企业管理软件的AI化重构②:从设计功能,到定义 AI 执行边界
假设你负责采购模块，领导问你：“这个模块功能全不全？”
有没有采购订单管理？有没有供应商管理？有没有采购合同管理？询价比价做没做？审批流能不能配置？报表够不够丰富？
他们关心的是模块是否完整、单据是否可配置、流程是否灵活、报表是否丰富。这些问题本质上都是功能视角：我有什么功能，用户怎么操作，和竞品相比多了什么。
这个问题看起来只是换了一个问法，实际上它把ERP 产品经理拉进了一个完全不同的时代。
未来，产品经理要设计的是“AI怎么理解并执行一个业务意图”。
01从“人怎么操作”，到“AI怎么调度”
如果上一篇文章的判断成立，未来用户接触ERP 的方式不再是“打开系统找菜单”，而是通过AI 完成业务意图，那么ERP 产品经理要回答的问题就会彻底变化。
过去你关心的是：菜单好不好找，字段清不清楚，操作流畅不流畅，报错信息友不友好。这些当然重要，但它们都是围绕人来设计的。人要看界面，人要理解字段，人要点击按钮，人要顺着菜单路径一步一步完成操作。
AI需要理解的是：用户想完成什么任务，这个任务需要调用哪些能力，调用这些能力时需要什么上下文，执行后如何解释结果，异常时如何中断，操作过程如何审计。
所以，未来ERP 产品经理要从“操作路径设计”进入“能力调度设计”。
意图→ Agent → Skill → 权限→ 执行→ 回写
过去你设计采购模块，是把采购业务拆成供应商管理、合同管理、订单管理、收货管理、付款管理，再用菜单、单据、字段和流程组织起来。
未来你设计采购能力，是要判断哪些业务动作可以被AI 调用，哪些只能建议，哪些可以生成，哪些能执行，哪些必须交给人复核。
02模块是给人用的，Skill是给AI调度的
未来，ERP产品的核心资产不只是模块，而是Skill。
模块是一组在UI 上组合起来的功能集合。采购模块里有供应商管理、采购合同、采购订单、到货、结算、付款。这些功能放在一起，是因为它们属于同一个业务领域，方便人进入系统后查找和操作。
Skill是可被AI 调度、可解释、可审计的业务能力单元。
模块是对“人的操作方式”的组织。它把人要做的事按业务领域分组，放在一个界面里。
Skill是对“AI 执行能力”的定义。它告诉AI：这个能力能做什么，需要什么输入，会输出什么结果，什么情况下不能做，执行以后如何审计。
“采购模块”是模块，“供应商准入评估”可以是一个Skill，“采购比价分析”可以是一个Skill，“自动补货建议”也可以是一个Skill。
这些Skill 不一定对应一个菜单，也不一定对应一张单据。它们对应的是一个业务任务。
AI理解这个意图后，调用供应商准入评估Skill。这个Skill 再去获取工商信息、历史交易、合同履约、质量异常、付款风险等数据，按照既定框架输出评估建议。
这时候，产品经理设计的就不是菜单了，而是这个Skill 的边界、输入、输出、权限、异常处理和审计要求。
也就是说，ERP产品经理的工作正在从“功能设计”转向“能力治理”。
03Skill是契约，不是规格书
很多人会把Skill 理解成一段提示词，或者一个更聪明的自动化脚本。
提示词只是告诉AI 怎么说，Skill 是规定AI 在什么业务边界内做事。
比如第一个字段填供应商代码，第二个字段填采购数量，第三个字段系统自动带出单价。每一步都定义清楚，规规矩矩，没有发挥空间。
比如一个“供应商准入评估Skill”，它不应该只是告诉AI“帮我评估供应商”。它至少要定义清楚几件事：
这个Skill 的核心工作是什么？是判断供应商是否值得准入。
它关注哪些维度？资质、信用、履约、价格、合规、行业口碑、合作意愿。
哪些信号是硬风险？比如存在重大法律纠纷、关键资质过期、历史履约严重违约。
什么时候必须交给人判断？比如采购金额超过历史合作规模两倍以上，或者风险信号互相冲突。
输出什么结果？评估结论、风险清单、建议动作、人工复核提示和关键依据。
契约不告诉AI 每一句话怎么写，也不把每一个步骤都写死。它定义的是AI 可以判断到哪里，必须停在哪里，出了问题如何追溯。
如果你把Skill 做成规格书，就会把AI 重新锁回传统系统逻辑里。每一步都写死，每个动作都固定，每个输出都预设，最后AI 只是在模拟一个会说话的RPA。
真正有价值的Skill，不是把每一步都写死，而是定义原则、边界和责任，给AI 留出判断空间，同时不给它越界的机会。
04Skill和规则不是一回事
这里还有一个容易混淆的地方：Skill和规则不是一回事。
“金额超过50 万必须集团审批”，这是规则。它不需要AI 判断，只需要系统稳定执行。
“这个供应商虽然报价低，但履约风险是否可接受”，这是Skill。它没有唯一答案，但需要一套成熟的判断方法。
规则解决确定性执行。比如黑名单供应商禁止下单，没有合同不能付款，库存不足不能发货，超预算必须追加申请。这些事情不能交给AI 自由判断，必须由系统规则稳定执行，因为规则的价值就是确定性。
比如这个供应商值不值得准入，合同风险如何分级，采购价格是否异常，项目蓝图是否合理，客户回款风险是否在上升。
这些事情不是简单的“是”或“否”，它需要经验、上下文、判断框架和解释能力。
所以，Skill的本质，是把组织里最值钱的东西沉淀下来。
那些资深采购、财务、项目经理和管理者脑子里的判断方法，过去往往散落在人身上。老采购知道哪个供应商报价虚高，老财务知道哪个费用科目容易出问题，老项目经理知道哪个需求一听就会返工，老板知道哪个客户虽然规模大但付款风险高。
如果这些经验不能沉淀，它们就只是个人能力。一旦这个人离职、换岗、退休，能力就随人流失。
但如果这些经验被封装成可被AI 调用、可治理、可审计的Skill，它们就变成了组织资产。
不是AI 替人点菜单，而是把企业的经营判断能力沉淀成数字能力。
05产品经理要定义“能做什么”，更要定义“什么时候不能做”
一个好的ERP 产品经理，在定义Skill 的时候，必须同时回答两个问题：
“能做什么”是功能设计，关注输入是什么、流程怎么走、输出格式是什么。
“什么时候不该做”是边界设计，关注什么情况下Skill 应该拒绝执行，什么情况下必须升级给人，什么场景下它不适用。
一个“自动采购下单Skill”能做很多事。它可以按历史采购数据定期补货，根据库存水位自动生成采购单，结合供应商报价选择最优方案。
但如果这个月预算突然被砍了一半，Skill应该自动降低采购量，还是停下来让人确认？
如果库存水位异常升高，可能是库存数据错误，Skill应该继续下单，还是标注异常？
如果某个供应商最近连续出现投诉，Skill是否还可以继续把订单分配给它？
更麻烦的是，AI很可能碰到一些产品经理一开始没有写进流程里的冲突。
比如库存已经低于安全水位，按库存逻辑应该立即补货；但同一时间，财务系统把现金流预警等级调高，供应商又要求预付款。这个时候，如果Skill 只看库存，它会做出一个“业务上正确、经营上危险”的动作。
库存确实低了，补货逻辑也没错，但现金流风险已经变了。
这类问题，不是靠多写几个字段就能解决，而是要在Skill 契约里提前定义：当库存目标、现金流目标、供应商风险发生冲突时，Skill 不能继续自动执行，必须停下来交给人判断。
边界设定得好，Skill是助手；边界设定得模糊，Skill 就会变成一个你以为它可控、实际上可能失控的黑盒子。
这也是为什么“Skill是契约，不是规格书”这个判断很重要。
契约不只定义要做什么，也定义不能做什么；更重要的是，它定义了什么情况下必须停下来，把判断交还给人。
06定义一个Skill契约，要回答5个问题
如果说Skill 是契约，不是规格书，那么产品经理真正要做的，就不是把功能重新包装成一个“AI 能调用的接口”，而是把一个业务能力的边界说清楚。
一个最小可用的Skill 契约，至少要回答5 个问题。
产品经理不能只写“它能调哪个接口”，而要说明它到底解决什么业务问题。
供应商准入评估Skill 的核心不是“查询供应商资料”，而是判断这家供应商是否值得进入企业合作体系。
采购比价Skill 的核心不是“列出三家报价”，而是判断哪一个报价在价格、交期、质量、履约风险之间更合理。
自动补货Skill 的核心不是“低于库存就下单”，而是判断在当前库存、预算、销售预测、供应商状态下，是否应该触发补货建议。
AI不能只靠一句指令做判断。一个Skill 要可靠执行，必须知道它需要哪些context。
供应商准入评估，至少需要工商信息、资质证照、历史交易、履约记录、质量异常、法务风险和内部黑名单。
采购比价，至少需要历史价格、交付周期、付款条件、质量投诉、供应商评级和当前库存状态。
自动补货，至少需要安全库存、销售预测、在途订单、采购周期、预算余额和现金流约束。
产品经理在这里要做的，不是简单写“调用供应商接口”，而是定义这个Skill 做判断时必须依赖哪些业务事实。没有这些上下文，AI 看起来能回答，实际上是在猜。
Skill不能什么都交给人，否则没有效率；也不能什么都自己做，否则风险失控。
产品经理要明确：在哪些条件下，Skill可以自主完成判断。
比如供应商准入评估中，如果供应商资质完整、无重大风险、历史履约良好、采购金额低于一定阈值，Skill可以给出“建议准入”。
采购比价中，如果价格差异不大、供应商评级接近、交付周期稳定，Skill可以给出推荐排序。
自动补货中，如果库存低于安全线、销售预测稳定、预算充足、供应商履约正常，Skill可以生成补货建议。
这里的关键不是让AI 自动做决定，而是定义它在哪些条件下可以形成一个可信建议。
这是Skill 契约里最容易被忽略、也最重要的部分。
一个Skill 的成熟度，不只看它能做什么，还要看它知不知道什么时候不能继续做。
比如自动采购下单Skill，表面上看，只要库存低于安全水位，就可以触发补货。但如果同一时间，财务系统已经把现金流预警等级调高，供应商又要求预付款，Skill 就不能只按库存逻辑继续下单。
库存确实低了，但现金流风险也在上升，是否继续补货？
再比如供应商准入评估，如果系统发现供应商工商信息正常、报价也有优势，但其关联公司存在重大诉讼，Skill就不能直接给出“准入”。它应该标记风险，要求人工复核。
很多AI 项目出问题，不是因为AI 不会做，而是因为产品经理没有定义它什么时候应该停下来。
它调用了哪些数据？参考了哪些案例？使用了哪些判断标准？在哪一步给出了结论？哪些风险被忽略了？人工是否修改过结果？修改理由是什么？
这些都必须留下痕迹。否则，Skill就会变成一个黑盒。看起来很智能，出了问题却没人说得清楚。
真正可治理的Skill，应该让企业可以回到每一次执行现场，看到AI 是如何理解任务、如何调用数据、如何形成判断、如何触发边界、如何交给人确认的。
所以，一个Skill 契约不是一句提示词，也不是一份接口文档。它至少包括五件事：
判断目标、上下文、可自主判断条件、必须中断条件、审计复盘机制。
这五件事写清楚了，AI才不是在系统里“乱跑”，而是在组织允许的边界内工作。
07产品经理的新命题：不是功能更多，而是边界更清楚
有API，只能说明系统可以被连接；能不能被AI 正确调用，取决于能力有没有被重新封装。
我们已经把采购能力拆成几个Skill。供应商准入评估Skill 有评估框架和人工复核边界；采购比价Skill 有对比标准和异常升级条件；自动补货Skill 有触发阈值和中断机制。每个Skill 都定义了输入、输出、权限要求和审计链路。
这意味着AI Agent 可以按业务意图调度它们。
如果需要评估供应商，Agent知道该调用哪个Skill，需要什么上下文，结果应该如何解释。如果评估出异常，Skill 知道是中断、标记，还是交给人复核，不会让AI 在不该判断的地方继续判断。
这段话背后，是ERP 产品经理在AI 时代真正要交付的东西。
过去产品经理的得意之作，可能是一个复杂但强大的配置界面。未来产品经理的得意之作，可能是一份清晰、克制、可执行的Skill 契约。
它让AI 在边界之内自由发挥，在边界之外果断交回给人。
因为最好的AI 产品，不是功能最多的那个，而是知道自己能做什么、更知道自己不能做什么的那个。
未来ERP 产品经理的核心能力，不是把功能设计得有多全，而是把业务判断翻译成AI 能理解的Skill 契约。
夜雨聆风
