Meta 的独立群组应用 Forum 在 2026 年 10 月 15 日由 Meta 工程团队发文复盘了它的造法：一个小团队从零起步，把 AI 智能体当作开发流程的参与者而非打字加速器，八周就做到了与 Facebook 群组核心功能对齐的程度。复盘里最值得注意的不是速度本身，而是他们给成功定的标准——不看生成了多少代码，只看有多少改动通过了构建、测试和评审，真正达到可上线状态。
从人盯每一步，到人只盯结果
团队把这套方式称为从 human-in-the-loop 转向 human-on-the-loop。传统用法里工程师主导每一步，AI 只在某一步里补全或答疑，节奏被人的手速锁死；新方式里，规划、实现、构建、测试、修正的循环由智能体自己跑，工程师负责定目标、看运行、在跑偏时介入、最后批准结果。人的工作从执行步骤变成守住质量线。为了让这种放手不变成放任，他们把验收门槛定在验证而不是编译通过：任务只有在自动化测试和视觉检查都过关后才算完成，智能体先自查，送到工程师面前的改动附带构建结果、测试结论和验证录像，评审因此能做得快而有据。
真正起作用的是四件配套设施
复盘列出的关键能力里，排在前面的不是提示词技巧。一是把规划做成机器可读的技术规格，因为含糊之处人可以凭直觉补，智能体只会直接失败。二是把构建状态、单元测试、界面规格比对这些通过与否的信号接进智能体循环本身，让它异步产出可评审的拉取请求。三是派出模拟用户智能体，像真人一样在应用里操作、看屏幕、报告回归，持续跑同样的验证路径。四是上线后让智能体先对用户反馈做根因分析，再把结论交给工程师定夺。团队的日常机制也围绕这套循环组织：反复犯的错写成永久规则只纠正一次，团队约定沉淀成可调用的技能，检查项做成自动智能体，常用流程串成命令，代码检查等动作由钩子自动触发。
压测智能体在上线前先抓到了内存问题
效果最具体的一例来自压力测试。团队让智能体按真实用户行为反复跑滚动、浏览、切换、加载媒体等场景，信号稳定可比对，异常出现时它能自己复现、缩小触发顺序并定位原因。开发期的一轮压测就这样提前发现了一个内存问题，修复后设备上的内存增长和缺页大致减半——这类问题按以往节奏多半要等上线后被用户撞上。也要看到边界：这是 Meta 用自家内部工具链和从零设计的代码库跑出的结果，复盘也承认收益主要来自改造代码与工具、让结构对智能体可读，而不是来自提示词。对外部团队可迁移的结论因此很朴素：先把验证设施和代码可读性补上，再谈让智能体独立跑循环，否则省下的写代码时间，只会变成审一堆看似完成的代码的时间。
