彻底驾驭前端 AI 编程助手：基于 Rules 与 Skills 的提效核心法则

目标读者：使用 AI 辅助开发的前端工程师、前端架构师、技术 Leader
核心价值：掌握使用 Rules 和 Skills 调教 AI 编程助手的核心方法，解决 AI 生成代码不符合项目规范的问题，实现从“盲目生成”到“确定性提效”的跨越。
阅读时间：6 分钟

一句话摘要：别再用长篇 Prompt 喂 AI 了，用 Rules 划定前端规范红线，用 Skills 沉淀组件最佳实践，让 AI 真正成为懂你项目的高级工程师。

引言：AI 编程的甜蜜与烦恼

在如今的前端开发领域，AI 编程助手已经从“玩具”蜕变为不可或缺的生产力工具。无论是快速生成一个 React 表单组件，还是用 Tailwind CSS 还原设计稿，AI 都能在几秒钟内给出令人惊艳的初稿。

然而，随着项目复杂度的提升，许多开发者会陷入一种“AI 焦虑症”：它确实能写代码，但它经常写出“不符合团队规范”的代码。比如，它可能在 TypeScript 中肆无忌惮地使用 any；在明明规定了使用 Zustand 进行状态管理的项目中，自作主张地引入了 Redux；或者在遇到稍微复杂的组件通信时，写出层层嵌套的“回调地狱”。

为什么会这样？因为 AI 拥有海量的互联网开源代码记忆，但它缺乏你的项目上下文。为了让 AI “听话”，许多人试图把所有的规范都塞进长长的系统提示词（System Prompt）中，但这很快就会遇到瓶颈：上下文过载不仅浪费 Token，还会让 AI 忽略关键指令。

那么，如何优雅地赋予 AI 个性，让它严格遵循团队的前端规范呢？答案就藏在两个核心概念中：Rules（规则） 与 Skills（技能）。只要掌握了它们的运用之道，你就能让 AI 变成你团队中最资深、最懂规矩的高级工程师。

一、Rules（规则）：划定不可逾越的技术红线

如果你不希望 AI 做某件事，请将其编写为一条规则（Rule）。

在前端开发中，规则更像是防御性编程的体现，它主要用于编码偏好和禁止性约束。把规则告诉 AI 最好的方式，就是通过在项目的根目录维护一个 CLAUDE.md 文件（或类似的系统级指令入口）。

构建逻辑嵌套的上下文目录

这里有一个极其重要的实用建议：不要把所有规则揉在一个文件里。请将你的 CLAUDE.md 视为一个逻辑嵌套的路由目录，用于根据特定场景分发上下文。

它应该尽可能地保持简洁，只包含类似 IF-ELSE 的条件语句，告诉 AI 在遇到什么情况时去阅读哪个具体的规则文件。规则是可以嵌套的，也是具备条件判断逻辑的。

例如，在你的前端项目中，CLAUDE.md 可能长这样：

• 如果你正在编写 React UI 组件，请在开始前阅读 docs/rules/react-component-rules.md。
• 如果你正在编写业务线的数据请求逻辑，请阅读 docs/rules/api-fetching-rules.md。
• 如果你正在编写单元测试，请阅读 docs/rules/jest-testing-rules.md。
• 如果你在运行测试时遇到了失败报错，请优先阅读 docs/rules/test-failing-rules.md。

通过这种方式，您可以创建任意逻辑分支的规则链条，只要在入口文件中明确指定，AI 就会顺藤摸瓜，精确获取它当前任务所需的上下文。

规则驱动下的敏捷纠偏

如果你在开发中发现 AI 犯了一个你不赞成的错误——比如它习惯性地把行内样式（Inline Styles）写死在 JSX 中，而不是使用 Tailwind 类名。不要只是在对话框里抱怨“别用行内样式”，而是把这件事写成一条固化的规则。

在 react-component-rules.md 中加上一句：“绝不允许使用 style 属性编写行内样式，所有样式必须通过 Tailwind CSS 的 className 实现。” 并在下一次遇到类似任务前提醒 AI：“在编写组件前，请重新阅读组件规则。” 从此以后，它绝对不会再犯同样的错误。

二、Skills（技能）：沉淀标准化的前端最佳实践

如果说 Rules 是用来防止 AI “搞破坏”的红线，那么 Skills（技能） 就是指导 AI “如何把事情做好”的菜谱。

规则通常用于编码偏好（“不要做什么”），而技能更适合用于固化复杂的业务流或技术实现方案（“应该怎么做”）。如果你对前端项目中的某类任务有极其特定的实现路径，你需要把它封装成一项技能。

