爆肝 Claude 6 个月后，我用这套“钩子系统”独自重写了 30 万行代码

转载于 2025-10-29 21:50:33 发布 · 137 阅读

CC 4.0 BY-SA版权

原文链接：https://mp.weixin.qq.com/s?__biz=MzU1MzY4NzQ1OA==&mid=2247523814&idx=1&sn=2b95bdafced0fae183d6655f79466efc&chksm=fa034d3311381087853750b7b2823de1a38a26b23a463350266814e11a035ec9541e402f1504&scene=126&sessionid=0

该文章已生成可运行项目，

这是 Reddit 上一篇很火的 Claude Code 实践帖

当 AI 的随机性与软件工程对确定性的要求相撞时，大多数讨论都停留在提示词技巧的层面。这篇文章的价值，在于它展示了越过这个阶段的工程实践是什么样的。

作者没有尝试驯服一个本质上不可靠的工具，而是为其构建了一套外部约束系统。这套由钩子（Hooks）、技能（Skills）和开发文档构成的精密装置，并非为了让 AI 更聪明，而是为了让它的行为可管理。它本质上是在为 AI 构建一个外置的、可工程化的额叶——将记忆、规划、规则遵循等高级认知功能，从依赖 AI 内部不可靠的状态，转移到外部稳定、可审查、可迭代的工程系统中。

这其实是一个重要的范式转变。当下的 prompt 工程师更像一个与黑箱对话的心理学家，而本文作者展示的，是一个 AI 系统架构师的角色。其核心工作不是与AI对话，而是设计和维护 AI 的工作流、记忆库和 QA 管道。在这里，工程的胜利不是 AI 输出了完美代码，而是系统确保了即便 AI 犯错，错误也能被稳定地捕-纠正-消化。

我认为这篇文章揭示的，或许是提示工程的终极形态：当所有人都掌握了基本对话技巧后，真正的壁垒在于你能否为AI设计出一套健壮的、可扩展的操作系统。

在此我抛出一个行业问题：如果未来高级开发者的核心产出，不再是代码本身，而是这套能驱动 AI 大规模、高质量产出代码的自动化装置，那么我们应当如何重新评估一名工程师的经验和价值？

同为懒人，给你个小妙招：你可以把这篇长篇大论丢进像 ElevenLabs Reader^[1] 或 Natural Reader^[2] 这样的 AI 语音服务里，让它读给你听 :)

免责声明

大概六个月前，我发了个帖子，分享了自己重度使用 Claude Code 一周后的体验。现在，我已经“肝”了它整整六个月了，想和大家分享更多的心得、技巧和一些碎碎念。我可能有点收不住了，所以，你最好坐稳了，泡杯咖啡，或者不管你是在蹲马桶还是在啥时候刷手机摸鱼，准备好读吧。

我想先声明：本文所有内容，仅仅是我个人目前用得最爽的一套配置分享，不应被奉为圭臬或唯一正确的方式。这只是希望能启发你，用 AI 智能体来改进你的编程配置和工作流。我就是个普通人，这真的...纯属个人拙见。

另外，我用的是 20x Max 套餐，所以你的体验可能（YMMV）效果因人而异。如果你想找的是“凭感觉编程”的技巧，那你看错地方了。如果你想从 CC (Claude Code) 身上榨出最佳性能，你就应该和它并肩作战：一起规划、评审、迭代、探索不同的实现路径等等。

快速概览

在极限压榨 Claude Code 六个月（单枪匹马重写 30 万行代码）后，我搭建了这么一套系统：

真正能在需要时自动激活的“技能”
防止 Claude“彻底跑偏”的开发文档工作流
PM2 + 钩子（Hooks）实现的“错误清零”机制
用于评审、测试和规划的专业智能体军团

我们这就开始。

背景

