文章作者、来源：雷峰网

一个小游戏，藏着 AI Agent 的工程考题。

一条贪吃蛇在吃到第几个苹果时，会开始怀疑自己为什么只能向上下左右移动？

这听起来像个冷笑话，但 Ethan Mollick 最近展示的 AI 实验，差不多就是从这个问题开始的。

他让 Fable 做了一个“有自我意识的贪吃蛇游戏”：蛇一开始只是经典 Snake 里的那条蛇，移动、吃东西、变长、撞墙死亡。

但随着游戏推进，它逐渐意识到自己活在一个游戏里，意识到规则是人为设定的，意识到玩家正在控制它。然后，游戏开始变形，玩法也从 Snake 延展到 RTS、农场经营和叙事探索等不同形态。

更有意思的是，Mollick 并没有像传统游戏制作人那样给出一份详细策划案。他没有逐项规定 UI 怎么改、关卡怎么设计、机制怎么平衡。很多时候，他只是给出一句话：“Make it better.”

这句话在传统软件开发里几乎不能算需求。它没有说明改哪里，也没有说明什么结果算合格。但对 AI Agent 来说，这正是难点所在：它必须把一个模糊反馈，翻译成下一步可以执行的工程动作。

这也是 Fable 这个 demo 真正值得分析的地方。

如果只是生成一个 Snake，技术难度并不高。真正难的是：当第一版已经存在之后，AI 能不能在旧系统上持续修改，而不是每一轮都重新生成一套东西。

从 prompt 到 loop

过去很多 AI 编程任务，更像一次性生成。人给出需求，模型返回代码。这个模式里的关键是 prompt，也就是人如何把需求说清楚。

但 Fable 这个案例更接近 loop。所谓 loop，不是模型回答一次就结束，而是进入一个连续过程：先理解当前项目，再提出修改方案，然后改代码、运行、检查结果，再进入下一轮。

这个变化会让技术难点发生转移。

一次性生成时，AI 可以按照自己的方式组织代码。只要最后能跑，结构是否适合长期维护，并不会马上暴露。但连续修改时，每一轮新改动都要接在旧系统上，代码结构、模块边界、状态管理这些问题很快就会浮出来。

在一个游戏项目里，基础玩法、状态变化、叙事推进和画面反馈往往会彼此影响。AI 如果没有理解这些部分之间的关系，就可能为了加一个新效果，改乱原来的运行逻辑。短期看，内容确实变多了；但多轮之后，系统会越来越难继续维护。

所以，Fable 在这个 demo 里被测试的，不只是会不会写代码，而是能不能在多轮修改中保持项目的连续性。

这种连续性大致落在几个层面：它要记住游戏主线仍然是“蛇逐渐意识到自己在游戏中”；它要分清当前代码中哪些部分负责基础玩法，哪些部分负责状态变化，哪些部分负责叙事推进；它还要控制每一轮的修改范围，避免为了一个局部效果重写过多旧逻辑。

这就是 agentic coding 和普通代码生成的差别。普通代码生成更像完成一道题；agentic coding 更像进入一个已经运行的项目，边读、边改、边验证。

也正因为它进入的是一个持续运行的项目，“Make it better” 这种模糊反馈才会变成一个工程问题。

「Make it better」难在哪

更详细的讲，“Make it better” 不是一个明确指令，而是一个开放评价。

明确指令比较容易处理。比如“增加一个开始按钮”“修复碰撞错误”“把速度调慢”，这些都能直接对应到代码修改。但“变得更好”没有这么清楚。

它可能指玩法更顺，也可能指叙事更自然，还可能指系统更稳定。AI 不能直接跳到写代码，而要先判断当前版本的问题属于哪一类。这一步看起来像产品判断，但它会直接影响工程实现。

如果问题出在交互层，改动可能会落到输入响应和反馈节奏；如果问题出在状态层，改动可能会落到阶段切换和规则管理；如果问题出在结构层，继续加功能反而可能让系统更乱，先整理代码会更稳。

也就是说，模糊反馈进入代码之前，需要经过一次任务分解：这轮要解决什么问题，改动应该限制在哪个范围，哪些旧逻辑不能被破坏，改完后用什么方式确认它没有引入新的问题。

这里比较考验 Agent 的，是“规划层”。普通代码补全更关注下一段代码怎么写；Agent 要多做一步，先决定这一轮到底该不该写、该写哪里、写到什么程度。

