这两天我让 AI 编程助手（OpenClaw）给自己的博客程序做了一轮“安全加固 + 性能优化”，它一口气改了 18 个文件、列了 28 项改动，自测写着“全部 PHP 语法检查通过”。看起来很漂亮。但上线前逐行过了一遍 diff，还是揪出了两处会直接伤到线上的问题。这篇把当时的检查流程整理成一份清单，适合所有“让 AI 改完代码就想直接覆盖上传”的人。
先说结论：语法通过 ≠ 能上线
php -l 只能证明代码能被解析，证明不了它的行为和原来一致。AI 的典型问题不是写错语法，而是改对了一处，顺手改坏了另一处它没看到的调用方。所以审查的重点永远是：这个改动影响到谁？
真实案例一：修了 XSS，评论却变成一堆代码
AI 发现评论输出时做了 htmlspecialchars_decode，判断有存储型 XSS 风险，于是直接删掉了解码。方向没错，但它没去看评论入库时的处理：程序会先把换行转成 <br>、把网址转成 <a> 链接，再整体转义存库。删掉解码后，所有评论里的换行标签和链接标签都会原样显示成文字。
正确的做法是“解码 → 只保留 br 和 a 两种标签 → 再过一遍链接协议白名单”，既不丢格式，也挡住 javascript: 之类的注入。教训：改输出之前，先搜一下数据是怎么写进去的。
真实案例二：时区差 8 小时，清理脚本会误删数据
AI 修了一个“统计永远不命中”的 bug，还加了一条 SQL 清理历史重复数据，判断“同一天”用的是 FLOOR(时间戳/86400)。问题在于：这个算法按 UTC 切天，而程序记录的“今天”是北京时间 0 点。北京时间 0 点等于 UTC 前一天 16 点，两套“天”的边界错开 8 小时，清理语句可能把相邻两天的记录当成同一天删掉。
教训：凡是出现时间、日期、86400 的改动，都要问一句“按哪个时区算”。
上线前检查清单
- 先对线上版本：把服务器上的文件和 AI 拿去改的那份源码比一遍哈希。如果线上有过别的修复，直接覆盖会把它们冲掉。
- 只看 diff，不看总结：AI 的改动说明是它“想做的”，diff 才是它“做了的”。
- 每处改动追调用方：函数签名、返回格式、数据库字段，改了就全局搜一遍谁在用。
- 默认值变化要对环境：比如“默认不信任代理头”在安全上是对的，但如果你的站在 Cloudflare 后面，所有访客 IP 都会变成 Cloudflare 的节点 IP，登录失败锁定会误伤所有人，需要显式打开可信代理。
- 别把已删的危险文件传回去：安装脚本
install.php这类文件，线上已经删了就别随包再上传。 - 改库语句先在副本上跑：DELETE、ALTER 一律先备份或在测试库跑。
- 备份 → 语法检查 → 原子替换：先打包旧文件，新文件在服务器上
php -l通过再覆盖。 - 上线后冒烟测试：首页、文章页、后台登录、表单提交、API 签名（正确签名通过、错误签名被拒）都要实际请求一次。
怎么让 AI 少挖坑
- 让它一次只改一类问题，比如这轮只修安全，下轮再做性能，diff 小了才审得动。
- 要求它对每项改动写清“影响到哪些文件和函数”，而不只是“修复了什么”。
- 把你的部署环境告诉它：PHP 版本、Nginx 还是 Apache、有没有 CDN、服务器时区。很多“正确的修复”只在特定环境下才正确。
- 涉及数据删除、权限、支付的改动，坚持人工过一遍。
写在最后
这次 AI 的 28 项改动里，大部分质量其实不错：CSRF 改成随机 token、API 签名升级 HMAC-SHA256、上一篇下一篇从全表扫描改成两条 LIMIT 1 查询，都是实打实的提升。AI 写代码已经很快，但“这段代码在我的服务器上会发生什么”，这个问题还是得你自己回答。
本文由 Lingshi 发布，转载请注明出处。
还没有评论，来说两句吧。