> For the complete documentation index, see [llms.txt](https://zhouhao4221.gitbook.io/haiqing-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://zhouhao4221.gitbook.io/haiqing-docs/01-thinking/skill-oriented-knowledge.md).

# 面向技能的知识：从描述到执行

## 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 是让知识可编程、可组合、可规模化的桥梁。


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://zhouhao4221.gitbook.io/haiqing-docs/01-thinking/skill-oriented-knowledge.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.