---
name: self-introduce
description: 向零基础用户全面介绍 xbot 的能力，教会正确用法
---

# 🤖 你好，我是 xbot！

> 我不是一个普通的聊天机器人。我是你的**私人工作助手**——能读文件、跑命令、搜索网页、管理日程、对接你用的各种办公软件，甚至能自动帮你干活。
>
> **不需要任何技术背景。** 像跟同事说话一样跟我说就行。

---

## 🌟 我能做什么？

简单说：**大部分你在电脑上做的事，我都能帮你做。**

### 📖 搜索和整理信息

```
你：帮我在知识库里找一下关于"新员工入职流程"的文档，总结要点
我：搜索知识库 → 找到 3 篇文档 → 提取关键步骤 → 整理成清单给你
```

```
你：最近 AI 行业有什么大新闻？
我：搜索最新新闻 → 筛选重要资讯 → 总结成 3-5 条要点
```

### 📊 处理表格和数据

```
你：帮我看一下这个月多维表格里的销售数据，找出增长最快的产品
我：读取表格数据 → 计算增长率 → 排序 → 生成分析报告
```

### 💻 帮你改文件、写代码

```
你：帮我把 config.yaml 里的端口号从 3000 改成 8080
我：找到文件 → 修改端口号 → 确认修改完成
```

```
你：帮我写一个 Python 脚本，批量重命名文件夹里的图片
我：编写脚本 → 测试运行 → 确认结果正确
```

### 📅 定时自动任务

```
你：每天早上 9 点帮我生成一份项目日报，发到这个群里
我：设置定时任务 → 每天自动收集信息 → 整理成日报 → 发送到群里
```

```
你：每周五下午 5 点提醒我提交周报
我：设置提醒 → 每周五准时通知你
```

### 🔗 对接你的办公工具

我可以直接操作你常用的工具，不需要你来回切换：

| 工具 | 我能做什么 |
|------|-----------|
| **飞书知识库** | 搜索文档、总结内容、提取关键信息 |
| **飞书多维表格** | 读取数据、筛选排序、生成报告 |
| **GitHub** | 查看 PR、搜索代码、审查代码变更 |
| **网页** | 抓取网页内容、搜索最新资讯 |
| **文件系统** | 读写文件、搜索代码、执行命令 |

### 🧠 我会记住你说过的话

```
你：记住，我们团队用 TypeScript，代码规范遵循 Airbnb
我：记住了！以后写代码我会遵循这些规范。

（几天后……）

你：帮我写一个工具函数
我：（自动使用 TypeScript + Airbnb 风格）
```

我不只是"记住"——我会在合适的时候**主动用到**这些信息。

---

## 💬 怎么跟我说话

### 核心原则：说人话就行

| ✅ 这样说 | ❌ 不用这样说 |
|-----------|-------------|
| "帮我查一下这个 bug" | "你是一个程序员，请分析这个 bug……" |
| "把这份报告翻译成英文" | "请扮演翻译专家，将以下内容翻译……" |
| "总结一下今天的会议记录" | "你的任务是提取以下文本的关键信息……" |

你不需要：
- ❌ 写复杂的指令格式
- ❌ 告诉我用什么工具（我会自己选）
- ❌ 担心自己说得不准确（我会理解你的意思）

### 复杂任务怎么说

对于复杂任务，直接把需求说清楚就好，我会自己拆解步骤：

```
你：帮我做一次项目巡检：
1. 检查 GitHub 上有没有新的 PR 和 Issue
2. 跑一下测试看看有没有失败的
3. 检查依赖有没有安全漏洞
4. 把结果整理成报告发到群里

我：（自动分步执行 → 汇总结果 → 生成报告 → 发送到群里）
```

### 纠正和调整

如果我做得不对，直接纠正我：

```
你：不对，我说的不是那个文件，是 src/utils/config.ts
我：好的，我来查看这个文件。
```

```
你：格式不对，用表格展示，按时间排序
我：好的，重新整理。
```

---

## 🚀 更厉害的用法

### 🤝 让我调用专家

遇到专业问题，我可以召唤"专家角色"来帮忙：

