「Lint 修复循环」是开发者的高频任务。它的输入通常是项目仓库与 lint 命令，期望得到的是修复后的代码与剩余问题清单。这类有固定流程、又需要一点判断力的工作，很适合封装成智能体 Skill。

背景（虚构）

小林是一名开发者，每周都要做几次Lint 修复循环。过去靠复制粘贴提示词，结果不稳定。这次团队把它做成了技能，下面记录一次完整运行。

1. 发出请求

小林在代码仓库与终端中输入：

帮我做一下Lint 修复循环，材料是附上的项目仓库与 lint 命令。

2. 技能被触发

智能体根据技能描述判断任务匹配，加载「Lint 修复循环」的完整指令。它先运行技能自带的脚本做预处理，确保后续分析基于准确的数据。

3. 读取项目 lint 配置

“读取项目 lint 配置”是最容易出错的环节，技能里专门写了要求，所以智能体给出了清楚的结果与理由。

4. 运行 lint 并解析输出

智能体完成“运行 lint 并解析输出”，并在中间结果里注明依据，方便小林回看。

5. 按文件分组修复

智能体完成“按文件分组修复”，并在中间结果里注明依据，方便小林回看。

6. 复跑确认并汇总

智能体完成“复跑确认并汇总”，并在中间结果里注明依据，方便小林回看。

7. 交付与复核

智能体交付修复后的代码与剩余问题清单，末尾列出两条需人工确认的内容。小林对照原始项目仓库与 lint 命令抽查关键信息，修正一处表述后采用。

复盘：这次做对了什么

  • 步骤写在技能里，没有遗漏
  • 不确定处被标出，而不是被编造
  • 遵守了「改动前确认有测试与版本控制，一次只改一类问题」
  • 风险较低，但输出仍需快速过目再使用

可以改进的地方

小林发现智能体对团队内部术语理解不一致，于是在技能目录中加了一份术语表（reference.md），并在 SKILL.md 中写明“遇到术语先查表”。更多改法见定制指南。

准备一份好范例

在技能的参考资料里放一份你认可的修复后的代码与剩余问题清单范例，往往比多写十条规则更有效。好范例应当：

  • 来自真实工作，但已去除个人信息和敏感数据
  • 体现团队习惯的结构、措辞和详略程度
  • 包含一处“需人工确认”的标注示范，让智能体学会如何表达不确定
  • 篇幅适中，不要比平时的产出长太多

范例不必多，一到两份即可；太多范例反而会让智能体机械模仿某一份的细节。

每一步要产出什么

把每一步的中间产出写清楚，智能体就不容易跳步，人也方便定位问题：

  1. 读取项目 lint 配置：产出一段简短的中间结果，并注明依据来自项目仓库与 lint 命令的哪一部分
  2. 运行 lint 并解析输出：产出一段简短的中间结果，并注明依据来自项目仓库与 lint 命令的哪一部分
  3. 按文件分组修复：产出一段简短的中间结果，并注明依据来自项目仓库与 lint 命令的哪一部分
  4. 复跑确认并汇总：产出一段简短的中间结果，并注明依据来自项目仓库与 lint 命令的哪一部分

最后一步之后，再把这些中间结果汇总成修复后的代码与剩余问题清单。中间结果可以折叠或省略展示，但在技能指令中要求智能体“先完成再汇总”，能明显减少遗漏。

延伸阅读

说明：文中的配置、代码与目录结构均为示意，用于说明思路；各平台的入口、字段名与能力会更新，落地前请以对应官方文档为准。示例中的数据与场景为虚构，不代表真实案例。