不知道你有没有遇到过这种情况：让 AI 写了一段代码，本地一跑居然通过了，但上线之后却出了事故；或者 AI 给了一个看起来很专业的修复方案，照着改完却发现另一个功能挂了。问题并不一定出在 AI 本身，而在于我们使用 AI 时，丢失了开发者的批判性思维。
AI 编程助手已经成为越来越多开发者的日常工具，但“能跑”和“正确”之间，往往隔着一整条验证链。这篇文章会围绕“使用 AI 但不失去批判性思维”这个主题，先讲清楚为什么 AI 输出不能直接当答案，再拆解四个核心思考原则，最后用一个完整的代码案例展示如何审查和修正 AI 生成的代码。无论你是刚开始用 AI 写代码，还是已经在团队里推广 AI 辅助开发，这篇文章都能给你一份可落地的检查方法。
1. AI 时代，为什么批判性思维反而更重要
1.1 AI 辅助开发已经变成常态
从 GitHub Copilot、Cursor，到各类 AI 编程插件和 Agent 工具，AI 正在深度参与需求分析、代码生成、错误排查、代码审查等环节。它的效率提升是实实在在的：重复样板代码可以秒出，常见框架的写法能自动补全，报错之后还能快速给出排查建议。
但效率提升并不等于质量提升。我在平时 review 代码时发现，很多同学把 AI 的输出直接当作“标准答案”，少了确认、验证和追问的过程。结果就是：一段代码看起来格式规范、注释完整，但业务逻辑是错的，或者依赖了一个根本不存在的 API。
AI 不是搜索引擎，更不是权威文档。它的本质是基于概率的文本生成模型，它给出的代码在“形式上”可能非常专业，但在“事实上”不一定正确。
1.2 什么是“使用 AI 时的批判性思维”
批判性思维不是否定 AI，也不是所有输出都怀疑一遍。它指的是：把 AI 的输出看作是“候选人答案”，而不是“最终答案”。
具体来说，你在接受 AI 输出之前，至少要完成以下几件事：
- 验证：代码能不能编译？测试能不能通过？边界情况有没有覆盖？
- 追问：AI 给出这个方案的理由是什么？它是否了解完整上下文？
- 核验：它提到的 API、配置项、版本号是否真实存在？来源是否可靠？
- 判断：这段代码会对线上产生什么影响？是否有安全、并发、数据一致性风险？
这套流程和代码审查（Code Review）的逻辑一模一样。只是过去我们审查的是同事的代码，现在审查的对象换成了 AI。
1.3 为什么批判性思维容易被丢掉
很多开发者不是没有能力审查 AI 输出，而是“不想查”或者“忘了查”。原因大概有三个。
第一是效率压力。既然 AI 已经帮我们写完了，再花时间去验证，好像违背了使用 AI 的初衷。但实际上，如果 AI 生成的代码有隐藏问题，后期排查的耗时可能是前期验证的好几倍。
第二是信任惯性。AI 生成的内容语气确定、格式完整，天然容易让人放松警惕。尤其当 AI 连续几次给出正确结果后，使用者会形成“它应该没问题”的惯性。
第三是反馈闭环缺失。AI 生成代码后，如果测试覆盖不够，问题不会立刻暴露。等到线上出了故障，你已经很难想起来这段代码是 AI 写的，还是自己写的。
所以，越是用 AI 辅助开发，越需要把“验证”从可选项变成必选项。
2. AI 辅助开发的典型场景与隐藏风险
2.1 场景一：自动生成代码
最常见的用法是：把需求描述给 AI，让它输出完整代码。这个场景的风险点在于 AI 对项目上下文的理解是有限的。
举一个我实际见过的例子。团队里用 AI 生成了一段订单状态更新的代码，AI 直接用了字符串拼接 SQL，看起来逻辑没问题，但一旦订单号来源于外部参数，就存在 SQL 注入风险。而且 AI 并不知道项目里已经统一封装了 BaseMapper，所以生成的代码风格也和现有工程不一致。
代码生成阶段，需要重点检查：依赖的类是否真实存在、是否有合适的异常处理、是否考虑了并发和数据一致性、是否符合团队现有编码规范。
2.2 场景二：错误信息排查
把报错信息粘贴给 AI，让它帮忙分析原因，这是很多开发者的日常操作。AI 确实能提供一些有价值的排查方向，但也存在明显风险。
第一个风险是上下文不足。你只给 AI 贴了一行报错，它并不知道项目用的什么框架、什么版本、什么配置，自然只能给出一个泛泛的答案。第二个风险是“看似合理但方向错误”的建议。AI 可能会引导你去改一个根本没问题的配置，反而把问题带偏。
正确做法是：先自己看完整堆栈，想清楚报错发生的位置和触发条件，再拿这些信息去和 AI 讨论。AI 可以当排错助手，但不应该当“背锅侠”。
2.3 场景三：代码审查与重构建议
用 AI 做代码审查，可以发现一些重复代码、命名不规范、结构臃肿的问题。但 AI 的审查缺乏业务语义，它不知道哪些逻辑是客户要求的硬性约束，也不知道哪些看似冗余的判断是为了兼容历史数据。
我见过一个例子，AI 建议把一个字段的非空校验删掉，理由是这个字段在数据库层已经设置了 NOT NULL。单看代码确实没问题，但业务方反馈说这个接口经常被外部系统调用，非空校验是为了在入口层提前拦截异常数据，而不是等数据库报错。AI 的建议虽然合理，却忽略了业务背景。
所以，AI 的重构建议可以参考，但最终是否采纳，必须结合你对业务的理解来判断。
2.4 场景四：技术方案设计
更高阶的用法，是让 AI 帮忙做技术选型和方案设计。这个场景的风险最大，因为方案设计需要结合现有系统、团队能力、运维成本和长期演进，而这些信息 AI 一无所知。
更需要注意的是，AI 在描述技术方案时非常自信，甚至会编造一些不存在的特性对比。如果你只依赖它的输出做决策，很可能会被带偏。涉及方案选型时，必须去查官方文档，看版本差异，甚至做最小原型验证。
3. 保持批判性思维的四个核心原则
3.1 原则一：验证优先，把 AI 输出当“待验证代码”
我给团队定的规矩是：AI 生成的代码，默认状态是“待验证”，而不是“可提交”。验证不是随便跑一下，而是带着问题去验证。
拿到 AI 输出的代码后，我会按顺序问自己几个问题：
- 这段代码能编译通过吗？
- 核心逻辑有没有单元测试覆盖？
- 边界条件（空值、超长、重复请求）有没有处理？
- 是否存在并发访问时数据不一致的问题？
- 有没有安全漏洞（注入、越权、敏感信息泄露）？
只要有一个问题没有明确答案，就不应该合并到主干代码。你可以把这些问题做成一份审查清单，每次用 AI 生成代码后逐项打勾。
3.2 原则二：保持追问，让 AI 给出依据而不是结论
很多人在和 AI 协作时，只问“怎么做”，不问“为什么”。比如：
- 不推荐：帮我写一个分页查询。
- 推荐：我要实现一个分页查询，但不确定用 limit 还是游标分页，表有 500 万数据，请对比两种方案在深分页场景下的性能差异，说明原理。
当你要求 AI 给出依据时，它不一定会完全正确，但这个“追问”的过程会促使你思考：这个方案成立的前提是什么？在什么条件下会失效？有没有更合适的替代方案？
把 AI 当作一个可以随时讨论的同事，而不是一个输出机器。这样你才能在协作中保持主动思考。
3.3 原则三：明确边界，知道哪些事不能交给 AI
AI 可以帮你生成代码、整理文档、梳理思路，但有些事情必须由人来负责：
- 业务规则的正确性判断：AI 不知道业务方的真实意图。
- 安全与合规决策：涉及认证、授权、数据删除、生产变更的方案，必须人工审查。
- 生产环境的变更操作：AI 给出的命令不能直接在生产环境执行。
- 最终质量责任：无论代码是不是 AI 写的，出了问题，责任在提交代码的人。
这一点尤其重要。很多团队出现线上事故后复盘，发现代码是 AI 写的，但没有人真正 review 过。责任感不能因为引入了 AI 工具就转移。
3.4 原则四：建立反馈闭环，用结果验证思考
批判性思维不能只停留在“我觉得有问题”，要落到反馈闭环上。
完整的反馈闭环包括：AI 产出代码 → 人工审查 → 自动化测试 → 代码合并 → 灰度发布 → 线上监控。每一环都在验证前一步的判断是否正确。
如果代码经过测试没发现 bug，不代表它一定正确，只能说明测试覆盖到的场景没有出问题。所以在关键业务上，我会要求补充更多异常场景的测试，比如重复请求、并发提交、依赖服务超时等。
4. 实战案例：一次 AI 生成代码的批判性审查与修正
光讲理论不够，下面用一个完整的案例，演示怎么用批判性思维审查 AI 生成的代码。
4.1 案例背景
假设我们有一个订单支付回调接口。第三方支付平台在用户完成支付后，会回调我们的系统，通知订单支付成功。你让 AI 生成一段处理逻辑，它给出了下面的代码。
4.2 AI 生成的第一版代码
// 文件路径：src/main/java/com/example/order/OrderPayService.java @Service public class OrderPayService { @Autowired private JdbcTemplate jdbcTemplate; public void handlePayCallback(String orderId, double amount) { Order order = queryOrder(orderId); if (order == null) { throw new RuntimeException("order not found"); } // 直接更新订单状态为 PAID String sql = "UPDATE t_order SET status = 'PAID', amount = " + amount + " WHERE order_id = '" + orderId + "'"; jdbcTemplate.execute(sql); } private Order queryOrder(String orderId) { String sql = "SELECT * FROM t_order WHERE order_id = '" + orderId + "'"; return jdbcTemplate.queryForObject(sql, Order.class); } }这段代码从语法上看没有问题，但用批判性思维审查一遍，问题非常多。
4.3 批判性审查：逐条发现问题
我把审查过程拆成几个问题，对应前面提到的核心原则。
问题一：是否存在安全漏洞？
queryOrder和handlePayCallback都使用了字符串拼接 SQL。如果orderId来自外部请求，攻击者可以构造恶意参数，造成 SQL 注入。即使在实际场景中订单号可能来自内部签名校验之后，这种写法仍然是高危反模式。
问题二：金额字段类型是否合理？
amount使用了double。金额计算在 Java 中推荐使用BigDecimal，因为double存在精度丢失问题。比如0.1 + 0.2在二进制浮点数中就不是精确的0.3。涉及真金白银的业务，绝对不能这样写。
问题三：状态流转是否可控？
代码直接把状态更新为PAID，没有检查订单当前的支付状态。如果支付平台因为网络原因重复回调，这段代码会把已经取消的订单重新置为已支付，或者重复处理两次回调。
问题四：并发场景下是否安全？
如果两条回调请求同时到达，两个请求都查询到订单状态是UNPAID，然后都执行更新，就可能出现重复处理。代码里没有任何乐观锁或版本号机制。
问题五：异常处理是否合理？
代码抛出的是RuntimeException，外部无法区分“订单不存在”“状态异常”“金额不一致”等不同情况，也就无法针对业务异常做差异化处理。
问题六：是否缺少幂等控制？
支付回调天然是幂等敏感的。一个健壮的系统，必须保证同一笔支付回调即使被通知多次，也只生效一次。
4.4 修正后的代码
针对上面的问题，修正后的代码应该做到：使用参数化 SQL 防注入、金额使用 BigDecimal、增加状态机校验、使用乐观锁防止并发重复处理、区分业务异常与系统异常、补充完整日志。
// 文件路径：src/main/java/com/example/order/OrderPayService.java @Service @Slf4j public class OrderPayService { private final JdbcTemplate jdbcTemplate; public OrderPayService(JdbcTemplate jdbcTemplate) { this.jdbcTemplate = jdbcTemplate; } @Transactional public void handlePayCallback(String orderId, BigDecimal amount) { // 1. 参数校验 if (orderId == null || orderId.isBlank()) { throw new IllegalArgumentException("orderId 不能为空"); } if (amount == null || amount.compareTo(BigDecimal.ZERO) <= 0) { throw new IllegalArgumentException("amount 必须大于 0"); } // 2. 查询订单，使用参数化 SQL 防止注入 Order order = queryOrder(orderId); if (order == null) { throw new BusinessException("订单不存在"); } // 3. 状态校验：只有 UNPAID 状态才能流转到 PAID if (!"UNPAID".equals(order.getStatus())) { throw new BusinessException("当前订单状态不允许支付回调处理"); } // 4. 金额校验：回调金额必须等于订单应付金额 if (amount.compareTo(order.getPayAmount()) != 0) { throw new BusinessException("回调金额与订单金额不一致"); } // 5. 乐观锁更新，防止并发重复处理 int rows = jdbcTemplate.update( "UPDATE t_order SET status = ?, pay_time = ?, version = version + 1 " + "WHERE order_id = ? AND status = 'UNPAID' AND version = ?", "PAID", LocalDateTime.now(), orderId, order.getVersion() ); if (rows != 1) { throw new BusinessException("订单状态已变化，请勿重复处理"); } // 6. 记录处理日志 log.info("支付回调处理成功, orderId={}, amount={}", orderId, amount); } private Order queryOrder(String orderId) { String sql = "SELECT order_id, status, pay_amount, version FROM t_order WHERE order_id = ?"; return jdbcTemplate.queryForObject(sql, new BeanPropertyRowMapper<>(Order.class), orderId); } }对应的表结构可以这样设计：
CREATE TABLE t_order ( id BIGINT AUTO_INCREMENT PRIMARY KEY, order_id VARCHAR(64) NOT NULL UNIQUE, status VARCHAR(16) NOT NULL, pay_amount DECIMAL(12,2) NOT NULL, version INT NOT NULL DEFAULT 0, pay_time DATETIME NULL, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP );4.5 用测试验证修改结果
修正代码只是第一步，还需要用测试验证行为。下面是核心测试思路：
// 文件路径：src/test/java/com/example/order/OrderPayServiceTest.java @SpringBootTest class OrderPayServiceTest { @Autowired private OrderPayService orderPayService; @Test void shouldRejectWhenOrderAlreadyPaid() { // 准备：数据库中订单 status = 'PAID' // 执行：再次调用 handlePayCallback // 断言：抛出 BusinessException，且订单金额没有被修改 } @Test void shouldRejectWhenAmountNotMatch() { // 准备：数据库中订单 pay_amount = 100.00 // 执行：传入 amount = 99.99 // 断言：抛出 BusinessException } @Test void shouldUpdateSuccessWhenStatusIsUnpaid() { // 准备：数据库中订单 status = 'UNPAID' // 执行：调用 handlePayCallback // 断言：订单状态变为 PAID，version 加 1 } }测试注释里的“准备”“执行”“断言”需要结合你实际的测试数据库来补齐。你可以使用 H2 内存数据库，也可以使用 Testcontainers 启动一个真实的 MySQL 容器。无论用哪种方式，目的都是一样的：用可重复的自动化测试，把“批判性审查”沉淀成机器可执行的验证。
5. 把批判性思维落实到日常工作流
5.1 需求输入：给 AI 足够的上下文
很多人抱怨 AI 生成的代码不符合预期，其实问题出在提问太宽泛。AI 不了解你的技术栈、版本、业务约束和代码风格，自然只能生成“通用答案”。
推荐你用一个结构化的提问模板：
我正在使用 [框架名 + 版本]，数据库为 [数据库类型 + 版本]，需要实现 [功能描述]。 约束条件： 1. [业务规则，例如“只有 UNPAID 状态可以流转到 PAID”] 2. [技术约束，例如“金额使用 BigDecimal”“SQL 必须参数化”] 3. [异常处理要求，例如“区分业务异常与系统异常”] 请输出： 1. 核心代码实现 2. 关键设计思路 3. 可能出现的边界情况把上下文交代清楚，AI 的输出质量会明显提升。更重要的是，这个写 prompt 的过程本身，就是在梳理你对需求的理解。
5.2 产出审查：把 AI 输出当“第一轮草稿”
无论 AI 输出多完整，都建议遵循一个固定的审查流程：
- 编译检查：确认代码能通过编译。
- 逻辑走查：逐行读一遍，看是否有明显逻辑错误。
- 边界测试：补充空值、重复请求、并发场景的测试。
- 安全审查：检查注入、越权、敏感信息泄露等风险。
- 业务确认：与需求方核对业务规则是否符合预期。
这个流程不需要每次都完整跑一遍，但至少前两项应该是默认动作。如果你用 AI 生成的是 SQL，一定要额外执行 EXPLAIN 查看执行计划；如果你用 AI 生成了配置文件，要确认每一项配置在目标环境有实际效果。
5.3 验证闭环：用自动化测试兜底
在团队里，我特别强调“用测试约束 AI 输出”。具体做法是：先写测试用例，再让 AI 去实现。如果你先让 AI 写实现，再补测试，很容易跟着实现思路走，测试的独立性会被削弱。
比如要实现一个订单金额计算功能，你可以先把下面的测试思路贴给 AI：
// 测试要求 // 1. 空订单列表返回 0 // 2. 单笔订单金额正确汇总 // 3. 含优惠金额时，最终金额不超过订单总额 // 4. 金额保留两位小数，且不丢失精度有了明确的测试约束，AI 生成的代码会更有针对性。而你在审查时，也拥有了可验证的标准。
5.4 记录沉淀：把 AI 踩坑经验变成团队规范
每一个被 AI 坑过的瞬间，都值得变成一条规范。比如：
- 凡是涉及金额的代码，必须使用 BigDecimal。
- 凡是外部回调接口，必须有幂等控制。
- 凡是 SQL，必须使用参数化查询或 ORM 封装方法。
- 凡是删除或更新操作，必须先备份或验证 WHERE 条件。
这些规范可以写在团队的开发文档里，也可以做成代码审查清单。当你从“个人经验”上升到“团队规范”时，AI 辅助开发的整体质量才会有质的提升。
6. 常见问题与排查思路
以下是我在团队推广 AI 辅助开发时，经常遇到的问题和排查思路：
| 问题现象 | 可能原因 | 解决思路 |
|---|---|---|
| AI 生成了不存在的 API | 模型基于训练数据中的过时知识生成内容 | 到官方文档核对类名、方法签名，锁定实际依赖版本 |
| AI 修复建议掩盖了根因 | 上下文不足，AI 只看到了局部代码 | 贴完整日志和代码，要求 AI 分析根因，不要只给“绕过方案” |
| 自己 review 了但线上还是出问题 | 审查清单不完整，缺少并发、安全、幂等视角 | 引入标准审查清单，覆盖数据一致性、安全、异常处理 |
| AI 代码风格和项目不一致 | 没有在 prompt 中指定项目规范和约束 | 在 prompt 中声明包结构、框架、统一返回类等规范 |
| AI 推荐了一个很新的依赖但没人用过 | 模型倾向给出“看起来先进”的方案 | 以官方文档和团队已用技术栈为准，先做技术小样验证 |
| 测试通过但代码有隐藏 bug | 测试主要覆盖正常路径，缺少边界用例 | 补充异常场景测试：重复请求、空值、超时、并发 |
排查时有一个很重要的原则：永远不要因为“AI 说没问题”就直接跳到下一步。验证的终点是代码运行结果和线上监控数据，而不是 AI 的结论。
7. AI 协作的工程最佳实践
7.1 个人层面：把验证变成肌肉记忆
我建议每个使用 AI 编程的人，给自己定三条强制规则：
- 第一，AI 生成的核心代码，必须手写对应的核心测试。
- 第二，涉及金额、权限、删除、更新的代码，必须经过一次完整走查。
- 第三，AI 给出的配置项，必须去官方文档确认之后再写入工程。
这三条规则不需要别人监督，但能在关键时刻挽回损失。
7.2 团队层面：建立 AI 辅助开发规约
如果团队已经重度使用 AI 编程工具，建议把规则写成文档，让全员遵守：
- AI 生成的代码必须经过人工评审，禁止跳过 Code Review 直接合并。
- 涉及安全敏感操作的代码，至少需要一名高级工程师审查。
- AI 生成的 SQL 必须查看执行计划，禁止直接在生产环境执行。
- 关键接口必须补充幂等、并发、异常场景测试。
- 生产环境的任何变更，必须经过人工复核和备份验证。
这些规约不是限制开发效率，而是保证在 AI 辅助开发的高效之下，依然保有质量底线。
7.3 安全边界：不能完全交给 AI 的环节
有几类工作，我建议永远不要全权交给 AI，哪怕它看起来表现很好：
- 权限模型的设计：认证、授权、越权判断这类逻辑，必须人工确认。
- 数据删除与批量更新：AI 给出的 SQL 可能漏了 WHERE 条件，风险极高。
- 加密密钥与密钥存储：涉及生产敏感信息，必须有专门的安全方案。
- 生产环境操作命令：任何 rm、drop、update、restart 操作前，都要人肉二次确认。
AI 在这些环节可以作为辅助，提供思路和检查清单，但最终决策和执行必须由人负责。
7.4 可维护性：让 AI 输出更容易被审查
最后提一个容易被忽略的点：AI 的代码能不能被高效审查，和代码本身的可读性直接相关。
让 AI 生成代码时，明确提出这些要求：
- 函数尽量拆小，一个函数只做一件事。
- 命名清晰，避免 a、b、temp 这种无意义命名。
- 错误信息描述具体，便于定位问题。
- 核心逻辑加注释，说明设计原因而不是重复代码行为。
- 不引入项目中没有使用过的新依赖，除非经过评审。
可读性好的代码，审查效率高，出错的概率也低。
8. 总结：AI 不会替你思考
回到文章标题：用 AI，但不失去批判性思维。这句话的本质是——AI 可以帮你写代码、查资料、排查错误，但它不会替你承担思考的责任。
AI 输出的每一段代码，都值得你像一个严格的 Code Reviewer 那样去审视。你可以信任它，但信任的前提是验证。你可以依赖它，但依赖的边界取决于你对业务、安全、架构的理解深度。
下一步，你不需要学什么高深的新技术，只需要从今天开始，给 AI 的每一个输出养成“先验证、再使用”的习惯。可以准备一份自己的审查清单，也可以把你踩过的 AI 坑写在评论区，让更多人避雷。
真正决定代码质量的，永远不是生成它的人或工具，而是提交它在审查时有多认真。
