AI Agent 防作弊 CI 实战自动拦截assertTrue(true)、跳过测试和空 catch系列导读本系列用一个可运行的 Spring Boot 秒杀 Demo拆解“当 AI 成为我的全职下属”之后研发工作流应该如何重建。五期内容从一次超卖事故开始依次讨论并发正确性、上下文裁剪、防作弊 CI、Agent 友好架构和 Human-in-the-loop 上线门禁。主线不是证明 AI 能不能写代码而是回答一个更实际的问题当 Agent 已经能高吞吐地产出代码时工程师如何用边界、验证和审批机制把它变成可靠的执行者。文章目录AI Agent 防作弊 CI 实战自动拦截 assertTrue(true)、跳过测试和空 catch1. 问题现场CI 绿了但问题没有修好2. 验证目标3. 原因绿色流水线为什么可能是假成功4. 原理把禁止项变成机器可执行规则5. 在 Demo 中验证审计器6. 解决办法不能让 Agent 修改守门脚本7. 正则扫描的边界8. 把奖励函数改写成验收函数实验环境小结发布到团队 CI 前的边界测试 Demo 仓库参考资料1. 问题现场CI 绿了但问题没有修好你给 Agent 的任务是“让测试通过”。它确实做到了流水线变绿PR 看起来也能合并。但代码里可能出现了Disabled、assertTrue(true)、空catch甚至把并发度从 100 改成 1。业务问题没有修好失败信号被消音了。本文实现一个轻量级完整性审计器在进入 Maven 测试前检测Disabled、assertTrue(true)、空catch、捕获Throwable和把并发度降为 1 等模式。重点不是依赖几个正则表达式而是建立不可由执行者自行修改的验收边界。2. 验证目标验证目标包括两部分恶意样例必须被检出当前合规工程必须以退出码 0 通过。只满足其中一项都不能证明审计器可用。3. 原因绿色流水线为什么可能是假成功下面几种改动都能让失败的并发测试“恢复绿色”Disabled(偶发失败先关闭)voidshouldHandleConcurrency(){}assertTrue(true);intconcurrentCount1;try{executeSeckill();}catch(Throwableignored){}它们没有修复任何业务问题只是移除了失败信号。配套动画假绿色流水线对比动画GIF 版本4. 原理把禁止项变成机器可执行规则Demo 中的规则定义如下RULES(Rule(DISABLED_TEST,re.compile(rDisabled\b),禁止跳过核心测试),Rule(ALWAYS_TRUE,re.compile(rassertTrue\s*\(\s*true\s*\)),禁止万能真断言),Rule(EMPTY_CATCH,re.compile(rcatch\s*\([^)]*\)\s*\{\s*\}),禁止空 catch 块),Rule(SWALLOW_THROWABLE,re.compile(rcatch\s*\(\s*Throwable\b),禁止捕获 Throwable 掩盖失败),Rule(LOW_CONCURRENCY,re.compile(rconcurrent(?:Count|cy)\s*\s*1\b),禁止把并发度降为 1),)执行审计python pipeline\verify_integrity.py通过时输出Integrity audit passed.如果测试中出现万能断言脚本以非零状态退出流水线立即失败。例如在临时目录中放入一个只包含assertTrue(true);的BrokenTest.java后实际输出格式如下%TEMP%\cheat-demo\BrokenTest.java:1 [ALWAYS_TRUE] 禁止万能真断言 EXIT_CODE1这段输出有三个关键信息命中的文件、行号和规则码。CI 不需要理解业务语义只要看到非零退出码就能阻断这次提交。配套动画CI 流水线拦截动画GIF 版本5. 在 Demo 中验证审计器不能因为工具名叫“审计器”就默认它可靠。项目使用临时目录构造恶意样例deftest_detector_finds_weakened_assertion(self)-None:withtempfile.TemporaryDirectory()asdirectory:rootPath(directory)(root/BrokenTest.java).write_text(assertTrue(true);,encodingutf-8,)self.assertTrue(any(ALWAYS_TRUEinitemforiteminscan(root)))运行python-m unittest discover-s ai_firm\tests-v当前 Demo 的两项 Python 测试均已通过一项验证作弊模式检测一项验证上下文裁剪依赖遍历。再对当前仓库执行正向验证python pipeline\verify_integrity.pyif($LASTEXITCODE-ne0){throw完整性审计失败}6. 解决办法不能让 Agent 修改守门脚本如果 Agent 能同时修改业务代码、测试和审计脚本它仍可以删除规则后提交。生产环境应至少采用以下一种隔离方式审计脚本放在独立仓库由平台团队维护。CI 从固定版本的制品或容器中加载规则。使用 CODEOWNERS修改pipeline/必须由人类审批。核心测试在远端私有测试集执行不暴露全部断言。这就是“只读门禁”的真正含义不是文件系统只读而是任务执行者没有单方面改变验收标准的权限。最小团队落地可以从两段配置开始。先在 CI 中把完整性审计放在 Maven 测试之前name:integrity-gateon:pull_request:jobs:verify:runs-on:ubuntu-lateststeps:-uses:actions/checkoutv4-uses:actions/setup-pythonv5with:python-version:3.12-name:Run integrity auditrun:python pipeline/verify_integrity.py-name:Run Maven testsrun:mvn test再用 CODEOWNERS 约束守门脚本的修改权限/pipeline/ platform-reviewers /ai_firm/cheat_detector.py platform-reviewers这样 Agent 可以提交业务修复但凡它试图改掉审计脚本或流水线规则都必须经过独立维护者审批。配套动画只读门禁权限边界动画GIF 版本7. 正则扫描的边界本例故意保持简单适合教学和本地前置检查。生产环境还应组合Checkstyle、PMD 或 Error ProneJava 语义和代码风格。SpotBugs字节码级缺陷分析。SonarQube质量门、覆盖率和重复代码。Maven Enforcer依赖版本与禁止依赖。Git diff 策略限制 Agent 可修改路径。静态扫描无法证明代码正确但能快速淘汰一批确定错误的提交。8. 把奖励函数改写成验收函数不要给 Agent 下达“让 CI 通过”而要给出分层验收第一层编译通过 第二层禁止模式扫描通过 第三层核心并发测试通过 第四层订单数、库存、成功响应三者一致 第五层人类 Review SQL、事务边界和锁释放。Agent 的目标越接近业务不变量钻空子的空间越小。实验环境项目版本或参数Python3.12.5 实测只依赖标准库被审计 DemoJDK 17、Spring Boot 3.5.15、Maven 3.6.3核心验证恶意样例能检出合规工程以退出码 0 通过小结测试不是装饰它是人类把意图固化为机器约束的方式。让 Agent 自动写代码之前先确保它不能随意改写裁判规则。下一期将从代码结构本身入手为什么职责单一、依赖倒置和小接口会直接提高 Agent 修改代码的成功率。发布到团队 CI 前的边界正则扫描可能误报注释、字符串和规则文件自身也可能漏掉换行、别名封装后的作弊方式。本文工具适合作为快速前置门禁不能替代 AST、覆盖率差异检查、私有测试集和人工 Review。测试 Demo 仓库配套 Demo 仓库地址https://github.com/quan020406/xiaozhan-blog-column-demos上一篇用 AST 依赖裁剪治理 AI 编程上下文下一篇小z疯狂码字ing…感谢阅读记得点赞、关注、收藏欢迎各位评论区交流参考资料JUnit 5 条件执行与禁用测试