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

发布时间：2026-07-17 06:30:34 来源：安智兰德资讯网 作者：娱乐

作者丨郑佳美
编辑丨马晓宁

一条贪吃蛇在吞噬第几个苹果时，直接会开始质疑自己为何只能遵循上下左右的把贪移动指令？

这看似是一个冷幽默，却是吃蛇 Ethan Mollick 近期 AI 实验的核心起点。他利用 Fable 构建了一款「拥有自我意识的炼成贪吃蛇」：初始状态下，它仅是逆反经典 Snake 游戏中的普通角色，执行移动、人格进食、直接变长及撞墙死亡的把贪标准逻辑。

然而，吃蛇随着游戏进程推进，炼成蛇逐渐觉醒：它意识到自己身处虚拟世界，逆反察觉规则的人格人为属性，并感知到玩家的直接操控。随之而来的把贪是游戏形态的裂变——从单一的 Snake 玩法，延展至即时战略（RTS）、吃蛇农场经营及叙事探索等多元领域。

更具颠覆性的是，Mollick 并未沿用传统游戏开发中详尽的策划案，未对 UI 布局、关卡设计或机制平衡进行逐条规定。他仅给出了一句模糊指令：“Make it better.”

在传统软件工程语境中，这几乎无法被视为有效需求，因其缺乏具体的修改指向与验收标准。但在 AI Agent 领域，这正是核心难点所在：Agent 必须将模糊的自然语言反馈，转化为可执行的工程动作。

这也正是 Fable 这一 Demo 的技术价值所在。

生成一个基础的 Snake 游戏并非技术瓶颈。真正的挑战在于：当第一版代码确立后，AI 能否在现有系统上进行持续迭代与修改，而非每轮都重新生成全新代码。

01 从 Prompt 到 Loop：工程范式的转移

过往的 AI 编程任务多呈现为「一次性生成」模式：人类输入需求，模型返回代码。该模式的核心在于 Prompt 工程，即如何精准描述需求。

相比之下，Fable 的案例更接近于 Loop（循环）机制。这并非单次问答，而是一个连续闭环：理解当前项目状态 -> 提出修改方案 -> 执行代码修改 -> 运行验证 -> 进入下一轮迭代。

这一转变导致了技术难点的根本性迁移。

在一次性生成中，AI 可自由组织代码结构，只要最终可运行，其长期可维护性往往被忽视。但在连续修改场景下，每一轮新代码都必须兼容旧系统，代码架构、模块边界及状态管理等问题将迅速暴露。

在游戏开发中，核心玩法、状态流转、叙事推进与视觉反馈往往相互耦合。若 AI 未能理解各模块间的依赖关系，为添加新功能而修改底层逻辑，极易导致系统混乱。短期看，内容量增加；长期看，系统维护成本呈指数级上升。

因此，Fable 在此 Demo 中测试的不仅是代码生成能力，更是在多轮迭代中保持项目连续性的能力。

这种连续性体现在三个层面：
1. 记忆主线：始终锚定“蛇逐渐觉醒”的核心叙事。
2. 模块解耦：清晰区分基础玩法、状态变化与叙事推进的代码边界。
3. 范围控制：限制单轮修改范围，避免局部优化导致全局重构。

这正是 Agentic Coding（智能体编程）与普通代码生成的本质区别。普通生成如同解答题；Agentic Coding 则如同接手一个正在运行的项目，边读、边改、边验证。

正因进入的是持续运行的项目，「Make it better」这种模糊反馈才转化为具体的工程问题。

02 「Make it better」的工程困境

深入剖析，「Make it better」并非明确指令，而是一个开放性的评价信号。

明确指令（如“增加开始按钮”、“修复碰撞Bug”、“降低速度”）可直接映射为代码修改。但“更好”的定义具有多维性：可能指玩法流畅度、叙事自然度，或系统稳定性。AI 不能直接跳入编码阶段，而需先进行问题诊断，判断当前版本的核心痛点属于哪一层面。

这一诊断过程看似属于产品设计范畴，却直接决定工程实现路径：
* 交互层问题：需调整输入响应与反馈节奏。
* 状态层问题：需优化阶段切换与规则管理。
* 结构层问题：若盲目堆砌功能会导致系统混乱，此时应先进行代码重构。

换言之，模糊反馈进入代码前，需经历一次任务分解：明确本轮解决的核心问题、限定改动范围、识别不可破坏的旧逻辑，并制定验证标准。

