AI编程工具普及下的代码质量治理：编译门禁与一致性审计

团队引入 AI 编程工具之后，PR 数量和合并速度都上来了，但代码库的混乱程度也在以同样的速度增长。编译错误其实是最容易拦住的那一类问题，真正让人头疼的是另一种现象：代码能编译、测试能过、Review 也看不出毛病，合进去之后却开始破坏工程的一致性——绕过统一封装、引入重复依赖、打破目录边界。这篇文章想聊聊我们是怎么在流水线里加了两道闸门来解决这个问题的：一道叫编译门禁，一道叫一致性审计。如果你是技术负责人、DevOps 工程师，或者正在团队里推广 AI 编程工具（比如 Trae、Cursor 这类）但开始隐隐觉得代码质量失控，可以参考这套思路。

1. AI编程工具规模化之后，代码库最怕的不是编译错误，而是"隐性失序"

先说一个背景。我们团队大概在一年前开始正式把 AI 编程工具作为日常开发的一部分，最早是有人用 Cursor 和 Copilot，后来换成对国内开发者更友好的 Trae 这类免费工具，门槛低，接入快，普通开发者不需要配模型、不需要折腾环境就能直接用上。一开始团队士气很高，流水线里通过率涨了不少，PR 从提交到合入的平均时间从原本的两天压缩到了半天。所有速度指标都在变好，直到某一个迭代周期结束，我们做了一次代码库体检，才发现问题比想象中严重。

1.1 编译通过不等于代码可以合入

这是我最想强调的一点：编译是底线，不是质量线。传统的 CI 流水线里，只要代码能编译过、测试能跑通，就默认这个 PR 是"健康"的。但 AI 生成代码的特点是局部看起来完全正确——单个函数、单个组件、单个文件，逻辑自洽、类型正确、命名规范，甚至比大多数新人写的代码还要"标准"。问题出在它和你现有代码库之间的关系上。

举个例子。我们的项目里有一个统一的 HTTP 请求封装，所有调用外部接口的代码都必须走这个封装，因为里面挂了登录态、统一错误处理、埋点日志。这个约束我们写在架构文档里，也写进了代码 Review 的检查清单。但 AI 工具不知道这些——它生成代码的时候，用的是训练数据里"通用"的写法，会直接fetch或者引入一个新的 HTTP 库。这样生成的代码，编译完全没问题，测试也能过，但一旦合入线上，就会绕过统一鉴权和日志，出了问题连查都查不到。

这种问题没法靠编译拦截，因为它不是"错"，是"不一致"。

1.2 一次代码库体检暴露的三个典型问题

我们那次体检针对 AI 工具接入前三个月合并的所有代码做了统计，挑几个有代表性的问题说：

第一，新增依赖数量失控。三个月里package.json里新增了 61 个直接依赖，其中 23 个是项目里本来已有替代方案的工具库。比如有人用 AI 生成日期格式化逻辑，AI 直接引入了dayjs，但项目里本来就在用date-fns，结果同一个项目里两套日期库并存，包体积涨了，维护的人也懵了。

第二，重复实现。项目里已经有现成的formatPrice、parseTime、buildQueryString这类工具函数，AI 生成的代码经常自己另写一个priceFormatter或者getQueryString，逻辑几乎相同，只是名字和写法不一样。这类代码不报错，但后续维护成本很高。

第三，架构边界被打破。我们的前端项目有明确的分层：页面组件不能直接碰数据访问层，请求要先走 service 再走 state。AI 生成的代码经常图省事，在页面组件里直接导入了一个请求函数，或者把一个本该放在utils里的工具类塞进components目录，导致循环依赖和构建问题。

这三个问题有一个共同点：单看每一处，都不至于让你在 Code Review 时指着鼻子骂；但累积到一定程度，整个代码库就变成了"补丁摞补丁"的状态，后面的开发效率会被拖累。

1.3 为什么选"编译门禁+一致性审计"这两个抓手

既然问题不只在编译这一层，那自然要往流水线里加更多检查。但加什么、怎么加，需要想清楚。

我考虑过很多方案。比如强制所有 AI 生成的代码都要经过架构师 Review——不现实，架构师就一个人，PR 每天几十个。比如禁止使用 AI 编程工具——更不可能，效率提升是实打实的，强行禁止只会让大家转去用个人账号，反而脱离管控。再比如加强代码规范文档——有作用，但文档是给人看的，AI 工具的上下文窗口有限，不可能读完整套文档再生成代码。

