这个顺序其实我纠结了一会,到底要不要把Hook(钩子)和 /insight 放一起。
/insight会生成一份过去一个月我使用Claude Code的习惯报告。这份HTML报告里会反映出你最常用的命令是什么,哪些操作模式是高度重复的。它还会推荐一些可以自定义的命令或者现成的Skill。
我就发现Claude Code有时候会修改太多文件,我还可以把常见的TypeScript工作流打包成新Skills。
如果说/insight是主动触发的话,那Hook就是被动触发的。我不需要去记隔个月运行一下/insight,Hook就是在我们有特定的明确的事件触发时,自动执行某个操作。
我常用的就有两个比较实用的Hook,
一个是当一次对话里工具调用次数大于 8 次时,就让CC输出优化建议,让它来教我把刚刚的一连串操作沉淀成Skill。
如果你想先适应适应这个Hook的话,可以让它先在项目(也就是当前的文件夹)里生效,后面再把它拓展成为全局。
我刚开始还有一个坏习惯,就是在对话开始时,扔给它一大段零散,未经思考的需求,说白了就是语音输入一大段文本。很多时候AI理解偏差,一来一回浪费了我时间。所以我做了另一个Hook,
如果我单次输入的文本超过200个token,就启动Plan模式。先引导我把这个长需求确认好,结构化,拆解成清晰的步骤,再开始动手开发。
也不用担心设置hook的时候表达不清晰,CC会进一步细化,给出优化建议。
Hook省了我大量的心力。
我不需要费脑子去想,这个操作是不是值得做一个Skill,也不担心一是不是开始的需求没想清楚,导致后面返工。
我们可以利用hook的这个特点,去做很多有意思的自动化。我就还有一个Hook,每次准备git提交开源的时候,都会触发一个动作,把所有commit信息写到一个可视化的网页上,等我预览确认没问题后,再真正提交。
这样就不担心因为模型抽风,把项目里的说明文件写得一团糟了。
这个命令很简单,就是让Claude Code定时重复执行某个任务。
比方我刚刚开源了一个新Skill,我一个人用可能没啥bug,但用的人多就容易出新问题。所以我用/loop来定时看看只要有人提bug,就自动修复并提交,用的话就是在任务前加一个loop和时间间隔就可以了,
/loop 24h 检查一下这个项目(github.com/LearnPrompt/ai-news-radar)有没有人提交Issue或是PR,有的话自动修复后更新项目
CC会每隔24小时检查一次状态。
loop的好处就是轻量,七天后这个任务就会自动过期并删除,不会一直占用本地资源。如果需要一个长期运行的任务,可以用schedule在云端运行的,只要不取消就一直会跑。
同样是循环,Ralph Wiggum(我们就简称为Ralph吧)就是一个有停止条件的单一任务循环。
如果我想要长时间运行同一个任务,但是这个任务又可能不是一次运行就能成功的,
Ralph就能在我睡觉期间用满我的模型额度,比方说重构一个项目的UI,我常用的就是给这个任务设置最多循环10-15次,然后让CC自己给自己出一个验收标准,
Opus 4.6最近降智有点严重,
所以我在Claude Code里用Codex的频率也升高了,OpenAI开源的这个codex-plugin-cc内置了/codex:review,用人话来说就是可以把现在的工作进度丢给Codex做代码审查。
🔗 https://github.com/openai/codex-plugin-cc
而且当时一出来的时候,我就觉得,既然能够发给Codex做代码检查,那我为什么不能把它当作为一个在Claude Code里随时随地调用Codex完成其他任务的入口呢?
所以我直接原汤化原食,
让Codex自己在项目里面新增了一个叫Codex Ask的功能,这样我可以把开发任务全部给Claude Code做,到了写开发计划,或者是文本写作的时候,还可以用到 GPT 5.4 high。
PS:也可以不用改,把/codex:rescue当通用Agent用
这一步,我其实还做了一个让它们记忆共享的Skill,在后面的文章里面会开源出来。
OK啊,当你把上面这几个命令都玩熟了,再配上几个从/insight里学到的Skill,
我可以保证,你已经比很多人用得溜了。
但我们还可以再讲究点。接下来的这几个参数,不是命令,是在我们开启一段新对话时,就能用上的开场白,就像游戏开局时,你可以选择的几个被动技能,选对了会省很多时间。
-c就是continue,
如果不小心把终端关了,或者电脑没电,总之就是各种各样的意外,导致你这次的对话突然中断的话,我们都可以加-c恢复。最近一次的对话记录,像游戏读档一样。
接下来,也是我开头提到的,省token小妙招,这个参数叫–add-dir。
比方说,我们在A文件夹里写代码做知识管理,但同时,我又需要参考我电脑另一个角落里,Obsidian文件夹里的一些个人笔记和设计规范。
那我只要在启动的时候,用–add-dir参数把Obsidian的路径加进来。这样CC就能直接读取那个文件夹里的所有内容,我不需要再复制粘贴任何文本,它就能理解我的所有黑话和个人习惯。
前面九个技巧,都是在让你用主Agent的时候变得更强。第十个,也是最后一个技巧,我就要拿出多Agent了。
可能很多人一听到这个词就头大,会觉得要新设置很多东西,会影响主Agent的表现之类的。实际上Claude Code已经把入门的门槛降得很低了。
我们先说简单的,Sub-agent(子智能体)。
你可以把它理解成一个临时工。有些任务,比如去网上搜资料,或者去翻几十个日志文件,直接在当前对话里提问的话会产生大量没用的中间过程,把主对话上下文搞得乱七八糟。
这时候就可以派subagent去干。它会在自己的工作空间里,默默地完成这些脏活累活,最后把一个干净整洁的摘要报告,交回到你的主对话里。
我们只需要先用/agents命令,就可以用大白话,创建一个自己的子代理,比方说,
创建一个灵感Agent,它会扫描当前开发项目,使用superbrainstrom skill和office hour skill,给出新角度建议。
创建的过程很简单,CC会问你要用什么样的模型去驱动,然后它是一个只读Agent,还是执行Agent,是把所有的Tools都开放给它用,还是只开放一部分。
BTW,superbrainstrom和 YC总裁开源的office hour都是两个跟头脑风暴相关的Skill,非常互补,都是我比较推荐的Skills。
🔗 github.com/obra/superpowers/tree/main
🔗 github.com/garrytan/gstack/tree/main
Agent Teams把分工玩法带到了一个新高度。
不再是主Agent和临时工的关系,是一个真正的多Agent团队。我们可以一次性创建多个不同角色的Agent,让它们并行地,从不同角度去解决一个复杂问题。我有一个新产品的想法,就可以这样说,
我正在设计一个 CLI 工具,帮助开发者追踪整个代码库里的TODO。组建一个 Agent 团队,从不同角度来探索这个方向:一个成员负责用户体验,一个成员负责技术架构,另一个成员专门负责挑刺。
然后,我就啥都不用干,围观一场头脑风暴。这三个Agent会开始互相讨论,分享发现,甚至会给对方的观点挑毛病。
我们还可以像项目经理一样去管理这个团队,比如提前结束某个队友的对话,二次分配新的任务,或者让它们先出方案,等你批准了再执行。
这种多 Agent 协作会比单 Agent 更适合复杂任务,因为它能降低模型一条路走到黑的概率,也能在早期就发现问题。
好了,十个技巧,全部分享完了。
我知道,这时候肯定会有朋友觉得记这些太麻烦了,不如直接去GitHub上,把Everything Claude Code那个超级大合集项目,一把梭哈,156个Skill,48个Agent,72个Command全装上。
真的真的真的千万别这么干。
全装,意味着你的Claude Code会突然多了几百个你根本不了解的文件。可能连hook的用法都还没摸熟,就直接复用了别人的工作流。结果发现,别人用的我们平时根本用不上。
其实就是给模型增加了记忆负担。
我的建议是,
如果你是刚开始用Claude Code,那什么都别装。先用,用上了就会有痛点。痛点就是你最需要配置的第一条规则,第一个Skill。
如果你已经有了自己的工作流,想参考一下别人的配置。那就从那些大合集里,选适合你的。比如,通用的规则,会话保存的模板,最常用的Skill,就够了。
毕竟在AI加持之下,产品的进化速度太快太快了。
我现在已经用Codex设置了一个长期定时任务帮我每天去监控Claude Code的更新日志了,
这些就等我之后玩熟了再来继续分享。
睡了睡了(其实是熬穿了),
希望起来Claude没有更新。
版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容,请联系我们,一经查实,本站将立刻删除。
如需转载请保留出处:https://51itzy.com/kjqy/263948.html