给它一个 Skill 包，让它从"帮你写代码"变成"替你守质量"——还能越用越懂你。

---

一句话

一个覆盖项目开发全流程的前端 Agent Skill 包——从需求澄清到产品验收全链路闭环，但沉淀的只有前端技术经验，每次修 bug 都能自动把经验写回规则，越用越懂你的习惯。

GitHub 仓库：LI-S-H/my-skills

---

痛点：AI 写代码很快，但…

你肯定经历过这些场景：

• 需求还没聊清楚，AI 就开始动手了，写完发现方向不对
• 表格列重叠、弹窗滚不动、提交没有二次确认——每次换项目都要重新踩一遍
• AI 修了一个 bug，下次遇到同类问题还是会犯
• 代码审核全靠人工，漏看是常态

核心问题不是 AI 不够聪明，而是它没有你的经验库。

每次对话从零开始，没有记忆，没有规则沉淀，当然每次都犯同样的错。

---

解法：前端全流程闭环 Skill 包

这个 Skill 包覆盖的是一个前端项目从需求到上线的完整生命周期——需求门禁、PRD 生成、开发规范、契约同步、代码审核、浏览器取证、产品验收、修复闭环，一步不少。但它的技术沉淀范围只有前端：布局、交互、组件、样式、数据映射、事件绑定……不涉及后端架构、DevOps 或数据库设计。

全景一览

阶段	Skill	一句话作用
1. 需求门禁	frontend-requirement-gate	开工前把目标、范围、字段、状态全钉死
2. PRD 生成	frontend-product-docs	自动生成/补全产品需求文档
3. 开发规范	frontend-dev-standards	改代码前先检查复用、契约、样式
4. 契约同步	frontend-doc-sync	字段/接口/Schema/Mock 变了，一齐更新
5. 代码审核	frontend-code-audit	写完自动审，按三类输出问题
6. 浏览器 QA	frontend-browser-qa	截图取证，只看不动手
7. 产品验收	frontend-product-acceptance	产品经理视角，审功能不是审代码
8. 修复闭环	frontend-fix-loop	修完 → 验证 → 沉淀规则
9. 技能索引	frontend-skill-index	路由表，维护时才用

工作流全图

需求门禁 ──复述模板──→ PRD生成 ──PRD──→ 开发规范 ──代码──→ 契约同步
                                                        │
                                                        ▼
                                                    代码审核(分类输出)
                                                   ╱        │        ╲
                                        显示问题      代码问题     业务逻辑
                                           │           │           │
                                           ▼           ▼           ▼
                                       浏览器QA     fix-loop    fix-loop
                                      (取证不修复)   →code-audit  →产品验收
                                           │           │           │
                                           └─────→ fix-loop ←──────┘
                                                     │
                                          显示/代码问题 → skill 文件
                                          业务逻辑问题 → 项目 PRD

这不是 10 个独立的工具，而是一条从需求到沉淀的完整流水线：

1. 门禁挡住模糊需求——不确定的先问，别猜着写代码
2. PRD 把产品逻辑落纸——别让需求只活在聊天记录里
3. 规范卡住低级错误——组件不复用、弹窗没滚动、提交没加锁，写之前就拦住
4. 契约同步防止漂移——字段改了但 Mock 没改、DTO 没跟，这类问题从此绝迹
5. 代码审核自动分类——显示问题、代码问题、业务逻辑问题，不同路子不同走法
6. 浏览器 QA 只取证——截图为证，不越权改代码
7. 产品验收把最后一关——不是"代码能跑"，而是"功能符合 PRD"
8. 修复闭环沉淀规则——这一步是进化的关键，下面重点讲

---

重点：自进化——越用越懂你

这才是这个 Skill 包的真正杀手锏。

三类问题，三条沉淀路径

问题类型	典型表现	沉淀位置
显示问题	布局破、列重叠、sticky 透明、截断缺失	skill 仓库长期维护文件（跨项目复用）
代码问题	数据映射错、事件缺、校验缺、提交锁缺	skill 仓库长期维护文件（跨项目复用）
业务逻辑问题	状态流转与业务不符、权限规则错	目标项目 PRD（项目特有）