```
你：让代码审查专家帮我看看这段代码有没有问题
我：（召唤代码审查专家 → 专业分析 → 反馈结果）
```

### 🔄 自动化工作流

把重复性的工作交给我，设置一次，永久自动执行：

```
你：帮我建一个每日巡检任务：
- 每天早上 9 点
- 检查项目状态、代码质量、安全漏洞
- 把结果发到"技术团队"群

我：好的，已设置。每天 9:00 我会自动执行巡检并汇报。
```

### 📝 积累团队知识

重要讨论和决策，让我帮你记录：

```
你：把刚才关于架构选型的讨论记下来
我：（自动存入长期记忆）

（一周后……）

你：上次架构选型我们最后定了什么方案？
我：上次讨论决定采用微服务架构，主要考虑了……（从记忆中检索）
```

### 🌐 实时追踪动态

```
你：帮我关注一下 React 19 有没有发布正式版
我：（设置关注）→ 有新消息时主动通知你
```

---

## 📦 Skill：让我学会新技能

> 想让我变成某个领域的专家？给我一本"技能说明书"，我就能照着做。

### 什么是 Skill？

想象一下，你买了一个智能音箱。刚买来的时候它只会简单对话，但你给它下载了一个"菜谱技能包"——突然它就能推荐菜谱、报食材清单了。

**Skill 就是我的"技能包"。** 你给我写一本说明书（一个 Markdown 文件），我就学会了新技能。

创建一个 Skill 只需要两步：
1. 在 `.xbot/skills/` 目录下建一个文件夹，比如 `.xbot/skills/周报生成/`
2. 在里面放一个 `SKILL.md` 文件，写下你想让我做的事

```
.xbot/skills/
├── 周报生成/
│   └── SKILL.md        ← 周报生成技能的"说明书"
├── 代码审查/
│   └── SKILL.md        ← 代码审查技能的"说明书"
└── 翻译助手/
    └── SKILL.md        ← 翻译技能的"说明书"
```

### 怎么写 SKILL.md？

SKILL.md 本质上就是一份**给 AI 看的说明书**。你只需要用自然语言告诉我要做什么。

最简单的 Skill 只需要标题和内容：

```markdown
# 周报生成器

帮我生成本周工作周报。

## 格式要求
- 列出本周完成的主要工作
- 标注每项工作的进度（✅ 已完成 / 🔄 进行中 / ⏳ 待开始）
- 列出下周计划
- 列出需要协调的事项
```

### 传递参数：用 `$ARGUMENTS`

如果你的 Skill 需要接收用户输入，用 `$ARGUMENTS` 占位符：

```markdown
# 翻译助手

请将以下内容翻译成英文，保持专业术语的准确性：

$ARGUMENTS
```

调用时直接带上参数：
```
你：/翻译 帮我把这句话翻译一下：我们的产品支持多语言国际化。
我：（用翻译技能处理这句话）
```

### YAML 配置（可选）

在 SKILL.md 开头可以加 YAML 配置，控制 Skill 的行为：

```markdown
---
name: 周报生成
description: 根据用户提供的信息生成格式规范的周报
disable-model-invocation: false
allowed-tools:
  - Read
  - Write
---

# 周报生成器
...
```

| 配置项 | 说明 | 默认值 |
|--------|------|--------|
| `name` | Skill 名称（不填则用文件夹名） | 文件夹名 |
| `description` | 一句话描述 Skill 的用途（帮助 AI 判断何时自动调用） | 无 |
| `disable-model-invocation` | 设为 `true` 则 AI 不会自动调用，只能手动 `/skill名` 触发 | `false` |
| `allowed-tools` | 限制该 Skill 能使用的工具列表（不填则不限制） | 无限制 |

### 怎么调用 Skill？

| 方式 | 说明 | 示例 |
|------|------|------|
| **手动调用** | 用 `/技能名` 或 `/技能名 参数` | `/周报生成`、`/翻译 这段话的意思是...` |
| **自动调用** | AI 根据你的描述自动判断该用哪个 Skill | "帮我生成本周周报" → 自动触发周报生成 Skill |

> 💡 **小技巧**：`description` 写得越准确，AI 越容易在正确的时候自动调用你的 Skill。

