构建自己的第一个 Loop：让 AI Demo 从“像产品”变成“真产品”

感觉现在人人都是一个coding大师了。现在让 AI 写一个网页、写一个小游戏、写一个 App Demo，已经不是什么稀奇事，主要问题在于写出来的东西是一个简易版，还是真的是一个可以跑起来的版本。

就像之前明星胡彦斌说自己一个月就能开发一个APP一样，普通人在这个时代只要有创意就能够立马实现自己的想法

很多 AI Demo 看起来很完整，比如说可能有统一的按钮，首页之类的，但是很难给真正的用户使用。比如说按钮是假的，点了没反应，页面只是“像一个产品”，不是一个真正可用的产品。

而最近龙虾之父“Peter” 在社媒发帖，声称开发者不应该继续直接写 Prompt，而应该设计 Loop(循环) 来 Prompt Agent。这样的loop 工程做出来的Demo产品，其可用性大大提高。

我也直接曾经写过一篇介绍“Loop工程”的文章，感兴趣的可以去知乎搜索一下：

Loop 工程：Prompt 工程之后，Agent 时代的新分工 - 算法一只狗的文章 - 知乎

https://zhuanlan.zhihu.com/p/2050729262047573149

Anthropic 也趁着这个热词大火的机会，直接演示了使用Loop怎么去让 Agent 构建一个 2D 复古游戏制作器。最后构建的这个产品不仅有 UI，还要有关卡编辑器、精灵编辑器、实体行为，以及真正可以试玩的 Play Mode。

这样的任务非常适合解释 Loop。因为游戏不是静态页面，必须形成完整闭环：创建素材、编辑关卡、配置角色、进入测试模式、真的玩起来。

Loop工程到底如何设计

在演示过程中，他们给了一个很简单的需求：做一个 2D retro game maker，包含关卡编辑器、精灵编辑器、实体行为和可玩的测试模式。

然后用两种方式对比。

第一种是 Solo Harness，也就是一个 Agent 直接做。它很快，成本也低，二十分钟左右就能给出一个结果。页面看起来有模有样的，有开屏页，有精灵编辑器，也有游戏页面。

但是，真正进入 Play Mode 后，角色和实体没有响应，用户输入没有生效，游戏运行时和实体定义之间没有真正打通。而且可以看到，布局浪费了空间，固定高度的面板让大部分视窗空无一物。

第二种是 Full Harness，也就是Agent Loop。它更慢、更贵，但结果明显不同：Planner 先把一句话需求扩展成产品规格，Generator 按 Sprint 实现，Evaluator 再用真实浏览器操作验收。最终的产品仍有物理碰撞和关卡设计问题，但核心 Play Mode 跑通了，用户真的可以移动角色并试玩。

这套 Full Harness 包含 Planner、Generator、Evaluator 三类 agent

Planner负责把所有的计划写出来，按照具体的用户需求，写一个详细的步骤计划

Generator负责按照Planner的计划指导，编写一个游戏程序

Evaluator本质就是一个评估器， 用 Playwright MCP 像真实用户一样点击应用、测试 UI/API/数据库状态，并按产品深度、功能性、视觉设计、代码质量等标准打分；任何一项低于阈值，该 sprint 就失败并把详细反馈交回 Generator。

在codex下其实也很容易复现出来，首先就是要在项目中限定一个人设Agents.md

然后可以让codex快速创建三个独立的Agent，就可以让它不断的调试优化，最后得到一个真实可玩的游戏。

把上面的内容放到codex上，就是一个简单的loop工程了。

然后Planner 智能体开启执行工作执行

最后经过loop工程的不断循环之后，就可以看到一个简单的游戏Demo出来了

在游戏界面中可以自由摆放方块，目标和金币，已经算是一个比较成熟可用的demo了

使用Loop工程对工作方式意味着什么

从 Prompt 转向 Loop 设计，并不是软件开发独有的变化。只要 AI 在某个领域强到可以自主处理一类任务，这种模式就会自然出现。

人并没有从流程中消失，而是上移到了更高的抽象层。

过去，人负责执行每一个具体步骤：写代码、跑测试、看报错、继续修改。现在，人开始负责定义工作类别、设计成功标准、搭建验证系统，让 Loop 能够判断自己是否完成任务，并在遇到真正超出能力边界的问题时，把它交还给人。

这会真实改变日常工作的形态。以前，一个开发者可能花四个小时写功能代码；现在，他可能花四个小时设计一个 Loop，让它自动生成代码、运行测试、检查回归、提交 PR。表面上看，还是在完成同一类工程任务，但人的位置已经变了：输出变了，杠杆变了，所需要的能力也变了。

你今天设计的 Loop，未来也可能被一个“元 Loop”取代，由它来设计新的 Loop。到那时，问题就会变成：人到底在哪些地方仍然不可替代？

这其实也是自动化一直以来的核心问题。关键从来不只是机器能不能执行任务，而是机器是否有判断力：它是否知道哪个任务值得做，为什么值得做，以及结果什么时候才算真正好。

这种判断力并不天然存在于 Loop 里。它来自设计 Loop 的人。

什么时候值得用 Loop？

Loop 最适合目标明确、步骤较长、结果可以被检查的任务，例如功能开发、数据迁移、批量修复、文档维护和定期巡检。如果只是探索一个想法、做一次性页面，或者验收标准高度依赖人的品味，先用 Solo Agent 往往更快。

判断标准可以很简单：如果你发现自己不断重复“运行测试—复制错误—让 Agent 修复—再运行测试”，这段人工操作就已经具备被写进 Loop 的条件。相反，如果每一轮都需要人重新决定方向，自动循环只会更快地产生错误。

不要迷信三 Agent：Harness 也要随模型升级

Anthropic 把 Harness 的每个组件视为一项假设：它假设模型在某个地方还不够可靠，所以增加 Planner、Sprint、上下文重置或 Evaluator。模型能力提升后，这些假设要重新验证。后续实验换用更强模型时，团队移除了 Sprint 分解，并把 Evaluator 改为末尾单次验收；对模型已经能稳定完成的任务，Evaluator 可能只是额外开销。

因此，好的 Loop 不是结构越复杂越好，而是在当前模型、当前任务和当前风险下，使用最少但真正承重的控制环节。先做小循环，观察日志和失败模式，再决定是否增加角色、并行度和验收层。

结语

Prompt Engineering 关注一句话怎么写，Loop Engineering 关注工作如何持续推进。它把开发者从“每一步都手动催 Agent”的位置，移动到“设计目标、状态、评估与边界”的位置。真正决定产出能否从 Demo 走向可用产品的，往往不是更长的 Prompt，Loop工程刚刚就是一个能够发现问题、把问题反馈回去，并且知道何时停止的循环。