最后我们定下来两个抓手：编译门禁解决"能不能跑"的问题，一致性审计解决"该不该这么写"的问题。前者是把已有的编译环节做到极致，后者是把工程规范和架构约束从文档变成可自动执行的代码检查。两件事都发生在流水线里，对开发者来说是无感的——你提 PR，机器帮你查，结果写到报告里，你自己看、自己改，不需要等人工 Review 发现这些低级问题。

后面几个章节详细说这两道闸门分别怎么设计、怎么落地，以及我们踩过的坑。

2. 编译门禁：让每一个PR都必须通过一次"完整且干净"的编译

编译门禁听起来很朴素，因为每个团队都有编译检查。但如果你观察过实际运行中的 CI，会发现"有编译"和"有编译门禁"是两回事。传统 CI 的编译检查有很多偷懒的空间，AI 生成代码恰恰是最擅长钻这种空子的。

2.1 传统编译检查的三个漏洞

第一个漏洞是增量编译。很多项目的 CI 为了节省时间，配置成只编译变更的部分，或者依赖本地构建缓存。这对人写的代码问题不大，因为你改一个文件，影响范围大概率就在那个模块里。但 AI 生成的代码不一样，它经常在一个不相关的文件里引入新的 import、新的类型引用，或者修改了一个公共函数但没改调用方。增量编译可能直接跳过这些联动检查，等代码合入后其他人拉取最新代码一编译，报错一大片。

第二个漏洞是缓存污染。团队里常见的构建缓存策略是：如果package-lock.json没变，就直接复用 node_modules 缓存。AI 工具生成代码的时候特别喜欢顺手加依赖，加了依赖但没更新 or 没正确更新 lockfile 的情况非常常见。缓存一复用，编译跑了等于没跑，本地能过，CI 也能过，最后部署的时候才发现依赖缺了。

第三个漏洞是编译错误信息的丢失。有些 CI 配置把编译日志压缩了、截断了，只输出最后几行，前面的警告全部丢掉。AI 生成的代码里经常出现"未使用的变量""隐式类型转换""废弃 API 调用"这类警告，单独看不致命，累积多了就是技术债。

2.2 门禁设计：三条硬性规则

针对这些问题，我们把编译门禁设计成三条规则，写进流水线配置，谁都不能改：

规则一：合并前必须执行全量编译，禁止跳过缓存。每次 PR 触发流水线，都从干净环境开始，npm ci重新安装依赖，然后全量npm run build。速度会慢，但我们用了一个小技巧：PR 的基础分支是main，我们给main上的构建物做了缓存，PR 的分支编译时先把main的构建产物拉下来对比，只对差异部分做全量重编。这样既保证了"干净"，又把大部分编译时间省了下来。

规则二：依赖锁文件必须有人工确认。只要package.json或package-lock.json出现变化，流水线就自动把 PR 标记为"需要人工确认依赖变更"。我们自己写了一个脚本，把新增的每个依赖生成一条说明，包括依赖名、版本、是直接依赖还是间接依赖、在哪些文件里被引用，然后贴到 PR 评论里，由架构师确认这份变更是否有必要。没有确认意见，PR 不能合并。

规则三：编译警告数超过阈值直接拦截。这个阈值我们定的是"0"。编译过程中出现任何 warning，都会让门禁失败。很多人觉得这太严格了，但设成 0 是有原因的：AI 生成的代码经常是无脑import了一堆用不到的模块，或者声明了变量不用。这种 warning 不会让编译失败，但每一个都意味着代码里有冗余，时间长了就是死代码堆积的来源。我们宁可让 PR 作者多花 30 秒删掉无用 import，也不愿意三个月后花三天清理存量。

2.3 落地脚本：一个不会给团队添堵的 build-gate

编译门禁的代码本身并不复杂，关键是把逻辑设计顺。下面是我们用的一个精简版脚本，放在流水线的build-gate阶段执行，命令语言是 TypeScript 项目的场景，其他语言可以对照着改：

