从怀疑到真香——AI 重构代码后，我不再追求“最合适”，而是做好这两件事：测试和优化

感谢博客园同学绅士联盟的关注，最近在在讨论的AI编程的问题，我也想了许多，结合近半年全面AI编程的心得里程来谈谈AI编程这件事儿，希望能对大家有点帮助。

AI 写的代码不一定最合适，但你写的就一定最合适吗？

相信不少人刚开始用 AI 写代码的时候，都会有这个疑虑：AI 生成的代码真的靠谱吗？会不会为了"看起来完整"而加入多余逻辑？会不会在边界场景里埋坑？会不会写屎山代码？

我刚开始也有这个疑虑，毕竟刚开始互联网上满是各种关于AI编程的负面消息，让人不得不持怀疑态度：到底能不能用AI放心的写代码？

但用久了之后，我的想法慢慢变了。

AI 重构后的代码不一定是最合适的，可我们自己手写的代码，也未必就是最优解。 区别在于，AI 掌握的技术方案更多，生成速度更快，还能顺手跑单元测试、梳理回归测试范围，最后告诉你哪些覆盖到了、哪些还缺着。这种效率，很多有十年经验的工程师也未必能稳定做到。

不过，问题也很真实。

根据 2026 年的实测数据，AI 生成代码的初次通过率大约只有 65%，经过人工审核后才能提升到 92% 左右。它确实会写出冗余结构、过度防御、不必要的类或注释；有时还会引入过时 API、重复逻辑，甚至在业务边界上"自信地犯错"。更关键的是，AI 能判断代码"写没写对"，却很难判断它是否"做对了事"。

所以，AI 不是替代者。它更像一套机械战甲：能力很强，但方向盘必须握在自己手里。

AI 真正擅长的，是"快"和"全"

AI 的优势不在于它永远正确，而在于它能快速给出多种方案，并把很多重复性工作自动化。

比如重构一个旧模块时，AI 可以：

• 快速识别重复逻辑；

• 给出几种不同的重构方案；

• 补全单元测试和边界用例；

• 检查命名、注释、异常处理是否统一；

• 梳理哪些文件被影响，哪些测试需要回归；

• 把重构前后差异整理成可读的变更说明。

这些事情如果完全靠人工做，不是不能做，而是成本高、容易漏、耗时间。AI 的价值，就是把这些"应该做但经常被忽略"的工作补回来。

但它也有明显短板。它不一定理解业务背后的真实约束，比如历史兼容、运营口径、数据迁移风险、团队开发习惯、上线窗口和回滚成本。它也可能把一段本来清晰的代码改得更"通用"，却增加了理解成本。

所以，AI 适合做"方案提供者"和"执行加速器"，不适合做最终拍板的人。

质量把控，我主要抓两块：测试和优化

很多人觉得 AI 写代码最大的问题是质量不可控。其实，质量不可控往往不是因为 AI 不能做测试和优化，而是我们没有把它放进流程里。

我现在基本会把 AI 当成一个"初级工程师 + 测试工程师 + 代码审查员"的组合体，但它不能拥有最终决定权。

测试交给 AI，但边界要自己定

单元测试、回归测试、接口测试脚本，AI 都能批量生成；真机测试它也能梳理操作步骤，甚至根据运行截图做初步确认。但测试用例的业务语义、边界条件、异常路径，最好由人先定义清楚。

AI 负责把覆盖率拉满，人负责确认它测的是不是真正重要的东西。

比如一个订单状态流转功能，AI 可以很快写出各种正常流程的测试用例，但"用户取消订单后是否还能支付""库存回滚是否触发通知""并发下单会不会超卖"这类业务边界，通常需要人来明确。AI 很擅长执行，但业务责任不能交给它。

我一般会这样安排测试流程：

1. 先让 AI 列出测试清单：让它根据需求整理正常路径、异常路径、边界条件和回归范围。

2. 人确认关键场景：尤其是涉及资金、权限、状态机、数据迁移、外部接口的部分。

3. 让 AI 生成测试用例和脚本：包括单元测试、接口测试、回归测试步骤。

4. 跑通后让 AI 整理结果：哪些通过、哪些失败、失败原因是什么、需要补充哪些用例。

5. 最后由人做最终确认：不只看"测试是否通过"，还要看"是否测到了真正重要的风险点"。

优化也要分阶段让 AI 自查

AI 反复调试复杂问题时，确实容易带来一些冗余代码。我的做法是：每完成一个功能模块，先让它跑基础单元测试；再让它以"代码审查员"的身份指出可删除、可合并、可简化的部分；最后再按项目规范做一轮重构。

比如：

• 控制方法长度，避免一个函数做太多事；

• 合并重复逻辑，减少复制粘贴式代码；

• 用标准库或成熟方案替换手写实现；

• 检查异常处理是否完整；

• 确认日志、错误码、返回值是否统一；

• 删掉调试代码、无用注释和临时分支；

• 检查是否有不必要的嵌套和过度抽象；

• 确认改动是否影响已有接口和数据结构。

如果项目有特殊要求，比如性能、安全、可维护性、团队规范，也可以直接写进提示词里，让它按约束执行。效果会比"随便让它优化一下"稳定很多。

我通常会分三轮让 AI 优化代码：

1. 第一轮：清理冗余：删除无用代码、重复逻辑、调试输出、过期注释。

2. 第二轮：结构优化：拆分过长函数，提取公共逻辑，统一命名和返回值。

3. 第三轮：规范对齐：按照团队代码规范检查格式、日志、异常处理、接口设计和文档说明。

每一轮都要让它说明"改了什么、为什么改、可能带来什么风险"，这样比直接丢一段重构后的代码更可控。

AI 不是替代者，而是效率放大器

真正好用的方式不是"AI 写完就合并"，而是：

AI 负责方案、生成和自测，人负责取舍、确认和兜底。

一两个月的工程，AI 可能几天就能跑通；各种测试都通过，需求也基本符合。但最后拍板的那个人，还得是你。你要知道哪些代码可以接受，哪些必须重写；哪些地方 AI 已经做得足够好，哪些地方还存在业务风险。

AI 可以帮你写得更快，但不能替你承担后果。它可以指出问题，但不能替你做取舍。它能提升效率，却不能替代判断。

就像漫威里的角色一样，同样的能力，可能造就超级英雄，也可能造就反派。AI 也是一样：用得好，它是机械战甲；用得不好，它也可能把问题包装得更漂亮。

所以，咱别神话 AI，但也别低估 AI。它会犯错，但它确实能显著提升效率；它不能替代人，但能让人把更多精力放在真正重要的判断上。

AI时代，IT界的各种岗位正在被重新定义，我们要拥抱AI、使用AI、驾驭AI，把重复交给工具，把判断留给自己，才能在时代的浪潮中不被取代，甚至能站得更高。