一篇来自国外开发者 Alice Moore编写的关于AI 辅助编程的新范式，了解这些对AI 时代的最新编程有帮助，分享记录一下：
AI 技能 (Skills) vs. 规则 (Rules) vs. 命令 (Commands)
如果你觉得你的 AI 编程工具正在成一堆装满“魔法 Markdown 文件”的文件夹，那你不是在产生错觉。
虽然不同工具的标签各异，但引起的困惑是相似的。而最近大家都在讨论的新 Markdown 文件就是 Skills（技能） ：agent在相关时可以发现并加载的上下文
让我们来看看它们究竟是什么、何时使用，以及如何构建一个既实用又易于管理的技能库
什么是 agent 技能 (Agent Skills / Claude Skills)
在 Builder（以及越来越多的供应商）中，技能采用了“Agent Skills”。你可以把它想象成存放指令和资源的“标准集装箱”
本质上，一个“skill”就是一个包含两样东西的文件夹：
- 定义文件：包含元数据和指令的 Markdown 文件
- 可选附件：任何你想要的东西，如脚本、模板或参考文档
在每个代码仓库中，技能通常位于 [.provider]/[skill-name]/SKILL.md。例如在 Builder 中，一个名为 fireworks 的技能会放在 .builder/fireworks/SKILL.md。（Builder 也能识别 .claude/ 文件夹下的技能）
最巧妙的一点是“渐进式披露”（Progressive Disclosure）。 如果你有 Web 开发背景，可以将其理解为“上下文的懒加载”
这点和人是非常类似的，知道有这个东西再进一步去查找对应的内容
agent 在会话开始时不会阅读每个技能文件。相反，它先扫描名称和描述等元数据，只有当它判定该技能与当前任务相关时，才会加载完整内容
这能让你随时调用深度专业知识，又不会强制将其塞进每一次对话中，从而避免污染模型的上下文
这种架构意味着你的编写方式需要改变：
- 描述是为了路由，而不是为了阅读：它必须简短、具体，并包含任务中实际会用到的关键词。如果描述太模糊或太文艺，AI 可能会直接忽略它
- 主体是流程，而不是维基百科：专注于检查清单（Checklists）和成功标准。如果有长篇参考文档，请将其放在单独的文件中并进行链接，以便 agent 仅在需要时才获取
技能如何帮助 agent
大语言模型（LLMs）并不会因为你喂给它更多文字就变得更聪明。事实上，文字越多往往噪音越大
请把上下文（Context）看作一笔严格的预算。 如果你把预算全花在通用指令或不用的工具上，留给核心内容（代码、错误日志、计划）的空间就少了
技能就是解决这个问题的良方。如果你曾见过 agent 因为某个关键约束被埋在巨大的规则文件深处而产生幻觉，技能就是补救措施。它们不一定让 agent 更聪明，但会让信息更聚焦、更容易检索
规则、命令与技能的思维模型
那么，深层的问题来了：什么时候该用技能，什么时候用命令或规则？
以下是我的思考逻辑：
- 规则（Rules）是恒定不变的：它们每次都适用，无一例外。
- 命令（Commands）代表你的明确意图：你输入
/command是因为你想亲自掌控方向。 - 技能（Skills）是可选的专业知识：agent 只在特定任务（缓存特定任务的流程模式）需要时才把它们从架子上拿下来
如果你只打算记住本文的一点，请记住这张表：
| 概念 | 触发者 | 适用场景 | 上下文成本 | 反模式（错误用法） |
|---|---|---|---|---|
| 规则 (Rules) | 工具/系统 | 仓库通用要求 | 始终占用 | 把教程塞进规则里 |
| 命令 (Commands) | 你（用户） | 可重复的工作流 | 使用时占用 | 把每个偏好都变成命令 |
| 技能 (Skills) | agent | 特定任务的执行手册 | 需要时占用 | 把本质是规则的东西做成技能 |
技能 vs. 规则：有意识地保持规则简洁
技能并不取代规则。规则是非谈判项，但有了技能，你写规则的方式应该彻底改变
默认的拆分方案：
- 规则：仓库要求、安全约束、命名规范、如何运行测试
- 技能：特定工作流的手册、工具使用指南、代码审查规范
测试标准：你是否希望该指令在你不考虑它时也生效？
- 是？-> 规则
- 否？-> 技能
举例：
- “绝不提交 .env 文件” 是规则
- “当你触达计费代码时，运行这三个集成测试” 是技能
- “设计系统使用这些标记名称”是一条规则
- “编写发行说明时，请遵循此格式和清单”是一项技能
一种实用的模式是将规则和技巧结合起来，使你的代码仓库规则主要由路由逻辑构成。例如：
- “更改用户界面组件时，请加载
ui-change技能” - “调试生产错误时，加载该
incident-triage技能”
这样可以保持始终显示的提示信息较小，并使代理更具适应性
技能 vs. 命令：可组合，但不等同
- 命令是确定性的：你调用它，工具注入提示词，agent 执行
- 技能是建议性的：AI自行决定是否需要该上下文
最强的模式是结合使用： 将复杂的长期指令保持为“skill”，将“命令”作为触发这些技能组合的快捷方式
例如，一个 /release 命令可以对应：“加载 release 技能，然后按照检查清单操作”
技能 vs. Agents
什么时候该用技能，什么时候该切换整个 agent？
- 技能改变agent知道什么
- agent改变谁在干活以及他们能接触到什么
当你想让当前的助手遵循更好的流程时，使用技能。当你需要隔离环境或专属专家（例如一个专门负责重构的、使用更昂贵模型、具备不同工具权限的agent）时，使用独立的 agent
如何编写出色的技能
技能很容易像文档一样变得臃肿。要保持控制，请参考以下清单：
- 编写真正起路由作用的描述：如果agent根据你的提示找不到技能，里面的代码写得再好也没用。
- 保持技能定义文件精简：把它当作快速入门指南
- 链接到大块资源：利用渐进式披露
- 明确定义“完成”标准：技能是为了减少歧义
一个简单的技能示例：UI 变更
Markdown
---
名称：UI 更改
描述：在更改用户界面组件、样式、布局或交互行为时使用此技能。---
此技能可帮助您使用设计系统来审查和实施用户界面更改。
## 约束条件
- 重要提示：使用现有的设计标记和组件
- 不要使用神奇数字或原始像素值
- 保持无障碍功能完好：键盘、标签、焦点、对比度
- 保持差异小，避免无关的重构
## 代币
该代码库的全局标记位于 `variables.css` 中。
### 间距
[关于何时使用何种间距的信息]
### 颜色
[关于使用颜色标记的信息]
等等。
[]
## 组件
[]
## 工作流程
1. 用一句话重述这个变化。2. 找出最接近的现有组件模式。3. 实现与规范相匹配的最小差异。4. 验证响应式行为、焦点状态和键盘导航。5. 如果有任何不清楚的地方，停下来请求确认。6. 请确保您的变更符合以下成功标准。
## 成功标准
- 除非用户明确要求，否则您的更改不得使用新标记、魔法数字、原始像素值或新的设计组件。
- 您的更改在移动设备、平板电脑或桌面视口上均不会出现故障。
- 即使终端用户没有鼠标或使用屏幕阅读器，您的更改也应完全可用。
- 您已确切告知用户您所做的更改，并与他们口头确认了上述三点。
值得拥有的入门技能库
如果你正在为真实的生产工作构建 AI 编码环境，你最终总会遇到那几个重复的“轮子”。为了节省时间，建议从以下基础技能开始构建：
- 项目导航 (Repo orientation) ：入口文件在哪里？测试代码写在哪？有哪些约定俗成的开发规范？
- UI 变更 (UI changes) ：如何处理设计变量（Design Tokens）？如何进行无障碍（Accessibility）检查？
- 调试 (Debugging) ：如何复现问题？如何判断哪些日志才是关键信息？
- 验证 (Verification) ：为了证明修改有效，具体需要运行哪些命令？
- PR 卫生 (PR hygiene) ：Commit 信息格式是什么？如何更新变更日志（Changelog）？
- 安全 (Safety) ：底线在哪里？（比如：绝对严禁删除生产环境数据库！）
这些技能描述不需要写得像小说一样长。重点不在于字数，而在于让智能体停止瞎猜，开始遵循你的标准。
优秀技能检查清单
如果你想让技能结构保持精简且实用，请用这六个特定问题来衡量你的技能：
- 触发条件 (Trigger/Description) ：智能体到底应该在什么时候加载这个技能？
- 输入 (Inputs) ：在开始之前，它需要从你这里或仓库中获取哪些信息？
- 步骤 (Steps) ：具体的执行流程是什么？
- 检查 (Checks) ：如何证明任务成功完成了？
- 中止条件 (Stop conditions) ：什么时候它应该停下来询问人类（你）？
- 恢复 (Recovery) ：如果检查失败，下一步该怎么办？
常见的失败模式（技能“翻车”现场）
每个人都会犯这些错误，以下是识别它们的方法：
- “百科全书”型 (The Encyclopedia) ：如果一个技能读起来像维基百科页面，那就把它拆掉。拆分成更小的文件，让技能只在需要时拉取信息
- “全能大杂烩”型 (The Everything Bagel) ：如果一个技能适用于每一个任务，那它就不是技能，而是“规则”或“仓库约定”
- “神秘暗号”型 (The Secret Handshake) ：如果智能体从不加载某个技能，很可能是你的描述太抽象了。请根据你平时描述任务的习惯来重写它
- “易碎”型 (The Fragile Skill) ：如果仓库一变技能就失效，说明你硬编码了太多细节。把具体细节移到参考文件中，保持技能逻辑的程序化
结语：去创造你的技能吧
技能并不是什么魔法，它们只是打包和加载指令的一种策略
- 用 规则 (Rules) 来处理那些“永恒不变”的事
- 用 命令 (Commands) 来处理那些“明确的手动工作流”
- 把 技能 (Skills) 留给那些“可选的、特定的专业领域知识”
- 只有当你尝试了技能但仍然搞砸时，才去考虑使用独立智能体/子智能体。
只要坚持这种拆分方式，你就能实现更高质量的自动化，同时避免提示词（Prompt）变得像淤泥一样臃肿。你的智能体将不再是一个脆弱的脚本，而是一个真正的合作伙伴
