人在工作中长能力，架构让能力可复用，治理让能力可信。

一个采购人员，要做一份供应商报价分析报告。

十几家供应商，报价表各不相同。有人报含税价，有人报未税价；有人包含运输，有人另算；付款条件、交货周期、质量等级，也不在一个口径上。

他把资料交给 AI，开始分析。

第一版不对，价格口径没统一。

第二版还是不对，账期长短不能直接当成价格优惠。

第三版发现，某家供应商看起来最便宜，却没有满足交期要求。

于是，他不断补充规则、纠正判断、调整呈现方式。来来回回十几轮，三个多小时，终于得到一份满意的报告。

到这里，故事很普通：一个人用 AI，提高了工作效率。

但真正值得关注的，是报告完成之后的一句话：

“你回顾一下我们刚才的过程，把有效的方法、判断规则、容易出错的地方整理出来。下次遇到类似任务，我们能不能直接调用？”

报告交了，这次工作结束了。方法留下来，另一件事才刚刚开始。

它可能先是一项个人技能，随后成为团队共享的能力，最终长成一个工具、一段工作流，甚至一套软件。

但这中间，需要跨过哪些门槛？个人经验如何成为组织能力？架构又该承接什么？

本文以这个采购场景贯穿讨论。其中，后续的验证、共享与系统集成，是用于说明落地方法的案例推演，不代表已经取得的实施成果。

一、软件研发，正在多出一个入口

过去，企业建设软件，通常从需求开始。

业务提需求，研发做分析，经过设计、评审、编码、测试，再上线交付。

后来，AI 进入这条链路：辅助整理需求、生成原型、编写代码、检查问题。人的工作方式变了，交付速度也变了。

现在，另一条路径开始出现：

员工先用 AI 完成真实工作，在探索和纠偏中形成方法，再把方法沉淀下来，反过来推动工具和软件的形成。

我们可以把它理解为三种范式：

这三种范式可以叠加。

一个复杂的 ERP 项目，也可以从员工工作中发现有效方法，用 AI 加速实现，再通过工程纪律保障交付。

真实工作提供需求与方法，人机协作加速实现，工程纪律保障可靠运行。

所谓第三种范式，打开的是一条新的能力生产通道。

过去，很多经验停留在人的脑子里，很多“小需求”排不进研发计划。现在，它们有机会先以轻量的方式形成可复用能力，再根据实际价值决定是否继续建设。

软件不再完全从立项开始，也可以从工作里长出来。

二、报告之外，更值得留下的是判断过程

回到采购案例。

那三个小时里，有价值的内容，并不只有最终报告。

采购人员为什么要求统一税费口径？为什么把交期作为准入条件，而不是评分项？为什么某个异常价格要单独核实？为什么数据不完整时不能直接给出排名？

这些判断，是专业经验的具体体现。

我们把从工作过程里提炼有效方法、规则和边界的动作，称为能力蒸馏。

这里借用的是“蒸馏”的意象，不一定涉及模型训练。它的落地形式，可以是一份结构化 Skill，配上模板、脚本、工具接口和评测样例。

但必须强调：

聊天记录里提炼出来的，首先是候选方法。经过验证，才有资格逐步成为组织能力。

一次成功，可能依赖当时恰好完整的数据，也可能依赖老员工没有说出口的判断，甚至可能包含一个没有被发现的错误。

因此，蒸馏不能只问“最后怎么做成的”，还要问：

• 哪些步骤具有普遍性？

• 哪些判断只适用于这次任务？

• 哪些失败路径需要转化为检查规则？

• 哪些地方仍然依赖人的专业判断？

例如，前几轮错误虽然不应原样保留，却可以留下有价值的规则：

税费口径不明确，不进入价格排名；交期不满足要求，单独标记；账期影响如需折算，必须采用业务确认的计算方法。

失败过程经过分析，同样能成为资产。

三、一个采购 Skill，究竟应该长什么样

如果只是把那次对话总结成一段提示词，换一批数据，很可能又要从头纠正。

一个可复用的采购分析 Skill，至少要把六件事说清楚。

注意，这里的重点已经超过“怎么让 AI 写一份好报告”。

它开始回答：什么情况下能做，什么情况下不能做，做错了如何发现，谁来确认。

随后，要让这个候选 Skill 接受三类检验。

第一，换数据。

换一批供应商，加入不同币种、缺失运费、交期模糊等情况，看看它是否还能正确处理。

第二，换使用者。

让没有参加原始对话的同事使用。否则，所谓“复用”，可能仍然依赖原作者在旁边不断补充说明。

第三，专门找麻烦。

放入单位不同、规格不一致、异常低价、失效报价等样例。检查它会不会因为急于完成任务，就给出一份看起来完整、实际上不能用的结论。

验收也不能只凭“感觉不错”。

应该检查：关键计算是否正确，关键规则是否遗漏，异常是否被识别，结论是否有依据，需要人工修改多少，整体耗时是否下降。