关键设计：通用前端问题沉淀进 skill 仓库，跟着你走；业务逻辑问题沉淀进项目 PRD，留在项目里。

沉淀怎么触发？

三种场景，殊途同归：

触发场景	举例
fix-loop 沉淀	修了表格列重叠，发现 dev-standards 里没有列宽规划规则
用户直接指出	你说"需求清单没有提到批量操作"
Agent 自发现	代码审核时发现没有检查 disabled 的原因说明

无论哪种触发，操作步骤完全一致：

定位文件 → 全文搜索 → 判断有无相似规则 → 强化/改写/新增 → 输出沉淀动作

强化而非重复——这是核心原则

• 已有规则没被执行 → 强化原条目，补充"必须"、加具体步骤、加反面案例。禁止另写新条目
• 已有规则表达不清 → 改写原条目，把问题合并进去。禁止另写新条目
• 没有相似规则 → 对应章节末尾新增一条

一句话：规则只进不散，同一类问题只会强化同一个条目，不会越沉淀越乱。

进化效果

想象一下实际使用过程：

第 1 次：表格列重叠，修完 → 沉淀"表格列宽必须有稳定规划"到 dev-standards

第 3 次：弹窗提交没加锁，修完 → 沉淀"写操作必须有提交锁"到 code-audit

第 10 次：你已经积累了 15 条个人化的规则——它们全部来自你实际踩过的坑

第 30 次：新手用你的 Skill 包，直接绕过了你踩过的所有坑

这就是进化：不是 AI 变聪明了，而是你的经验被结构化地注入了工作流。

---

设计思路：路由 + 进化

这个 Skill 包能跑起来，靠的是两个核心机制：路由决定问题往哪走，进化决定经验往哪存。下面讲清楚它们是怎么实现的。

路由：问题分类 → 精准分流

10 个 Skill 不是随意排列的，每一步的输出都定义了下游该交给谁。核心分流点在代码审核——它不是输出一个笼统的"有问题"，而是把问题分成三类，每类走不同路径：

代码审核
  ├── 显示问题 ──→ 浏览器QA(取证) ──→ fix-loop ──→ 沉淀到 skill 文件
  ├── 代码问题 ──→ fix-loop ──→ code-audit(回归) ──→ 沉淀到 skill 文件
  └── 业务逻辑问题 ──→ fix-loop ──→ 产品验收(回归) ──→ 沉淀到项目 PRD

为什么这么分？ 因为三类问题的"修复验证方式"和"经验归属"完全不同：

• 显示问题要靠眼睛看——所以先让浏览器 QA 截图取证，再修，修完再截图
• 代码问题要靠审核验证——所以修完必须重新跑 code-audit 回归
• 业务逻辑问题要靠产品视角验证——所以修完必须过产品验收

每条路径的回归检查也不同，不是笼统的"再跑一遍"，而是针对问题类型的最小聚焦检查。

路由的实现：SKILL.md + 主 reference 二级结构

每个 Skill 只有一个强制阅读的主 reference（检查清单/规范文件），SKILL.md 只是入口描述。这样做的好处：

• 按需加载：Agent 只读当前阶段的主 reference，不浪费 token
• 规则隔离：需求阶段的规则和审核阶段的规则不会互相干扰
• 精准沉淀：进化时能精确定位到该改的文件，不用在几千行里翻

记录库、脚本、历史案例是按需读取，不作为每次执行的必读项。这就是"文档收敛"——该读的少而精，该存的多而准。

进化：修 bug → 沉淀规则 → 下次自动绕过

进化的起点永远是一个被修复的真实问题。流程是这样的：

发现问题 → 修复 → 用户认可 → 判断问题类型 → 定位沉淀文件
     → 全文搜索相似规则 → 强化/改写/新增 → 输出沉淀动作

关键设计点：

1. 只有用户认可后才沉淀

一次性业务问题不写通用记录。你说"可以了、通过了"，才会触发沉淀。避免噪音。

2. 强化而非新增

已有规则没被执行 → 强化原条目（加"必须"、加具体步骤、加反面案例），禁止另写新条目。已有规则表达不清 → 改写原条目。只有真正没有相似规则时才新增。

