上周项目复盘我们团队又一次聊到了同一个问题每个人都在用 AI但每个人都在重复造轮子。有人用 AI 写日报、有人用 AI 整理会议纪要、有人用 AI 做竞品分析、有人用 AI 从数据库里挑异常数据工具买了一堆提示词也收藏了几百条可真到要复用时大家发现自己还是得重新组织语言、重新调参、重新验证一遍结果。聊到最后我们形成了一个有点反直觉的判断AI-Native 组织真正的瓶颈不是算力不是模型而是能不能把零散的 AI 使用方式沉淀成一套可以运行、扩展和维护的“技能”Skills。这个标题说出来之后有同事当场问了一句“我们不是已经有了很多 AI 工具吗为什么还要搞技能”我当时给了这样一个回答工具只是入口技能才是把工具转成工作流的关键。一个组织如果只是让大家各自用 AI本质上和十年前每个员工自己装一套办公软件没什么区别——有人用得顺手有人用不起来最后成果全部留在个人电脑里组织一点沉淀都拿不到。真正能让一家公司“跑在 AI 上”的不是员工私下会用几个对话框而是那些高频的、重复的、有明确输入输出的任务被结构化成可复制、可评估、可跨团队复用的最小单元。这篇文章想聊的就是我和团队在把日常 AI 使用方式改造成“技能体系”过程中总结出来的一个具体路径从选任务、定契约、建最小闭环到治理、编排、评估再到部署和长期迭代。如果你们团队目前也处在一个“人人都在用 AI但 AI 没有真正进入组织流程”的阶段这篇文章可能会是一次比较实用的参考。1. 为什么“运行在技能上”是 AI-Native 组织的分水岭1.1 从“会用 AI”到“把 AI 固化进工作流”过去一年我们在各种场合听到“AI Native”这个词。很多团队的理解是给员工开一个企业版大模型账号再配上几款 AI 应用就算 AI 原生了。但实际做下来这类部署很快会撞上一个问题效率提升只在个人层面发生团队和组织层面几乎没有变化。原因很简单。个人使用 AI 的时候整个链路是松散的你打开对话框输入需求拿到结果看一眼然后复制粘贴。这个流程看似很快但它只能证明“这个模型能处理这一类问题”并不能证明“这个团队能稳定地用 AI 处理这一类问题”。稳定意味着什么意味着同样的输入不同的人去操作能得到相近质量的结果意味着过程可以被记录可以被审计意味着结果能被验收而不是完全凭感觉判断好坏。这些事情靠一个聊天界面是永远做不到的。我见过一个比较典型的例子市场部的同事用 AI 写产品卖点每一次效果都不一样。状态好的时候他能调出一个很清晰的文案框架状态差的时候他甚至忘了让 AI 查一下产品对应的目标用户画像。后来我们把这个任务拆成了三个步骤先让 AI 从指定文档里抽取产品信息再输给一个固定的框架生成卖点最后让人工勾选合规风险。这三个步骤全部变成固定流程之后文案质量的方差立刻小了很多。这里的关键不是模型变聪明了而是我们把“会用的个人经验”变成了“可执行的团队流程”。1.2 技能不是 Prompt而是可重用的最小任务单元很多人在谈“AI 技能”时首先想到的是提示词Prompt。提示词确实重要但把提示词当成技能是一个常见误解。一段提示词只描述了“怎么问”却没有定义“输入从哪里来”“输出到哪里去”“怎么判断结果对不对”“失败时怎么办”。真正能跑在组织工作流里的技能应该是一个包含了输入、处理逻辑、输出格式和校验规则的任务单元。打个比方。你把一个资深数据分析师的思考过程写成一段提示词让其他人拿去问 AI大概率得不到和他相同的结果。因为这位分析师会先确定数据字段、再过滤异常样本、然后选择合适的统计口径、最后还要用业务常识判断结论是否合理。这些步骤没有写进提示词里模型当然不知道。技能化的任务就是要把这些隐藏步骤全部显式化使用什么输入、调用什么接口、采用什么上下文、输出什么结构、由谁在哪个节点做人工判断。它更像是一份可以被机器执行的 SOP而不是一句漂亮的话术。这也解释了为什么“技能”比“提示词”更适合作为组织级 AI 的载体。提示词是个人资产技能是团队资产。个人资产可以靠悟性和经验积累团队资产必须靠协议、版本、owner 和评审机制来维护。后面我们会看到这些治理动作恰恰是 AI 能从“小打小闹”走向“生产系统”的关键。1.3 为什么组织比个人更需要“技能化”从个人视角看“技能化”听起来有点多此一举。我已经能用 AI 解决我的问题了为什么还要把它做成一个技能但如果把视角切换到组织答案会完全不同。第一组织要的是可预测性。个人使用 AI 可以容忍 100 次里有 30 次效果不稳定但面向客户的自动化流程不行。技能化通过固定流程和输出校验把不可预测的模型输出约束在可控范围内。第二组织要的是知识传承。个人用 AI 的技巧如果不沉淀员工离职后一切归零。技能一旦变成代码、配置、文档和测试用例就不会随人去留而丢失。第三组织要的是成本可管理。当你只有一个员工用 AI你不会在意一次调用消耗了多少 token。当几百个技能跑在几十个团队里每一笔调用都对应预算和资源你需要知道哪个技能被高频使用、哪个技能结果合格率低、哪个技能应该换更便宜的模型。技能化的计费单位比“人均一个账号”要精确得多。所以我的结论是AI-Native 组织的分水岭不在于是不是用上了最新模型而在于组织能不能把 AI 的使用方式从个人行为升级为组织能力。技能就是这种升级的最小载体。2. 一个 AI 技能是如何从零构建出来的2.1 选择任务高频、可验收、边界清晰很多团队启动技能化建设时最容易犯的错误是贪多。看到什么任务都想先做结果两周后一个都没跑通。我的建议是从三个标准里筛选第一个技能高频、可验收、边界清晰。高频意味着这个任务每周都会出现做出后收益立刻能体现。可验收意味着你能定义什么叫“做对了”比如输出必须包含五个字段、必须符合某种格式、必须没有超过多少字的幻觉。边界清晰意味着任务输入和输出比较明确不会牵扯太多模糊的上下文。我推荐第一批技能优先考虑这几类任务信息抽取从长文档中提取结构化字段、格式转换非标准文本转成标准表格、摘要生成会议纪要、周报要点、分类打标工单分类、风险判定。这些任务都有一个共同点输入是文本输出是结构化结果评价标准相对客观。等到团队熟悉了构建流程再逐步扩展生成型任务、探索型任务和需要多轮决策的任务。2.2 定义契约输入、上下文、输出、校验在我看来技能的构建不是从写提示词开始而是从定义一份“技能契约”开始的。契约不需要很重但至少需要包含四部分输入定义、上下文来源、输出结构、校验规则。输入定义回答的问题是“用户调用这个技能时需要提供什么”可以是原始文本、文件路径、表单字段也可以是一段数据库查询结果。上下文来源回答的是“模型除了用户输入还需要知道哪些背景信息”例如一个写产品文案的技能需要把产品文档、品牌风格、目标用户画像作为上下文拼进请求里。输出结构回答的是“模型应该返回什么格式”是 JSON、Markdown 表格还是一段带固定分点的文案校验规则回答的是“如何判断结果合格”可以检查字段非空、格式合法、长度范围、必填项是否存在也可以用规则引擎做关键词检测甚至调用另一个小模型打分。契约定义得越清楚后面做评估、调参和跨团队复用就越容易。很多人觉得这很繁琐但正是这份繁琐把“AI 技能”和“临时对话”区分开了。2.3 最小闭环先跑通一条真实样本契约定义完之后不要急着写抽象代码先拿一条真实业务样本跑通闭环。这里说的闭环不是仅仅在模型对话框里得到一次答案而是从上一次完整输入到输出解析再到校验结果通过整个过程都能在一段脚本里执行。假设我们要做一个“会议纪要整理技能”输入是一段录音转文字输出是包含会议结论、待办事项、负责人、截止日期的结构化文件。第一步不是立刻调用模型而是准备一份非常典型的真实会议转写文本哪怕是 300 字的小片段也行。第二步设计好输出 JSON 的字段结构。第三步把这段文本拼到上下文模板里调用模型接口得到 JSON解析后检查字段是否齐全。第四步如果某些字段缺失或者格式不对优化提示词和上下文直到这条样例稳定通过。这里的核心原则是先窄后宽先单例后批量。不要试图一开始就覆盖各种异常场景。先用一条真实样本建立起可复用的最小闭环再逐步增加样本和边界条件。2.4 用代码把技能固化下来当一条样例跑通之后下一步才是把技能“固化”成代码或配置。固化的方式有很多种最轻的是写一个 Python 函数把提示词、上下文拼接、模型调用和结果解析封装在一起。稍重一点是做成一个 HTTP 接口再重一点是接进 Agent 框架或工作流引擎。这里给一个非常简化的示例结构用常见的大模型调用接口举例import json from openai import OpenAI client OpenAI() def extract_action_items(transcript: str) - list[dict]: prompt f 你是项目跟进助理。请从会议记录中提取待办事项。 要求 1. 只提取明确指派和截止时间的任务 2. 输出 JSON 数组每个元素包含 task、owner、due_date 3. 不要补充原文中没有的信息。 会议记录 {transcript} response client.chat.completions.create( modelgpt-4o-mini, # 实际模型名称以你的服务商为准 messages[ {role: system, content: 你是一个严谨的信息抽取器。}, {role: user, content: prompt}, ], temperature0, ) raw response.choices[0].message.content # 这里最好增加一个健壮的 JSON 提取逻辑 return json.loads(raw)等代码写完你会看到“技能”的形态已经和“提示词”不一样了。它有了确定的函数名、参数列表、返回结构还有一段可以反复执行的逻辑。接下来你要做的事情就变成了更多的样本测试、更严格的输出校验、更完善的异常处理以及把技能发布到团队能访问的地方。3. 扩展技能库单点能力到组织能力3.1 治理机制版本、权限、Owner当团队里出现了第三个、第五个、第十个技能时一定会遇到治理问题。最典型的是某个技能的输出结果变了但没有及时通知所有使用者或者某个技能是三个人同时维护的谁也不想为质量负责。我比较推荐在技能库早期就引入三个轻量机制版本号、Owner、调用权限。版本号每次修改提示词、上下文模板或输出结构都更新一次版本并在技能描述里注明改动内容。这样使用者能明确知道自己在用哪个版本出问题时也可以快速回退。Owner每个技能指定一个负责人可以是产品经理、数据工程师或业务骨干。Owner 的职责不是写所有代码而是对技能最终输出质量负责收集反馈、安排迭代。调用权限区分内部公开、团队可见、私有三类权限。早期很多技能还不稳定不要一上来就全员公开先在核心团队跑一段时间确认效果后再扩展范围。治理不是把流程做复杂而是让“技能库”在组织里建立基本信任。没有治理大家用着用着就会重新回到各自为政的状态。3.2 编排用 Agent 把多个技能串成工作流技能一旦积累到一定程度就会出现一个明显的需求把多个技能串联成更复杂的任务。比如“竞品分析”这个任务可能由“页面抓取”“信息抽取”“卖点对比”“报告生成”四个技能组成。每个技能单独运行只能完成一个环节串联起来才能形成完整的服务。这个串联过程就是 AI Agent 的开发场景。你可以给 Agent 定义一个目标并让它根据用户指令调用技能库中的现有技能也可以采用更可控的方式自己用代码编排流程按顺序调用技能中间加入人工审核节点。从工程实践来看后者在早期更稳定因为 Agent 自主编排的路越走越宽但“为什么做出这个选择”很难解释出了问题也难回查。更好的策略是先用硬编码流程把业务跑通直到你真的遇到需要动态决策的场景再让 Agent 介入。举个例子很多团队用 Agent 做“工单自动分诊”其实就是把“文本分类”“相似度检索”“优先级计算”三个技能串在一起。Agent 的职责是理解工单内容并决定调用哪个技能但每个技能内部的逻辑仍然是固定且可测试的。这种设计保留了技能的可验证性同时提升了任务处理的灵活性。3.3 质量闸门幻觉与输出不稳定的应对在技能库规模化过程中有一关躲不开AI 幻觉。模型会在信息不够完整时一本正经地编造事实这是所有生成式模型共有的问题。组织级技能和临时对话最大的不同在于你需要设计一道“质量闸门”。质量闸门可以分三层输入侧确保模型拿到的是完整、可信的上下文。如果输入本身不完整后续再调优也无济于事。输出侧用结构化约束和规则校验来拦截明显错误。比如任务涉及发布日期时要求模型返回 ISO 日期格式涉及数字金额时要求模型必须基于输入文本给出依据。复盘侧把不合格的样本沉淀下来变成回归测试用例。每次升级技能时先跑一遍历史测试集确保旧的问题没有复发。很多人喜欢问“怎么让模型完全不产生幻觉”我的回答是很难做到。更实际的目标是“把幻觉发生的概率降到可接受范围并且在发生时可以被发现”。所以涉及事实输出的技能尽量让模型完成抽取、改写、摘要这类任务而不要把知识问答、情报研判这种高风险任务全部交给模型做最终判断。话说回来现在大家已经越来越不迷信“用 AI 一次写完整篇文章”这件事了就是因为 AI 生成内容在事实准确性和语气稳定性上仍然需要人机协作真正靠谱的用法是把它拆到不同环节并在关键节点加入人工复核。3.4 部署边界API、私有化还是本地模型技能化之后你还会面临一个非常现实的工程问题模型到底跑在哪里是调用云端的模型服务还是私有化部署还是本地跑开源模型这个问题没有统一答案但可以按几个维度拆。维度云端 API私有化部署本地模型数据安全要求较低需签署数据协议高数据留内网高数据不出机器启动成本低按量付费中高需要 GPU 资源中取决于硬件维护成本低服务商负责高需要专人部署升级中需自己管理环境模型能力通常最新最强取决于选型通常弱于头部 API适用场景大部分高频文本任务金融、医疗、政企等高合规场景离线环境、个人学习、隐私敏感在实际操作中很多团队会采用混合策略不敏感、对模型能力要求高的任务走云端 API敏感数据走私有化模型个人研究和小规模实验用本地部署。这里需要提醒的是本地部署不只是把模型下载下来那么轻松。以 AMD Ryzen AI 9 HX 370 这类新处理器为例如果你用 Ollama 跑本地模型要确认推理过程是否真的用上了 GPU而不是空耗 CPU。排查手段通常是先运行ollama ps查看当前模型运行的设备再用rocm-smi或任务管理器看 GPU 占用率最后跑一个固定 prompt 对比耗时。不同硬件驱动版本对模型算子的支持差异很大不能简单认为“能加载模型就等于优化到位”。在 Java 技术栈里Spring AI 这类框架提供了一套抽象层可以让我们比较方便地切换不同模型服务商也适合把技能封装成可注入的 Bean 或 REST API。不过框架只能解决接入层的统一真正的技能质量仍然取决于你的输入处理、输出校验和回归测试是否到位。4. 一路上最容易踩的坑以及排查链路4.1 单点跑通不等于批量稳定技能化建设第一个大坑是拿单条样例成功后就匆忙上线。我在前面强调过“先跑通一条样本”但这个“先”不是终点只是起点。当你把技能从 1 条样本扩展到 100 条真实数据时会发现各种意想不到的情况输入格式不统一、某些字段为空、特殊字符导致解析失败、同一类任务在不同主题上的质量波动极大。一个更稳妥的做法是在技能上线前准备至少 20 条覆盖正常、边界、异常情况的测试用例。正常用例验证主流程边界用例验证输入长度、格式变化、内容歧义异常用例验证模型在信息不足时是否会产生幻觉。只有当测试通过率达到你设定的阈值时才允许把技能提供给团队使用。这就像写代码一样你不能只跑 happy path 就上生产。4.2 上下文和输入格式是最容易出问题的地方大量技能故障最后排查下来都不是模型能力问题而是输入侧的问题。比如调用方传进来的参数是 Markdown 文本而技能模板里默认是纯文本比如用户上传的文档是一个扫描件 PDF没有经过 OCR模型自然提取不到任何有用信息再比如长文档超过了上下文窗口的限制模型只看到了文章开头后面的关键信息完全没有参与推理。如果技能定义时没有对输入做规范化和预处理后面所有环节都会被带偏。我建议在技能入口处先做一个输入检查清单内容是否可读、编码是否正常、长度是否超限、是否需要先经过 OCR、是否需要拆分成多个 chunk。不要让模型去猜输入问题尽量在进入模型之前就把它处理好。4.3 排查的顺序现象、输入、环境、参数、边界当技能出错时不要一上来就怀疑模型不够好。按照下面的顺序排查通常能更快定位问题看现象报错、空输出、格式错误、内容错误、速度慢、结果不稳定分别对应不同原因。看输入原始输入和上下文拼接后模型实际看到的到底是什么。建议先把 prompt 保存到日志里复现问题时能直接核对。看环境依赖版本、接口密钥、模型名称、网络权限、资源占用是否有变化。很多“昨天还能跑今天不行”的问题都是环境变动导致的。看参数温度、max tokens、top_p、超时时间、重试次数等参数是否被误调。尤其是温度在信息抽取类任务里应该设为 0 或接近 0否则输出方差会很大。看边界当前技能的处理能力边界在哪里上下文长度、输入字段、输出结构、模型本身的能力天花板都可能成为瓶颈。如果任务超出边界就要考虑换模型、加预处理或拆流程。这个排查链路不复杂但能省去大量拍脑袋的调试时间。尤其是当组织里多个技能同时运行后日志和可观测性会成为最重要的基础设施。5. 落地建议先做小再做深再做广5.1 用三张表盘点现有任务如果你所在团队正准备开始技能化改造我建议先不要急着写代码。找一天时间让团队核心成员一起做一次任务盘点。可以分三张表第一张是“高频重复任务”第二张是“当前 AI 用得上但质量不稳的任务”第三张是“目前只能人工处理、但可能被拆解的任务”。盘点完按“难度 × 价值”画一个二维矩阵从第一象限里挑 1 到 3 个任务作为首批技能试点。这里有个容易被忽略的原则不要选对你业务最核心但失败成本极高的任务。比如医疗诊断、财务审批虽然价值巨大但早期技能还不够成熟一旦出错会让团队失去信心。先选一些风险可控的周边任务赢得信任后再向核心流程推进。5.2 先搭一个内部技能沙盒组织级技能建设早期不需要一个庞大的平台。你可以先用一个代码仓库管理技能定义再用一套简单的目录结构组织每个技能的文档、prompt 模板、测试用例和调用代码。如果有条件再提供一个内部 Web 页面或聊天应用入口让团队成员能搜索技能、查看示例、提交反馈。这个“沙盒”阶段的关键不是功能多全而是让大家感受到技能化和临时提示词之间的差别它稳定、可复用、有文档、有测试。当有几个技能在沙盒里稳定运行 2 到 4 周后再考虑接入统一身份认证、调用审计、成本计量等能力。很多团队一上来就追求大平台结果平台没搭好技能又没人维护最后反而回到聊天框。5.3 长期来看技能库会变成组织的新“知识库”最后再说一个我自己的判断随着每个团队把自己的任务技能化这个技能库会逐渐长成组织最有价值的知识资产。过去我们积累知识的方式是写文档、存 wiki、录制分享视频未来可运行、可调用、可验证的技能会成为一种更高级的知识形态。文档记录的是“当时怎么做”技能记录的是“现在怎么做、怎么让机器替你做、怎么做完验证是否达标”。这并不意味着文档不再重要而是说文档会越来越多地成为技能的附属品解释设计意图、说明边界条件、记录变更历史。真正的业务处理能力将由成体系的技能库来承载。到那个时候AI-Native 组织才真正意义上“Run on Skills”了。如果你问我现在最该做什么。我的答案很朴素选一个你每周都要做、又总做不好的小任务花半天时间把它拆成输入、上下文、输出和校验再写 20 行代码让模型跑一遍然后把测试用例留下来。你不需要立刻建平台也不需要等最强模型发布。从这一个技能开始你就已经走在从“用 AI”到“运行在 AI 上”的路上了。
AI-Native组织的分水岭：把AI使用方式沉淀为可复用技能
上周项目复盘我们团队又一次聊到了同一个问题每个人都在用 AI但每个人都在重复造轮子。有人用 AI 写日报、有人用 AI 整理会议纪要、有人用 AI 做竞品分析、有人用 AI 从数据库里挑异常数据工具买了一堆提示词也收藏了几百条可真到要复用时大家发现自己还是得重新组织语言、重新调参、重新验证一遍结果。聊到最后我们形成了一个有点反直觉的判断AI-Native 组织真正的瓶颈不是算力不是模型而是能不能把零散的 AI 使用方式沉淀成一套可以运行、扩展和维护的“技能”Skills。这个标题说出来之后有同事当场问了一句“我们不是已经有了很多 AI 工具吗为什么还要搞技能”我当时给了这样一个回答工具只是入口技能才是把工具转成工作流的关键。一个组织如果只是让大家各自用 AI本质上和十年前每个员工自己装一套办公软件没什么区别——有人用得顺手有人用不起来最后成果全部留在个人电脑里组织一点沉淀都拿不到。真正能让一家公司“跑在 AI 上”的不是员工私下会用几个对话框而是那些高频的、重复的、有明确输入输出的任务被结构化成可复制、可评估、可跨团队复用的最小单元。这篇文章想聊的就是我和团队在把日常 AI 使用方式改造成“技能体系”过程中总结出来的一个具体路径从选任务、定契约、建最小闭环到治理、编排、评估再到部署和长期迭代。如果你们团队目前也处在一个“人人都在用 AI但 AI 没有真正进入组织流程”的阶段这篇文章可能会是一次比较实用的参考。1. 为什么“运行在技能上”是 AI-Native 组织的分水岭1.1 从“会用 AI”到“把 AI 固化进工作流”过去一年我们在各种场合听到“AI Native”这个词。很多团队的理解是给员工开一个企业版大模型账号再配上几款 AI 应用就算 AI 原生了。但实际做下来这类部署很快会撞上一个问题效率提升只在个人层面发生团队和组织层面几乎没有变化。原因很简单。个人使用 AI 的时候整个链路是松散的你打开对话框输入需求拿到结果看一眼然后复制粘贴。这个流程看似很快但它只能证明“这个模型能处理这一类问题”并不能证明“这个团队能稳定地用 AI 处理这一类问题”。稳定意味着什么意味着同样的输入不同的人去操作能得到相近质量的结果意味着过程可以被记录可以被审计意味着结果能被验收而不是完全凭感觉判断好坏。这些事情靠一个聊天界面是永远做不到的。我见过一个比较典型的例子市场部的同事用 AI 写产品卖点每一次效果都不一样。状态好的时候他能调出一个很清晰的文案框架状态差的时候他甚至忘了让 AI 查一下产品对应的目标用户画像。后来我们把这个任务拆成了三个步骤先让 AI 从指定文档里抽取产品信息再输给一个固定的框架生成卖点最后让人工勾选合规风险。这三个步骤全部变成固定流程之后文案质量的方差立刻小了很多。这里的关键不是模型变聪明了而是我们把“会用的个人经验”变成了“可执行的团队流程”。1.2 技能不是 Prompt而是可重用的最小任务单元很多人在谈“AI 技能”时首先想到的是提示词Prompt。提示词确实重要但把提示词当成技能是一个常见误解。一段提示词只描述了“怎么问”却没有定义“输入从哪里来”“输出到哪里去”“怎么判断结果对不对”“失败时怎么办”。真正能跑在组织工作流里的技能应该是一个包含了输入、处理逻辑、输出格式和校验规则的任务单元。打个比方。你把一个资深数据分析师的思考过程写成一段提示词让其他人拿去问 AI大概率得不到和他相同的结果。因为这位分析师会先确定数据字段、再过滤异常样本、然后选择合适的统计口径、最后还要用业务常识判断结论是否合理。这些步骤没有写进提示词里模型当然不知道。技能化的任务就是要把这些隐藏步骤全部显式化使用什么输入、调用什么接口、采用什么上下文、输出什么结构、由谁在哪个节点做人工判断。它更像是一份可以被机器执行的 SOP而不是一句漂亮的话术。这也解释了为什么“技能”比“提示词”更适合作为组织级 AI 的载体。提示词是个人资产技能是团队资产。个人资产可以靠悟性和经验积累团队资产必须靠协议、版本、owner 和评审机制来维护。后面我们会看到这些治理动作恰恰是 AI 能从“小打小闹”走向“生产系统”的关键。1.3 为什么组织比个人更需要“技能化”从个人视角看“技能化”听起来有点多此一举。我已经能用 AI 解决我的问题了为什么还要把它做成一个技能但如果把视角切换到组织答案会完全不同。第一组织要的是可预测性。个人使用 AI 可以容忍 100 次里有 30 次效果不稳定但面向客户的自动化流程不行。技能化通过固定流程和输出校验把不可预测的模型输出约束在可控范围内。第二组织要的是知识传承。个人用 AI 的技巧如果不沉淀员工离职后一切归零。技能一旦变成代码、配置、文档和测试用例就不会随人去留而丢失。第三组织要的是成本可管理。当你只有一个员工用 AI你不会在意一次调用消耗了多少 token。当几百个技能跑在几十个团队里每一笔调用都对应预算和资源你需要知道哪个技能被高频使用、哪个技能结果合格率低、哪个技能应该换更便宜的模型。技能化的计费单位比“人均一个账号”要精确得多。所以我的结论是AI-Native 组织的分水岭不在于是不是用上了最新模型而在于组织能不能把 AI 的使用方式从个人行为升级为组织能力。技能就是这种升级的最小载体。2. 一个 AI 技能是如何从零构建出来的2.1 选择任务高频、可验收、边界清晰很多团队启动技能化建设时最容易犯的错误是贪多。看到什么任务都想先做结果两周后一个都没跑通。我的建议是从三个标准里筛选第一个技能高频、可验收、边界清晰。高频意味着这个任务每周都会出现做出后收益立刻能体现。可验收意味着你能定义什么叫“做对了”比如输出必须包含五个字段、必须符合某种格式、必须没有超过多少字的幻觉。边界清晰意味着任务输入和输出比较明确不会牵扯太多模糊的上下文。我推荐第一批技能优先考虑这几类任务信息抽取从长文档中提取结构化字段、格式转换非标准文本转成标准表格、摘要生成会议纪要、周报要点、分类打标工单分类、风险判定。这些任务都有一个共同点输入是文本输出是结构化结果评价标准相对客观。等到团队熟悉了构建流程再逐步扩展生成型任务、探索型任务和需要多轮决策的任务。2.2 定义契约输入、上下文、输出、校验在我看来技能的构建不是从写提示词开始而是从定义一份“技能契约”开始的。契约不需要很重但至少需要包含四部分输入定义、上下文来源、输出结构、校验规则。输入定义回答的问题是“用户调用这个技能时需要提供什么”可以是原始文本、文件路径、表单字段也可以是一段数据库查询结果。上下文来源回答的是“模型除了用户输入还需要知道哪些背景信息”例如一个写产品文案的技能需要把产品文档、品牌风格、目标用户画像作为上下文拼进请求里。输出结构回答的是“模型应该返回什么格式”是 JSON、Markdown 表格还是一段带固定分点的文案校验规则回答的是“如何判断结果合格”可以检查字段非空、格式合法、长度范围、必填项是否存在也可以用规则引擎做关键词检测甚至调用另一个小模型打分。契约定义得越清楚后面做评估、调参和跨团队复用就越容易。很多人觉得这很繁琐但正是这份繁琐把“AI 技能”和“临时对话”区分开了。2.3 最小闭环先跑通一条真实样本契约定义完之后不要急着写抽象代码先拿一条真实业务样本跑通闭环。这里说的闭环不是仅仅在模型对话框里得到一次答案而是从上一次完整输入到输出解析再到校验结果通过整个过程都能在一段脚本里执行。假设我们要做一个“会议纪要整理技能”输入是一段录音转文字输出是包含会议结论、待办事项、负责人、截止日期的结构化文件。第一步不是立刻调用模型而是准备一份非常典型的真实会议转写文本哪怕是 300 字的小片段也行。第二步设计好输出 JSON 的字段结构。第三步把这段文本拼到上下文模板里调用模型接口得到 JSON解析后检查字段是否齐全。第四步如果某些字段缺失或者格式不对优化提示词和上下文直到这条样例稳定通过。这里的核心原则是先窄后宽先单例后批量。不要试图一开始就覆盖各种异常场景。先用一条真实样本建立起可复用的最小闭环再逐步增加样本和边界条件。2.4 用代码把技能固化下来当一条样例跑通之后下一步才是把技能“固化”成代码或配置。固化的方式有很多种最轻的是写一个 Python 函数把提示词、上下文拼接、模型调用和结果解析封装在一起。稍重一点是做成一个 HTTP 接口再重一点是接进 Agent 框架或工作流引擎。这里给一个非常简化的示例结构用常见的大模型调用接口举例import json from openai import OpenAI client OpenAI() def extract_action_items(transcript: str) - list[dict]: prompt f 你是项目跟进助理。请从会议记录中提取待办事项。 要求 1. 只提取明确指派和截止时间的任务 2. 输出 JSON 数组每个元素包含 task、owner、due_date 3. 不要补充原文中没有的信息。 会议记录 {transcript} response client.chat.completions.create( modelgpt-4o-mini, # 实际模型名称以你的服务商为准 messages[ {role: system, content: 你是一个严谨的信息抽取器。}, {role: user, content: prompt}, ], temperature0, ) raw response.choices[0].message.content # 这里最好增加一个健壮的 JSON 提取逻辑 return json.loads(raw)等代码写完你会看到“技能”的形态已经和“提示词”不一样了。它有了确定的函数名、参数列表、返回结构还有一段可以反复执行的逻辑。接下来你要做的事情就变成了更多的样本测试、更严格的输出校验、更完善的异常处理以及把技能发布到团队能访问的地方。3. 扩展技能库单点能力到组织能力3.1 治理机制版本、权限、Owner当团队里出现了第三个、第五个、第十个技能时一定会遇到治理问题。最典型的是某个技能的输出结果变了但没有及时通知所有使用者或者某个技能是三个人同时维护的谁也不想为质量负责。我比较推荐在技能库早期就引入三个轻量机制版本号、Owner、调用权限。版本号每次修改提示词、上下文模板或输出结构都更新一次版本并在技能描述里注明改动内容。这样使用者能明确知道自己在用哪个版本出问题时也可以快速回退。Owner每个技能指定一个负责人可以是产品经理、数据工程师或业务骨干。Owner 的职责不是写所有代码而是对技能最终输出质量负责收集反馈、安排迭代。调用权限区分内部公开、团队可见、私有三类权限。早期很多技能还不稳定不要一上来就全员公开先在核心团队跑一段时间确认效果后再扩展范围。治理不是把流程做复杂而是让“技能库”在组织里建立基本信任。没有治理大家用着用着就会重新回到各自为政的状态。3.2 编排用 Agent 把多个技能串成工作流技能一旦积累到一定程度就会出现一个明显的需求把多个技能串联成更复杂的任务。比如“竞品分析”这个任务可能由“页面抓取”“信息抽取”“卖点对比”“报告生成”四个技能组成。每个技能单独运行只能完成一个环节串联起来才能形成完整的服务。这个串联过程就是 AI Agent 的开发场景。你可以给 Agent 定义一个目标并让它根据用户指令调用技能库中的现有技能也可以采用更可控的方式自己用代码编排流程按顺序调用技能中间加入人工审核节点。从工程实践来看后者在早期更稳定因为 Agent 自主编排的路越走越宽但“为什么做出这个选择”很难解释出了问题也难回查。更好的策略是先用硬编码流程把业务跑通直到你真的遇到需要动态决策的场景再让 Agent 介入。举个例子很多团队用 Agent 做“工单自动分诊”其实就是把“文本分类”“相似度检索”“优先级计算”三个技能串在一起。Agent 的职责是理解工单内容并决定调用哪个技能但每个技能内部的逻辑仍然是固定且可测试的。这种设计保留了技能的可验证性同时提升了任务处理的灵活性。3.3 质量闸门幻觉与输出不稳定的应对在技能库规模化过程中有一关躲不开AI 幻觉。模型会在信息不够完整时一本正经地编造事实这是所有生成式模型共有的问题。组织级技能和临时对话最大的不同在于你需要设计一道“质量闸门”。质量闸门可以分三层输入侧确保模型拿到的是完整、可信的上下文。如果输入本身不完整后续再调优也无济于事。输出侧用结构化约束和规则校验来拦截明显错误。比如任务涉及发布日期时要求模型返回 ISO 日期格式涉及数字金额时要求模型必须基于输入文本给出依据。复盘侧把不合格的样本沉淀下来变成回归测试用例。每次升级技能时先跑一遍历史测试集确保旧的问题没有复发。很多人喜欢问“怎么让模型完全不产生幻觉”我的回答是很难做到。更实际的目标是“把幻觉发生的概率降到可接受范围并且在发生时可以被发现”。所以涉及事实输出的技能尽量让模型完成抽取、改写、摘要这类任务而不要把知识问答、情报研判这种高风险任务全部交给模型做最终判断。话说回来现在大家已经越来越不迷信“用 AI 一次写完整篇文章”这件事了就是因为 AI 生成内容在事实准确性和语气稳定性上仍然需要人机协作真正靠谱的用法是把它拆到不同环节并在关键节点加入人工复核。3.4 部署边界API、私有化还是本地模型技能化之后你还会面临一个非常现实的工程问题模型到底跑在哪里是调用云端的模型服务还是私有化部署还是本地跑开源模型这个问题没有统一答案但可以按几个维度拆。维度云端 API私有化部署本地模型数据安全要求较低需签署数据协议高数据留内网高数据不出机器启动成本低按量付费中高需要 GPU 资源中取决于硬件维护成本低服务商负责高需要专人部署升级中需自己管理环境模型能力通常最新最强取决于选型通常弱于头部 API适用场景大部分高频文本任务金融、医疗、政企等高合规场景离线环境、个人学习、隐私敏感在实际操作中很多团队会采用混合策略不敏感、对模型能力要求高的任务走云端 API敏感数据走私有化模型个人研究和小规模实验用本地部署。这里需要提醒的是本地部署不只是把模型下载下来那么轻松。以 AMD Ryzen AI 9 HX 370 这类新处理器为例如果你用 Ollama 跑本地模型要确认推理过程是否真的用上了 GPU而不是空耗 CPU。排查手段通常是先运行ollama ps查看当前模型运行的设备再用rocm-smi或任务管理器看 GPU 占用率最后跑一个固定 prompt 对比耗时。不同硬件驱动版本对模型算子的支持差异很大不能简单认为“能加载模型就等于优化到位”。在 Java 技术栈里Spring AI 这类框架提供了一套抽象层可以让我们比较方便地切换不同模型服务商也适合把技能封装成可注入的 Bean 或 REST API。不过框架只能解决接入层的统一真正的技能质量仍然取决于你的输入处理、输出校验和回归测试是否到位。4. 一路上最容易踩的坑以及排查链路4.1 单点跑通不等于批量稳定技能化建设第一个大坑是拿单条样例成功后就匆忙上线。我在前面强调过“先跑通一条样本”但这个“先”不是终点只是起点。当你把技能从 1 条样本扩展到 100 条真实数据时会发现各种意想不到的情况输入格式不统一、某些字段为空、特殊字符导致解析失败、同一类任务在不同主题上的质量波动极大。一个更稳妥的做法是在技能上线前准备至少 20 条覆盖正常、边界、异常情况的测试用例。正常用例验证主流程边界用例验证输入长度、格式变化、内容歧义异常用例验证模型在信息不足时是否会产生幻觉。只有当测试通过率达到你设定的阈值时才允许把技能提供给团队使用。这就像写代码一样你不能只跑 happy path 就上生产。4.2 上下文和输入格式是最容易出问题的地方大量技能故障最后排查下来都不是模型能力问题而是输入侧的问题。比如调用方传进来的参数是 Markdown 文本而技能模板里默认是纯文本比如用户上传的文档是一个扫描件 PDF没有经过 OCR模型自然提取不到任何有用信息再比如长文档超过了上下文窗口的限制模型只看到了文章开头后面的关键信息完全没有参与推理。如果技能定义时没有对输入做规范化和预处理后面所有环节都会被带偏。我建议在技能入口处先做一个输入检查清单内容是否可读、编码是否正常、长度是否超限、是否需要先经过 OCR、是否需要拆分成多个 chunk。不要让模型去猜输入问题尽量在进入模型之前就把它处理好。4.3 排查的顺序现象、输入、环境、参数、边界当技能出错时不要一上来就怀疑模型不够好。按照下面的顺序排查通常能更快定位问题看现象报错、空输出、格式错误、内容错误、速度慢、结果不稳定分别对应不同原因。看输入原始输入和上下文拼接后模型实际看到的到底是什么。建议先把 prompt 保存到日志里复现问题时能直接核对。看环境依赖版本、接口密钥、模型名称、网络权限、资源占用是否有变化。很多“昨天还能跑今天不行”的问题都是环境变动导致的。看参数温度、max tokens、top_p、超时时间、重试次数等参数是否被误调。尤其是温度在信息抽取类任务里应该设为 0 或接近 0否则输出方差会很大。看边界当前技能的处理能力边界在哪里上下文长度、输入字段、输出结构、模型本身的能力天花板都可能成为瓶颈。如果任务超出边界就要考虑换模型、加预处理或拆流程。这个排查链路不复杂但能省去大量拍脑袋的调试时间。尤其是当组织里多个技能同时运行后日志和可观测性会成为最重要的基础设施。5. 落地建议先做小再做深再做广5.1 用三张表盘点现有任务如果你所在团队正准备开始技能化改造我建议先不要急着写代码。找一天时间让团队核心成员一起做一次任务盘点。可以分三张表第一张是“高频重复任务”第二张是“当前 AI 用得上但质量不稳的任务”第三张是“目前只能人工处理、但可能被拆解的任务”。盘点完按“难度 × 价值”画一个二维矩阵从第一象限里挑 1 到 3 个任务作为首批技能试点。这里有个容易被忽略的原则不要选对你业务最核心但失败成本极高的任务。比如医疗诊断、财务审批虽然价值巨大但早期技能还不够成熟一旦出错会让团队失去信心。先选一些风险可控的周边任务赢得信任后再向核心流程推进。5.2 先搭一个内部技能沙盒组织级技能建设早期不需要一个庞大的平台。你可以先用一个代码仓库管理技能定义再用一套简单的目录结构组织每个技能的文档、prompt 模板、测试用例和调用代码。如果有条件再提供一个内部 Web 页面或聊天应用入口让团队成员能搜索技能、查看示例、提交反馈。这个“沙盒”阶段的关键不是功能多全而是让大家感受到技能化和临时提示词之间的差别它稳定、可复用、有文档、有测试。当有几个技能在沙盒里稳定运行 2 到 4 周后再考虑接入统一身份认证、调用审计、成本计量等能力。很多团队一上来就追求大平台结果平台没搭好技能又没人维护最后反而回到聊天框。5.3 长期来看技能库会变成组织的新“知识库”最后再说一个我自己的判断随着每个团队把自己的任务技能化这个技能库会逐渐长成组织最有价值的知识资产。过去我们积累知识的方式是写文档、存 wiki、录制分享视频未来可运行、可调用、可验证的技能会成为一种更高级的知识形态。文档记录的是“当时怎么做”技能记录的是“现在怎么做、怎么让机器替你做、怎么做完验证是否达标”。这并不意味着文档不再重要而是说文档会越来越多地成为技能的附属品解释设计意图、说明边界条件、记录变更历史。真正的业务处理能力将由成体系的技能库来承载。到那个时候AI-Native 组织才真正意义上“Run on Skills”了。如果你问我现在最该做什么。我的答案很朴素选一个你每周都要做、又总做不好的小任务花半天时间把它拆成输入、上下文、输出和校验再写 20 行代码让模型跑一遍然后把测试用例留下来。你不需要立刻建平台也不需要等最强模型发布。从这一个技能开始你就已经走在从“用 AI”到“运行在 AI 上”的路上了。
