1. 引言
在传统软件工程中，代码是最小的可执行单元。
在 AI 时代，这个假设正在改变。
我们用自然语言描述逻辑，通过模型执行任务，以提示词作为接口。
但这引出了一个更深层的问题：
如果知识可以被执行，知识本身是否也需要重新设计？
这引出了一个新的抽象：
Skill —— 可执行的知识单元
2. 传统知识的问题
传统知识本质上是不可执行的：
- 文档能解释，但不能行动
- 经验能指导，但无法系统性复用
- 提示词能辅助，但零散且脆弱
由此导致：
- 知识无法规模化
- 系统依赖个人
- 工作流无法自动化
知识存在，但没有被运营化。
3. 转变：知识变得可执行
大语言模型带来了根本性的转变：
- 自然语言成为执行接口
- 提示词成为可编程指令
- 人类推理变得部分可自动化
知识第一次可以被直接执行。
这要求我们用新的方式来组织知识。
4. 什么是 Skill？
Skill 是一个可复用、可执行的单元，具备：
- 结构化输入
- 定义明确的输出
- 基于提示词的执行逻辑
- 验证约束
可以形式化为：
Skill = 类型化函数 + LLM 执行
5. Skill 与 Prompt 的区别
这个区分至关重要：
| 概念 | 角色 |
|---|---|
| Prompt | 实现细节 |
| Skill | 系统级抽象 |
Prompt 是写给模型的。
Skill 是为系统设计的。
6. 最小 Skill 结构
一个 Skill 至少包含四个要素：
- 类型化的输入定义
- 类型化的输出定义
- 执行用的 Prompt
- 一个可调用的
run方法
7. 组合：从 Skill 到工作流
Skill 不孤立使用，而是被串联成工作流。例如一个功能开发流程可以依次调用：需求结构化 → 任务拆解 → 代码生成 → 代码审查，每一步的输出作为下一步的输入。
Skill = 执行单元
工作流 = Skill 的组合
失败传播问题
串联结构带来一个关键风险：上游 Skill 的错误会被下游 Skill 当作合法输入处理，错误被放大而非拦截。结构验证只能发现格式错误，语义错误（输出结构正确但含义偏差）会静默通过。
典型模式：上游需求结构化 Skill 输出了语义偏移的需求描述，下游代码生成 Skill 基于它生成了逻辑完整但功能错误的代码，审查 Skill 验证代码实现了”需求”——每一步单独看都通过了，但最终结果是错的。
应对方式：在工作流的关键节点设置语义校验屏障，而不只是结构校验：
– 高风险节点（需求确认、架构决策）：人工在此停下确认，再继续下游
– 中风险节点（代码逻辑、接口设计）：另一个 Skill 做独立语义审查，而不是直接传递
– 低风险节点（格式转换、文档生成）：结构验证 + 自动重试即可
工作流的可靠性不取决于最强的 Skill，而取决于最薄弱的校验节点。
8. 处理不确定性
与传统函数不同，Skill 是概率性的。这是 AI 工程与传统软件工程最本质的差异。
核心失效模式：
- 输出不稳定 —— 相同输入在不同次运行中可能产生不同输出
- 语义漂移 —— 提示词版本更新或模型升级后，含义悄悄偏移
- 幻觉 —— 输出听起来合理但实际错误，当审阅者缺乏领域知识时最难发现
这些不是一次性可修复的 bug，而是执行环境的固有属性，必须在工程层面持续应对。
应对方案：
- 结构验证 —— 拒绝不符合预期结构的输出
- 重试机制 —— 验证失败时重新执行，而非直接报错
- 自我优化 —— 让模型批判并修正自身输出
- 多样本共识 —— 运行 N 次，取多数或最优验证结果
AI 系统的可靠性是工程设计出来的，不是假设出来的。
9. 版本管理与评估
Skill 必须作为版本化资产管理，每个版本记录名称、版本号及核心指标。
核心指标：
- 准确率
- 稳定性
- 成本
Skill 不是静态的——它需要持续演进和度量。
10. 哪些知识应该成为 Skill？
不是所有知识都值得转化。一个实用的判断规则：
Skill = 高频 + 可标准化 + 可验证
逐条判断：
| 条件 | 需要回答的问题 |
|---|---|
| 高频 | 这个任务是否足够频繁，使自动化成本值得投入？ |
| 可标准化 | 能否清晰定义成功标准，使其能被写成 Schema 和 Prompt？ |
| 可验证 | 输出质量能否被代码、审阅者或另一个 Skill 检验？ |
任何一个条件不满足，就将知识保留为文档或指南。将低频或难以验证的知识强行变成 Skill，只会增加复杂度而没有收益。
11. 系统架构
Skill 存在于分层系统中：
原则（Principles）
↓
领域知识（Domain Knowledge）
├── 产品需求：这个版本要做什么
├── 工程规约：怎么改才不会出问题
└── 领域规约：行业和项目的规则是什么
↓
工作流（Workflow / 编排）
↓
Skill（执行单元）
↓
Prompt（实现细节）
关键洞察：
LLM 不是系统。
Skill 才是系统的最小可执行单元。
领域知识决定 Skill 的执行边界，详见02-design/domain-knowledge-layer.md。
12. 对组织的影响
之前
- 工作分配给人
- 知识存储在文档中
- 执行依赖掌握知识的个人，手动完成
之后
- 工作变成能力调用——任务被分派给 Skill，而不是某个人
- 知识被结构化沉淀——进入领域知识层，对所有 Skill 可见，不再依赖个人记忆
- 执行逻辑封装为 Skill——可复用、可版本化、可度量
这个转变改变了团队设计方式。能力驱动的团队问的是：我们需要哪些 Skill？ 而不是 这件事谁来做？ 个人的工作重心从执行重复任务，转向定义、优化和组合 Skill。
团队从以人驱动演进为以能力驱动的系统。
13. 结论
软件工程正在经历根本性的转变：
- 从编写代码 → 设计能力
- 从确定性执行 → 概率性系统
在传统系统中，函数封装逻辑；在 AI 系统中，Skill 封装能力。
如果知识没有被转化为可执行单元，AI 系统就无法超越个人使用的规模。
Skill 是让知识可编程、可组合、可规模化的桥梁。