这保证了一个核心特性：规则只进不散。同一个坑踩两次，规则只会变得更强更具体，不会越沉淀越乱。

3. 通用 vs 项目的分离

通用前端问题（布局、交互、组件、数据映射……）沉淀进 skill 仓库，跟着你跨项目走。业务逻辑问题（状态流转、权限规则、字段含义……）沉淀进目标项目 PRD，留在项目里。

这个分离确保了：skill 仓库里的规则永远是可复用的前端技术经验，不会被某个项目的业务细节污染。

4. 三种触发场景，同一套操作

触发方式	举例
fix-loop 沉淀	修了表格列重叠，发现 dev-standards 里没有列宽规划规则
用户直接指出	你说"需求清单没有提到批量操作"
Agent 自发现	代码审核时发现没有检查 disabled 的原因说明

无论哪种触发，都走同一条路径：定位文件 → 全文搜索 → 强化/改写/新增 → 输出沉淀动作。操作一致，结果可预期。

适配个人习惯

进化的本质是让规则越来越像你。几个细节保证了这一点：

• 规则写法：写"做什么"而非"注意什么"；用"必须/禁止"不用"建议/尽量"——可执行，不留模糊空间
• 沉淀门槛低：你随口一句"这个清单漏了规则"，就会触发沉淀流程
• 强化不新增：同一个坑踩两次，规则只会变得更强更具体

用得越久，这个 Skill 包就越像你——因为每一条规则都来自你实际的工作，而不是某个通用模板。

---

5 分钟上手

# 克隆仓库
git clone https://github.com/LI-S-H/my-skills.git

# 按你的 Agent 工具复制对应目录
# Codex
cp -r my-skills/frontend-* ~/.codex/skills/

# Trae：复制到 Trae skills 目录或项目设置中引用

# Claude Code：在项目上下文或自定义规则中引用 SKILL.md

建议不要一次性加载所有 skill——按任务阶段加载最相关的，Agent 更稳定执行。

按需选择：

• 需求不清 → frontend-requirement-gate/SKILL.md
• 缺 PRD → frontend-product-docs/SKILL.md
• 开发前 → frontend-dev-standards/SKILL.md
• 契约变化 → frontend-doc-sync/SKILL.md
• 提交前 → frontend-code-audit/SKILL.md
• 浏览器取证 → frontend-browser-qa/SKILL.md
• 产品验收 → frontend-product-acceptance/SKILL.md
• 修复反馈 → frontend-fix-loop/SKILL.md

---

项目结构

my-skills/
├── frontend-requirement-gate/   # 需求门禁
│   ├── SKILL.md
│   └── references/requirement-checklist.md
├── frontend-product-docs/       # PRD 生成
│   ├── SKILL.md
│   └── references/product-docs-guide.md
├── frontend-dev-standards/      # 开发规范
│   ├── SKILL.md
│   └── references/frontend-dev-standards.md
├── frontend-doc-sync/           # 契约同步
│   ├── SKILL.md
│   └── references/doc-sync-checklist.md
├── frontend-code-audit/         # 代码审核
│   ├── SKILL.md
│   └── references/code-audit-checklist.md
├── frontend-browser-qa/         # 浏览器 QA 取证
│   ├── SKILL.md
│   └── references/browser-qa-checklist.md
├── frontend-product-acceptance/ # 产品验收
│   ├── SKILL.md
│   └── references/product-acceptance-checklist.md
├── frontend-fix-loop/           # 修复闭环
│   ├── SKILL.md
│   └── references/fix-loop.md
├── frontend-skill-index/        # 技能索引
│   ├── SKILL.md
│   └── references/frontend-skill-package.md
└── .trae/skills/                # 历史技能（通用型）
    ├── blog-writer/
    ├── bug-fix/
    ├── hexo-front-matter/
    ├── requirement-clarifier/
    └── task-review-executor/

一句话总结

10 个 Skill，1 条闭环，∞ 次进化。

这不是一个静态的规则集，而是一个会成长的 AI 工作流。每修一个问题，你的经验就被写入规则；每踩一个坑，下次就自动绕过去。用得越久，它越懂你——因为每一条规则，都来自你真实的工作。

Star & Fork：github.com/LI-S-H/my-skills

---