ARTICLE · 1324951
专家把经验做成了AI Skill,为什么其他人还是用不了?
一个真实库存核算案例，揭示从专家经验固化到企业级AI应用之间的工程鸿沟。
最近在推进企业AI Skill应用时，遇到了一个很有代表性的案例。
一位库存核算专家，已经利用AI把多年积累的业务经验，整理成了一套相当完整的Skill。
它不仅有SKILL.md，还有业务规则、Python脚本、Excel模板、运行说明和质量检查机制。
从交付成果来看，已经远远超出普通提示词的范畴。
但当我尝试从另一个使用者的角度去理解和复用这套Skill时，却发现一个问题：
专家能够通过AI完成一项复杂工作，不代表把经验固化成Skill之后，其他人就能稳定复现。
这不是简单的提示词问题，也不能简单归结为脚本写得不够好。
它揭示的是从专家经验到自动化工具，再到企业级业务产品之间，一道经常被低估的工程鸿沟。
一、专家已经做到了什么？
这个案例来自半导体企业的月度库存核算。
库存核算听起来只是财务工作，但实际涉及多个系统、多类库存、多种业务规则，以及大量跨月计算。
例如：
不同来源的库存数据需要合并和映射； 原材料、在制品、成品需要采用不同处理逻辑； 库龄、库存分类、特殊物料需要按照规则判断； 呆滞计提、冲回、库损需要进行跨月计算； 某些异常需要依靠业务专家人工确认； 最后还需要生成财务核算结果和经营分析报表。
这些工作过去大量依赖Excel、人工处理和专家经验。
而现在，专家已经尝试把整个过程固化为Skill和脚本。
根据提供的v1.1.2技能包，已经包含流程说明、业务规则、多个Python与PowerShell脚本、人工确认机制、质量校验和跨机部署说明。
主要计算流程划分为五个阶段：
库龄数据处理； 公式计算； 库龄分析表生成； 计提、冲回与库损核算； 计算步骤说明生成。
此外，还包含在线库存补充、异常分析等辅助任务。
这意味着专家已经完成了一个重要转变：
从“我知道怎么做”，变成“我能够让AI和程序按照我的方法做”。
这是业务知识固化的重要成果。
但问题恰恰出现在下一步。
二、我把它的数据流画出来后，发现了什么？
为了理解这套Skill，我首先梳理了它的数据图谱。
这一步非常有必要。
因为一个复杂业务Skill真正的能力边界，并不只存在于SKILL.md里，而是隐藏在所有输入、输出、规则、脚本和文件依赖之间。
从当前数据图谱可以看到：
左侧是主数据和规则，包括物料映射、产品分类、加工费用和BOM等。
上方是当月财务库存、辅助数据、历史结果和人工确认文件。
右侧是在线库存及数仓快照。
中间是多个Python任务，串联完成数据处理、公式计算、分析和计提。
最终生成多个Excel结果文件。
第一眼看，这已经是一套比较完整的自动化流程。
但仔细分析就会发现三个结构性问题。
问题一：输入数据并不全是原始数据
当前输入包里，有些是ERP或数仓导出的原始数据，有些已经经过财务合并，有些来自历史计算，还有些经过人工补充。
例如：
某张财务库龄表已经完成了上游合并。
某个特殊库存金额文件已经由人工补充。
部分跨月计算依赖上月已经处理过的结果。
这意味着当前流程更接近：
半加工数据包 → Skill再次加工 → 财务核算结果
而不是：
原始数据 → 完整业务规则 → 可复现结果
为什么这个区别很重要？
因为如果上游的人工加工过程没有被完整记录，即使拿到了相同的原始系统数据，也不一定能够复现最终结果。
一个专家知道哪些地方需要补充、调整和确认。
但另一个人不一定知道。
当输入数据本身已经包含未记录的业务判断时，自动化只是覆盖了后半段流程。
问题二：数据、规则、计算和展示混在一起
当前Python脚本承担了大量工作。
其中一些脚本同时负责读取Excel、识别字段、匹配规则、执行计算、写入结果以及设置Excel格式。
还有的脚本既负责处理历史数据，也负责生成经营汇总。
更复杂的是，部分计算阶段依赖提前存在的Excel模板和过程文件。
这并不意味着实现方式错误。
对于由专家快速开发的业务自动化工具，这是一种非常自然的实现路径。
但随着流程变长、参与人员增多、跨月运行次数增加，问题会逐渐显现。
例如：
修改Excel模板，可能影响计算程序。
调整业务规则，可能需要同时修改多个脚本。
某个中间文件不存在，可能导致后续阶段无法运行。
Excel公式没有正确刷新，也可能影响计算结果。
功能虽然串起来了，但系统职责还没有真正分开。
问题三：有结果文件，不代表有完整运行状态
复杂的月度核算不会永远一次成功。
可能数据已经处理完成，但等待人工确认。
也可能公式已经计算完毕，但分析阶段出现异常。
如果没有统一的运行状态管理，系统就只能依赖目录和文件判断进度。
问题在于：
文件存在，不代表文件有效。
文件名正确，不代表内容来自本次运行。
同一个月份重新运行，也不代表使用了相同的数据和规则。
因此，真正需要管理的不只是文件，还包括每一次运行的完整过程。
三、为什么有了Skill和脚本，仍然不等于可复现？
经过诊断，我认为这个案例主要暴露了九类工程问题。
它们并不是简单增加几个脚本就能全部解决的。
1. 数据没有真正分层
应当明确区分原始数据、标准数据、人工调整、计算过程和最终交付。
原始快照需要保留，人工调整不能直接覆盖原始数据。
否则结果发生变化时，很难判断究竟是源数据变化，还是人为调整造成的。
2. 规则没有统一注册
业务规则目前分布在Python条件、Excel配置、Skill文档和历史文件中。
例如不同库存类型的计算条件、特殊物料判断和例外规则。
这些规则都可能直接影响金额。
如果没有统一版本管理，就很难回答：
为什么这个月按这个规则计算？
上个月采用的是什么规则？
某条规则从什么时候开始生效？
3. 人工确认没有形成完整审计记录
技能包已经具备人工确认持久化机制，这是值得肯定的。
但如果只保留最终确认值，仍然缺少关键上下文。
完整的人工调整应该记录：
调整对象、原值、新值、调整原因、确认人、确认时间、依据、适用月份，以及是否延续使用。
人工判断可以保留，但人工判断不能成为无法追溯的黑箱。
4. 运行前检查不够完整
在启动计算之前，系统应该能够检查数据是否属于同一月份、关键文件是否齐全、历史结果是否兼容、数据主键是否唯一、必要确认是否完成。
并给出明确的运行状态：
可以开始、存在风险，或者禁止运行。
而不是执行到中间阶段才发现缺少必要文件。
5. 中间状态依赖隐式文件
模板、历史基准、在线数据备份和过程文件，都可能成为后续步骤的前置条件。
但当前还缺少一份完整的、机器可读取的运行清单，统一登记每个数据来源、版本及处理状态。
6. 缺少完整的数据契约
只检查Excel是否包含某个列名还不够。
还需要定义主键、数据类型、唯一性、允许为空规则、单位、日期口径和来源系统。
例如，当一批数据存在多个匹配记录时，如果程序默认取第一条，那么不同导出顺序就可能产生不同结果。
只有明确排序和冲突处理规则，才能真正做到确定性执行。
7. Excel仍然承担过多中间计算职责
Excel很适合作为财务人员的输入和交付工具。
但如果同一个Excel同时承载原始数据、业务规则、计算过程、人工调整和结果展示，就会形成复杂的隐式依赖。
Sheet名称、列位置、公式刷新与外部引用，都可能影响流程稳定性。
更合理的方向是将核心计算迁移到Python和标准数据层。
8. 核算结果与经营分析混在一起
核算结果需要稳定、准确、可审计。
经营分析则需要灵活，可以按照事业部、产品线、时间、异常类型等不同维度展开。
这两者应该使用同一套可信结果数据，但不应让分析展示逻辑反过来影响核算计算。
9. 缺少完整的运行版本标识
每一次月度核算，都应该记录输入数据版本、规则版本、代码版本、人工调整版本、运行批次和输出校验信息。
否则同一个月份运行两次，即使结果不同，也可能无法快速定位原因。
这九个问题可以进一步归纳为五种治理能力：
数据治理、规则治理、运行治理、异常治理和结果治理。
它们共同决定了一套业务Skill是否能够稳定运行。
四、我重新设计了这套Skill的目标架构
发现问题之后，还需要回答一个更重要的问题：
如果重新设计，应该是什么样子？
我认为可以将整个系统划分为五个相互协作的部分。
第一部分：AI负责流程编排和解释
AI不应该直接承担所有核算。
它应该判断当前需要执行什么任务，检查输入是否齐全，组织程序运行，识别异常并向用户解释。
例如：
“本月数据已经齐全，但有三项物料分类需要人工确认。”
或者：
“本月呆滞计提较上月增加，主要变化集中于某类库存，以下是对应明细及规则依据。”
AI应当帮助人理解并推进流程，而不是绕过审批直接修改财务结果。
第二部分：Python负责确定性计算
字段映射、分类判断、库龄计算、跨月匹配、计提冲回、汇总勾稽等工作，应当尽可能由确定性程序完成。
相同数据、相同规则、相同程序版本，应产生相同结果。
这比让大模型每次重新推导计算逻辑更可靠。
第三部分：规则库负责统一业务口径
把原本散落在脚本、Excel和人工经验中的规则，逐步整理成可配置、可版本化的规则库。
规则需要有生效时间、优先级和变更记录。
对于影响财务金额的重要规则，还应当具备明确的审批机制。
第四部分：标准数据层负责保存完整计算依据
原始数据进入系统后，先进行标准化。
人工调整单独保存。
计算过程使用标准数据集，不依赖Excel文件反复传递状态。
根据规模和技术条件，可以采用Parquet、SQLite或DuckDB等方式管理中间数据。
关键不是选择哪一种技术，而是确保每一层的数据职责清楚、能够追溯。
第五部分：交付与经营分析层负责形成业务价值
最终核算数据需要输出为财务人员熟悉的Excel。
同时，可以进一步生成库存趋势、事业部分布、产品线变化、呆滞分析和TOP异常原因。
这样，核算和经营分析既有清晰边界，又能够共享可信的数据基础。
完整的关系可以概括为：
AI负责组织工作，规则库定义如何计算，Python执行计算，标准数据层保存事实，Excel与BI负责交付和展示。
这才是一套相对清晰的AI业务应用架构。
五、Excel应该回到它最擅长的位置
这个案例让我印象比较深的一点，就是Excel的角色问题。
过去几十年，Excel承担了大量企业管理工作。
它既是数据表，也是计算工具；既是流程载体，也是管理报表。
这种灵活性是Excel最大的优势。
但当业务逐渐形成复杂的自动化系统时，这种灵活性也可能成为风险。
尤其是多个脚本依次读取和修改Excel时：
一个列名变化，可能导致程序失败。
一张模板缺失，可能阻断后续流程。
公式刷新状态不同，可能造成结果不一致。
人工直接修改中间文件，可能破坏数据链路。
因此，我并不认为企业应该放弃Excel。
相反，应该让Excel回到它最擅长的位置：业务输入、人工确认、抽样复核和结果交付。
至于数据标准化、批量计算、运行状态和版本控制，应由更适合的程序和数据存储层承担。
一个更合理的处理路径是：
原始Excel或CSV数据进入Python，完成标准化后保存到统一数据层。
计算引擎基于规则库和人工调整表执行计算。
结果通过质量校验后，再生成最终Excel和经营分析数据集。
这样，修改报表展示格式，不应该影响底层核算结果。
同样，经营分析需要增加一个维度，也不应该要求重写核心计算逻辑。
六、从专家工具到企业产品，我建议分四步改造
如果现在就准备把整个系统重新开发成一个完整平台，成本和风险可能都比较高。
我的建议是分阶段改造，优先解决复现问题，而不是急于追求漂亮的操作界面。
第一步：先解决数据可复现。
明确原始快照、标准数据、人工调整、计算结果和交付文件的边界。
把已经存在的人工确认机制升级为结构化调整记录。
建立统一运行清单，记录每月数据来源和处理状态。
这个阶段的目标非常明确：
同一套输入和规则，应该能够重复得到相同结果。
第二步：再解决规则可治理。
集中管理关键业务规则、计提系数、判断条件和特殊例外。
明确规则版本、生效范围和审批机制。
将核心计算逻辑逐步与Excel文件结构解耦。
这个阶段的目标是：
不仅知道结果是多少，还知道结果为什么这样计算。
第三步：引入AI编排和异常闭环。
让AI识别任务、组织程序执行、解释错误、生成待确认事项，并在人工确认后调用确定性程序重新计算。
但AI不直接修改最终核算金额，也不替代有权限的业务负责人审批。
这个阶段的目标是：
使用者不需要了解每个脚本和目录，也能在系统引导下完成核算。
第四步：建设经营分析和产品界面。
基于稳定的核算结果数据，形成经营指标、趋势分析、异常归因和管理视图。
进一步提供业务人员可使用的操作界面。
最终实现：
选择月份、准备数据、处理异常、执行核算、查看分析、下载结果。
这时，Skill才真正开始从专家工具走向可广泛使用的业务产品。
七、重新定义企业AI Skill的成熟度
通过这个案例，我尝试把企业业务Skill划分为四个层级。
这四个层级不代表专家能力的高低，而是交付形态的不同。
对于个人使用的Skill，L2可能已经足够。
对于需要每月重复运行的核算工作，通常应该进一步追求L3。
对于准备向大量业务人员推广的能力，才需要建设完整的L4产品。
从这个角度看，当前库存核算案例已经具备比较完整的L2能力，并拥有部分L3基础。
它的下一阶段重点，不应是继续堆叠更多脚本，而是提升数据、规则和运行过程的可治理性。
不是每一个Skill都需要产品化，但每一个准备规模化推广的Skill，都应该接受产品化的检验。
八、AI降低了开发门槛，却没有消除工程复杂度
我认为这是这个案例最值得讨论的地方。
过去，企业业务人员提出需求，IT部门负责开发。
开发过程相对漫长，因此往往需要提前明确需求、方案、测试和交付标准。
现在有了AI，业务专家自己就可以编写脚本，甚至在很短时间内实现过去需要开发人员完成的功能。
这显著降低了从想法到原型的门槛。
但与此同时，也容易产生一种误判：
既然专家已经通过AI把功能做出来了，是不是就不需要专业工程建设了？
我认为答案是否定的。
AI降低的是功能实现的门槛，并没有自动消除业务系统的治理要求。
数据来源仍然需要管理。
业务规则仍然需要版本控制。
异常仍然需要闭环。
结果仍然需要审计。
系统仍然需要维护。
权限和责任仍然需要明确。
这些原本就存在于企业软件建设中的问题，不会因为代码由AI生成就自动消失。
更值得关注的是，随着AI开发门槛不断降低，未来企业内部可能出现越来越多由业务专家自行创建的Skill和Agent。
如果缺少统一管理，很容易出现新的应用孤岛。
每个专家都有自己的Skill，每个Skill都有自己的目录、规则、脚本和运行方式。
原本希望通过AI提高组织效率，最后却可能形成新的维护负担。
因此，企业推广AI Skill，不能只关注开发了多少个Skill。
还需要关注多少个Skill能够持续运行、多少个具备明确责任人、多少个可以被其他人复现，以及多少个真正进入业务流程。
九、企业AI能力建设，需要新的分工
这也让我重新思考业务专家、AI和IT之间的关系。
未来，企业AI应用的建设方式可能会逐渐改变。
业务专家负责定义业务。
包括业务规则、计算口径、异常处理原则和结果验收标准。
AI负责理解、编排与解释。
包括识别任务、选择工具、组织执行、提示异常和生成分析。
确定性程序负责计算。
承担规则计算、数据匹配、批量处理和校验。
工程与治理团队负责产品化。
包括数据模型、运行环境、规则版本、权限审计、异常管理和系统维护。
业务负责人负责授权与结果确认。
确保自动化能力始终处于清晰的责任体系之内。
这不是让每个专家都变成程序员。
也不是要求所有AI应用都由IT重新开发。
而是让专家的业务知识、AI的理解能力和专业工程能力形成新的分工。
专家决定什么是对的，程序保证按规则执行，AI负责组织与解释，治理机制保证结果可信。
只有这样，个人能力才有可能真正变成组织能力。
写在最后：Skill不是终点，而是起点
这个库存核算案例并不是一个失败案例。
恰恰相反。
正因为专家已经通过AI，把复杂的业务经验固化成较完整的Skill与脚本，我们才能清晰地看到下一阶段的问题。
如果没有这一步，业务规则仍然可能留在专家脑中，组织甚至无法准确识别系统需要完成哪些工作。
因此，我认为应该肯定专家完成的知识固化成果，同时重新定义后续交付标准。
从专家经验到Skill，是一次能力突破。
从Skill到稳定流程，是一次工程升级。
从稳定流程到人人可用，则是一次产品化和组织治理升级。
专家经验固化，解决“知道怎么做”。
Skill与脚本，解决“能够自动做”。
工程治理，解决“能够稳定、可信地做”。
产品化，解决“让更多人都能做”。
而企业真正需要的，不只是大量Skill文件，而是能够长期运行、持续改进、责任明确的组织能力。
AI让专家更容易创造工具，但只有经过工程化和治理，工具才有可能真正成为组织资产。
这或许是企业大规模推广AI Skill时，最值得重视的一道鸿沟。
本文基于真实业务Skill交付包和工程诊断整理，已对部分企业内部业务数据、系统及核算规则进行泛化处理。有关成熟度的判断属于架构与交付能力评估，不代表已经完成完整生产环境测试。
AI降低了专家创造工具的门槛，却没有消除企业应用的工程复杂度。Skill让个人经验可以被复用，工程化让复用结果值得信赖，产品化才能让这种能力真正属于组织。从专家能做，到AI能做，再到人人能用，这才是企业AI能力建设真正需要跨越的鸿沟。
