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