Meta 如何用 AI 原生工程构建 Forum

Meta 的最新应用 Forum，面向所有希望更深入参与 Facebook 群组讨论的人。
为了开发 Forum，Meta 工程师将 AI 智能体引入开发周期，采用了一种全新的工作方式。
我们将分享借助智能体式 AI 开发 Forum 的经验：我们如何调整代码库、测试框架和内部工具以支持智能体执行，以及哪些做法有效、哪些无效。

Forum 是一款由小型团队从零开始开发的独立群组应用。我们也在这个项目中测试了一种不同的工作方式：将 AI 智能体视为工程流程的参与者，而非一种更快的打字方式。

这项实验需要明确成功的标准，而我们的标准并不是代码量。我们衡量的是经过验证、可用于生产环境的成果——能够成功构建、通过测试并通过审查的变更。

从人参与循环到人监督循环

仅将 AI 用于编码环节，并不会带来太大改变。当我们将这一方法扩展到围绕实现的各个阶段——规划、构建、测试和验证——时，成效便不断叠加。要看清这种转变，最直观的方式就是看每个步骤由谁负责。

在人参与循环的模式下，工程师主导每个步骤，AI 则在其中提供辅助，例如自动补全函数、提出修复建议或回答问题。每次迭代都按照主导者的节奏推进。

在人监督循环的模式下，智能体自行运行迭代——规划、实现、构建、测试、纠正、重复——而工程师负责设定目标、观察运行过程、在出现偏差时介入，并批准结果。人的职责从执行步骤转向对结果负责、把控质量标准。这是我们正在努力实现的目标，而非已经完成的状态：目前有些阶段已能自主运行，而另一些阶段仍需要工程师参与每次迭代。

当工程师负责监督时，工作就不再严格按顺序进行。过去只能逐一运行的循环现在可以重叠进行，工程师的时间也转而用于指导和判断，而不是全程守着循环。但这一切的前提是，返回的结果值得信赖。如果缺乏验证，AI 生成的代码就会带来一个熟悉的问题——输出看似合理，却没人确认它是否真的有效，随后工程师还得阅读、调试，而且往往最终将其丢弃。薄弱的信号并不能消除瓶颈；它们只是将瓶颈从编写代码转移到了审查那些看似完成、实则未完成的代码上。

因此，我们将标准设在验证上，而非编译上。编译成功并不是终点——只有通过自动化测试和视觉检查，任务才算完成。智能体会在工程师查看之前检查自己的工作，这意味着进入审查的是一组数量更少、可信度更高的结果，而不是一堆需要筛选的输出。生成的内容更少，被丢弃的内容也更少。每项交付成果仍须由工程师签核；我们的努力在于让签核快速完成且有充分依据，为变更附上构建结果、测试结果以及记录下来的验证过程。

当工程师不再参与每一次循环时，循环就必须能够安全地自主运行。以下四项能力使之成为可能：

将规划作为技术规范： 智能体执行需要极高的精确度。工程师或许能凭直觉消解的歧义，却会导致智能体失败。我们投入精力，在前期进行严谨的任务拆解，并提供机器可读的上下文，从而让工程师和智能体的工程迭代闭环都更加紧凑。

闭环内的自动化验证是效能倍增器： 我们将自动化的通过/失败信号——构建状态、单元测试和 UI 规范匹配情况——直接集成到智能体闭环中。这使异步开发成为可能，产出的拉取请求已可供审查，并附有预先填好的测试计划和录制的验证过程。验证是难以做好的环节，而我们能安全地将多少工作交给闭环，取决于我们对验证工具的信任程度。

使用智能体模拟用户测试： 我们部署了导航智能体，它们像真人一样与实际运行的应用交互。这些智能体执行操作、读取屏幕内容并报告回归问题。导航智能体能够持续运行相同的验证路径。

智能体驱动的生产运维： 上线后，智能体会协助自动化根因分析。当 Forum 用户提交反馈时，智能体会利用这些反馈排查可能的回归问题。随后，智能体将分析结果转交给工程师，由工程师决定下一步行动。

运作模式

这种责任归属模式需要一套包含五个关键组成部分的机制：

规则是长期有效的项目指令。当智能体重复同一个错误超过两次时，我们就将纠正方法统一编写一次，供所有人使用。
技能将团队惯例转化为智能体可以调用的可加载步骤。
智能体将以前需要人工检查的事项自动化。
命令将技能和智能体串联成工作流。它们评估复杂度、复现错误、规划并实施修复、创建拉取请求，并开展多阶段审查。
钩子是自动化触发器，例如在智能体每轮操作后运行代码检查工具、在安装前检查模拟器连接状态，以及在创建拉取请求前验证测试。

调整环境以适应模型

最大的收益来自改变代码和工具，而不是提示词。

优先保证架构易读，而非沿袭复杂性： 我们努力让 Forum 的代码库尽可能直观，并选择将架构中的关键部分模块化，以便在享受久经考验的基础设施所带来的好处的同时，也让智能体能够轻松实现即插即用。对于难以做到这一点的部分，我们从头重建，以复用换取智能体的工作吞吐量，事实证明，这提升了开发速度。智能体会从所阅读的代码中学习模式。将一个不良模式修正一次，今后每次智能体会话都能继承这项改进；若放任不管，同样的捷径就会出现在智能体接下来编写的所有内容中。

