过去两周我干了一件让自己挺意外的事我给 Claude Code 装了一个自定义 SKILL然后它就开始自己写管理后台了。不是那种玩具级别的 demo而是能直接跑起来的用户管理、角色权限、订单 CRUD 模块前端页面和后端接口一起生成我只需要做最后的检查和微调。这事放在一个月前我是不太信的但实测下来效率提升确实非常明显。如果你也在用 Claude Code 写业务系统或者你被无穷无尽的管理后台需求折磨过这篇内容应该能给你一些真正能上手的启发。先说结论Claude Code 的 Agent Skills 本质上就是“把老手的操作手册打包成文件让 AI 按手册干活”。我只不过把管理后台开发的规范、模板、命名习惯、常见坑全部沉淀成了一个 SKILL 目录让 Claude 每次遇到相关需求时自动加载然后按流程执行。听起来简单但把它跑通之后我才意识到这种方式对 AI 编程的影响有多大。1. 为什么拿管理后台当 SKILL 的试验田再合适不过1.1 管理后台这类需求的高度重复性管理后台大概是业务开发里最“无聊”又最“磨人”的场景了。你仔细想几乎每个管理后台都逃不开那几样东西登录鉴权、用户管理、角色权限、菜单配置、数据统计看板然后就是一堆围绕业务表的增删改查。页面结构高度相似无非是左侧菜单、顶部面包屑、中间内容区放表格表格上面放搜索条件右侧是新增编辑按钮弹出表单做校验提交后刷新列表。我做了这么多年项目管理后台换过的技术栈都数不清了从早期的 jQuery EasyUI 到 Vue 2 Element UI再到现在的 Vue 3 Element Plus、React Ant Design。表面上看起来项目差别很大实际上内部的套路几乎是固定的。每个模块都像同一个模具压出来的数据库表结构不同字段不同但 Controller、Service、DAO 的写法前端列表页的表格列定义表单页的校验规则全都是一样的骨架。这种高度重复的特性让管理后台成了最适合做自动化的场景。它不是不需要技术含量而是它的技术含量已经被行业反复沉淀成一套很成熟的模式普通工程师看一眼需求就能知道要建哪些表、写哪些接口、页面长什么样。那既然人脑可以总结规律为什么不让 AI 也掌握这套规律1.2 不用 SKILL 时Claude Code 写出来的东西有多飘在没有 SKILL 之前我也尝试过让 Claude Code 直接写管理后台模块。它的代码能力确实很强但问题也很突出你每次都要花很长的 prompt 描述需求而且它每次的行为都不太一样。这次它给你生成一个带搜索条件的列表页下次同样的需求它可能连分页都没做。遇到复杂一点的需求比如“根据订单状态字段控制操作按钮的显示”它经常要跟我反复确认好几轮测试环境稍微跑出个报错它又开始在无关文件里乱翻。我印象很深的一次我让它实现一个简单的“公告管理”模块。它在项目里四处翻找之后把用户模块的代码复制了一份改了改类名就算完事。字段倒是都对应上了但公告需要的“置顶状态”“发布定时”逻辑完全没有列表页还保留着用户头像的展示列。这种结果你说它不能用吧它确实是照着现有代码风格写的你说能用吧我后续改的时间比自己重新写还长。后来我意识到问题的根子在于Claude Code 每次都是“重新理解一遍世界”。它知道 Vue、知道 FastAPI但它不知道我项目里的最佳实践是什么不知道我这个团队的代码风格是什么样的。我需要一种机制把这些经验性的东西固化成文件让它每次遇到管理后台需求时自动加载。“经验固化”这件事恰好就是 SKILL 的核心能力。2. SKILL 机制拆解它到底是怎么让 Claude 变听话的2.1 SKILL 的文件结构和触发原理Claude Code 的 SKILL 本质上就是一个目录目录里通常包含一个 SKILL.md 文件以及一些可选的脚本、模板和参考资料。当你把它放在指定的 skills 目录下时Claude Code 会在合适的时机自动识别并加载它。它的工作方式很像 Unix 的 man page不会在对话一开始就全部读进上下文而是在需要的时候才被调出来减少对上下文窗口的占用。你会发现这个设计很聪明。如果把一份 20 页的开发规范直接塞进 system prompt普通任务也会被这些内容干扰模型的理解会被带偏。SKILL 则是按需加载只有当用户需求与它描述的场景匹配时才会把完整内容注入。这样既保证了专业场景下的指导充分又不影响日常开发对话的效率。一个典型的 SKILL 目录长这样.claude/skills/my-skill/ ├── SKILL.md ├── scripts/ │ └── generate.sh └── assets/ ├── template.html └── reference.md其中 SKILL.md 是最核心的入口文件它需要在开头用 YAML frontmatter 声明一些元信息name 是技能名称description 描述这个技能的适用场景Claude 靠它来判断要不要加载allowed-tools 可以限制这个技能运行时允许调用哪些工具增强安全性。正文部分则是具体的操作指引可以写得很详细告诉 Claude 在什么情况下怎么做。2.2 SKILL 和其他“暗示”方式有什么本质区别很多人会问SKILL 跟把要求写在 CLAUDE.md 里有什么区别跟普通的 prompt 模板又有什么区别先说 CLAUDE.md。这个文件里通常放的是项目全局约定比如“项目使用 pnpm”“后端代码放在 backend 目录”它会在每次对话时被加载。但管理后台的完整开发规范至少几千字不适合全部放进 CLAUDE.md否则模型处理简单任务时也会背着沉重的包袱。SKILL 则相反它平时不占空间遇到对应场景才触发适合存放“某类任务的操作手册”。再说 prompt 模板。我在用 SKILL 之前也积累过一些 prompt每次要点开复制粘贴还经常因为上下文不同需要临时修改。prompt 只存在于对话里是一次性的SKILL 则可以被反复引用、组合和继承。它不仅有说明还可以带脚本、带模板文件权限控制也更细。更重要的是SKILL 可以被团队共享提交到 Git 仓库里所有人都能复用而 prompt 往往就是个人手里的一堆文档碎片。从模型的角度理解SKILL 给 Claude 提供的是一套“任务启动方案”任务类别被识别出来后模型会先读取 SKILL 正文知道该按什么步骤做参考哪些模板遇到边界情况怎么兜底。它不再是临场发挥而是戴着“操作规范”上工输出稳定性自然上了一个台阶。3. 自己写一个“管理后台生成” SKILL实操全过程3.1 设计思路把老手的判断固化成标准动作我这个 SKILL 的目标很明确让我只需要用一句话描述业务需求Claude Code 就能完成从需求分析到生成前后端代码的全过程。为了达到这个目标我首先把管理后台开发的流程拆成了四个标准动作理解需求、设计数据模型、生成后端接口、生成前端页面。每个动作下面都沉淀了我多年的习惯。比如理解需求时先识别实体对象比如“订单”“用户”“商品”然后识别实体之间的关联关系比如订单属于用户、订单包含商品再识别关键状态字段比如订单状态、支付状态。数据模型设计时约定主键统一用 id创建时间用 created_at更新时间用 updated_at逻辑删除用 deleted_at所有字段用下划线命名返回给前端时转为驼峰。后端接口命名遵循 RESTful 风格按资源路径组织。前端页面方面列表页统一包含搜索区、表格区、分页区表单页统一做校验提示。这些规则在我脑子里是根深蒂固的但 Claude Code 不知道。我不可能每次都在 prompt 里把这套东西讲一遍所以我把它完整写进了 SKILL.md。下面是 SKILL.md 的核心骨架我给读者的参考版本实际项目里可以按你自己的习惯改--- name: admin-panel-generator description: 生成管理后台模块时使用。当用户需要新增或维护后台管理页面、CRUD接口、数据模型时自动加载本技能。 allowed-tools: Bash, Read, Write, Edit, Glob --- # 管理后台生成规范 ## 1. 需求理解阶段 - 识别用户描述中的核心实体例如用户、角色、订单、商品。 - 列出实体字段判断字段类型字符串、整数、浮点、日期、枚举、JSON。 - 标记实体间的关联关系一对一、一对多、多对多。 ## 2. 数据模型设计 - 默认包含 id、created_at、updated_at、deleted_at 四个基础字段。 - 表名使用业务名词复数形式小写加下划线。 - JSON 字段必须给出明确结构说明。 - 枚举字段在数据库中存字符串使用全大写加下划线。 ## 3. 后端接口生成 - 使用项目现有框架风格不要新造不存在的工具类。 - 接口路径统一为 /api/v1/{resource}。 - 列表接口必须支持分页参数 page 和 page_size。 - 所有写操作返回创建或更新后的完整对象。 - 权限校验按项目现有装饰器实现不要绕过。 ## 4. 前端页面生成 - 列表页结构搜索区 操作按钮区 表格区 分页器。 - 表格列优先展示主键、名称、状态、创建时间、操作。 - 表单必须包含必填校验提交成功后刷新列表并关闭弹窗。 - 不要生成多余的 mock 数据页面必须对接真实接口。这段内容我是经过几轮迭代之后才定下来的。第一版我写了特别长的细则结果 Claude 在生成代码时过于死板遇到一点超出规则的情况就不知所措。后来我调整了写法规则给到关键约束但不限制死实现方式给模型留出根据实际项目判断的空间。事实证明这个平衡很重要。3.2 用模板文件兜住 80% 的重复代码光靠 SKILL.md 的文字描述还不够因为如果每一个字段的模板代码都要模型现写它仍然可能写得五花八门。我的做法是把常用的 model、router、vue 列表页、vue 表单页都抽成模板文件放进 SKILL 的 assets 目录让 Claude 按模板去套。拿后端来说我的 FastAPI 项目模板长这样# assets/model_template.py from sqlalchemy import Column, Integer, String, DateTime, JSON from database import Base class {{ModelName}}(Base): __tablename__ {{table_name}} id Column(Integer, primary_keyTrue, indexTrue) {{fields}} created_at Column(DateTime, server_defaultfunc.now()) updated_at Column(DateTime, server_defaultfunc.now(), onupdatefunc.now())前端列表页模板我用的是 Element Plus 风格!-- assets/list_template.vue -- template div classpage-container el-form inline el-form-item label关键词 el-input v-modelquery.keyword placeholder请输入关键词 / /el-form-item el-button typeprimary clickfetchList查询/el-button /el-form el-table :datalist v-loadingloading el-table-column propid labelID / el-table-column propcreated_at label创建时间 / el-table-column label操作 template #default{ row } el-button link typeprimary clickopenEdit(row)编辑/el-button /template /el-table-column /el-table el-pagination v-model:current-pagequery.page v-model:page-sizequery.page_size changefetchList / /div /template模板不追求代码量巨大而是追求“结构正确”。模型拿到的是一副已经画好骨架的画它只需要往里填细节产出的质量自然稳定很多。我还写了一个 scripts/scaffold.sh负责在生成模块时创建目录、初始化路由文件、自动把新路由注册到主应用。这样 Claude 就不需要在项目里翻来翻去找路由注册位置了一个脚本调用就完成了结构搭建。3.3 安装到指定目录并验证生效SKILL 的安装位置有两个选择。一个是用户级目录放在~/.claude/skills/下适用于全局通用的技能比如“生成管理后台”这种几乎每个项目都能用的另一个是项目级目录放在项目根目录的.claude/skills/下适用于绑定特定项目的技能比如“本项目的代码规范检查”。管理后台生成我放在用户级因为我几乎每个项目都要用到。安装完之后可以打开 Claude Code 的交互界面输入/skills查看当前已经注册的技能列表。如果能看到自己刚写的 SKILL 名称说明解析成功。也可以用一句明显的测试 prompt 触发它比如“帮我写一个用户模块的管理后台”然后观察 Claude 的回复如果它开始按照你写的规范拆解需求、引用模板那就说明加载成功。4. 实测Claude Code 如何一步步自己写出管理后台4.1 真实项目中的一次完整流程我拿一个内部工具项目做了测试。需求就一句话“我需要一个订单管理模块订单表字段包括订单号、用户ID、商品名称、商品数量、订单总金额、订单状态、收货人手机号、收货地址、创建时间状态有待付款、已付款、已发货、已完成、已取消要支持按状态和订单号搜索。”如果放在以前这个需求我自己写大概需要半天到一天包含建表、后端接口、前端页面、联调。换成装了 SKILL 的 Claude Code 之后我只需要把这句话发出去然后观察它的动作。Claude Code 的第一步是先读取了 SKILL.md我通过日志能看到它加载了 admin-panel-generator。接着它调用 Glob 工具扫描了当前项目结构确认了前端目录、后端目录、数据库连接文件的路径。然后它在本地创建了一个临时分析文件列出了订单实体的字段清单区分了字符串字段、数字字段和枚举字段并标记了“收货地址”这种 JSON 字段和“订单状态”这种枚举字段。之后它开始按照 SKILL 里的指引操作先根据模板生成模型文件写入backend/app/models/order.py再生成 CRUD 路由文件backend/app/routers/order.py然后跑 scaffold 脚本自动注册路由。前端部分它参考列表模板渲染了搜索区、表格、分页器并且生成了订单状态对应的 tag 颜色映射最后创建了frontend/src/views/order/index.vue和frontend/src/views/order/form.vue。整个过程持续了不到十分钟。我后来检查代码的时候发现几个值得表扬的细节它没有忽略“支持按状态和订单号搜索”这个需求列表页搜索区确实放了状态下拉框和订单号输入框后端列表接口真的实现了这两个查询参数创建订单时会把商品数量、金额字段做非空校验。这些点要是让普通 LLM 直接生成大概率会漏。4.2 它生成的代码长什么样我贴关键片段后端接口的核心逻辑比我想象的干净。这里是从生成结果里节选的查询部分def list_orders(db: Session, page: int, page_size: int, status: str None, order_no: str None): query db.query(Order) if status: query query.filter(Order.status status) if order_no: query query.filter(Order.order_no.like(f%{order_no}%)) total query.count() items query.offset((page - 1) * page_size).limit(page_size).all() return {total: total, items: [item.to_dict() for item in items]}前端页面的生成也不错。状态列用了 tag 展示不同状态有不同颜色而且它主动给“已取消”配了灰色给“已发货”配了蓝色这些视觉习惯我可没写在 SKILL 里应该是借鉴了 Element Plus 的常见用法效果还挺自然。4.3 同需求对比没装 SKILL 时它有哪些毛病为了做对比我在另一个没装 SKILL 的会话里也提了同样的需求。结果差异非常明显Claude 虽然也生成了模型和页面但它没有先分析字段而是随手给订单表加了一个非业务要求的remark字段前端列表页没有搜索区分页逻辑也是写了但没接到接口上后端路由没有做状态筛选我问它为什么没做它表示“可以后续继续优化”。这个对比实验让我确认了一点Claude Code 在标准任务上的能力下限已经足够高但上限完全取决于有没有提供领域知识。SKILL 把我多年的项目经验预先注入给了模型相当于给模型戴上了一个“企业导师”的帽子它在动手之前先想清楚流程生成的代码从结构到细节都更贴近高水平开发者的习惯。4.4 跑通之后我做的第一次调优第一次跑通后我其实还发现了一个问题Claude Code 抄模板抄得太死比如模板里的query.keyword会原样生成到订单列表但“关键词”这个字段名在图里还需要改成“订单号”。也就是说它虽然套用了模板但没有严格按照业务字段修正变量名。我在 SKILL.md 里补了一条规则“模板中的示例字段必须替换为当前实体实际字段禁止保留示例命名尤其是搜索条件、表格列、表单 model 里的变量名。”再次测试时它就没有再犯这个错误。这类经验很多都是迭代出来的所以你第一版 SKILL 不完美非常正常边用边补才是正确姿势。5. 常见问题与排查技巧实录5.1 SKILL 不生效可能是这个原因新手最容易踩的坑就是 SKILL 描述没写好。Claude Code 是根据 SKILL.md 里 frontmatter 的 description 来决定是否加载技能的。如果你的描述写得太窄比如只写了“订单管理”那么用户提“新增一个商品模块”时它就不会加载这个技能。描述应该用概括性语言把整个类别的场景都覆盖到比如“生成管理后台模块时使用当用户需要新增或维护后台管理页面、CRUD 接口、数据模型时自动加载”。另一个很常见的原因是 YAML frontmatter 格式错误。有一次我把 name 写成了带空格的名字结果 Claude 控制台直接报错这个技能在列表里死活不显示。解决方案是在本地严格检查 YAML 格式name 使用小写字母和连字符description 写成一个完整通顺的句子。可以用/skills命令及时验证。5.2 技能内容太长反而拖慢任务速度我刚开始把 SKILL.md 写得像文档中心各种边界情况、异常处理写了好几万字结果反而导致 Claude 在加载技能时消耗了大量上下文正常的代码生成也变得卡顿还容易抓不住重点。后来我把 SKILL.md 精简成操作流程和关键约束把“某类字段常见的处理方式”“某框架的完整参考代码”这类比较重的信息拆分到了 assets 目录下的独立文件里然后在 SKILL.md 中要求 Claude 在遇到特定情况时“先读取 assets/xxx.md 再继续”。这样既保证了信息的完整供给又不让主流程被沉重的内容拖垮。这个思路我非常推荐SKILL.md 走“轻目录”路线只放决策逻辑细节知识全部外置按需引用。就好比一个经验丰富的师傅指点徒弟不会一口气把所有事情讲完而是遇到什么问题再翻出对应的手册。5.3 怎么防止 Claude 在生成过程中“跑偏”所谓跑偏就是它开始不按照你给的流程来而是自己在项目里翻找、修改无关文件或者陷入某个死循环里反复尝试同一个错误的操作。我在 SKILL.md 里特别加了两条约束第一如果已有文件存在先读取该文件内容在现有代码基础上做增量修改不要整体覆盖第二如果尝试某一步操作连续失败两次停止操作向用户报错说明情况并给出可选项。我还给 allowed-tools 做了限制例如在生成前端页面时不允许使用删除文件的 Bash 命令避免它误操作删除重要代码。权限控制这块虽然看起来不起眼但在自动化执行场景里真的能救命。有一次我测试一个实验性技能时差点让 Claude 把整个 dist 目录清理掉因为它在执行构建命令时自动附加了一个多余的清理参数。从那以后所有技能我都要求明确列出可用工具不给模型即兴发挥的空间。5.4 一套我实测好用的排查路径如果你遇到 SKILL 相关的问题可以按这个顺序排查第一启动 Claude Code 后输入/skills确认技能是否注册第二在日志窗口观察模型是否有读取 SKILL.md 的记录第三检查描述文件内容是否与触发语句匹配必要时把触关键词写得更宽泛第四检查技能目录的权限和被引用文件是否都存在第五如果还是不行把 SKILL.md 内容大幅精简后再次测试排除上下文过载的问题。这套路径我用了好几轮几乎能解决九成以上“技能没生效”的疑惑。剩下的一成往往跟 Claude Code 版本更新有关升级后再看一下官方文档里的兼容性说明基本就能搞定。6. 这套玩法还能延展到什么方向6.1 把团队规范沉淀成可以共享的 SKILL我目前最看好的延展方向是把团队的代码评审规范变成 SKILL。比如我们团队的前端代码要求“组件内 props 统一用 const 声明禁止直接修改 props”“状态管理只在页面层引入组件层不直接依赖 store”。这些约定写在文档里大家不看但变成 SKILL 之后Claude Code 在每次生成代码时都会按规范执行相当于把纪律装进了开发流程里。同样的思路也可以用于数据库 SQL 规范、安全编码规范、测试用例编写规范。你可以做一个 code-reviewer 技能让 Claude 在生成完模块后自动对照规范投一遍发现不合规的地方自动修改。团队新人来了以后只要配置好同样的 SKILL 环境产出的代码质量就不会跟老成员差太多。6.2 多个 SKILL 组合使用当你积累了多个 SKILL 之后真正有意思的事情就开始发生了。我现在的项目里有三个 SKILL 配合使用第一个负责处理需求描述把模糊的业务需求转换成结构化的字段清单和接口定义第二个就是我这次讲的 admin-panel-generator负责生成管理后台代码第三个是 code-reviewer负责在生成结束后按规范自查。这三个技能可以串成流水线需求描述进来先被转化为规格说明然后管理后台生成器拿着规格说明去产出代码最后 code-reviewer 检查一遍收尾。Claude Code 允许技能之间互相引用在一个技能的处理过程中按需加载另一个技能这种组合编排产生的威力远超过单个技能。我甚至想过把“写周报”也做成 SKILL让 Claude 根据我这周的 commit 记录和 issue 描述自动生成工作周报省去每周五下午的纠结时光。类似的思路大家完全可以举一反三。6.3 我的个人体会做这个 SKILL 的过程让我对 AI 编程有了新的理解。以前总觉得 AI 编程就是输入 prompt、拿结果后来才明白真正的分水岭是你能不能把自己的经验系统化地喂给 AI。写 SKILL 看似是在写文档本质上是在梳理自己的知识结构把自己脑子里的“隐形经验”翻译成 AI 能执行的指令和模板。我个人的建议是不要一上来就想做一个通用的万能 SKILL那注定失败而是找一个你被重复咨询最多的任务先把最痛的那个场景做成 SKILL用起来再迭代。我拿管理后台开刀就是因为它足够的“普通”恰恰是这种普通的需求反而最能体现标准化的价值。等到你的 SKILL 库越来越丰富你会发现自己写代码的时间少了思考架构和业务的时间多了这可能就是 AI 编程时代最有意义的转变。