Meta 如何用 AI 原生工程方式开发 Forum 应用

• Meta 最新的应用 Forum，面向所有想更深入参与其 Facebook 群组对话的人。
• 为了构建 Forum，Meta 的工程师采用了一种全新的工作方式，将 AI 智能体引入开发周期。
• 我们分享构建 Forum 过程中使用智能体式 AI 的洞察：我们如何调整代码库、为智能体执行测试框架和内部工具，哪些做法有效，哪些无效。

Forum 是一款独立的小组应用，由一个小团队从零开始构建。它也是我们测试一种不同工作方式的场所：将 AI 智能体视为工程流程的参与者，而不是更快的打字方式。

这项实验需要定义成功，而我们的标准不是代码量。我们衡量的是经过验证、可投入生产的结果——能够构建、通过测试并经受审查的变更。 

从 Human-In-The-Loop 到 Human-On-The-Loop

仅将 AI 指向编码步骤本身并不会带来太大改变。当我们将这一方法扩展到实现前后的各个阶段——规划、构建、测试和验证——我们的成果开始复利式增长。看清这一转变最直观的方式，是看每个步骤由谁主导。

在 human-in-the-loop 模式下，工程师驱动每一步，AI 在其中辅助，自动补全函数、建议修复方案或回答问题。每次迭代都以驱动者本人的节奏推进。

在 human-on-the-loop 模式下，智能体自行运行迭代——规划、实现、构建、测试、修正、重复——而工程师设定目标、观察运行、在偏离时介入并批准结果。人的工作从执行步骤转变为对结果负责并守住质量标准。这是我们努力的方向，而非已完成的终态：如今有些阶段已能自主运行，而另一些阶段仍需工程师参与每次迭代。

当工程师进行监督时，工作不再是严格的顺序执行。过去一次只能运行一个的循环可以重叠，工程师的时间用于方向和判断，而不是坐在循环里等待。但这一切只有在返回的结果可信时才成立。没有验证，AI 生成的代码会带来一个熟悉的问题——看似合理但无人确认其真正可用的输出，工程师随后不得不阅读、调试，并常常将其丢弃。弱信号并不能消除这一约束；它们只是把约束从编写代码转移到审查那些看起来已完成、实则不然的代码上。

因此我们把标准设在验证而非编译上。编译不是终点——只有自动化测试和视觉检查都通过，任务才算完成。智能体在工程师看到之前先检查自己的工作，这意味着到达审查环节的是一组数量更少、可信度更高的结果，而不是一堆需要筛选的输出。生成得更少，丢弃的也更少。每个交付的结果仍需工程师签字确认；我们的努力在于让这一签字确认快速且有据可依，将构建结果、测试结果和录制的验证会话附加到变更上。

当工程师置身于每个循环之外时，循环必须能安全地自行运行。四项能力使之成为可能：

将规划作为技术规范： 智能体执行需要极高的精确度。工程师可能凭直觉解决的歧义会导致智能体失败。我们投入于严格的上游分解和机器可读的上下文，这为工程师和智能体同样收紧了工程闭环。

循环内的自动化验证是力量倍增器： 我们将自动化的通过/失败信号——构建状态、单元测试和 UI 规范匹配——直接集成到智能体循环中。这使得异步开发能够产出可供审查的拉取请求，并预先填充测试计划和录制的验证会话。验证是最难做对的部分，而我们能安全地交给循环多少，取决于我们能多大程度信任验证器。

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

智能体化生产运维：发布后，智能体帮助自动化根因分析。当使用 Forum 的人提交反馈时，智能体会利用该反馈调查可能的回归问题。随后智能体将分析转发给工程师，由工程师决定下一步行动。  

运营模式

这种所有权模式需要具备五个关键组件的机制：

• 规则 是永久性的项目指令。当智能体重复犯错超过两次时，我们将纠正措施一次性编码，供所有人使用。
• 技能 将团队约定转化为智能体可以调用的可加载步骤。
• 智能体 自动化此前需要人工通过的检查。 
• 命令 将技能和智能体串联成工作流。它们评估复杂度、复现缺陷、规划并实施修复、创建拉取请求，并运行多阶段审查。
• 钩子 是自动化触发器，例如在每次智能体回合后运行 linter、在安装前检查模拟器连接性，以及在创建拉取请求前验证测试。

让环境适应模型

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

架构清晰性优先于继承的复杂性： 我们努力保持 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 的宝贵贡献。 

文章 How Meta Built Forum With AI-Native Engineering 首次发表于 Engineering at Meta。