看起来像专家，不等于能够稳定承担专业任务。

四、从一个人会用，到一个团队能用

假设这个采购 Skill 通过初步验证，下一步可以在小范围内共享。

这时，新的问题会出现。

另一位采购人员可能负责不同品类。他发现，有些订单交期优先，有些订单质量稳定性优先，原来的规则不能直接套用。

财务同事可能指出，付款条件的比较需要统一计算口径。

业务负责人可能要求，推荐结果必须同时展示备选方案和未解决风险。

这些反馈，才让 Skill 开始从“一个人的习惯”，走向“组织认可的方法”。

但这里有一个容易忽略的原则：

不是每一次修改，都应该覆盖原来的规则。

有些反馈是纠错，应当进入新版本；有些属于品类差异，应该成为不同参数或分支；有些只是个人偏好，不必变成所有人的规定。

因此，团队共享需要明确负责人、版本、适用范围和变更依据。试用版本与正式版本，也应该区分。

另外，还要回答一个组织问题：员工为什么愿意贡献经验？

贡献者应该获得认可，能够参与方法修正，也应该从复用中获得直接收益：减少重复劳动、降低带新人负担、提升专业影响力。

如果员工只是多承担一份“整理经验”的工作，却感受不到收益，沉淀很容易变成形式。

让经验持续沉淀，需要让贡献者和使用者都从中受益。

五、什么时候，这项能力应该长成软件

Skill 被反复使用之后，我们会逐渐发现，任务里的不同部分，适合不同的执行方式。

在采购案例中，价格换算、税费计算、字段校验，规则明确，适合交给脚本或确定性服务。

解释供应商之间的差异、整理风险说明、形成报告初稿，可以继续由 AI 辅助完成。

供应商信息查询、报价读取、审批提交，则需要与业务系统连接。

于是，一条工作流可能形成：

读取报价 → 检查字段 → 统一口径 → 识别异常 → 生成分析 → 人工确认 → 进入审批。

这时，软件的形态已经逐渐清晰。

它可能是一个上传报价文件的页面，可能是 ERP 中的一个按钮，也可能是一条由多个工具和 Skill 共同完成的工作流。

但不是所有 Skill 都值得走到这一步。

如果采购人员每月只遇到一次特殊报价，每次条件又差异很大，现有 Skill 配合人工判断已经足够，就没必要专门开发一个应用。

把输入要求、检查规则和异常处理保留下来，可能更划算。除非它的风险或潜在收益，足以支撑进一步建设。

因此，可以按这样的思路判断：

• 低频、多变、探索性强的任务，保留灵活交互。

• 高频、规则稳定的步骤，考虑工程化。

• 跨系统、跨角色的流程，加强编排与责任控制。

• 即使低频，但错误后果严重的任务，也需要专门设计控制机制。

最终要比较的，是使用频率、规则稳定性、维护成本、错误后果和实际业务收益。

保持为 Skill，也可以是一种成熟的最终选择。

它不必为了证明价值，就一定长成一个独立应用。

六、架构要承接的，是已经开始生长的能力

当这个 Skill 从一个人手里走到一个团队，再走到跨系统协作时，它需要的就不再是个人提示词管理，而是一套承接机制。

同事调用的是不是最新版本？不同采购人员能看哪些供应商数据？报价能否直接从 ERP 读取？分析完成后，谁有权提交审批？出了问题，又能不能查清是哪一步出了错？

这些问题，就是架构要承接的事。

对于企业 AI 平台，可以从五个方面理解。

第一，入口与交互：员工从哪里使用。

员工可能从网页、企业 IM、IDE 或业务系统发起任务。入口可以不同，但身份、权限和底层能力需要保持一致。

界面也不会全部消失。

采购横向比较需要清晰的表格，审批需要稳定的确认页面，持续监控需要仪表盘。对话和动态界面，则可以承接临时解释与个性化需求。

第二，能力资产：大家调用的究竟是什么。

平台要知道有哪些 Skill，分别适合什么任务，谁负责维护，哪个版本可用，哪些已经失效。

工具提供具体操作，Skill 组织任务方法、规则和工具使用。二者都需要权限、版本和运行管理。

采购人员不应该每次都去群里问：“那个最新版的分析方法，谁再发我一下？”

第三，业务语义：大家说的是不是同一件事。

“价格最低”究竟指什么？是否含税、含运费？是否满足规格和交期？

这在同一企业内部，也可能存在不同理解。

起步阶段，可以先用术语表、数据字典和规则清单统一表达。随着跨系统协作变复杂，再逐步建设更完整的业务对象与本体模型，把对象、关系、规则和可执行动作明确下来。

本体不必在起步时一次建完，但业务语义必须有人持续澄清。

第四，系统连接：分析结果如何进入业务。

ERP、MES、CRM 继续承担交易、业务规则和记录责任。AI 通过受控 API、MCP 等接口调用能力。

