🧩 很多时候我们会把 Steering、system prompt 和 skill 混着说，但它们其实不是同一层的东西。 如果把它们混为一谈，就很难真正理解一个 AI 代理为什么会那样行动。

Steering、System Prompt 与 Skill：三层约束到底有什么区别

在和 AI 代理协作时，人们经常会问一个问题：为什么模型会这样回答、这样做事、这样调用工具？

表面上看，很多行为都像是“模型自己决定的”；但实际上，模型的行为通常同时受到多层约束。Steering、system prompt 和 skill 正是这几层约束里最容易混淆、但也最重要的三个概念。

如果想真正理解一个 AI 代理的工作方式，最好的方法不是问“它是怎么想的”，而是先问：它当前受到哪些层级的约束，这些约束各自负责什么。

先说结论

可以先用一句话分别概括它们：

• Steering：一个总称，指所有用来引导模型行为、决策方向和风格的机制
• system prompt：最高优先级的全局行为规则，决定模型在当前会话里的大边界
• skill：面向某类任务的局部工作流与最佳实践，用来约束具体任务该怎么做更稳 也就是说，Steering 不是和另外两个并列的“第三种东西”，而更像是一个上位概念。system prompt 和 skill 都可以看成 Steering 的具体表现形式。

什么是 Steering

Steering 更像一个概念框架，而不是某一段固定文本。

只要一个机制能够影响模型的行为方向、判断标准、执行顺序或者表达方式，它都可以被看作是在“steer”这个模型。

常见的 steering 来源包括：

• 系统级规则
• 开发者指令
• task-specific skill
• 用户当前给出的限制条件
• 工具本身的调用契约 所以当我们说“这个代理被 steering 了”，真正的意思通常是：它不是在完全自由地响应，而是在多个引导层的共同约束下行动。

什么是 System Prompt

system prompt 是最接近“总规则”的那一层。

它通常负责决定：

• 模型的基本角色
• 哪些行为允许，哪些行为不允许
• 何时必须调用工具
• 何时必须先验证信息
• 回答的格式、风格和安全边界 这类规则往往是全局的，而且优先级很高。只要当前会话没有被新的更高层规则覆盖，它就会持续生效。

从作用上看，system prompt 更像是这个代理的“操作系统”或“运行环境说明书”。它不告诉模型某一篇文章该怎么写得更漂亮，但它会规定模型在什么情况下可以写、什么时候必须先查、怎么引用、怎么做风险控制。

什么是 Skill

skill 更像是一个面向具体任务的操作手册。

它不会接管整个会话，而是在某种任务被触发时生效，比如：

• 在 Figma 里创建 UI

• 把设计转成代码

• 往 Notion 数据库里写结构化文档

• 创建 design system 规则 一个 skill 通常会包含：

• 适用场景

• 推荐工具链

• 建议的执行顺序

• 常见坑点

• 需要读取的参考文档或脚本

• 在这个任务下什么叫“做对了” 所以 skill 的重点不是“告诉模型世界观”，而是“告诉模型在这个任务上应该怎么落地”。

三者的核心区别

最重要的区别，可以从三个维度看：范围、稳定性、粒度。

1. 范围不同

• system prompt 影响整个会话
• skill 只影响某一类任务
• Steering 是对所有这些引导机制的统称

2. 稳定性不同

• system prompt 相对稳定，通常从会话开始就存在
• skill 是按需触发的，不是每一轮都会用到
• Steering 本身不是单个固定对象，因此谈不上单一稳定性

3. 粒度不同

• system prompt 管的是原则和边界
• skill 管的是具体流程和方法
• Steering 管的是“所有会让模型朝某个方向走的东西”这个总集合

为什么它们容易被混淆

因为从外部看，这三者都会改变模型的输出。

当一个代理回答得更谨慎、更结构化、更像某个专业角色时，我们很容易把这一切都笼统地归因于某一个“prompt”。但事实上，常见情况是：

• 风格由系统级规则决定
• 工作顺序由 skill 决定
• 具体任务边界由用户请求决定
• 是否能真的执行，还要受工具契约限制 也就是说，最终看到的行为往往是多层约束叠加后的结果，而不是某一条 prompt 单独造成的结果。

用一个直观比喻来理解

如果把 AI 代理看成一个团队成员：

• system prompt 像公司的总制度与岗位职责

• skill 像某个具体岗位的 SOP 或作业手册

• Steering 则像所有影响这个人工作方式的管理机制总和 这个比喻的关键在于：

• 公司制度不会告诉你某个按钮应该离输入框多远

• 但它会规定你做事要不要先验证、是否要遵循安全要求

• SOP 不会定义你是谁，但会告诉你遇到某类任务时该按什么顺序完成

在实际任务里，它们是怎么一起工作的

以 Figma 创建移动端 UI 为例：

• system prompt 会约束模型必须遵守工具规则、及时验证结果、不要乱猜

• skill 会约束模型先读 page、检查字体、确认 design system、决定是否先建 wrapper、是否截图验收

• 用户请求会进一步限定：是做流程稿、还是做高保真交付稿，是否要加 Status Bar 和 Home Indicator 所以最后看到的行为，不是单纯“模型会不会设计”，而是：

• 它被允许做什么

• 它被要求先做什么

• 它在这个任务里应该遵循什么工作流

一个更准确的理解方式

如果必须用一句更准确的话来概括三者关系，可以这样说：

Steering 是总称，system prompt 是全局规则层，skill 是任务工作流层。

这句话的价值在于，它把三者放回了正确的位置上：

• Steering 解决“有哪些东西在引导模型”
• system prompt 解决“模型整体该怎么表现”
• skill 解决“这个具体任务该怎么执行”

结语

当我们开始把 Steering、system prompt 和 skill 区分开，很多原本模糊的问题会突然变得清楚。

模型不是单靠一段 prompt 在工作，而是在多层约束下运行：有全局边界，有任务手册，也有当下用户给出的目标和限制。理解这些层级，不只是为了分析 AI 为什么这样做，更是为了在需要的时候，知道应该修改哪一层，才能真正改变它的行为。