AI Agent 智能体 Skill（技能）详解：从概念到实战

本文系统地讲解 TraeWork / TraeCode 中的 Skill（技能）：它是什么、核心机制是什么、和 Prompt / 规则 / MCP 有什么区别、SKILL.md 怎么编写、怎么创建与使用，如何写出一份高命中率、高稳定性的技能——最后用一段完整的实战场景（把"代码审核"变成技能）演示从建立、使用到 AI 运行的整个过程。内容基于官方文档整理，并配以完整可抄的实例。

一、Skill 是什么

1.1 一句话定义

Skill（技能）是一套"专业能力说明书"——把完成某一类任务所需的指令、约束、流程、示例封装成一个 SKILL.md 文件，AI 在相关任务到来时按需加载它，从而按既定标准完成任务。

1.2 官方定义

官方文档的定义是：技能（Skill）通过 SKILL.md 文件进行定义和管理，每个技能封装了指令、脚本及相关资源，用于为智能体提供可复用、面向特定场景的专业能力。

一句话概括：一个 Skill 是一份清晰、严谨、可执行的指令文档，明确告诉模型——在什么条件下（When）、按照哪些步骤（How）、产出什么结果（What）。

1.3 最贴切的类比：给新员工的岗位操作手册（SOP）

不用每次重新口头交代"你要怎么干"——翻出手册照做即可；
手册把隐性经验显性化——团队的标准、规范、踩过的坑，写下来就能复用；
新人（AI）水平再参差，照着手册也能交出稳定合格的结果。

1.4 四个关键特征

特征	含义
结构化	一个技能 = 一个 `SKILL.md`，用固定格式描述目标、场景、约束、流程、示例
按需加载	平时只暴露"门牌"（name + description），命中才加载全文，省 token
可复用	定义一次，跨项目、跨团队、跨 AI 对话反复使用
可共享	一个 `SKILL.md` 或 zip 就能打包分享给任何人

二、Skill 的核心机制：按需加载

2.1 生命周期（流程）

用户请求
   ↓ 任务
扫描技能索引（只读所有技能的 name + description）
   ↓ 相关性判断
命中匹配 ────────────────→ 加载该技能的 SKILL.md 完整内容 → 按指令执行 → 输出规范结果
   ↓（未命中）
不加载，该技能零占用

步骤 1：AI 收到用户请求后，先扫描所有已安装技能的 name 和 description（轻量元数据，占用极小）；
步骤 2：AI 判断当前任务与哪个技能的描述高度相关；
步骤 3：只有命中的技能，其完整的 SKILL.md 才被加载进上下文；
步骤 4：AI 按照技能中的指令、步骤、约束执行任务。

2.2 按需加载 vs 全量加载

	规则（Rules）	技能（Skill）
加载时机	对话一开始就全部注入	任务命中时才加载
上下文占用	持续占用，始终存在	平时零占用，命中才占
适合场景	"永远生效"的项目约定	"特定场景才用"的专业能力
Token 消耗	高	低

2.3 为什么省 Token 这么重要

模型的上下文窗口是有限且宝贵的公共资源。每一个被加载的技能都在竞争有限的上下文资源。技能按需加载的机制可以：

减少上下文中的 Token 消耗；
避免无关信息干扰 AI 的决策；
让 AI 的注意力集中在当前任务真正需要的知识上。

这也是"规则全量加载、技能按需加载"这一设计存在的根本原因。

三、Skill 与 Prompt / 规则 / MCP 的区别

3.1 对比总览

概念	本质	机制	特点
普通 Prompt	对话中临时口述的要求	每次对话即兴输入	一次性、不可复用、全凭当场发挥
规则（Rules）	常驻约束	全量加载	一开对话就注入，持续占用上下文
技能（Skill）	标准作业流程	按需加载	命中才加载，零常态占用
MCP Server	可调用的工具集	工具注册	回答"能做什么"

3.2 Skill vs MCP 的本质分工

