我把"重复搭框架"这件事彻底干掉了：前端后端脚手架 Skill 封装实录

目录

1. 缘起：熟练的重复，才是最贵的重复
2. 什么时候适合把"经验"封装成 Skill
3. 脚手架 Skill 的设计思路：三个输入 + 一套模板
4. 我用结构：规则文件怎么组织
5. 第一次封装踩的坑：太贪心
6. 迭代：从"能用"到"好用的三个版本"
7. 实际收益：一次项目启动的真实对比
8. 结尾：把你重复三次的事，变成一件可以复制的事

1. 缘起：熟练的重复，才是最贵的重复

我每年要开好几个前后端项目。坦白说，框架那部分我闭着眼都能写：前端 Vite + React 那套目录、axios 封装、路由守卫、状态管理、ESLint/Prettier 配齐；后端 Spring Boot 的启动类、统一返回、全局异常、JWT 拦截、MyBatis/MyBatis-Plus 配置……每一步都"很会"，但没有一步是"有新意"的。

按一个项目搭 3-5 小时算（还不算踩版本兼容的坑），一年光"搭架子"就烧掉十几个小时。而且更烦的是：每一个项目搭完，我都要想一想"上次我是怎么配的来着"。

我需要的是把"我的标准搭配"固化下来，随取随用。在 AI 出现之前，这只能靠"复制上一个项目改改用"——然后被上一个项目的历史包袱污染。现在有了 Skill，这件事有了更干净的解法。

2. 什么时候适合把"经验"封装成 Skill

先给结论：不是所有事都值得封装 Skill，我给自己订了三条标准。

1. 重复率够高：这件事每年要做 3 次以上，且每次操作步骤基本一致；
2. 结果可预期：产出的结构是"模板化"的，有清晰的标准答案；
3. 差异可参数化：不同项目之间的不同，能用几个参数说清（项目名、技术栈、端口…）。

"搭前后端脚手架"三条全中。而像"设计某个特定页面"这种每次都不一样的事，就没必要封装——封装了反而会限制 AI 的创造力。

一句话：Skill 是固化"你反复做的、有标准答案的事"，不是固化"你偶尔做、每次都需要发挥的事"。

3. 脚手架 Skill 的设计思路：三个输入 + 一套模板

封装之前，我先想明白了 Skill 的"输入输出"是什么。把它看成一个小函数：

输入：项目名、技术栈选项（如 Vite+React / Vue3+TS）、后端选型（如 Spring Boot 3）
处理：按预置规则生成目录结构、配置文件、基础封装代码
输出：一个开箱即用的前后端项目骨架 + 运行说明

模板部分我沉淀的"标配"清单是这样：

核心设计原则：Skill 里装的不是"一切可能的东西"，而是"我的标配"。 公共的沉淀，个性的留白给后续编码注入。

4. 我的结构：规则文件怎么组织

Skill 的本质是"给 AI 的一组结构化指令"。我把它组织成几个清晰的块：

skill:
  name: web-fullstack-scaffold
  description: 一键生成前后端项目基础脚手架，包含目录结构、配置与常用封装

steps:
  - step: 01-init
    action: 先询问项目名与技术栈偏好，输出确认清单
  - step: 02-frontend
    action: 按模板生成前端骨架，执行依赖安装并验证构建通过
  - step: 03-backend
    action: 按模板生成后端骨架，完成配置项占位
  - step: 04-verify
    action: 两端分别启动并验证"欢迎页可访问"，输出结果报告

templates:
  frontend: path/to/frontend-template
  backend: path/to/backend-template

我在结构上最满意的设计是 "生成 → 安装 → 跑通验证"三步闭环。Skill 不是"给你一堆文件就完事"，而是负责到"验证通过"为止（依赖能装、前端能 build、后端能启动）。这一步让脚手架的产出质量有了硬性验收线。

5. 第一次封装踩的坑：太贪心

第一个版本我犯了一个经典错误——把"我可能会需要"的所有东西都塞了进去。

微前端？装上。Docker 编排？配上。灰度开关？也要。结果 Skill 生成的骨架又大又重，每次要清理掉一半用不到的东西，反而比手动搭还慢。

这个坑在工程上有个名字：过度设计。 我一轮迭代就把原则改成：

Skill 里只放"100% 每个项目都要用"的公共能力，其余一律不放、由后续按需注入。

那条公理从此成了我这套 Skill 的最高准则：架子只有"必须有"，没有"可能有"。

6. 迭代：从"能用"到"好用的三个版本"

• V1 人设版：把需求描述成 prompt，让 AI 每次"自由发挥"搭项目。结果：每次结构都不太一样，微调开销大。
• V2 模板版：把目录结构和核心配置做成固定模板 + 规则文档，AI 按模板生成。结果：结构稳定了，但还没解决"版本兼容"和"验证通过"。
• V3 工程版（现在）：模板 + 明确步骤 + 依赖版本约定 + 强制"构建验证通过"才交付。结果：一次生成，直接可跑，业务开发从第二天就能开始。

心得：Skill 和普通代码一样，是迭代出来的，不是一次写对的。前两版的经验，比第三版本身值钱。

7. 实际收益：一次项目启动的真实对比

拿最近一个订单管理系统的启动做对比：

省下的不是"5 小时"，而是 “每次项目开始的那股心理阻力”——因为你知道"开局即就绪，今天就能写业务"。这个收益，比时间数字更有价值。

8. 结尾：把你重复三次的事，变成一件可以复制的事

最后分享三条可以带走的判断标准：

1. Skill 的边界 = 你的重复 + 你的标准。它封装的是"你如何做事"，不是"AI 如何做"；
2. 模板要瘦身，成功要验证。骨架只装公共标配，交付必须"跑通"；
3. 迭代优先于完美。V1 哪怕粗糙，跑通流程也比空想更值钱。

我在这个过程中最大的感受是：把"我很熟练"变成"我不需要再熟练"，才是工具化的意义。AI 不再只是帮你写代码，而是帮你把经验本身变成可调用的基础设施。

如果你也有"每次都从零搭、搭了八百遍"的东西，试着把它封装成一个 Skill 吧。你会发现，最值钱的也许不是省下的几个小时，而是那个**“新项目第一天就能全身心写业务”**的全新开始。