最近“AI-Native”被讨论得很多但大多数内容停留在“我们用 AI 辅助写代码”“上线一个 AI 客服”“接入了几个大模型”这种单点应用层面。真正让一家公司从“用 AI”变成“AI-Native”核心不在于买了多少模型、接了多少 Agent而在于把组织里的工作方式拆解成可复用、可组合、可度量的“技能”Skills再围绕技能去重构流程、团队和工具链。这次的题目是 AI-Native Organisations Run on Skills重点回答两个问题技能怎么结构化技能怎么规模化。如果只记一个结论那就是在 AI-Native 组织里技能是比项目和岗位更稳定的基本单元。项目会结束岗位会调整但一个经过验证的技能可以长期沉淀、跨团队复用。对应的落地参考是 the ai-native sdlc playbook——它不是某一款软件而是一套把 AI 能力嵌入软件研发全生命周期的方法论。它把“发现需求、设计接口、实现能力、测试质量、部署上线、持续观测”这套软件工程动作从“开发一个系统”下沉到“开发一个技能”。这篇文章会从概念讲清楚什么是技能再给出一套可以落地的技能结构、生命周期、组织协同、平台化和度量方法。适合正在搭建 AI 平台、做 Agent 研发、规划研发效能或负责企业 AI 落地的技术负责人和架构师。文章不绑定具体产品重点是一套可以直接拿到团队里讨论和试点的框架。1. 核心概念速览先给一张速览表把文章的讨论范围固定下来。维度说明组织形态以技能注册表Skill Registry为底座围绕技能组织研发、运维和业务能力核心单元Skills可复用、可组合、可版本化、可观测的 AI 能力单元流程方法AI-Native SDLC Playbook覆盖发现、设计、实现、测试、部署、监控、退役全生命周期基础设施技能目录、技能运行时、评测数据集、观测与权限控制适用对象平台工程团队、AI 产品团队、企业架构师、研发效能团队、AI Agent 团队规模化路径从高频任务试点 → 目录沉淀 → 跨团队复用 → 平台化运营主要风险技能质量不稳定、重复建设、成本失控、权限边界模糊、依赖关系混乱这张表要表达的核心意思是AI-Native 不是“模型原生”而是“流程原生”。模型只是运行时的一部分技能才是被管理的对象。组织的 AI 能力演进本质上是在持续积累一批高质量、接口稳定、可以互相组合的技能。从实操角度看搭建这套体系不需要一步到位。可以先定义技能规范、建一个简单的技能目录、跑通两三个高频业务技能再逐步把生命周期和平台能力补上。比起“上一套 Agent 平台”先梳理技能结构更便宜也更不容易翻车。2. 为什么“技能”是 AI-Native 组织的基本单元传统组织里能力被封装在项目、系统和岗位里。要做一件事先排期、立项、招人、写代码、上线做完之后能力留在系统里但系统和业务的变化往往不同步。AI-Native 组织把能力进一步解耦把一段可重复执行的工作抽象成一个技能技能内部可以使用模型、提示词、工具、知识库和代码对外只暴露稳定的输入输出接口。从这个角度看技能的定位介于“提示词模板”和“完整应用”之间。它比提示词模板更工程化有版本、有测试、有 owner、有调用约束它比完整应用更轻不需要独立的前端、独立的发布节奏可以通过目录和运行时被任意业务系统调用。一个技能必须符合几个基本条件。第一是职责单一。一个技能只解决一个问题例如“抽取合同关键字段”“把需求文档转成用户故事”“把会议录音整理成会议纪要”而不是把多个无关能力塞在一起。职责单一才能保证测试集有效才能让复用变得容易。第二是接口明确。输入是什么、输出是什么、异常怎么返回都要写清楚。接口是技能之间组合的基础也是技能作为组织资产可以被他人消费的前提。第三是可验证。技能必须有一组固定的测试用例和明确的成功标准。没有验证的技能只能算实验不能进入目录。第四是有归属。每个技能都要有 owner负责质量、迭代和退出。没有 owner 的技能会像没有维护人的开源项目一样慢慢腐烂。在组织层面项目是临时的技能是长期的。项目结束时人员解散、代码归档但通过项目沉淀下来的技能可以继续留在目录里成为组织的能力底盘。组织对 AI 的投入从“交付一个系统”转为“沉淀一批技能”这是 AI-Native 组织与传统组织最本质的区别。3. 适用场景与使用边界这套方法适合的团队和场景可以从三个角度来判断。从团队类型看适合有平台工程或研发效能性质的团队。平台团队负责制定技能规范、搭建技能目录和运行时业务团队负责提出需求和消费技能两侧各司其职。如果团队规模很小、只有几个人在做 AI 实验可以先不搭平台用一套目录规范和代码仓库管理技能等规模变大再补工具。从业务场景看适合那些重复度高、流程相对稳定、可以被清晰描述的任务。例如客服工单分类、文档解析、代码审查、测试用例生成、数据分析、周报提炼。这类任务需求明确、结果可验证是技能化的首选。反之高度依赖人际判断、目标模糊、结果难以定义的任务不适合强行技能化。从问题类型看如果组织当前的问题是“每个人都在重复造提示词”“Agent 能力无法沉淀”“AI 项目结束后能力丢失”就非常需要技能化。如果当前的问题是“还找不到合适的模型”“业务没有明确需求”那应该先解决需求和选型技能化是后一步的事。使用边界也必须说清楚。技能化会涉及数据流转、模型调用、权限设计这里有几个底线。第一数据合规。技能处理的数据如果包含个人隐私、客户信息或内部敏感数据必须遵守所在地区的数据保护要求。技能示例、测试集、训练语料都不能包含未经脱敏的真实个人信息。第二版权与授权。技能引用的模型、工具、代码、知识库素材都要确认授权范围。对外发布或商用前一定要重新检查素材来源。第三安全边界。技能能访问什么系统、能调用什么工具、能读取哪些数据必须按最小权限设计。AI-Native 组织里技能是高频、自动被调用的权限一旦过宽风险会被放大。第四责任边界。技能的输出不能直接用于高风险决策例如医疗诊断、金融风控、法律意见。如果业务上必须用要保留人工复核环节并在技能设计阶段定义清楚输出责任归属。4. 技能结构设计一个技能应该包含什么要让技能可管理、可复用第一步是定义一个统一的技能结构。下面是一份建议的 YAML 技能定义模板实际落地时需要按团队情况调整字段。# skill-example.yaml version: 1.0.0 name: doc-extractor display_name: 文档结构抽取 owner:>import json def run_eval(skill_api, golden_path): with open(golden_path, r, encodingutf-8) as f: cases [json.loads(line) for line in f if line.strip()] pass_count 0 for case in cases: result skill_api(case[input]) if result.get(output) case[expected]: pass_count 1 success_rate pass_count / len(cases) if cases else 0.0 print(fsuccess_rate{success_rate:.2f}, pass{pass_count}/{len(cases)}) return success_rate这只是演示逻辑实际项目里需要按技能接口调整调用方式和比对规则。重点是发布前必须跑一遍测试集成功率达标才能进目录。5.4 部署与发布技能部署不是简单发布一个提示词而是要注册到技能目录、创建调用端点、配置权限和限流然后以小范围灰度开始。灰度阶段只允许试点团队调用观察一段时间再扩大到全组织。发布动作建议做成自动化代码提交触发测试测试通过后打版本号、更新目录、部署运行环境。如果组织还没有发布流水线至少也要保证“每个版本都能回滚到上一个稳定版本”。5.5 监控与迭代技能上线后要持续观测调用量、成功率、延迟、成本和失败原因。监控数据要按技能维度汇总而不是只按模型维度。如果某个技能成功率下降可能是上游数据变化、模型版本更新或输入分布偏移。迭代不能只靠监控数据被动响应。建议每个技能 owner 定期 review golden_dataset把新出现的失败案例补充进测试集。测试集是技能质量的护栏它不是一次建完就结束而是随着真实使用不断生长的。5.6 退役与合并技能也有生命周期终点。当某个技能长期没有调用、功能被其他技能覆盖、或者业务场景不再存在就应该走退役流程。退役前要通知所有消费者给出替代技能和迁移建议保留一段时间的过渡期。目录里堆满失效技能会让检索变得困难最终导致整个目录没人信任。6. 组织协同谁拥有技能、怎么共享技能化不只是技术问题更是组织问题。一个技能要持续存活必须有人在业务和技术之间做翻译有平台团队负责基础设施有质量团队负责把关。建议在组织里定义几个角色。技能所有者Skill Owner通常是对业务最熟悉的工程师或产品经理负责技能的目标定义、迭代节奏和最终质量。技能所有者不一定要自己写全部代码但必须对技能结果负责。领域专家负责提供业务知识和测试样本。例如一个合同审核技能需要法务同事帮忙标注典型错误案例一个需求拆解技能需要资深产品经理提供高质量拆解样例。领域专家的价值体现在 golden_dataset 的质量上。平台工程师负责技能目录、运行时、权限、限流、观测这些横向能力。平台团队不直接交付业务技能而是让业务团队能够自助发布和消费技能。组织协同的关键是“集中治理、分散建设”。技能规范、目录结构、质量门槛、安全要求由平台团队统一制定技能的具体建设由业务团队分散完成。这样既能保证一致性又能让贴近业务的人来决定怎么做最合适。跨团队共享需要一个技能评审机制。技能进入正式目录之前建议经过一次评审接口是否清晰、测试集是否充分、owner 是否落实、权限是否合理。评审不是行政审批目的是在早期发现问题避免不成熟技能被大量消费后反噬信任感。7. 平台化与规模化技能注册表、运行时与接口技能规模达到几十个之后靠文档管理和手工调用是不现实的必须引入平台能力。一个最小可用的技能平台通常包含四层。第一层是技能注册表。注册表保存所有技能的元信息、版本、状态、owner、依赖关系和接口说明。它既是开发者的技能搜索引擎也是平台自动化的数据源。技能目录建议按业务域分类同时维护标签体系例如“文档处理”“代码生成”“数据分析”“客服场景”。第二层是技能运行时。运行时负责加载技能定义、调用模型和工具、执行提示词逻辑、处理重试和超时。技能运行时需要支持两种执行模式同步调用适合交互式场景例如用户在对话框里触发总结异步批量调用适合离线处理例如批量抽取上个月所有工单的关键字段。第三层是权限与治理。每个技能绑定独立的访问凭证和权限范围。技能能访问哪些存储、调用哪些外部 API、读取哪些数据表都要显式声明。默认建议是最小权限不要因为方便把所有技能都接到同一个宽权限服务账号下。第四层是观测与成本。调用日志、token 用量、延迟、错误码、成功率要按技能维度记录。成本要精确到每次调用、每个输入大小否则技能数量上来之后很难控制开销。接口调用是技能被外部消费的主要方式。下面是一个通用的同步调用示例实际路径和参数需要按项目接口调整curl -X POST http://skill-platform.internal/skills/doc-extractor \ -H Content-Type: application/json \ -H Authorization: Bearer token \ -d { version: 1.0.0, input: { file_url: https://your-storage/doc.pdf, page_range: 1-10 } }对应的 Python 调用模板import requests SKILL_ENDPOINT http://skill-platform.internal/skills/doc-extractor payload { version: 1.0.0, input: { file_url: https://your-storage/doc.pdf, page_range: 1-10 } } resp requests.post(SKILL_ENDPOINT, jsonpayload, timeout120) data resp.json() print(data[output][markdown])响应建议统一结构方便消费方解析{ status: success, output: { markdown: # 标题\n\n正文内容..., page_count: 10 }, usage: { input_tokens: 1234, output_tokens: 567 }, latency_ms: 3200 }批量任务是技能平台上高频出现的使用方式。例如把一批 PDF 全部转成结构化 Markdown、把过去一个季度的客服记录全部打上标签。批量任务建议走异步队列而不是同步长连接。任务拆分成 jsonl 或数据库待处理表由 worker 逐条消费失败自动重试最终输出结果文件和失败原因。参考批量脚本模板import json import time import requests BATCH_FILE ./tasks.jsonl SKILL_ENDPOINT http://skill-platform.internal/skills/doc-extractor MAX_RETRY 3 def run_batch(): with open(BATCH_FILE, r, encodingutf-8) as f: tasks [json.loads(line) for line in f if line.strip()] results [] for task in tasks: for attempt in range(MAX_RETRY): try: resp requests.post(SKILL_ENDPOINT, jsontask, timeout180) resp.raise_for_status() results.append({ task_id: task.get(task_id), status: success, data: resp.json() }) break except Exception as exc: if attempt MAX_RETRY - 1: results.append({ task_id: task.get(task_id), status: failed, error: str(exc) }) time.sleep(2 ** attempt) return results if __name__ __main__: print(json.dumps(run_batch(), ensure_asciiFalse, indent2))批量脚本要注意几点任务文件要包含 task_id 用于追踪重试要用指数退避避免集中重试打挂服务失败任务要保留原始输入和错误信息方便事后修复再补跑。更成熟的方案是用消息队列加 worker但小规模场景先用脚本也能跑通。8. 效果度量与验证方法技能体系是否在产生价值不能被“建了多少技能”这种虚荣指标带偏要看复用率、覆盖率和质量稳定性。指标计算方式监控频率用途技能复用率被多个团队/业务线使用的技能数 / 技能总数每周判断技能目录是否在产生共享价值采纳覆盖率高频任务中被技能执行的比例每月判断技能是否切入核心流程任务成功率成功完成数 / 总调用次数每天判断技能质量稳定性单次成本模型调用成本 token 成本 存储成本每天成本控制平均延迟请求响应的 p50 / p95每天性能监控质量评分人工抽检或 golden dataset 准确率每次发布质量门槛技术验证的核心是 golden dataset 和 A/B 测试。每次技能发布前都要在固定测试集上跑回归。出现新失败案例就补充到测试集里让测试集伴随真实场景持续生长。A/B 测试用于模型切换和提示词优化。例如把一个技能的模型从 A 换成 B可以先让 10% 的流量走新模型对比成功率和成本再决定是否全量切换。切模型之前必须跑一遍 golden dataset把两个模型的测试集表现同时输出对比避免线上灰度翻车。成本验证同样重要。AI-Native 组织里的成本是按 token 计算的技能数量上去之后成本会呈非线性增长。建议给每个技能设置月度成本预算定期检查单次调用成本高的技能看是否能通过缓存、分块、降低模型规格或压缩输入来优化。成本控制不是一刀切限制使用而是让每一块钱花在明确的业务结果上。9. 常见问题与排查方法技能体系在落地过程中会遇到一批典型问题下面整理成排查表方便直接对照。问题现象可能原因排查方式解决方案技能建了一堆但没人用与真实业务链路脱节缺少消费入口查看调用日志和目录检索记录优先把技能接入现有工具入口找到真实场景再建设技能质量时好时坏提示词不稳定、模型版本漂移、测试集缺失跑 golden dataset对比不同版本的输出固定模型版本完善测试集发布前强制回归技能重复建设缺少目录发现和检索能力检查注册表名称、标签和重复定义建立命名规范、标签体系和技能评审机制成本快速上升长文本频繁调用、没有缓存、并发过高按技能维度查 token 用量和调用次数增加缓存、分块处理、限制并发按场景降模型规格权限越界技能可访问范围过大服务账号权限过宽审计技能运行时使用的凭证和数据权限按最小权限原则配置定期做权限复核批量任务卡住外部 API 超时、模型限流、任务无超时控制查看任务队列和依赖服务日志增加超时、指数退避重试和死信队列技能接口频繁变更接口定义阶段没考虑兼容性查看版本记录和调用方反馈采用语义化版本主版本变更走兼容性评审模型换新后结果变差新模型输出分布与旧测试集不匹配对比新旧模型在 golden dataset 上的表现切换前先跑 A/B 测试必要时保留旧模型版本这些问题的共同根源通常是技能建设少了“工程化”这一环。把测试集、版本、owner、权限和观测补齐大部分问题会在早期暴露而不是等到被大量消费之后才爆发。10. 最佳实践与落地建议结合前面的内容给出一些可以直接执行的工程化建议。第一先小规模试点。不要一开始就建完整的技能平台先选 5 到 10 个高频任务做技能化用一套目录规范和代码仓库管理起来验证流程跑通后再考虑平台建设。第二接口先行。每个技能先写清楚输入输出和成功标准再动手写实现。接口不清晰后面的测试、复用、评测全部会乱。第三测试集是底线。没有 golden dataset 的技能不进目录。测试集要包含正常用例和边界用例并且持续补充真实失败案例。第四技能文件和模型版本要纳入版本管理。提示词、配置、依赖、代码都放在同一个仓库里发布时打标签确保任何版本都可以回溯。第五目录要治理。技能命名、标签、分类、owner 信息必须规范。目录里不要堆积失效技能定期清理和合并。第六权限按最小化原则设计。技能能访问什么、能调用什么都要显式声明。涉及用户隐私、版权素材、敏感数据的技能必须经过合规评审。第七成本要按技能维度透明化。每次调用的成本、每个月的总量成本都要能查到让每个技能 owner 对自己的成本负责。第八对高风险场景保留人工复核。医疗、金融、法律等领域的输出不能直接自动生效技能设计阶段就要定义复核节点和责任边界。第九定期做效果复盘。建议每月复盘一次技能目录的调用数据季度做一次技能生命周期健康度检查停用无效技能合并重复技能补充高价值技能。11. 总结与下一步AI-Native 组织真正值得先做的不是立刻采购更多模型、也不是搭建一个庞大的 Agent 平台而是定义清楚“技能”这个基本单元然后把技能的发现、设计、实现、测试、部署、监控、退役全流程跑通。组织能力沉淀的最小单位不是项目而是可以被反复调用的技能。如果你想在自己的团队里开始建议从周一做三件事第一找出当前团队最高频的三个重复性任务第二为其中一个任务编写技能定义 YAML明确 owner、接口和 golden dataset第三用最小方式部署并接入现有工具入口观察一周的调用数据。三周之后你就能判断这套方法适不适合自己的组织。最容易踩的坑是跳过测试集直接上线或者让技能散落在各个团队的聊天记录和个人脚本里。技能一旦脱离目录和版本管理很快会变成新的信息孤岛。先从一个技能跑通闭环再逐步扩展比一开始就铺大摊子要稳妥得多。等技能数量多起来再补注册表、运行时、权限和成本观测AI-Native 的组织形态就会自然生长出来。