1. 这五个 Skill 到底解决了什么问题第一次接触 Agent Skill 这个概念是在一个做前端交付的朋友那里。他给我看了一段不到两百行的配置说“这玩意儿让我少写了三天的重复代码”。当时我还不信直到自己把几个 Skill 装进工作流里跑了一周才明白为什么有人说“用后根本停不下来”。先把概念说清楚。Agent Skill本质上是一段可被 AI Agent 动态加载和调用的能力封装。它不像传统的函数库那样需要你手动 import而是以“技能描述 触发条件 执行逻辑”的形式挂载在 Agent 上Agent 在理解用户意图后自己决定要不要调用、调用哪个。你可以把它理解成给一个通用助手配了一套“专业工具箱”需要拧螺丝的时候它自己会去拿螺丝刀而不是每次都问你“请问您需要什么工具”。这次要聊的五个 Skill分别覆盖了记忆管理、前端设计、能力编排、空间分析、内容去味五个方向。它们对应的热词是 claude-mem、frontend-design、Superpowers、gis 空间分析 skill、去 AI 味的 skill。这五个不是随便凑的而是我在实际项目里反复验证过、真正能提升交付效率的组合。适合谁看如果你正在搭 AI Agent、做 Agent 开发、或者单纯想让手上的 AI 工具更好用这篇内容应该能帮你省下不少试错时间。我踩过的第一个坑就是以为 Skill 装得越多越好。结果 Agent 每次响应都要在几十个技能描述里做匹配延迟肉眼可见地涨还经常调错。后来才明白Skill 的价值不在于数量而在于覆盖高频场景的精准度。下面这五个是我筛完之后留下来的。2. 五个 Skill 的深度拆解与选型逻辑2.1 claude-mem让 Agent 真正记住上下文Agent 最让人抓狂的问题之一就是“失忆”。你上一轮刚说过项目用的是 React TypeScript下一轮它又给你生成 JavaScript 的代码。这不是模型笨而是上下文窗口有限历史信息被截断了。claude-mem 这个 Skill 解决的就是这个问题。它的核心思路不是简单地把对话历史塞进 prompt而是做了一层结构化记忆提取把对话中的关键事实技术栈、命名规范、业务约束、用户偏好抽出来存成一个可检索的记忆库每次新对话开始时按相关性注入。我实测下来配置大概是这样几个关键参数参数作用我的建议值memory_scope记忆作用范围project 级不要用 globalextract_threshold触发记忆提取的对话轮数3 轮max_memory_tokens注入记忆的最大 token 数800decay_days记忆衰减周期14 天为什么 memory_scope 要用 project 级因为全局记忆会串味。你在 A 项目里定的“所有接口用 snake_case”跑到 B 项目里可能就冲突了。project 级隔离能避免这种污染。注意max_memory_tokens 不要设太大。我一开始设了 2000结果每次请求都带着一大堆无关记忆不仅贵还干扰模型判断。800 是个比较舒服的平衡点。2.2 frontend-design把设计稿变成能跑的代码frontend-design 这个 Skill 的定位很明确输入设计意图输出可用的前端代码。但它和普通的“代码生成”不一样它内置了一套设计系统约束——间距用 4 的倍数、颜色从预设调色板取、组件优先复用而不是重新造。我拿它做过一个后台管理页面从描述到能跑起来大概花了二十分钟。关键不在于快而在于生成的代码结构是统一的。以前用通用模型生成十个组件十种写法后期维护想死。frontend-design 会强制走同一套组件规范这点对团队协作特别重要。它的触发方式也很有意思不是你说“帮我写个按钮”它就写而是需要你给出场景 约束。比如“一个数据密集型的表格页需要支持排序和分页风格偏克制”它才会启动完整的设计流程。这种设计其实是在逼你把需求想清楚反而减少了来回改的次数。2.3 SuperpowersSkill 的编排层如果说前面两个是“单项技能”Superpowers 就是技能的管理者和编排者。它解决的是一个很实际的问题当你有十几个 Skill 的时候怎么让 Agent 知道什么时候该用哪个、怎么组合使用。Superpowers 的核心机制是能力声明 依赖解析。每个 Skill 在注册时声明自己“能做什么”和“需要什么”Superpowers 负责在运行时做匹配和串联。举个例子你让 Agent“把这个设计稿实现出来并部署”它会自动串联 frontend-design生成代码→ 某个构建 Skill打包→ 某个部署 Skill上线。我装 Superpowers 的时候踩过一个坑依赖声明写得太宽泛。比如一个 Skill 声明“我能处理所有文本”结果什么请求都往它那儿路由把其他 Skill 饿死了。后来改成精确的能力描述路由准确率才上来。2.4 gis 空间分析 skill专业领域的降维打击这个 Skill 是我最近才加进来的但用一次就离不开了。它把常见的空间分析操作封装成了自然语言可调用的能力缓冲区分析、叠加分析、路径规划、热力图生成。以前做这类分析要么开 QGIS 手动点要么写 Python 调 geopandas门槛不低。现在直接说“找出这个点位三公里内所有学校”它自己会去做缓冲区 空间查询。专业工具的门槛被自然语言抹平了这是 Skill 机制最有价值的地方。不过要注意这类专业 Skill 对输入数据的格式很敏感。坐标系不统一、几何类型不匹配都会导致结果错误。我建议在调用前先做一次数据校验别等结果出来了才发现不对。2.5 去 AI 味的 skill让输出像人写的最后一个可能听起来有点“玄”但实际需求非常大。AI 生成的内容有个通病结构太工整、用词太套路、缺少个人痕迹。去 AI 味的 skill 就是针对这个来的。它的做法不是简单换同义词而是从几个维度做调整打散过于对称的句式结构、替换高频套话、注入口语化表达、调整段落长度节奏。我拿它处理过一批文案处理前后的对比很明显——处理前读起来像说明书处理后读起来像有人在跟你聊天。但这里有个度的问题。去味太狠会损失专业性尤其是技术文档该严谨的地方还是要严谨。我的做法是分场景配置强度营销文案用高强度技术文档用低强度。3. 从零搭建五个 Skill 的实操配置流程3.1 环境准备与基础依赖在装任何 Skill 之前先把基础环境理清楚。我用的是 Node.js 20 Python 3.11 的组合因为有些 Skill 依赖 Python 做数据处理有些依赖 Node 做前端生成。# 检查基础环境 node -v # 建议 18 python3 --version # 建议 3.10 # 创建工作目录 mkdir agent-skills cd agent-skills # 初始化配置 npm init -y目录结构我建议这样组织后面维护会清晰很多agent-skills/ ├── skills/ # 各 Skill 的配置 │ ├── claude-mem/ │ ├── frontend-design/ │ ├── superpowers/ │ ├── gis-analysis/ │ └── de-ai-flavor/ ├── memory/ # 记忆存储 ├── config.json # 全局配置 └── logs/ # 运行日志为什么要把每个 Skill 单独放一个目录因为它们的依赖可能冲突。比如 gis-analysis 需要特定版本的几何库frontend-design 需要特定版本的构建工具混在一起迟早出问题。隔离是最好的解耦。3.2 claude-mem 的安装与记忆策略配置claude-mem 的配置核心是记忆的提取和注入策略。我把它拆成三步第一步定义记忆的 schema。不是所有对话都值得记我一般只提取这几类{ memory_types: [ tech_stack, naming_convention, business_rule, user_preference ], extract_prompt: 从以下对话中提取上述类型的关键事实以 JSON 输出 }第二步配置注入时机。我试过两种方案每轮都注入 vs 按需注入。实测下来按需注入更好具体做法是用当前用户输入去检索记忆库只注入相关度高的那几条。第三步设置衰减。记忆不是越久越好过期的技术决策反而会误导。我设的是 14 天衰减超过周期的记忆权重降低除非被反复引用。实操心得刚开始跑的时候建议把日志打开看看它到底提取了什么、注入了什么。我第一周就是靠看日志发现它把一些闲聊也当成了“用户偏好”后来加了过滤规则才干净。3.3 frontend-design 的设计约束调优frontend-design 装好之后默认的设计约束不一定符合你的项目。我一般会做一次约束对齐把项目的设计 token 喂给它。{ spacing_unit: 4, color_palette: { primary: #2563eb, neutral: [#f8fafc, #e2e8f0, #94a3b8, #475569] }, component_library: internal-ui-kit, forbidden: [inline-style, !important] }这里forbidden字段很关键。我见过太多生成代码里塞满!important的情况后期根本没法维护。提前把禁忌写进去比事后改省事得多。另外component_library指向你项目里已有的组件库这样生成的代码会优先复用而不是重新造轮子。我实测下来复用率能从 30% 提到 70% 左右。3.4 Superpowers 的能力注册与路由规则Superpowers 的配置是五个里面最需要花心思的因为它管的是路由。每个 Skill 注册时能力描述要写得既准确又有区分度。{ skill: frontend-design, capabilities: [generate_ui_code, apply_design_system], triggers: [写页面, 实现设计稿, 生成组件], priority: 8, requires: [design_tokens] }triggers我建议用具体短语而不是宽泛的词。比如“写页面”比“前端”好因为“前端”太宽容易误触发。priority用来处理冲突数值高的优先。路由规则我踩过的坑是循环依赖。A 需要 BB 又需要 A结果死锁。Superpowers 一般有检测机制但最好在设计阶段就避免。我的原则是依赖关系必须是单向的 DAG不能有环。3.5 gis 空间分析 skill 的数据准备这个 Skill 对数据的要求比较高装之前先把数据规范定好检查项要求常见问题坐标系统一为 EPSG:4326 或项目指定混用导致距离计算错误几何类型明确 point/line/polygon类型不匹配查询失败数据完整性无空几何、无自相交分析结果异常索引空间索引已建立大数据量查询慢我一般会写一个预处理脚本在调用 Skill 之前先跑一遍import geopandas as gpd def validate(gdf): assert gdf.crs is not None, 缺少坐标系 assert gdf.geometry.is_valid.all(), 存在无效几何 assert not gdf.geometry.is_empty.any(), 存在空几何 return gdf别小看这几行校验它能帮你挡掉 80% 的“结果不对”问题。3.6 去 AI 味的 skill 强度分级配置最后一个的配置相对简单核心是强度分级{ intensity_levels: { low: {synonym_replace: true, restructure: false}, medium: {synonym_replace: true, restructure: true, inject_colloquial: false}, high: {synonym_replace: true, restructure: true, inject_colloquial: true} }, default: medium }我的使用习惯是技术文档用 low对外文案用 high内部沟通用 medium。这个分级不是拍脑袋定的是根据不同场景对“人味”的需求程度来的。4. 五个 Skill 协同工作的实战案例4.1 场景设定一个完整的前端交付任务光说单个 Skill 没意思真正体现价值的是组合使用。我拿最近做的一个真实任务来演示给一个物流系统做“网点分布可视化”页面。需求大概是这样展示全国网点分布支持按区域筛选点击网点显示详情还要有一个热力图看密度。数据是 GIS 格式的页面要符合公司设计规范文案要自然不能太机器。这个任务如果纯手工做我估计要两三天。用这五个 Skill 组合实际花了大概四小时。4.2 执行流程拆解第一步claude-mem 先上场。我把项目背景、技术栈、设计规范一次性告诉它让它记住。这样后面所有环节都不用重复交代。用户这个项目用 React 18 TypeScriptUI 库是内部的 xxx-ui 设计规范见 design-tokens.json地图用 xxx-map 库。claude-mem 会把这几条提取成记忆后续自动注入。第二步gis 空间分析 skill 处理数据。原始数据是 shapefile坐标系是 EPSG:3857我先转成 4326然后做聚合用户把这些网点数据按省份聚合算出每个省的网点数量和中心点它自己会做 groupby 空间聚合输出一份带中心点坐标的 JSON。第三步frontend-design 生成页面。我把聚合后的数据和设计约束一起给它用户生成一个网点分布页面左侧是省份列表右侧是地图 地图上显示网点热力图点击省份联动筛选它会按设计规范生成组件代码间距、颜色、组件复用都自动对齐。第四步Superpowers 做编排。其实前面几步的串联就是它在管。当我说“把数据处理好并生成页面”时它自动路由到 gis-analysis 再路由到 frontend-design中间的数据传递也是它负责的。第五步去 AI 味的 skill 处理文案。页面上的提示语、空状态文案、错误提示统一过一遍处理前暂无数据请尝试调整筛选条件后重试。 处理后这个范围里暂时没有网点换个条件试试差别很明显后者更像人写的。4.3 协同过程中的关键参数这个流程里有个参数特别关键Superpowers 的传递格式。gis-analysis 输出的 JSON 结构frontend-design 得能直接吃。我一开始没注意结果数据传过去格式不对页面生成失败。后来定了一个中间数据契约{ type: geo_aggregation, features: [ {region: 省份名, count: 12, center: [lng, lat]} ], crs: EPSG:4326 }所有 Skill 之间的数据传递都走这个契约问题就少了。这也是我建议大家在搭多 Skill 系统时一定要做的事先定数据契约再写 Skill。5. 常见问题与排查技巧实录5.1 Skill 不触发或触发错误这是最高频的问题。表现是你说了一句话Agent 要么没调用任何 Skill要么调用了不相关的。排查思路我整理成一张表现象可能原因排查方法完全不触发triggers 描述不匹配检查触发短语是否覆盖用户表达触发错误 Skill能力描述重叠看日志里的路由决策过程时好时坏优先级冲突检查 priority 设置触发后报错依赖未满足检查 requires 字段我的经验是80% 的触发问题出在描述上。描述太宽会误触发太窄会不触发。建议用真实用户会说的话来做 triggers而不是你自己想的“标准表达”。5.2 记忆污染与上下文串味claude-mem 用久了会遇到记忆污染不同项目的记忆混在一起导致 Agent 给出矛盾的决策。解决办法是严格的作用域隔离 定期清理。我一般每周做一次记忆审计把过期的、冲突的、低价值的记忆清掉。清理不是删是标记为 inactive万一需要还能恢复。避坑技巧给记忆加一个 source 字段记录它来自哪个项目、哪次对话。出问题的时候能快速定位。5.3 生成代码不符合项目规范frontend-design 生成的代码偶尔会跑偏尤其是项目有特殊规范的时候。我的做法是把规范写成可执行的检查而不是靠描述。比如“间距用 4 的倍数”这种与其写在 prompt 里不如加一个后置校验function checkSpacing(code) { const matches code.matchAll(/margin:\s*(\d)px/g); for (const m of matches) { if (parseInt(m[1]) % 4 ! 0) { throw new Error(间距 ${m[1]}px 不是 4 的倍数); } } }校验不过就打回重生成。这样比反复调 prompt 靠谱。5.4 空间分析结果偏差GIS 分析结果不对十有八九是坐标系或几何类型的问题。我遇到过一次算两个点的距离结果差了十倍。查了半天发现一个点是经纬度另一个是投影坐标。这种问题不看数据根本发现不了。所以我现在养成了一个习惯任何空间分析之前先打印数据的 crs 和几何类型。多花十秒省下半小时排查。5.5 去 AI 味过度导致专业性下降去 AI 味的 skill 用high 强度处理技术文档会把“该接口返回 200 状态码”改成“这个接口一般会给你个 200”专业度直接掉档。我的原则是分场景、分强度而且处理完要人工过一遍。机器去味是辅助最终判断还是得人来。尤其是涉及准确性的内容宁可保留一点“AI 味”也不能牺牲准确性。6. 我个人的使用体会这五个 Skill 用下来最大的感受是Skill 的价值不在于它多聪明而在于它把正确的做法固化下来了。以前每次做项目都要重新想“设计规范怎么对齐”“数据格式怎么统一”现在这些都被 Skill 封装好了我只需要关注业务本身。如果让我给刚上手的人一个建议那就是别贪多先把一个 Skill 用透。我见过太多人一口气装十几个结果每个都半生不熟反而添乱。选一个最贴合你高频场景的跑通、调优、形成肌肉记忆再考虑加下一个。另外Skill 之间的数据契约比 Skill 本身更重要。这个是我踩了坑才明白的。单个 Skill 再强如果和其他 Skill 对接不上价值就大打折扣。先把契约定好后面加 Skill 就是插拔的事。最后分享一个小技巧给每个 Skill 建一个“使用日志”记录什么场景下用了、效果如何、有什么问题。用一个月回头看你会清楚知道哪些 Skill 真正在创造价值哪些只是占着位置。这个习惯帮我砍掉了好几个“看起来很美”但实际没用的 Skill。