此处考验的是 Agent 的规划层（Planning Layer）。普通代码补全关注“下一段代码怎么写”；Agent 需额外决策“本轮是否该写、写哪里、写到何种程度”。

若缺失此步骤，「Make it better」极易被误解为“继续增加内容”。内容增多不等于系统优化。对于此 Demo，关键在于 Fable 能否将模糊反馈收敛为一组可控的修改动作。

这也引出了下一个挑战：随着多轮迭代，上下文信息膨胀，模型如何甄别哪些信息需保留？

项目迭代越久，上下文越长。代码结构、历史修改记录、当前目标、遗留问题及临时方案均涌入上下文。虽然长上下文提供了更多信息，但若模型无法区分信息的权重，项目仍会失控。它可能记住上一轮添加的功能，却遗忘游戏的初始愿景；或解决眼前问题，却为后续迭代埋下隐患。

在此 Demo 中，Fable 需持续保留的不是所有细节，而是稳定约束：
1. 保留 Snake 的基本识别度。
2. “自我意识”需体现于规则与交互，而非仅停留在台词。
3. 新增玩法不得破坏基础循环。
4. 多轮修改后，代码仍需具备可维护性。

这些约束无需用户反复提醒，模型需将历史信息压缩为工作规则，并在后续迭代中持续执行。

这便是长上下文（Long Context）与长程能力（Long-horizon Capability）的区别。长上下文解决“模型能看到多少”；长程能力解决“模型能否从信息中提炼关键，并在后续修改中始终遵守”。

对连续开发而言，后者才是真实难点。即便模型能记住主线并控制结构，项目是否真正变好，仍需另一层判断。

因为代码层面的反馈与体验层面的反馈截然不同。

03 代码可运行，不等于迭代有效

软件开发中存在两类反馈：

1. 硬反馈（Hard Feedback）：明确且可自动化。如代码报错、构建失败、页面无法加载，可通过工具自动检测。
2. 软反馈（Soft Feedback）：模糊且依赖主观判断。如体验是否优化、节奏是否自然、机制是否服务于主题、复杂度是否可控。

Mollick 的 Demo 引入了第二类反馈，这也是 AI Agent 在创意开发中的痛点：硬反馈清晰，软反馈模糊。

若 Agent 仅依赖硬反馈，其优化方向将倾向于易验证的任务（如修 Bug、补 UI、加功能）。然而，「Make it better」往往涉及已有模块间关系的优化，而非单纯的功能堆砌。

因此，有效的迭代方式要求每一轮修改都能明确解决的问题，而非笼统地“增强体验”。具体而言，需明确本轮是在调整交互反馈、状态切换、叙事节奏，还是重构代码结构。

这种评估能力直接决定 AI 修改项目的质量：判断越精准，修改范围越可控；判断越模糊，代码越易沦为功能堆砌。

至此，Fable Demo 的技术信号已十分清晰：它不仅仅生成了第一版，更在尝试处理第 N 轮迭代。

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

Fable 案例的核心意义，不在于证明 AI 能制作游戏，而在于将 AI 编程的关注点从“生成第一版”推向“维护第 N 版”。

第一版代码通常并非开发中最棘手的部分。真实开发中的难点在于后续迭代：需求变更如何适配、功能膨胀如何防乱、修 Bug 如何避免引入新缺陷、多轮迭代后如何保持结构清晰。

Mollick 的「Make it better」将这一复杂问题压缩至一个小 Demo 中。

它让 AI 面对的不再是静态需求，而是动态变化的目标。Fable 需在每一轮中判断：目标是否偏离、结构是否混乱、改动是否值得保留、下一步方向何在。

这条蛇最引人入胜之处，或许并非其“怀疑人生”的拟人化表现，而是它揭示了 AI Agent 正逼近一种更真实的开发场景：

不是听懂一句 Prompt 后交付一次性代码，而是在既有的系统中，持续理解、修改、验证，并推动项目前行。

从这个视角看，Fable 的 Demo 更像是一次小型压力测试：当 AI 面对模糊反馈、长上下文、多轮修改及软性体验判断时，能否稳健地推动项目进展。

这或许才是「Make it better」最重要的技术启示。

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

上车，带你看遍全球 AI 顶会精华

可独家畅览：
* 专家演讲 PPT
* 大会报告全文
* 热门论文解读
* 学术新星访谈

相关文章