AI协同开发规范:人定约束,AI填充;人做校验,AI提速

一句话读懂本规范:AI 帮你把代码写快,但上线前必须人看过;越关键的模块,看得越严。AI 是实习生不是背锅侠——活是它干的,责任是你担的。

Posted by WuQingBao on October 12, 2026

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 交的是草稿,不是成品

  1. 看不懂的代码不许提交——提交人必须逐行读懂。
  2. 当心 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 条规矩:

  1. 高风险模块的 AI 产出禁止直接合入主干,必须负责人留痕确认。
  2. AI 写的代码和手写代码一样进代码审计,提交时标注”AI 辅助生成”。
  3. 评审发现”带病”,要么改提示词重新生成,要么人工改写——禁止带病合入。

四、三种用法,按场景选

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 是实习生不是背锅侠——活是它干的,责任是你担的。看得懂、审得过,才能合得进。