Claude Coach：帮你更好地使用 Claude Code

我习惯进入一个 working directory，打开 Claude 或 Codex，直接开始写代码。后来学会了在 CLAUDE.md 里写一些约定，但新的 skills、subagents 和各种最佳实践出现得越来越快。我打开文档，一目十行，让 AI 总结各种做法，然后——眼睛都看会了，做项目的时候还是路径依赖了。

Claude Code 的 /insights 给了一个很好的入口。它把使用记录整理成报告，告诉我主要做什么项目、常用哪些工具、形成了哪些习惯，以及协作卡在哪里。

报告提到，我常让 Claude 拆分较大的功能，规划 git worktrees 和详细 spec，再推进实现；另一方面，初始技术路径不合适、外部 API 或 SDK 缺少参考资料，也会造成反复纠偏。它给出的建议很具体：把 worktree 拆分固化成自定义命令，把约束写进去，减少每次重讲规则；涉及外部接口时，先提供 demo 和 SDK 文档。

但真正让我想做 Coach 的，是报告之后发生的事：我扫了一眼，截了几张图分享给朋友，然后没有后文。报告已经足够细致，洞察却没有变成行动。

从“你可以改进”到“帮你把它做出来”

既然 agent 已经知道我反复拆分 worktree、重复写同一种 spec，为什么只告诉我这些习惯？它可以继续判断：哪些值得沉淀成 command，哪些适合抽成 skill，哪些步骤需要一条固定约束。

原文里提出的例子很直接：生成 worktree 拆分命令的模板；把常用 spec 结构整理成 skill；新建 worktree 时带上约束；调用外部 API 前提醒先给 SDK。这些是从观察推导出来的行动方向，不需要用户再独自读一遍工具生态，然后自己判断应该装什么。

我把 /insights 的报告当成另一个 agent 的输入，给它一个任务：如果你是我的开发教练，下一步要帮我做什么？Claude Coach 就是围绕这个问题写的小插件。

它要做的不是不断增加建议数量，而是找出当前最值得采用的两三个能力。可以来自已有 skill、Claude Code 命令或配置，也可以是插件；确实没有合适选项时，再根据具体需求创建新的 skill。推荐之后还要能走到配置、安装或生成这一步，才算把一条建议变成可使用的东西。

一次回顾，只改变少量工作方式

用户显式调用 /coach 后，插件获取 /insights 报告，并读取此前的推荐与选择。agent 据此组织本次建议：观察到了什么、为什么这个能力与当前工作有关、接受后会改变哪一步。

例如，反复解释同一套 spec 结构，可以成为生成专用 skill 的依据。但如果只是某次项目的临时要求，就不应直接上升为长期偏好。建议需要连着具体情境出现，用户也可以拒绝或跳过。

接受已有能力时，按相应方式安装或配置；需要定制时，由 skill-creator 帮助生成。最后把本次推荐和用户选择写回历史，接受的能力记入已安装列表，避免下一次从零开始推荐同一套东西。

原文希望 agent 更主动地把洞察变成行动，当前交互仍把回顾入口和选择权留给用户：它没有常驻监控，也没有在写代码时不断插入提醒。“外部 API 前提醒先给 SDK”这样的例子，是可沉淀进具体工作流的约束，不代表插件会自动监听所有 API 调用。

为什么把判断交给 agent

最初的设计比较像一个独立推荐系统：分别分析会话、匹配推荐、安装模板，并维护苏格拉底式提问、结构化输出等预置模板。

后续把它缩减成一个脚本和一份 skill。脚本负责从报告提取基础线索、读取并保存历史；理解这些线索、形成建议以及更新对使用者工作方式的判断，交给 Claude。通用模板库也被移除，优先寻找现有能力，必要时再生成。

这个分工让插件不必预先穷举“某种用户应该使用某种工具”。同样一个重复操作，在一个项目里值得自动化，在另一个项目里可能只是短期需求。agent 需要结合当前对话解释它，而脚本提供相对稳定的输入与记录。

历史中保留三类内容：报告提取的基础线索、agent 对工作领域和偏好的暂时理解、每次推荐以及接受或拒绝的选择。它们分别回答“看到了什么”“目前怎么理解”“用户实际怎么选”。已安装项应避免重复推荐，近期拒绝的建议则需要新的理由，才值得再次提出。

这些记录用于支持下一次判断，不应成为给用户定性的标签。某次偏好先讨论再决定，不等于这个人永远属于某种思维类型；选择拒绝一个 skill，也可能只是因为当前项目不需要它。

把反思接回工作

Claude Coach 的出发点可以概括为原文中的一句话：不要只做 reflection，要做 operationalization。

这里的 operationalization 很具体：把反复解释的要求变成配置，把重复的步骤变成命令，把已经形成的做法整理成 skill。报告是输入，少量有依据的建议是中间结果，能够在下一次工作中用起来的能力才是输出。

这是一个小插件。它保留了一个我希望继续使用的顺序：从真实协作中发现问题，解释为什么值得改，让人选择，再把选择落到可以执行的工作方式上。