一条贪吃蛇在捕获到第几个苹果时，会开始质疑自己为何只能沿着上下左右方向移动？

这听起来像是一个冷笑话，但 Ethan Mollick 最近演示的 AI 实验，几乎就是从这样一个问题起步的。他让 Fable 构建了一款“具备自我意识的贪吃蛇游戏”：蛇起初只是经典 Snake 中的那条蛇，负责移动、吃食物、增长长度、撞墙死亡。但随着游戏推进，它逐渐意识到自己存在于一个游戏世界，发现规则是人为设定的，并察觉到玩家正在控制它。随后，游戏开始变形，玩法从 Snake 延伸至 RTS、农场经营和叙事探索等多种形态。

更有趣的是，Mollick 并未像传统游戏制作人那样提供一份详细的策划方案。他没有逐一规定 UI 如何调整、关卡怎样设计、机制如何平衡。很多时候，他仅仅给出了一句话：“Make it better。”这句指令在传统软件开发中几乎无法被视为有效需求。它既没有指明修改方向，也未定义合格结果。然而，对 AI Agent 而言，这正是挑战所在：它必须将一则模糊的反馈，转化为下一步可执行的工程动作。

这也是 Fable 这个演示真正值得分析的原因。如果仅仅是生成一个 Snake，技术难度并不高。真正的难点在于：当第一版已经存在之后，AI 能否在旧系统上持续进行修改，而不是每次迭代都重新生成一套完整的方案。

从 prompt 到 loop：AI 编程的范式转变

过去，许多 AI 编程任务更像是一次性生成。人给出需求，模型返回代码。这种模式的核心在于 prompt，即人们如何将需求表述清楚。但 Fable 这个案例更接近于 loop。所谓 loop，并非模型回答一次就结束，而是进入一个连续循环过程：先理解当前项目，再提出修改方案，随后修改代码、运行、检查结果，并进入下一轮迭代。

这一变化会导致技术难点发生转移。一次性生成时，AI 可以按照自己的方式组织代码。只要最终能运行，代码结构是否适合长期维护，通常不会立即暴露。但连续修改时，每一轮新改动都必须衔接在旧系统之上，代码结构、模块边界、状态管理等问题很快就会浮现。在一个游戏项目中，基础玩法、状态变化、叙事推进以及画面反馈往往会彼此影响。AI 若未能理解这些部分之间的关联，就可能在添加新效果时打乱原有的运行逻辑。短期来看，内容确实增多了；但经过多轮迭代后，系统会变得越来越难以维护。

因此，Fable 在这个演示中被检验的，不只是能否写出代码，更是能否在多轮修改中维持项目的连续性。这种连续性大致体现在几个层面：它需要记住游戏主线仍然是“蛇逐渐意识到自己身处游戏中”；它要区分当前代码中哪些部分负责基础玩法、哪些负责状态变化、哪些负责叙事推进；同时，它还必须控制每一轮的修改范围，避免为了一个局部效果而重写过多的旧逻辑。

这正是 agentic coding 与普通代码生成之间的差异。普通代码生成更像完成一道题目；agentic coding 则更像是进入一个已经运行的项目，边阅读、边修改、边验证。也正因为它介入的是一个持续运行的项目，“Make it better”这种模糊反馈才会变成一个工程难题。

「Make it better」难在何处：模糊反馈的工程化分解

更详细地来说，“Make it better”并非明确指令，而是一个开放性评价。明确指令相对容易处理，例如“添加一个开始按钮”“修复碰撞错误”“降低速度”，这些都能直接对应代码修改。但“变得更好”并没有如此清晰的指向。它可能意味着玩法更流畅，可能指叙事更自然，也可能表示系统更稳定。AI 不能直接跳转到写代码阶段，而必须先判断当前版本的问题属于哪一类。这一步看似是产品判断，但它会直接影响工程实现。

如果问题出在交互层，改动可能涉及输入响应和反馈节奏；如果问题出在状态层，改动可能涉及阶段切换和规则管理；如果问题出在结构层，继续添加功能可能反而让系统更混乱，此时先整理代码会更稳妥。也就是说，模糊反馈在进入代码之前，需要经历一次任务分解：这一轮要解决什么问题，改动应限制在哪个范围，哪些旧逻辑不能破坏，修改完成后如何确认没有引入新问题。

这里比较考验 Agent 的是“规划层”。普通代码补全更关注下一段代码怎么写；Agent 则必须多做一步，先决定这一轮到底是否应该写、写在哪里、写到什么程度。如果缺少这一步，“Make it better”很容易被理解为“继续添加内容”。内容变多，并不代表系统一定变好。对于这个演示而言，更关键在于 Fable 能否将一句模糊反馈收敛为一组可控的修改动作。