#!/bin/bash # build-gate: 编译门禁核心逻辑 # 在干净目录执行全量编译，并拦截一切编译错误与警告 set -euo pipefail echo ">>> 1. 校验 lockfile 是否与 package.json 同步" npm ci --dry-run > /dev/null 2>&1 || { echo "LOCKFILE_MISMATCH: package.json 与 lockfile 不一致" echo "请在本机执行 npm install 后重新提交 lockfile" exit 1 } echo ">>> 2. 执行全量编译" npm run build -- --mode=production 2> build-error.log || { echo "BUILD_FAILED: 编译失败" grep -E "error|Error" build-error.log | head -50 exit 1 } echo ">>> 3. 统计编译警告（阈值：0）" warning_count=$(grep -cE "warning|Warning" build-error.log || true) if [ "$warning_count" -gt 0 ]; then echo "BUILD_WARNING_COUNT=$warning_count (>0)" grep -E "warning|Warning" build-error.log | head -30 exit 1 fi echo ">>> 4. 提取公共 API 签名，供一致性审计使用" npx ts-json-schema-generator --path 'src/**/*.ts' > /tmp/api-schema.json echo "BUILD_GATE_PASS"

这里面有几个细节值得说明。

npm ci --dry-run这一步是专门拦截 lockfile 不同步的。AI 工具改package.json后经常忘了更新锁文件，这条命令能在安装依赖之前就发现问题，省掉后面全量安装的时间。实际用下来，这是整个门禁里命中率最高的一项检查。

2> build-error.log把编译日志完整保留下来，而不是只输出到终端。因为 CI 系统的终端窗口是滚动刷屏的，错误信息一闪而过，开发者根本看不清自己哪里错了。日志文件会同时上传到流水线 artifacts 里，PR 作者可以直接下载，按行号定位。

最后那步提取 API 签名，是给下一章的一致性审计留的输入数据。编译门禁不只是拦错误，它顺手把项目的公共接口清单导出来，后面审计 AI 生成的代码是否重复造轮子时，直接拿这份签名做比对。

2.4 AI生成代码特有的编译陷阱清单

通过几个月的门禁数据，我们整理了一份 AI 生成代码最常见的编译问题清单，给团队做培训也给自己做规则时参考：

• 引用不存在的依赖。AI 的训练数据里见过很多库，但你的项目不一定装了。生成代码时它照样 import，编译直接失败。这类错误门禁能拦下，但真正让我心疼的是它暴露出的另一个问题——AI 不知道项目的依赖边界。
• 同名函数签名不匹配。项目里有个getUser(id)，AI 生成代码时调用了一个getUser(id, withProfile)，编译不一定报错，但参数被忽略，行为和你预期的不一样。这类问题要靠接口审计抓。
• 平台相关路径。AI 生成的代码经常用\拼接路径，在 macOS 和 Linux 上编译通过，在 Windows 上构建失败。我们没有在门禁里直接处理，而是在团队规范里要求统一使用path.join。
• 死代码与重复定义。同一个文件里生成了两个相同功能的不同函数名，编译不报错，但这是在给一致性审计送数据。

编译门禁的定位是"兜底"，它不应该也别想解决所有问题。它的价值在于：让进入代码库的每一行代码都经过一次严格、完整、可追溯的构建验证，把最基础的错误挡在合并之前。在此基础上，才有资格谈更高层次的治理。

3. 一致性审计：对照项目契约，而不是对照编码规范

编译门禁上线两周后，CI 的红灯率明显下降，但我知道真正的硬仗还没开始。编译门禁解决的是语法和依赖层面的问题，而开头提到的那三类问题——重复实现、依赖混乱、架构越界——需要另一套机制来处理。这就是一致性审计。

3.1 一致性 ≠ lint：三个层次的差距

很多团队听到"代码检查"第一反应是 eslint、prettier 这类工具。它们解决的是"格式一致"和"风格一致"的问题，AI 生成的代码在这些工具的约束下通常表现得很好——因为它训练数据里的代码本来就符合主流风格规范，你让 eslint 严格一点，它也能立刻变"规矩"。

但真正的工程一致性有三层：

• 第一层：风格一致。缩进、引号、命名规范。lint 工具能管。
• 第二层：依赖一致。项目里已有的能力不再重复引入新依赖。lint 管不了。
• 第三层：架构一致。数据流方向、目录边界、分层职责。lint 管不了。

一致性审计要管的是第二层和第三层。它对照的不是抽象的"最佳实践"，而是你们项目自己沉淀下来的契约集合：哪些工具函数是唯一的、哪些目录是可以互相 import 的、哪些依赖是允许直接使用的。

