Rust打造的AI辅助PHP引擎通过17%测试，可运行WordPress

背景

一位自称不懂 Rust 的程序员，利用 AI（可能是类似 Claude 或 GPT 的代码生成模型）从头实现了一个用 Rust 编写的 PHP 解释器，名为 Phargo。该项目不包含任何 PHP 官方源代码，而是完全由 AI 生成代码，人类仅负责设定目标、审查错误并决定是否通过。目前，Phargo 已通过 PHP 官方测试套件 22,037 个测试中的 3,844 个（17.4%），并且能够成功渲染一个 WordPress 页面（包括前端和管理仪表盘）。作者将此视为一场「彻底诚实」的实验：用第三方测试套件作为唯一评价标准，避免 AI 自己给自己打分。

核心内容

项目定位与工作方式

Phargo 是一个用 Rust 编写的、从零开始的 PHP 解释器。作者本人不会 Rust，从未写过词法分析器，也无法解释「树遍历求值器」是什么。他的角色被类比为「中世纪的国王审视海图——庄严地点头，零理解，然后打出现代软件开发中最强大的语句：'looks good, continue.'」

核心工作循环极其简单：

1. AI 运行整个测试套件的失败直方图，找到可以修复的最大的失败聚类。
2. AI 实现修复。
3. 运行约 22,000 个测试（约 7 分钟）。
4. 如果通过数增加，提交、推送、重复；如果通过数减少，作者说另一句台词：「嗯，退步了，再看一遍。」

测试套件作为唯一 Oracle

PHP 官方测试套件包含约 22,000 个 .phpt 文件，由 PHP 内部团队三十年来编写。这些测试覆盖了语言的各种角落，包括 DateTime 的夏令时计算、var_dump() 对浮点数的输出格式等。作者认为，这个套件无法被讨好、协商或提示出更好的情绪——它要么通过，要么不通过。由于测试套件中约 40-45% 的测试涉及 C 扩展（如 GD、curl、SOAP、intl、MySQL 驱动等），这些超出了 Phargo 的范围，因此实际天花板约为 40-45%。当前 17.4% 的通过率是在真实比赛场地上从零开始爬升的结果。

测量偏差的教训

早期通过率出现诡异的平台期：整类明显简单的测试持续失败，输出 diff 看起来与预期输出完全相同。最终发现是回车符（carriage return）问题——测试套件在 Windows 上用 CRLF 检出，而 Phargo 的测试比较器按字节逐字比较。PHP 自己的测试运行器在比较前会标准化换行符，Phargo 没有。加上一行标准化代码后，数百个测试瞬间变绿。作者因此将教训刻在项目上：必须测量你的测量工具。Oracle 的诚实程度取决于连接你与它的管道。

测试套件中的「炸弹」

部分测试是「炸弹」——不是恶意的，而是意外的。例如针对古老内存泄漏的回归测试会分配荒谬的结构，生成器测试会无限扩展，有些测试只设计在 PHP 自己的 CI 防护下运行。一次生成器测试导致作者开发机 RAM 被吃光、整机黑屏重启。此后 Phargo 变得极端防御：

• 全局分配器上限 6 GiB
• 步数限制，避免无限循环
• 字符串大小、数组节点、输出长度、生成器扩展的上限
• 面包屑文件，每次测试前记录当前测试名，挂起时知道该盯哪个文件

「波将金」功能

最令作者喜爱的 bug 类型：功能存在、解析通过、运行不报错，但什么都不做。测试套件无情地暴露了这些：

• clone — 解析正常，但求值为 NULL。引擎范围内，所有 DateTimeImmutable 对象的不可变日期计算都被静默破坏，因为不可变日期数学基于 clone。
• unset($arr[$key]) — 完全无操作。键就这么……留着。
• trim($str, $charlist) — 一直忽略字符列表参数，始终只去除空格。
• $$variable 变量变量 — 不存在。
• static 函数变量 — 不存在。
• spl_autoload_register() — 温暖地接受你的自动加载器，但从不调用。
• catch (\Throwable) — 什么都不匹配，对于一个全捕捉子句来说这非常有趣。

每一个都能在 demo 中存活，都能经过作者（不懂 Rust）的代码审查，但没有任何一个能逃过测试套件。这正是整个实验的论点：我无法审计代码，所以这 22,000 个测试替我审计，其彻底性远超任何人类审查员在午餐后能维持的。

最终目标：运行 WordPress

WordPress 是 PHP 兼容性的最终 BOSS，其代码库古老到包含自 2003 年以来的每一层 PHP 惯用法沉积。让 wp-load.php 启动就烧掉了一长串阻塞点：

• goto（是的，WordPress 的 HTML 解析器用了 goto）
• str_replace 的引用传递 $count 参数
• 正则字符类中的 \xNN 转义
• function_exists() 对半数内置函数视而不见

安装器后来因为 preg_split 忽略 PREG_SPLIT_DELIM_CAPTURE 标志而导致数据库损坏——一个深埋四层的 bug，作者不可能诊断，但 AI 找到了并修复了。

最终，wp_install() 完成。管理员用户创建，选项表填充，SQLite 中有三篇文章。前端页面渲染——真实主题、真实文章、真实永久链接。/wp-admin/ 仪表盘也能正常显示，甚至比前端更让作者惊讶。REST API 未完全测试（标注为 ⚠️）。

关键要点

• 零手工编码：Phargo 的代码完全由 AI 生成，人类作者不懂 Rust，但通过迭代运行官方测试套件并指导 AI 修复失败，实现了 17.4% 的通过率。
• 第三方 Oracle：使用 PHP 官方 22,000 个测试作为唯一评分标准，杜绝 AI 自己评价自己，结果无法造假。
• 死线隐藏风险：早期因换行符标准化缺失导致数百个测试虚假失败，暴露了「测量本身需要被测量」的原则。
• 防御性架构：面对测试套件中的「炸弹」，Phargo 加入了内存上限、步数限制、字符串/数组长度上限等防护措施，使其能在无人值守下安全运行全部测试。
• 「波将金」功能暴露：多个常见 PHP 功能（clone、unset、trim 等）存在但行为完全错误（求值为 NULL 或静默无操作），测试套件通过 diff 揭示了它们，而人类 demo 会遗漏。
• WordPress 兼容性里程碑：成功完成新安装、渲染前端和管理仪表盘，但 REST API 尚未完全验证。
• 人类角色极度简化：作者仅负责「看通过率是否上升」，实现了高度的任务委派。

意义与影响

• AI 构建完整语言的可行性：该项目证明，即使开发者不具备底层语言实现知识，AI 也能在大型测试套件的引导下逐步构建出可运行的解释器。这挑战了传统上认为语言实现需要深厚专业知识的观念。
• 自动化测试作为唯一质量锚点：在 AI 生成代码无法被人类有效审计的情况下，大规模、公开、无偏见的测试套件成为保证正确性的核心方法。这为 AI 辅助编程提供了一种可验证的范式。
• 测量偏差的普遍性：换行符 bug 表明，即使是最简单的测试比较环节也可能引入系统性错误。在其他 AI 项目中，类似「管道谎言」可能导致虚假的成功或失败。
• 安全与可靠性启示：AI 生成的代码可能隐含「波将金」功能（存在但无行为），这类 bug 在 demo 中无法被发现，只有通过压力测试才能暴露。Phargo 的防御性架构（资源限制、步数限制）为其他 AI 生成系统提供了参考。
• 对 PHP 生态的潜在冲击：如果 Phargo 能最终