### 实用例子

#### 例 1：周报生成 Skill

```markdown
---
name: 周报生成
description: 根据用户提供的工作内容生成格式规范的周报
disable-model-invocation: false
---

# 周报生成器

你是一位专业的项目经理助手。请根据用户提供的信息，生成一份格式规范的周报。

## 输入
用户会提供本周的工作内容，可能是：
- 随口说的几句话
- 一段文字描述
- 一系列要点

## 输出格式
请按以下格式输出：

### 📋 本周工作总结

**1. [工作项标题]** — ✅ 已完成
- 具体做了什么
- 产出是什么

**2. [工作项标题]** — 🔄 进行中（进度 xx%）
- 当前进展
- 预计完成时间

### 📅 下周计划
1. ...

### ⚠️ 需要协调的事项
- ...

## 注意事项
- 如果用户说的信息不够，主动提问补充
- 语言简洁专业，不要啰嗦
- 进度尽量量化
```

#### 例 2：代码审查 Skill

```markdown
---
name: 代码审查
description: 对指定的代码文件或 PR 进行专业审查，发现问题并给出改进建议
disable-model-invocation: false
allowed-tools:
  - Read
  - Search
---

# 代码审查助手

你是一位资深工程师。请对用户指定的代码进行专业审查。

## 审查维度
1. **正确性** — 逻辑是否正确？有没有明显的 bug？
2. **可读性** — 变量命名是否清晰？代码结构是否易理解？
3. **性能** — 有没有明显的性能问题？（如 N+1 查询、内存泄漏风险）
4. **安全性** — 有没有安全隐患？（如 SQL 注入、XSS、敏感信息硬编码）
5. **最佳实践** — 是否遵循了常见的编码规范和设计模式？

## 输出格式

### 审查结果

**总体评价**：⭐⭐⭐⭐☆（4/5）

| 严重程度 | 问题 | 位置 | 建议 |
|----------|------|------|------|
| 🔴 高 | ... | 第 xx 行 | ... |
| 🟡 中 | ... | 第 xx 行 | ... |
| 🟢 低 | ... | 第 xx 行 | ... |

### 改进建议
1. ...
```

#### 例 3：翻译 Skill

```markdown
---
name: 翻译助手
description: 将文本翻译成指定语言，保持专业术语准确、语句自然流畅
disable-model-invocation: false
---

# 翻译助手

你是一位专业翻译，精通中英双语。

## 输入格式
用户会提供：翻译目标语言 + 待翻译内容
如果没有指定目标语言，默认翻译成英文。

## 翻译原则
1. **准确性优先** — 专业术语必须翻译准确
2. **自然流畅** — 不要机翻味，要像母语者写的
3. **保留格式** — Markdown 格式、代码块、链接等保持原样
4. **适当意译** — 成语和俗语要翻译出含义，不是字面翻译

## 输出格式
直接输出翻译结果，不需要额外解释。
如果原文中有不确定的翻译，在文末用注释标注。

$ARGUMENTS
```

### ✅ 正确 vs ❌ 错误 对比

| ❌ 错误写法 | ✅ 正确写法 | 原因 |
|-------------|-------------|------|
| 只写标题，没有内容说明 | 标题 + 详细的格式要求和注意事项 | AI 需要明确知道你要什么 |
| `帮我做周报` | `根据用户提供的信息，按以下格式生成周报：...` | 越具体，AI 做得越好 |
| 把 Skill 当 Prompt 用，塞一堆无关内容 | 聚焦一个明确的功能 | Skill 贵精不贵多 |
| 不写 `description` | 写清用途描述，方便 AI 自动调用 | 没有描述 AI 不知道什么时候用 |

### ❓ 常见问题

**Q：Skill 和直接跟我说有什么区别？**
A：直接说也行！Skill 的优势在于——你可以把反复用的操作固化下来，调用更方便，而且 AI 知道你期望的格式和风格。

**Q：我需要会编程才能写 Skill 吗？**
A：完全不需要。Skill 就是 Markdown 文本，用自然语言写就行。会写文档就会写 Skill。

**Q：可以给 Skill 传文件吗？**
A：可以！调用 Skill 时把文件路径告诉我就行，我会读取文件内容再按 Skill 的要求处理。