3.2 依赖一致性审计：让"引入新依赖"变成高成本操作

AI 生成代码时，最容易犯的错就是"为了一个简单功能引入一个新库"。我们要做的是把这件事的成本抬升到足够高，让 AI 和开发者都自觉回避。

我们的实现方案分三步：

第一步，在仓库里维护一份dependencies-whitelist.json，明确列出项目允许使用的所有第三方库，以及它们对应的用途说明：

{ "允许的直接依赖": { "react": "UI 框架", "date-fns": "日期处理（唯一允许的日期库）", "axios": "HTTP 请求（必须通过 src/services/request.ts 封装调用）", "zustand": "状态管理" }, "明确禁止的替代品": { "dayjs": "日期处理请使用 date-fns", "moment": "日期处理请使用 date-fns，禁止新引入", "fetch": "请使用 src/services/request.ts 里的 request 方法" }, "允许的间接依赖（AI 可能误import）": { "react-dom": "仅限入口文件使用", "lodash-es": "按需引入，优先使用原生实现" } }

第二步，流水线里跑一个依赖审计脚本，扫描每个变更文件的 import 语句，把不在白名单里的包全部标红：

# dependency-audit.sh # 扫描 src/ 下所有 import，检查依赖是否在白名单内 commits=$(git diff --name-only origin/main...HEAD | grep '\.\(ts\|tsx\|js\|jsx\)$') for file in $commits; do imports=$(grep -E "^import .* from ['\"]" "$file" | sed -E "s/.*from ['\"](.*)['\"];?/\1/" ) for pkg in $imports; do # 去掉相对路径 if [[ "$pkg" == ./* || "$pkg" == ../* ]]; then continue fi pkg_name=$(echo "$pkg" | cut -d'/' -f1) if ! grep -q "\"$pkg_name\"" dependencies-whitelist.json; then echo "DEPENDENCY_VIOLATION: $file 引入了未授权依赖 $pkg" echo "如果确实需要，请在 PR 描述中说明理由并通知架构组审批" fi done done

第三步，也是最重要的一步：审计不过的 PR 不会被直接拒绝，但会被打上一个醒目的标签，要求开发者解释"项目里已有的方案为什么不能满足需求"。这一步的意义是让引入新依赖变成一种需要论证的操作，而不是顺手就能做掉的事。

实际执行下来，效果很明显。第一个月还有人不理解，觉得"我用 dayjs 挺方便的，为什么非要和 date-fns 保持一致"。两个月后，新增依赖的数量降到接近零，因为大家都发现，与其在 PR 里写一堆说明走审批流程，不如直接复用项目里现成的封装——而且那也是 AI 工具应该做的事。

3.3 接口一致性审计：识别重复造轮子

依赖白名单能管住"用什么库"，但管不住"自己写一个函数实现已有功能"。项目里有 300 个工具函数，AI 不可能全部记住，它生成代码时经常凭直觉新造一个轮子。

我们的做法是做一个API 指纹库，在编译门禁那一步导出全项目的公共函数签名，然后每隔一段时间做一次相似度比对，找出签名接近或实现逻辑高度相似的函数对。

具体逻辑简化来说：

• 提取每个公共函数的签名：函数名、参数列表、返回值类型、所在模块。
• 然后对新进入代码库的函数，与指纹库里的已有函数做签名相似度匹配。
• 阈值以内就触发警告，提示开发者"新函数与已有函数formatPrice的功能疑似重叠，请选择其中一个保留"。

这个方案不需要复杂的 AI 模型，用简单的字符串相似度算法就能覆盖大部分场景。因为 AI 生成的重复函数通常只是名字不同，参数和逻辑几乎一样，特征非常明显。

另外，我们还在 AST 层面做了一层检查：如果一个函数的函数体长度超过 30 行，而且它不是项目里已有模块的扩展，而是从零写出来的，就触发一条提示，要求开发者确认是否应该放到src/utils/下并登记到公共工具清单里。这听起来简单，但非常有效地防止了工具函数散落在各个业务组件里、最后变成无人知晓的隐藏代码。

3.4 架构一致性审计：用工具强制分层

如果说依赖一致性和接口一致性是"微观层面"的一致性，那架构一致性就是"宏观层面"的一致性。AI 生成代码时没有全局视野，它不知道你们项目的分层规则，也不知道哪些目录之间不能互相依赖。两年后你回看代码，会发现一团乱麻，但当时每一笔改动看着都是合理的。

