PHP代码审查如果只依赖人工，很容易在业务逻辑纠缠中漏掉类型错误、未初始化变量和潜在的注入路径。引入静态分析工具后，规则类问题可以被自动识别，但工具报出的告警往往数量庞大，尤其是老项目第一次接入时会发现成千上万条历史问题。这时直接让开发者逐条处理并不现实，AI的作用不是替代静态分析，而是帮助过滤噪音、解释告警成因、甚至生成修复补丁。理解了这一点，集成方案的设计目标就清晰了：让机器处理机器擅长的事，让人类聚焦业务正确性。
一个典型的组合是PHPStan负责类型检查和规则校验，AI模型负责对告警上下文做语义判断，例如判断某个$_GET参数是否已经过足够的安全过滤，或者某个array_key_exists检查之后是否真的不会触发未定义索引。静态分析器给出精确的代码位置和规则编号，AI则结合周边代码生成自然语言解释与修复建议。两者输出合并后，再通过CI评论或本地钩子推送给开发者，可以显著降低审查负担。
静态分析基线：让历史问题不干扰新提交
老项目接入PHPStan时，最常见的阻力是告警太多。如果没有任何基线机制，开发者会直接被大量历史遗留问题淹没，最后只能选择关闭工具。比较合理的做法是先生成一份基线文件，把当前所有已存在的错误记录下来，后续仅对新增或修改代码触发告警。PHPStan原生支持baseline，通过phpstan analyse --generate-baseline命令可以生成phpstan-baseline.neon。Psalm也可以用--set-baseline达到类似效果。
基线文件本身值得纳入版本控制，但需要注意的是，基线里面只记录了错误摘要和文件位置，不包含代码上下文。如果某段代码被移动或者重构，基线中的路径可能会失效，导致告警重新冒出来。因此在CI中最好是先运行基线校验，再运行增量分析。对于新写入的代码，CI管道可以强制要求不允许向基线文件追加新条目，这样能保证新增问题必须被修复，而不是顺手又塞进基线里。
下面是一个典型的PHPStan基线生成与校验配置，使用phpstan.neon引用基线文件：
includes:
- phpstan-baseline.neon
parameters:
level: 5
paths:
- src
- tests
tmpDir: var/phpstan
checkMissingIterableValueType: false
在CI脚本里可以先执行vendor/bin/phpstan analyse --memory-limit=1G，如果存在未被基线覆盖的新增错误，进程会返回非零退出码，阻断合并请求。此时再把AI集成进来，让AI读取失败日志并自动为每个告警附带简短的修复建议，开发者就不必在终端和代码编辑器之间来回切换。
AI辅助审查的输入设计与提示策略
要让AI在代码审查中真正发挥作用，输入构造比模型本身更重要。直接把整个文件丢给模型，不仅token消耗大，而且模型容易丢失对具体告警位置的注意力。更好的做法是把告警信息作为锚点，截取告警行前后20到40行代码，再加上文件路径、规则编号和错误描述，形成结构化的提示词。例如PHPStan报出Offset 'id' might not exist on array时，提示词可以包含该数组的初始化语句和相关条件判断，让模型判断是否存在False Positive。
提示词中可以要求AI输出固定格式，比如先给结论是否为误报，再给风险等级，最后给修复建议。不要在提示词里要求模型直接修改整个文件，那样容易引入无关改动。更稳健的方式是让AI生成补丁片段或者仅输出诊断结论，由开发者确认后再提交。这也是很多团队在CI评论机器人里采用的模式：AI只负责解释和建议，不直接写入代码库。
以下是构造提示词的一段PHP示例，展示如何通过循环读取PHPStan的JSON输出并生成待分析列表：
<?php
$report = json_decode(file_get_contents('phpstan-report.json'), true);
foreach ($report['files'] as $file => $fileReport) {
foreach ($fileReport['messages'] as $message) {
$context = file_get_contents($file);
$lines = explode("\n", $context);
$start = max(0, $message['line'] - 20);
$length = 40;
$snippet = implode("\n", array_slice($lines, $start, $length));
echo sprintf(
"文件: %s\n行号: %d\n规则: %s\n信息: %s\n代码片段:\n%s\n\n",
$file,
$message['line'],
$message['identifier'] ?? 'unknown',
$message['message'],
$snippet
);
}
}
这段代码把PHPStan输出中的每个告警提取出来，并截取上下文供后续AI接口调用。生产环境中可以把echo替换成HTTP请求发送给本地或远程模型服务，但要注意不要把包含敏感业务逻辑的代码片段发送到不可信的外部API。
将AI与静态分析集成进CI管道
集成的关键节点是CI流水线中的静态分析步骤。常见做法是分成两个阶段：第一阶段运行PHPStan或Psalm，把结果输出为机器可读格式，如JSON或Checkstyle；第二阶段由AI处理这些结果，生成评论并发布到代码托管平台的合并请求页面。如果使用GitHub Actions，可以在pull_request事件中触发，并通过actions/github-script调用API发布评论。
一个简化的GitHub Actions工作流片段如下，展示如何先跑PHPStan再调用AI脚本：
name: php-review
on:
pull_request:
paths:
- '**.php'
jobs:
static-analysis:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Setup PHP
uses: shivammathur/setup-php@v2
with:
php-version: '8.2'
tools: composer
- run: composer install --no-interaction --prefer-dist
- name: Run PHPStan
run: vendor/bin/phpstan analyse --error-format=json --no-progress > phpstan-report.json
continue-on-error: true
- name: AI review comments
run: php scripts/ai-review.php phpstan-report.json
这里使用continue-on-error: true让PHPStan的失败不会阻断后续AI步骤，但最终是否允许合并需要根据实际策略决定。比较严格的做法是AI脚本执行完毕后，再根据修复建议覆盖率和严重告警数量设置门禁。还可以把AI生成的分析结果写入一个artifact，方便后续人工查看完整上下文。
除了CI管道，本地开发阶段也可以利用Git钩子做轻量集成。例如在pre-commit钩子中只对暂存的PHP文件运行php -l和快速规则检查，如果通过再触发一个异步AI审查任务，这样能在提交前发现低级错误，又不至于拖慢提交速度。但本地钩子无法强制所有成员使用，因此不能替代CI门禁。
效果评估与常见误报处理
引入AI后，最大的挑战不是漏报而是误报。AI模型有时会把代码风格问题误判为安全漏洞，或者对动态生成的数组给出过度自信的错误提示。要控制这一点，可以在AI输出中要求提供置信度，并设置阈值来区分自动评论与仅记录日志。例如模型给出的结论为高危且置信度高于0.8时才自动发布评论，其他情况仅保存到内部审计记录中。
另一个常见问题是模型对PHP动态特性的理解不足。PHP中的__get、__call、ArrayAccess以及可变变量$$name，都可能让静态分析器和AI同时感到困惑。静态分析器通常可以通过@phpstan-ignore或更精细的类型注解来消除误报，AI则可以在提示词中给出这些注解的上下文，让模型先判断是否属于动态调用场景，再决定是否给出告警。这样既能减少无意义评论，也能保留真正有价值的发现。
为了衡量集成效果，建议记录三个指标：告警总量、AI自动关闭的告警比例、开发者手动确认的修复比例。运行一到两个迭代后，可以对比引入AI前后的平均审查时间和线上缺陷密度。如果AI只是增加了评论数量而没有降低缺陷，说明提示策略或模型选择存在问题，需要调整截取上下文的范围或让模型先学习项目的类型约定。
最后还要注意代码隐私与合规。静态分析通常在本地CI环境执行，结果不会被外传；而调用外部AI服务时，代码片段会离开你的基础设施。对于涉及商业机密的项目，优先选择本地部署的开源模型，或者对发送给外部服务的代码做脱敏处理，如暂时替换字符串字面量和变量名为占位符。安全与效率之间需要根据实际风险做出取舍。
