zhuangang/topics/ai/ai-coding/scenarios/ai-assisted-feature.md

id, title, type, domain, stack, tags, level, prerequisites, est_hours, related, week

id	title	type	domain	stack	tags	level	prerequisites	est_hours	related	week
ai.ai-coding.scenario.ai-assisted-feature	团队引入 AI 编程：从“各用各的”到可验证、可复用的工作流	scenario	ai	ai-coding cicd git	AI 编程规范 规则文件 Skills 代码审查 CI 数据安全	intermediate	ai.ai-coding.verify-evidence	2	ai.ai-coding.interview devops.git.index	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，平台不同路径不同）：

## 改了什么
-

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

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

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

取舍

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

易错点

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

面试怎么讲

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