我是一名软件工程师，过去七年左右一直在做生产环境的 Web 应用。我全心全意地拥抱了 AI 浪潮。我不太担心 AI 会很快抢走我的饭碗，因为它是我用来放大我能力的工具。通过使用它，我一直在构建超多新功能，并与 Claude 和 GPT-5 Thinking 一起提出了各种新提案，将新的 AI 系统集成到我们的生产应用中。在没有 AI 融入我的工作流之前，这些项目我连想都不敢想。凭借这一切，我给了自己足够的就业保障，并成了公司的“AI 达人”，因为其他人在如何将 AI 融入日常工作方面，大概都落后了一年左右。

带着这股新获得的信心，我提议对公司内部使用的一个 Web 应用进行一次大规模的重新设计/重构。这是一个相当粗糙的、由大学生练手的项目，它是从我实习时开发的另一个项目 fork（分支）出来的（大约 7 年前创建，4 年前 fork）。我这可能有点过于雄心勃勃了，因为为了说服老板们 (stakeholders)，我同意在几个月内独自一人完成这个规模相当大的项目（约 10 万行代码）的自上而下彻底重构。我打一开始就知道，即使有 CC 的帮助，我也得加班加点才能完成。但我内心深处知道，这玩意儿一旦搞成，绝对会火，它将自动化好几个手动流程，为公司里的一大票人节省大量时间。

现在六个月过去了...是啊，我当初可能真的不该同意这个时间表。我考验了 Claude 和我自己理智的双重极限，拼了命想把这东西搞定。我彻底扔掉了旧的前端，因为一切都严重过时了，我想玩点最新最酷的技术。我说的是：React 16 JS → React 19 TypeScript，React Query v2 → TanStack Query v5，React Router v4 (带 hashrouter) → TanStack Router (带基于文件的路由)，Material UI v4 → MUI v7，并且全部严格遵守最佳实践。这个项目现在大概有 30-40 万行代码，而我的预期寿命大概缩短了 5 年。现在，它终于准备好上线测试了，我对结果非常满意。

这曾经是一个技术债堆积如山、测试覆盖率为零、开发者体验极度糟糕（测试东西简直是噩梦）、还有各种乱七八糟的玩意儿的项目。我解决了所有这些问题，实现了不错的测试覆盖率，技术债也变得可控，还实现了一个用于生成测试数据的命令行工具，以及一个用于在前端测试不同功能的开发模式。在这段时间里，我摸透了 CC 的能力，也知道了该对它有什么样的预期。

关于质量和一致性的说明

我注意到在论坛和讨论中，一个老生常谈的话题是——人们对使用限制感到沮丧，并担心输出质量随时间下降。我想先说清楚：我不是来否认这些体验，也不是说这仅仅是“你用错了”的问题。每个人的用例和上下文都不同，合理的担忧理应被倾听。

话虽如此，我还是想分享一下对我有效的方法。以我的经验来看，CC 的输出在过去几个月里实际上有了显著改善，我相信这很大程度上归功于我一直在不断优化的工作流。我希望，如果你能从我的系统中哪怕只学到一丁点灵感，并将其融入你的 CC 工作流，你就能给它一个更好的机会，产出你满意的优质内容。

好了，说点实在的——Claude 确实有时会完全抓不到重点，生成不理想的代码。这可能由多种原因导致。首先，AI 模型是随机性的 (stochastic)，这意味着相同的输入可能会得到截然不同的输出。有时候纯粹是运气不好，你得到的输出质量确实很差，这不是你的错。其他时候，则与你构建提示词 (prompt) 的方式有关。用词稍有不同，输出就可能有天壤之别，因为模型对输入是逐字理解的。如果你用词不当或表述模棱两可，就可能导致结果大打折扣。

有时候，你就是得亲自上

听着，AI 很牛，但它不是魔法。在某些问题上，模式识别和人类直觉就是更胜一筹。如果你花了 30 分钟看 Claude 在某个问题上苦苦挣扎，而你自己 2 分钟就能搞定，那就自己动手吧。不丢人。这就像教人骑自行车，有时候你就是得帮他扶一下车把，然后再松手。