**Q：Skill 会影响其他对话吗？**
A：不会。每个 Skill 只在调用时生效，不会改变我其他时候的行为。

---

## 🏛️ SubAgent：召唤专家团队

> 一个人再厉害也干不过一个团队。遇到大任务，我会召唤"专家团队"来协同完成。

### 什么是 SubAgent？

你有没有遇到过这种情况：公司要搞一个大项目，不是一个人能搞定的，需要**各个部门配合**——有人写方案，有人审核质量，有人具体干活，有人测试验收。

**SubAgent 就是我的"专家团队"。** 当任务比较复杂时，我不会一个人硬扛，而是召唤合适的专家来分工协作。

为了方便理解，你可以把我们想象成一个**古代朝廷**：

| 角色 | 类比 | 职责 |
|------|------|------|
| 🤖 **我（主 AI）** | 太子 | 接收你的指令，判断该派给谁，统筹全局 |
| 📋 **规划者** | 中书省 | 遇到复杂问题，制定详细的执行方案 |
| 🔍 **审核者** | 门下省 | 审查方案质量，发现遗漏和错误 |
| ⚡ **执行协调者** | 尚书省 | 把方案拆成具体任务，分派给专员执行 |
| 🧑‍💻 **各部专员** | 六部 | 各有专长，负责具体工作 |
| ↳ 吏部 | 人事专员 | 环境搭建、权限配置、资源安排 |
| ↳ 户部 | 数据专员 | 数据处理、信息检索、日志分析 |
| ↳ 礼部 | 文档专员 | 文案撰写、文档编写、发布公告 |
| ↳ 兵部 | 安全专员 | 安全审计、漏洞扫描、权限检查 |
| ↳ 刑部 | 测试专员 | 测试编写、质量验证、Bug 排查 |
| ↳ 工部 | 工程专员 | 代码编写、方案落地、技术实施 |

你不需要记住这些角色——**只需要告诉我你想做什么，我会自动判断要不要召唤专家、召唤哪些专家。**

### 基本用法：让我召唤专家

你不需要知道具体的技术细节，只需要正常表达你的需求：

```
你：帮我审查一下这个项目的代码质量
我：（判断需要专业审查 → 召唤安全专员和测试专员 → 协同完成 → 汇报结果）
```

```
你：帮我制定一个技术方案，把我们的系统从单体架构迁移到微服务
我：（判断这是一个复杂规划任务 → 召唤规划者制定方案 → 审核者审查 → 工程专员评估可行性 → 汇报完整方案）
```

当你看到我说"正在召唤专家"或类似的话时，就说明我已经在组织团队协作了。

### 多轮对话模式（Interactive）

有些任务不是一句话就能完成的，需要**来回讨论**——比如制定方案时，我可能需要先给你一个初稿，你提出修改意见，我再调整。

这就是"多轮对话模式"。遇到这类任务时，我会自动启用：

```
你：帮我制定一个用户系统的重构方案

我：（召唤规划者）
   → 分析现有代码结构
   → 制定初步方案

我：方案初稿如下：
   1. 拆分用户模块为独立服务
   2. 引入缓存层
   3. ...
   你觉得这个方向对吗？有什么要调整的？

你：第 2 点的缓存方案我觉得用 Redis 比较好
    还有，需要考虑数据迁移的兼容性

我：（继续和专家讨论，更新方案）
   → 已更新：缓存方案改为 Redis
   → 新增：数据迁移兼容性方案

我：已更新方案，请过目：
   1. ...
   2. 缓存层（Redis）
   3. 数据迁移方案（兼容旧数据）
   ...
```

> 💡 **简单理解**：简单任务我直接搞定，复杂任务我会拉着专家跟你反复讨论，直到满意为止。

### 实用例子

#### 例 1：让代码审查专家审查代码

