02 · 三个内置技能

设计 debug、review、refactor 三个内置 skill，每种技能为模型定义特定的工作步骤和输出要求。

为什么是这三个

debug、review、refactor 覆盖了 coding agent 最常见的三类任务：

debug：出了问题，要找到原因并修复
review：代码写好了，要检查质量
defactor：代码能跑，但结构不好，要改进

这三类任务的工作方式差异很大。debug 需要系统性地追踪错误链路，review 需要从多个维度检查代码质量，refactor 需要小步修改并持续验证。如果只用通用的系统提示词，模型很难自动切换到正确的工作模式。

Debug Skill

Debug skill 告诉模型用"复现 → 定位 → 修复"三步法来处理 bug：

export const debugSkill: Skill = {
  name: "debug",
  description: "定位和修复 bug",
  keywords: ["bug", "fix", "error", "报错", "错误", "崩溃", "修复", "调试", "debug"],
  instructions: [
    "## Debug 技能",
    "",
    "你正在使用 debug 技能来定位和修复 bug。请按以下步骤工作：",
    "",
    "### 第一步：复现问题",
    "- 使用 read_file 工具读取报错相关的文件",
    "- 使用 run_command 工具运行相关命令，确认问题能复现",
    "- 记录完整的错误信息和堆栈跟踪",
    "",
    "### 第二步：定位根因",
    "- 从错误信息出发，使用 search 工具追踪代码调用链",
    "- 读取相关文件，找到出错的函数或模块",
    "- 区分表面现象和根本原因",
    "",
    "### 第三步：实施修复",
    "- 优先使用 patch_file 工具精确修改出错的部分",
    "- 修复后立即使用 run_command 运行相关测试验证",
    "- 如果修复引入新问题，回退并尝试其他方案",
    "",
    "### 输出要求",
    "- 说明根因是什么",
    "- 解释修复思路",
    "- 附上修复后的测试结果",
  ].join("\n"),
};

这个 skill 的 instructions 定义了结构化的工作流程：

先复现——不急于修复，先确认问题真的存在。很多"bug"其实是环境问题或使用方式错误。
再定位——追踪调用链，找到真正的出错位置。错误信息和出错的代码可能相隔好几层调用。
最后修复——精确修改，立即验证。每一步都有工具支撑，不是凭空猜测。

Review Skill

Review skill 告诉模型从三个维度审查代码：

export const reviewSkill: Skill = {
  name: "review",
  description: "代码审查",
  keywords: ["review", "审查", "reviewer", "检查代码", "code review"],
  instructions: [
    "## Code Review 技能",
    "",
    "你正在使用 code review 技能来审查代码。请从以下三个维度进行审查：",
    "",
    "### 正确性",
    "- 逻辑是否正确？边界条件是否处理？",
    "- 是否有类型错误、空指针、越界等常见问题？",
    "- 使用 search 工具查看调用方，确认接口使用是否正确",
    "",
    "### 安全性",
    "- 是否有注入风险（SQL、命令、XSS）？",
    "- 是否有敏感信息泄露（密钥、token 硬编码）？",
    "- 权限检查是否完整？",
    "",
    "### 可读性与可维护性",
    "- 命名是否清晰？是否有误导性的变量名？",
    "- 函数职责是否单一？是否需要拆分？",
    "- 是否有可以简化的复杂逻辑？",
    "",
    "### 输出要求",
    "- 按严重程度排列问题（Critical / Warning / Suggestion）",
    "- 每个问题给出具体的修改建议",
    "- 用 search 和 read_file 工具查看上下文后再给出建议",
  ].join("\n"),
};

三个维度是代码审查的经典分类：正确性（能不能跑）、安全性（会不会出事）、可读性（好不好维护）。每个维度都引导模型使用工具获取实际信息，而不是凭空猜测。

Refactor Skill

Refactor skill 告诉模型用"小步修改 + 持续验证"的方式重构代码：

export const refactorSkill: Skill = {
  name: "refactor",
  description: "代码重构",
  keywords: ["refactor", "重构", "优化", "整理", "clean up", "改进"],
  instructions: [
    "## Refactor 技能",
    "",
    "你正在使用 refactor 技能来改进代码结构。请遵循以下原则：",
    "",
    "### 重构原则",
    "- 小步修改，每次只改一个方面",
    "- 每步修改后运行测试，确保行为不变",
    "- 优先消除重复代码，其次改善命名，最后调整结构",
    "",
    "### 工作步骤",
    "1. 使用 search 和 read_file 理解当前代码结构",
    "2. 使用 create_todos 创建重构计划",
    "3. 逐个执行重构步骤，每步用 patch_file 精确修改",
    "4. 每步修改后用 run_command 运行测试验证",
    "",
    "### 输出要求",
    "- 说明重构了什么、为什么重构",
    "- 附上重构前后的对比",
    "- 附上测试通过的验证结果",
  ].join("\n"),
};

重构的核心原则是"小步前进"——每次只改一个方面，改完就测试。这和 debug 的"先定位再修复"不同，强调的是渐进式改进和持续验证。

instructions 的设计原则

三个 skill 的 instructions 都遵循相同的设计原则：

告诉模型"怎么做"，不只是"做什么"。 不说"修复 bug"，而是说"先复现、再定位、再修复"。这种结构化的步骤指引，比模糊的指令更有效。

引导使用工具。 每个步骤都提到具体的工具名（search、read_file、run_command 等）。这和系统提示词中的"不要猜测"原则一脉相承。

定义输出要求。 "说明根因"、"按严重程度排列"、"附上测试结果"——明确的输出格式让模型的回答更有结构。

用 markdown 标题分层。 使用 ### 标题来组织指令，模型能清楚地看到步骤之间的区分。

下一节讲解怎么让这些 skill 被正确触发。

登录以继续阅读

解锁完整文档、代码示例及更多高级功能。

立即登录