例如，读取报价和提交采购申请，是两种不同权限的动作，不能因为“接口已经接通”，就默认都能执行。

哪些数据能读，哪些动作能写，写入失败怎么办，重复执行如何防止，都要明确。

第五，运行治理：出了问题如何发现与处理。

谁调用了什么能力，用了哪些数据，花了多少成本，在哪一步失败，是否需要人工接管，都应该能够检查。

可靠编排，依赖模型能力，也依赖数据质量、业务语义、工具契约和执行控制。任何一环缺失，都可能让整条链路出问题。

架构的价值，就体现在这里：

让个人能够完成的事，逐渐变成组织可以可靠复用的事。

七、从第一个 Skill 开始，就要有底线

治理可以逐步增强，但底线不能等到规模扩大后再补。

第一个正式共享的 Skill，就应该有负责人、权限边界、基本评测、版本记录和失败退出方式。

具体来说，至少要守住四条边界。

一是数据使用有范围。

哪些工作记录可以采集，哪些经验可以提炼，共享给谁，保存多久，都应明确。涉及敏感信息时，要做相应处理，不能把所有工作对话无差别纳入。

二是业务动作有授权。

涉及采购承诺、付款、订单变更等动作，要按风险设置人工确认与授权控制。

AI 可以提供分析，但不能因为生成了一份漂亮报告，就自动获得交易权限。

三是能力变化有验证。

修改提示词、更换模型、调整脚本、更新工具接口，都可能改变结果。

不能只验证“新版本能运行”，还要检查原来能正确处理的情况，有没有被改坏。

四是失败处理有办法。

这里尤其要分清两种“回退”。

提示词、脚本、规则和模型配置，可以恢复到此前经过验证的版本；但已经发出的订单、已经发送的通知、已经发生的付款，未必能靠软件回滚撤销。

这类动作需要事前审批、重复执行防护，以及事后的取消或补偿流程。

随着使用规模扩大，再增强自动化评测、成本归因、资产去重、依赖分析和退役管理。

执行可信，靠的是可以检查的工程机制和明确的责任安排。

八、CIO 如何启动：先证明一条链路

对于团队规模有限的传统企业，不必一开始就建设一个包罗万象的平台。

可以先选一个边界清楚、重复发生、有专业人员愿意参与、结果能够判断的场景。

采购报价分析就是一种候选，但最初可以只做辅助分析，保留原有审批与业务责任。

随后，把一条完整链路跑通：

完成真实任务 → 提炼候选 Skill → 验证 → 小范围复用 → 收集问题 → 迭代 → 决定是否系统化。

先回答几个朴素的问题：

换一个同事，能不能用？

换一批数据，会不会错？

错了，能不能发现？

遇到不确定情况，会不会主动停下来？

节省下来的时间，是否超过整理、审核和维护的成本？

这些问题有了答案，再逐步增加系统连接、资产管理与自动化治理。

不必把全员培训当成唯一开场。可以围绕一个已经跑通的场景，让员工理解什么值得沉淀、怎样反馈、哪些边界必须遵守。

一个真实案例，既能成为工具，也能成为培训材料，还能帮助团队发现下一批值得建设的能力。

先把一项能力做扎实，再让它带动下一项能力。

九、今天完成的工作，也应该为明天留下能力

过去，我们常用上线系统、交付项目和覆盖功能，衡量数字化建设。

这些指标仍然有用，但还需要增加另一组问题：

员工的经验，有多少能够被别人复用？

复用之后，质量是否稳定，错误是否减少？

新人是否更容易完成任务？

组织是否减少了对少数人的过度依赖？

这些能力最终有没有改善效率、质量、交付和经营结果？

Skill 数量本身不能说明成功。

一个有几百个条目、没人维护的能力库，可能只是另一种文档堆积。少量持续被使用、经过验证、有人负责的能力，往往更有价值。

同时，不能只看单个任务省了多少时间。原作者的整理、同事的验证、平台的运行与长期维护，都要计算在内。

能力是否成为资产，要看它能否持续创造超过维护成本的价值。

回到最开始的采购人员。

三个小时之后，他完成了一份报告，这是一次工作成果。

他把有效方法提炼出来，这是一个候选能力。

同事能够复用，异常能够识别，规则能够修正，结果能够验证，它才逐步成为组织能力。

当其中稳定的部分进入工具、工作流和业务系统，软件便从真实工作中长了出来。

下一次类似任务到来时，我们希望看到这样的画面：

这位采购人员不必再从头解释规则，而是检查分析结果，处理异常，把更多精力放在供应商谈判和关键取舍上。

另一位同事接手新的品类，也能沿用经过验证的方法，补充新的规则，再把修正反馈回来。

一份报告结束了，一套方法留下了；一个人摸索过的路，下一个人不必再从头走。

这就是“工作长出软件”真正值得期待的地方：

今天完成的工作，也在为明天留下能力。