用技能与插件复用 Claude Code 项目规范

Claude Code 每次开新会话，都要重新解释目录结构、命名规范和测试要求，问题未必出在提示词写得不够好。作者 Davis George 的主张是：把反复交代的知识写成配置，让它在后续会话中继续生效。

这篇文章值得读的地方，是把项目约定、会话记录、工作流程和工具连接拆开处理。不过，它提供的是一套配置思路和示例，没有给出节省时间或 token 的实测对照。能拿走的是方法，收益需要自己验证。

想让 Agent 记住项目，先分清该把信息放在哪里

作者把常被统称为插件的扩展机制拆成了五类。它们解决的问题不同，不能互相替代。

CLAUDE.md 放在项目根目录，按照文章的描述，Agent 每个会话都会读取。它适合保存长期稳定的项目事实：目录怎么分、重要模块在哪里、哪些库不能用、哪些文件不能动。

Skills 是带有简短描述的 Markdown 文件。请求符合描述时，Agent 加载对应内容，按里面的清单、流程或约定执行。Slash commands 则由用户明确调用，例如 /review、/deploy-check，背后各有提示文件。两者的区别在于，一个依靠任务匹配，一个依靠显式入口。

MCP servers 连接 issue、文档、数据库或日历，让 Agent 有机会查询实际信息。Hooks 则在特定时机运行脚本，例如编辑之后格式化，或者在提交前检查测试。

所谓记忆，首先是把知识保存到下次还能读取的位置。

作者还建议用 MEMORY.md 或 notes 文件保存会话决策：为什么选 library X 而没选 Y、某个不稳定测试是什么原因、已经修过哪些问题。会话结束时更新，下次开始先读。

这里有个容易漏掉的前提：文件存在，不代表读写流程已经建立。文章提出了记录模式，却没有给出自动更新、处理过期记录或解决冲突的完整实现。团队需要明确维护方式，否则旧结论也会被带进新任务。

减少重复读取，比继续堆上下文更值得先做

作者提出的五个扩展方向里，模型路由和上下文管理都指向同一件事：把资源用在真正需要的地方。

简单重命名、修正文档注释，可以交给更小、更快的模型；复杂重构再使用更强的模型。有些配置还能在一个提供商触发限流后，自动切到另一个提供商。不过，原文没有指定路由工具、模型组合或判断标准，这部分是原则性建议，不能直接当作配置方案。

上下文也需要类似的取舍。Agent 每次回答问题都扫描相同的十个文件，就会反复消耗读取这些代码的 token。作者建议在 CLAUDE.md 中放一份简短架构说明，并通过代码索引或映射定位目标，减少整文件读取。

对前端和全栈仓库，这个思路很实用：先告诉 Agent 页面、共享组件、接口封装分别在哪里，再围绕当前问题读取代码。架构说明的作用是帮助定位，不必把整个仓库抄进去。

连接外部工具也遵循同样的节制。作者建议先接一个能解决真实麻烦的来源，通常是 issue 或文档，确认有用后再扩展。文章说 MCP 配置通常只需几行 JSON，但没有展示实例，也没有讨论权限和认证，不能据此判断自己团队的接入成本。

把「帮我检查一下」写成能复用的审查流程

文章最具体的例子，是把审查要求保存到 .claude/skills/review/SKILL.md。它要解决的是：每次功能或缺陷修复结束后，都按同一套标准检查变更。

---
name: review
description: "Review code changes for correctness, security, and consistency with this repo's conventions. Use after implementing a feature or fixing a bug."
---

## Code review

1. Read the diff, not the whole file. Focus on what changed.
2. Check: does it handle the error paths? Are inputs validated at the boundary?
3. Check: does it follow the conventions in CLAUDE.md (naming, error handling, logging)?
4. List findings as: BLOCKER, SHOULD-FIX, NIT. Never rewrite the code yourself — report and let the human decide.
5. If tests are missing for changed behaviour, say so explicitly.

要看的是 description 和第 4 条：前者描述何时使用，后者规定输出边界。审查结果按 BLOCKER、SHOULD-FIX、NIT 分级，Agent 只报告，由人决定是否修改。

配套的 CLAUDE.md 则提供检查依据：TypeScript 使用 strict mode，新增代码禁用 any；错误以带类型的结果返回，不跨模块边界抛出；测试使用 vitest，*.test.ts 与代码放在一起，宣称完成前运行 npm test；禁止提交 secrets，禁止手动修改 migrations/。

流程和规则由此接上了。Skill 规定「怎么检查」，项目文件规定「按什么标准检查」。

作者还给出一个编辑后自动执行检查命令的 Hook：

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [{ "type": "command", "command": "npm run lint:fix" }]
      }
    ]
  }
}

要看 matcher 和 command：Edit|Write 匹配后执行的是 npm run lint:fix。它究竟能否同时完成格式化和 lint 修复，取决于仓库中这个脚本的定义，配置本身没有保证。

作者的推进节奏也很克制：先写一个 Skill，用一周，观察哪里执行不对，修改措辞后再加下一个。

我的判断

我赞同把重复约定纳入仓库管理。相较于每次手动粘贴提示词，配置文件更容易审查、共享和修订；相较于把所有要求塞进 CLAUDE.md，按任务加载 Skill 也更便于维护。

但自然语言清单仍然需要 Agent 理解和执行。npm test 是否真的运行、migrations/ 是否被修改，能由脚本和检查工具验证的，就应该配上相应机制。Skill 适合描述流程和判断要求，确定性的检查仍有自己的位置。

文件能保存约定，不能保证约定始终正确，也不能保证 Agent 每次都遵守。

作者称会话记录是自己发现的高收益习惯，却没有提供实验过程或对照数据，这是经验之谈。文中的「50% fewer tokens」也是提醒读者谨慎看待的宣传示例，并非作者取得的结果。模型路由、索引查询能省多少，同样需要结合实际任务测量。

第三方插件还应按依赖来管理：阅读内容、固定版本、有意识地更新，尤其要检查执行 shell 的部分。作者认为五个写得好的 Skills 胜过五十个安装项，我认同这个取舍方向，但这也不是经过量化验证的效果排名。

能拿来做什么

• 先给当前仓库写一份短 CLAUDE.md，记录目录入口、测试命令和修改禁区，让 Agent 更快找到代码，并有明确的完成标准。
• 把最常重复的一类要求做成 Skill，例如检查 TypeScript 变更的错误路径、输入校验和测试缺失，使用一周后根据误判修改描述。
• 用 MEMORY.md 记录会影响后续任务的决策和已知问题，并建立会话结束更新、下次开始读取的步骤，避免把整段聊天原样堆进去。
• 在增加模型路由、代码索引或 MCP 连接前后，对比同类任务的 token 消耗和人工纠正次数，只保留确实减少重复工作的配置。