给智能体工具，而不是描述：我们遇到的主要失败模式是，智能体搞不清自己在应用中的位置——要求它修改群组主屏幕，它却编辑了首页信息流，或是猜测屏幕坐标。因此，我们没有向智能体描述应用，而是给它提供了用于核查的工具：从模拟器读取实时视图层级、列出屏幕上实际显示的元素，以及查找目标视图的路径——所有这些都在它采取行动之前完成。改错位置的情况大幅减少。凡是智能体会接触到我们系统的地方，我们都采用了同样的方法：让智能体能够直接检查状态，而不是根据描述进行推理。

通过构建级隔离实现安全的 AI 原型开发：随着 Forum 逐渐成熟、走向生产环境，我们希望为早期原型和智能体生成的实验留出运行空间，同时严格确保生产版应用只包含已完成且经过审核的工作成果。我们希望获得比单靠功能开关更强的保障，因为使用功能开关时，原型代码仍然存在于生产构建中。我们的解决方案是采用一种独立的构建变体，即一个与生产版共用完全相同的代码库、框架和设计系统的沙盒应用，但通过插件/插槽架构，在编译时将原型代码从生产构建中彻底排除。

这让我们同时获得了三项好处：

设计师和跨职能合作伙伴可以使用 AI 工具自由制作原型，无需每次修改都让工程师参与。
沙盒中构建的任何内容都可以直接移植到生产环境，无需重新构建。
任何原型代码都不可能导致生产版应用崩溃，因为这些代码根本不存在于该构建中。

这种模式让我们在有了需要保护的真实应用用户之后，仍然能够保持快速的 AI 迭代。

通过 AI 压力测试发现真实缺陷

调整环境不仅让智能体能更快地参与构建，还让它成为了测试者。我们没有让它针对某一个具体缺陷展开测试，而是设置了可重复执行的压力测试场景，模拟真实用户行为（高强度滚动、随机浏览群组、快速切换页面、反复加载媒体），并定期在各个构建版本上运行。由于这些测试会产生一致的信号（崩溃、内存增长、缺页异常、UI 回归问题），智能体可以对异常进行分诊，缩小范围以确定触发异常的操作序列，然后调查根本原因。

其中一次测试暴露了一个内存问题。智能体确定了复现步骤、提出修复方案并完成验证——这一切都发生在开发期间、应用交付用户之前。该修复显著减少了多轮压力测试中的设备端内存增长和缺页异常。

虽然架构决策由工程师做出，但检测和回归监控是自动化且可重复执行的；一旦检测到异常，智能体就可以使用同一套测试框架完成复现 → 隔离问题 → 提出修复方案 → 验证。

将同样的规范应用于 Forum 的信息流

我们在两个方面采用了人类监督的方法：

构建技术栈：智能体梳理架构选项及其利弊；工程师随后进行评估和选择。我们刻意保留给人类决定的是目标——判断什么样的结果才算好，是一项产品判断，不应由系统自行定义。

技术栈运维： 过去需要找熟悉相关代码路径的工程师才能解答的问题，如今交由调查智能体处理：它会收集所需信息，并发布包含修复建议的报告。在对一批真实调查进行人工评分后，我们形成了一套工作流程：智能体压缩机械性工作，向工程师提交结构化报告，再由工程师验证发现的问题究竟是真正的缺陷，还是有意做出的权衡。

提升质量的并不是更好的提示词，而是上下文。有一类调查的结果一直不理想，直到我们像对待第一天入职的新工程师那样，为智能体提供相关代码的指引、示例查询和设计文档。这类调查的质量随即大幅提升。与人类入职培训不同的是，只需培训一次，之后的每次会话都能以此为起点。

奏效了吗？

我们不仅交付得更快，交付质量也更高。持续验证让系统性问题——比如上文提到的内存瓶颈——在开发期间就暴露出来，而不是等到上线之后。成果体现在性能表现上：

及早发现质量问题： 自主压力测试循环在开发期间就发现并修复了上述内存问题，而不是等到上线之后，使内存使用量和缺页次数大致减半。
速度： Forum 在八周内实现了与 Facebook Groups 核心功能对等，AI 承担了大量常规实现工作，让工程师能够专注于架构、产品决策和质量。
持续发挥的效能： 上线后，智能体驱动的调查帮助工程师对用户反馈进行分类处理并查明根因。

AI 所做的不只是生成代码。它缩短了我们的质量反馈闭环，帮助一个小团队交付高质量应用，同时减少后续持续返工。

哪些做法有效，哪些无效

致谢

我们感谢 Neeharika Sinha、Jane Kou、Gang Yang、Guohao Zhang、Zeya Zhang、Kinnary Jangla，以及Yonghui Lu 的宝贵贡献。

文章《Meta 如何通过 AI 原生工程构建 Forum》首发于 Engineering at Meta。