我们用dependency-cruiser来强制分层。它支持通过配置文件定义模块之间的依赖规则，然后把违反规则的调用关系直接画出来。我们的规则配置长这样：

// .dependency-cruiser.js module.exports = { forbidden: [ { name: "views-不得直接依赖-data-access", from: { path: "^src/views" }, to: { path: "^src/data-access" }, comment: "页面组件必须通过 service 层访问数据，不许直接操作数据访问层" }, { name: "utils-不得依赖-components", from: { path: "^src/utils" }, to: { path: "^src/components" }, comment: "工具函数必须是纯函数，禁止依赖 UI 组件" }, { name: "禁止循环依赖", from: {}, to: { circular: true } } ] };

然后在流水线里加一步：

npx depcruise src --config .dependency-cruiser.js --output-type err-json

--output-type err-json会把违规关系以 JSON 格式输出，方便流水线解析并把内容直接贴在 CI 报告的评论区。违规数量大于 0，门禁失败。

这里面有一个很关键的取舍：我们把所有的违规路径都当成 error，而不是 warning。刚开始有人觉得太粗暴，比如某个 views 页面确实需要读一个常量，而那个常量定义在># consistency-audit.sh echo ">>> 1. 依赖一致性检查" bash scripts/dependency-audit.sh echo ">>> 2. 接口相似度检查" node scripts/api-similarity.js --threshold 0.85 echo ">>> 3. 架构约束检查" npx depcruise src --config .dependency-cruiser.js --output-type err-json echo ">>> 4. AI 变更标记检查" bash scripts/check-ai-tags.sh

第四步check-ai-tags.sh是我们后来加的一个约定：凡是 AI 生成或主要修改的文件，统一要求在文件头加一行注释标记是 AI 生成的。这一步不强制、不拦截，只是统计。但统计结果非常有用——它能让我们知道每个 PR 里有多少代码是 AI 写的，这些代码在后续三个阶段的违规率是多少，从而针对性地调优门禁规则。

4.3 让 AI 生成代码进入流水线前先"读文档"

这一节稍微跑个题，但和流水线改造强相关。很多团队在门禁里加了各种规则，却忘了最关键的一件事：让 AI 工具在生成代码之前就知道这些规则的存在。

我们做过一个对比实验。同样让 AI 工具生成一个"获取用户列表并显示"的页面，第一批直接让 AI 自由发挥，结果它在组件里直接调用了axios.get，绕过了项目封装的request方法，被依赖一致性审计拦下。第二批我们在 AI 工具的上下文里加了一段项目约定的简版说明，告诉它"所有 HTTP 请求必须通过src/services/request.ts的request方法调用，项目禁止直接使用fetch或axios"，同样的需求生成出来的代码直接规避了这条规则，审计一次通过。

结论：门禁是兜底，提示词是源头。流水线里的规则最好能变成 AI 工具上下文里的一份机器可读的"项目契约摘要"，让 AI 在生成阶段就避开坑，而不是生成之后反复被打回。

我把这个摘要整理成了一份PROJECT_GUIDE.md，放在仓库根目录，内容就是依赖白名单、目录边界、统一封装的入口文件路径、以及几条最重要的架构约束。AI 工具在生成代码时会自动引用仓库上下文，这份文件就是让它"懂规矩"的关键。

4.4 门禁失败后的反馈闭环

门禁失败本身不是目的，让开发者快速理解并修改才是。我们的反馈闭环设计了三层：

第一层，CI 报告直接评论到 PR 里。每条违规都会给出具体的文件、行号、规则名称，以及一句人话解释。比如"你在这里使用了dayjs，但项目统一使用date-fns，请替换"。

第二层，失败原因分类统计。我们每周拉一次门禁失败数据，按照"lockfile 不一致""依赖越权""架构违规""编译警告"等分类统计。连续几周如果某一类占比很高，就说明源头没有堵住——要么是提示词里没有写清楚，要么是规则本身太苛刻需要调整。

第三层，失败信息驱动规则调优。每次门禁失败，开发者修改完重新提交，都会在审计日志里留下一条记录。我们定期回看这些记录，如果发现规则误伤了正常代码，就调整规则或添加豁免路径；如果发现规则拦得住但开发者不理解，就优化提示文案。