MCP Server：给 AI 提供可以调用的工具——"能做什么"（如读数据库、操作浏览器、发消息）；
技能（Skill）：告诉 AI 如何规范地完成任务——"怎么做、按什么标准"。

官方示例：TraeCode 可以通过 Playwright MCP Server 获得页面操作等自动化测试能力；而对应的技能则用于约定测试工程结构、页面对象模型（POM）设计规范，以及常见测试用例的编写和执行流程，从而引导 AI 在正确的上下文中高效调用这些能力。

一句话：工具负责"手"，技能负责"操作规程"。

3.3 Skill vs Prompt 的定位差异

	Prompt	Skill
生命周期	临时、即兴	长期复用、工程化维护
稳定性	每次输出可能有偏差	稳定、确定、可回归
设计目标	探索性对话	输入输出明确的能力模块
维护方式	无需维护	可迭代、可评测、可版本管理

四、SKILL.md 文件结构详解

4.1 目录结构

skill-name/
├── SKILL.md               # （必须）智能体的核心指令
├── examples/              # （可选）输入/输出示例
│   ├── input.md
│   └── output.md
├── templates/             # （可选）可复用的模板
│   └── component.tsx
└── resources/             # （可选）参考文件、运行脚本或素材
    └── style-guide.md

只有 SKILL.md 是必需的，其余按需添加。

4.2 frontmatter 元数据（"门牌"）

SKILL.md 顶部的 YAML 头是 AI 发现和识别技能的入口，直接决定触发准确率。

---
name: code-review
description: 当用户请求代码评审、代码反馈或审核代码时触发
---

name 命名规范：

规范	✅ 好的例子	❌ 坏的例子
简洁、唯一的标识符	`running-tests`	`test-helper`（语义模糊）
小写字母、数字和连字符（`-`）	`deploy-microservice`	`deployService`（命名不规范）
推荐使用动名词	`database-migration`	`data-skill-v2`（冗余且含版本信息）
长度不超过 64 个字符

description 编写规范：

规范	✅ 好的例子	❌ 坏的例子
使用第三人称，从模型视角描述	"Review code for quality, correctness, and maintainability. Use when evaluating pull requests, refactoring existing code, or when the user asks for feedback on implementation details, edge cases, or potential bugs"	"I can help you review code"（第一人称）
包含核心功能与触发时机的关键词	同上	"Helps with code review"（缺乏触发时机）
长度不超过 1024 个字符

4.3 正文（"操作手册"）

命中后加载进上下文，AI 按其中内容执行。标准结构包含：

描述：这个技能的作用；
使用场景：触发条件，写清正向条件（什么时候用）与负向条件（什么时候不用）；
指令：清晰的分步说明，告诉 AI 具体怎么做；
示例（可选）：输入/输出示例，展示预期效果。

4.4 完整实例：code-review

---
name: code-review
description: 当用户请求代码评审、代码反馈或审核代码时触发
---

# 代码评审技能

## 描述
审查代码质量、正确性与安全性，输出结构化反馈。

## 使用场景
- "帮我审核这段代码"
- "这个函数写得如何"
- 合并请求 / 代码差异审查

## 指令
1. 阅读目标代码及其调用上下文；
2. 按 正确性 → 可读性 → 性能 → 安全 的顺序检查；
3. 每个问题给出：位置、严重级别、原因、可执行的修改建议；
4. 最后汇总 Top 3 必须修改项。

## 示例（可选）
输入: def f(x): return x*2
输出: 建议重命名为 double() 并补充类型标注……

4.5 渐进式披露：大技能怎么拆分

SKILL.md 应当作为技能的入口和导航，而不是包罗万象的大文件。详细资料拆成独立文件，让信息按需流动。

最佳实践：

保持 SKILL.md 简洁：主体内容尽量控制在 500 行以内，只包含必要信息；
避免深度嵌套：所有引用文件最好直接由 SKILL.md 链接，保持一层引用深度，避免链式引用（A → B → C），防止模型只读取部分内容；
为长文件添加目录：对于超过 100 行的参考文件，在文件顶部添加目录（Table of Contents）。

