8.0
热点
AI SCORE
编程提效2025-10-29 11:10
Claude Code 深度使用 6 个月的实战技巧
DEV Community · Diet-Coder#Claude Code#工具教程
Editor brief · 编辑速览
来自重度用户的系统性经验总结，包含高效工作流、实战技巧，直接提升编码效率。
更新：我下定决心花了一个下午，为那些发消息向我索要代码仓库的人建好了 GitHub 仓库。我刚刚发了一篇包含更多补充信息的帖子，你也可以直接查看源代码：
🎯 仓库：https://github.com/diet103/claude-code-infrastructure-showcase
大约六个月前，我曾在另一个平台发帖，分享自己高强度使用 Claude Code 一周后的体验。如今，我已经高强度使用它大约六个月了，想再和大家分享一些技巧、窍门，以及想到哪儿说到哪儿的碎碎念。在文章开头，我想先声明一下：本文的所有内容都只是分享目前最适合我的配置，不应被奉为圭臬，也不代表这是做事的唯一正确方式。希望这些内容能够给你一些启发，帮助你改进使用 AI 智能体编程时的配置和工作流。我只是个普通人，而这些也不过是我的个人看法，兄弟。
另外，我使用的是 20x Max 套餐，所以你的实际体验可能有所不同。如果你想找的是凭感觉编程技巧，那应该去别处看看。如果想充分发挥 CC 的能力，你就应该和它协作：制订计划、审查、迭代、探索不同方案，等等。
关于质量与一致性的说明 有时你就是需要亲自介入
有时你就是需要亲自介入
我的系统 技能自动激活系统（改变游戏规则！） CLAUDE.md 与文档体系的演进 开发文档系统 PM2 进程管理（彻底改变后端调试体验） Hooks 系统（#NoMessLeftBehind） 与技能绑定的脚本 工具及其他内容 文档（依然重要，但已经演进） 提示词技巧 Agents、Hooks 与 Slash Commands（神圣三位一体）
技能自动激活系统（改变游戏规则！）
CLAUDE.md 与文档体系的演进
PM2 进程管理（彻底改变后端调试体验）
Hooks 系统（#NoMessLeftBehind）
与技能绑定的脚本
工具及其他内容
文档（依然重要，但已经演进）
Agents、Hooks 与 Slash Commands（神圣三位一体）
我是一名软件工程师，过去大约七年一直在开发生产环境中的 Web 应用。我也张开双臂，彻底拥抱了这波 AI 浪潮。我暂时并不太担心 AI 会抢走我的工作，因为对我来说，它是一种用来放大自身能力的工具。在这个过程中，我开发了许多新功能，还借助 Claude 和 GPT-5 Thinking 制作了各种新提案演示文稿，计划把新的 AI 系统集成到我们的生产应用中。如果没有把 AI 融入工作流，我以前甚至不敢想象自己能有时间考虑这些项目。通过这一切，我为自己带来了相当不错的职业保障，也成了公司里的 AI 专家，因为其他人在将 AI 融入日常工作的方式上，大概落后了我一年左右。
有了这份新获得的自信，我提议对公司内部使用的一款 Web 应用进行规模相当大的重新设计和重构。这原本是一个由大学生开发、相当粗糙的项目，它又是从我实习期间开发的另一个项目中 fork 出来的（原项目大约创建于 7 年前，并于 4 年前被 fork）。这可能有点过于雄心勃勃，因为为了说服利益相关者，我答应在几个月内完成这个规模不算小的项目（约 10 万行代码）的自顶向下全面重新设计……而且全部由我一个人完成。我从一开始就知道，即使有 CC 的帮助，我也必须投入额外的工作时间才能完成它。但在内心深处，我知道它一定会大获成功：它将自动化多个手动流程，为公司里的许多人节省大量时间。
如今六个月过去了……是的，我当初大概不该答应这个时间表。为了完成这件事，我不仅测试了 Claude 的极限，也测试了自己理智的极限。我彻底废弃了旧前端，因为所有东西都严重过时了，而且我想尝试最新、最好的技术。具体来说，就是 React 16 JS → React 19 TypeScript、React Query v2 → TanStack Query v5、使用 hashrouter 的 React Router v4 → 使用基于文件路由的 TanStack Router、Material UI v4 → MUI v7，而且全部严格遵循最佳实践。现在项目已经达到约 30 万到 40 万行代码，而我的预期寿命大概缩短了 5 年。它终于可以交付测试了，我对最终成果感到无比满意。
这个项目过去背负着难以承受的技术债，测试覆盖率为零，开发者体验糟糕透顶（测试任何东西都简直是一场噩梦），而且到处都是乱七八糟的问题。我解决了所有这些问题：建立了相当不错的测试覆盖率，把技术债控制在可管理范围内，还实现了一个用于生成测试数据的命令行工具，以及一个用于在前端测试不同功能的开发模式。在此期间，我逐渐深入了解了 CC 的能力，也知道了应该对它抱有怎样的预期。
我注意到论坛和讨论中反复出现一个主题——人们对使用限额感到沮丧，并担心输出质量会随着时间推移而下降。我想先明确一点：我不是来否定这些体验的，也不是要声称这只是因为大家“用错了”。每个人的使用场景和上下文都不同，合理的担忧理应得到重视。
话虽如此，我还是想分享一下对我有效的方法。就我的体验而言，CC 的输出在过去几个月里实际上有了显著改善，而我认为，这在很大程度上得益于自己不断改进的工作流。我希望，即使你只从我的系统中获得一点点启发，并将其融入自己的 CC 工作流，也能让 CC 更有机会产出令你满意的高质量结果。
现在，我们说点实在的——Claude 当然会有完全偏离目标、产出次优代码的时候。这可能由多种原因造成。首先，AI 模型具有随机性，也就是说，相同的输入可能得到差异极大的输出。有时随机性就是没有站在你这边，即使你没有做错任何事情，也会得到质量确实很差的输出。另一些时候，问题则出在提示词的结构上。仅仅因为措辞略有不同，输出就可能产生显著差异，因为模型会非常字面地理解你的话。如果你用词不当，或者表达得模棱两可，就可能得到差得多的结果。
听着，AI 确实很强大，但它不是魔法。有些问题就是模式识别和人类直觉更占优势。如果你已经花了 30 分钟看着 Claude 苦苦挣扎，而自己只需要 2 分钟就能修好，那就亲自修吧。这没什么丢人的。把它想象成教别人骑自行车：有时你只需要扶稳车把几秒钟，然后再放手。
这种情况在逻辑谜题或需要现实世界常识的问题上尤其常见。AI 可以用穷举方式解决很多问题，但有时人类就是能更快地“领会”其中的关键。不要因为固执，或者某种“但 AI 就应该包办一切”的错误观念而浪费自己的时间。亲自介入，修复问题，然后继续前进。
我自己也写过不少糟糕的提示词，这通常发生在一天快结束的时候：我开始犯懒，不愿再花太多精力打磨提示词，而结果也确实会明显反映出这一点。所以下次你再遇到类似问题，觉得现在的输出质量差了很多，并怀疑 Anthropic 在暗中削弱 Claude 时，我建议你先退一步，反思一下自己是如何编写提示词的。
要经常重新输入提示词。你可以连按两次 Esc 调出之前的提示词，然后选择其中一条作为分支起点。当你已经知道自己不想要什么，再次给出相同提示词时，往往能得到好得多的结果——这种情况出现的频率可能会让你大吃一惊。总而言之，输出质量看起来变差可能有很多原因。适当自省一下，思考自己可以做些什么，才能让它尽可能产出你想要的结果，是件好事。
正如某位不知身在何处的智者大概说过的那样：“不要问 Claude 能为你做什么，要问你能为 Claude 提供什么上下文。”——某位智者
好了，我现在要从讲道台上下来了，开始聊真正有用的内容。
在过去 6 个月里，我对与 CC 相关的工作流做了许多调整，而在我看来，效果相当不错。
这部分值得单独成章，因为它彻底改变了我使用 Claude Code 的方式。
Anthropic 发布 Skills 功能时，我心想：“这看起来太棒了！”这些可移植、可复用的指导原则可以供 Claude 参考，用来在我的大型代码库中保持一致性——这个想法听起来简直完美。我花了相当多的时间和 Claude 一起编写全面的技能，涵盖前端开发、后端开发、数据库操作、工作流管理等方面。这里说的可是数千行的最佳实践、模式和示例。
然后……什么也没发生。Claude 就是不肯使用它们。我甚至会逐字使用技能描述中的关键词。毫无反应。我会处理那些本应触发技能的文件。依然毫无反应。这令人极其沮丧，因为我能看到这些技能的潜力，但它们却只是摆在那里，像昂贵的装饰品一样。
就在这时，我想到了使用钩子。如果 Claude 不会自动使用技能，那如果我构建一个系统，强制它在执行任何操作之前检查相关技能呢？
于是我深入研究了 Claude Code 的钩子系统，并使用 TypeScript 钩子构建了一套多层自动激活架构。结果它真的有效！
我创建了两个主要钩子：
分析提示词中的关键词和意图模式
检查哪些技能可能相关
将格式化的提醒注入 Claude 的上下文
现在，当我询问“布局系统是如何工作的？”时，Claude 甚至还没开始阅读我的问题，就会先看到一条醒目的提示：“🎯 SKILL ACTIVATION CHECK - Use project-catalog-developer skill”（project catalog 是我前端一个基于大型复杂数据网格的功能）。
分析编辑过的文件
检查高风险模式（try-catch 块、数据库操作、异步函数）
显示一条温和的自检提醒
“你添加错误处理了吗？Prisma 操作是否使用了仓储模式？”
它不会阻塞流程，只是让 Claude 保持警觉，同时又不会令人厌烦。
我创建了一个中央配置文件，其中为每个技能定义了：
关键词：明确匹配主题（“layout”“workflow”“database”）
意图模式：通过正则表达式捕获操作（“(create|add).*?(feature|route)”）
文件路径触发器：根据正在编辑的文件激活
内容触发器：当文件包含特定模式时激活（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 的官方最佳实践文档。结果发现我之前的做法是错的，因为他们建议将主 SKILL.md 文件控制在 500 行以内，并通过资源文件实现渐进式披露。
好吧。我的 frontend-dev-guidelines 技能超过了 1,500 行，另外还有几个技能超过了 1,000 行。这些单体文件完全违背了技能的初衷——只加载你需要的内容。
因此，我重新组织了所有内容：
frontend-dev-guidelines：398 行的主文件 + 10 个资源文件
backend-dev-guidelines：304 行的主文件 + 11 个资源文件
现在，Claude 最初只加载轻量级的主文件，仅在确实需要时才读取详细的资源文件。对于大多数查询，Token 效率提高了 40%～60%。
这是我目前的技能阵容：
指南与最佳实践：
backend-dev-guidelines - Routes → Controllers → Services → Repositories
frontend-dev-guidelines - React 19、MUI v7、TanStack Query/Router 模式
skill-developer - 用于创建更多技能的元技能
workflow-developer - 复杂工作流引擎模式
notification-developer - 电子邮件/通知系统
database-verification - 防止列名错误（这是一个真正会阻止编辑的护栏！）
project-catalog-developer - DataGrid 布局系统
所有这些技能都会根据我正在处理的内容自动激活。这就像有一位真正记得所有模式的高级开发者，站在 Claude 身后监督它。
使用技能和钩子之前：
即使我记录了新模式，Claude 仍然会使用旧模式
每次都必须手动告诉 Claude 检查 BEST_PRACTICES.md
在超过 30 万行代码的代码库中，代码风格不一致
花费太多时间修正 Claude 的“创造性解读”
使用技能和钩子之后：
自动强制执行一致的模式
Claude 甚至会在我看到代码之前自行纠正
可以确信指南得到了遵循
花在审查和修复上的时间大幅减少
如果你正在处理一个拥有既定模式的大型代码库，我再怎么推荐这套系统都不为过。初始设置花了几天时间才调整到位，但它带来的回报已经超过投入十倍。
在我 6 个月前写的一篇文章中，有一节提到规则是你最好的朋友，这一点我至今仍然认同。但我的 CLAUDE.md 文件很快就变得难以控制，试图承担太多职责。我还有一个庞大的 BEST_PRACTICES.md 文件（超过 1,400 行），Claude 有时会读取它，有时则会完全忽略。
所以，我花了一个下午和 Claude 一起将所有内容整合并重新组织成一套新系统。以下是发生的变化：
以前，BEST_PRACTICES.md 包含：
React 模式（hooks、components、suspense）
后端 API 模式（routes、controllers、services）
错误处理（Sentry 集成）
数据库模式（Prisma 用法）
性能优化
现在，所有这些内容都被放进了技能中，并通过自动激活钩子确保 Claude 真正使用它们。再也不必寄希望于 Claude 还记得检查 BEST_PRACTICES.md。
现在，CLAUDE.md 高度聚焦于项目特定信息（只有约 200 行）：
快捷命令（pnpm pm2:start、pnpm build 等）
特定服务的配置
任务管理工作流（开发文档系统）
测试需要身份验证的路由
工作流试运行模式
浏览器工具配置
Root CLAUDE.md (100 lines)
├── Critical universal rules
├── Points to repo-specific claude.md files
└── References skills for detailed guidelines
Each Repo's claude.md (50-100 lines)
├── Quick Start section pointing to:
│ ├── PROJECT_KNOWLEDGE.md - Architecture & integration
│ ├── TROUBLESHOOTING.md - Common issues
│ └── Auto-generated API docs
└── Repo-specific quirks and commands
其中的妙处在于：技能负责所有“如何编写代码”的指南，而 CLAUDE.md 负责“这个具体项目如何运作”。关注点分离，大获全胜。
在所有这些措施中（除了技能本身），我认为这套系统对我使用 CC 所获得的结果影响最大。Claude 就像一个极其自信、却又患有严重健忘症的初级开发者，很容易忘记自己正在做什么。这套系统正是为了解决这些缺点。
以下是我 CLAUDE.md 中的开发文档部分：
### Starting Large Tasks
When exiting plan mode with an accepted plan: 1.**Create Task Directory**:
mkdir -p ~/git/project/dev/active/[task-name]/
2.**Create Documents**:
- `[task-name]-plan.md` - The accepted plan
- `[task-name]-context.md` - Key files, decisions
- `[task-name]-tasks.md` - Checklist of work
3.**Update Regularly**: Mark tasks complete immediately
### Continuing Tasks
- Check `/dev/active/` for existing tasks
- Read all three files before proceeding
- Update "Last Updated" timestamps
每个功能或大型任务都会创建这些文档。在使用这套系统之前，我有过很多次这样的经历：突然意识到 Claude 已经偏离了目标，我们不再是在实现 30 分钟前规划好的内容，因为不知为何，我们沿着某个岔路越走越远。
我的流程从规划开始。规划至上。如果在让 Claude 实现某些东西之前，你连规划模式都不用，那你肯定会吃苦头，懂了吧。你不会让一个施工人员来到你家，连图纸都不画，就直接动手加建房屋。
当我开始规划一个功能时，我会让它进入规划模式，尽管最终我还是会让 Claude 把计划写进一个 Markdown 文件。我不确定进入规划模式是否真的有必要，但在我看来，规划模式能够更好地研究代码库，并获取所有正确的上下文，从而制定出一份计划。
我创建了一个名为 strategic-plan-architect 的子智能体，它基本就是一个规划猛兽。它会：
高效收集上下文
分析项目结构
创建全面且结构化的计划，其中包括执行摘要、阶段、任务、风险、成功指标和时间线
自动生成三个文件：计划、上下文和任务清单
但我发现看不到智能体的输出真的很烦人，更烦人的是如果你拒绝了计划，它就直接停止智能体而不是继续规划。所以我也为主 CC 实例创建了一个自定义斜杠命令（/dev-docs），使用相同的提示词。
Claude 输出漂亮的计划后，我会花时间彻底审查它。这一步真的很重要。花时间理解它，你会惊讶地发现自己有多常捕捉到一些愚蠢的错误，或者 Claude 误解了请求或任务的某个至关重要的部分。
退出规划模式后，我通常会剩余 15% 或更少的上下文。但这没关系，因为我们要把所有需要的内容放入开发文档中以重新开始。Claude 通常喜欢直接冲进去，所以我会立即按 ESC 键中断并运行我的 /dev-docs 斜杠命令。该命令接收已批准的计划并创建所有三个文件，有时还会做一些额外的研究来填补空白（如果剩余的上下文足够的话）。
完成这些后，我基本上可以让 Claude 完全实现该功能而不会迷失或忘记它在做什么，即使在自动压缩过程中也是如此。我只需确保时不时地提醒 Claude 更新任务以及上下文文件中的任何相关信息。一旦当前会话的上下文即将耗尽，我就运行 /update-dev-docs 斜杠命令。Claude 会记录任何相关的上下文（附带后续步骤）以及标记任何已完成的任务或添加新任务，然后我再对会话进行压缩。在新会话中，我只需说"continue"。
在实现过程中，根据功能或任务的大小，我会明确告诉 Claude 一次只实现一两个部分。这样，我有机会在每组任务之间查看和审查代码。同时，我会定期让子智能体也审查这些更改，这样我可以及早捕捉到大的错误。如果你还没有让 Claude 审查它自己的代码，我强烈推荐这样做，因为它为我省去了很多麻烦，帮我捕捉了关键错误、缺失的实现、不一致的代码和安全漏洞。
这是最近添加的功能，但它使调试后端问题变得容易得多。
我的项目有七个后端微服务同时运行。问题是 Claude 无法在服务运行时查看日志。我不能就这样问"email 服务出了什么问题？"—— Claude 无法看到日志，除非我手动复制并粘贴到聊天中。
有一段时间，我让每个服务使用 devLog 脚本将其输出写入带时间戳的日志文件。这样工作...还行。Claude 可以读取日志文件，但很笨拙。日志不是实时的，服务在崩溃时不会自动重启，管理一切是一件麻烦事。
然后我发现了 PM2，这改变了游戏规则。我配置了所有后端服务通过 PM2 运行，只需一个命令：pnpm pm2:start
// ecosystem.config.jsmodule.exports = {
apps: [
{
name: 'form-service',
script: 'npm',
args: 'start',
cwd: './form',
error_file: './form/logs/error.log',
out_file: './form/logs/out.log',
},
// ... 6 more services
]
};
之前：
Me: "The email service is throwing errors"
Me: [Manually finds and copies logs]
Me: [Pastes into chat]
Claude: "Let me analyze this..."
现在的调试工作流：
Me: "The email service is throwing errors"
Claude: [Runs] pm2 logs email --lines 200
Claude: [Reads the logs] "I see the issue - database connection timeout..."
Claude: [Runs] pm2 restart email
Claude: "Restarted the service, monitoring for errors..."
天壤之别。Claude 现在可以自主调试问题，而不需要我充当一个人工日志获取服务。
有一个需要注意的地方：PM2 不支持热重载，所以我仍然用 pnpm dev 单独运行前端。但对于不那么经常需要热重载的后端服务，PM2 非常强大。
我正在开发的项目是多根的，在根项目目录中有大约八个不同的仓库。一个用于前端，七个用于后端的微服务和工具。根据功能，我不断地在几个仓库之间跳转进行更改。
令我烦恼的一件事是 Claude 经常忘记在它正在编辑的任何仓库中运行构建命令来捕捉错误。它就这样留下十几个左右的 TypeScript 错误而我没有捕捉到。然后几个小时后，我看到 Claude 像个好孩子一样运行构建脚本，我看到输出："有几个 TypeScript 错误，但它们无关，所以我们都没问题！"
不，我们没有问题，Claude。
首先，我创建了一个在每次 Edit/Write/MultiEdit 操作后运行的 post-tool-use hook。它记录：
最初，我让它在每次编辑后立即运行构建，但那太低效了。Claude 总是会先进行一些会破坏东西的编辑，然后再快速修复它们。
然后我添加了一个在 Claude 完成响应时运行的 Stop hook。它：
自从实现这个系统以来，就没有出现过 Claude 在代码中留下错误让我稍后发现的情况。hook 会立即捕捉到它们，Claude 在继续之前就修复了它们。
这个很简单但很有效。在 Claude 完成响应后，自动使用 Prettier 格式化所有编辑的文件