这也会自然引出下一个问题：项目修改得越久，历史信息越多，模型如何知晓哪些内容需要继续保留？到多轮修改阶段，上下文会变得越来越长。项目持续越久，模型需要处理的信息就越庞杂。代码结构、历史修改记录、当前目标、旧问题、临时方案都会被纳入上下文。长上下文当然有帮助，因为模型至少能查看到更多历史信息。但如果模型只是把更多内容塞进上下文，却无法区分哪些信息仍然重要，项目仍然可能失控。它也许记得上一轮添加了什么，却忘记了游戏最初想要表达什么；也许解决了眼前的问题，却让后续修改变得更加困难。

在这个演示中，Fable 需要持续保留的不是所有细节，而是几个稳定约束：游戏仍然要保留 Snake 的基本识别度；“自我意识”不能只停留在台词中，而应影响规则和交互；新增玩法不能破坏原有的基础循环；多轮修改之后，代码必须还能继续维护。这些约束不会每次都靠用户重新提醒。模型需要把历史信息压缩为一组工作规则，并在后续修改中持续应用。

这就是长上下文与长程能力的区别。长上下文解决的是“模型能看到多少”；长程能力处理的是“模型能否从这些信息中抓住关键，并在后续修改中一直遵守”。对于连续开发而言，后者更接近实际难点。不过，即使模型能记住主线、控制结构，项目是否真正变好，仍需要另一层判断。因为代码层面的反馈与体验层面的反馈并非同一回事。

代码能跑，不代表迭代有效：硬反馈与软反馈的鸿沟

在软件开发中，有一类反馈非常明确：代码是否报错，构建能否通过，页面能否正常打开。这些都可以通过工具自动检查。但 Mollick 的这个演示还涉及另一类反馈：体验是否变好。这就没那么容易自动判断了。程序运行成功，只说明它通过了工程层面的最低检验。它不能说明游戏节奏是否更自然，新增机制是否服务于主题，也不能说明多轮修改之后，系统是否变得更清晰。

这也是 AI Agent 进行创意型开发时比较棘手的一点：硬反馈明确，软反馈模糊。硬反馈来自代码和工具，例如报错、测试、构建日志。软反馈来自体验和主观判断，比如玩家是否理解规则变化，玩法是否与叙事相互支撑，复杂度是否仍在可控范围内。如果一个 Agent 只依赖硬反馈，它会倾向于做容易验证的事情，比如修复错误、补充界面、添加功能。但“Make it better”很多时候并非仅仅添加功能，而是让已有部分之间的关系更加顺畅。

因此，比较有效的迭代方式，是每一轮修改都能清晰说明它解决了什么问题。不是笼统地“增强体验”，而是更具体地指出：这一轮是在调整交互反馈、状态切换、叙事节奏，还是优化代码结构。这类评估能力会直接影响 AI 改进项目的质量。判断越清晰，修改范围越容易收窄；判断越模糊，代码越容易变成堆砌。

至此，Fable 这个演示的技术信号已经比较明确了：它不只是生成了第一版，而是在尝试处理第 N 轮修改。

从生成第一版，到维护第 N 版：AI 编程的真正进阶

Fable 这个案例的意义，不在于证明 AI 会做游戏，而在于它将 AI 编程的关注点从“生成第一版”推向了“维护第 N 版”。第一版代码通常不是最麻烦的。真实开发中，更麻烦的是后续的修改：需求变化时如何调整，功能增加时如何避免混乱，修复 bug 时如何不引入新 bug，迭代多轮后如何保持清晰的结构。

Mollick 的“Make it better”正好将这个问题压缩进了一个小型演示中。它让 AI 面对的并非一份明确需求，而是一个持续变化的目标。Fable 需要在每一轮中判断：目标是否偏离，结构是否混乱，改动是否值得保留，下一步应该推进哪个方向。

这条蛇最有意思的地方，或许并不在于它会“怀疑人生”，而在于它让我们看到 AI Agent 正接近一种更真实的开发场景：不是听懂一句 prompt 然后交出一份代码，而是在一个已经存在的系统中持续理解、修改、验证，再继续往前走。从这个角度看，Fable 的演示更像是一个小型压力测试：当 AI 面对模糊反馈、长上下文、多轮修改以及软性体验判断时，它能否将项目稳步推进。这或许才是“Make it better”最重要的意义。

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