关于skill：

************如何寻找或创建skill**************
1、可以在官方git仓库中寻找合适当前ai 智能体的具有某种能力的skill;

2、也可以下载find skills，然后通过npx skills find "xxx技能关键词"来下载；
eg:

-----安装适合trae的skill
npx skills add https://github.com/vercel-labs/skills --skill find-skills --agent trae -y
-----寻找能处理pdf的skill----
npx skills find "pdf 处理" # 搜索 PDF 相关技能

3、还可以自己创建skill
----按照指定格式写，一般为markdown格式
----或者在ide的引导下按步骤填写

************如何引用skill**************
对于以上的skill, 首先要导入到项目中(如果没有图形化界面，就存放到指定目录中)
1、使用@引用”SKLL文件名“ （相对路径或绝对路径）
2、使用/技能名 直接激活技能
3、在SKILL文件中添加触发条件eg：某个关键词xxx，然后在智能体对话框中直接使用 ”xxx“触发；
eg:以下是添加在SKILL文件中的触发条件

## 触发条件

- 关键词：["关键词1", "关键词2"]

注意！不同平台触发技能的方式不一样。trae 平台编写SKILL文件时，触发关键词放在元数据头的description字段中。

------------------------------------在ai 智能体中遇到的一些问题------------------------------------

1、为什么我已经在ide中配置了全局技能，但是在solo 模式下智能体对话框中输入关键词却不能触发相关技能呢？

这是一个非常典型且深入的 AI IDE 配置问题。你遇到的情况（配置了技能但未触发）通常不是配置错误，而是由 AI 路由机制、模式能力限制 和 指令优先级 共同导致的。

以下是导致 test-case-generator-optimize 技能在 Trae Solo 模式下未被触发的核心原因分析，以及解决方案：

1. 核心原因分析

A. Solo 模式的能力限制 (最主要原因)

• Solo 的定位： Solo 模式主要侧重于代码补全、解释和轻量级修改。为了安全和响应速度，Solo 模式通常会限制或禁止 AI 自主执行系统命令（RunCommand）、创建复杂文件结构或运行外部脚本（如 Python + pandas）。
• Builder 的定位： 你的技能定义中包含了 RunCommand、Python with pandas、Write Excel 等重操作。这些是 Builder 智能体 的典型能力。
• 冲突点： 当你在 Solo 模式下输入指令时，Trae 的路由器（Router）检测到该任务需要执行“危险”或“重型”工具（如运行 Python 脚本生成 Excel），出于安全策略，它可能主动抑制了该技能的调用，转而使用基础模型直接生成文本格式的测试用例，或者什么都不做。

B. “激活规则”是指令而非系统钩子

• 误解： 你在 Markdown 内容中写的 ## Activation Rule (激活规则) 是写给 LLM（大语言模型） 看的提示词（Prompt），而不是写给 Trae IDE 系统 看的配置代码。
• 现实： Trae 的系统路由器在决定是否调用某个技能时，主要依据技能的 name 和 description 字段，以及当前的上下文意图。它不会解析你 Markdown 正文里的“当用户提到...时激活”这段文字来作为系统级的触发器。
• 结果： 如果路由器的语义匹配置信度不够高（例如它认为基础模型也能做这件事），它就不会加载这个技能，因此技能内部的“激活规则”根本没机会被执行。

C. 上下文引用 (@UPR.md) 的干扰

• 机制： 当你使用 @UPR.md 时，你是在向 AI 提供数据上下文（需求文档）。
• 冲突： 这可能会让 AI 认为你只是希望它“阅读这个文件并回答”，而不是“执行一个特定的工作流”。如果没有明确选择技能，AI 倾向于使用最通用的路径（直接聊天）而不是调用特定技能。

D. 技能描述的匹配度

• 虽然你的描述写了 Invoke when user needs to create test cases，但 AI 路由有时比较保守。如果它判断“生成测试用例”是一个通用任务，它可能优先使用内置能力，而不是自定义技能，除非内置能力无法满足。

2. 解决方案

为了让这个技能按预期工作，建议尝试以下步骤：

方案一：切换到 Builder 模式 (推荐)

鉴于你的技能涉及 文件写入、命令执行、Excel 生成，这完全符合 Builder 的场景。

• 操作： 在 Trae 中切换到 Builder 智能体模式。
• 输入： @UPR.md 请使用 test-case-generator-optimize 技能生成测试用例。
• 原因： Builder 模式拥有更高的工具调用权限（Tool Use），允许执行 Python 脚本和写入文件，且更倾向于执行多步任务。

方案二：显式调用技能 (在 Solo 中)

不要依赖关键词自动触发，而是显式告诉 AI 使用哪个技能。

• 操作： 在输入框中，尝试通过 / 命令或技能选择器（如果有）明确指定。
• 输入示例： /test-case-generator-optimize @UPR.md 生成测试用例
• 或者： 请调用 "test-case-generator-optimize" 技能，根据 @UPR.md 生成测试用例。
• 原因： 明确提及技能名称可以大幅提高路由器的匹配置信度。

