麦睿菱AI实践 05｜Skill复用，还有一笔维护账

把客户定制整理成供 AI 调用的方法包（Skill），再提供给更多人使用，企业也就接下了后续支持工作。少写一次代码，可能换来更多适配、辨认、验证和求助。是否值得通用化，要看下一次工作的总负担能否下降；已投入的成本可以留下经验，却不能代替对未来需求的判断。

设想一个客户定制项目，经过几轮补数据、改程序和专家确认，终于可以交付。复盘时，有人提议：“这次花了这么多力气，整理成通用功能吧，下次谁都能用。”

通用功能发布后，支持工作可能反而增加：同事找不到正确入口，参数选完还要问原作者，客户换了一种条件，公共方法又多出一个分支。功能发布了，支持它的人反而更难脱身。

定制成果可以有三种去向

以测量项目为例，一次定制可能留下三项成果：读取旧系统特殊编码的转换程序，一组客户认可的评价参数，以及一套检查并比较数据的方法。图1列出三种合理去向，选择哪一种，要看下一次使用需要承担什么。

图1｜项目专用、有限配置与共同方法，三种去向没有高低之分

第一项只服务于即将停用的旧系统。把原始输入、转换依据、验证样本和版本保存好，安排项目支持，已经有价值。若为了让所有人使用，再承担多年兼容义务，新增投入可能没有足够需求支撑。

第二项可以成为有限配置，但前提是差异已经理解清楚。同一种定义下，评价区段或阈值不同，可以开放选择；单位、允许范围、不能同时选择的组合，需要一并交代。否则只是把开发时的判断转移给使用者。

第三项最有机会成为共同方法，但“大家都要比较数据”还不够。需要先找出稳定的部分：输入应具备什么条件，执行哪些检查，采用什么计算口径，输出究竟说明什么。客户各自的验收约定可以留在外层，避免一次客户变更牵动所有使用者。

一个容易误判的反例是：两个客户都要求“波动不能超过某个数”。数字形式相似，定义却可能不同。强行放进同一个阈值框，会让界面更统一、结果更难解释。保留两种名称清楚、边界明确的方法，反而更容易交接。

通用化会产生一笔持续的支持账

定制项目的责任通常有边界：为谁做，依据什么交付，哪些变化另行处理。方法面向更多人之后，问题也会增加：谁能用，选错了怎么办，修改后哪些历史结果要重查？

使用者越多，这些问题越不能靠口头交代。每新增一种配置，都要考虑说明、验证与后续兼容；每加入一种“特殊情况”，都可能让其他员工更难选对。

评审时，除了估算“下一次少写多少代码”，还要估算寻找方法、核对适用性、调整输入、验证输出和持续支持的负担。卡内基梅隆大学软件工程研究所（CMU/SEI）的产品线经济模型[1]也将共同资产投入与复用相关成本放在一起分析。

已经花出去的钱不应成为继续投入的理由。不过，经过检验的代码、错误样本和计算依据，确实可能降低下一次投入。评审要问的是：利用现有成果，从现在起还需付出什么，能支持哪些有依据的需求？

一项少见检查若能避免代价很高的错误，也可能值得共同维护。评审时需要说明，这项检查能发现什么错误，持续维护为什么比每次临时求助更合适。

先让另一位同事接得住

按 Agent Skills 开放格式[2]，方法包可以包含任务说明、脚本和参考材料，供智能体按需读取。

方法包应该回答：“什么情况下用”“先查什么”“调用哪个经过验证的程序”“缺什么就停”。它可以引用知识库中的标准和依据，但调用的程序及结果口径，仍要经过专业验证。

比如，一份方法只写“采用客户默认阈值”，原作者知道是哪位客户，后来者和助手未必知道。更可靠的写法是要求读取本项目已经确认的配置，并在来源不明时停下。这个改动多了一步来源检查，可以减少凭默认阈值跨客户误用参数的风险。

请一位具备相应资格、没有参与开发的同事试用，可以看出支持成本会落在哪里。让他独立处理一个相近任务，观察四件事：

• 他能否找到并选对方法，说明它为什么适用

• 他能否区分共同步骤与本项目参数，找到参数来源

• 遇到缺少条件的输入时，他能否停在正确位置并求助

• 结果交给审核人后，能否还原输入、方法和版本

把中间的求助和返工记下来，与原来由专家直接处理的同类任务比较。若每个关键节点仍要原作者出面，就说明方法说明里仍缺少只有原作者知道的选择依据。此时收窄范围，可能比再增加几个选项更有效。

经过验证的方法再交给更多人

员工试出来的做法，先是一份候选经验。要交给更多人使用，还需要专业人员确认适用范围，检查客户材料的使用权限，补齐验证样本，并指定维护责任。

企业可以用枢策 Orchelm[3]这类企业智能体治理与协同平台，组织和发布这些经过确认的方法及所需工具。发布前，团队还需核对执行格式、工具依赖和可用范围。

聊天记录和运行结果可以作为整理材料，不能代替专业人员对适用条件、验证依据和开放范围的确认。

版本记录在这里要服务于责任。客户只改了阈值，应能定位到客户配置和生效范围；共同程序修正了单位处理，则应查出哪些任务和结果可能受影响。把所有改动笼统称为一次“AI 升级”，会丢掉最需要追溯的区别。

用下一次真实使用决定是否扩大

不确定时，可以先提供给条件相近的一小组任务。投入前写清楚要验证的问题：是否有重复需求，后来者能否独立使用，持续支持的负担是否可承受。试用后据此决定扩大、继续完善，或退回项目专用。

也要给这项能力设退出条件。业务变了、依赖系统停用了，或者公共维护已经比单独处理更费力，都可以停止推广，同时保留有用资料和历史依据。

通用化是一笔新的投资，需要有明确的未来用途、能够接手的使用者和持续维护的责任人。保留项目专用、开放有限配置、建设共同方法，都可以是合理决定。把这些条件说清楚，才能判断哪些成果值得扩大使用，哪些保留在项目内更合适。

参考阅读

[1] CMU/SEI：SIMPLE 产品线经济模型

[2] Agent Skills：官方概览

[3] MEASIX：枢策 Orchelm