第四篇《效率慢的排查顺序》把工具、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变成无限豁免只有章程里的紧急流程工单写明2448 小时内补审、补测发布清单勾了用户还没验收就对外说「已交付」发布清单 上生产≠ 合同验收测试勾了清单开发口头说检查过了发布单贴流水线链接或构建编号能核对密钥贴进 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 太大 / 规则不清下迭代改计划别只骂 AIAI哪些用法有用、哪些没用少踩「生成完就合并」结语AI 省的是写代码的时间人审、测试、发布前清单才决定能不能安心上线。第二篇是整条链第三篇是钱烧在哪第四篇是先查哪这篇是勾什么、勾完谁放行——机器出稿人拍板审过才能合清单过才能发。团队更小时下一篇《小团队最少项目管理规则》会裁流程——但任务表里仍保留「审查 联调」一行发布前仍保留发布清单别先砍这两块。
