一句「Make it better」，Fable 5直接把贪吃蛇炼成「逆反人格」

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

    作者丨 郑佳美

    编辑丨 马晓宁

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

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

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

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

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

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

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

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

01

从 prompt 到 loop

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

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

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

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

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

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

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

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

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

02

「Make it better」难在哪

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

主题：游戏