别急着造AI员工:企业真正该复制的,是组织的工作方法

企业做 AI，最容易高估的是模型，最容易低估的是“把事情做对的方法”。

模型接上了，知识库建好了，Prompt 模板也发给员工了。可真让 AI 做一份竞品分析、处理一批客户反馈，或者生成一份业务方案，结果还是差点意思：信息很多，结论很满，看起来也很专业，却很难直接拿去用。

问题往往不在于 AI 不知道，而在于它不知道该怎么判断。

企业真正稀缺的，从来不只是文档里的知识，而是资深员工在工作中反复做出的那些选择：先看什么、相信什么、排除什么，什么时候换一种方法，做到什么程度才算可以交付。

这些经验过去藏在人脑里。现在，企业有机会把它们做成 Skill。

一个只负责配图的 Skill，让我重新理解了企业 AI

最近写文章时，我给 AI 加了一个专门负责配图的 Skill。

它不负责选题，不生成观点，也不写正文。等文章基本完成后，它会读一遍结构，找出适合配图的位置，再判断那里更适合流程图、对比图，还是架构图。

它接走的，只是写作流程里很小的一块工作。

但恰恰是这种“小”，让我觉得它比许多号称能接管完整岗位的 Agent 更接近真实工作。

一篇文章不是一个动作，而是一连串能力的组合：选题、检索资料、核查事实、梳理观点、设计结构、配图、排版。产品经理做竞品分析也是一样：先明确分析目的，再选择竞品、收集信息、核查来源、统一口径、识别差异，最后才能输出结论。

所谓“写文章”或者“做竞品分析”，只是我们对一组复杂工作的统称。真正可以稳定交给 AI 的，往往不是整个岗位，而是其中那些反复出现、边界清楚、方法稳定、结果可以验收的能力模块。

竞品分析本身很难被一个 Skill 包办，但持续收集动态、核查信息来源、整理功能矩阵、比对版本变化、生成图表，都可以分别做成 Skill，再组合成一套工作流。

所以，Skill 最值得企业重视的地方，不是它又给 AI 增加了一项功能，而是它提供了一种新的组织能力载体：把原本依附在个人身上的工作方法，封装成团队和 AI 都能重复调用的能力。

Skill 不是更长的 Prompt

很多人第一次接触 Skill，会把它理解成一份写得更详细的提示词。两者确实有关，但解决的不是同一个问题。

Prompt 告诉 AI“这一次要做什么”，比如“给这篇文章画三张图”。工具负责执行动作，比如生成图片、修改颜色、保存文件。知识库提供可参考的内容，比如品牌规范、历史文章和配色方案。Workflow 规定动作顺序，比如先读正文，再生成图片，最后保存。

Skill 解决的是另一层问题：这类任务究竟应该怎样做好。

配图工具可以画图，却不知道文章的哪一段值得画，也不知道什么时候应该选流程图、什么时候应该选架构图。一个合格的配图 Skill 不只会调用工具，还要理解内容关系、选择合适的视觉形式、控制图片的信息密度、检查风格是否统一，并知道生成后应该先交给人确认。

这和给新员工配电脑很像。软件都装好了，不代表他知道公司的方案怎么写、数据从哪里找、哪些信息不能对外发、交付之前应该找谁确认。

一个可以真正投入工作的 Skill，至少要回答五个问题：

什么情况下应该调用它？
它按什么方法和顺序处理任务？
它可以使用哪些知识、数据和工具？
哪些情况必须暂停并交给人判断？
最终结果达到什么标准才算完成？如果这些问题没有被回答，AI 即使拥有工具和资料，也仍然需要人在每次任务里从头教一遍。

企业 AI 卡住，不是因为知识不够

很多企业的 AI 落地路径高度相似：先接入模型，再建设知识库，然后给员工准备一套 Prompt。

该有的似乎都有了，输出却依然不稳定。

比如让 AI 做一份竞品分析。知识库里已经放进了行业报告、竞品资料和历史文档，AI 也能把功能、价格、用户群体整理得很完整。但完整不等于有用。

