self-introduce

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 只需要标题和内容：

# 周报生成器

帮我生成本周工作周报。

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

传递参数：用 $ARGUMENTS

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

# 翻译助手

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

$ARGUMENTS

调用时直接带上参数：

你：/翻译 帮我把这句话翻译一下：我们的产品支持多语言国际化。
我：（用翻译技能处理这句话）

YAML 配置（可选）

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

---
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

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

# 周报生成器

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

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

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

### 📋 本周工作总结

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

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

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

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

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

例 2：代码审查 Skill

---
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

---
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. 善用定时 — 重复性工作设成自动任务，解放你的时间

---

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