1. 从装了一堆Skill却用不起来说起如果你最近在折腾 Agent 相关的东西大概率已经被各种 Skill 刷屏了。打开任何一个技术社区满眼都是这个 Skill 太强了装上就回不去了效率直接翻倍。于是你兴冲冲地装了一堆结果发现——真正每天会主动用的可能就那么两三个剩下的全在列表里吃灰。这个现象太普遍了。我自己前前后后试过的 Skill 没有一百也有八十从最早的 claude-mem 到后来的 frontend-design、superpowers 系列踩过的坑比用顺手的多得多。所以当有人问我到底哪几个 Skill 值得装的时候我一般不会甩一个长长的清单过去而是先反问一句你平时最重复、最烦、最容易出错的动作是什么Skill 这个东西的本质不是给你增加功能而是把你已经会做但懒得做、或者容易做漏的事情固化成一个可以随时调用的动作。它解决的是重复劳动和流程遗忘这两个问题而不是我不会做的问题。想清楚这一点你选 Skill 的眼光会立刻变得挑剔起来。下面这 5 个 Skill是我在长期使用中真正留下来的。它们覆盖了记忆管理、前端产出、任务编排、代码审查、内容去味这几个高频场景。我不会只告诉你它很强而是会讲清楚它到底解决了什么痛点、为什么这样设计、以及我在实际使用中踩过哪些坑。如果你正在搭自己的 Agent 工作流或者单纯想让手上的工具更顺手这篇应该能帮你少走不少弯路。2. claude-mem让 Agent 真正记住上次聊到哪2.1 为什么大多数 Agent 的记忆都是假的先说一个很多人没意识到的问题大部分所谓有记忆的 Agent记忆其实是假的。它们要么把整段对话历史一股脑塞进上下文要么用一个简单的摘要覆盖掉旧内容。前者的问题是 token 爆炸聊到后面又慢又贵后者的问题是信息丢失你上周让它记住的项目约定这周它忘得一干二净。claude-mem 这个 Skill 的价值就在于它把记忆当成一个需要主动管理的工程问题来处理而不是靠上下文窗口硬扛。它的核心思路是把对话中值得留存的信息抽取出来结构化存储然后在需要的时候按相关性检索回来。这跟人脑的工作方式其实很像——你不会记住每一次对话的每个字但你会记住关键结论和约定。我实测下来装了 claude-mem 之后最明显的变化是跨会话的项目连续性变好了。以前每次开新对话都要重新交代一遍我这个项目用的是 XX 框架、目录结构是这样、命名规范是那样现在这些约定会被自动记住新会话里直接就能用。2.2 记忆抽取的粒度控制是门手艺claude-mem 用起来最需要调的地方是记忆抽取的粒度。抽得太粗记不住细节抽得太细又会把一堆废话也存进去检索的时候全是噪音。我的经验是把记忆分成三层来管理项目级约定技术栈、目录结构、命名规范、代码风格。这类信息变化慢一旦确定就长期有效优先级最高。任务级上下文当前在做什么、做到哪一步、下一步计划。这类信息生命周期短任务完成后就可以归档。事实级知识某个 API 的用法、某个报错的解决方案、某段配置的含义。这类信息复用率高值得长期保留。在配置抽取规则的时候我会明确告诉它哪些内容属于哪一层。比如项目级约定用固定的关键词触发像我们约定统一用规范是任务级上下文用时间标记事实级知识则靠语义相似度去重。这样检索的时候不同场景调不同层命中率会高很多。注意claude-mem 的存储如果放在本地记得定期清理过期的事实级知识。我见过有人用了半年记忆库膨胀到几万条检索一次要好几秒体验反而变差了。2.3 检索时机比存储更重要很多人把精力全花在怎么存上却忽略了什么时候取。claude-mem 的检索触发时机直接决定了它是有用还是添乱。我的做法是设置明确的检索触发条件而不是每轮对话都去查一遍记忆库。具体来说这几种情况才触发检索用户提到上次之前我们说过这类回溯性词汇时当前任务涉及的文件路径、函数名、配置项在记忆库里有记录时用户明确要求按之前的规范来时。其他时候就让记忆库安静待着。这样既省 token又避免了不相关的记忆干扰当前对话。我踩过的一个坑就是早期设成了每轮都检索结果 Agent 老是莫名其妙地引用一些陈年旧事把简单问题复杂化。3. frontend-design把能看变成能交付3.1 前端产出最大的问题不是不会写是没审美frontend-design 这个 Skill 解决的是一个很具体但很痛的问题Agent 写出来的前端页面功能往往没问题但就是丑。按钮间距不对、颜色搭配辣眼睛、响应式一塌糊涂。你让它改它改完还是丑因为它根本不知道什么叫好看。这个 Skill 的核心是把一套设计规范前置到生成流程里。它不是在生成完之后再修而是在生成之前就把栅格系统、间距节奏、配色方案、字体层级这些东西定好。这就像装修房子先出设计图再施工而不是砌完墙再说这面墙颜色不对。我拿它做过几个内部工具的后台页面最直观的感受是出来的东西第一次就能给人看不用再花半小时调样式。以前用裸的 Agent 生成出来的页面我得手动改一堆 CSS现在基本是微调。3.2 设计令牌的注入方式决定了产出质量frontend-design 用得好不好关键看设计令牌design token怎么注入。所谓设计令牌就是把颜色、间距、字号、圆角这些基础值抽成变量统一管理。我的做法是维护一份自己的令牌文件包含这几组令牌类别示例值用途主色#2563eb按钮、链接、强调中性色阶#f8fafc 到 #0f172a背景、文字、边框间距4/8/12/16/24/32px内边距、外边距、间隙字号12/14/16/20/24/32px正文、标题、辅助文字圆角4/8/12px卡片、按钮、输入框把这套令牌喂给 frontend-design它生成出来的页面就会自带一致性。不会出现这个按钮圆角 4px、那个卡片圆角 12px 的混乱情况。提示令牌不要设太多档位。我一开始设了 10 档间距结果 Agent 每次选值都要纠结产出反而不稳定。后来砍到 6 档效果好很多。3.3 响应式断点要提前说清楚frontend-design 默认的响应式策略是移动优先但如果你不明确告诉它断点在哪它可能会用一套很奇怪的断点组合。我一般会明确指定三个断点手机640px、平板640-1024px、桌面1024px。然后针对每个断点说明布局怎么变。比如桌面端侧边栏固定 240px平板端侧边栏收起为图标手机端侧边栏变成抽屉。这样生成出来的页面在不同尺寸下都有合理的表现而不是简单地缩放。我见过太多 Agent 生成的页面桌面端好看一到手机端就挤成一团就是因为断点策略没提前定。4. superpowers任务编排的总调度4.1 单个 Skill 再强串不起来也是白搭装了一堆 Skill 之后新的问题来了什么时候用哪个多个 Skill 之间怎么配合这就是 superpowers 要解决的事。superpowers 本质上是一个任务编排层。它不直接干活而是负责判断当前任务需要哪些能力然后按顺序调用对应的 Skill。这就像一个项目经理自己不写代码但知道该派谁去干哪件事。我一开始觉得这层是多余的觉得我自己判断不就行了。但用久了发现当任务复杂到需要五六个步骤、涉及三四个 Skill 的时候人脑的调度能力其实很有限经常漏掉某一步或者顺序搞反。superpowers 的价值就在于把这个调度逻辑固化下来减少人为失误。4.2 编排逻辑要写成显式规则别靠模型猜superpowers 最容易踩的坑是把它当成一个智能调度器指望模型自己判断该调什么。实测下来这种模糊编排的稳定性很差同样的任务今天走这个流程明天走那个流程。正确做法是把编排逻辑写成显式规则。比如任务类型新增页面 步骤 1. frontend-design 生成页面骨架 2. 调用代码审查 Skill 检查规范 3. claude-mem 记录本次页面涉及的约定 4. 输出交付说明这种规则化的编排好处是可预测、可调试。出了问题你能定位到具体哪一步而不是面对一个黑盒干瞪眼。4.3 失败重试和降级策略不能省编排层还有一个容易被忽略的点失败处理。某个 Skill 调用失败了怎么办是重试、跳过、还是整个任务中止我的策略是分级处理关键步骤失败比如生成代码失败直接中止并报告不要继续往下走否则后面全是错的。非关键步骤失败比如记忆记录失败可以跳过不影响主流程但要在日志里标记。可重试步骤比如网络请求类的设置最多 3 次重试间隔递增。这套策略写进 superpowers 的配置里之后整个工作流的健壮性提升很明显。以前一个环节出错整个任务就崩了现在大部分小问题都能自动消化掉。5. 代码审查 Skill把规范检查从人肉变成自动5.1 为什么代码审查最该被 Skill 化代码审查这件事重复度极高而且特别容易因为疲劳而漏检。同一个人审同一类问题前十个 PR 认真后十个就开始走马观花。这正是 Skill 最擅长的场景——不知疲倦地执行固定规则。我用的这个代码审查 Skill核心是把团队的编码规范拆成可执行的检查项。不是笼统地说代码要规范而是具体到函数不超过 50 行嵌套不超过 3 层魔法数字必须提取成常量这种可判定的规则。5.2 检查项要分阻断级和建议级一开始我把所有检查项都设成同等重要结果每次审查都报一大堆问题真正严重的反而被淹没了。后来改成两级级别处理方式示例阻断级必须修复才能合并空指针风险、资源未释放、SQL 注入建议级提示但不阻断命名风格、注释缺失、函数偏长这样分级之后审查结果的可读性大幅提升。开发者一眼就能看到哪些是必须改的哪些是可以商量的。5.3 审查 Skill 也要喂项目上下文通用的代码审查规则只能抓一些普适问题真正有价值的审查需要项目上下文。比如这个模块不允许直接访问数据库必须走 Repository 层这种规则只有知道项目架构才能判断。我的做法是在审查 Skill 里挂一份项目约定文件里面写清楚分层规则、依赖方向、禁止的用法。审查的时候先加载这份约定再结合通用规则一起判断。这样审查出来的问题才是真正贴合项目的。注意审查 Skill 的规则要定期更新。项目在演进老的规则可能已经过时了。我一般每个迭代回顾一次把不再适用的规则删掉把新出现的坑加进去。6. 去 AI 味的 Skill让产出像人写的6.1 AI 味到底是个什么东西最后这个 Skill 可能听起来有点虚但实际用起来价值很高。所谓AI 味就是那种一眼就能看出是机器生成的行文特征过度使用通过……可以……随着……的发展综上所述段落结构高度模板化缺乏具体的个人经验和细节。这个去 AI 味的 Skill做的事情就是在生成之后再过一遍把这些特征明显的表达替换掉同时补充具体的细节和口语化的表达。它不是简单地换同义词而是从行文节奏和内容密度上做调整。6.2 去味的关键是加细节而不是换词很多人以为去 AI 味就是换个说法把通过改成用把可以改成能。这只是表面功夫改完还是那股味。真正有效的做法是加细节。AI 生成的内容之所以有味道是因为它空泛——说了一堆正确的废话但没有具体的数字、场景、案例。你往里面塞进我实测下来上次踩了个坑这个参数设成 300 比较合适这类具体信息味道自然就淡了。我在配置这个 Skill 的时候会明确要求它做三件事把抽象表述替换成具体例子把被动句式改成主动句式在关键结论后面补充一句个人经验或注意事项。这三招下去产出的可读性提升非常明显。6.3 别过度去味保留必要的专业表达去 AI 味也要有个度。有些专业术语和固定表达是不能动的动了反而不专业。比如技术文档里的幂等原子性背压这些词你非要换成大白话读者反而看不懂。我的原则是行文风格去味专业术语保留。句子结构可以口语化但该用的术语一个不少。这样出来的内容既不像机器写的又不失专业性。7. 这 5 个 Skill 怎么组合才不打架单独用好每个 Skill 是一回事把它们组合起来是另一回事。我踩过的最大的坑就是几个 Skill 之间互相干扰。比如 claude-mem 和去 AI 味的 Skill 就曾经冲突过记忆库把去味后的内容存进去下次检索出来又是去味前的版本来回折腾。后来我把存储时机调整到去味之后问题才解决。再比如 superpowers 编排的时候如果同时触发 frontend-design 和代码审查两个 Skill 可能会对同一份代码给出矛盾的建议。我的处理方式是明确优先级设计相关的问题听 frontend-design规范相关的问题听代码审查冲突时以更严格的那个为准。组合使用的核心原则是明确每个 Skill 的职责边界避免功能重叠。职责清晰了编排起来才不会乱。我现在的工作流大致是这样一条链路superpowers 负责调度claude-mem 负责记忆frontend-design 负责产出代码审查负责把关去 AI 味负责收尾。各司其职串起来就是一条完整的生产线。这套组合我用了大半年最大的体会是Skill 的价值不在于数量而在于它们能不能形成合力。装十个各自为战的 Skill不如装五个能串起来的。如果你现在手上有一堆 Skill 但用得不顺不妨先停下来想想它们之间是不是缺了一个像 superpowers 这样的调度层或者缺了一个像 claude-mem 这样的记忆中枢。把骨架搭起来再往里填肉效果会完全不一样。