🎯 Repository: github.com/diet103/cla...
免责声明
大约六个月前,我发了一篇帖子,分享了我硬核使用Claude Code一周后的经验。现在已经过去了大约六个月的硬核使用,我想与大家分享更多的技巧、窍门和心得。我可能有点过于详细了,所以请做好准备,喝杯咖啡,坐在马桶上,或者做任何你在刷Reddit时会做的事情。
我想先以一个免责声明开始这篇帖子:本文中的所有内容仅仅是分享目前对我效果最好的设置,不应被视为福音或唯一正确的做事方式。它的目的希望能够启发你改进AI代理编程的设置和工作流程。我只是一个人,这只是我的观点,兄弟。
另外,我使用的是20x Max计划,所以你的结果可能会有所不同。如果你在寻找氛围编程技巧,你应该看别处。如果你想要从CC获得最佳效果,那么你应该与它合作:规划、审查、迭代、探索不同的方法等。
快速概览
在6个月将Claude Code推到极限(独自重写30万行代码)后,这是我构建的系统:
- 能够在需要时实际自动激活的技能
- 防止Claude迷失方向的开发文档工作流程
- PM2 + hooks实现零错误遗留
- 用于审查、测试和规划的专家代理团队
让我们深入了解。
背景
我是一名软件工程师,过去七年左右一直在从事生产级Web应用开发。并且我完全拥抱了AI的浪潮。我并不太担心AI会很快夺走我的工作,因为它是我用来增强能力的工具。通过这样做,我一直在构建许多新功能,并提出各种各样的新提案,与Claude和GPT-5 Thinking合作,将新的AI系统集成到我们的生产应用中。在将AI集成到我的工作流程之前,我做梦也想不到有时间考虑这些项目。通过这一切,我给了自己很好的工作保障,并成为了公司的AI guru,因为其他人在如何将AI集成到日常工作中比我落后大约一年左右。
凭借我新获得的信心,我提出了一个相当大的重新设计/重构我们公司用作内部工具的Web应用的提案。这是一个相当粗糙的大学生制作的项目,是从我作为实习生开发的另一个项目分叉出来的(大约7年前创建,4年前分叉)。这可能对我来说有点过于雄心勃勃了,因为为了卖给利益相关者,我同意在几个月内独自完成这个相当大型项目(约10万行代码)的从上到下的重新设计。我知道在进行时,即使有CC的帮助,我也必须投入额外的时间来完成这件事。但在内心深处,我知道这会是一个成功的项目,自动化几个手动流程,为公司很多人节省大量时间。
现在是六个月后......是的,我可能不应该同意这个时间表。我已经测试了Claude和我的理智的极限,试图完成这件事。我完全废弃了旧的前端,因为一切都严重过时了,我想玩最新的最酷的技术。我说的是React 16 JS → React 19 TypeScript,React Query v2 → TanStack Query v5,React Router v4 w/ hashrouter → TanStack Router w/ file-based routing,Material UI v4 → MUI v7,都严格遵守最佳实践。项目现在大约有30-40万行代码,我的预期寿命缩短了约5年。它终于准备好进行测试了,我对结果感到非常满意。
这曾经是一个技术债务无法逾越、零测试覆盖率、糟糕的开发体验(测试东西绝对是噩梦)、各种问题层出不穷的项目。我通过体面的测试覆盖率、可管理的技术债务,以及一个用于生成测试数据的命令行工具和一个在前端测试不同功能的开发模式解决了所有这些问题。在这段时间里,我了解了CC的能力以及可以期待什么。
关于质量和一致性的一点说明
我注意到论坛和讨论中的一个反复出现的主题------人们遇到使用限制的挫败感以及担心输出质量随时间下降的问题。我想在前面明确表示:我不是在这里忽视那些经历或声称这只是"做错了"的问题。每个人的用例和背景都不同,合理的担忧值得被倾听。
也就是说,我想分享什么对我有用。在我的经验中,CC的输出在过去几个月里实际上显著改善了,我相信这主要是由于我不断优化的工作流程。我希望如果你从我的系统中获得一点点的灵感并将其集成到你的CC工作流程中,你会给它在产生你满意的质量输出方面更好的机会。
现在,让我们现实一点------绝对有些时候Claude完全misses the mark并产生次优代码。这可能由于各种原因发生。首先,AI模型是随机的,意味着你可以从相同输入获得完全不同的输出。有时随机性就不利于你,你得到的输出就是 legitimately poor quality,这并不是你的错。其他时候,这取决于提示的结构。由于模型的字面解释,略有不同的措辞可能导致输出显著差异。如果你措辞不当或表达模糊,可能导致结果质量大大降低。
有时你只需要介入
看,AI令人难以置信,但它不是魔法。在某些问题上,模式识别和人类直觉就是会赢。如果你花了30分钟看Claude挣扎于你能在2分钟内修复的事情,就自己修复它。这不丢人。把它想象成教别人骑自行车,有时你只需要在松手之前稳定一秒钟把手。
我特别在逻辑谜题或需要现实世界常识的问题上看到这一点。AI可以蛮力处理很多事情,但有时人类就是"懂"得更快。不要让固执或某种错误的"但AI应该做一切"的观念浪费你的时间。介入,解决问题,然后继续前进。
我也有过自己糟糕的提示经历,这通常发生在我变懒的一天结束时,没有在我的提示上投入太多努力。结果真的显示出来。所以下次你遇到这些问题,认为现在的输出比以前差多了,因为你认为Anthropic偷偷削弱了Claude,我鼓励你退一步反思你如何提示。
经常重新提示。 你可以按双esc键调出你之前的提示并选择一个来分支。你会惊讶于当你知道什么不想要时,同样的提示经常能获得更好的结果。总而言之,输出质量似乎更差可能有很多原因,反思并考虑你能做些什么给它最好的机会获得你想要的输出,这是很好的。
正如某个智慧的家伙可能说过的,"不要问Claude能为你做什么,问你能给Claude什么上下文" ~ 智慧家伙
好吧,现在我要从我的soapbox走下来,进入好东西。
我的系统
在过去6个月中,我实现了很多与CC相关的工作流程变更,结果相当不错,IMO。
技能自动激活系统(游戏规则改变者!)
这个值得单独一节,因为它完全改变了我与Claude Code的工作方式。
问题
Anthropic发布了这个技能功能,我在想"这看起来太棒了!"拥有这些便携、可重用的指导方针供Claude参考,听起来非常适合在我庞大的代码库中维护一致性。我花了大量时间与Claude为前端开发、后端开发、数据库操作、工作流程管理等编写全面的技能。我们说的是数千行的最佳实践、模式和例子。
然后......什么都没有。Claude就是不会使用它们。我真的会使用技能描述中的确切关键词。什么都没有。我处理应该触发技能的文件。什么都没有。这令人难以置信的沮丧,因为我能看到潜力,但技能就像昂贵的装饰品一样坐在那里。
"啊哈!"时刻
这时我有了使用hooks的想法。如果Claude不会自动使用技能,如果我构建一个系统让它在做任何事情之前都检查相关技能呢?
所以我深入研究Claude Code的hook系统,并构建了一个带有TypeScript hooks的多层自动激活架构。它实际上有效!
如何工作
我创建了两个主要的hooks:
-
UserPromptSubmit Hook(在Claude看到你的消息之前运行):
- 分析你的提示的关键词和意图模式
- 检查哪些技能可能是相关的
- 向Claude的上下文注入格式化的提醒
- 现在当我问"布局系统如何工作?"Claude在读取我的问题之前看到大的"🎯 SKILL ACTIVATION CHECK - Use project-catalog-developer skill"(项目目录是我的前端基于复杂数据网格的功能)
-
Stop Event Hook(在Claude完成响应后运行):
- 分析哪些文件被编辑
- 检查有风险的模式(try-catch块、数据库操作、async函数)
- 显示温和的自我检查提醒
- "你添加了错误处理吗?Prisma操作是否使用了repository模式?"
- 非阻塞,只是让Claude感知而不烦人
skill-rules.json配置
我创建了一个中央配置文件,定义每个技能包括:
- 关键词:明确主题匹配("layout"、"workflow"、"database")
- 意图模式:捕获动作的正则表达式("(create|add).*?(feature|route)")
- 文件路径触发器:根据你编辑的文件激活
- 内容触发器:如果文件包含特定模式激活(Prisma imports、controllers等)
示例片段:
json
{
"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行。这些整体文件正在 defeat 技能的整个目的(只加载你需要的东西)。
所以我重新组织了所有内容:
- 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的肩膀,实际记住所有模式。
为什么这很重要
技能 + hooks之前:
- Claude会使用旧模式即使我记录了新模式
- 每次都得手动告诉Claude检查BEST_PRACTICES.md
- 在30万+行代码库中代码不一致
- 花太多时间修复Claude的"创造性解释"
技能 + hooks之后:
- 一致的模式自动强制执行
- Claude在我看到代码之前自我纠正
- 可以相信指导方针被遵循
- 在审查和修复上花的时间少得多
如果你在处理有既定模式的大型代码库,我强烈推荐这个系统。初始设置花了几天才做对,但它已经十倍回报了。
CLAUDE.md和文档演进
在我6个月前写的一篇帖子中,我有一个关于规则是你最好朋友的部分,我仍然坚持。但我的CLAUDE.md文件很快变得失控,试图做得太多。我还有一个巨大的BEST_PRACTICES.md文件(1400+行),Claude有时会读,有时会完全忽略。
所以我花了一个下午与Claude整合并将所有内容重新组织成一个新系统。这是变化的:
什么移动到技能
以前,BEST_PRACTICES.md包含:
- TypeScript标准
- React模式(hooks、components、suspense)
- 后端API模式(routes、controllers、services)
- 错误处理(Sentry集成)
- 数据库模式(Prisma使用)
- 测试指导方针
- 性能优化
所有这些现在都在技能中,有自动激活hook确保Claude实际使用它们。不再希望Claude记得检查BEST_PRACTICES.md。
什么留在CLAUDE.md
现在CLAUDE.md专注于项目特定信息(约200行):
- 快速命令(
pnpm pm2:start、pnpm build等) - 特定服务配置
- 任务管理工作流程(dev docs系统)
- 测试经过身份验证的路由
- 工作流程干运行模式
- 浏览器工具配置
新结构
scss
根CLAUDE.md (100行)
├── 关键通用规则
├── 指向特定repository的claude.md文件
└── 引用技能获取详细指导方针
每个Repo的claude.md (50-100行)
├── 快速开始部分指向:
│ ├── PROJECT_KNOWLEDGE.md - 架构和集成
│ ├── TROUBLESHOOTING.md - 常见问题
│ └── 自动生成的API文档
└── 特定repository的怪癖和命令
魔法:技能处理所有"如何编写代码"的指导方针,CLAUDE.md处理"这个特定项目如何工作。"关注点分离的胜利。
Dev Docs系统
在所有东西中(除了技能),这个系统我认为对从CC获得的结果影响最大。Claude就像一个极其自信的初级开发人员,有严重的健忘症,容易迷失他们在做的事情。这个系统旨在解决这些缺点。
来自我的CLAUDE.md的dev文档部分:
开始大任务
当以接受的计划退出计划模式时:
-
创建任务目录:
bashmkdir -p ~/git/project/dev/active/[task-name]/ -
创建文档:
[task-name]-plan.md- 接受的计划[task-name]-context.md- 关键文件、决策[task-name]-tasks.md- 工作检查清单
-
定期更新:立即标记任务完成
继续任务
- 检查
/dev/active/寻找现有任务 - 继续前阅读所有三个文件
- 更新"最后更新"时间戳
这些是为每个功能或大任务创建的文档。在使用这个系统之前,我有很多次突然意识到Claude迷失了方向,我们不再实现30分钟前计划的东西,因为无论什么原因我们走上了某个切线。
我的规划过程
我的过程从规划开始。规划为王。如果你在要求Claude实现某东西之前至少没有使用规划模式,你会很难受,好的。你不会让建造师来你家开始加盖附加建筑而不让他先画图。
当我开始规划一个功能时,我把它进入规划模式,即使我最终会让Claude将计划写在markdown文件中。我不确定进入规划模式是必要的,但对我来说,感觉规划模式在做你的代码库研究并获得所有正确的上下文来能够制定计划方面获得更好的结果。
我创建了一个strategic-plan-architect子代理,基本上是一个规划猛兽。它:
- 高效收集上下文
- 分析项目结构
- 创建包含执行摘要、阶段、任务、风险、成功指标、时间线的全面结构化计划
- 自动生成三个文件:计划、上下文和任务检查清单
但我觉得看不到代理的输出很烦人,更烦人的是如果你对计划说不,它只是杀死代理而不是继续规划。所以我也创建了一个自定义斜杠命令(/dev-docs)在主CC实例上使用相同的提示。
一旦Claude吐出那个漂亮的计划,我花时间彻底审查它。这一步真的很重要。花时间理解它,你会惊讶于你多经常抓住愚蠢的错误或Claude误解请求或任务的一个非常关键的部分。
很多时候,我会在退出规划模式时剩下15%的上下文或更少。但这没关系,因为我们将把开始所需的一切放入我们的dev文档。Claude通常喜欢直接跳进来开始干,所以我立即按ESC键中断并运行我的/dev-docs斜杠命令。命令接受批准的计划并创建所有三个文件,有时如果有足够的上下文,会做更多的研究来填补空白。
一旦我完成了这些,我基本上都准备好让Claude完全实现功能而不迷失或忘记它在做什么,即使在自动压缩期间。我只是确保偶尔提醒Claude更新任务以及任何相关上下文的上下文文件。一旦我在当前会话中上下文运行低,我就运行我的斜杠命令/update-dev-docs。Claude会记录任何相关上下文(带有下一步)以及标记任何完成的任务或添加新任务,然后我压缩对话。在新会话中我需要做的就是说"继续"。
在实施期间,根据功能或任务的大小,我会特别告诉Claude一次只实现一两个部分。这样,我能在每组任务之间有机会进入并审查代码。而且定期,我也有一个子代理审查更改,所以我能及早发现大错误。如果你不让Claude审查它自己的代码,那么我强烈推荐它,因为它为我节省了很多头痛,抓住了关键错误、缺失实现、不一致代码和安全漏洞。
PM2进程管理(后端调试游戏规则改变者)
这个是一个相对较新的补充,但它使调试后端问题变得容易多了。
问题
我的项目有七个后端微服务同时运行。问题是Claude在服务运行时无法查看日志。我不能只是问"邮件服务出了什么问题?" - Claude看不到日志,除非我手动将它们复制粘贴到聊天中。
中间解决方案
一段时间,我让每个服务使用devLog脚本将其输出写入时间戳日志文件。这工作......还行。Claude可以读取日志文件,但很笨拙。日志不是实时的,服务在崩溃时不会自动重启,管理一切都很痛苦。
真正的解决方案:PM2
然后我发现了PM2,它是一个游戏规则改变者。我配置所有后端服务通过PM2使用单个命令运行:pnpm pm2:start
这给我带来什么:
- 每个服务作为管理进程运行,有自己的日志文件
- Claude可以轻松实时读取单个服务日志
- 崩溃时自动重启
- 使用
pm2 logs实时监控 - 使用
pm2 monit内存/CPU监控 - 容易的服务管理(
pm2 restart email、pm2 stop all等)
PM2配置:
javascript
// 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之前:
arduino
我:"邮件服务抛出错误"
我:[手动找到并复制日志]
我:[粘贴到聊天中]
Claude:"让我分析一下..."
现在调试工作流程:
css
我:"邮件服务抛出错误"
Claude:[运行] pm2 logs email --lines 200
Claude:[读取日志] "我看到问题 - 数据库连接超时..."
Claude:[运行] pm2 restart email
Claude:"重启了服务,监控错误..."
白天和黑夜的区别。Claude现在可以自主调试问题,而不需要我成为人类日志获取服务。
一个警告:热重载不适用于PM2,所以我仍然单独运行前端使用pnpm dev。但对于不需要经常热重载的后端服务,PM2令人难以置信。
Hooks系统(#NoMessLeftBehind)
我正在处理的项目是多根的,在根项目目录中有大约八个不同的repository。一个用于前端,七个用于后端的微服务和实用程序。我不断在几个repository之间弹跳,根据功能进行更改。
有一件事会让我极度烦人,就是当Claude忘记在其编辑的任何repository中运行构建命令来捕获错误。它只会留下十几个左右的TypeScript错误而不让我发现。然后几个小时后我看到Claude像个好孩子一样运行构建脚本,我看到输出:"有几个TypeScript错误,但它们无关紧要,所以我们这里都很好!"
不,我们不好,Claude。
Hook #1:文件编辑跟踪器
首先,我创建了一个post-tool-use hook,在每次Edit/Write/MultiEdit操作后运行。它记录:
- 哪些文件被编辑
- 它们属于哪个repository
- 时间戳
最初,我让它立即在每次编辑后运行构建,但那效率极其低下。Claude经常在进行修复之前进行破坏事物的编辑。
Hook #2:构建检查器
然后我添加了一个Stop hook,在Claude完成响应时运行。它:
- 读取编辑日志找到哪些repository被修改
- 在每个受影响的repository上运行构建脚本
- 检查TypeScript错误
- 如果<5个错误:显示给Claude
- 如果≥5个错误:建议启动auto-error-resolver代理
- 记录所有东西用于调试
自从实现这个系统以来,我没有一次实例让Claude在代码中留下错误让我以后发现。hook立即捕获它们,Claude在继续之前修复它们。
Hook #3:Prettier格式化器
这个简单但有效。在Claude完成响应后,使用适合该repository的.prettierrc配置自动用Prettier格式化所有编辑的文件。
不再手动编辑文件只是让prettier运行并产生20个更改,因为Claude上周我们创建文件时决定省略尾随逗号。
⚠️ 更新:我不再推荐这个Hook
发布后,一个读者分享了详细数据,显示文件修改会触发<system-reminder>通知,可能消耗大量上下文token。在他们的情况下,Prettier格式化导致在3轮中仅160k token消耗,因为system-reminders显示文件差异。
虽然影响因项目而异(大文件和严格的格式化规则是最坏情况),我从设置中删除了这个hook。无论如何,当你手动编辑文件时让格式化发生不是什么大事,潜在的token成本不值得这种便利。
如果你想要自动格式化,考虑在会话之间手动运行Prettier而不是在Claude对话期间。
Hook #4:错误处理提醒
这是我之前提到的温和哲学hook:
- 在Claude完成后分析编辑的文件
- 检测有风险的模式(try-catch、async操作、数据库调用、controllers)
- 如果编写了有风险的代码显示温和提醒
- Claude自我评估是否需要错误处理
- 无阻塞,无摩擦,只是感知
示例输出:
sql
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
📋 ERROR HANDLING SELF-CHECK
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
⚠️ Backend Changes Detected
2 file(s) edited
❓ Did you add Sentry.captureException() in catch blocks?
❓ Are Prisma operations wrapped in error handling?
💡 Backend Best Practice:
- All errors should be captured to Sentry
- Controllers should extend BaseController
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
完整Hook管道
现在每次Claude响应会发生什么:
yaml
Claude完成响应
↓
Hook 1: Prettier格式化器运行 → 所有编辑的文件自动格式化
↓
Hook 2: 构建检查器运行 → 立即捕获TypeScript错误
↓
Hook 3: 错误提醒运行 → 错误处理的温和自我检查
↓
如果发现错误 → Claude看到并修复它们
↓
如果错误太多 → 建议auto-error-resolver代理
↓
结果:干净、格式化、无错误代码
而UserPromptSubmit hook确保Claude在开始工作之前加载相关技能。
没有留下混乱。 这很美。
附加到技能的脚本
我从GitHub上Anthropic的官方技能示例中学到的一个很酷的模式:将实用脚本附加到技能。
例如,我的backend-dev-guidelines技能有一个关于测试经过身份验证的路由的部分。不仅仅是解释身份验证如何工作,技能引用实际脚本:
测试经过身份验证的路由
使用提供的test-auth-route.js脚本:
bash
node scripts/test-auth-route.js http://localhost:3002/api/endpoint
脚本为你处理所有复杂的身份验证步骤:
- 从Keycloak获取刷新令牌
- 用JWT密钥签名令牌
- 创建cookie头部
- 发出经过身份验证的请求
当Claude需要测试路由时,它确切知道要使用什么脚本以及如何使用它。不再有"让我创建一个测试脚本"和每次重新发明轮子。
我计划扩展这个模式------将更多实用脚本附加到相关技能,以便Claude有现成的工具而不是从头生成它们。
工具和其他东西
Mac上的SuperWhisper
当我因为打字手累时进行语音转文本提示。效果出奇地好,Claude理解我蹩脚的语音转文本出奇地好。
Memory MCP
我现在使用得越来越少,因为技能处理了大部分"记住模式"的工作。但它仍然用于跟踪项目特定决策和架构选择,这些不属于技能。
BetterTouchTool
- 从Cursor复制相对URL(用于共享代码引用)
- 我打开VSCode更容易找到我正在寻找的文件,我可以双击CAPS-LOCK,然后BTT输入快捷键复制相对URL,通过在剪贴板内容前面加上'@'符号来转换,聚焦终端,然后粘贴文件路径。一切都在一个动作中完成。
- 双击热键快速聚焦应用(CMD+CMD = Claude Code, OPT+OPT = Browser)
- 常见动作的自定义手势
老实说,仅仅不在应用之间摸索的时间节省就值得BTT购买。
所有东西都有脚本
如果有任何烦人的乏味任务,很可能有一个脚本:
- 生成模拟测试数据的命令行工具。在使用Claude代码之前,生成模拟数据极其烦人,因为我要向一个有大约120个问题的表单提交才能生成一个测试提交。
- 身份验证测试脚本(获取令牌、测试路由)
- 数据库重置和播种
- 迁移前模式差异检查器
- 开发数据库的自动备份和恢复
专业提示:当Claude帮助你编写一个有用的脚本时,立即在CLAUDE.md中记录它或将它附加到相关技能。未来的你会感谢过去的你。
文档(仍然重要,但已演进)
我认为除了规划之外,文档几乎同样重要。我除了为每个任务或功能创建的dev文档之外,还在进行过程中记录一切。从系统架构到数据流图到实际开发人员和API文档,仅举几例。
但这里改变了什么:文档现在与技能一起工作,而不是代替它们。
**技能包含:**可重用模式、最佳实践、如何指导方针 **文档包含:**系统架构、数据流、API参考、集成点
例如:
- "如何创建controller" → backend-dev-guidelines技能
- "我们工作流引擎如何工作" → 架构文档
- "如何编写React组件" → frontend-dev-guidelines技能
- "通知如何在系统中流动" → 数据流图 + 通知技能
我仍然有很多文档(850+ markdown文件),但现在它们专注于项目特定架构,而不是重复更好地由技能服务的一般最佳实践。
你不一定非要那么疯狂,但我强烈建议设置多个级别的文档。用于特定服务的广泛架构概述,其中包含指向更详细的不同架构部分文档的路径。这将在Claude轻松导航你的代码库能力方面产生重大差异。
提示技巧
当你写出提示时,你应该尽可能具体说明你想要什么作为结果。再说一次,你不会让建造师来为你建造新浴室而不至少讨论计划,对吗?
"你完全正确!毛茸茸的地毯可能不是浴室的最佳选择。"
有时你可能不知道细节,这没关系。如果你不问问题,告诉Claude研究并带回几个潜在的解决方案。你甚至可以使用专门的子代理或使用任何其他AI聊天界面做你的研究。世界是你的牡蛎。我保证这会带来回报,因为你将能够查看Claude产生的计划并更好地了解它是否好、坏或需要调整。否则,你只是在盲目飞行,纯粹的氛围编程。然后你会陷入不知道要包含什么上下文的境地,因为你不知道什么文件与你试图修复的东西相关。
尽量不要在提示中引导,如果你想要诚实的、无偏见的反馈。如果你对Claude做的事情不确定,用中立的方式询问,而不是说,"这是好还是坏?"Claude倾向于告诉你它认为你想听的,所以引导性问题可能会扭曲回应。更好的方法是描述情况并询问想法或替代方案。这样你会得到更平衡的答案。
代理、Hooks和斜杠命令(三位一体)
代理
我建立了一支专家代理小军队:
质量控制:
- code-architecture-reviewer - 审查代码是否遵守最佳实践
- build-error-resolver - 系统地修复TypeScript错误
- refactor-planner - 创建全面重构计划
测试和调试:
- auth-route-tester - 用身份验证测试后端路由
- auth-route-debugger - 调试401/403错误和路由问题
- frontend-error-fixer - 诊断和修复前端错误
规划和策略:
- strategic-plan-architect - 创建详细实施计划
- plan-reviewer - 实施前审查计划
- documentation-architect - 创建/更新文档
专业化:
- frontend-ux-designer - 修复样式和UX问题
- web-research-specialist - 研究问题以及网上许多其他东西
- reactour-walkthrough-designer - 创建UI tours
代理的关键是给他们非常特定的角色和明确的指示关于返回什么。我在创建了会跑去做谁知道什么、带着"我修复了!"回来而不告诉我它修复了什么的代理后,艰难地学到了这一点。
Hooks(上面已覆盖)
Hook系统诚然是将一切联系在一起的东西。没有hooks:
- 技能闲置不用
- 错误溜走
- 代码格式不一致
- 没有自动质量检查
有了hooks:
- 技能自动激活
- 零错误遗留
- 自动格式化
- 内置质量感知
斜杠命令
我有相当多的自定义斜杠命令,但这些是我最常用的:
规划和文档:
/dev-docs- 创建全面战略计划/dev-docs-update- 压缩前更新dev文档/create-dev-docs- 将批准的计划转换为dev文档文件
质量和审查:
/code-review- 架构代码审查/build-and-fix- 运行构建并修复所有错误
测试:
/route-research-for-testing- 找到受影响的路由并启动测试/test-route- 测试特定经过身份验证的路由
斜杠命令的美妙之处在于它们扩展成完整的提示,所以你可以将大量上下文和指令打包成一个简单的命令。比每次输入相同的指令好得多。
结论
在六个月硬核使用后,这是我学到的:
必需品:
- 规划一切 - 使用规划模式或strategic-plan-architect
- 技能 + Hooks - 自动激活是技能实际可靠工作的唯一方式
- Dev文档系统 - 防止Claude迷失方向
- 代码审查 - 让Claude审查它自己的工作
- PM2用于后端 - 使调试真正可忍受
锦上添花:
- 为常见任务设置专门代理
- 为重复工作流程设置斜杠命令
- 全面文档
- 附加到技能的实用脚本
- 用于决策的Memory MCP
现在我基本上能想到的就是这些了。就像我说的,我只是一个人,我很想听到其他人的技巧和窍门,以及任何批评。因为我总是愿意改进我的工作流程。我只是真的想与我尽可能多的人分享什么对我有效,因为我在现实生活中没有人可以分享(我的团队很小,他们在AI列车上都慢了大约一年)。
如果你读到这里,感谢花时间阅读。如果你对任何这些东西有疑问或想要更多实施细节,我很高兴分享。hooks和技能系统特别是花了一些试验和错误才做对,但现在它工作了,我无法想象回去。
TL;DR: 使用TypeScript hooks为Claude Code技能构建了自动激活系统,创建了防止上下文丢失的dev文档工作流程,并实现了PM2 + 自动错误检查。结果:6个月独自重写30万行代码,质量一致。