我发现这在逻辑谜题或需要现实世界常识的问题上尤其明显。AI 可以暴力破解很多东西，但有时候，人就是能更快地“get 到”。别让固执或“AI 就该搞定一切”这种错误的执念浪费你的时间。插手，解决问题，然后继续前进。

我也有过提示词写得巨烂的时候，通常发生在快下班时，人变懒了，没花心思去写提示词。结果真的惨不忍睹。所以下次你再遇到这类问题，觉得“现在的输出质量大不如前”，怀疑 Anthropic 是不是又暗中削弱了 Claude 时，我劝你先退一步，反思一下你是怎么提问的。

要经常重新提问。 你可以按两下 esc 键调出你之前的提示词，选择一个来进行分支。当你已经知道了自己不想要什么时，再给出一个相同的提示，你往往会惊讶地发现结果好得多。说了这么多，就是想表明，输出质量看起来变差可能有很多原因，最好先自我反思一下，想想你能做些什么，来给它最好的机会，让它给出你想要的输出。

正如某个地方的某位智者可能说过的那样：“别问 Claude 能为你做什么，要问你能为 Claude 提供什么上下文” ~ 某智者

好了，我的说教到底为止，下面开始上干货。

我的系统

在过去的 6 个月里，我对我的 CC (Claude Code) 相关工作流做了大量改进，在我看来 (IMO)，结果相当不错。

技能自动激活系统（游戏规则改变者！）

这个值得单独开一节，因为它彻底改变了我与 Claude Code 的工作方式。

痛点

Anthropic 发布了“技能” (Skills) 这个功能时，我心想“这玩意儿看起来太棒了！”。让 Claude 能引用这些可移植、可复用的指南，这对于在我庞大的代码库中保持一致性来说，听起来简直完美。我花了大量时间和 Claude 一起编写了关于前端开发、后端开发、数据库操作、工作流管理等方面的综合性技能。我们谈论的是数千行的最佳实践、模式和示例。

然后...就没然后了。Claude 压根就不用它们。我明明用了技能描述里的原话关键词，没用。我处理那些本该触发技能的文件，还是没用。这简直令人沮丧，因为我能看到它的潜力，但这些技能就像昂贵的摆设一样杵在那儿。

灵光一闪的时刻

就在那时，我冒出了使用钩子 (hooks) 的想法。如果 Claude 不会自动使用技能，那要是我构建一个系统，在它做任何事情之前，强制它去检查相关的技能呢？

于是我深入研究了 Claude Code 的钩子系统，并用 TypeScript 钩子构建了一个多层自动激活架构。它真的管用！

它是如何工作的

我创建了两个主要的钩子：

1. UserPromptSubmit 钩子 (在 Claude 看到你的消息之前运行):

分析你提示词中的关键词和意图模式
检查哪些技能可能是相关的
在 Claude 的上下文中注入一个格式化的提醒
现在当我问“布局系统是怎么工作的？”时，Claude 在读我的问题之前，就会先看到一个大大的“🎯 技能激活检查 - 使用 project-catalog-developer 技能”（项目目录是我前端一个基于复杂数据网格的大功能）

2. Stop Event 钩子 (在 Claude 完成响应之后运行):

分析哪些文件被编辑了
检查高风险模式（try-catch 块、数据库操作、异步函数）
显示一个温和的自查提醒
“你添加错误处理了吗？Prisma 操作是否使用了仓库 (repository) 模式？”
非阻塞性的，只是提醒 Claude 注意，不会很烦人

skill-rules.json 配置

我创建了一个中央配置文件，定义了每个技能的：

Keywords: 明确的主题匹配（“layout”、“workflow”、“database”）
Intent patterns: 捕捉动作的正则表达式（“(create|add).*?(feature|route)”）
File path triggers: 根据你正在编辑的文件激活
Content triggers: 如果文件包含特定模式（Prisma 导入、控制器等）则激活

示例片段：