方案三：优化技能元数据 (Metadata)

修改技能配置头部的 description，使其更具强制性和辨识度。

• 修改前： Generates high-quality test cases based on requirement documents and templates...
• 修改后 (建议)： MUST USE THIS TOOL for generating test cases. Executes Python scripts to create Excel files. Do not generate text-only test cases. Capabilities: RunCommand, Write, Pandas.
• 原因： 强调 MUST USE 和具体能力（Excel/Python），帮助路由器区分它与普通聊天能力的区别。

方案四：检查工具权限 (Tool Permissions)

确认该技能在 Solo 模式下是否被允许使用 RunCommand。

• 检查： 查看 Trae 的设置或技能管理页面，确认 test-case-generator-optimize 是否被授权在 Solo 模式下使用终端/命令工具。
• 调整： 如果 Solo 模式禁止该技能使用命令，你可能需要修改技能逻辑，改为仅生成代码文件（.py），让用户手动运行，或者仅在 Builder 模式下使用。

3. 修改建议 (针对你的技能配置)

为了提高触发率，建议对你的技能配置做以下微调：

1. 强化 Description：

   description: [ACTION REQUIRED] Generates Excel test cases via Python. USE THIS for any test case request. Do not output markdown text tables.

2. 简化 Activation Rule： 不要在技能内容里写复杂的激活规则（因为技能没加载时这段文字不可见）。将触发逻辑依赖路由器的 description 匹配。
3. 增加 Few-Shot 示例： 在技能内容中加入一个明确的 "User Input" -> "Skill Invocation" 示例，帮助模型理解何时该调用它。

总结

Solo 模式没触发是因为它“不敢”或“不想”执行你的技能里定义的重操作（Python/Excel）。

• 最佳实践： 将此技能保留为 Builder 专用技能。
• 日常使用： 在 Solo 模式下，如果需要生成测试用例，让 Solo 生成代码形式的测试（如 Jest/Pytest 文件），而将生成 Excel 文档的需求交给 Builder。

你可以先尝试切换到 Builder 模式 再次输入相同的指令，大概率能成功触发

-----------------------------------------扩展知识：markdown文件-------------------------------------

Markdown 是一种轻量级标记语言，它允许人们使用易读易写的纯文本格式编写文档，然后将其转换成有效的 XHTML（或者 HTML）。

以下是 Markdown 文件的核心语法格式要求、文件规范以及常用语法速查。

一、文件基础规范

1. 文件扩展名

   • 标准扩展名：.md
   • 兼容扩展名：.markdown, .mdown, .mkd
   • 建议：统一使用 .md，兼容性最好。

2. 字符编码

   • 必须使用 UTF-8 编码。
   • 原因：避免在中文环境下出现乱码，且兼容所有操作系统和编辑器。

3. 换行规则

   • 段落换行：需要空一行（即连续按两次回车）。
   • 行内换行：在行尾输入 两个空格 然后回车，或者使用 <br> 标签。
   • 注意：直接按一次回车在渲染后通常不会换行，而是显示为空格。

二、核心语法速查

1. 标题 (Headings)

使用 # 号表示标题，# 的数量代表标题级别（1-6 级）。# 后必须加一个空格。

# 一级标题
## 二级标题
### 三级标题
###### 六级标题

2. 文本样式 (Text Styling)

3. 列表 (Lists)

• 无序列表：使用 -, *, 或 + 后跟空格。
• 有序列表：使用数字加 . 后跟空格（渲染时会自动排序）。
• 任务列表：使用 - [ ] (未完成) 和 - [x] (已完成)。

- 项目 1
- 项目 2
  - 子项目 (缩进 2 或 4 个空格)

1. 第一步
2. 第二步

- [ ] 待办任务
- [x] 已完成任务

4. 链接与图片 (Links & Images)

