很多前端在用 AI 的时候，都会遇到一个很真实的问题：
不是 AI 不够强，而是它经常没进入你想要的工作模式。
比如：
- 你明明想让它先排查 bug，它却直接开始改代码
- 你只是想先聊方案，它却默认进入实现
- 你只想让它按项目规则来，它却先把目录扫了一遍
- 你想让它帮你验收页面，它却只会从代码层面讲一堆“道理”
我后来慢慢发现一个问题：
真正影响协作效率的，往往不是 AI 能不能做， 而是它有没有一开始就进入正确模式。
所以我最近专门把自己高频会用到的一套 AI skill 做了整理。 目标很简单：
不要每次重新教 AI，而是提前把高频工作模式准备好。
这篇文章就把我目前最常用的一套 前端高频 AI skill 分享出来。 如果你平时会拿 AI 来做这些事：
- 前端开发
- 调 bug
- 需求拆解
- 页面还原
- 页面验收
- PR 协作
那这套方法你大概率能直接用上。
为什么我要专门整理 skill？
一开始我和 AI 协作时，最痛苦的不是它不会，而是它老做错阶段。
最典型的有 3 种。
1）该先讨论的时候，它直接开写
需求还没聊清楚，我只是想先讨论方案，结果它已经开始默认实现，甚至开始写代码。
2）该先定位问题的时候，它直接猜改
页面白屏、构建报错、接口异常、交互失效，本来最重要的是先找根因。 但很多 AI 会直接进入“猜哪里有问题”的状态。
3）该按项目规则来的时候，它忽略上下文
真实项目里通常已经有：
- 协作规范
- 上下文文件
- 任务边界
- 多人分工方式
如果 AI 一上来就乱读、乱扫、乱改，其实非常低效。
所以后来我做了一个调整：
不是每次临时写 prompt 教它怎么做，而是直接给它一套明确的工作模式。
也就是 skill。
一、前端开发里我最常用的 4 个 skill
1. systematic-debugging
它是干什么的？
这是我调 bug 时最常用的 skill。
核心原则就一句：
先找根因，再决定怎么修。
它会优先按这个顺序工作：
- 先复现
- 先收集现象
- 先定位链路
- 再判断修法
适合什么场景？
前端里几乎所有问题都适合：
- 页面白屏
- 请求异常
- 构建报错
- 样式错乱
- 按钮点击没反应
- 某个交互突然失效
为什么它特别实用？
因为很多 AI 的默认行为是“猜修复”。
但真正高效的调试不是：
- 先改代码
- 先试运气
- 先补丁式修补
而是：
先知道为什么坏，再决定怎么改。
你可以怎么说？
- 用调试方式排查这个 bug
- 帮我系统排查这个前端问题
- 这个页面为什么打不开，先定位根因
2. test-driven-development
它是干什么的？
这个 skill 会让 AI 按 TDD 的方式工作：
- 先写测试
- 再写实现
- 再重构
也就是经典的：
RED → GREEN → REFACTOR
适合什么场景？
特别适合：
- 新功能开发
- bugfix
- hooks 重构
- 工具函数补测试
- 状态逻辑回归保护
为什么值得用？
很多 bug 修完了，下一次还是会回来。 问题不是没修，而是：
没有留下回归保护。
TDD 最大的价值就在这里：
不是只修这一次，而是把这次问题钉住。
你可以怎么说？
- 用 TDD 做这个功能
- 先补测试再改实现
- 这个 bug 先写回归测试
3. writing-plans
它是干什么的？
这个 skill 不会直接写代码，而是先帮你做方案和拆解。
它会更关注：
- 改哪些文件
- 分几步推进
- 有哪些风险点
- 哪些事情先做，哪些后做
适合什么场景？
非常适合：
- 新页面开发
- 复杂需求
- 模块重构
- 联调前梳理方案
为什么它很有用？
很多时候，真正浪费时间的不是写代码，而是：
- 改到一半才发现边界不清
- 文件改散了
- 顺手改成了新需求
- 风险点前面没看见
这个 skill 的意义就是：
先把路走顺，再开始动手。
你可以怎么说？
- 先给我实现计划，不要写代码
- 先拆任务和文件改动
- 先做方案设计
4. requesting-code-review
它是干什么的？
这个 skill 适合提交前做一轮代码审查。
它重点会看：
- 质量
- 风险
- 可维护性
- 可读性
- 隐藏坑
适合什么场景？
比如：
- 页面做完准备提交
- PR 前自检
- 重构后复核
- 联调前自查
为什么我建议保留这一步？
很多前端问题不是“功能没做出来”，而是：
- 边界没兜住
- 命名太乱
- 状态耦合太重
- 组件职责不清
- 修法能跑，但后患很大
所以在提交前，让 AI 先走一轮 review，真的能提前挡掉不少问题。
二、前端 UI / 页面还原阶段，我常用的 4 个 skill
5. popular-web-designs
它是干什么的？
这个 skill 更像一个“设计风格参谋”。
它不是直接画图，而是帮你先定页面的设计语言，比如更偏：
- Linear
- Stripe
- Vercel
- Notion
适合什么场景？
- 官网
- Landing Page
- SaaS 后台
- 登录页
- 产品介绍页
为什么它有用？
很多页面不是不会做，而是：
风格不统一。
当你说：
- 参考 Linear 风格做这个页面
- 参考 Stripe 做一个官网首屏
它就能先帮你把这些定下来：
- 配色
- 布局
- 组件气质
- 视觉基调
6. excalidraw
它是干什么的？
这个 skill 很适合在需求讨论阶段使用。
它擅长：
- 页面结构图
- 交互流程图
- 区块关系图
- 弹窗 / 抽屉 / 表单流梳理
为什么我很喜欢它？
因为很多页面一旦直接开写，很容易越写越乱。
但如果先把结构画出来，很多问题会当场暴露：
- 入口在哪里
- 主动作是什么
- 信息层级清不清楚
- 哪些区块根本不该出现在这个页面
一句话总结：
先把结构讲清楚，再开始写，会省很多返工。
7. architecture-diagram
它是干什么的？
如果说 excalidraw 更偏草图，那这个 skill 更偏正式图。
适合做：
- 前后端架构图
- 模块关系图
- 接口流转图
- 汇报型技术图
什么时候适合用？
- 做系统方案说明
- 给团队汇报
- 梳理前后端边界
- 写技术设计文档
8. dogfood
它是干什么的？
这是我很喜欢的一个 skill。
本质上就是：
让 AI 像 QA 一样，真正去测你的页面。
它通常会检查这些问题：
- 控制台报错
- 交互问题
- 视觉问题
- 可访问性问题
- 隐藏的 UI bug
特别适合什么时候用？
- 页面开发完成后
- 提测前
- 交付前
- 想自己先跑一遍验收时
为什么它比“只看代码”更有用？
因为前端很多问题，不是看代码就能发现的，必须进页面操作：
- 点击没反应
- 弹窗层级不对
- 表单校验时机不对
- 某个状态下按钮不可达
- 样式在真实页面里错位
所以这个 skill 很适合做最后一轮查漏补缺。
三、GitHub 协作里，我会固定用这 4 个
9. github-pr-workflow
适合完整推进 PR 流程：
- 建分支
- 整理提交
- 开 PR
- 看 CI
- 合并
如果你平时 GitHub 协作很频繁，这个会非常省心。
10. github-code-review
这个更专注于 PR / diff 审查。
适合：
- review 自己的改动
- review 同事的 PR
- 快速找出 diff 里的风险点
11. github-issues
如果团队用 GitHub issue 管需求和 bug，这个也很顺手：
- 建 issue
- 查 issue
- 关联 PR
- 整理 issue 流程
12. codebase-inspection
这个 skill 特别适合刚接手一个仓库时使用。
它能快速帮你了解：
- 仓库规模
- 代码量
- 语言分布
- 结构构成
对于新项目接入阶段非常有帮助。
四、如果你懒得记 skill 名，记住这些自然触发句就够了
其实你不一定要硬背 skill 名。
很多时候，只要自然说需求，AI 也能自动匹配到对应模式。
前端调 bug
用调试方式排查这个问题
对应：
systematic-debugging
先出方案
先不要写代码，先给我方案
对应：
writing-plans / plan
页面还原
参考 Linear / Stripe 风格做这个页面
对应：
popular-web-designs
画页面结构
先帮我拆页面结构和交互流
对应：
excalidraw
做代码检查
帮我 review 这次改动
对应：
requesting-code-review / github-code-review
做页面验收
帮我测一下这个页面
对应：
dogfood
提 PR
帮我开 PR 并看 CI
对应：
github-pr-workflow
五、我现在最认可的一条原则：别把 AI 当万能回答器，要把它当“可切模式的搭档”
这是我最近用 AI 最大的感受。
真正让 AI 变得好用的，不是你每次都写超长 prompt， 而是你逐步建立起一套稳定的 工作模式切换机制。
也就是：
- 讨论时，用讨论模式
- 调试时，用调试模式
- 规划时，用规划模式
- 验收时，用 QA 模式
- 协作时，用 PR / review 模式
这样 AI 的表现会稳定很多，沟通成本也会明显下降。
六、如果你是前端，我建议优先把这 8 个用熟
如果只保留最常用的一组，我推荐这 8 个：
systematic-debuggingwriting-plansrequesting-code-reviewpopular-web-designsexcalidrawdogfoodgithub-pr-workflowgithub-code-review
它们基本覆盖了前端最高频的几类事情：
- 排查问题
- 先做方案
- 提交前 review
- 页面风格参考
- 页面结构梳理
- 页面验收
- PR 推进
- 差异审查
如果你也经常觉得：
- AI 有时候很强，但不稳定
- 同一个问题，不同轮次表现差异很大
- 经常要重复教它“先别这样，先那样”
那你可以试试我这套思路：
不要每次重新教 AI，而是提前给它准备好几种高频工作模式。
当这些模式稳定下来之后，AI 就不再只是一个“回答问题的工具”。
它会更像一个：
- 知道什么时候该先讨论
- 知道什么时候该先定位
- 知道什么时候该先验收
- 知道什么时候该先 review
的协作搭档。