一个刚接触业务的新人和一个做了五年产品的人，即使看到完全相同的资料，也会交出两份截然不同的分析。

新人容易从“竞品有哪些功能”开始。资深产品经理会先问：这次分析是为了立项、定价，还是版本规划？目的不同，选择的竞品、比较的维度和结论的颗粒度都会改变。

新人看到官网宣布新功能，可能直接写进报告。资深产品经理会继续确认：它已经正式上线，还是仍在灰度测试？是所有地区可用，还是只有部分用户开放？发布稿里的描述，是否能在真实产品中得到验证？

新人记录的是“对方增加了什么”。资深产品经理判断的是“这项变化解决了谁的问题，会不会改变付费路径，对自己的产品意味着什么”。

真正拉开结果差距的，不是两个人掌握了不同的文档，而是他们使用了不同的工作方法。

知识库擅长保存事实、文档和历史结果，却很难自动保存员工在工作中做出的判断：哪个来源更可信，哪些异常可以忽略，什么情况下不能沿用旧口径，什么时候必须找业务负责人确认。

传统 SOP 也很难解决这个问题。SOP 通常会告诉员工打开哪个系统、下载哪张表、填写哪个模板，却很少解释为什么这次要排除某类数据，为什么某个客户必须单独处理，为什么同一个指标在两个业务里不能直接比较。

于是出现了企业 AI 落地中很典型的错位：业务专家觉得 AI 不懂业务，技术团队觉得资料已经全部接入，产品经理只好继续补 Prompt。

模型拿到了公司的知识，却没有拿到公司做事的方法。

Skill 要补上的，正是这道断层。它不是再复制一批文档给 AI，而是把专家处理任务时的选择、顺序、边界和验收标准，变成可以执行、测试和迭代的能力。

把经验做成 Skill，难点不在写文件

理解了 Skill 的价值之后，企业很容易掉进另一个坑：把现有 SOP 复制进去，再补几句要求，就宣布 Skill 制作完成。

这样做出来的，往往只是一个更会朗读制度的 AI。

真正把个人经验转化为 Skill，至少要跨过五道关。

第一，先找对任务，不要先找大岗位

战略判断、复杂谈判和组织协调，高度依赖现场信息、关系处理与责任承担，不适合一开始就整体交给 AI。

第一批适合 Skill 化的任务，通常有四个共同点：经常重复，输入输出相对明确，专家已经形成稳定方法，结果好坏可以检查。

文章配图符合这些条件。每篇文章的内容不同，但哪里需要配图、该选什么图、图片是否清晰，都有相对稳定的判断标准。

“完成竞品分析”则太大。更适合先拆出来的，是信息收集、来源核查、版本对比和矩阵整理。

企业不必先回答“哪个岗位会被 AI 取代”，而应该先回答“团队每周都在重复、每次都容易返工的小任务是什么”。

第二，不要只问专家怎么做，要看他怎样做选择

直接让资深员工总结经验，经常只能得到一句：“先理解需求，再结合业务具体判断。”

每个字都对，但 AI 一个字也执行不了。

更有效的方法，是找三到五个真实案例，让专家重新走一遍：为什么这次选择 A 而不是 B？为什么官网已经发布，报告里仍然标注待确认？为什么两个看似相似的功能，没有放在同一个维度比较？

抽象经验很容易变成正确的废话。具体案例里的取舍，才有机会变成可执行的规则。

不仅要看成功案例，也要看失败案例和边界案例。很多最值钱的经验，不是“通常应该怎么做”，而是“出现什么信号时绝对不能这样做”。

第三，把经验装进任务结构，而不是堆成一篇说明书

经验被提取出来后，还需要转化成 AI 可以执行的任务结构。

以“竞品信息核查”为例，它的触发条件可以是监测到竞品发布新功能，或者分析报告引用了一项未经确认的能力；来源顺序可以是先查真实产品和官方文档，再查官方发布内容，最后参考媒体与社区讨论。

处理时需要区分正式上线、灰度测试、预约开放和概念预告，记录版本、地区与发现时间；不同来源发生冲突时，应保留差异，而不是替业务人员强行下结论。

