「让 AI 写一段代码」已经不难，难的是判断这段代码能不能上线。模型给出来的东西通常语法通顺、看着像对，但放进真实项目、真实数据和真实并发才暴露问题。下面按我们在深圳做外贸独立站、小程序和企业定制时真的审到过的坑来写，不编造「AI 提效百分之多少」这类无法核对的数据。
一、幻觉：不存在的函数、参数和配置项
最典型的一类。语法完全合法，一运行就报错，因为它调用的方法在真实库里根本不存在，或者参数顺序、参数名是编的。
- 调用了 SDK 里没有的方法，名字却和真方法很像。
- import 一个不存在的包，或者写了文档里查不到的配置项。
- URL、回调字段、环境变量名凭印象生成，接口对接时才炸。
处理办法：在真实环境跑一遍，不要只读 diff。不确定的接口回官方文档核对；把版本号一起给模型，不要让它自由发挥。
二、版本错位：训练数据停在旧版本
模型见过大量旧代码，容易写出已废弃的写法：老版本的框架 API、旧版依赖、已经改名的函数。单文件看没问题，装进你现在的项目就冲突。
处理办法：把项目的 package.json / composer.json 和 lock 文件给它看，明确「按这个版本写」。升级框架单独开一轮，不要和业务功能混在同一次改动里。
三、看着对、逻辑错：边界与精度
这类最难查，因为代码能跑通正常路径，出错的是边缘情况。
- 分页、循环的 off-by-one，列表少一条或多一条。
- 金额用浮点相加，对账差几分钱。
- 时区、字符编码、空数组和
null没处理，线上偶发。 - 注释写得很自信，实际和代码行为不一致。
处理办法：把正确样例和反例一起给它，让它先写测试再改实现。涉及钱、时间、权限的逻辑，人必须复核。
四、静默失败：错误被吃掉
空 try/catch、catch 之后 return null 或直接忽略、不检查接口返回码，都属于这一类。代码不崩，但事情没做成，线上还查不到日志。
处理办法：要求错误必须被记录或抛出，不允许静默吞掉；关键路径加日志和告警。生成代码时明确「失败要可见」。
五、安全类坑：最不能省人工的一环
这是 AI 生成代码里最危险的部分，因为漏洞通常藏在细节里。
- 字符串拼接 SQL，而不是参数化查询或 ORM。
- 把用户输入直接渲染进页面，形成 XSS。
- 把密钥、数据库密码、API Key 硬编码进代码，甚至提交进仓库。
- 为了「先跑通」关掉权限校验、验证码，CORS 直接开成
*。 - 从网上抄来的片段夹带后门或挖矿脚本。
处理办法：密钥一律走环境变量，绝不入库；查询走参数化；上线前跑一遍依赖与静态安全扫描。任何模型的「这段很安全」都不能替代审查。
六、依赖膨胀与供应链风险
AI 习惯「能跑就行」，为一个小功能引入一个大包，或者重复造轮子、装上早已不维护的库。包越多，攻击面和维护成本越大。
处理办法：装依赖前问一句「能不能用现有代码或标准库」；定期看依赖告警和更新记录。
七、「完成」不等于测试通过
模型说「已实现」时，往往只代表代码写完了，不代表跑过。重构时还可能改坏别的地方。
处理办法：把「通过测试」作为完成定义；改动小步提交，便于回滚；让 AI 补测试路径，但用例的正确性由人认定。
八、上线前人工审查清单
- 在真实环境跑过，不只读 diff。
- 接口、版本按项目实际核对，没有幻觉调用。
- 边界、金额、时区、空值有覆盖。
- 错误可见，没有静默吞异常。
- 密钥不入库，权限没被关掉。
- SQL 参数化，输出做转义。
- 依赖没有明显多余和高风险项。
- 测试通过、能回滚、有部署说明。
九、把 AI 放在流水线的哪一段
稳妥的分工是：人定目标、架构与验收标准，AI 负责起草、改多文件和加快联调，安全与上线由人兜底。这样既能提速，又不会把风险留给客户。
我们做外贸独立站、AI 小程序和企业定制时按这个方式协作，交付源码、数据库和部署说明，放在客户自己的服务器。相关口径见源码交付说明。有存量项目想让 AI 加速改造，或需要排查生成代码的质量问题，把清单发到联系页，或来电 0755-28896137。深圳客户可到龙华当面把范围摊开。