{
  "backend-dev-guidelines": {
    "type": "domain",
    "enforcement": "suggest",
    "priority": "high",
    "promptTriggers": {
      "keywords": ["backend", "controller", "service", "API", "endpoint"],
      "intentPatterns": [
        "(create|add).*?(route|endpoint|controller)",
        "(how to|best practice).*?(backend|API)"
      ]
    },
    "fileTriggers": {
      "pathPatterns": ["backend/src/**/*.ts"],
      "contentPatterns": ["router\\\\.", "export.*Controller"]
    }
  }
}

成果

现在，当我处理后端代码时，Claude 会自动：

在读我提示词之前，就看到技能建议
加载相关指南
始终如一地遵循这些模式
通过温和的提醒，在最后进行自我检查

这区别简直是天壤之别。 再也没有不一致的代码了。再也不会“等等，Claude 怎么又用旧模式了”。再也不用每次都手动告诉它去检查指南了。

遵循 Anthropic 的最佳实践（惨痛的教训）

在让自动激活生效后，我深入研究了 Anthropic 的官方最佳实践文档。结果发现我搞错了，因为他们建议将主 SKILL.md 文件保持在 500 行以下，并使用资源文件进行渐进式披露。

我勒个去。我的 frontend-dev-guidelines 技能有 1500 多行。我还有几个技能也超过了 1000 行。这些庞大的单体文件完全违背了技能设计的初衷（只加载你需要的东西）。

于是我重构了一切：

frontend-dev-guidelines: 398 行的主文件 + 10 个资源文件
backend-dev-guidelines: 304 行的主文件 + 11 个资源文件

现在 Claude 首先加载轻量级的主文件，只有在真正需要时才引入详细的资源文件。对大多数查询来说，Token 效率提高了 40-60%。

我创建的技能

这是我目前的技能阵容：

指南与最佳实践：

backend-dev-guidelines - 路由 → 控制器 → 服务 → 仓库 (Repositories)
frontend-dev-guidelines - React 19, MUI v7, TanStack Query/Router 模式
skill-developer - 用于创建更多技能的元技能 (Meta-skill)

领域特定：

workflow-developer - 复杂工作流引擎模式
notification-developer - 电子邮件/通知系统
database-verification - 防止列名错误（这是一个会真正阻止编辑的护栏！）
project-catalog-developer - DataGrid 布局系统

所有这些都会根据我正在做的工作自动激活。这就像有位高级开发在 Claude 背后盯着它，确保它真正记住了所有的模式。

为什么这很重要

在（技能 + 钩子）之前：

尽管我记录了新模式，Claude 还是会用旧模式
每次都得手动提醒 Claude 去检查 BEST_PRACTICES.md
在 30 多万行代码库中，代码风格不一致
花费太多时间修复 Claude 的“创造性”发挥

在（技能 + 钩子）之后：

自动强制执行一致的模式
在我看到代码之前，Claude 就能自我纠正
可以相信指南正在被遵守
花在评审和修复上的时间大大减少

如果你正在一个有既定模式的大型代码库上工作，我强烈推荐这套系统。最初的配置花了我几天时间才搞定，但这点投入早就十倍奉还了。

CLAUDE.md 和文档的演进

在我 6 个月前写的帖子里，我有一节说“规则是你最好的朋友”，我现在仍然坚持这一点。但我的 CLAUDE.md 文件很快就变得越来越失控，试图塞进太多东西。我还有一个庞大的 BEST_PRACTICES.md 文件（1400 多行），Claude 有时会读，有时则完全忽略。

所以我花了一个下午和 Claude 一起，把所有东西整合并重组到一个新系统中。变化如下：

什么被移到了“技能”里

以前，BEST_PRACTICES.md 包含：

TypeScript 标准
React 模式（钩子、组件、Suspense）
后端 API 模式（路由、控制器、服务）
错误处理（Sentry 集成）
数据库模式（Prisma 用法）
测试指南
性能优化

所有这些现在都在“技能”里了，并通过自动激活钩子确保 Claude 真正使用它们。再也不用指望 Claude 会“记得”去检查 BEST_PRACTICES.md 了。

什么留在了 CLAUDE.md 里

