Claude Code+SKILL实战：AI自动生成管理后台全流程复盘

管理后台这东西放在两年前谁能想到有一天 AI 能从头到尾自己给你写出来我当时也是抱着试试看的心态往 Claude Code 里装了一个专门针对后台开发场景的 SKILL结果它真的开始自己干活了扫描项目、建表、写接口、生成页面、接路由、跑通登录一套流程下来基本不需要我逐条指挥。这篇文章就把我的完整过程拆开讲一遍SKILL 到底是什么、管理后台为什么是它最适合发挥的战场、我具体怎么装怎么配、以及实际跑下来踩了哪些坑。无论你是刚听说 Claude Code 的新手还是已经在用但总觉得它不够自觉的老手这篇都值得看完。1. 先搞清楚SKILL 不是提示词是一套工作协议1.1 SKILL 的目录结构一个文件夹就是一个技能包很多人第一次听到 SKILL 的时候第一反应是这不就是长一点的 system prompt 吗我一开始也这么想后来用多了才意识到完全不是一回事。SKILL 本质是一个文件夹里面以一份SKILL.md为核心附带各种可选的模板、脚本、参考文档。也就是说它不只是让模型记住一句话而是让模型在需要的时候把一个完整的方法论文件读进上下文然后照着文件里规定的流程去执行。我装的这套后台 SKILL目录大概长这样admin-dashboard-builder/ ├── SKILL.md ├── templates/ │ ├── backend_crud.js │ ├── frontend_list_page.jsx │ └── login_page.jsx ├── examples/ │ └── demo_schema.sql └── scripts/ └── verify_api.shSKILL.md是主控文件负责告诉模型你是谁、什么时候用你、按什么步骤干活templates/是给模型参考的代码模板保证生成的前后端风格一致examples/放一个完整的数据库示例让模型设计表结构时有参照scripts/是自检脚本写完后跑一遍来验证接口通不通。这套结构和我们团队平时做项目沉淀下来的脚手架 规范文档思路一模一样只是这次消费方从人变成了 AI。1.2 触发机制什么情况下模型会主动调用它SKILL 的触发靠的是description和when_to_use这两个字段。模型在对话过程中会持续判断当前任务是否命中某个 SKILL 的描述一旦命中它就会把对应 SKILL 的内容加载进来进入按章办事的状态。举个实际感受最明显的例子。以前我让 Claude Code 写后台每次都要从头交代我们要做一个用户管理需要列表、新增、编辑、删除列表要分页、搜索新增要表单校验……它确实能写但你每换一个页面就得重新说一遍。装上 SKILL 之后我只需要说了一句按这个 skill 做一个订单管理后台。它自己就知道要先去建订单表、写后端 CRUD、再生成列表页和表单页、最后把路由接起来。这背后最关键的一点是SKILL 不是一个一次性指令它是一份可以反复调用的 SOP。只要任务命中场景模型就会自动按照里面定义的步骤走。用一句不太准确但很好懂的话来说普通提示词是给模型递小抄SKILL 是给模型一本带目录的岗位手册。1.3 为什么说它和普通提示词有本质区别普通提示词的问题是一次性。你今天告诉它先看项目结构再动手它这次听了下次你再让它干活它又忘了。你得像老妈子一样反复叮嘱。SKILL 解决的就是这个记忆力和稳定性问题。另外SKILL 还承载了经验层面的东西。我们团队写后台一直有固定的规矩接口返回统一格式、错误码有规范、新建接口必须加鉴权中间件、列表接口必须支持分页和筛选。这些规矩以前散落在各人的脑子里和 PRD 里现在全部写进 SKILL.md模型只需要照做。我发现它的产出质量直接提升了一个档次因为它的执行不再是临场发挥而是按图施工。2. 为什么偏偏是管理后台2.1 管理后台是所有 CRUD 场景的最大公约数你可能觉得管理后台听起来挺宽泛但它其实是一个非常标准化的东西。拆开来看任何后台都逃不过这几块登录认证、角色权限、列表页带分页搜索、表单页带校验、详情页、操作日志、统计报表。这些东西在不同项目里长得几乎一样差别无非是表字段不同、业务规则不同。这就给 SKILL 提供了最好的土壤。SKILL 本质上是在复用一套方法论而管理后台是软件行业里方法论沉淀得最完整、最统一的场景之一。从数据库设计到接口定义再到页面结构每一步都有成熟范式。模型只要照着范式走产出就不会跑偏。2.2 没有 SKILL 时 AI 写后台的三个翻车点在没装 SKILL 之前我也让 Claude Code 写过后台结论是能写但很累而且容易翻车。三个最典型的问题第一每个页面都要重新交代上下文。写用户列表的时候它会认真写但到了订单列表它又会重新问一遍要不要分页要不要搜索接口返回什么格式效率很低。第二代码风格和项目不一致。它这一题用了 Express 的写法下一题可能就变成 Koa 的写法前一页用函数组件后一页又冒出类组件。维护起来简直想哭。第三横切逻辑经常被漏掉。权限校验、登录态拦截这种每个接口都要过一遍的代码它写着写着就忘了。有一次它生成的接口连鉴权中间件都没挂直接裸奔在公网上。这种问题靠对话式提醒只能救一次救不了每一次。2.3 SKILL 怎么把隐形套路变成硬性流程装上 SKILL 之后上述问题被从机制上解决而不是靠运气。因为 SKILL.md 里写死了规则除 login 外的所有接口必须先通过 auth 中间件没有当前用户信息直接返回 401所有列表接口必须支持 page、pageSize、keyword 参数所有接口响应统一为 { code, msg, data } 格式。模型在执行时不是记得就遵守而是不遵守就完不成流程因为 SKILL 自带自检清单跑完代码后它自己要检查一遍。这一步的差别有点像让实习生自由发挥和让实习生照着《开发规范手册》逐条打勾的区别。前者靠悟性后者靠流程而流程天然具备稳定性。3. 实操复盘我装的这个 SKILL 到底做了什么3.1 安装的两种常见姿势先说安装。我试过两种方式效果都行看你的使用习惯。第一种是用 Claude Code 的插件机制在会话里执行/plugin把本地 SKILL 目录作为插件路径加进去。这个方式的好处是会话内就能看到加载状态适合调试验证。第二种更轻量也是我目前一直在用的直接把 SKILL 目录扔进项目根目录下的.claude/skills/文件夹然后在CLAUDE.md里写一行引用说明。这样每次会话开始时模型就知道项目里有哪些 SKILL 可用你不需要每句话都提起它。需要提醒的是不同版本的 Claude Code 对 SKILL 的加载方式可能有细微差别但核心逻辑不变让模型在开始干活之前就能把 SKILL.md 的内容读到上下文里。如果不确定就先用/plugin方式验证一次确认能加载后再固化到项目里。3.2 SKILL.md 外层字段怎么写如果自己从头写一版SKILL.md开头有一段 YAML 格式的元信息这部分是灵魂。我总结了自己调出来的版本--- name: admin-dashboard-builder description: 生成标准企业级管理后台适用于用户管理、订单管理、内容管理等 CRUD 型业务后台 when_to_use: 当用户要求搭建管理后台、Admin 面板、运营后台或者要求对某一类资源实现增删改查页面时 ---这里有两个我踩过坑的经验。第一description一定要把场景别名写全。因为我发现模型的触发判断依赖自然语言理解如果你只写生成管理后台它遇到帮我搞个运营系统我要一个订单管理界面这种说法时就可能不触发。把各种叫法都写进描述里触发成功率会明显提升。第二when_to_use要写触发条件而不是功能简介。它本质上是在告诉模型你什么时候该翻出这套流程写得越具体模型越容易在正确的时机加载它。我一开始就把这部分写成用于创建管理后台结果它经常在只需要写一个单独接口的时候也把整套流程加载进来反而拖慢速度。3.3 核心正文把写后台拆成可执行的步骤SKILL.md 的正文部分是我花最多时间打磨的地方。我按照团队做后台的真实顺序把它拆成了七个阶段需求分析、数据建模、后端接口、前端页面、权限处理、自检、交付。每个阶段不是简单一句话而是带着明确产出物和验收标准。比如数据建模阶段我要求它先列出所有实体和字段清单标注类型、约束、索引并经用户确认后才允许写建表语句后端接口阶段我要求它必须按统一格式返回且每个接口旁标注对应前端页面自检阶段我要求它必须实际启动服务用 curl 调用一遍所有接口而不是只在脑内模拟。这套拆解思路其实是把人类的开发流程翻译给 AI。我们自己在写后台的时候也是先想清楚表结构再动手凭什么要求 AI 一上来就生成代码SKILL 的作用就是强制它按这个先后顺序来。3.4 Claude Code 的自主执行过程实录装好之后我做的第一件事是开了一个全新的空目录然后给了一个很模糊的需求做一个后台能管理用户和订单。接下来我就看着它的执行记录一条条冒出来。它先是翻了一遍当前目录发现什么都没有于是读 SKILL.md然后自动进入第一阶段列需求拆解。它在工作区里写了一页requirements.md把用户管理、订单管理、数据统计这些模块列得清清楚楚还附带一个字段清单。那一刻我确实有点惊讶因为没有任何人告诉它先写需求文档。接下来它开始建表。它根据字段清单生成了一份schema.sql包括 users、orders、order_items 三张表外键、索引、时间戳都补齐了。然后进入后端阶段用 Express 生成了路由文件、控制器、数据库连接模块每个接口都套上了 auth 中间件。前端阶段它又按模板生成了登录页、布局框架、用户列表页、订单列表页和表单组件。最后它自己装了依赖、启动了服务、跑了自检脚本把一个接口不通的问题修掉之后给我输出了一篇简短的交付说明。整个过程大概一个多小时我只在数据模型的字段确认这一处被打断过一次其他时间完全插不上手。4. 从零到一复现一套可用的管理后台4.1 环境准备与项目初始化如果你想照着复现一遍我建议你按我这次的步骤来。第一步肯定是要有 Claude Code最常见的是用 npm 全局安装装完在终端敲claude就能进入会话界面。这个没啥好说的装不上基本就是网络或环境问题按官方文档排查就行。第二步初始化一个空项目目录并且先把 git 仓库建立起来。这一步强烈建议不要省因为 AI 自主写代码的过程中会频繁产生文件变更有 git 你才能随时git diff查看它改了什么、git revert回滚错误操作。我在实际操作时每完成一个阶段就git commit一次这样即使后面写崩了也能精准回退到上一个阶段。第三步把 SKILL 目录放到.claude/skills/下并在CLAUDE.md里加一句项目包含管理后台开发 SKILL涉及后台需求时优先参考 admin-dashboard-builder。然后启动 Claude Code 会话先简单问它一句你能用的 SKILL 有哪些确认它能答出名字说明加载成功。4.2 用一句需求触发完整任务环境就绪后关键来了——怎么开口。我这次用的原始指令是做一个运营后台包含用户管理和订单管理。用户管理需要支持列表、新增、编辑、禁用订单管理需要支持列表、查看详情、修改状态。技术栈用 Node.js Express SQLite React。按 admin-dashboard-builder 这个 SKILL 的流程来做。注意几个细节。第一我明确说了按这个 SKILL 的流程来做这是给模型一个强提示确保它加载 SKILL 而不是自由发挥。第二我给出了具体技术栈因为 SKILL 虽然可以自适应技术栈但给一个明确选型能减少它反复试探的时间。第三我把功能边界划清楚了它就不会自作主张加一堆你用不上的模块。4.3 我在旁边盯着它实际干了什么触发之后我全程盯着它的执行路径记录一下给各位参考。第一阶段它生成了requirements.md里面包含角色定义管理员、运营、用户管理功能清单、订单管理功能清单以及两个模块的表字段设计。这个文档我 review 了一遍基本和我脑子里想的方案一致只改了一个字段类型就放行了。第二阶段它建表并生成了后端代码。SQLite 的表结构在schema.sql里后端路由全部挂在/api前缀下分了 auth、users、orders 三组。登录接口用的 JWT用户接口做了角色校验订单状态修改接口只允许管理员调用。这些都是 SKILL 里写死的约束它算是执行到位了。第三阶段是前端。它用 React 生成了登录页、布局框架、用户管理页和订单管理页列表页都带了分页和搜索框表单页带了基本校验。页面风格走的极简风能用但不算好看毕竟 SKILL 里没有审美要求所以你对样式有期待的话最好在 SKILL 里预先定义 UI 规范或组件库。最后是自检。它自己启动了开发服务器用 curl 依次打了一遍登录、获取用户列表、新增用户、修改订单状态等接口其中发现新增用户时密码字段没有加密又回去补了一个 hash 处理然后重新跑了自检。这部分是我最感动的地方因为它真的把运行验证当成了流程的一环而不是生成完代码就交差。4.4 验收清单与人工介入点即使 AI 干了这么多活验收这步我也没省。我自己写了一份检查清单照着过了一遍登录流程是否闭环错误密码是否有提示未登录访问接口是否返回 401非管理员能否访问仅限管理员的接口用户新增、编辑、禁用后列表是否实时刷新订单状态修改是否写入了操作日志分页和搜索是否真正生效结果发现一个问题订单列表的搜索只搜了订单号没有搜用户昵称。这个逻辑上的小疏漏靠 AI自觉是很难避免的因为需求描述里没写。我直接在会话里补了一句订单列表的搜索框要能同时按订单号和用户昵称搜索。它马上改了相关代码并把搜索逻辑的数据流又捋了一遍。这也引出了我认为最重要的使用心态SKILL 能帮你把 80% 的机械劳动扛下来但它不是产品经理不会有意识地替你把边界条件想全。你需要做的就是守住一个角色——验收者和补需求的人。5. 翻车记录这些坑我真的踩过5.1 问题排查速查表没有哪套方案是不踩坑的我把实际遇到的问题整理成一张速查表方便你直接对照。现象可能原因处理方式需求说了一堆模型没触发 SKILLdescription 或 when_to_use 没覆盖你这次的说法在指令里点名按 xx SKILL 执行或补全 SKILL 的场景别名过一会儿就忘了项目规范SKILL.md 太短约束不够强制用必须 / 禁止 / 如果…则…这类强约束句式并加自检清单生成了大量文件但没运行验证SKILL 里没写必须实际运行才算完成在流程里加入启动服务和 curl 自检环节并明确不通过不交付改到一半方向跑偏开始写无关功能需求边界没有在 SKILL 流程里写死在需求分析阶段强制列功能清单并经用户确认后再动手反复生成同一个文件上下文里没有说明文件已存在流程开头加先扫描现有目录避免重复创建打包安装了一个不存在的依赖版本模型凭空生成版本号在 SKILL 里规定安装依赖前先用包管理器查询可用版本5.2 三个容易被忽略的隐性坑除了表格里那些还有三个更隐蔽的坑我想单独拿出来说。第一个坑叫上下文撑爆。SKILL 的模板如果太多模型每次加载都要读进去会把上下文窗口占掉一大截导致后续生成代码时可用空间变小。我一开始把十几个页面模板全塞进去结果模型写到一半就断片了。后来我把模板精简到三个典型页面列表页、表单页、登录页剩下的让它按这三个的风格推导生成。效果反而更好。第二个坑叫过程没有检查点。AI 生成代码是连续动作如果你不在关键节点打断它它可能会一口气写出很多错误代码然后在一个错误的基础上继续堆。我的办法是在 SKILL 流程里强制规定生成完数据模型必须停下来等用户确认生成完后端接口必须提交一次 commit生成完前端必须跑一次构建。这几个检查点让整个执行过程从一锤子买卖变成了分段交付出错后回退成本大大降低。第三个坑是权限验证看着有实际裸奔。有些情况下模型会生成一个 auth 中间件但只在注册路由时挂在部分接口上或者中间件里只做了 token 解析却忘记校验当前用户是否存在。我在 SKILL 里加了一条硬规则所有非登录接口必须统一经过 auth 守卫且守卫内部必须查询数据库确认用户状态。加了这条之后我再也没看到无鉴权接口出现在 diff 里。6. 自己动手写 SKILL 的模板与心得6.1 一个好的 SKILL 长什么样用了别人写的 SKILL 之后我开始自己动手改造慢慢总结出好 SKILL 的三个标准。判断标准很简单让人或者让另一个 AI看完之后能不加思考地照着干完一整件事。第一个标准是触发条件清晰。它在什么时候被调用、什么时候不该被调用必须一眼能看懂。精确到用户要求做管理后台时比处理后台需求时好用得多。第二个标准是流程可拆分。一件复杂任务必须拆成三个阶段以上每个阶段都有明确产出物。我看到很多写着生成管理后台然后就结束的 SKILL这种跟一条大号提示词没有任何区别因为模型看完还是不知道该先干嘛。第三个标准是有验收标准。每个阶段结束要检查什么、整体完成要跑什么测试必须白纸黑字写清楚。验收机制是 SKILL 和提示词拉开差距的关键也是保证 AI 输出质量稳定性的护城河。6.2 最小可用模板如果你要自己写第一个 SKILL我建议直接套这个最小模板先跑通再慢慢丰富--- name: your-skill-name description: 一句话说清技能边界 when_to_use: 什么场景下启动 --- ## 1. 执行目标 用两三句话说明完成这项任务后的最终状态。 ## 2. 执行流程 1. 第一步产出什么怎么验证 2. 第二步产出什么怎么验证 3. 第三步产出什么怎么验证 ## 3. 强制约束 - 必须遵守的规则列表用必须禁止开头 ## 4. 自检清单 - [ ] 检查项 A - [ ] 检查项 B - [ ] 检查项 C这套模板的好处是通用不管是做后台、写数据报表、还是批量处理文档都可以套。我先拿后台场景跑通了后来又照着写了一个数据报表生成器 SKILL效果同样稳定。6.3 SKILL 的边界别什么场景都硬上说句大实话不是所有场景都适合用 SKILL。我尝试过把它用在开放式创意写作上效果很差。原因是 SKILL 的核心机制是确定性约束而创意写作需要的是开放式发散约束越多产出就越中规中矩。这类场景倒不如直接和模型闲聊来得自然。另外如果任务涉及的领域是模型基本没训练过的全新知识SKILL 也帮不上忙。因为 SKILL 再怎么写流程模型肚子里没料硬套流程也产不出干货。这时候该做的是先给模型补充参考资料而不是指望一个 SKILL 力挽狂澜。我个人现在的判断标准是只要这个任务在团队里已经形成了稳定方法论、并且一个月内至少要做三次以上就值得为它写一个 SKILL。一次性的任务不值得花时间去搭流程高频重复的任务才值得。经历过这次自己写管理后台事件之后我最大的体会是SKILL 的本质是把你自己脑子里那套已经跑通的项目方法论翻译成 AI 能照章办事的流程说明书。我现在每次给 Claude Code 布置复杂任务之前都会先问自己一个问题——如果现在坐在我面前的是个刚入职的实习生我会怎么带他我会先让他看什么文档、按什么顺序干活、做完怎么自检把这些话写进 SKILL.mdAI 干活的稳定性和质量就都稳住了。这套打法的想象空间很大后台只是我试水的第一站。