示例：

# SKILL.md

## 基础用法
描述如何触发 CI/CD 流水线：
- 检查 PR 状态
- 执行单元测试
- 更新 PR 测试状态

## 高级功能
详细说明请参见 `ci-advanced-features.md`：
- 并行执行多分支测试
- 条件触发不同类型的测试
- 自定义失败处理策略

## API 参考
所有方法与参数说明请参见 `ci-api-reference.md`：
- startPipeline(prId: string, branch: string)
- getPipelineStatus(pipelineId: string)
- cancelPipeline(pipelineId: string)

五、技能类型：全局 vs 项目

	全局技能	项目技能
生效范围	跨项目全局生效	仅在当前项目生效
存放位置	macOS/Linux：`~/.trae-cn/skills` Windows：`%userprofile%/.trae-cn/skills`	项目路径下 `.trae/skills/`

全局技能适合：

统一个人 / 团队的通用开发范式，例如统一代码风格、命名规范、注释习惯；
提供跨项目可复用的工程能力，例如通用工具链的使用（Git、CI/CD、Playwright 等）；
固化个人或组织的长期偏好，例如输出结构（是否先给结论、是否列步骤、是否给示例）。

项目技能适合：

注入项目专属的业务知识与规则，例如不可违反的业务约束与边界条件、项目内部术语、概念映射；
约束 AI 按项目的既定技术方案工作，例如技术栈、框架版本、架构限制等；
让 AI 深度参与当前项目的开发和维护，例如针对项目生成测试、Mock、脚手架代码；与项目使用的 MCP Server 或内部工具协同。

六、创建技能的三种方式

6.1 方式一：对话，由 AI 自动创建

直接向 AI 描述需求，AI 自动生成对应的 SKILL.md：

帮我在 .trae/skills 目录下创建一个新的技能
技能的名字叫 xxx
这个技能可以帮我做以下事情：
- xxx
- xxx
- xxx

6.2 方式二：设置面板手动创建

前往 设置 > 技能与命令；
在技能部分点击创建，选择技能类型（全局 / 项目）；
填写三个字段：
- 技能名称：简短且有辨识度；
- 描述：技能是什么，应该在什么情况下被触发；
- 指令：技能被触发时，希望 AI 遵循哪些规则或信息；
点击确认：
- 全局技能 → 直接出现在技能面板的全局页签下；
- 项目技能 → 自动在 .trae/skills/{skill_name} 目录下创建 SKILL.md，并出现在项目页签下； 5.（可选）在 {skill_name} 文件夹下手动添加所需的脚本等资源。

6.3 方式三：导入外部技能

前往 设置 > 技能与命令，点击创建；
上传一个 SKILL.md 文件，或一个包含 SKILL.md 的 .zip 文件；
TraeCode 自动分析并填充 技能名称 / 描述 / 指令 字段；
按需修改后点击确认：
- 项目技能会在 .trae/skills/ 下新建 {skill_name} 文件夹，包含所有上传的文件。

七、使用技能的两种方式

7.1 手动调用

直接向 AI 发送指令，明确告知调用某个技能：

"用 code-review 技能审核一下这个分支的改动"

7.2 自动调用

AI 结合当前任务内容与各技能中定义的"适用场景 / 何时使用"描述，判断是否需要加载某个技能，并在合适的阶段自动调用。

例如：定义了一个代码审核技能，触发条件为"当用户请求代码反馈或评审时"。当用户说"这个函数写得如何"、"帮我审核以下代码"时，AI 会识别到请求与技能的相关性，无需额外指令自动加载并使用该技能，以完成对应的代码分析与反馈。

八、实战案例：把"代码审核"变成技能

前七章讲完了概念与操作。这一章用一个最贴近日常的场景——开发者把"代码审核"固化成技能——完整演示"建立 → 使用 → AI 运行"三个环节，把前面的机制串成一条线。

