AI协同开发规范
💬 一句话读懂本规范:AI 帮你把代码写快,但上线前必须人看过;越关键的模块,看得越严。
| 版本 | 适用范围 | 维护 |
|---|---|---|
| V1.1 | 研发部全体成员(产品/测试/运营可参照) | 技术委员会 |
一、先搞清楚:AI 干什么,人干什么
AI 是一个手速极快的实习生——干活快、不知累,但会犯错、会瞎编,需要有人带; 你是带教导师——负责派活、定规矩、验收结果。出了事,责任在导师,不在实习生。
flowchart LR
subgraph H["👤 人(导师):定方向、把最后一道关"]
H1["定目标和约束"]
H2["评审产出"]
H3["业务/安全决策"]
end
subgraph A["🤖 AI(实习生):干重活、干快活"]
A1["样板代码 / CRUD"]
A2["单测 / 注释 / 文档"]
A3["查资料 / 方案草稿"]
end
H -->|"派活 + 定规矩"| A
A -->|"交草稿"| H
H2 -->|"通过"| R["✅ 合入上线"]
H2 -.->|"不通过,重来"| A
各角色分工一览
| 你是谁 | 你负责(不能甩给AI) | AI 帮你干 |
|---|---|---|
| 架构师 / 负责人 | 需求拆解、技术选型、风险评估、最终验收 | 方案草稿、技术调研、代码骨架 |
| 开发工程师 | 核心逻辑设计、代码评审、疑难 bug、性能与安全 | 样板代码、CRUD、单测、注释、重构、脚本 |
| 测试工程师 | 测试策略、场景设计、边界用例、验收标准 | 批量用例、自动化脚本、日志分析 |
| 产品经理 | 业务目标、优先级、业务规则 | PRD 初稿、需求清单、FAQ |
💡 记住一句话:人定约束,AI 填充;人做校验,AI 提速。
二、核心工作流:G-P-R-L 闭环
任何 AI 辅助任务,都按这个圈走一遍:
flowchart LR
G["🎯 G · 目标<br>说清楚要什么"] --> P["📝 P · 提示<br>结构化地提问"]
P --> A["🤖 生成<br>AI 交草稿"]
A --> R{"🔍 R · 评审<br>人工把关"}
R -- "不通过" --> P
R -- "通过" --> L["📚 L · 沉淀<br>存模板、记坑点"]
L -.->|"下次更快更好"| G
classDef step fill:#e3f2fd,stroke:#1976d2,color:#0d47a1
classDef gate fill:#fff3e0,stroke:#e65100,color:#bf360c
class G,P,A,L step
class R gate
G · 目标——先把要什么说清楚
动手前想清楚 4 件事,缺一件就先别找 AI:
- 要解决什么问题、给谁用
- 必须遵守哪些业务规则、不能碰什么
- 技术栈、框架版本、编码规范是什么
- 怎样算做完了(可测试、可度量)
P · 提示——好好提问,别甩一句话
| ❌ 反面示范 | ✅ 正确姿势 |
|---|---|
| “帮我写个订单功能” | 背景 + 任务 + 约束 + 输出要求,分段说清(模板见附录 A) |
| 复杂系统让 AI 一次写完 | 拆成小任务,一步一步生成 |
| 把密钥、真实用户数据贴给 AI | 用假数据、脱敏数据演示 |
生成——AI 交的是草稿,不是成品
- 看不懂的代码不许提交——提交人必须逐行读懂。
- 当心 AI 瞎编——它可能调用根本不存在的 API,提交前逐个核实。
R · 评审——人工把关(这一步不许省)
四个维度快速过一遍(详细清单见附录 B):
flowchart LR
C["AI 产出的代码"] --> Q1["逻辑对吗?<br>符合业务规则吗"]
C --> Q2["安全吗?<br>注入/越权/泄密"]
C --> Q3["能看吗?<br>符合团队规范"]
C --> Q4["扛造吗?<br>异常/边界/性能"]
L · 沉淀——把经验变成团队资产
- 好用的提示词 → 提交到提示词模板库(附录 A)
- 踩过的坑 → 记入坑点清单(附录 C)
- 可复用的代码 → 归入团队模板仓库
三、AI 产出审多严?看风险等级
一句话原则:模块越要命,审得越狠;拿不准等级,就高不就低。
flowchart TD
S["🤖 AI 产出了东西"] --> Q{"动的是什么模块?"}
Q -->|"工具脚本 / 文档 / 单测"| L["🟢 低风险<br>自己认真过一遍<br>+ 团队抽查"]
Q -->|"业务接口 / 页面代码 / SQL"| M["🟡 中风险<br>完整 Code Review<br>至少 1 名工程师评审通过"]
Q -->|"支付 / 权限 / 核心算法 / 数据读写"| H["🔴 高风险<br>AI 只当草稿纸<br>人工重写或逐行重审 + 自测<br>负责人终审签字"]
L --> OK["✅ 才能合入"]
M --> OK
H --> OK
classDef low fill:#e8f5e9,stroke:#2e7d32,color:#1b5e20
classDef mid fill:#fffde7,stroke:#f9a825,color:#795548
classDef high fill:#ffebee,stroke:#c62828,color:#b71c1c
class L low
class M mid
class H high
补充 3 条规矩:
- 高风险模块的 AI 产出禁止直接合入主干,必须负责人留痕确认。
- AI 写的代码和手写代码一样进代码审计,提交时标注”AI 辅助生成”。
- 评审发现”带病”,要么改提示词重新生成,要么人工改写——禁止带病合入。
四、三种用法,按场景选
mindmap
root((三种协同模式))
🛵 助手模式(默认)
人主导,AI 当副驾
写一段问一段,补代码查 bug
适合 日常业务开发
🏍 并行模式
人做架构和核心模块
AI 并行做外围模块、脚本、单测
适合 多模块项目
要点 接口契约先定好
🔬 预研探索模式
AI 快速出多个方案原型
人对比选型,淘汰不可行的
适合 新技术调研
⚠️ 原型代码禁止直接转生产
五、安全红线:碰了就是事故
flowchart LR
X["🚫 五条红线"] --> X1["密钥 / 证书 / 生产配置<br>不许贴给任何 AI 工具"]
X --> X2["真实用户数据<br>不许贴给任何 AI 工具"]
X --> X3["AI 引入的开源依赖<br>必须走白名单评估"]
X --> X4["不许用 AI 产出<br>绕过鉴权 / 加密 / 审计日志"]
X --> X5["疑似抄袭开源的片段<br>必须核实许可证才能用"]
classDef red fill:#ffebee,stroke:#c62828,color:#b71c1c
class X,X1,X2,X3,X4,X5 red
还有一条隐形红线:安全决策、业务决策、复杂业务规则,永远由人拍板,AI 只能提建议。
六、用了 AI 之后,时间都去哪了
编码时间确实少了,但评审和需求拆解的时间变多了——别指望”躺着变快”,要习惯”把功夫前置”。
pie title 🐢 传统开发:时间分配
"需求&架构" : 20
"编码实现" : 50
"测试&bug修复" : 20
"文档" : 10
pie title 🚀 AI协同开发:时间分配
"需求&架构" : 30
"代码评审&核心编码" : 35
"测试&风险校验" : 25
"文档&资产沉淀" : 10
七、怎么知道用得好不好(每月看这几个数)
| 指标 | 看什么 | 期望方向 |
|---|---|---|
| 编码阶段耗时 | 同类需求,编码工时降没降 | ⬇️ |
| AI 幻觉拦截数 | 评审时抓到多少”瞎编的 API / 错误逻辑” | 📝 记录即可,喂给坑点清单 |
| bug 来源分布 | bug 是手写的多,还是 AI 产出的多 | 👀 监控 |
| 评审一次通过率 | AI 产出一次过审的比例 | ⬆️ |
| 资产沉淀数 | 新增了多少提示词模板、坑点记录 | ⬆️ |
每月一次团队复盘:分享好用的提示词、通报典型坑点;每季度按数据修订本规范。
附录 A:提示词模板(直接抄作业)
A.1 让 AI 写代码
1
2
3
4
5
6
7
8
9
10
【背景】技术栈:xxx;相关模块:xxx;现有代码/接口定义:(粘贴)
【任务】实现 xxx 功能
【约束】
1. 遵循编码规范:xxx
2. 依赖限制:不引入新依赖 / 仅白名单内:xxx
3. 必须处理的边界情况:xxx
【输出要求】
1. 完整可运行代码 + 关键逻辑注释
2. 列出你做出的所有假设
3. 配套单元测试用例
A.2 让 AI 帮你审代码(审完人还要再过一遍)
1
2
3
4
5
6
7
以下代码由 AI 生成,请以资深工程师视角审查,重点找出:
1. 逻辑错误与业务规则偏差(业务规则:xxx)
2. 安全漏洞(注入、越权、敏感信息)
3. 不存在的 API / 过时用法(幻觉)
4. 异常与边界处理缺失
代码:(粘贴)
输出:按严重程度分级列出问题,每条给修复建议。
A.3 提交新模板的格式
模板名称 + 适用场景 + 模板正文 + 使用示例 + 提交人 + 至少 1 次实际使用效果记录。
附录 B:AI 代码评审清单(评审时逐项勾)
逻辑对不对
- 业务逻辑与需求一致,没有”想当然”的默认行为
- 边界条件覆盖(空值、越界、并发、超时)
- 无幻觉:所有 API、方法、依赖真实存在且版本正确
安全不安全
- 无 SQL 注入 / 命令注入 / XSS
- 权限校验完整,无越权路径
- 无硬编码密钥、密码、内网地址、敏感数据
代码能不能看
- 命名、分层、注释符合团队规范
- 没有重复造轮子(已有工具类没用上)
扛不扛造
- 异常处理完整,失败路径有兜底
- 无明显性能问题(循环内 IO、N+1 查询等)
合不合规
- 新增依赖走了白名单流程
- 无疑似不兼容许可证的开源片段
- 提交信息已标注 AI 辅助生成
附录 C:AI 常见坑点清单(持续补充)
| 坑 | 长什么样 | 怎么防 |
|---|---|---|
| 幻觉 API | 调用根本不存在的方法/库,或已废弃的旧 API | 逐个核实依赖和 API;本地跑一遍 |
| 过时知识 | 用旧版本框架写法,和新版本不兼容 | 提示词里写明框架版本号 |
| 想当然逻辑 | 自己脑补业务规则,和真实需求跑偏 | 提示词给全业务约束;评审对照需求逐条核对 |
| 隐性安全漏洞 | 拼接 SQL、日志打印敏感信息、鉴权放水 | 强制用附录 B 清单;高风险模块人工重写 |
| 表面正确的单测 | 只测顺利路径,断言形同虚设 | 人工补边界用例,检查断言是否真的在断言 |
| 过度工程 | 三行能解决的事,给你抽象出八个类 | 提示词约束”最简实现”;评审砍掉多余抽象 |
💬 最后再啰嗦一遍:AI 是实习生不是背锅侠——活是它干的,责任是你担的。看得懂、审得过,才能合得进。