从黑盒到确定性的解决方案

很多开发者经常抱怨：面对一个复杂的业务需求（比如实现一个带权限控制的动态路由菜单），不知道 AI 到底会用什么野路子来解决，这种不可控性让人感到恐慌。

想要将这种不可控转化为确定性，方法其实非常简单：让 AI 先调研它会如何解决这个问题，然后你对其进行审查与修正，最后把修正后的标准答案保存为一项 Skill。

假设你希望统一团队中“实现响应式可访问性模态框（Accessible Modal）”的标准。你可以和 AI 进行一次预演，修正它过度依赖第三方臃肿库的行为，引导它使用 Radix UI primitives 结合 Tailwind 来实现。一旦方案敲定，创建一个名为 modal-accessibility-skill.md 的文件，里面详细记录了这个标准流程：

1. 必须使用 @radix-ui/react-dialog 作为底层 headless 组件。
2. 必须包含屏幕阅读器可见的 DialogTitle 和 DialogDescription。
3. 样式的覆盖必须遵循我们在 tailwind.config.js 中的定制设计系统。

触发你的专属技能

如何让 AI 知道这项技能的存在？一如既往，回到你的配置中枢 CLAUDE.md。

你只需要加上一条简单的引导：“当你遇到需要处理弹窗或模态框相关的需求时，请立即阅读 docs/skills/modal-accessibility-skill.md。”

通过这种方式，你在 AI 遇到真实的业务问题之前，就已经为它注入了团队的最佳实践。它不再是一个盲目搜索互联网旧代码的机器，而是传承了你前端架构思想的得力助手。

三、规则与技能的运用（Dealing with Rules and Skills）：从魔法到治理

当你深刻理解了 Rules 和 Skills 的差异，并开始将团队的前端规范源源不断地注入其中时，你会体验到一种前所未有的爽快感。

你的 AI 助手突然变得充满魔力，它开始“按照你想要的方式”写出优雅的 React 代码，准确地捕捉到你在状态管理上的洁癖。在这一刻，你甚至会觉得，自己终于领悟了“智能体工程（Agentic Engineering）”的终极精髓。

然后……不可避免地，你会发现 AI 的表现开始再次出现下滑。它开始变得迟钝，偶尔甚至会无视一些指令。

怎么回事？上下文灾难与矛盾冲突

原因其实非常简单。随着你在前端项目中积累了越来越详细的规则和技能，它们开始相互打架了。

也许你在三个月前写了一条规则要求“优先使用 Axios 处理请求”，但上周你又添加了一项新技能规定“所有的服务端状态必须用 React Query 的 Fetch 封装”。AI 在这两个指令间迷失了。

更严重的问题是上下文冗余（Context Bloat）。如果 AI 在开始写一行简单的按钮组件代码之前，需要被迫阅读 14 个长篇大论的 Markdown 文件，它就会面临人类开发者一样的困境——被大量过时或无用的信息淹没，导致注意力分散，核心指令丢失。

给你的 AI 助手安排一次“水疗日”

那么，作为架构师，你应该怎么做？

答案是：定期重构与清理。

你需要给你的 AI 代理们安排一次“水疗日（Spa Day）”。定期审查你的 docs/rules/ 和 docs/skills/ 目录：

1. 整合去重：把散落的几个关于 CSS 命名的零碎规则整合到一个内聚的文档中。
2. 剔除矛盾：消除不同时期沉淀下来的冲突逻辑，保持唯一真实的数据源（SSOT）。
3. 按需加载：重新审视 CLAUDE.md 中的 IF-ELSE 路由，确保颗粒度足够精细。不要让 AI 在写一个简单的纯函数时去加载整个前端工程的性能优化长文。

只有通过不断的剪枝与治理，你的 AI 助手才能保持敏锐，那股“魔法般的感觉”才会再次降临。

结语：掌控最终的结果 (Own The Outcome)

这就是驯服前端 AI 编程助手的真正秘诀。不要把 AI 当作一个全知全能的神，而是要将它视为一个能力极强但需要明确边界的实习生。保持指令系统的简单纯粹，熟练运用 Rules 划定边界，用 Skills 沉淀方法，把 CLAUDE.md 作为一个动态的路由分发中心，并时刻对上下文的冗余度保持敬畏。

在当前的时代，没有哪个 AI Agent 是绝对完美的。虽然你可以将大量繁重的前端组件设计和实现工作下放给它们，但作为开发者，你始终是那个需要对最终代码质量负责（Own the outcome）的架构师。