8周做出可上线应用，Meta怎样让 Agent 自己验收

你大概已经遇到过这种 PR：Agent 写得挺快，CI 也绿了，打开页面才发现它改错了入口，或者把边角逻辑一起削掉。真正麻烦的不是回滚一次，而是你开始不信任“已完成”三个字。于是人又把每一行都读回去，AI 省下的时间原地蒸发。

Meta 最近复盘了他们做独立 Groups 应用 Forum 的过程。一个小团队从零开工，核心功能在八周内达到与 Facebook Groups 的功能对齐。更值得看的不是八周，而是他们给 Agent 定的完成标准：能编译不算完成；构建、自动测试、视觉检查和可回看的验证记录都过了，才把东西送到人面前。

这不是“把 Agent 放开跑”的故事，反而是给 Agent 加了一套更硬的验收装置。Meta 把它叫作从 human-in-the-loop 走向 human-on-the-loop：人不必卡在每一个操作里，但仍要定义结果、盯住跑偏处、批准最终进入生产的变更。

如果你的团队已经让 Agent 提 PR，Forum 的经验可以翻成一句很实际的话：别只问它能不能写，更要问它能拿出什么证据证明这次改动没把系统带沟里。

Agent 多走几步，人该少做什么

传统的人机协作很熟悉：工程师把任务切小，AI 补一个函数、解释报错、给出修复建议；下一步怎么走，仍由人逐项推动。它的好处是可控，代价是每个循环都得等人腾出手。

Meta 想要的另一种节奏，是让 Agent 自己跑完“规划、实现、构建、测试、修正、再试”这条短循环。工程师不再负责每一次按键，而是负责目标、质量门槛和最终判断。多个任务因此可以并行，人的注意力不必耗在等待构建和重复检查上。

听起来很顺，但这里有一个很容易被忽略的坑：如果 Agent 交上来的是十个“看起来差不多”的结果，人只是从写代码变成了读十份更长的代码。Meta 在原文里把这种状态说得很直白：弱验证不会消除约束，只会把约束搬到后面的人工评审。

所以，人该少做的不是判断，而是机械地重复取证。真正适合交出去的，是这些可重复、可给出通过／失败信号的动作：跑构建、跑单元测试、比对 UI、沿固定路径点一遍页面、复现已知问题。人留下来做的，是那些没有单一正确答案的事：功能目标是否值得、架构取舍是否合适、风险是否能接受、一次异常到底算 bug 还是有意设计。

这个分工比“AI 写代码，人来 review”更细。它要求团队先把“什么叫完成”写清楚，再把完成的证据接进循环。没有前半句，后半句的自动化只会变成一个更快的代码打印机。

验收别放在 PR 末尾

Forum 的关键不是多加一个 review bot，而是把验证塞进 Agent 的每一轮运行里。Meta 公开的信号包括构建状态、单元测试和 UI 规格匹配；待评审的 PR 还会带上测试计划和录制的验证过程。

这让评审的输入发生了变化。人看到的不再只是一个 diff，而是一组可以追溯的问题：它改了什么、在哪个环境构建、哪些检查通过、哪个页面被实际操作过、失败时怎样复现。证据不一定保证代码正确，却能把“我觉得应该没问题”变成一个可追问的对象。

没有现成平台的团队，也能从一张很小的验收单开始。下面这段不是 Meta 的原始模板，而是按它公开流程抽出的最小版：每个 Agent 任务结束前，把能自动回答的部分填掉；人只处理留白和高风险项。

task: 修复群组页筛选条件失效
success: 筛选结果与接口返回一致，空结果可恢复
checks:
  build: passed
  unit_tests: passed
  ui_path: 群组页 → 筛选 → 清除筛选
  evidence: artifacts/filter-replay.mp4
  rollback: 关闭新筛选路径
human_decision: 待产品确认空状态文案

这张单的重点不在字段有多全，而在每一项都能被查。比如“已测试”不是证据；测试命令、报告地址、录屏或截图才是。再比如“功能正常”不是结论；目标路径、预期状态和回退办法才让 reviewer 知道该查哪里。

把这一步前置以后，评审不会消失。它会从翻大量无上下文代码，变成先判断证据是否足够，再把注意力放到产品和架构的少数关键处。这才是 Agent 真正能给团队腾出的空间。

别让它靠描述猜页面

Meta 还提到一个特别日常的失败：Agent 会在被要求修改群组主页时，跑去改 Home Feed；它也会猜屏幕坐标。任何做过移动端自动化的人都知道，这种错不算“模型笨”，更像是给了一个新同事一句模糊指路，然后让他蒙着眼进楼。

他们的处理方式不是继续写更长的说明，而是给 Agent 状态读取工具：操作前先读模拟器实时视图层级、列出屏幕上实际存在的元素、查询目标视图的路径。它先看见真实状态，再决定怎么动。Meta 表示，这类误导性修改明显下降。

图注：Forum 的官方产品界面。工程文章的重点不在 UI 长什么样，而在 Agent 操作前能否读取当前界面的真实层级与元素。来源：Meta Engineering。

这件事可以推广到网页、后端和数据任务。让 Agent 改数据库之前，给它 schema 和只读查询；让它改权限之前，给它当前策略和测试账号；让它修线上问题之前，给它时间范围、日志索引、告警 ID 和可重放的请求。能读取的状态，比一大段自然语言说明更接近事实。

