新人入职第三天，第 5 个 MR 被打回。
评论里写的全是：
- "我们这里不用 moment，用 dayjs"
- "service 文件放 src/services 下面，不是 src/api"
- "组件命名用 PascalCase"
- "这个公共方法已经有了，在 src/lib/utils 里"
我突然意识到：这些"规矩"只存在于老人的脑子里。 没有文档，全靠口口相传，新人只能靠"被打回"来学习。
我做了什么
把所有"潜规则"写成 AI 配置文件，提交到 git。
新人 clone 项目后，AI 自动加载这些规则。他写的代码从第一行开始就符合团队规范------不是因为他"学会了"，而是 AI 帮他遵守了。
配置文件结构
graph TD
A[.kiro/steering/] --> B[tech.md<br/>"用什么"]
A --> C[structure.md<br/>"放哪里"]
A --> D[coding.md<br/>"怎么写"]
A --> E[patterns.md<br/>"照着谁写"]
B --> F[技术栈规范]
C --> G[文件结构规范]
D --> H[编码风格规范]
E --> I[范例参考]
F --> J[AI自动遵守]
G --> J
H --> J
I --> J
J --> K[新人代码<br/>天然正确]
style A fill:#e1f5fe
style B fill:#f3e5f5
style C fill:#e8f5e8
style D fill:#fff3e0
style E fill:#fce4ec
bash
.kiro/steering/ （或 .cursorrules 单文件）
├── tech.md ← "用什么"
├── structure.md ← "放哪里"
├── coding.md ← "怎么写"
└── patterns.md ← "照着谁写"tech.md --- 回答"用什么"
markdown
- React 17 + TypeScript 4
- UI: Ant Design 5 + ProComponents
- 状态管理: Rematch 2
- 日期: dayjs（禁止 moment）
- 样式: Less + CSS Modules（.m.less）structure.md --- 回答"放哪里"
markdown
| 类型 | 路径 | 示例 |
|------|------|------|
| 页面组件 | src/view/<domain>/ | src/view/marketing/CouponList/ |
| 接口函数 | src/services/<domain>/ | src/services/marketing/coupon.ts |
| 状态模型 | src/models/<domain>/ | src/models/marketing/coupon.ts |
| 公共组件 | src/components/ | src/components/SearchForm/ |
| 工具函数 | src/lib/ | src/lib/format.ts |
| 常量枚举 | src/constant/ | src/constant/marketing.ts |
| 自定义Hook | src/hooks/ | src/hooks/useModal.ts |coding.md --- 回答"怎么写"
markdown
## 命名
- 变量/函数: camelCase
- 组件: PascalCase
- 常量: UPPER_SNAKE_CASE
- 事件处理: handle + 事件名 (handleClick)
- 状态变量: is/has + 形容词 (isLoading)
## 函数风格
- ✅ const handleSubmit = () => {}
- ❌ function handleSubmit() {}
## 组件规范
- 单文件不超过 250 行
- Props 必须定义 interfacepatterns.md --- 回答"照着谁写"
markdown
| 页面类型 | 范例文件 |
|----------|---------|
| 列表页 | src/view/marketing/CouponList/index.tsx |
| 表单页 | src/view/marketing/CouponCreate/index.tsx |
| 详情页 | src/view/member/MemberDetail/index.tsx |
| Service | src/services/marketing/coupon.ts |
| Model | src/models/marketing/couponList.ts |效果对比
xychart-beta
title "新人第一个MR被打回次数对比"
x-axis ["没有配置", "有配置"]
y-axis "被打回次数" 0 --> 6
bar [5, 1]
---
title "新人问'这个放哪里'频率对比"
x-axis ["没有配置", "有配置"]
y-axis "每天提问次数" 0 --> 6
bar [5, 0.5]
---
title "代码风格统一时间对比"
x-axis ["没有配置", "有配置"]
y-axis "所需天数" 0 --> 15
bar [14, 1]
arduino
新人第一个 MR 被打回次数
没有配置：█████ 3-5次
有配置： █ 0-1次
新人问"这个放哪里"的频率
没有配置：每天 5+ 次
有配置： 几乎不问
代码风格统一时间
没有配置：2 周后
有配置： 第 1 天传统方式 vs AI配置方式对比
flowchart TD
subgraph A[传统方式]
A1[写规范文档] --> A2[新人阅读文档]
A2 --> A3[新人忘记规则]
A3 --> A4[写错代码]
A4 --> A5[CR打回]
A5 --> A6[再看文档]
A6 --> A3
end
subgraph B[AI配置方式]
B1[写配置文件] --> B2[AI自动遵守规则]
B2 --> B3[新人代码天然正确]
B3 --> B4[CR通过]
end
A4 -.->|循环3-5次| A6
B3 -.->|第一次就对| B4
style A fill:#f9f2f4
style B fill:#f2f9f2
为什么这比"写文档"有效
markdown
传统方式：
写规范文档 → 新人看了 → 忘了 → 写错 → CR 打回 → 再看文档 → 记住了
↑ 循环 3-5 次
AI 配置方式：
写配置文件 → AI 自动遵守 → 新人写的代码天然正确 → CR 通过
↑ 第一次就对规范文档是"教人记住规则"，AI 配置是"让机器执行规则"。后者不依赖人的记忆力。
可直接抄走的完整模板
markdown
# Project AI Configuration
## Tech Stack
- Framework: [填你的]
- UI Library: [填你的]
- State: [填你的]
- HTTP: [填你的]
- Date: [填你的]
- Style: [填你的]
## File Placement
| Type | Path |
|------|------|
| Pages | src/view/<domain>/ |
| Services | src/services/<domain>/ |
| Models | src/models/<domain>/ |
| Components | src/components/ |
| Utils | src/lib/ |
| Hooks | src/hooks/ |
## Naming
- Variables/Functions: camelCase
- Components: PascalCase
- Constants: UPPER_SNAKE_CASE
## Banned Patterns
- No any type
- No moment.js
- No class components
- No inline styles
- No function declarations
- No single file > 250 lines
## Reference Files
- List page: [填路径]
- Form page: [填路径]
- Service: [填路径]
- Model: [填路径]一句话总结：团队的"潜规则"不应该只存在于老人的脑子里。写成配置文件，让 AI 帮你传承。新人不需要"被教"，只需要"被约束"。
💬 你们团队带新人最头疼的是什么？有没有一个"新人必踩的坑"清单？