我是怎么用 Rules 驯服 AI 写代码的

我用 AI 辅助开发快一年了。一开始很兴奋，觉得效率翻倍。后来发现不对劲——AI 写的代码经常"自作主张"，改着改着把我原来的设计搞乱了。

这篇文章讲的是我怎么用 rules 文件来约束 AI，让它老老实实按我的规矩写代码。

---

问题是怎么来的

我有一个 React 项目，UI 是高度定制的，配色、圆角、阴影都是设计师一点点调的。

有一次我让 AI 帮我加个功能，它"顺手"把我的渐变色改成了纯色，理由是"更简洁"。还有一次，它把我三个组件合成了一个，说是"减少重复代码"。

我当时就崩溃了。这些"优化"我根本没要求，而且改完之后设计稿对不上了。

我意识到一个问题：AI 太"聪明"了，它会按自己的理解去优化，但它不知道我的项目背景。

---

Rules 是什么

现在主流的 AI 编程工具（Cursor、Kiro、Windsurf 等）都支持 rules 文件。简单说就是一个 markdown 文件，写上你希望 AI 遵守的规则，AI 在生成代码时会参考这些规则。

我的 rules 文件放在项目的 .kiro/steering/ 或 rules/ 目录下。

---

我写了哪些规则

1. 禁止"顺手优化"

这是我最先加的规则，因为吃过亏。

【最高优先级规则】
1. 不允许改变现有 UI 风格、布局、配色、渐变、圆角、阴影
2. 不允许"顺手优化设计""统一样式""组件库化"
3. 不允许一次性重构多个文件，除非明确被要求

加了这条之后，AI 老实多了。它还是会建议优化，但不会直接动手改。

2. 明确项目定位

AI 默认会按"最佳实践"来写代码，但最佳实践不一定适合我的项目。

【项目定位】
- 产品型项目（Product-first）
- UI 高度定制化
- 偏移动端体验
- 非通用组件库

我告诉它这是一个 C 端产品，不是组件库，不需要过度抽象。

3. 具体的代码规范

光说"写好代码"没用，得给具体例子。

### 函数式 setState（防止闭包陷阱）

// ❌ 错误
const addItem = useCallback((item) => {
  setItems([...items, item])
}, [items])

// ✅ 正确
const addItem = useCallback((item) => {
  setItems(prev => [...prev, item])
}, [])

我把项目里常见的坑都写成了正反例，AI 看到类似场景就知道该怎么写。

4. 决策优先级

有时候规则之间会冲突，我得告诉 AI 怎么取舍。

## AI 决策优先级（从高到低）

1. 正确性 - 代码必须正确运行
2. 业务语义不变 - 优化不能改变业务逻辑
3. 用户体验 - 流畅度、响应速度
4. 可维护性 - 代码清晰易读

5. 条件触发

有些规则只在特定场景下生效。比如性能规则只在改 React 组件时才需要。

---
inclusion: fileMatch
fileMatchPattern: "frontend/src/**/*.{ts,tsx}"
---

这个 frontmatter 告诉 AI：只有在编辑 frontend/src 下的 ts/tsx 文件时，才加载这个规则。

---

踩过的坑

规则写太多，AI 反而乱了

一开始我写了几十条规则，结果 AI 经常顾此失彼。后来我精简到核心的十几条，效果反而更好。

规则太抽象，等于没写

"写高质量代码"这种话没用。得写具体的，比如"Props 超过 6 个必须拆分"。

忘了写"不确定时怎么办"

AI 遇到规则没覆盖的情况，会自己瞎猜。我后来加了一条：

如果规则中没有明确说明：
- 不允许自行假设
- 必须先声明你的假设，再给出实现

---

现在的效果

用了 rules 之后，AI 写的代码稳定多了。它不再"自作主张"，遇到不确定的会先问我。

当然也不是完美的。有时候它还是会忘记某条规则，我得在对话里再提醒一次。但整体来说，比之前好太多了。

---

我的建议

1. 从你踩过的坑开始写规则。AI 坑过你什么，就加什么规则。
2. 规则要具体，最好有正反例。
3. 不要一次写太多，慢慢迭代。
4. 记得写"不确定时怎么办"。

Rules 不是万能的，但它能让 AI 从"野马"变成"可控的工具"。对我来说，这就够了。