Snowflake CoCo 上线技能共享与治理：让 SKILL.md 从个人文件夹变成团队资产
Snowflake 的智能体助手 CoCo 新增了技能与插件共享能力（预览阶段），可将个人编写的 SKILL.md 转化为账户级、可版本管理、可授权治理的 SQL 对象。本文拆解技能与插件的区别、三种对象层次的划分，以及编写、共享、发现、认证这一完整生命周期背后的实际 SQL 操作。对正在用 AI 编程工具沉淀团队工作流的开发者来说，这相当于给“氛围编程”产物补上了一套分发与治理机制。
从个人技能到团队资产
用过 CoCo（Snowflake 的智能体 AI 助手，原名 Cortex Code）的人，多半写过一两个 SKILL.md 文件。这类文件本质上是一份可复用的操作指南，用来教会智能体完成某个特定且可重复的任务，比如核对 Snowflake 成本报告，或者生成每周的高管业务指标摘要。
问题在于：写好之后怎么维护、怎么让更多同事用上，一直很麻烦。
现在这个缺口由新推出的技能与插件共享功能补上。该功能目前处于预览阶段，作用是把本地技能变成账户范围内可共享、可治理、支持版本管理的对象，底层依托一种名为 Cortex Extension（Cortex 扩展）的原生 SQL 对象。用户可以通过链接分享技能，浏览别人共享出来的技能目录；拥有管理员权限的人还能对优质技能做认证，让它们带上可信标识。
本文将沿着技能的完整生命周期展开：编写、共享、发现、认证，并给出每一步实际执行的 SQL。读完不仅能理解机制，也可以照着写脚本自行实现。
技能与插件分别是什么
技能就是一份 Markdown 格式的操作指南，即 SKILL.md 文件。文件开头是一小段元数据，写明名称、描述，以及触发 CoCo 加载该技能的条件；正文则一步步指导智能体完成特定流程。写技能不需要编程，但技能可以引用需要 CoCo 执行的脚本。
CoCo 自带大量内置技能，覆盖数据治理审计、动态表故障排查、成本分析、Cortex Agent 配置等场景。这些由 Snowflake 编写维护，随产品版本走，所有用户开箱即用。
真正需要关注的是用户自己创建的技能——不写就不存在，和内置技能不同，它们必须有一套有效的分发机制。
那么，哪些任务值得封装成自定义技能？可以参考三条判断标准：
- 同一件事已经做过两次以上。 比如反复诊断计算资源消耗突增的原因、排查卡住的动态表数据处理管道、核对每月资源消耗报告。只要重复程度足够高，甚至让你在心里形成了一套固定流程，就值得封装。
- 执行过程需要判断，而不只是跑一条查询。 如果任务用固定 SQL 就能搞定，保存的工作表或视图已经够用。技能真正有价值的场景是流程中存在条件分支，比如“出现 X 就继续查 Y，Y 没问题再看 Z”——这类逻辑通常正是你带新人时要口头解释的部分。
- 它能沉淀团队里的隐性知识。 比如团队的命名规范、哪个仪表板才是权威数据源、记在便签上的业务规则。这些知识眼下可能只装在某个人的脑子里，或者散落在一段日后翻不到的 Slack 对话中。
插件是“技能与插件目录”（Skills & Plugins Catalog）支持的另一种对象类型。它本质上是一个目录，里面含一份隐藏的 .cortex-plugin/plugin.json 清单文件，可以把多个技能连同其他 CoCo 扩展能力（钩子 Hooks、MCP 服务器、自定义智能体）打包成一个可版本管理、可安装的独立单元。
如果目标不只是教会智能体跑通某一个流程，而是要封装一整套更完整的能力，就该考虑做成插件。典型做法是把若干相关技能与生命周期自动化（如 Hooks）组合起来，或者整合通过 MCP 服务器提供的外部工具和数据连接。
三个容易混淆的层次
动手之前，先分清三个概念：
- 本地技能（Local Skill）： 就是一个装着 SKILL.md 的文件夹，放在哪里都行——项目目录、用户主目录或 Snowflake 工作区。
- Cortex 扩展（Cortex Extension）： 共享技能时在 Snowflake 中创建的对象。每个共享技能或插件对应一个扩展对象，支持版本管理、基于角色的访问控制（RBAC）授权，以及可发现性设置。
- 认证（Certification）： 管理员针对扩展对象的某个特定版本授予的可信标识，含义是“这个版本经过认可”。认证和共享不是一回事：共享由用户自行完成，认证属于治理流程。
后文介绍的所有操作，都可以归入这三个层次之一。
第一步：编写技能
假设你已经花了不少时间解决一个复杂问题。整个过程中你使用的是 Snowsight 里的 CoCo，探索和交流的记录都留在 CoCo 聊天记录中。为了让 CoCo 下次只靠少量指令就能重复同样的步骤，你可以直接用自然语言让它创建一个技能，也可以点“创建技能”（Create Skill）按钮。
随后，CoCo 会调用技能创建工作流，生成对应的 SKILL.md 文件。
技能存放在哪里，决定了它的作用范围：
- 在 CoCo Desktop 或 CoCo CLI 中：把技能放在项目根目录下的
.cortex/skills//（类似.git），它只对当前项目生效；放在$HOME/.snowflake/cortex/skills//，本机上的所有项目都能使用。
不管放在哪里，这时候技能都还完全在本地。对 Snowflake 来说，它还不是任何数据库对象，只是 CoCo 从本地磁盘或工作区暂存区域读取的一个文件。
第二步：共享技能（创建 Cortex 扩展）
过去，想让别人用上自己创建的技能，通常得绕不少弯子。
现在，你只要向 CoCo 发出“共享这个技能”（share this skill）的指令，系统就会执行以下操作：
1. 为共享技能创建存储位置
CoCo 会先在你的个人数据库中查找或创建用于存放共享技能的位置。
每位用户都有一个隐式创建的 USER$ 数据库。首次共享技能时，CoCo 会在其中创建一个 SKILL_SHARING Schema，并把使用权限授予 PUBLIC 角色，让其他用户能够访问这个对象。
2. 暂存技能文件并创建 Cortex 扩展
接下来，CoCo 会暂存技能文件并创建 Cortex 扩展。
具体来说，系统会创建一个临时 Stage，把 SKILL.md 文件上传进去，然后直接基于这个 Stage 创建扩展对象。
扩展对象的名称来自 SKILL.md 文件头部元数据中的 name 字段。例如，warehouse-cost-triage 会被转换为 WAREHOUSE_COST_TRIAGE。
扩展创建完成后，临时 Stage 会立即被清理。
之后，如果你再次共享该技能（也就是提交更新后的 SKILL.md 文件），CoCo 会重新执行共享流程，上传新文件并自动递增版本号，依次生成 VERSION$2、VERSION$3 等版本。
3. 授予读取权限，使其他用户能够安装
把 READ 权限授予 PUBLIC 角色，意味着账户中的所有用户都可以安装该技能。
扩展对象的 DISCOVERABLE 属性默认设置为 TRUE，因此用户浏览技能目录时也能看到它。
如果你希望采用“仅通过共享链接访问”的方式，即允许其他用户安装，但不希望技能出现在可浏览的目录中，可以显式设置 DISCOVERABLE = FALSE。
第三步：发现技能
完成共享后，其他用户可以通过两种方式发现技能。
方式一：获取并分享链接
使用 DESCRIBE CORTEX EXTENSION 命令，可以获取一个 snow://skill_catalog/... 格式的 URI，随后将其分享给团队成员。
方式二：浏览技能目录
在 Snowsight 中，进入“AI 与机器学习”（AI & ML）→“技能与插件”（Skills & Plugins）。
点击技能旁边的“使用”（USE）按钮，就可以将该技能添加到当前聊天会话中并执行。
在 CoCo Desktop 中，也可以通过共享链接安装技能。具体路径为：
第四步：认证技能
认证可以把一个“团队成员上传的技能”升级为“获得官方认可的版本”。
通过认证的技能，会在技能目录中的各个展示位置显示绿色认证标识。
认证技能需要具备 ACCOUNTADMIN 权限。
在 Snowsight 中，进入“AI 与机器学习”（AI & ML）→“技能与插件”（Skills and Plugins），选择目标技能，然后点击“添加认证”（Add certification）。
同一页面还提供其他治理操作，例如基于角色的访问控制（RBAC）、所有权转移和删除。这些操作在底层均由 ALTER CORTEX EXTENSION 相关命令支持。
认证时，系统实际做了两件事
管理员对共享技能进行认证时，Snowflake 会执行两个操作。
1. 把技能复制到集中治理库
系统会将 Cortex 扩展从创建者的个人数据库复制到一个专门用于集中治理的数据库中。第一次执行任何治理操作时，管理员需要先选择目标数据库。由于这里是复制而非移动，原作者存放在 SKILL_SHARING Schema 中的扩展对象不会受到影响。
2. 认证针对具体版本，而非整个扩展
管理员会把某个指定版本标记为已认证。也就是说，认证的对象是版本，不是整个扩展。
如果某个 snow://skill_catalog/... 链接没有写明版本号，只要存在已认证版本，它就会解析到最新的已认证版本；只有不存在任何已认证版本时，才回退到最新版本。这样，即使原作者继续提交 VERSION$2、VERSION$3，使用者也感知不到变化：已认证的链接仍然指向 VERSION$1，直到管理员完成新版本的审核和认证。
这正是此次功能更新的关键变化。认证不再只是一次性贴上去的标签，而是一个持续的版本管理决策：由管理员独立判断哪个版本可以进入生产环境，不受原作者当前迭代进度的影响。
在团队推广前，有两点要注意
提前建好集中治理数据库。 最好事先确定用来存放已认证技能的数据库，而不是等到第一次执行认证时再临时选一个存储位置。
目前还不支持安全扫描。 该功能仍处于预览阶段，暂时无法对共享技能和插件做内容安全扫描。因此，认证代表对作者及其提交内容的信任，并不等于系统已经自动完成安全检查，管理员仍需认真审核准备认证的技能。
技能层正在变成基础设施
从更大的视角看，这一领域的发展速度值得关注。一年前，可能很少有人知道 Skill 是什么。如今，它已经成为 Snowflake 中一种支持治理、版本管理、基于角色的访问控制（RBAC，即按角色分配权限）以及独立认证流程的对象。
随着越来越多的日常工作交给智能体执行，围绕智能体构建的工具体系——包括技能、插件以及承载它们的目录——正在逐渐成为真正的基础设施，而不只是提升便利性的辅助功能。对这一层基础设施的治理，应该像生产系统的访问控制一样，被当作基础工作来做，而不是等出了问题再补。