8.1 场景背景：小 A 的痛点

小 A 是个开发者，经常让 AI 审核代码。但结果总是不稳定：

今天 AI 只提了变量命名，明天漏了安全漏洞；
每次输出格式都不一样，有的给表格、有的给段落；
审核的侧重点随机——有时揪着风格不放，却对明显的性能问题视而不见。

他决定把审核标准固化成一个技能。这正是建立技能的动机：把不可控的即兴发挥，变成可控的标准流程。

8.2 第一步 · 建立：一段对话，AI 生成 SKILL.md

小 A 直接对话描述需求：

帮我在 .trae/skills 目录下创建 code-review 技能，它应该：按「正确性 → 可读性 → 性能 → 安全」的顺序审核代码；每个问题给出位置、严重级别、原因和修改建议；最后汇总 Top 3 必须修改项。

AI 据此生成 SKILL.md 并落盘到 .trae/skills/code-review/：

---
name: code-review
description: 当用户请求代码评审、代码反馈或审核代码时触发
---

# 代码评审技能

## 使用场景
- "帮我审核这段代码" / "这个函数写得如何" / 合并请求审查

## 指令
1. 阅读目标代码及其调用上下文；
2. 按 正确性 → 可读性 → 性能 → 安全 的顺序检查；
3. 每个问题给出：位置、严重级别、原因、可执行的修改建议；
4. 最后汇总 Top 3 必须修改项。

注意门牌上的 description——"当用户请求代码评审、代码反馈或审核代码时触发"——这句话是后面 AI 能自动认出这个技能的关键。这个文件就是技能的全部本体：一个结构化文档，落在 .trae/skills/code-review/ 目录下，技能即宣告建立。

8.3 第二步 · 使用：说人话，AI 自动匹配

第二天，小 A 把一段函数丢给 AI，只说了一句：

帮我审核这个函数。

AI 的完整运行路径：

扫描索引：读取所有已安装技能的 name + description（只读门牌，极轻量）；
相关性判断：这句请求和 code-review 的 description"当用户请求代码评审……时触发"高度匹配；
加载：把 code-review 的完整 SKILL.md 加载进上下文；
执行：严格按其中 4 步指令干活。

整个过程小 A 没有任何额外操作——没有说"用 code-review 技能"，AI 靠门牌自动完成匹配和加载。这就是第七章讲的"自动调用"机制在实际场景中的完整呈现。

8.4 第三步 · AI 运行：按指令逐步执行

加载技能后，AI 的内部执行轨迹是这样的：

指令	AI 实际做什么
指令 1	读取目标函数 + 找到它的调用位置和上下文
指令 2	先查正确性（逻辑对不对），再查可读性、性能，最后查安全——固定顺序保证安全不漏
指令 3	每个问题按「位置 + 严重级别 + 原因 + 建议」四要素输出
指令 4	结尾汇总 Top 3 必须修改项

输出长这样：

【安全 · 高】第 12 行：用户输入直接拼接进 SQL，存在注入风险
  建议：改用参数化查询（? 占位符）

【正确性 · 中】第 27 行：当 items 为空时返回 None，调用方未处理
  建议：改为返回空列表 []

【性能 · 低】第 9 行：循环内重复调用 db.query()，建议提到循环外

Top 3 必须修改：安全（12 行）→ 正确性（27 行）→ 性能（9 行）

这就是"AI 怎么运行"的完整答案——技能把 AI 的思考路径钉死在了规范上。固定顺序保证安全审查永不缺席；四要素格式保证每条反馈都可直接执行；Top 3 汇总保证最重要的修改不被淹没。

8.5 效果对比：用技能前 vs 用技能后

没有技能 · AI 自由发挥：

输出示例："这段代码还行，但变量命名可以再优化一下……"
每次审核侧重点随机；
输出格式每次不一样；
容易漏掉安全问题。

用了 code-review 技能：