现在 CLAUDE.md 高度聚焦于项目特定信息（只有约 200 行）：

快速命令（pnpm pm2:start, pnpm build 等）
特定服务的配置
任务管理工作流（开发文档系统）
测试需要认证的路由
工作流的“空跑” (dry-run) 模式
浏览器工具配置

新的结构

根目录 CLAUDE.md (100 行) ├── 关键的通用规则 ├── 指向各个仓库 (repo) 特定的 claude.md 文件 └── 引用“技能”以获取详细指南

每个仓库的 claude.md (50-100 行) ├── 快速上手部分，指向： │ ├── PROJECT_KNOWLEDGE.md - 架构与集成 │ ├── TROUBLESHOOTING.md - 常见问题 │ └── 自动生成的 API 文档 └── 仓库特定的怪癖和命令

精妙之处在于： “技能”处理所有“如何写代码”的指南，而 CLAUDE.md 处理“这个特定项目如何运作”。为胜利而生的关注点分离 (Separation of concerns)。

开发文档系统

这个系统，在所有东西里（除了“技能”），我认为是对我从 CC 得到的结果影响最大的。Claude 就像一个极度自信但又有极度健忘症的初级开发，很容易就搞不清自己在做什么。这个系统就是为了解决这些缺点。

这是我 CLAUDE.md 里的开发文档部分：

#### 开始大型任务

当退出规划模式并接受了一个计划后：
1. **创建任务目录**：
   `mkdir -p ~/git/project/dev/active/[task-name]/`

2. **创建文档**：
   - `[task-name]-plan.md` - 已接受的计划
   - `[task-name]-context.md` - 关键文件、决策
   - `[task-name]-tasks.md` - 工作清单

3. **定期更新**：任务一完成就立刻标记

#### 继续任务
- 检查 `/dev/active/` 中是否已有任务
- 在继续之前阅读所有三个文件
- 更新“最后更新”时间戳

这些是为每个功能或大型任务始终创建的文档。在使用这个系统之前，我有很多次突然发现 Claude 已经彻底跑偏了，我们不再执行 30 分钟前计划好的东西，因为它不知道因为什么原因七拐八拐扯到别处去了。

我的规划流程

我的流程从规划开始。规划为王。如果你在让 Claude 实施任何东西之前，连最基本的规划模式都不用，那你可要吃苦头了，懂？你总不会叫个建筑工来你家，连图纸都不画，就让他直接开始给你加盖一个房间吧。

当我开始规划一个功能时，我会把它设置成规划模式，即使我最终会让 Claude 把计划写在一个 markdown 文件里。我不确定是否非要用规划模式，但对我来说，感觉规划模式在研究你的代码库和获取所有正确上下文以制定计划方面，能出更好的结果。

我创建了一个 strategic-plan-architect（战略规划架构师）子智能体，它基本上是个规划猛兽。它会：

高效收集上下文
分析项目结构
创建包含执行摘要、阶段、任务、风险、成功指标、时间表的综合结构化计划
自动生成三个文件：计划、上下文和任务清单

但我发现很烦人的一点是，你看不到智能体的输出，更烦人的是，如果你对计划说“不”，它会直接终止智能体，而不是继续规划。所以我还创建了一个自定义的斜杠命令 (/dev-docs)，在 CC 主实例上使用相同的提示词。

一旦 Claude 吐出那份漂亮的计划，我会花时间仔细审查它。这一步非常重要。 花点时间去理解它，你会惊讶地发现，你经常能抓到一些愚蠢的错误，或者 Claude 对请求或任务的某个关键部分理解有误。

十有八九，退出规划模式后，我的上下文就只剩下 15% 或更少了。但这没关系，因为我们将把开始新工作所需的一切都放进我们的开发文档里。Claude 通常喜欢一上来就撸起袖子开干，所以我马上猛按 ESC 键打断它，然后运行我的 /create-dev-docs 斜杠命令。这个命令会接收批准的计划并创建所有三个文件，如果上下文还够用，有时还会做点研究来填补空白。

