AI如何强制执行工程标准：从代码评审到CI门禁的落地实践

Cloudflare 通过 AI 来 enforce 工程标准这个方向最近讨论很多。它不是简单地让 AI 帮你写代码而是把团队里那些靠人肉检查、靠文档反复强调的工程规范变成由 AI 在代码提交和评审阶段自动识别、提醒、修改和拦截的规则。简单说就是让 AI 从“写代码助手”变成“工程质量的检查员和门禁”。这类实践最值得关注的价值在于它把“标准”这件事从纸面搬到了流水线里。对很多团队来说工程标准不缺少缺的是一个能长期稳定执行标准的机制。如果你正在做研发效能、代码治理或者想了解大模型在开发流程里除了生成代码还能干什么这篇文章值得看完。下面我会按实际落地的顺序拆一遍先理解 Cloudflare 这类做法到底在解决什么问题再看需要准备什么然后是单条 PR 的最小闭环最后是效果衡量和踩坑经验。1. 先弄清楚 Cloudflare 这次说的 enforce 到底是什么意思1.1 不是“AI 帮你写代码”是“AI 当工程质量的检查员”看到“Cloudflare enforces engineering standards using AI”这个标题很多人第一反应是Cloudflare 在用 AI 写代码、补代码、做代码生成。这不算错但不是最核心的点。enforce 这个词在工程语境里不是“辅助”而是“强制执行”。也就是说AI 不是坐在旁边给建议而是被接到代码评审链路里在 PR 提交、CI 跑批、Merge 之前这些节点上做检查。检查不通过PR 会被打回或者至少会在门禁状态上标记失败迫使工程师处理完问题才能继续。这种定位和 Copilot 式工具完全不同。Copilot 回答的是“你让我写什么”AI 强制执行标准回答的是“你是否按照团队约定的方式做了”。如果团队已经有严格的 code review 文化AI 扮演的更像一个永远在线、不会疲劳、记得所有规则的首席评审官。不过也要说清楚现实中不会有团队直接让 AI 一票否决所有合并。公开分享里提到的做法通常是分级执行低风险问题 AI 直接提醒或自动修改高风险问题 AI 标记后留给人工 reviewer 决策。1.2 为什么传统工程标准容易失效很多团队不是没有工程标准。入组文档里写了命名规范、接口设计规范、禁止在业务代码里直接拼 SQL、日志要按固定结构输出、敏感信息不能落盘等等。但标准写出来之后落地通常靠两件事新人自己读文档老人在 code review 时凭经验抓。这两件事都不稳定。新人读文档容易漏老人在评审时容易只看逻辑不看规范。PR 一旦变大评审者很难把每个文件的命名、依赖方向、错误处理、日志字段都核对一遍。于是标准从“红线”慢慢变成“建议”最后变成“没人在意”。AI 强制执行标准解决的是这个断层标准一旦被翻译成可检查的规则模型就可以在每次代码变更时自动跑一遍不管 PR 是大是小、评审者今天状态如何。1.3 强制和辅助要分开设计这里有一个很容易踩的误区认为给模型一段 Prompt说“请检查代码是否符合规范”就等于完成了 AI 执行标准。实际做下来会发现这种开放指令的输出非常不稳定模型经常会提出一堆“看着有道理但是团队根本不关心”的问题真正需要拦截的反而漏掉。所以更稳妥的做法是把检查项拆成两类硬标准命名、文件路径、禁止项、依赖方向、敏感信息、必填字段。这类适合让 AI 按规则判断输出是“通过 / 不通过”。软标准代码可读性、函数长度、模块边界、异常处理完整性。这类适合让 AI 给建议输出是“建议程度”。强制和辅助分开语义才清晰。如果所有问题都走同样级别的拦截工程师很快就会烦躁最后绕过这套机制。2. 用 AI 执行工程标准之前需要先把标准变成机器能判断的东西2.1 标准要分三层可遵守、可检查、可自动修正把工程标准交给 AI 前第一件事不是选模型而是整理标准清单。我建议把团队已有的标准分成三层第一层是“可遵守”。也就是人类能看懂、知道怎么做。比如“控制器不应直接操作数据库”。这类标准通常写在文档里是原始素材。第二层是“可检查”。要把上面的抽象标准转成机器可判断的检查项比如“在 controllers 目录中出现的 import 或调用不允许直接出现 UserRepository.save、db.write 等数据库访问方法”。这一层才是真正需要喂给模型或规则引擎的内容。第三层是“可自动修正”。比如“日志必须使用结构化 logger不允许 print”这类问题修改方式确定AI 可以直接生成 patch让工程师一键应用。不是说每一条标准都要到第三层。但至少要走到第二层否则模型拿到的是一个无法判定的模糊任务。2.2 接入点代码评审入口和 CI 门禁标准整理完下一步是选接入点。常见的接入点有三个一是代码托管平台的 PR 检查机器人。PR 创建或更新时触发AI 读取 diff 和关联文件返回评论或 check status。这是体验最好、最容易解释效果的接入方式。二是 CI 里的独立检查任务。在测试之前或之后跑一个 AI 检查脚本输出报告到日志或者平台。适合团队暂时不想装机器人只想先看报告的情况。三是本地命令或 pre-push 钩子。适合把一些硬标准提前拦截在开发者本地但不能作为唯一门禁因为本地很容易被跳过。从 Cloudflare 这类大团队的工程文化来看PR 阶段接入最自然。因为它对齐的是评审流程模型发现问题贴到 diff 对应行工程师在弹窗里决定接受还是忽略。2.3 上下文准备把仓库知识喂给模型用 AI 做工程标准检查有一个和传统 lint 工具很不一样的地方模型需要上下文。同一个规则在不同项目里执行边界完全不同。比如“禁止在控制器里直接访问数据库”这条规则在一个普通 Web 项目里很合理但如果项目本身没有 service 层或者项目是一个简单脚本仓库这条规则就不适用。模型如果没有看到项目的目录结构、依赖层级、历史评审模式就很容易按通用常识去判断结果就是误报率很高。所以我建议在接入时至少给模型准备这些上下文仓库的目录结构和模块边界项目使用的语言、框架、ORM团队已经沉淀的典型代码示例包括好的和坏的历史上人工 reviewer 经常提的那几类问题这些内容不一定写进一条超长 Prompt。更实际的做法是按仓库生成一份规则描述文件把检查项和上下文一起维护模型只负责按这份文件执行。3. 最小闭环一条 PR 从提交到 AI 检查通过要经过哪些步骤3.1 触发与输入组装diff、规则、仓库上下文我建议在任何团队里先跑最简版本不要一开始就设计一个完整平台。最小闭环可以拆成四步。第一步是触发。在 PR open 或 synchronize 事件时Webhook 或 CI 任务调用模型服务。第二步是组装输入。最关键的是把 diff 提取出来然后把项目规则文件、仓库上下文和本次变更的目标说明一起拼进请求。注意不要把整个仓库都塞给模型很多仓库很大成本高也没必要。通常只需要变更文件、相关配置文件、以及 README 或设计文档里和本次变更相关的片段。第三步是模型判断。这里要避免让模型自由发挥。建议在 Prompt 里明确只按给出的规则清单检查不新增规则所有判断都要给出文件路径和行号拿不准的标记为“需人工确认”。第四步是输出和落地。模型返回结构化结果程序去操作 PR 评论、创建 check 或者打开一个报告面板。3.2 结构化输出不是让 AI 写作文而是返回 JSON 检查结果工程化落地时一定要把模型输出转成结构化的东西。如果直接让 AI 在 PR 下写一段评论后面想统计误报率、跟踪问题状态、按文件过滤都会很痛苦。我见过比较合理的返回结构是 JSON每个检查问题包含规则 ID、严重级别、文件路径、起始行、结束行、问题描述、修改建议、是否可自动修复。这样一个列表可以直接映射到 PR 评论的不同位置也可以存进数据库做后续分析。下面是一个示意性的返回结构实际字段可以根据平台调整{ repository: example-service, pull_request: 1234, results: [ { rule_id: LOG-001, level: error, file: src/order/controller.go, start_line: 48, end_line: 48, message: 禁止使用 print 输出日志请使用结构化 logger, suggestion: logger.Info(\order created\, logger.Field(\order_id\, order.ID)), auto_fixable: true } ] }注意这里面最重要的是行号。模型输出没有行号工程师就很难定位。与其追求模型写一段漂亮的解释不如让它把每条问题都绑到具体位置。3.3 落地动作评论、状态检查、自动建议补丁拿到结构化结果后落地动作可以选择三种。第一种是 PR 评论。适合软标准和需要解释的问题。模型在对应行下面留言工程师自己判断改不改。第二种是 GitHub 或 GitLab 的 check status。适合硬标准。如果存在 error 级别的问题check 标记为失败Merge 按钮被禁掉。这是 enforce 最有体感的实现方式。第三种是自动建议补丁。适合 auto_fixable 字段为 true 的问题。可以由 AI 直接生成一个 patch 或 commit但这里强烈建议不要直接把 patch 推到远程分支而是先创建评论里的 suggestion让工程师点一下应用到代码中。把动作分级是为了防止 AI 过度干预。真正的 enforce 不是说每一条 AI 意见都要导致合并失败而是让不同级别的问题走不同强度的规则。3.4 典型流程先影子模式再硬门禁如果要给一个稳妥的上线顺序我建议这样影子模式AI 跑检查只在内部群或日志里输出结果不在 PR 下评论也不影响合并。评论模式AI 在 PR 下加评论但不设 check也不阻止合并。软门禁风险高的问题设置 check failure低风险问题只评论。硬门禁 自动修复error 级别自动生成补丁工程师确认后由人工触发合并。大多数团队到第三步就可以了硬门禁加自动修复容易引发信任问题需要很长的磨合期。注意不要第一步就开启硬门禁。AI 检查工具在没有足够反馈数据和人工校正之前误报率通常不会低到可以一票否决所有 PR。4. 怎么判断这套 AI 工程标准检查是有效还是“看着热闹”4.1 先定义四个核心指标误报率、漏报率、接受率、阻断率很多团队跑了一周 AI 检查后汇报时候只用一句话“AI 在 PR 里发现了 200 个问题。”这句话没有意义。200 个问题里如果 190 个是无关紧要的工程师根本不看那这套机制就是在制造噪音。我更建议用四个指标衡量误报率AI 认为有问题、但工程师确认不该改的比例。漏报率人工 reviewer 发现、而 AI 没发现的标准问题比例。这个指标可以先抽样数周再估算。接受率工程师接受 AI 建议并修改的比例。接受率太低说明规则不够精准或表达方式不对。阻断率AI 设置 check failure 后工程师最终修改且合并的比例。如果阻断率很高说明硬标准选得准如果大部分被人工 override说明规则不合适。这四个指标不需要做成复杂报表。前两周甚至用表格手动统计都行。重点是让规则维护者看到趋势。4.2 建立基线先在影子模式下跑两周我一般会建议团队先跑两周影子模式不要急着开评论。两周时间足够覆盖至少几十个 PR能看出模型对哪些规则判断稳定哪些规则输出混乱。影子模式期间要做两件事。一是把规则名、发现次数、人工确认结果记录下来二是让人工 reviewer 做一个小样本标注把 AI 意见分成“同意、不同意、表达有问题但方向对”三类。有了基线之后再进入评论模式。这时候已经有数据支撑可以告诉团队我们预计哪些规则误报率低于 5%哪些规则还需要继续调。4.3 什么情况下可以把 AI 结果升级为硬门禁硬门禁不是永远不能开但要有条件。我的判断标准是单个规则连续两周误报率低于 5%。对应问题的修改方向明确不存在“可以改也可以不改”的争议。团队里至少有一位 reviewer 愿意对该规则负责。有办法让工程师临时豁免比如在评论里回复同意或人工批准后可以跳过。满足这些条件后才可以把这条规则从“评论”升级为“check failure”。注意是逐条升级不是整套规则一起升级。硬门禁的规则越少效果越明确信任越容易建立。5. 最容易翻车的五个坑和对应的排查顺序5.1 规则写得太抽象模型只能做“我觉得这是问题”翻车频率最高的坑是规则描述还停留在文档语言。比如“请确保代码健壮性”。模型没法判断什么是健壮输出就会越来越飘。排查时先重新读一遍规则原文然后问自己一个刚入职的工程师能完全按这条规则执行吗如果不行说明规则还不可检查。应该改成一个具体条件比如“外部输入必须经过参数校验缺失时返回 400不允许出现直接用于查询数据库的字符串拼接”。5.2 上下文太少AI 不理解项目里的历史约定有时模型连续在同一个地方误报比如不了解项目的数据库访问模式把 Repository 的调用误判成直接访问数据库。这时候问题通常不是模型能力而是上下文缺失。处理思路是给模型补充对应模块的说明或者直接在白名单里把这一层调用排除掉。与其反复调 Prompt不如先检查项目描述、目录结构、依赖关系是否已经放进了输入。5.3 自动修复建议被直接应用代码被大范围重写自动修复很诱人但风险也最大。AI 理解的“正确”和项目实际需要可能不一致。一旦自动化 patch 被直接推到远程轻则产生无意义 diff重则把原有逻辑改坏。排查顺序是确认自动修复开关是否默认开启确认 patch 有没有经过本地测试确认分支保护是否阻止了直接推送确认 review 阶段是否给了工程师逐条确认入口。更稳妥的做法是AI 只生成 suggestion不主动推送 commit。5.4 没有申诉通道工程师开始绕过 AI如果 AI 检查变成一条无法申诉、无法关闭的失败状态工程师会产生抵抗心理。最常见的结果是PR 频繁 rebase、绕过检查、把大 PR 拆成小碎块、甚至直接在描述里要求 reviewer 强制合并。这属于流程设计问题。在硬门禁旁边一定要保留脱困通道比如“标记为不适用”“添加人工审核通过标签”“降低门槛到 warning”。AI 检查工具和所有自动化工具一样必须有 override 能力。5.5 问题反馈没有回到规则库AI 一直重复报错最后一个坑是反馈闭环缺失。工程师已经把某条规则标记为误报很多次但规则维护者没有同步更新规则库于是每个新 PR 还会继续收到同样的噪声。要解决这个不是让模型自己学习而是定期把标记为误报或忽略的问题导出按规则 ID 聚合看哪几条规则被忽略次数最多。超过阈值就处理要么改规则描述要么降低级别要么把例外情况写进规则文件。这个定期复盘要做成流程而不是口头约定。每周花半小时处理一次规则库比攒一个季度再找原因高效得多。6. 不是大厂也能用小团队和个人的落地路径6.1 先不做门禁只做 PR 评论助手看到 Cloudflare 这类实践最容易产生的想法是“我们团队也要上一套完整平台”。但对大多数团队来说第一版只需要一个 PR 评论助手。具体做法用项目现有的 CI 或代码托管平台 Webhook在 PR 更新时调用一个大模型接口把 diff 和规则文件传给它让它只输出匹配规则的问题。不设置 check status不做自动修复只在 PR 评论区出现一条经过明确格式化的报告。好处是成本低、可撤销、团队接受度高。跑两周后再看数据决定要不要加门禁。6.2 用通用工具和 API 也能搭一个最小版本如果团队没有现成的 AI 平台也可以直接调大模型 API。最简流程是在仓库放一个rules.md每条规则有编号、严重级别、判断条件、参考示例。CI 脚本在 PR 事件时拉取 diff读取rules.md发送给模型。模型返回 JSON 检查结果。脚本把结果转换成评论使用代码托管平台 API 提交。这里的实现重点是控制 Prompt 长度和调用成本。PR diff 很大时可以按文件分片或者只检查变更行。rules.md建议控制在几十条以内不然模型容易顾此失彼。6.3 边界哪些工程标准不适合交给 AI最后要记得AI 不是所有工程标准的最终执行者。有些规则本质上不依赖 AI传统 lint、静态检查、测试覆盖率更稳定。比如go 代码的格式用 gofmt 解决Python 命名用 flake8 或 ruff 解决依赖漏洞用扫描器解决。这些场景不适合让大模型执行因为规则明确、执行快、不会产生争议。更适合 AI 执行的是那些“需要理解上下文才能判断”的规则例如新增接口是否缺少鉴权注解对外暴露的返回结构是否包含内部字段日志中是否拼接了用户输入的原始内容数据库迁移脚本是否包含破坏性变更这类规则对传统工具太开放对人工又太烦琐正好卡在大模型的处理范围内。6.4 后续演进从单点检查到 AI Agent 式的规则治理当第一阶段跑稳后可以从单条 PR 检查扩展到更完整的治理链路。比如让 AI 根据历史问题生成新的规则草稿由负责人确认后进入规则库或者让 AI 在发现问题时自动关联对应的文档链接和负责人更进一步可以让 AI 识别出团队高频出错区域反向推动代码重构。这个过程本质上就是 AI Agent 在研发规范领域的落地模型不再只做一次孤立判断而是把发现、反馈、规则更新、异常处理串成闭环。现在很多团队谈 AI Agent实际落地时最成熟的入口之一就是这里。先从一个仓库、一组规则、一个 PR 检查开始比一开始就设计一个万能治理平台更靠谱。整套方案真正落地时最该盯住的不是模型选得多强而是规则库维护、反馈闭环和分级执行。Cloudflare 给外界展示的更多是结果而中间那些“标准如何结构化、误报如何处理、工程师怎么才愿意配合”的工作才是 AI 强制执行工程标准能不能长期跑下去的关键。如果你准备在自己的团队里做类似的事我建议顺序是选一条最明确、最不能妥协的标准用影子模式跑通最小闭环再由人工确认后升级成门禁。先让 AI 当一个靠谱的检查员再让它慢慢承担更多 enforcement 职责。这样既不伤团队信任也能拿到可见的工程效能收益。