这套闭环跑通之后，一个最明显的变化是：门禁失败不再是一种"惩罚"，而变成了开发者和机器的一次低成本对话。开发者知道自己错在哪，改完就能过，不需要找架构师说情，也不需要在群里提问。

5. 实测数据与那些容易翻车的细节

到这里，方案的基本框架已经说完了。最后聊聊数据，以及几个我们踩过的坑。

5.1 改造前后的数据对比

我们团队规模约 20 人，前端为主，改造前基线是 AI 工具接入后的三个月数据，改造后是门禁和审计完全上线的三个月数据。数据来自 CI 系统的日志和我们的手动统计：

最直观的感受是，门禁把"发现问题的时机"往前移了一大截。过去问题是合入后才被发现，再回头修，代价翻倍；现在这些代码在合并前就被拦住了，开发者改一遍就能过，整体消耗反而更小。

5.2 最容易翻车的五个场景

第一，规则定得太严，团队直接摆烂。我们一开始把一致性审计的所有违规都设成 error，结果一个页面重构的 PR 里，因为历史代码就存在跨层依赖，被连续拦截三次，开发者干脆把门禁关了，或者绕过流水线强推合并。后来改成"新代码必须合规，存量代码记录在案，限期整改"，团队接受度才上来。

第二，全量编译带来的性能问题让门禁形同虚设。编译从平均 2 分钟涨到 7 分钟 ，开发者等不起，就频繁重新提交让 CI 跑。解决方式有两个：一是拉大并发额度，二是把前面说的"基于 main 构建产物增量化"做扎实，实际跑下来大多数 PR 能在 3 分钟内出结果。

第三，审计规则被滥用成"代码风格 REVIEwer"。有一次开发者在 CI 报告里看到一条警告说"函数名不符合项目命名规范"，跑去改了一轮，结果改完发现是误报——那是规则没有排除测试文件。从那以后我们明确要求：审计规则只关注"一致性"和"架构"，不再管代码风格，风格问题一律交给 lint 工具。

第四，只审计新增文件，不审计修改的文件。这个坑很隐蔽。AI 工具经常在修改一个旧文件时顺便改了几个 import，如果你只 diff 新增文件，就完全漏掉了。我们的审计范围是"本次 PR 内发生变更的所有文件"，而不是"新增的文件"。

第五，依赖白名单写得太死，把合法需求逼到墙角。比如 node 内置模块node:fs、node:path不该被算作第三方依赖，但一开始我们的扫描脚本没有排除，导致有人用fs读取配置文件被误拦。这个好修，加个内置模块过滤就行，但反映出规则设计一定要留白。

5.3 一些实操经验

最后分享几条个人经验，都是踩过坑或者和团队成员反复磨合后总结出来的：

• 门禁规则不是越多越好。多一条规则，就多一分误伤风险。我们坚持"每条规则必须命中过真实问题才能留在配置里"，没有命中记录的规则，宁可删掉。
• 让 AI 工具先看文档再写代码，比在流水线里堵截高效十倍。项目根目录放一份简短的项目契约摘要，AI 工具生成的代码合规率会显著上升。
• 审计报告要写给人看，而不是写给机器看。如果开发者看不懂 CI 报告里的错误，第一反应一定是关掉这个检查。我们花了很多时间把每条违规的提示文案改得通俗。
• 免费工具和商业工具在流水线治理层面没有本质区别。团队里有人用 Trae，有人用 Cursor，有人直接用 Copilot，我们的门禁和审计对这些工具生成的代码一视同仁。治理的关键不在于工具本身有多强，而在于你在流水线里设计了什么样的边界。

我们自己现在最常用的是 Trae 的免费版本，因为它对国内开发者环境友好，不需要折腾各种配置，团队推行成本低。但流水线里的规则和流程才是真正让 AI 编程工具用得放心的东西——工具负责提高生成效率，流水线负责守住工程边界。

有个小细节值得单独提一下：每次门禁失败时，我们会在 CI 报告里贴一段 AI 生成的"修改建议"，但这建议其实是我们预先写的模板，不是 AI 实时生成的。比如"依赖白名单违反：dayjs 被禁止，请使用 date-fns 的 format 方法替代"。这样做的好处是反馈足够具象，开发者照着改就行，不用自己去查文档。如果你也想做类似的事情，给每条规则配一个"修改建议模板"，你会发现门禁的接受度能有质的提升。