完成之后，我基本上就准备好让 Claude 完全实现这个功能了，不用担心它会迷路或忘记自己在做什么，即使经历了上下文自动压缩。我只需要每隔一段时间提醒 Claude 更新任务以及上下文文件（用任何相关上下文）。一旦当前会话的上下文快用完了，我就运行我的斜杠命令 /update-dev-docs。Claude 会记下所有相关的上下文（以及下一步行动），并在我压缩对话之前，标记所有已完成的任务或添加新任务。而在新的会话中，我只需要说“继续”就行了。

在实施过程中，根据功能或任务的大小，我会明确告诉 Claude 一次只实现一两个部分。这样，我就有机会在每组任务之间进去审查代码。而且，我还会定期让一个子智能体来审查变更，这样我就能及早发现重大错误。如果你没有让 Claude 审查它自己的代码，那我强烈建议你这么做，因为它能捕捉到关键错误、缺失的实现、不一致的代码和安全漏洞，帮我省了巨多头疼事。

PM2 进程管理（后端调试的游戏规则改变者）

这是我最近才加上的，但它让后端问题的调试变得容易多了。

痛点

我的项目有七个后端微服务同时运行。问题在于，Claude 无法在服务运行时查看日志。我不能直接问“邮件服务出了什么问题？”——除非我手动把日志复制粘贴到聊天框里，否则 Claude 根本看不见。

中间方案

有段时间，我让每个服务都用一个 devLog 脚本把输出写入带时间戳的日志文件。这...还行吧。Claude 能读取日志文件，但这很笨重。日志不是实时的，服务崩溃后不会自动重启，管理这一切都让人头疼。

真正的解决方案：PM2

然后我发现了 PM2，这简直是游戏规则的改变者。我配置了所有的后端服务，通过一个命令 pnpm pm2:start 来用 PM2 运行。

这给我带来了什么：

每个服务都作为受管进程运行，有自己的日志文件
Claude 可以轻松地实时读取单个服务的日志
崩溃时自动重启
用 pm2 logs 进行实时监控
用 pm2 monit 进行内存/CPU 监控
轻松管理服务（pm2 restart email, pm2 stop all 等）

PM2 配置：

// ecosystem.config.js
module.exports = {
  apps: [
    {
      name: 'form-service',
      script: 'npm',
      args: 'start',
      cwd: './form',
      error_file: './form/logs/error.log',
      out_file: './form/logs/out.log',
    },
// ... 另外 6 个服务
  ]
};

使用 PM2 之前：我：“邮件服务在报错” 我：[手动查找并复制日志] 我：[粘贴到聊天框] Claude：“我来分析一下...”

现在的调试工作流：我：“邮件服务在报错” Claude：[运行] pm2 logs email --lines 200Claude：[读取日志] “我看到问题了 - 数据库连接超时...” Claude：[运行] pm2 restart emailClaude：“已重启服务，正在监控错误...”

天壤之别。Claude 现在可以自主调试问题了，我再也不用当人肉日志搬运工了。

一个提醒： 热重载 (Hot reload) 和 PM2 不兼容，所以我还是用 pnpm dev 单独运行前端。但对于那些不需要频繁热重载的后端服务来说，PM2 简直是神器。

钩子系统（不留烂摊子）

我正在做的项目是多根 (multi-root) 目录的，在根项目目录里大概有八个不同的仓库 (repo)。一个用于前端，七个用于后端的微服务和工具。我经常要根据功能需求，在几个仓库之间跳来跳去，同时进行修改。

有一件事让我烦得要死，那就是 Claude 在编辑完某个仓库后，老是忘记运行构建命令来捕获错误。它会留下一堆 TypeScript 错误而我却没发现。然后几个小时后，我看到 Claude 像个乖宝宝一样在运行构建脚本，然后我看到了输出：“有几个 TypeScript 错误，但它们（和当前任务）无关，所以我们一切都好！”

不，Claude，我们一点都不好。

钩子 #1：文件编辑追踪器