如果少了这一步，“Make it better” 很容易被理解成“继续加内容”。内容变多了，不一定代表系统变好了。对这个 demo 来说，更关键的是 Fable 能否把一句模糊反馈，收敛成一组可控的修改动作。

这也会自然带出下一个问题：项目改得越久，历史信息越多，模型怎么知道哪些东西需要继续保留？

之后到了多轮修改阶段，上下文就会变得越来越长。

项目做得越久，模型需要处理的信息就越多。代码结构、历史修改、当前目标、旧问题、临时方案，都会进入上下文。长上下文当然有帮助，因为模型至少能看到更多历史信息。

如果模型只是把更多内容塞进上下文，却分不清哪些信息仍然重要，项目仍然会失控。它可能记得上一轮加过什么，却忘了这个游戏最初想表达什么；也可能解决了眼前问题，却让后续修改变得更难。

在这个 demo 里，Fable 需要持续保留的不是所有细节，而是几个稳定约束：游戏仍然要保留 Snake 的基本识别度；“自我意识”不能只停留在台词里，而要影响规则和交互；新增玩法不能破坏原来的基础循环；多轮修改之后，代码还要能继续维护。

这些约束不会每次都由用户重新提醒。模型需要把历史信息压缩成一组工作规则，并在后续修改中持续使用。

这就是长上下文和长程能力的区别。长上下文解决的是“模型能看到多少”；长程能力处理的是“模型能不能从这些信息里抓住关键，并在后续修改里一直遵守”。

对连续开发来说，后者更接近实际难点。不过，就算模型能记住主线、控制结构，项目是否真的变好了，仍然需要另一层判断。

因为代码层面的反馈和体验层面的反馈并不是一回事。

代码能跑，不代表迭代有效

软件开发里，有一类反馈很明确：代码有没有报错，构建能不能通过，页面能不能打开。这些都可以通过工具检查。

但 Mollick 这个 demo 还有另一类反馈：体验有没有变好。这就没那么容易自动判断。

程序运行成功，只能说明它通过了工程层面的最低检查。它不能说明节奏是否更自然，新增机制是否服务于主题，也不能说明多轮修改之后，系统有没有变得更清楚。

这也是 AI Agent 做创意型开发时比较难的一点：硬反馈清楚，软反馈模糊。

硬反馈来自代码和工具，比如报错、测试、构建日志。软反馈来自体验和判断，比如玩家是否理解规则变化，玩法是否和叙事互相支撑，复杂度是否还在可控范围内。

如果一个 Agent 只依赖硬反馈，它会倾向于做容易验证的事，比如修错、补界面、加功能。但 “Make it better” 很多时候并不只是加功能，而是让已有部分之间的关系更顺。

所以，比较有效的迭代方式，是每一轮修改都能说清楚它解决了什么问题。不是笼统地“增强体验”，而是更具体地说明：这一轮是在调整交互反馈、状态切换、叙事节奏，还是代码结构。

这类评估能力会直接影响 AI 改项目的质量。判断越清楚，修改范围越容易收住；判断越模糊，代码越容易变成堆料。

到这里，Fable 这个 demo 的技术信号也就比较清楚了：它不只是生成了第一版，而是在尝试处理第 N 轮修改。

从生成第一版，到维护第 N 版

Fable 这个案例的意义，不在于证明 AI 会做游戏，而在于它把 AI 编程的关注点从“生成第一版”推到了“维护第 N 版”。

第一版代码通常不是最麻烦的。真实开发里，更麻烦的是后续修改：需求变了怎么改，功能多了怎么不乱，修 bug 时怎么不引入新 bug，迭代多轮以后怎么还能保持清晰结构。

Mollick 的 “Make it better” 正好把这个问题压缩进了一个小 demo 里。

它让 AI 面对的不是一份清楚需求，而是一个持续变化的目标。Fable 需要在每一轮里判断：目标有没有偏，结构有没有乱，改动是否值得保留，下一步应该推进哪里。

这条蛇最有意思的，或许并不是因为它会“怀疑人生”，而是因为它让我们看到 AI Agent 正在接近一种更真实的开发场景：不是听懂一句 prompt，然后交出一份代码；而是在一个已经存在的系统里，持续理解、修改、验证，再继续往下走。

从这个角度看，Fable 的 demo 更像是一个小型压力测试：当 AI 面对模糊反馈、长上下文、多轮修改和软性体验判断时，它能不能把项目稳稳地往前推。

这或许才是 “Make it better” 最重要的意义。

参考链接：https://x.com/emollick/status/2069207757199200408