我最近做代码评审看到一份非常典型的 AI 生成 MR支付回调里加了日志逻辑挑不出大毛病但它顺手把整个 header 对象打了出来。如果合入access token 会跟着日志一起流进日志系统。这不是个例而是 AI 编码时代的典型翻车方式——AI 生成的代码越来越“像样”但它不会主动告诉你它改了哪些文件、加了哪些依赖、埋下了哪些自己察觉不到的问题。所以我想认真聊一个很多人忽略的话题工程级 AI 编码边界与防护规则设计。如果你正在用 AI 写代码或者正准备把 AI 编码工具引入正式项目这篇文章适合你。我会结合自己踩过的坑讲清楚为什么边界比效率更重要再给出一套可以直接拿走的防护规则设计从规则文件到 Git Hook、再到 CI 流水线尽量做到每一步都可落地。1. 为什么 AI 代码总会“暗度陈仓”失控场景复盘1.1 主路径正确边缘条件一碰就碎让 AI 写一个用户上传头像的功能它生成的文件处理函数看着漂漂亮亮文件名处理、格式校验都有。但仔细一检查能发现三个问题文件名直接用原始文件名拼进路径没有做归一化路径穿越风险MIME 校验用了includes(image)image/svgxml也能混进来如果 SVG 里塞了脚本就成了存储型 XSS文件大小检查放在读入内存之后一个超大文件能把内存打满。这不是个例。AI 的训练数据让它特别擅长模仿“正常代码的长相”但项目特有的威胁模型和边界条件它没有感知。它写出来的代码主流程基本能跑一到异常分支、恶意输入、极端参数就开始露馅。这些代码混进主干之后不是“有个 bug 没修”这么简单而是直接给系统开了一个口子。1.2 AI“一本正经”编造 API 和配置更让人头疼的是 AI 的“幻觉”。我问过 AI 某个第三方 SDK 的用法它给我写出了一个根本不存在的函数签名参数名、返回类型看起来都合理一编译就报错。还有一次它在一个 Node 项目里自行添加了一个 npm 包没做任何版本锁定理由是“这个场景用这个库比较方便”。这种“自信地犯错”比不会写更危险。人工写代码时作者通常会查文档、跑测试确认一下AI 生成代码后如果开发者在 review 时也没多想这些不存在的 API、未锁版本的依赖就会直接进入代码库。等部署环境一换或者依赖一更新问题才会集中爆发。1.3 失控的真正代价责任和信任都模糊了代码是资产也是负债。AI 生成的代码在没有边界约束时会变成一种特殊的负债——你不知道它在什么场景下会失效也不知道它背后的设计依据是什么。人工写代码时作者至少踩过哪些坑、为什么绕开某个方案都会有印象AI 代码没有这些上下文。出问题后你不得不从需求反推重新理解一遍代码逻辑甚至重写。更麻烦的是责任模糊。团队一旦养成“AI 写、我随便看”的习惯review 就会流于形式。到时候出了线上事故谁都觉得不是自己的问题但谁都无法快速定位问题。结果就是信任崩塌一部分人开始把 AI 编码拉黑另一部分人继续无边界地依赖 AI团队割裂成两个极端。2. 工程级 AI 编码边界设计三层边界模型与工作流改造2.1 动手前先回答三个问题我建议你在给 AI 编码立规矩之前先认真回答三个问题第一你允许 AI 写哪些文件哪些文件是绝对不让 AI 碰的比如鉴权模块、支付逻辑、部署脚本这些改动一旦出错影响的是账号和钱。第二每一段 AI 代码进入主干前要经过哪几道验证单测、lint、安全扫描、人工 review缺了哪一道都不算完整闭环。第三万一 AI 改错了你能在多长时间内回滚影响范围到哪里这三个问题看着简单但绝大多数团队答不上来。答不上来说明边界是模糊的。别让这种模糊延续到代码库里。2.2 入口边界任务拆到多细才算稳入口边界解决的是“给 AI 什么活儿”的问题。很多开发者习惯一句话丢给 AI“帮我重构这个模块”。任务太大AI 的自由发挥空间就大产出不可控性也大。工程级的做法是把需求拆成小而明确的“任务单元”比如“把 utils/format.ts 里的手机号格式化函数拆成两个函数并补充单元测试”这个粒度就比“重构整个 utils 模块”稳得多。我给团队的提示词模板大概是这样的先说明目标任务再限定文件范围再列出约束条件。比如“只修改 src/utils/date.ts 文件不要新增依赖不要改变现有函数签名不要格式化无关代码提交前跑一遍相关测试”。这些约束看起来啰嗦但对 AI 来说约束越明确它的行为就越可控。2.3 过程边界文件范围、变更粒度和可观测性过程边界解决的是“AI 干活时怎么限制它”的问题。我习惯从三个维度去卡文件范围用规则文件把关键目录拉黑比如src/auth/**、deploy/**凡是 AI 生成的 diff 碰了这些目录直接拦截。变更粒度AI 一次只能提交一个任务单元对应的改动不允许夹带无关重构。判断方法很简单看 diff 里有没有跟当前任务无关的改行。可观测性AI 生成的提交必须在提交信息里带[ai]或类似标签比如feat: add phone formatter [ai]。标签的作用不是区别对待而是让评审者心里多一道校验线也让日后的代码考古能够快速定位这段代码的来源。2.4 出口边界没有验证就不许合并出口边界解决的是“AI 写的东西怎么验收”的问题。我规定 AI 相关 MR 必须满足三个条件才能合并单测和 lint 全绿密钥扫描和依赖审计通过至少一个负责该模块的人做了 review。如果有 AI 改动的文件属于关键模块比如鉴权、支付、权限模型我会要求两个人 review其中一个人专门看安全影响。这个环节不能省。很多项目出事都是因为 AI 写着顺手review 看着也顺手结果上线后一打就碎。2.5 把 AI 编码改成“时间流式”工作流现在很多 AI 编码工具都强调“一键生成”但工程上我更推荐“时间流式”推进。所谓时间流就是把开发过程看作一系列按时间顺序排列的可回放步骤每个步骤只做一件事做完就提交提交就能回滚。举个例子让 AI 重构一个父组件我不会让它一次性输出完整的新文件。我会拆成三个时间片第一个时间片把被内联的子组件抽成独立组件第二个时间片替换父组件的调用方式第三个时间片跑测试并清理死代码。每个时间片单独提交、单独 review。这样就算第二个时间片的方案有问题也不会把第一个时间片的好代码拖下水。工具类型上现代 AI 代码编辑器、命令行 Agent、自动评审机器人可以组合成一条流水线。哪怕只是先用免费的基础工具也应该让它们遵循同一套工作流而不是各干各的、最后人工补救。AI 代码编程工具的效率差异其实没有想象中大真正拉开差距的是“输出有没有被有效校验和控制”。3. 防护规则落地规则文件、Git Hook 与 CI 强校验3.1 规则要防的不是 AI而是五类高发风险规则不是用来防 AI 的防的是 AI 放大后的工程风险。从我实际看到的上线事故来看有五类风险优先级最高风险类型典型表现防护手段敏感信息泄露硬编码密钥、日志打印 token 和 header密钥扫描、正则黑名单危险 API 调用eval、child_process.exec、shell 拼接危险调用黑名单依赖失控AI 自行新增第三方包、不锁版本依赖白名单、lock 文件检查权限过宽文件权限 0o666、越权写操作代码风格检查、人工审核非幂等操作数据库迁移脚本被重复执行、批量写操作单独人工审核AI 的很多错误是“单个点看着没问题整体破坏系统稳定性”。所以规则要偏保守宁可用黑白名单也不要让 AI 在关键路径上自由探索。3.2 用一份规则文件统辖所有检查我习惯把防护规则收敛到一份 YAML 文件里比如ai-code-rules.yml。这份文件同时供本地脚本和 CI 读取避免在两处各写一套规则、最后不一致的问题。一个比较典型的文件长这样version: 1.0 project: demo-web blocked_paths: - src/auth/** - src/payment/** - deploy/** - .github/workflows/** allowed_paths: - src/components/** - src/utils/** - src/pages/** forbidden_patterns: - (AKIA[0-9A-Z]{16}) - eval\\( - password\\s*\\s*[\][^\][\] dangerous_calls: - child_process.execSync - child_process.exec - shell: true dependency_policy: mode: whitelist allow: - lodash - axios - react deny: [] check_level: strict review_required: true这份文件里blocked_paths是保护名单allowed_paths是鼓励 AI 发挥的范围forbidden_patterns是正则黑名单dependency_policy则是依赖白名单。实际操作中要根据项目情况调整但核心思路一致把规则写成代码而不是写在团队协作说明里。3.3 本地第一道网pre-commit 扫描脚本本地防护的最佳位置是pre-commithook。我写过一个 Node 脚本核心逻辑是读取当前暂存的 diff然后依次检查刚才那份规则文件里的条目。以下是一个简化版#!/usr/bin/env node // scripts/guard-ai-diff.js const { execSync } require(child_process); const fs require(fs); const yaml require(yaml); const rules yaml.parse(fs.readFileSync(ai-code-rules.yml, utf8)); const diff execSync(git diff --cached, { encoding: utf-8 }); const problems []; // 1. 检查是否触碰未允许修改的文件 rules.blocked_paths.forEach((pattern) { if (diff.includes(diff --git a/${pattern})) { problems.push(禁止修改文件: ${pattern}); } }); // 2. 检查危险正则 rules.forbidden_patterns.forEach((pattern) { const re new RegExp(pattern, gm); if (re.test(diff)) { problems.push(检测到危险模式: ${pattern}); } }); if (problems.length) { console.error(AI 防护规则拦截到以下问题:); problems.forEach((p) console.error( -, p)); process.exit(1); }这里有一个很实际的坑扫描 diff 时要过滤掉删除行。如果你删掉一行坏代码正则却从删除的内容里命中了问题就会误报。更稳妥的做法是解析 diff只扫描新增行。另外YAML 解析和 JSON 解析一样加错一个空格就会挂所以规则文件建议配一个rules.schema.json做校验或者用 TypeScript 写规则让编译期帮你看住类型。3.4 CI 做强制关卡密钥扫描、依赖审计、diff 校验本地 hook 可以被绕过真正强制的是 CI。我一般在流水线里放四类任务先跑 lint 和单元测试再跑依赖漏洞检查接着跑密钥扫描最后跑刚才那份规则文件里的 diff 校验。GitHub Actions 的简版配置大概是这样的name: ai-guard on: [pull_request] jobs: ai-guard: runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 - uses: actions/setup-nodev4 with: node-version: 20 - run: npm ci - run: npm run lint - run: npm test - run: npm audit --audit-levelhigh - run: npx gitleaks detect --source . --redact - run: node scripts/guard-ai-diff.jsgitleaks是目前比较普及的密钥扫描工具对常见云厂商密钥格式都有默认规则npm audit则负责依赖漏洞。两者配合 diff 校验基本能覆盖我前面列的五类高发风险中的四类。关键是CI 里的规则必须和本地脚本用同一份配置否则本地测完 CI 又拦一道体验会很割裂。3.5 人的 review 升级成“决策点抽查”加入防护规则后人工 review 的价值没有降低而是变化了。要求 reviewer 一行行重读 AI 生成的几百行代码不现实也没有必要。我更推荐把 review 重心放在三个决策点上第一AI 为什么做这个设计有没有被忽略的更简单方案第二边界条件覆盖了吗尤其是输入校验、日志脱敏、依赖变化。第三AI 是不是顺手改多了有没有夹带与当前任务无关的重构这三个决策点一看就是“人在回路”才会关注的单纯靠自动化工具判断不了。Reviewer 不需要把 AI 当成不信任对象而是把它当成一个经验丰富但偶尔冒进的协作伙伴你要做的是把住设计层面的关键关口。4. 实操记录给前端 Node 项目加一道 AI 代码安全闸门4.1 项目背景和规则目标我在一个由 3 人维护的 Node 前端项目上完整跑过这套方案。项目有几十个页面核心业务集中在几个大模块里团队三个人都在用 AI 编码工具。刚开始大家觉得 AI 效率很高直到有一天在日志里发现测试环境密钥被打了出来才意识到没有边界的 AI 编码有多危险。这次整改的目标很简单第一防止敏感信息进仓库第二保护 auth 和支付这类核心目录不被 AI 随意改动第三让 AI 新增依赖必须有意识、有记录第四保证所有 AI 生成代码都经过 review。4.2 第一步建立 ai-code-rules.yml 并锁死我先在仓库根目录建了ai-code-rules.yml并规定这个文件本身不允许 AI 修改改动必须走人工提交。然后做了三个设置把src/auth、src/payment、deploy目录加入blocked_paths因为账号和钱相关的模块一旦被改坏影响不可控把src/components、src/utils加进allowed_paths在这个范围内允许 AI 自由发挥在forbidden_patterns里放入密钥正则、eval、child_process.exec和密码硬编码规则。依赖策略我用了白名单模式新依赖必须人工确认后加进allow列表。这个文件建好之后我会在团队里同步一份说明文档把每个规则的解释写清楚。因为规则如果不解释大家只会觉得“我改了代码结果被机器人拦了”不知道拦的是什么、为什么拦。4.3 第二步写本地 pre-commit 防护我按照前面的示例写了scripts/guard-ai-diff.js挂在pre-commithook 上。脚本做三件事检查 blocked_paths 是否出现在暂存的 diff 里扫描新增代码中的危险模式检查 package.json 里的新增依赖是否在白名单内。如果发现问题脚本直接输出错误并退出进程提交被中断。第一周跑下来误报率确实不低比如eval的正则会命中测试代码里的字符串。后来我按文件类型做了分级测试文件和数据模拟文件走宽松规则业务代码走严格规则。误报降下去之后团队对这个脚本的态度从“烦人”变成了“还挺靠谱”。4.4 第三步在 CI 里跑同一套规则本地 hook 只是缓解CI 才是强制关卡。我把项目接到 GitHub Actions在 PR 合并前跑了npm run lint、npm test、npm audit、gitleaks最后再执行一次node scripts/guard-ai-diff.js。develop 分支设为保护分支merge 前必须全部通过。这里一个重要经验是不要让本地和 CI 各实现一套逻辑。我之前见过有团队本地 Shell 脚本、CI 用插件结果两边规则不同步本地通过、CI 报错或者反过来 CI 通过、本地拦截非常浪费时间。我直接把本地脚本复用到 CI这样只要规则文件更新全链路立刻生效。4.5 第四步两个星期的实测数据运行两周后我看到一些比较有意思的数据防护脚本在合并前拦下了 2 次密钥泄露拦下 1 次对 auth 目录的越权修改有 3 个 PR 因为新增依赖没走白名单被打回。这个结果直接证明规则拦截的“潜在事故”数量是真实的而不是空转。更微妙的变化是团队对 AI 编码的信任度提升了。以前大家心里没底不知道 AI 有没有埋雷现在规则跑完一遍大家默认“只要过了规则大概率没问题”。信任体系建立起来之后AI 编码的效率红利才真正释放出来。5. AI 防护规则避坑指南误报、绕过与团队阻力5.1 误报太多规则会被“内部和谐”第一次上规则的时候不要试图把所有检查调到最强。我第一周收集了大量误报发现若干正则写得太宽比如密钥正则把代码里示例 token 当成真密钥危险调用正则把注释里的字符串也算了进去。处理方式是按文件类型分规则文档、测试文件、业务代码分开配置严苛度不同。还有一个技巧是给开发者留显式的豁免注释比如在代码行尾写// ai-guard:ignore-line告知规则这里已经人工确认过。这样既不会卡住正常开发也能保证豁免行为有记录、可追溯。如果豁免次数太多就要回头看看是不是规则本身有问题而不是开发者想绕规则。5.2 本地 Hook 能绕过CI 必须兜底git hooks 可以被绕过。git commit --no-verify一用本地脚本直接失效。所以我要强调这个原则CI 才是最后的兜底。我见过不少团队把心思都花在给开发者装 hook 上结果绕过之后毫无感知。更好的做法是本地 hook 做体验优化CI 做强制校验两者各司其职。如果团队用企业级代码托管平台建议把主干分支设为保护分支要求 PR 合并前必须全部检查通过。这样就算有人强行 push也会被拦截在服务器端而不是靠个人自觉。5.3 AI 喜欢顺手改没关的代码怎么治AI 编码工具最普遍的问题就是“顺手优化”。它改一个函数时会把相邻代码也重排一遍顺手改掉几个缩进、几个变量名然后让整个 MR 看起来像个大重构。这种情况不仅增加 review 负担还会掩盖真正有风险的改动。我的处理方式有两个第一在提示词里显式要求“只修改与任务相关的区域不要格式化无关代码”第二在 diff 检查里增加行数阈值AI 相关 MR 改动超过 400 行时自动标记为“需要人工拆分”。同时Reviewer 的检查单里要有“删除与本任务无关的改动”这一项从制度上逼着 AI 的产出更聚焦。5.4 规则文件本身被改动等于保护失效规则文件本身也要被保护这一点最容易忽略。如果 AI 可以顺手修改ai-code-rules.yml和 CI 配置那它相当于解锁了所有限制防护形同虚设。我会把这些文件加进blocked_paths并且要求对规则文件的任何改动走单独的 MR说明变更原因由负责人确认后再合入。另外规则文件最好放在.ai/目录下让所有 AI 工具和所有团队成员都读取同一份配置。不要靠某个成员在个人提示词里“约定俗成”那个东西没法审计也没法传承。5.5 团队觉得审查负担重怎么把阻力降到最低任何新流程都会遇到阻力防护规则也一样。我最常听到的抱怨是“审查太多了本来 AI 是为了解放人现在又要搭进去时间”。我的经验是不要把防护做成对人的考核而是把它做成对代码的体检。在落地时我会明确传达一个原则这套规则是帮助开发者在交付前发现问题的不是事后追责的依据。然后把绝大多数检查自动化让 AI 生成的代码自动跑扫描只有扫描结果异常时才需要人工介入。这样团队成员感受到的就不是流程变重而是安全感变强AI 写的代码有人帮忙把关自己可以放手试。我在实践里最有用的一句话是“这套规则不是不让你用 AI是让 AI 的产出不会在深夜上线的时候反咬你一口。”我自己的体会是AI 编码边界不是对 AI 的不信任而是对软件交付这件事的尊重。AI 工具只会越来越强但工程系统的价值从来不是由“生成速度”决定的而是由“可预测性”决定的。你给 AI 设置边界、设计防护规则本质上是把对交付质量的控制权重新拿回自己手里。最后分享一个小技巧把这份规则文件放到仓库的.ai/目录下让所有 AI 工具和所有成员都读取同一份配置团队就不需要靠口口相传来约定 AI 使用规范。规则会过时记得每两周 review 一次跟项目一起演进。