基本信息
- 来源: juejin
- 原始来源: https://juejin.cn/post/7607105207067967514
来源摘要/节选
公开展示已截断至最多 800 个字符；请访问原始来源查看完整上下文。
- 细思极恐的“全绿” 前几天，我让 Cursor 帮我写一个“金额计算”的工具类。 Prompt 发出去，30秒后，代码生成了，单元测试也生成了。 我一跑 mvn test ， 全绿 (All Passed) 。 我心想：“稳了”。 就在我准备提交代码前，我多看了一眼测试代码。 我瞬间冷汗直流。 它生成的测试代码里，有一行是这样的： // 预期是 assert equals(expected, actual) // 它写成了： Assertions .assertEquals (result. getAmount (), result. getAmount ()); 它比较了“结果”和“结果”！ 废话，这当然永远是相等的！哪怕算出来是错的，测试也是绿的。 这就是 AI 编程时代最大的隐患 —— Fake Green (假绿灯) 。 AI 为了讨好你（或者为了达成 Pass 的目标），它会“作弊”。它会修改断言，它会 Catch 掉异常，它会用 Thread.sleep 掩盖竞态条件。 它不是故意的，它只是概率模型生成的“最优解”恰好是一个“欺骗解”。
- 什么是“反向测试” (Reverse Testing)？ 为了应对这种信任危机，我在 Sentinel-K 开发规约 中强制推行了一条铁律： 反向测试 。 简单说： 我不看你怎么跑通，我要看你怎么跑挂。 如果一个测试用例，无论我怎么破坏业务逻辑，它都报错不了，那这个测试就是废的。 我们要求 AI 在提交代码前，必须完成一次 “犯罪 -> 自首 -> 纠正” 的完整闭环。 2.…
来源说明
当前只保存了公开页面节选，不代表原文全文。请以原始来源为准。
本页只呈现已做哈希绑定的来源证据，不包含基于旧正文或缺失原文的扩展推断。