AI 代码审查的价值不在于生成一长串“建议优化”，而在于帮助开发者快速找到会影响正确性、安全性和线上稳定性的具体问题。对于 PHP 或 ThinkPHP 项目，最有效的方法是先缩小到本次变更，再按输入、权限、数据和输出四层检查，最后用最小补丁和定向测试证明修复有效。
第一步为什么必须先读变更而不是全仓库扫描
审查应从 git diff、相关控制器、服务类和模型开始。全仓库扫描会引入大量历史问题，让真正与本次需求相关的风险被淹没。先理解调用链和数据流，再扩展到必要的公共函数，可以降低误报并保持修改范围可控。
输入校验要检查哪些边界
重点检查请求字段是否存在类型、长度、枚举和格式限制。图片上传还要校验 MIME、真实图片信息和文件大小，不能只信扩展名。远程 URL 下载需要限制协议、拒绝内网地址并控制重定向，避免 SSRF。JSON 请求体还应设置总体大小上限。
- 整数 ID 使用显式转换并验证资源存在。
- 标题、标签和分类限制最大长度。
- 数组字段确认元素类型并去重。
- 时间字段解析失败时拒绝，而不是默认为当前时间。
权限与鉴权审查如何避免只看“是否登录”
鉴权不仅是检查 Token 存不存在，还要确认这个身份是否有权执行当前动作。发布接口应只暴露创建文章所需能力，而不是把管理员会话或数据库账号交给 Agent。HMAC 签名需要覆盖原始请求体，同时配合时间戳、Nonce、频率限制和可选 IP 白名单。
数据库操作最常见的风险是什么
除了 SQL 注入，还要关注重复写入、部分成功和关联数据不一致。例如文章主表成功而标签关系失败，就可能留下不完整数据。多表更新应使用事务；重复标题应在写入前检查；分类和标签创建要幂等，重复调用不能生成多个同名记录。
输出编码为何同样属于安全问题
文章正文最终进入前台 HTML。审查时要确认模板是否把脚本当文本输出，统计代码是否被错误实体化，以及用户可控字段是否可能注入事件属性。需要保留的 HTML 应经过明确白名单处理，不需要 HTML 的字段则统一转义。
怎样让AI给出可执行的修复
- 要求指出具体文件、函数和触发条件。
- 优先修复根因，不在模板层隐藏后端错误。
- 保持补丁最小，不顺手重构无关模块。
- 为错误路径补充返回值和日志。
- 先运行最接近改动的语法检查或单元测试，再做更广泛验证。
PHP项目定向验证清单
php -l application/common.php
php -l application/common/service/ArticlePublisher.php
git diff --check如果项目有测试，应先运行修改模块对应测试。对于上传和发布接口，还要验证成功、超限、错误签名、重复标题和不可用图片五条路径。不能因为正常路径通过就忽略异常分支。
总结
可靠的 AI 代码审查应当输出“问题位置、影响、触发条件、最小修复和验证证据”。把审查过程固定为读取差异、追踪数据流、分层检查和定向验证，可以显著减少泛化建议，让 Codex 真正参与工程质量保障。
评论 0