首先，我创建了一个 post-tool-use (工具使用后) 钩子，它在每次 Edit/Write/MultiEdit (编辑/写入/多重编辑) 操作后运行。它会记录：

哪些文件被编辑了
它们属于哪个仓库
时间戳

一开始，我让它在每次编辑后立即运行构建，但这简直是蠢到家的低效。Claude 经常会先做出破坏性的修改，然后马上又修复它们。

钩子 #2：构建检查器

然后我添加了一个 Stop (停止) 钩子，在 Claude 完成响应时运行。它会：

读取编辑日志，找出哪些仓库被修改了
在每个受影响的仓库上运行构建脚本
检查 TypeScript 错误
如果 < 5 个错误：展示给 Claude 看
如果 ≥ 5 个错误：推荐启动自动错误解决智能体
记录所有日志以备调试

自从实施了这个系统，我再也没遇到过 Claude 把错误留在代码里等我稍后发现的情况。钩子会立即捕获它们，Claude 会在继续下一步之前修复它们。

钩子 #3：Prettier 格式化器

这个很简单，但很有效。在 Claude 完成响应后，使用该仓库对应的 .prettierrc 配置文件，自动用 Prettier 格式化所有编辑过的文件。

再也不用手动去编辑一个文件，结果只因为 Claude 上周创建那个文件时忘了加行尾逗号，导致 Prettier 跑出了 20 个变更。

钩子 #4：错误处理提醒器

这就是我前面提到的那个温和的“哲学”钩子：

在 Claude 完成后，分析编辑过的文件
检测高风险模式（try-catch、异步操作、数据库调用、控制器）
如果编写了高风险代码，就显示一个温和的提醒
Claude 自我评估是否需要错误处理
不阻塞、无摩擦，只是提升意识

示例输出：

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
📋 错误处理自查
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

⚠️  检测到后端变更
    2 个文件被编辑

    ❓ 你在 catch 块里添加 Sentry.captureException() 了吗？
    ❓ Prisma 操作是否被包裹在错误处理中了？

    💡 后端最佳实践：
       - 所有错误都应被捕获到 Sentry
       - 控制器应继承 BaseController
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

完整的钩子管道

现在，Claude 的每次响应都会发生这些事：

Claude 完成响应 ↓ 钩子 1：Prettier 格式化器运行 → 所有编辑过的文件被自动格式化 ↓ 钩子 2：构建检查器运行 → TypeScript 错误被立即捕获 ↓ 钩子 3：错误提醒器运行 → 温和的错误处理自查 ↓ 如果发现错误 → Claude 看到并修复它们 ↓ 如果错误太多 → 推荐使用自动错误解决智能体 ↓ 结果：干净、格式化、无错误的代码

而 UserPromptSubmit 钩子确保 Claude 在开始工作之前就已经加载了相关技能。

不留任何烂摊子。太完美了。

附加到技能的脚本

我从 Anthropic 在 GitHub 上的官方技能示例中学到了一个非常酷的模式：将工具脚本附加到技能上。

例如，我的 backend-dev-guidelines 技能中有一节是关于测试需认证的路由的。这个技能不只是解释认证如何工作，它还引用了一个实际的脚本：

测试需认证的路由

使用提供的 test-auth-route.js 脚本：node scripts/test-auth-route.js http://localhost:3002/api/endpoint

该脚本会为你处理所有复杂的认证步骤：

从 Keycloak 获取刷新令牌 (refresh token)
用 JWT 密钥签署令牌
创建 cookie 头部
发出认证请求

当 Claude 需要测试一个路由时，它清楚地知道该用什么脚本以及如何使用它。再也不用“让我来创建一个测试脚本”，每次都重复造轮子了。

我正计划扩展这个模式——把更多的工具脚本附加到相关的技能上，这样 Claude 就有了现成的工具，而不是每次都从头生成。

工具及其他

Mac 上的 SuperWhisper

当我的手懒得打字时，用语音转文本来输入提示词。效果出奇的好，而且 Claude 对我叨叨咕咕的语音转文字内容理解得也出奇的好。