输出也不该只有一段总结，而应包含事实描述、来源、可信度、待确认事项，以及新信息对原有结论的影响。涉及战略威胁、商业判断和产品决策时，则必须交给负责人确认。

直到这一步，经验才从“供人阅读的知识”变成了“可以被执行的能力”。

第四，用真实任务评测，不要凭感觉验收

企业验证 Skill，不能只看结果是否通顺、演示是否惊艳。

竞品分析写得很像那么回事，不代表其中的功能真实存在；客服回复语气很好，也不代表它没有承诺一项公司根本无法提供的服务。

一个 Skill 至少要接受四项检查：事实是否准确，关键步骤是否遗漏，输出是否符合内部标准，以及人工还需要修改多少。

最实用的办法，是从历史任务中选择一批结果明确的案例，建立基础评测集。每次更新 Skill 后都重新运行。效果究竟变好了，还是只在某几个案例上显得更聪明，数据比现场演示更诚实。

第五，让 Skill 有负责人，也有退出机制

业务规则会变，系统会更换，原本可靠的数据源也可能失效。

如果 Skill 上线后无人维护，它很快会变成一份过期 SOP，只是执行得更快。

每个企业 Skill 都应该有明确的负责人：谁可以修改，更新后由谁审批，使用了哪些数据，出现问题如何回滚。员工对 AI 结果的高频修改也不该停留在个人手里，而应该成为下一轮迭代的输入。

Skill 不是一次性交付的软件功能，而是一项需要持续校准的组织能力。

Skill 多了以后，企业管理的不是文件，而是能力资产

个人使用几个 Skill，放在自己的目录里就能工作。企业一旦拥有几十、上百个 Skill，重复建设、权限混乱、规则冲突和内容过期会立刻出现。

这时，Skill 就不能再被当成普通文件，而应该像内部 API 或产品一样管理。

每个 Skill 都需要明确归属和负责人；标明能够读取哪些数据、调用哪些工具、执行哪些操作；每次更新都要通过历史评测，效果下降时可以回滚；上线以后还要观察真实调用量、任务完成率、人工修改率和错误率。

公司拥有两百个 Skill，听起来很厉害。但如果没人使用，或者每次输出都要推倒重来，它们只不过是两百份换了格式的 SOP。

Skill 的数量不是企业 AI 能力的指标。真正的指标是：有多少工作方法被稳定复用，有多少低价值返工因此消失，有多少原本依赖个别专家的任务变得可传承。

这也是为什么业务专家不能只在项目初期提供资料。经验应该怎样拆、规则是否准确、结果能否交付，都需要业务人员持续参与。技术团队可以让 Skill 跑起来，但只有业务团队知道它有没有把事情做对。

企业真正要复制的，不是员工，而是能力

回到文章配图的例子。

它没有替我完成一篇文章，也没有取代选题、观点和判断。它只是接走了一个边界清楚、经常重复、结果可以验收的环节。

但真实的工作，本来就是这样一点点被重新组织的。

岗位未必会被一个完整的 AI 员工直接接管，却可以被拆成信息收集、事实核查、数据整理、异常识别、内容生成等能力模块。不同 Skill 承担不同模块，再和人的判断一起组成新的工作流。

模型会越来越通用，也越来越容易获得。企业真正难以复制的部分，是自己如何判断、如何协作，以及如何把一件事做到可以交付。

这些方法过去藏在员工脑子里，跟着项目流动，也可能随着员工离职一起消失。把它们做成 Skill，不只是为了让 AI 更好用，也是为了让组织第一次有机会把隐性的经验变成可维护、可评测、可复用的能力资产。

所以，AI 产品经理接下来要做的，不只是选择模型、设计对话框和优化 Prompt。更重要的是找到那些值得沉淀的工作方法，把它们拆清楚、装进 Skill，再用真实任务慢慢把它们养起来。

别急着造一个能接管完整岗位的 AI 员工。

先去找那个团队每周都在重复、每次都有人返工的小任务，把它做成第一个真正有人愿意用的 Skill。