Fable 5 凭 Make it better 将贪吃蛇炼成有自我意识的 AI Agent
速览
Ethan Mollick 利用 Fable 5 演示了 AI Agent 如何通过“Make it better”等模糊反馈，将经典贪吃蛇迭代为具备自我意识的复杂游戏。该案例揭示了 AI 编程从一次性生成向连续循环（loop）模式的转变，重点考验 Agent 在多轮修改中保持代码结构连续性和项目主线的能力。这标志着 AI 开发难点从代码补全转向了任务分解、长程约束管理及软硬反馈的综合判断。
AI 深度解读
背景
Ethan Mollick 近期展示了一个基于 AI Agent Fable 的实验：让 AI 开发一款具有“自我意识”的贪吃蛇游戏。与传统游戏开发中提供详细策划案不同，Mollick 并未逐项规定 UI 或关卡设计，而是仅通过一句模糊的指令 “Make it better”（让它变得更好）来驱动迭代。
这一实验的核心价值不在于生成一个基础的 Snake 游戏，而在于测试 AI 在已有系统上进行多轮连续修改的能力。它揭示了 AI 编程从“一次性代码生成”向“持续性工程维护”转变过程中所面临的工程挑战，特别是如何处理模糊反馈、保持代码结构连续性以及平衡硬性与软性反馈。
核心内容
1. 从一次性生成到 Agentic Coding 的范式转移
传统的 AI 编程任务往往是一次性的：用户给出明确需求（Prompt），模型返回代码。这种模式下，代码结构是否适合长期维护并不立即暴露。然而，Fable 的案例更接近于一个闭环（loop）过程：理解当前项目 -> 提出修改方案 -> 修改代码 -> 运行检查 -> 进入下一轮。
在这种连续修改的模式下，技术难点发生了转移。每一轮新改动都必须接在旧系统上，代码结构、模块边界和状态管理等问题会迅速浮现。如果 AI 无法理解基础玩法、状态变化、叙事推进和画面反馈之间的相互关系，为了添加新效果而破坏原有逻辑的风险将大幅增加。因此，Fable 被测试的重点是其在多轮修改中保持项目连续性的能力，即 Agentic Coding（智能体编程）。与普通代码生成不同，Agentic Coding 要求 AI 进入一个已运行的项目，边读、边改、边验证。
2. 模糊反馈的工程化分解
“Make it better” 是一个开放评价而非明确指令。AI 不能直接跳入编码，而必须先进行任务分解，判断当前版本的问题属于哪一类：
- 交互层问题：需调整输入响应和反馈节奏。
- 状态层问题：需调整阶段切换和规则管理。
- 结构层问题：若继续加功能会导致系统混乱，则需先整理代码结构。
这考验的是 Agent 的“规划层”能力。普通代码补全关注下一段代码怎么写，而 Agent 必须先决定这一轮该不该写、写哪里、写到什么程度，以及改完后如何确认未引入新问题。若缺乏这一步，AI 容易将“变得更好”误解为“继续堆料”，导致系统失控。
3. 长上下文与长程能力的区别
随着多轮修改的进行，上下文信息（代码结构、历史修改、当前目标等）会迅速膨胀。虽然长上下文让模型能看到更多信息，但如果模型无法区分哪些信息重要，项目仍会失控。
Fable 需要持续保留的不是所有细节，而是几个稳定约束：
- 游戏保留 Snake 的基本识别度。
- “自我意识”不仅停留在台词，更要影响规则和交互。
- 新增玩法不破坏基础循环。
- 代码在多轮修改后仍具备可维护性。
这体现了“长程能力”的重要性：模型需将历史信息压缩为一组工作规则，并在后续修改中持续遵守。长上下文解决的是“能看到多少”，而长程能力解决的是“能否抓住关键并持续遵守”，后者才是连续开发的真正难点。
4. 硬反馈与软反馈的平衡
软件开发中存在两类反馈：
- 硬反馈：代码报错、构建失败、页面无法打开等，可通过工具自动检查。
- 软反馈：体验是否变好、节奏是否自然、机制是否服务于主题等，难以自动判断。
如果 AI 仅依赖硬反馈，会倾向于做容易验证的事（如修错、加功能），而忽略让已有部分关系更顺畅的优化。有效的迭代方式要求每一轮修改都能明确解决的具体问题（如调整交互、状态或结构），而非笼统地“增强体验”。这种评估能力直接决定了 AI 修改项目的质量，避免代码变成无序的堆料。
关键要点
- 工程难点转移：AI 编程的难点从“如何生成第一版代码”转移到了“如何在旧系统上持续修改并保持结构稳定”。
- Agentic Coding 定义：区别于一次性生成，Agentic Coding 强调在已运行项目中持续理解、修改和验证，要求 AI 具备维护项目连续性的能力。
- 模糊反馈的处理：“Make it better” 需要 AI 具备规划能力，先判断问题层级（交互、状态或结构），再决定修改范围，避免盲目堆砌功能。
- 长程能力 vs 长上下文：长上下文仅提供信息量，长程能力要求模型从海量信息中提取关键约束并长期遵守，这是多轮迭代成功的关键。
- 软硬反馈结合：仅靠硬反馈（代码正确性）不足以优化创意型开发，AI 需具备对软反馈（用户体验、叙事节奏）的判断力，才能做出有意义的迭代。
意义与影响
Fable 的这个 Demo 具有里程碑式的意义，它标志着 AI 编程的关注点从“生成第一版”推向了“维护第 N 版”。
- 模拟真实开发场景：真实开发中最麻烦的不是初始构建，而是后续的需求变更、功能扩展和 Bug 修复。Mollick 的实验将这一复杂过程压缩进了一个小 Demo，展示了 AI 在面对模糊反馈、长上下文和多轮修改时的压力测试结果。
- 验证 AI 的工程化潜力：该实验证明，AI 正在接近一种更真实的开发场景——不是听懂一句 Prompt 就交付出代码，而是在一个已存在的系统中，持续理解现状、执行修改、验证结果并推进下一步。
- 重新定义 AI 辅助编程的价值：未来的 AI 编程助手不仅需要能写代码，更需要具备类似资深工程师的“规划层”思维，能够评估修改的影响范围，维护代码架构的整洁，并在模糊需求下做出合理的工程决策。
这一案例表明，AI 在创意型开发中的价值不仅在于加速初始生成，更在于通过智能体能力实现可持续、高质量的长期迭代。