Memory MCP

现在“技能”承担了大部分“记住模式”的工作，这个我已经用得比较少了。但它对于追踪那些不属于技能范畴的项目特定决策和架构选择，仍然很有用。

BetterTouchTool

从 Cursor 复制相对 URL（用于分享代码引用）
- 我打开 VSCode 是为了更容易地找到我想要的文件，然后我可以双击 CAPS-LOCK 键，BTT 就会输入复制相对 URL 的快捷键，转换剪贴板内容（在前面加上一个‘@’符号），聚焦到终端，然后粘贴文件路径。一气呵成。
双击热键快速聚焦应用（CMD+CMD = Claude Code, OPT+OPT = 浏览器）
常见操作的自定义手势

老实说，光是省下在应用之间手忙脚乱地切换的时间，就值回 BTT 的票价了。

为一切编写脚本

如果有什么烦人的琐碎任务，很可能已经有脚本来处理它了：

命令行工具，用于生成模拟测试数据。在使用 Claude Code 之前，生成模拟数据极其烦人，因为我必须提交一个有大约 120 个问题的表单，才能生成一个测试提交。
认证测试脚本（获取令牌、测试路由）
数据库重置和植入种子数据 (seeding)
迁移 (migration) 前的 schema 差异检查器
开发数据库的自动备份和恢复

专业提示： 当 Claude 帮你写了一个有用的脚本时，立即将它记录在 CLAUDE.md 中或附加到相关技能上。未来的你会感谢过去的你。

文档（仍然重要，但已演进）

我认为，仅次于规划，文档几乎同样重要。除了为每个任务或功能创建的开发文档外，我还会边做边记录一切。从系统架构到数据流图，再到实际的开发者文档和 API，等等。

但变化在于： 现在文档是配合“技能”工作的，而不是取代它们。

技能包含： 可复用的模式、最佳实践、操作指南文档包含： 系统架构、数据流、API 参考、集成点

例如：

“如何创建一个控制器” → backend-dev-guidelines 技能
“我们的工作流引擎如何工作” → 架构文档
“如何编写 React 组件” → frontend-dev-guidelines 技能
“通知如何在系统中流转” → 数据流图 + notification 技能

我仍然有大量的文档（850 多个 markdown 文件），但现在它们高度聚焦于项目特定的架构，而不是重复那些更适合由“技能”来提供服务的通用最佳实践。

你不一定非要搞得那么夸张，但我强烈建议你设置多层文档。一层用于特定服务的宏观架构概览，在其中包含指向其他文档的路径，这些文档会更深入地介绍架构的不同部分。这将会对 Claude 轻松驾驭你代码库的能力产生重大影响。

提示词技巧

当你在写提示词时，你应该试着尽可能具体地说明你想要什么样的结果。再说一遍，你不会叫一个建筑工来给你盖个新浴室，却连图纸都不讨论一下，对吧？

“你说的太对了！在浴室里用长毛绒地毯可能真的不是个好主意。”

有时候你可能不知道具体细节，那也没关系。如果你不问问题，就告诉 Claude 去研究，然后带着几种可能的解决方案回来。你甚至可以用一个专门的子智能体或任何其他 AI 聊天界面来做你的研究。世界尽在你手。我向你保证，这样做会给你带来丰厚的回报，因为你将能够审查 Claude 给出的计划，并更好地判断它是好是坏，还是需要调整。否则，你就是在两眼一抹黑，纯凭感觉编程。然后你就会陷入一种你都不知道该包含什么上下文的境地，因为你根本不知道哪些文件与你试图修复的东西相关。

如果你想要诚实、不偏不倚的反馈，就尽量不要在提示词里带节奏（诱导性提问）。 如果你对 Claude 做的某件事不确定，用中立的方式去问，而不是说“这个是好是坏？”。Claude 倾向于说它认为你想听的话，所以诱导性问题可能会扭曲回复。最好只是描述情况，并询问它的想法或替代方案。这样，你会得到一个更中肯的答案。