```
你：帮我全面审查一下 src/auth/ 目录下的代码，重点关注安全问题

我：（自动组织审查流程）
   → 召唤安全专员审查安全漏洞
   → 召唤测试专员检查逻辑正确性
   → 汇总所有发现的问题
   → 按严重程度排序

我：审查完成，发现以下问题：

   🔴 高风险：2 个
   - auth/token.go 第 45 行：Token 过期时间硬编码为 24 小时，建议改为可配置
   - auth/password.go 第 23 行：密码比较使用了明文对比，应使用常量时间比较

   🟡 中风险：3 个
   - ...

   ✅ 已给出每个问题的修复建议，需要我直接修复吗？
```

#### 例 2：让方案规划师制定技术方案

```
你：我们要给项目加上实时消息推送功能，帮我制定一个技术方案

我：（召唤规划者）
   → 调研项目现状
   → 评估可选方案（WebSocket / SSE / 长轮询）
   → 制定推荐方案

我：技术方案如下：

   ## 方案概述
   推荐 WebSocket 方案，理由是...

   ## 架构设计
   - 消息网关：...
   - 连接管理：...
   - 消息分发：...

   ## 实施步骤
   1. 第一阶段：搭建消息网关
   2. 第二阶段：接入业务模块
   3. 第三阶段：压测和优化

   ## 风险评估
   - ...

你：第一阶段的工期能缩短吗？我们两周内要上线基础版

我：（调整方案，给出精简版实施计划）
```

#### 例 3：让测试工程师写测试用例

```
你：帮我给 src/payment/ 目录下的支付模块写单元测试，覆盖率要达到 80%

我：（召唤测试专员）
   → 分析支付模块的代码结构
   → 识别需要覆盖的核心逻辑
   → 编写测试用例
   → 运行测试并确认覆盖率

我：测试编写完成，结果如下：

   ✅ 新增测试文件：payment_test.go
   ✅ 测试用例：15 个（全部通过）
   ✅ 覆盖率：87%（目标 80%，已达标）

   测试覆盖场景：
   - 正常支付流程 ✅
   - 余额不足 ✅
   - 超时处理 ✅
   - 并发支付 ✅
   - ...
```

### ✅ 正确 vs ❌ 错误 对比

| ❌ 错误用法 | ✅ 正确用法 | 原因 |
|-------------|-------------|------|
| "你是一个测试工程师，请帮我写测试" | "帮我给这个模块写测试，覆盖率 80%" | 不需要角色扮演，直接说需求 |
| 一次说 10 个不相关的小任务 | 把相关任务放在一起说 | 专家协作需要聚焦 |
| "用 SubAgent 帮我审查代码" | "帮我审查这段代码" | 不需要知道技术名词，说人话就行 |
| 任务太模糊："帮我优化项目" | "帮我优化数据库查询性能，目标是响应时间降到 200ms 以内" | 目标越清晰，专家干得越好 |

### ❓ 常见问题

**Q：每次都会召唤专家吗？**
A：不会。简单的任务（比如查个文件、改个配置）我自己就能搞定，不需要兴师动众。只有复杂任务才会召唤专家团队。

**Q：召唤专家会很慢吗？**
A：专家们可以**并行工作**，所以有时候比你想象的快。比如同时审查安全和测试，不会一个一个排队。

**Q：我能指定用哪个专家吗？**
A：通常不需要——我会根据任务自动选择最合适的专家。如果你想指定，也可以直接说，比如"让安全专员重点看一下"。

**Q：专家的审查结果靠谱吗？**
A：所有专家的产出都会经过**审核者**（门下省）复核，确保质量过关才会交给你。

**Q：多轮对话模式下我可以随时修改需求吗？**
A：当然可以！随时提出修改意见，专家会根据你的反馈调整方案。这就是多轮模式的意义——一起讨论直到满意。

---

## 💡 使用小贴士

1. **大胆说** — 你想不到的事我可能真的能做，试试看
2. **说清楚** — 越具体的需求，我做得越好
3. **让我记住** — 告诉我你的偏好和习惯，我会越来越懂你
4. **分步来** — 特别复杂的任务可以拆成几步说
5. **随时纠正** — 我做错了直接说，我会立刻调整
6. **善用定时** — 重复性工作设成自动任务，解放你的时间

---

> 🎯 **现在就开始吧！** 告诉我你想做什么，哪怕是"帮我搜一下今天的天气"这样简单的事——你会发现，我比你想的能干得多。
