AI 技能正在变成软件，需要工程化治理

我们开始把 AI Skill 当作软件来对待了。

但我们仍在用管理提示词的方式管理它们。

这种错位在小规模下很容易被忽视——当一个开发者只有几个本地的指令文件时。但当 Skill 在团队间共享、被多个 Agent 运行时加载、并被信任来指导那些能读取代码库、执行命令或修改生产系统的工具时，错位的代价就开始显现了。

一个可复用的 Skill 不再只是一段文本。它有接口、有依赖、有兼容性假设、有失败模式，还有影响范围。它会过时。它会与其他 Skill 冲突。它在一个运行时上能用，在另一个运行时上却会静默失败。

换句话说，它的行为开始像一个软件制品了。

而软件制品需要治理。

提示词模型在团队规模下失效

几乎所有 Agent 工作流的第一版都是一个提示词：解释任务、添加几个例子、让模型遵守规则。

然后提示词就膨胀了。架构约定被追加上去。安全警告越堆越多。工具特定的语法出现了。第二位开发者复制了一份并做了小改动。另一个团队创建了一个"更干净"的版本。六个月后，没人知道哪一份是权威版本。

这主要不是上下文窗口的问题。这是一个生命周期问题。

模型仍然可以概率性地执行这些指令。但围绕这些指令的资产不必处于无人管理的状态。

什么让一个 Skill 成为软件制品？

不是每个提示词都值得一个发布流程。边界是复用加上后果。

当一个 Skill 符合以下条件时，它就跨越了那条边界：

• 能够反复工作，而非一次性；
• 能够从自然语言意图中被发现并激活；
• 能够协调工具、脚本、文件或子 Agent；
• 能够在不同项目或运行时间保持一致的行为；
• 能够由多个人维护；或
• 能够产生失败后影响重大的变更。

到了这个地步，这个 Skill 就有了软件般的属性：

接口。它的名称和描述决定了 Agent 何时选择它。它的输入、输出和验证步骤构成了一份契约。

依赖。它可能依赖工具、MCP 服务器、脚本、引用文件或其他 Skill。

兼容性。宿主特定的字段和能力可能在 Claude Code、GitHub Copilot、Cursor、Codex 和 Gemini CLI 之间产生不同的行为。

质量属性。清晰度、完整性、特异性、可发现性、可测试性、可移植性和安全性都可以被评估。

风险。指令可以规范化破坏性命令、暴露凭证路径、信任恶意内容，或将无害的 Unicode 字符隐藏在行为背后。

把文件称为"Markdown"并不能消除这些属性。

治理不是官僚主义

治理通常听起来像是有一个委员会挡在工程师和有用工作之间。这不是我说的那种模式。

对于 Skill 来说，治理是一小组答案：

• 我们有哪些资产？
• 每个资产承诺了什么契约？
• 它支持哪些运行时和依赖？
• 在分享之前需要什么证据？
• 什么应该阻止一个变更，什么应该仅发出警告？
• 我们如何安全地升级、弃用和移除它？

好的治理让安全的路径成为简单的路径。它给作者一个标准，给审查者一个共享词汇表，给 CI 一个确定性的基线。

目标不是让每次编辑都变慢，而是让生命周期变得可见。

记忆是症状，不是产品

我走上这条路，始于一个 AI 结对编程工具——它总是在会话之间丢失项目上下文：架构决策、命名约定、测试期望，以及早期选择背后的原因。

我的第一反应是写一个更大的指令文件。

那有帮助——直到它不再有帮助。文件变得难以导航、难以验证，而且越来越偏向某个特定工具。更深层的问题不是模型需要一个更大的记忆。项目知识需要结构。

我不再要求 Agent 记住一切，而是开始将有边界的流程打包成 Skill：可发现、可复用、有版本、可审查、可移植。

记忆问题导致了架构。治理成为了产品。

一个具体实验：Skill Governance Toolkit

我构建了开源的 Skill Governance Toolkit 作为这种方法的一个参考实现。

它使用一个规范的 skills/ 目录和一个共享的 AGENTS.md 作为项目规则源，同时为 Claude Code、GitHub Copilot、Cursor、OpenAI Codex CLI 和 Google Gemini CLI 打包了相同的六个核心元 Skill。

这些元 Skill 覆盖了一个实用的生命周期：

• 在创建另一个 Skill 之前先找到一个存在的；
• 从九个质量维度评估一个 Skill；
• 比较本地版本和公司版本；
• 审计一个库的系统性问题；
• 将宿主特定的 Skill 转换为可移植的；和
• 初始化可选的集成。

该仓库还包括一个确定性的、只读的审计引擎。同样的检查可以通过 CLI 在本地或 CI 中运行，通过 MCP 交互式运行，或在锁定的 Docker 容器内运行。一个"仅变更"门可以阻止新引入的高严重性发现，而不必强制团队先修复所有历史债务。

这个区别很重要：

• 确定性检查处理可复现的事实，如格式错误的 front matter、不安全的 shell 模式、隐藏字符、硬编码路径和缺失的契约；
• 模型辅助评估处理语义问题，如指令是否清晰、例子是否有用的、触发短语是否可发现。

治理需要两者兼有。让 LLM 做每一个安全决策会产生递归信任。让词法扫描器判断清晰度会产生虚假自信。

我们应该在审查中问的问题

一旦我们把 Skill 视为软件，审查就变了。"这个提示词看起来好吗？"太弱了。

• 它的激活边界是否足够具体以避免冲突？
• 它是否说明了它将做什么和不会做什么？
• 输入、输出和完成标准是否明确？
• 它能否在没有某个供应商私有 front matter 的情况下运行？
• 所需的脚本和 MCP 服务器是否已声明？
• 一个变更工作流是否预览变更并支持恢复？
• 不可信的内容是否可能被误认为是指令？
• 在中断、重试或部分失败时会发生什么？

这些都是普通的工程问题。这正是关键所在。

提示词工程问的是：如何措辞才能让模型遵守这条指令？

Skill 工程问的是：如何设计、验证、分发和演进这个能力，让团队能够依赖它？

我们将继续编写提示词。但那些可复用的正在变成更重要的东西：人类意图、模型行为和可执行工具之间的接口。

较早认识到这一转变的团队不会仅仅拥有更好的提示词。他们将拥有一个可维护的能力系统。

Next: Part 2 — Designing a Governance Layer for AI Skills examines the architecture: instruction layers, deterministic and semantic checks, portability, CI policy, and safe adoption.

AI Skills Are Becoming Software. They Need Governance. (this article)

Designing a Governance Layer for AI Skills

AI Skills Are Executable Assets. Let's Review Them Like Code.

该工具包是开源的，采用 MIT 许可：github.com/artemrudenko/skill-governance-toolkit。

你的团队今天是如何审查和维护可复用的 Agent 指令的？