软件项目管理（5）：AI 辅助开发下的审查与上线门禁
第四篇《效率慢的排查顺序》把工具、AI放在最后一步——不是不重要，而是范围、拍板、等待、排期缓冲没理顺时，上 AI 只会更快堆出一摞待审的合并请求（PR）。第二篇《执行骨架》写过「AI 生成的也要人审」「不能因为 AI 写过就不测」；第三篇《成本篇》讲过大模型用量和「审不过来」怎么算进成本。
这篇不重复整条流程，只收能照着勾、能贴进 PR、能在发布前当最后一关的清单。你们若还没用 AI，把表里的「AI」当成把审查和测试写严一点即可——很多坑本来就和模型无关。
默认场面：七八人的项目，有人用 Copilot、有人用网页对话写代码，合并请求堆着没人审，测试说「能跑」，上线前老板问「能不能今晚发」。
先问一句：考核到底在奖励什么？
编码变快之后，最容易错位的是：考核仍看「提交了多少、生成了多少」，而审查、测试、发布的时间被挤掉。
先问一句：周报和里程碑里，有没有写清「本周已合并、自动检查已通过、能验收的一条交付」？若只有「开发 80%」「PR 已提交」，待审 PR 只会越堆越多——第四篇「等待」里说的审不过来，往往从这里开始。
合并进主干 ≠ 可以上生产：合并和自动检查管的是代码进主库；发布前清单（下文第三道防线）要另外勾一遍——别只追「合并了多少」。
管理上要盯的（与《执行骨架》一致）：能发布、能交代的结果，不是「人有没有在敲键盘、模型有没有在出字」。
几个词先说清
词 | 人话 |
|---|---|
PR | 合并代码前的审查单（Pull Request）；堆着不审多半是没人负责或没排审的时间，不是「大家懒」。 |
自动检查 / CI | 代码一提交就自动编译、跑测试、扫漏洞；和发布前清单一起用，不能装样子。 |
什么叫做完（DoD） | 这条任务怎样算完成——必须能验，不能是「感觉差不多了」。 |
用户验收（UAT） | 按合同或约定试用、签字；演示能跑 ≠ 验收通过。 |
机器出方案、人拍板 | 范围、架构、能不能合并、测没测完、能不能发布、出事谁担责——最后签字必须是活人（责任表里拍板人只能有一个）。 |
一条底线：禁止「生成完就直接合并」
AI 适合：草稿、样板、文档初稿、测试数据、整理日志 人 必须：范围与架构拍板、审查后合并、测试判定、发布与事故责任硬规则（写进项目章程或群公告，不必每次开会重讲）：
规则 | 说明 |
|---|---|
AI 参与的代码必须有人审 | 写的人 + 另一个没写这段的人；禁止自己审自己 |
不能因为「AI 写过」就不测 | 能运行 ≠ 测过；演示 ≠ 验收 |
敏感资料不能贴进未授权的 AI | 见下文数据红线；怀疑泄露立刻按公司信息安全制度办 |
对外材料、给客户看的演示 | 人看过再发；演示要标明不是最终交付 |
范围、合同、能不能上线 | AI 可以整理材料，人拍板；别因「AI 还能赶」砍掉测试和审查时间 |
导读《AI 与机械化种地》：犁快了，巡田不能省——这篇就是巡田时要看的清单。
三道防线：立项约定 → 合并前审查 → 发布前检查
立项时（勾一次） 用什么 AI、什么数据不能贴、谁审代码、账号谁管 ↓ 每个 PR AI 或大改必须严审；重点看数据库、权限、依赖 ↓ 每次上生产前 缺陷、测试、版本对应、回滚；不因 AI 少测与《执行骨架》阶段一致；这里只写和 AI 相关时要格外盯的勾选项。
勾选不是填表交差，而是卡口：过了才往下走；有一项不过就停、改、或按章程找上级——下面各表写看什么，「勾选了，然后呢？」一节写看完以后干什么。
勾选了，然后呢？
三道防线节奏不同，别当成每天勾同一张大表：
第一道（立项勾一次）→ 写进章程，以后按章程做 ↓ 第二道（每个 PR） → 审过 → 自动检查通过 → 合并 → 测试 ↓ 第三道（每次发布） → 允许发布 → 盯监控 → 留下记录备查防线 | 谁勾 | 勾齐 / 审过之后 | 有一项不过 |
|---|---|---|---|
立项约定 | 项目组长 + 发起人确认 | 六条附进章程或群公告；计划里单独有「审查 + 联调」时间；AI 工具统一登记 | 别口头开干：「谁审、什么不能贴进 AI、合并规则」没写清，先补齐 |
每个 PR | 审查人（不能是作者） | PR 里写「审过」→合并前自动检查全绿→合并→（主库若再跑一遍流水线）再绿→ 交给测试 | 不许合并：打回改；范围、架构吵不清的，找拍板人定 |
每次上生产 | 上线放行拍板人（多为测试；开发对自动检查，运维对发布） | 发布单或邮件留下勾选结果→ 运维按窗口发布 →发布后 30 分钟内看监控→ 清单归档备查 | 今晚不发：修 bug、补测、砍本期功能，或走紧急修 bug 流程（仍要写清何时补审、补测） |
和第二篇怎么接（记动作即可）：
合并进主干（开发侧拍板）：前提是 PR已经人审过。
上生产放行（测试侧拍板）：前提是测试、回归、缺陷级别达标。
客户验收 / 用户试用签字：在《执行骨架》验收一节，一般晚于发布前清单；发布清单勾完 ≠ 合同验收，除非章程写明这次发布就是验收节点。
记录放哪：能进系统最好（PR 评论、发布工单、Wiki）；小团队邮件 + 勾选截图也行——关键是事后能查到谁、什么时候、放行还是拦下。
第一道防线：立项时写进章程（约 5 分钟）
除范围和责任分工表（RACI）外，启动时建议书面勾齐下面各行（可复制进章程附件）：
要写清什么 | 常见漏项 | 勾选 |
|---|---|---|
允许用哪些 AI 工具（或统一入口） | 人人私下用网页版，费用和数据都说不清 | ☐ |
什么资料禁止贴进 AI（客户信息、密钥、未脱敏日志等） | 口头说「大家注意」，没有例外流程 | ☐ |
谁审 AI/他人写的代码；禁止自己审自己 | 只说要提 PR，没写谁审 | ☐ |
谁有权点合并；是否必须先审过 | 为赶进度绕过审查 | ☐ |
计划里单独一行：审查 + 联调 + 回归时间 | 全塞进「开发 80%」 | ☐ |
出事谁担责（不能推给「是 AI 写的」） | 事后扯皮 | ☐ |
六条勾齐后：附进章程 → 启动会过一遍→ 任务表加「审查 + 联调」→ 以后不必每周重勾这张表，按章程做；要改章程，走变更流程（见《执行骨架》）。
成本提醒（详见第三篇）：AI 账号宜统一登记、统一管；私人账号乱用，月账单和审不过来会叠在一起——账要看得见。
数据红线（没有商量余地）
下列内容默认不能贴进公司未授权、事后查不清的 AI 服务（具体按本单位信息安全制度）：
类别 | 示例 |
|---|---|
身份与密钥 | 账号密码、API Key、证书私钥、数据库连接串 |
客户与交易 | 未脱敏客户名单、订单、合同、薪酬 |
生产与运维 | 未脱敏生产库、整段生产日志、带内网信息的监控截图 |
合规限制 | 等保或行业规定不能外发的资料 |
一旦怀疑泄露：别再往模型里贴 → 保留证据 →立刻找信息安全接口人——别等项目周会。
可以怎么做：用脱敏后的样例、公开文档、假数据问 AI；生产问题用概括后的现象描述，别整段粘贴带密码、手机号的报错。
第二道防线：每个 PR 合并前（进主库的都要人审）
凡合并进主库的 PR，都必须有「非作者」审过。
PR 说明（A 表）每个都要填；下面任一情况，审查人还要按 B 表逐项勾：
主要代码是 AI 生成或重写的
改动大，或涉及权限、支付、对外接口
发现自己审自己（必须换人审，并按 B 表勾）
A. 作者在 PR 里先写清（审查人对照着看）
要写什么 | 作者填写 |
|---|---|
本 PR有没有用 AI 写代码 | 有 / 没有 / 一部分 |
改了哪里（模块、接口、表） | |
自己怎么测的（步骤或用例编号） | |
你觉得风险在哪（数据库、权限、性能、新依赖） | |
对应需求或变更单号 |
别瞒报：作者写「没用 AI」，审查人仍要看代码改动；发现瞒报按章程处理。编辑器里的 Copilot 等也算，PR 里要标一部分/有。
B. 审查人勾选（通用；AI 参与的更要细）
审什么 | AI 容易出的问题 | 勾选 |
|---|---|---|
需求和范围 | 做的是书面范围，不是聊天里口头加的 | ☐ |
对不对 | 编出来的接口：库里根本没有的方法、错版本语法 | ☐ |
数据库 | 注入、一次查全表、缺索引、迁移脚本回不去 | ☐ |
权限与安全 | 越权、没鉴权、密钥写死在代码里、日志里打隐私 | ☐ |
依赖与许可证 | 乱加第三方包、许可证冲突 | ☐ |
异常与边界 | 只写了「一切正常」的路径；空值、并发、重试没管 | ☐ |
测试 | 关键路径有用例或测试记录；不因 AI 少测 | ☐ |
好不好维护 | 风格跟项目一致；别一堆「一股 AI 味」的过度封装 | ☐ |
自动检查 | 流水线全绿；静态扫描、依赖漏洞无新增高危 | ☐ |
B 表勾齐后：审查人在 PR 写「审过」（或系统里点通过）→合并前自动检查全绿→ 才能合并→ 主库若再跑流水线，再绿一次再交给测试。有一项对不上：打回改或补测试说明，不许合；别先合再补审、先合再跑检查。
改动小、没用 AI、风险低的 PR：仍要换人审过 + 检查全绿；B 表可只勾几项关键的（需求、测试、自动检查），但不能因为改动小就不找人审。
C. PR 说明模板（可复制）
【AI】有 / 没有 / 一部分 【改了啥】…… 【变更单】…… 【自测】步骤或 TC-xxx 【风险】数据库 / 权限 / 依赖 / 性能 【审查人】@xxx（不能是作者本人）六类改动：即使用 AI 很快，也建议两人看一眼
类型 | 多问一句 |
|---|---|
SQL / 数据库访问 | 参数化了吗？数据量大会不会拖死？ |
登录与权限 | 新接口默认拒绝还是默认开放？角色边界对吗？ |
配置与密钥 | 密钥进仓库了吗？测试、生产分开了吗？ |
调外部系统 | 地址、超时、重试、重复提交处理存在吗？ |
前后端字段 | 名字、枚举和后端一致吗——模型很爱「猜」 |
定时任务 / 批处理 | 重复执行、做一半失败、加锁想到了吗？ |
第三道防线：上生产前的清单（上线放行拍板人勾选）
上线放行拍板人（《执行骨架》责任表里多为测试负责人；章程另有规定的从其规定）在动生产前勾齐；开发核对合并与自动检查，运维核对发布与回滚。缺一项不上线（紧急修 bug 若公司有单独流程，仍须写明何时补审、补测）。
全表勾齐后：测试（或章程定的拍板人）在发布单写「发布清单已通过」→ 运维发布 →30 分钟内看监控（见下文「发布前 15 分钟」）→ 清单与发布记录归档。勾不齐：今晚不发——只能修、测、砍功能或走紧急流程，不能口头「先上再说」。
范围和变更
检查项 | 勾选 |
|---|---|
这次发布对照书面范围和变更单，没有口头夹带 | ☐ |
本期说不做的没有偷偷上线 | ☐ |
没有把客户演示当成已经验收 | ☐ |
质量和测试
检查项 | 勾选 |
|---|---|
缺陷达到项目约定级别（例如没有未关闭的严重 bug——级别在项目里写死） | ☐ |
回归测完；AI 动得多的模块有单独回归记录 | ☐ |
没有「AI 写过就不用测」这种例外 | ☐ |
压测、容量、安全扫描（若章程要求）做完，或书面同意豁免 | ☐ |
工程和运行
检查项 | 勾选 |
|---|---|
这次发布的版本号 / 标签 / 提交号和已审过的 PR 列表对得上 | ☐ |
自动检查通过；装出来的包能追溯到是哪次提交 | ☐ |
配置、数据库迁移脚本在预发环境试过 | ☐ |
回滚方案写清（谁操作、多久内能回退） | ☐ |
监控、告警、值班同事知道这次要发什么 | ☐ |
交付和合规
检查项 | 勾选 |
|---|---|
交付清单里有第三方依赖和许可证（模型爱乱加包） | ☐ |
发布说明人看过（可用 AI 起草） | ☐ |
运维交接文档更新（含必须人工维护的说明） | ☐ |
能跑 ≠ 能交货，更 ≠ 能上生产——第四篇「门禁」一节；这篇是把「门禁」落成一张表。
合并请求堆成山了：先别加人写码，先疏通「审和合」
常见现象：待审 PR 越来越多、排队最久的那条已经等了两三天、开发说「写完不让合」、测试一次收到巨大一包。
先这么做（对应第四篇等待、排期、拍板）：
做法 | 说明 |
|---|---|
计划里每天固定一段审查时间 | 别等「开发完了再挤」 |
限制同时在审的 PR 数量 | 先审先合，少开很多半成品并行 |
大 PR 拆开 | AI 一次生成两千行，谁也审不动 |
写清谁负责审代码（可轮值，必须不是作者） | 别和「合并进主干的拍板人」混成一个人只批不审 |
里程碑前别砍审查和测试时间 | 「今晚必须发」不能当跳过清单的理由 |
不宜：再加 AI 补代码、再加人只写不合——那是更快把管道塞满。
容易钻的空子（章程或工具里要堵上）
空子 | 怎么堵 |
|---|---|
PR 写「没用 AI」其实用了 Copilot | 审查人看代码改动；瞒报按章程处理；编辑器辅助也算 AI |
先合并再补审、先合并再跑检查 | 仓库设置：审过 + 检查全绿才能点合并 |
紧急修 bug变成无限豁免 | 只有章程里的紧急流程；工单写明24～48 小时内补审、补测 |
发布清单勾了，用户还没验收就对外说「已交付」 | 发布清单 =上生产≠ 合同验收 |
测试勾了清单，开发口头说检查过了 | 发布单贴流水线链接或构建编号，能核对 |
密钥贴进 AI 或误提交仓库 | 按数据红线升级；评估换密钥、错误合并要不要回滚 |
AI 生成一大堆测试用例 | 测试仍按业务判定；不能因用例多就少做探索和边界 |
和前面几篇怎么配合
篇 | 这篇干什么 |
|---|---|
《执行骨架》 | 全流程、责任表——本篇是照着勾的动作 |
《成本篇》 | PR 堆积、AI 乱用 →干等和工具费；账号要统一管 |
《效率篇》 | 前面都查过了还慢在 AI → 用本篇对 PR 和发布清单 |
导读《AI 与机械化种地》 | 观念；本篇动作 |
不同角色怎么用（不是人人勾整张表）
按谁、什么时候用；不是每次开会全队勾完（立项约 6 项、PR 审查约 9 项、发布约 15 项，各勾各的）。
谁 | 什么时候 | 怎么做 |
|---|---|---|
项目组长 / 发起人 | 立项一次 | 勾立项约定表→ 附章程；以后按章程，不必每周重勾 |
开发（作者） | 每个 PR | 填A 表；不勾 B 表——自己审自己不算 |
审查人（不是作者） | 每个 PR | 按B 表审；PR 里点通过或写「审过」即可，不必再抄一遍 ☐ |
测试（上线放行拍板人） | 每次上生产前 | 勾发布前清单；开发在发布单贴检查通过的链接或构建号；运维确认发布和回滚并签字 |
发起人 / 老板 | 日常不必勾表 | 看留痕：有没有「发布清单已通过」、PR 有没有非作者审过；项目黄了问卡在哪一项 |
在系统里长什么样（任选）：
PR：说明按A 模板+ 审查人点通过
发布：工单或邮件贴发布前清单，测试选通过/不通过
立项：章程附件打勾，或会议纪要写「六条已约定」
要点：☐ 表示「这事我负责过了」；留下记录比形式重要。新人：读硬规则 + 勾选了然后呢，跟着审两轮 PR 就会了。
建议与实操
项目启动：10 分钟定三条
把立项约定表附进章程或群公告置顶。
指定审查人轮值（别永远只有技术负责人一人审）。
任务表单独一行：「审查 + 联调」，工时别藏进「开发」。
日常：看什么数
节奏 | 做什么 |
|---|---|
每日 | 看还有几条 PR 没审、排队最久的那条已经等几天；超了团队定的天数（例如 2 天），当天必须审掉或把大 PR拆开 |
每周 | 周会问：上周说能验收的，验了没有？（与第四篇一致） |
每次发布 | 测试（或上线拍板人）勾发布前清单；勾选结果邮件或工单留底 |
发布前 15 分钟（测试主持，开发、运维参加）
有项卡住时，拍板人要在场或给书面结论。
过发布前清单——有一项不过就停。
问一句：有没有「今晚特殊、明天再补测」？——没有章程里的紧急流程，一律没有。
发布后30 分钟内看监控和报错；AI 动过的模块重点看。
复盘多记两行
记什么 | 有什么用 |
|---|---|
本周审代码卡在哪（人不够 / PR 太大 / 规则不清） | 下迭代改计划，别只骂 AI |
AI哪些用法有用、哪些没用 | 少踩「生成完就合并」 |
结语
AI 省的是写代码的时间；人审、测试、发布前清单才决定能不能安心上线。第二篇是整条链；第三篇是钱烧在哪；第四篇是先查哪；这篇是勾什么、勾完谁放行——机器出稿，人拍板；审过才能合，清单过才能发。
团队更小时，下一篇《小团队最少项目管理规则》会裁流程——但任务表里仍保留「审查 + 联调」一行，发布前仍保留发布清单，别先砍这两块。