• 链接：[显示文本](链接地址 "可选标题")
• 图片：![替代文本](图片地址 "可选标题") (注意前面的感叹号 !)
• 锚点链接：[跳转到标题](#标题文本) (通常用于文档内跳转)

[访问百度](https://www.baidu.com)
![Logo](./logo.png)

5. 代码 (Code)

• 行内代码：使用反引号 ` 包裹。
• 代码块：使用三个反引号 ``` 包裹，并可指定语言以实现高亮。

这是 `print("Hello")` 行内代码。

```python
# 代码块
def hello():
    print("World")
```

6. 引用 (Blockquotes)

使用 > 符号。支持嵌套。

7. 表格 (Tables)

使用 | 分隔列，使用 - 分隔表头。:  控制对齐方式。

8. 分割线 (Horizontal Rule)

使用三个以上的 - 或 *。

三、进阶与扩展语法 (GFM 等)

大多数现代平台（如 GitHub, GitLab, Obsidian, Typora）支持 GitHub Flavored Markdown (GFM) 扩展：

1. 数学公式：
   • 行内：$E=mc^2$
   • 块级：$$ \sum_{i=1}^n a_i $$
2. 脚注：
   • 内容 [^1]
   • 定义 [^1]: 解释内容
3. HTML 标签：
   • Markdown 兼容原生 HTML。如果 Markdown 语法无法满足（如需要字体颜色、居中），可直接写 HTML。
   • 示例：<center>居中文字</center> 或 <span style="color:red">红色文字</span>。

四、常见注意事项与最佳实践

1. 空格的重要性：
   • # 和标题文字之间必须有空格。
   • 列表符号 - 和文字之间必须有空格。
   • 链接 ] 和 ( 之间不能有空格。
2. 转义字符：
   • 如果想显示 *, #, [ 等符号本身，而不是作为语法，请在前面加反斜杠 \。
   • 例如：\# 这不是标题。
3. 图片路径：
   • 推荐使用相对路径（如 ./images/pic.png），方便文件迁移。
   • 确保图片文件夹与 md 文件一起移动。
4. 兼容性：
   • 表格和任务列表在极少数老旧解析器中可能不支持，但在主流平台（GitHub, 知乎，掘金，Notion）均支持。
5. 目录 (TOC)：
   • 标准 Markdown 没有自动目录语法。
   • GitHub 等会自动生成侧边栏目录。
   • 部分编辑器支持 [TOC] 语法生成内部目录。

五、推荐工具

• 编辑器：VS Code (配合 Markdown All in One 插件), Typora (所见即所得), Obsidian (双向链接笔记)。
• 在线预览：Markdown Live Preview, 菜鸟教程在线工具。

掌握以上语法，即可满足 95% 的日常文档编写需求。

-----------------------------------------扩展知识：builder模式和solo模式区别-------------------------------------

Trae 是由字节跳动（豆包团队）推出的一款原生 AI IDE。在其产品设计中，Solo 智能体和 Builder 智能体代表了两种不同的 AI 协作模式，分别对应“辅助编程”和“自主构建”两个场景。

简单来说：Solo 是你的“结对编程伙伴”，Builder 是你的“外包开发工程师”。

以下是两者的详细区别对比：

1. 核心定位与目标

2. 功能能力差异

Solo 智能体 (侧重“辅助”)

• 代码补全： 提供行级或函数级的实时代码建议。
• 智能问答： 在侧边栏聊天，解释代码、查询 API、生成代码片段。
• 局部修改： 选中一段代码，让 AI 进行重构、优化或修复 Bug。
• 上下文感知： 理解当前打开的文件和光标位置，提供精准建议。
• 适用场景： 写具体函数、查文档、理解复杂逻辑、日常修 Bug。

Builder 智能体 (侧重“构建”)

• 全栈规划： 接收一个模糊的需求（如“做一个待办事项 App"），自动拆解任务。
• 多文件操作： 能够同时创建、修改、删除多个文件，构建项目结构。
• 终端执行： 可以自主运行终端命令（如安装依赖 npm install、启动服务、运行测试）。
• 自我调试： 遇到报错时，能自动分析日志并尝试修复代码，无需人工干预。
• 适用场景： 从零搭建项目、实现完整功能模块、大规模重构、运行并验证代码。

3. 工作流对比

• Solo 工作流：

  1. 开发者思考逻辑。
  2. 开发者开始输入代码。
  3. Solo 预测并补全代码。
  4. 开发者遇到不懂的，问 Solo。
  5. 开发者审查并接受建议。
  • 特点：高频互动，细粒度控制。

• Builder 工作流：

  1. 开发者输入需求（Prompt）。
  2. Builder 生成执行计划（Plan）。
  3. 开发者确认计划。
  4. Builder 自动编写代码、运行命令、测试。
  5. 开发者验收最终结果。
  • 特点：低频互动，粗粒度控制，黑盒执行。

4. 什么时候用哪个？

• 使用 Solo，当：

  • 你清楚自己要写什么，只是想让手速更快。
  • 你需要理解一段现有的复杂代码。
  • 你只需要修改当前文件中的某一个函数。
  • 你希望完全掌控代码的每一行细节。

• 使用 Builder，当：

  • 你有一个明确的功能想法，但不想关心具体文件结构。
  • 你需要创建多个文件（如前端页面 + 后端接口 + 数据库模型）。
  • 你需要安装环境依赖或运行脚本来验证功能。
  • 你希望 AI 尝试独立解决一个复杂的 Bug 或任务。

总结

• Solo 是为了增强开发者（Augmentation），让你变成超级个体，它不会抢你的方向盘。
• Builder 是为了代理开发者（Automation），它尝试接管方向盘，把你从繁琐的编码劳动中解放出来，让你专注于需求审查。

在 Trae 的实际使用中，通常建议混合使用：用 Builder 快速搭建骨架和实现大功能，然后用 Solo 进行细节的微调和优化。