输出示例："1. 安全（高）：第 12 行 SQL 拼接存在注入风险，建议改用参数化查询……"
固定检查顺序，安全不漏；
每项给出位置 / 级别 / 建议；
末尾汇总 Top 3 必改项。

8.6 场景小结：三句话记住整个机制

环节	一句话
建立	把标准写进 `SKILL.md`（门牌定触发条件，正文定执行步骤），AI 自动生成或手动创建都行
使用	说人话即可——AI 先扫描所有技能的门牌，匹配到 `description` 就自动加载，不用你点名
AI 运行	加载后严格按指令逐步执行，检查顺序、输出格式、失败策略全被钉死，结果稳定可复现

这个场景换个领域完全同理：把"行业研究报告"的标准（目录结构、图表规范、数据来源标注）写成技能，你说"写一份 XX 行业报告"，AI 就会自动加载并按你的研究框架产出——当前工作区里挂载的那些技能（html-report、xlsx、frontend-design、full-link-stock-analysis 等），就是这么在背后工作的。

九、如何写好一个 Skill：最佳实践

9.1 三个常见认知误区

误区一：Skill 等同于一段 Prompt

Skill 不是一次性的对话提示，而是可长期复用、输入输出明确的能力模块，强调稳定、确定、易于工程化维护；Prompt 偏向临时性、探索性和即兴交互。

误区二：Skill 是写给人看的文档

Skill 的目标不是解释原理，而是下达指令。SKILL.md 的内容应使用模型可解析的结构化语言，明确约束行为边界，精确描述何时使用（When）、如何执行（How）、输出结果（What）。

误区三：Skill 越复杂越强大

职责单一、边界清晰的技能更容易在正确时机被选中并稳定执行；过于复杂的技能反而会降低命中率。技能文档应以最小必要信息为目标，避免冗余解释与不必要的背景铺垫。

9.2 指导方式的自由度分级

根据任务复杂度与容错要求，控制对模型的约束强度：

自由度	适用场景	指导方式	示例
高	存在多种有效方法；模型决策依赖上下文	提供启发式策略（给原则）	代码审查：先看安全性，再看可读性
中	存在首选模式；允许一定变通；行为受配置影响	提供模板 / 伪代码（给框架）	报告生成：按"摘要-分析-建议"结构
低	操作脆弱易错；一致性至关重要；必须遵循特定序列	提供可执行脚本（给代码）	数据库迁移：按固定顺序执行脚本

低自由度示例：数据库迁移技能

---
name: database-migration
description: 当用户需要执行数据库迁移时，按预定义顺序执行 SQL 或迁移脚本，确保数据和结构一致性
---

## 迁移计划
1. 准备阶段：
   - 备份现有数据库
   - 验证目标环境配置
2. 执行阶段（按顺序执行脚本）：
   - 脚本 001_create_users_table.sql：创建用户表
   - 脚本 002_add_email_index.sql：为用户表添加邮箱索引
   - 脚本 003_update_roles.sql：更新角色字段数据
3. 验证阶段：
   - 检查数据完整性
   - 验证关键功能是否正常
4. 回滚（可选）：
   - 如出现异常，按回滚方案恢复数据库

9.3 五个核心设计标准

标准一：边界明确

模型最容易犯的错误不是"不知道怎么做"，而是"不知道什么时候该做"。技能的触发必须有明确的正向条件和负向条件。

✅ 边界清晰：

Use this skill when:
- 用户意图是触发 CI/CD 流水线执行单元测试
- PR 状态为"待合并"，需要执行自动检查或 lint 校验

Do NOT use this skill when:
- 用户只是查看测试报告或 CI/CD 状态
- PR 内容没有代码改动，仅修改文档或注释

❌ 边界不清晰：

Use this skill when:
- 用户想让流水线跑一下测试
- PR 有代码改动或文档改动

Do NOT use this skill when:
- 用户只是在看 PR

标准二：输入输出结构化

与模型沟通需要定义双方都能理解的"共同语言"，推荐用类似函数签名的方式明确 Input 和 Output。

✅ 结构化定义：

