AI编程实战：3个落地技巧、5个坑，别让AI改坏你的工程
开篇：周三晚上十点，AI给你挖了三个坑
周三晚上十点，你让AI“给订单列表加个导出功能”。它哗哗返回一百多行代码，看起来挺像回事。你复制进项目，编译报错：CsvWriter 找不到。你让它修，它换了个依赖，又报错。你手动改到能跑，单元测试红了三片。第二天代码评审，同事指着 diff 问你：“权限注解怎么没了？”
这个场景不罕见。用AI写代码，很多人卡在两个误区里。
误区一：把AI当自动补全，期待一句话生成可上线代码。 它更像手速极快、但没上过你生产环境的实习生。你不给它边界，它就自由发挥。
误区二：把AI当背锅侠，出了问题只怪模型。 真正的问题常在于：你没给验收标准，没做小步提交，没把测试和代码一起管起来。
下面拆3个能直接照搬的技巧、5个高频坑，再复盘一个真实项目。
一、高效实战技巧：3个方法，照做就能少返工
1.1 先画“不可越界地图”，再让它写代码
AI 最容易犯的错，是热情过头：你让它改一个方法，它顺手重构三个类。
操作步骤：
- 列出本次涉及的文件清单，标清各自职责。
- 贴出接口契约、数据库表、依赖版本。
- 写“禁止改动清单”：不改方法签名、不删注解、不新增依赖、不格式化无关代码。
- 要求它先输出改动计划，不写代码。你确认后，再单文件生成 diff。
案例：我给订单导出接口加时间范围筛选。AI 第一版想改 Controller、Service、Mapper、DTO、XML。我限定：只改 Service 和 DTO，Mapper 复用现有方法，Controller 参数已经存在。结果一次编译通过，diff 只有 37 行。
前提条件：你得先知道自己的工程边界。连你都不清楚哪些不能碰，AI 更不可能清楚。
【金句：AI写代码前，先把“不能碰什么”说清楚，比夸它“你很专业”有用得多。】
1.2 先补特征测试，再让AI动刀
老项目最怕改出内伤。你要重构优惠券计算、订单状态机、对账逻辑，先别让 AI 直接改实现。
操作步骤：
- 对要改的函数写现状测试，覆盖正常值、空值、边界值。
- 跑绿，确认测试反映当前行为。
- 把测试文件和函数一起发给 AI。
- 要求只输出最小 diff，每改一轮跑一次测试。
案例：优惠券叠加规则重构，我先补了12条用例，包含过期券、门槛刚好、互斥券。AI 改完后测试全绿，我才让它继续优化可读性。没有这些测试，它把“满减和折扣不能同享”改成“可叠加”，你未必能第一时间发现。
【金句：测试不是写给AI看的，是给未来的你留的刹车片。】
1.3 小步 diff + 人工做“最后一公里”
别让 AI 一次性改八个文件。每次只改一个函数，控制在20到50行。要求统一 diff 格式，你逐块看。
重点审查：
- 空值和类型转换。
- 事务边界。
- 并发与幂等。
- 日志、权限、埋点。
案例：修复订单查询空指针。AI 建议全局 try-catch，我拒绝，只在参数解析处判空。它不懂你的业务边界，只知道“别抛异常”。
注意事项：AI 生成的代码能编译，只代表语法过关，不代表业务过关。
【金句：让AI踩油门，但方向盘和刹车必须在你手里。】
二、高频避坑要点：5个坑，踩一次疼一次
2.1 幻觉 API 和依赖
现象：调用不存在的方法，引入你项目里没有的包。
危害：编译失败，或者隐藏依赖进生产。
规避：把 pom.xml、package.json、内部 SDK 签名贴给 AI。要求“只使用现有依赖和方法”。先编译，再谈逻辑。
2.2 改坏原有工程
现象：顺手重命名、删日志、改注解、调整导入顺序。
危害：线上行为变化，review 成本暴涨。
规避：提示词写明“禁止扩大
