---
id: ai.ai-coding.scenario.ai-assisted-feature
title: 团队引入 AI 编程：从“各用各的”到可验证、可复用的工作流
type: scenario
domain: ai
stack: [ai-coding, cicd, git]
tags: [AI 编程规范, 规则文件, Skills, 代码审查, CI, 数据安全]
level: intermediate
prerequisites: [ai.ai-coding.verify-evidence]
est_hours: 2
related: [ai.ai-coding.interview, devops.git.index]
week: [8, 15]
---

# 团队引入 AI 编程：从“各用各的”到可验证、可复用的工作流

## 业务背景与问题

一个 8 人的研发团队开始普遍使用 AI 编程工具，三个月后出现：

1. 代码风格和分层越来越乱，每个人的 AI 按不同的“常见写法”生成代码；
2. 有 PR 一次改了 40 个文件，审查者看不过来，直接通过，上线后出了问题；
3. 测试覆盖率看起来上升了，但很多测试只是重复了实现逻辑；
4. 有人把包含客户手机号的日志粘贴给了外部 AI 工具；
5. 同样的错误（例如时区处理）AI 反复犯。

## 约束

- 不禁止使用 AI 工具，要让它用得更稳。
- 公司有数据安全规定。

## 方案设计

1. **仓库级上下文**：`AGENTS.md` / `CLAUDE.md` 写明技术栈、命令、分层约定、完成标准；按目录的规则文件（前端、后端、迁移各一份）。
2. **团队 Skills**：把高频任务（新增接口、加数据库迁移、发版检查）写成 Skill，由资深成员维护，评审后合并。
3. **PR 规范**：单个 PR 限制规模；描述中必须写“验证方式”（跑了哪些测试、在哪个环境验证、截图），可附验证记录；AI 生成的大段代码要标注。
4. **CI 兜底**：测试、类型检查、lint、密钥扫描必须通过；关键模块要求人工审查者理解后再批准。
5. **数据安全**：明确哪些工具被允许、哪些数据不能发送（客户数据、密钥、未脱敏日志）；提供脱敏脚本。
6. **错误沉淀**：每次 AI 犯的典型错误，在周会复盘后补充到规则文件或 Skill。

## 关键代码

PR 模板（`.github/pull_request_template.md`，平台不同路径不同）：

```markdown
## 改了什么
-

## 怎么验证的（必填）
- [ ] 自动：测试 / 类型检查命令和结果
- [ ] 手动：在哪个环境做了什么操作，结果截图
- [ ] 边界情况：补充了哪些测试

## AI 使用说明
- 使用的工具：
- AI 生成的主要部分：
- 我重点审查 / 修改的地方：
```

验证记录脚本示例：[examples/ai-workflow/verify.py](../examples/ai-workflow/verify.py)。

## 取舍

| 选择 | 优点 | 缺点 |
| --- | --- | --- |
| **规则 + Skills + PR 规范 + CI（本方案）** | 稳定、可积累 | 需要有人维护规则 |
| 禁止使用 AI | 风险最低 | 效率损失，成员私下使用更难管理 |
| 完全放开 | 短期快 | 质量和安全问题累积 |

## 易错点

- 规则文件写一次就不维护，和实际代码不一致。
- 只要求“写测试”，不审查测试质量。
- 用 PR 规模限制来“拆”成很多互相依赖的小 PR，反而更难审查：按功能拆分。
- 数据安全规定只口头传达。

## 面试怎么讲

> “我在项目里用 AI 编程有一套固定做法：仓库里有 AGENTS.md 写清约定和完成标准，常见任务写成 Skill；让 AI 先出计划再执行，小步提交；每次改动跑测试和类型检查，边界测试我自己补，并在真实环境验证；PR 里写清验证方式。AI 反复犯的错误我会补进规则文件。比如有一次 AI 生成的价格计算在优惠券大于金额时返回负数，就是我补的边界测试发现的。”