当然，状态读取也有边界。只给读权限不等于不会误判；返回的数据过旧、观测点不完整、测试环境和线上不一致，都会让 Agent 得出漂亮但错的结论。这里最该做的是把观测缺口显式写进验收单，而不是让它用“应该”补齐。

原型跑得快，生产别跟着裸奔

当 AI 参与原型越来越快，另一个问题会冒出来：实验代码到底怎么不污染生产？许多团队靠 feature flag 解决，但 Meta 认为这还不够。即使开关关闭，原型代码仍躺在同一个生产构建里，依旧可能被意外触发、被错误依赖，或者给维护者增加理解成本。

Forum 的做法更硬一点：单独做一个 build flavor。沙盒应用和生产版本共享同一代码库、框架和设计系统；但借助 plugin/socket 架构，原型代码会被直接编译排除在生产构建之外。设计师和跨职能伙伴可以继续用 AI 快速试验，成熟成果再迁进生产；那些没成熟的实验则物理上不在生产包里。

这个办法不必照抄到每个项目。它在复杂客户端、长期运行的服务、涉及权限或支付的路径上更有价值；一个一次性的内部脚本，可能只需要隔离目录和有限凭据。但它提醒了一个现实：“不默认启用”与“根本不会进入生产物”不是同一个安全等级。

如果你的团队最近刚开始让 Agent 改真实业务，可以先问三个问题：原型能访问哪些数据？它生成的依赖会不会进生产镜像？回退时，能否把实验代码从交付物里完整移除？能回答清楚，再谈速度才比较踏实。

压力测试才是第二双眼睛

静态检查、单元测试和 UI 对比能抓到很多事，却抓不住所有真实使用方式。Meta 给 Forum 加了一组可反复运行的压力场景：快速滚动、随机浏览群组、频繁跳转、重复加载媒体。它们不是为了“测试 Agent”，而是持续制造稳定的崩溃、内存增长、缺页和 UI 回归信号，让 Agent 有东西可查。

一次压力测试发现了内存问题。官方描述的后续路径是：Agent 复现、定位触发序列、提出修复、用同一套 harness 验证；工程师仍负责架构决定。Meta 给出的结果是，重复压力场景中的设备内存增长和缺页都约减半。这不是绝对数值，也不是其他应用可以照搬的性能承诺，但它很好地说明了：只有同一条验证路径能反复跑，修复前后才有可比较的结果。

图注：依据 Meta 官方“约减半”结论绘制的相对指标图，修复前设为 100；并非官方披露的绝对内存或缺页数。

很多团队让 Agent“帮忙测试”，最后只得到一串自然语言总结。更有用的交付应该是失败序列、环境版本、关键指标、最小复现和回归结果。没有这些，Agent 就算定位到一次问题，也很难让下一个会话继续接住。

八周背后，藏着三条不那么浪漫的限制

Forum 的八周很抓眼球，但 Meta 自己也没把它包装成一键复制的神话。源站给出的“哪些没奏效”反而更值得贴在团队墙上。

一条是上下文会跨会话丢失。架构决定、已试过的方案和例外条件，如果只存在某个人脑子或聊天记录里，下一个 Agent 和新加入的工程师都会重新踩一遍。Meta 的处理是把反复出现的修正固化成规则，把团队惯例做成可加载的技能，再用命令和钩子把它们接到工作流里。这里不需要迷信某种工具名，重点是：同一种错误出现两次以上，就别靠口头提醒第三次。

另一条是 PR 通过也可能在偷工减料。Meta 明说，技术上通过的 PR 仍可能切掉边角，因此质量信号必须足够严，不是把检查跑得更频繁就够了。也就是说，测试覆盖不到的风险不能被绿勾掩盖；高风险修改仍要定义额外的人工审查点。

还有一条很朴素：远程 iOS 模拟器连接不稳定，反而拖慢整个循环。它提醒我们，Agent 的上限也受开发环境限制。模型再快，构建排队、沙盒网络、测试数据和设备连接不可靠，都会把人机协作重新拖回等待。

因此，想借 Agent 提速，先别把问题全扔给 prompt。先清点三样东西：项目上下文能否沉淀、验证信号能否自动产生、运行环境能否稳定复现。少一项，自动化就容易在最需要它的时候失灵。

明天就能开始的四个检查

不必等到有一套完整的 Agent 平台再开始。挑一个边界清楚、回退容易的仓库或功能，先跑一轮小实验：

1. 写清一条成功定义。 不要只写“实现 XX”，写出用户路径、边界条件与不该发生什么。
2. 让 Agent 在修改前读取状态。 给它页面层级、schema、日志或配置的只读入口，减少凭描述猜位置。
3. 把证据和代码一起交。 每次 PR 至少带构建、测试和一条可重放验证路径；高风险改动再加截图、录屏或指标。
4. 把原型和生产交付物分开。 哪怕暂时做不到独立 build flavor，也要明确实验目录、权限、依赖和回退边界。

这四步不会让 Agent 突然变得更聪明，却会让团队更早知道它什么时候不可靠。等验证链路跑稳，再把任务范围一点点放大，成本通常比先放开权限、再补事故复盘低得多。

Meta 这篇复盘最有价值的地方，不是证明 Agent 能在八周内写出多少代码，而是把“质量责任还在人身上”落到了具体机械上：规则、状态读取、验证器、隔离构建和可复放的压力测试。

你现在让 Agent 提交的改动里，哪一类最缺可验证的证据：页面行为、数据正确性，还是生产隔离？