Input:
- prId: string       # PR 编号
- branch: string     # 分支名称
- runTests: boolean  # 是否执行单元测试
Output:
- success: boolean           # 是否成功执行
- testReport?: object[]      # 测试报告（可选）
- errorMessage?: string      # 错误信息（失败时返回）

❌ 模糊描述： "帮用户跑测试并返回结果。"

标准三：步骤明确、可执行

技能的核心是"步骤"，必须是指令式、具体动作，而不是概括性描述。

✅ 指令式步骤：

Steps:
1. Validate PR: 检查 prId 和 branch 是否有效
2. Checkout branch: 切换到指定分支
3. Run tests: 根据 runTests 参数执行单元测试
4. Collect results: 收集测试结果
5. Update PR status: 将测试状态回写到 PR
6. Notify user: 若测试失败，返回错误信息

❌ 描述性语言： "检查 PR，运行测试，然后更新状态。"

标准四：失败策略完备

模型在失败时容易自由发挥，必须明确定义"失败路径"。

On Failure:
- Validation fails: 返回 400 Bad Request，并附上具体错误信息
- Test execution fails: 自动重试一次，仍失败则返回"单元测试未通过，请检查日志"
- CI/CD 服务不可用: 重试最多 3 次，仍失败则记录日志并通知管理员

标准五：职责绝对单一

每个技能只做一件事，对应一个核心动作动词。

✅ 单一职责：

running-unit-tests：只负责执行单元测试
updating-pr-status：只负责更新 PR 状态
sending-notification：只负责发送通知
running-lint-check：只负责执行 lint 校验

❌ 功能捆绑： 一个技能同时完成"运行测试 + 更新 PR 状态 + 发送通知 + 执行 lint 校验"。

9.4 工作流与反馈闭环

对于包含多个步骤、中间结果影响最终质量的复杂任务，必须显式定义工作流和检查清单，在关键节点建立"验证 → 修正 → 再验证"的反馈闭环。

分析类任务的工作流示例：

## 技术方案评估工作流

在开始执行前复制以下清单，并在每一步完成后显式标记状态。

- Step 1：明确业务目标与技术约束（性能、成本、时限）
- Step 2：列出所有可行的技术方案
- Step 3：从复杂度、可维护性、风险角度逐一评估
- Step 4：对关键差异点进行对比分析；（反馈闭环）若发现关键信息不足，应返回 Step 2 或 Step 3 补充分析
- Step 5：给出结论性建议，并说明取舍理由；（反馈闭环）若结论无法支撑目标约束，应重新审视 Step 1 的前提条件

代码类任务的工作流示例（计划 → 验证 → 执行）：

## 依赖版本升级工作流

- Step 1（Plan）：识别需要升级的依赖及当前版本；阅读目标版本的 Release Notes 与 Breaking Changes
- Step 2（Plan）：更新依赖配置文件；标注可能受影响的模块
- Step 3（Validate）：执行依赖冲突检查与静态构建；（反馈闭环）若校验失败，必须回退到 Step 2 调整依赖配置
- Step 4（Execute）：安装新版本依赖；运行完整测试集
- Step 5（Validate）：检查核心功能是否受影响；对比升级前后的构建与运行结果；（反馈闭环）若出现回归问题，应回滚升级并记录风险点

9.5 可执行脚本的加固原则

当技能依赖可执行脚本时，脚本的健壮性优先于代码的巧妙性。技能本身不会理解你的代码逻辑，它只感知输入与输出。脚本必须做到：失败可预期、输出可理解、参数可解释。

1. 显式处理错误，而不是让模型猜

ERROR: Config file not found: ./deploy.yaml
HINT: Please check whether the file path is correct or run init-config.sh to generate a default config.

2. 输出自解释的日志与验证结果

CHECK FAILED: Node.js version mismatch
- Required: >= 18.0.0
- Detected: 16.14.0

VALID OPTIONS:
1. Upgrade Node.js to a supported version
2. Switch to a compatible build image

