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

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

Forum 是一款独立的小型团队从零打造的 Groups 应用。它也是我们测试一种不同工作方式的场所：把 AI 智能体当作工程流程中的参与者，而不是更快的打字方式。

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

从人在环内到人在环上

仅将 AI 指向编码环节并不会带来太大改变。随着我们将这一方法扩展到实现周围的各个阶段——规划、构建、测试和验证——我们的成果不断累积。看清这一转变最清晰的方式，就是看每个阶段由谁负责。

在 人在环内模式下，工程师驱动每一步，AI 在其中辅助，自动补全函数、提出修复建议或回答问题。每次迭代都按照驱动它的人的速度推进。

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

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

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

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

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

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

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

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

运营模式

这种归属模式需要具备五个关键组件的机制：

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

让环境适应模型

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

架构清晰胜过继承的复杂性： 我们努力让 Forum 的代码库尽可能简单直接，并选择将架构的关键部分模块化，以便既能获得久经考验的基础设施带来的好处，又能让智能体轻松即插即用。在无法轻易做到的地方，我们从头重建，以复用换取智能体吞吐量，事实证明这在开发速度上很有回报。智能体从它们读到的代码中学习模式。修复一次薄弱的模式，未来每个智能体会话都会继承这一改进；放着不管，同样的捷径就会出现在智能体接下来写的所有东西里。 

给智能体工具，而不是描述：我们的主要失败模式是智能体搞不清自己在应用中的位置——被要求修改群组主页时却编辑了主页信息流，或者靠猜屏幕坐标。所以，我们没有向智能体描述应用，而是给它提供了检查工具：从模拟器读取实时视图层级、列出屏幕上实际存在的元素、查找通往目标视图的路径——全部在它行动之前完成。误操作的编辑大幅减少。凡是智能体接触我们系统的地方，我们都采用了同样的方法：给智能体一种直接检查状态的方式，而不是让它基于描述去推理。

为安全的 AI 原型开发构建构建级隔离： 随着 Forum 逐渐走向生产环境，我们希望早期原型和智能体生成的实验有空间运行，同时让生产应用严格只包含已完成、经过审查的工作。我们想要比单纯的功能开关更强的保证，因为在功能开关下，原型代码仍然存在于生产构建中。我们的解决方案是单独的构建变体，一个沙盒应用，它与生产环境共享完全相同的代码库、框架和设计系统，但通过插件/套接字架构，将原型代码从生产构建中完全编译排除。 

这同时给了我们三样东西： 

• 设计师和跨职能合作者可以自由使用 AI 工具进行原型开发，无需每个改动都有工程师参与。 
• 沙盒中构建的任何内容都可以直接移植到生产环境，无需重新构建。 
• 任何原型代码都不会导致生产应用崩溃，因为它实际上不存在于那个构建中。 

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

用 AI 压力测试发现真实缺陷

调整环境不仅让智能体构建起来更快——它还让智能体成为了一名测试者。我们没有把它指向某个具体缺陷。相反，我们设置了可重复的压力场景来模拟真实用户行为（激进滚动、随机浏览群组、快速导航、重复加载媒体），并在各构建中例行运行。由于这些运行会产生一致的信号（崩溃、内存增长、页面错误、UI 回归），智能体可以对异常进行分类、缩小到触发序列，然后调查根本原因。

其中一次这样的运行暴露了一个内存问题。智能体隔离出一个复现、提出修复方案并进行了验证——全部发生在开发期间，在应用到达用户之前。该修复大幅减少了设备内存在重复压力会话中的增长和页面错误。

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

将同样的纪律应用到 Forum 的信息流

我们在两个地方应用了人在环中（human-on-the-loop）的方法：

构建技术栈： 智能体梳理了架构选项和权衡；工程师随后评估并做出选择。我们有意保持人类负责的是目标——决定什么样的结果是好的，这是产品判断，不应由系统自己定义。

运维整个技术栈： 过去需要找了解相关代码路径的工程师来回答的问题，现在都交给一个调查 agent，它会自行收集所需信息，并发布一份带有建议修复方案的报告。在对一批真实调查进行人工评分后，我们得出了一套工作流程：agent 压缩机械性工作，向工程师交付一份结构化报告，工程师再验证某个发现是真正的 bug，还是有意的权衡取舍。 

提升质量的并不是更好的 prompt，而是上下文。有一类反复出现的调查一直效果不佳，直到我们给了 agent 与新工程师入职第一天会得到的相同指引——相关代码、示例查询和设计文档。这一类调查的质量随即大幅提升。与人类入职培训的不同之处在于，你只需训练一次，之后每一次会话都从那里开始。

它奏效了吗？

除了交付更快，我们也交付得更干净。持续验证在开发期间而非上线之后暴露出系统性问题——比如上面提到的内存瓶颈。结果体现在性能剖析中：

• 质量，早早发现： 自主压力测试循环在开发期间而非上线后捕获并修复了前述内存问题，将内存使用和缺页中断大致减半。
• 速度： Forum 在八周内达到了与 Facebook Groups 相当的核心功能，其中 AI 处理了大量常规实现工作，让工程师能够专注于架构、产品决策和质量。
• 持久的杠杆效应： 上线后，agent 驱动的调查帮助工程师对用户反馈进行分诊和根因分析。 

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。