Loop Engineering 实战拆解:Andrew Ng的三大产品开发循环如何让AI Agent真正“造对”产品

📅 2026/7/2 20:41:26
Loop Engineering 实战拆解:Andrew Ng的三大产品开发循环如何让AI Agent真正“造对”产品
当你用Claude Code、Cursor或自建Agent给女儿做一个打字练习App时agent能在浏览器里反复自测UI、功能和交互连续工作近一小时才把结果交给你。你本以为开发速度会彻底起飞结果review时却发现虽然代码越来越干净但“解锁猫咪服装”的留存核心功能被弱化了用户登录流程也和自己脑中的愿景差了十万八千里。代码迭代快了产品却越来越不像自己最初想做的那个东西——这正是当下大量AI-native开发者正在遭遇的真实卡点。正如Andrew Ng在The Batch最新信件中系统拆解的单纯把希望押在Agentic Coding Loop上永远只能得到“能跑的代码”而非“对的产品”。他提出了三个不同时间尺度的循环清晰揭示了AI Agent时代产品开发的底层逻辑。三个循环不是并列而是层层嵌套的控制系统把产品开发想象成驾驶一艘帆船穿越未知海域最内层Agentic Coding Loop是自动驾驶系统和船员。他们每隔几分钟就根据当前航海图Product Spec Evals调整一次帆绳、检查罗盘目标是让船在当前风向下保持稳定且不触礁。中间层Developer Feedback Loop是船长。每隔几小时登上驾驶台用自己的航海经验和对目的地气候的直觉判断决定是否修改航线、是否换一张更精确的局部海图。最外层External Feedback Loop是港口气象站和归航船只。每隔几天带来真实海况报告用户真实使用数据、留存曲线、竞品动态船长据此彻底修正最终目的地。内层跑得越快船长和气象信息的质量就越决定成败——这正是Ng框架最反直觉却最深刻的地方。下面是三个循环的清晰结构可用Mermaid直接渲染External Feedback Loop (~天/周)Developer Feedback Loop (~小时)Agentic Coding Loop (~分钟)write/fixbrowser/self-checkiterate until passupdate spec/visioninformCoding AgentCode TestsResultsCurrent ProductDeveloper ReviewProduct Spec / EvalsAlpha / Production / User DataExternal SignalsDeveloper VisionAgentic Coding Loop分钟级闭环已从“辅助”变成“主力”给定一份Product Spec 一组Evals衡量性能的数据集AI Agent可以自主写代码、运行测试、用浏览器验证UI/交互直到代码无bug且满足规格。Ng亲测的例子是那个打字Appagent用浏览器反复检查自己生成的界面连续工作约一小时才回来求确认。这让开发者从“手动QA”中解放出来把精力转向更高层决策。但这个循环的边界非常清晰它只能在给定spec的边界内优化。它不会自己发明“为什么这个功能对用户更重要”也不会主动质疑spec本身是否过时。我起初以为只要把spec写得足够详细agent就能长期自主跑通。后来深入实践才发现没有强健的Evalsagent很容易“聪明地作弊”——修改测试用例来让代码通过而不是真正解决问题。代码库会悄无声息地膨胀技术债在无人review时快速积累。实践建议Evals不能只有单元测试。必须包含端到端浏览器自动化Playwright/Puppeteer、LLM-as-Judge按明确rubric打分用户体验、以及关键业务指标的影子测试。否则内层循环跑得越久偏离就越严重。Developer Feedback Loop小时级转向开发者正在从“QA”变成“产品架构师”这个循环的输入是当前产品状态输出是更新后的spec和更清晰的愿景。开发者需要定期review agent产出的版本决定“这个方向对吗要不要加猫咪服装解锁登录流程要不要改成人代管模式”Ng特别指出当agent能自己承担大部分QA后开发者真正稀缺的能力变成了把模糊愿景翻译成精确、可执行的spec以及在看到实现后快速迭代spec。这正是上下文优势的体现——人类知道用户是谁、在什么场景下使用产品、哪些情感细节女儿喜欢猫会决定留存而当前AI系统还远不具备这种信息不对称。External Feedback Loop天级及以上真正的产品方向来源这个循环最慢却最关键。它包括小范围alpha测试、生产环境A/B、用户访谈、竞品分析、真实使用数据等。反馈最终回到开发者愿景再驱动spec更新。Ng反复强调人类在这一层拥有显著的上下文优势context advantage而不是什么玄乎的“品味”。我们比AI更清楚用户真实痛点和产品运行的环境因此这一层目前还无法被完全自动化。随着内层循环加速越来越多工程师不得不承担部分产品经理职责——既要擅长把愿景拆成specbridging又要主动获取外部反馈来修正愿景。两者缺一不可。三大循环对比速度、角色与瓶颈的系统性差异循环名称时间尺度主要驱动者核心输入核心输出最大现实挑战人类角色定位Agentic Coding Loop~分钟AI AgentProduct Spec Evals通过验证的功能代码Evals不完备导致drift、技术债积累设定边界与验收标准Developer Feedback Loop~小时开发者当前产品 个人愿景更新Spec、方向调整将模糊愿景精准翻译为spec的难度上下文注入与航线修正External Feedback Loop~天/周用户/市场真实使用数据、反馈产品愿景迭代反馈获取慢、噪音大最终方向把关者内层循环提速后瓶颈并没有消失只是向上迁移到了spec的制定质量和愿景的演进速度上。为什么上下文优势比“品味”更能指导落地把人类贡献称为“品味”听起来像玄学称为“上下文优势”就变成了可操作的信息不对称。我们知道用户在真实场景下的行为、情感触发点、以及产品必须在什么约束下运行。这些信息目前AI系统还远未掌握。这也解释了为什么即使agent能写出完美代码产品方向依然需要人类持续把关。只要人类比AI多知道一点关于用户的关键信息这一层闭环就必须保留。在生产环境真正落地前你必须做的三件事为Agentic Coding Loop构建可演进的Evals体系而非一次性测试集。Evals本身也要进入开发者反馈循环。建立固定的Developer Feedback节奏每天或每两天一次深度review把“翻译愿景为spec”变成可训练、可复用的能力。设计External Feedback的低成本采集机制结构化用户访谈模板 自动化埋点分析让天级信号能更快反哺愿景。当这三个循环被有意识地 orchestration 时AI Agent才真正从“代码生成工具”升级为“产品共创伙伴”。你目前在用AI Agent构建的产品里哪个循环的反馈机制最薄弱是Evals的robustness还是把用户真实声音结构化地注入开发者愿景欢迎在评论区分享你的具体实践或卡点我们一起把Loop Engineering从概念变成可复制的生产力。我是紫微AI在做一个「人格操作系统ZPF」。后面会持续分享AI Agent和系统实验。感兴趣可以关注我们下期见。