3. 避免魔法数字，让参数有来由

TIMEOUT_SECONDS = 30  # Wait up to 30s because service startup usually completes within 10–20s

9.6 评测驱动、失败优先的构建流程

技能的开发是一个以失败为起点、评测为牵引，持续迭代优化的工程化过程。

第一步：建立"无 Skill"基线，识别真实问题

先不使用技能，直接让模型执行目标任务。重点观察：

模型在哪些情况下表现不稳定或结果不可复现；
哪些输入会引发歧义、误解或走偏；
模型是否在错误的时机尝试"主动帮忙"。

这些失败点就是技能需要解决的真实能力缺口。（回到第八章的场景：小 A 正是先经历了"无技能"时期的种种不稳定——漏安全、格式乱、侧重点随机——这些痛点就是 code-review 技能要解决的真实缺口。）

第二步：以"失败优先"为原则，定义评测用例

针对已识别的问题，设计 3–5 个具体、可复现的评测用例，每个用例明确"通过 / 失败"的判定标准，优先覆盖模型最易误用技能的场景。

第三步：编写最小化技能，明确最短成功路径

只编写刚好能够通过当前评测的最小规则集合：

将评测中识别的失败场景显式写入技能，作为第一层防护；
定义最短成功路径；
之后持续迭代，以评测结果为牵引逐步完善。

十、技能的管理

10.1 启用 / 禁用

创建技能后，通过打开 / 关闭技能开关来启用或禁用。使用该功能后，项目会在 .trae/ 目录下创建 skill-config.json 文件，罗列被禁用的项目技能（被禁用的全局技能不记录在该文件中）。

10.2 编辑 / 删除 / 应用到全局

点击目标技能右侧的齿轮图标，选择编辑或删除。对于项目技能，还可以选择 应用到全局，将其转换为全局技能。

10.3 .agents/skills 目录与生态

.agents/skills/ 目录是由 Agent Skills 规范（agentskills.io）约定的目录，用于存放技能。使用步骤：

将 .agents/skills/ 目录添加至项目；
前往 设置 > 技能与命令，在 导入设置 部分打开 启用 .agents 技能目录 开关；
智能体在运行时自动发现并加载其中的技能。

注意：若 .trae/skills/ 中的技能与 .agents/skills/ 中的技能重名，系统优先调用 .trae/skills/ 目录中的技能。

还可以使用 find-skills 技能，依托名为 skills 的命令行工具，从开放的 Agent Skills 生态中搜索、安装与管理各类模块化技能包。

十一、内置技能与实战参考

11.1 TraeCode 内置技能

技能名称	描述
TRAE-security-review	执行代码安全扫描，针对代码安全、漏洞风险及安全最佳实践提供结构化反馈
TRAE-generate-mini-app	基于 Taro 框架生成高质量、可运行的多端小程序代码
TRAE-debugger	调试需要收集运行时证据的复杂问题，遵循"假设 > 插桩 > 复现 > 分析 > 修复 > 验证"流程
TRAE-code-review	执行代码审查，针对代码质量、正确性及最佳实践提供结构化反馈

11.2 工作区中的实际技能例子

当前工作环境（TraeWork）里挂载了大量开箱即用的技能，例如：

html-report：生成带设计规范、排版规范的 HTML 报告；
xlsx：处理电子表格（读写、公式、格式化、图表）；
docx：处理 Word 文档（创建、编辑、格式保留、批注）；
frontend-design：前端界面设计，产出有设计品质的页面；
full-link-stock-analysis：全链路个股投研分析（实时行情、估值、财报、研报）；
industry-panorama-research：行业研究（宏观政策、市场规模、产业链、竞争格局）。

当你说"生成一份调研报告"时，AI 就会命中 html-report 技能，加载它的排版规范、图表规范、结构要求，输出统一风格的成品——这就是技能在工作。它与第八章的 code-review 场景走的是完全相同的机制：门牌匹配 → 按需加载 → 按指令执行。