Fable 5 实战项目观察：用户到底在用它做什么

讨论 Fable 5 时，最容易落入两个极端：一种只盯着 benchmark，另一种只转发几个惊艳 demo。真正有价值的观察应该落到项目层：谁在用它，做了什么，接了哪些工具，提示词怎么写，为什么这个任务需要 Fable 5 这种长任务模型，而不是普通聊天模型。

下面整理的是今天更适合跟进的一组 Fable 5 项目和项目形态。它们不全是开源仓库，有些是企业内部迁移，有些是产品化软件，有些是研究者做出的工作台，有些是可复现的小游戏和网页生成范式。判断一个 Fable 5 项目是否值得看，不只看结果是否炫酷，而要看它有没有把模型能力接进真实工程循环：输入、规划、执行、验证、回滚和人类验收。

项目总览

这张表里最重要的不是“有哪些链接”，而是任务形态。Fable 5 级模型真正的使用场景通常有三个特征：上下文长、步骤多、结果可验证。只要缺少其中一个特征，换一个便宜模型、专用工具或传统脚本可能更合适。

1. Stripe Ruby 迁移：模型作为迁移执行器

这个案例最值得工程团队研究。公开材料提到的核心信息是：大型 Ruby 代码库迁移被压缩到非常短的执行周期。它不只是“让模型帮忙改代码”，而是把模型放进迁移流水线。

这类任务通常包含几层技术工作：

• 先扫描代码库，找出要迁移的 API、类、调用点和隐式依赖。
• 把迁移规则写成可执行模式，而不是让模型每次自由发挥。
• 用 codemod 或脚本处理确定性修改。
• 让模型处理脚本覆盖不到的上下文判断。
• 每个批次运行测试、类型检查、lint 和关键业务回归。
• 把失败样本回灌给下一轮迁移提示。

Fable 5 的价值在中间两层。确定性替换不需要大模型，纯人工又无法在短时间里读完复杂依赖。强模型适合做的是“半结构化迁移”：看懂调用语义，判断一个修改是否需要连带改测试、文档、fixture、mock、配置或调用链。

一个更稳的提示词不应该写成“帮我迁移这个仓库”，而应该写成迁移协议：

你是迁移执行器，不是自由重构者。

目标：
把旧 Ruby API A 迁移到新 API B，保持公共行为不变。

工作顺序：
1. 先列出所有候选调用点，按风险分为机械替换、需要人工判断、暂不处理。
2. 每次只处理一个风险分组。
3. 修改后运行指定测试。如果测试失败，先定位失败原因，不要继续扩大改动。
4. 不允许顺手重构命名、目录和无关样式。
5. 最终输出修改文件、测试结果、剩余风险和需要人工确认的调用点。

验收：
- 行为兼容。
- 测试通过。
- 没有扩大公共 API。
- 每个未迁移点都有原因。

这里的提示词像工程合同，而不是聊天请求。Fable 5 这类模型越强，越要用这种方式约束它。因为能力越强，它越可能“顺手做好更多事”，而迁移任务最怕的就是无关改动混进同一个批次。

真正的创新点在于：大模型不是替代迁移系统，而是补上迁移系统里最难自动化的语义判断。以后大型代码迁移可能会变成三段式：静态分析找范围，脚本做机械改动，强模型处理长尾语义。

2. 非结构化调查分析器：把 19 页规格变成研究工具

另一个很有启发的项目，是把长规格文档变成非结构化调查答案分析器。这个任务表面上是“写一个数据分析工具”，实际上需要同时理解研究方法、分类体系、UI、数据清洗和可解释输出。

非结构化调查答案很麻烦，因为它不是简单的选择题。受访者会写长句、错别字、双重含义、隐含情绪、多个主题和互相矛盾的意见。研究者需要的不是普通摘要，而是可操作的分析工作台：

• 能导入 CSV 或表格数据。
• 能定义分类 schema。
• 能标注一个回答属于哪些主题。
• 能统计主题频率、共同出现关系和代表性原文。
• 能让研究者覆盖模型判断。
• 能导出可复查结果。

这个项目的技术栈可以很朴素：前端用 React 或 Next.js，数据处理用 Python/pandas 或浏览器端表格解析，分类层用模型 API，存储用 SQLite 或本地 JSON。难点不在技术新，而在需求结构复杂。一个 19 页规格里可能同时写着目标用户、分类规则、统计口径、排除条件、异常样本、交互细节和导出格式。

适合 Fable 5 的提示词应该先让它产出中间设计，而不是直接写代码：

我会给你一份研究工具规格。你的任务不是立即实现，而是先把规格拆成产品协议。

请输出：
1. 数据模型：输入表、回答、主题、置信度、人工覆盖、导出记录。
2. 工作流：导入、预处理、自动分类、人工复核、统计、导出。
3. 分类规则：哪些判断必须可解释，哪些可以合并，哪些必须保留原文。
4. UI 页面：最少需要几个视图，每个视图的核心操作。
5. 验收样本：用 10 条模拟回答覆盖边界情况。

在我确认后，再进入实现。

这个提示的关键是把“长文档理解”转化为“产品协议”。Fable 5 的强项不是一句话答对，而是能在长规格里保持多个约束不丢失。研究工具正好需要这种能力：既要产品化，又不能把研究假设偷偷改掉。

更深一层看，这类项目代表了一个趋势：很多过去“不值得做成软件”的专业小工具，会因为强模型而变得可行。它们市场很小，但对具体人群价值很高。研究者、律师、医生、教师、投研、运营都可能有类似需求：不是通用 SaaS，而是围绕一份复杂工作规程生成一个半定制工具。

3. 视觉通关实验：小游戏不是玩具，而是长期 agent 测试

视觉通关实验看起来像娱乐 demo，但它比普通网页生成更能测试模型能力。只看画面玩完整个游戏，意味着模型要把像素输入变成状态理解，再把状态变成动作计划，还要长期记住目标。

最小技术架构大概是：

Emulator -> Frame Capture -> Vision Model -> State Summary -> Policy Prompt -> Action Adapter -> Emulator
                                  ^                                      |
                                  |                                      v
                          Episodic Memory <---------------------- Result Feedback

这类项目中，Fable 5 做的不是传统游戏 AI 的路径搜索。它更像一个“视觉策略解释器”：看到画面，判断当前位置、菜单状态、角色方向、障碍物、战斗阶段和下一步目标。然后把自然语言策略压成具体动作，比如上、下、左、右、A、B、开始。

提示词要特别强调“不要臆测屏幕外信息”。一个可复现模板可以这样写：

你只能根据当前截图和历史摘要决策。不要假设屏幕外物体。

每一步输出三部分：
1. 画面理解：当前位置、可见对象、菜单/战斗/地图状态。
2. 目标进度：当前主目标、最近完成的子目标、卡住迹象。
3. 下一步动作：只输出一个动作，必须来自允许动作集合。

如果连续 8 步没有进展：
- 回退到最近稳定位置；
- 尝试不同方向；
- 不要重复同一动作循环。

这个例子的价值不在某个游戏，而在 agent 设计。未来很多机器人、浏览器自动化、桌面助手和工业视觉任务都像这个结构：输入是视觉状态，输出是有限动作，过程中需要长期记忆和反思。小游戏只是便宜、可复现、可观察的测试场。

也正因为如此，小游戏项目不能只看“能不能跑”。要看它有没有状态摘要、重复动作检测、失败恢复和验证日志。没有这些，模型只是偶然通关；有这些，才接近可工程化的视觉 agent。

4. 诉讼草拟产品：Fable 5 进入专业文档流水线

Legion 的案例说明，Fable 5 不只被个人开发者拿来做原型，也被小团队放进产品核心流程。公开材料显示，这类产品围绕诉讼文件草拟，包括诉状、发现请求和其他法院文件。

法律文档生成是非常典型的高约束场景。它和普通写作不同：

• 必须遵守司法辖区和法院格式。
• 必须引用案件事实和证据。
• 不能把没有证据的事实写成确定结论。
• 需要保留律师审阅和修改痕迹。
• 需要模板、规则和模型输出共同工作。

一个合理的技术架构不会把整件事交给模型自由发挥，而是拆成几层：

提示词也要带“法律草拟刹车”：

你是诉讼文件草拟助手，不能替代律师判断。

输入：
- 案件事实摘要；
- 可引用证据清单；
- 目标法院/司法辖区；
- 文件类型；
- 律师提供的策略备注。

输出要求：
1. 先生成大纲和需要确认的问题。
2. 每个事实性段落必须标注可支持材料编号。
3. 不得新增输入中没有的事实。
4. 对不确定内容使用待确认标记。
5. 最后输出风险清单：事实不足、引用不足、格式待核、策略需律师确认。

这里 Fable 5 的优势是长文档、多约束和语气控制。风险也很明显：一旦模型把推测写成事实，后果比普通内容错误严重得多。所以这类项目的创新不应该是“AI 自动写法律文件”，而应该是“AI 把材料整理成可审阅草稿，并把不确定性显式暴露给专业人员”。

5. 交易分析评测：强模型的价值在多约束判断

IMC 交易分析评测值得关注，是因为它不是普通问答，而是接近真实金融分析工作：事实查找、概念推理、根因分析和期望值判断同时出现。

金融场景里，模型最容易犯的错不是不会写，而是过度自信。一个交易分析任务可能同时要求：

• 找到事实数据。
• 判断数据是否过时。
• 区分相关性和因果。
• 解释市场结构。
• 在不完整信息下计算期望值。
• 标注假设条件。

这类任务适合 Fable 5，不是因为它“知道更多金融知识”，而是因为它能在长链路里维持假设和证据边界。提示词应该把输出拆成可审计结构：

请完成交易分析任务，但每个判断必须归类。

输出结构：
1. 已知事实：只写输入或可检索材料支持的信息。
2. 推理链：说明从事实到判断的中间假设。
3. 不确定性：列出缺失变量和可能反例。
4. 期望值：给出计算方式，不要只给结论。
5. 决策建议：必须附带适用条件和失效条件。

禁止：
- 把猜测写成事实；
- 忽略时间窗口；
- 只给单一结论不说明敏感变量。

对团队来说，这种项目最大的启发是：强模型不能只看最终答案，要看它能否把答案拆成事实、假设、计算和风险。如果不能拆，金融、法律、医疗、工业这些专业场景都不应该直接相信它。

6. Claude Code 多端工程流：Fable 5 的产品化容器

Fable 5 的很多能力只有接进执行环境才有意义。Claude Code 提供了一个很清晰的容器：终端、IDE、桌面、网页、MCP、hooks、skills、subagents、后台任务和 CI。

这类工具的项目价值在于，它把模型从“写答案”推进到“做工作”：

• 读仓库结构和历史决策。
• 修改多个文件。
• 运行测试和命令。
• 生成 commit 或 PR。
• 通过 MCP 接内部工具。
• 用 hooks 做格式化、检查和审计。
• 用 subagents 拆分研究或并行任务。

一个实际项目可以这样组织：

repo/
  CLAUDE.md              # 项目规则、禁止事项、测试命令
  .claude/
    skills/
      migrate-ruby-api/  # 可复用迁移流程
      review-risk/       # 审查清单
    hooks/
      post-edit-lint.sh  # 每次编辑后自动检查
  tests/
  scripts/

关键不是把所有规则塞进一次 prompt，而是把规则变成可维护资产。比如迁移、PR 审查、部署、内容发布、安全扫描都可以做成 skill。这样模型每次进入项目时，不需要重新学习团队习惯，也不需要用户反复解释“我们这里怎么做”。

一个团队级提示词可以非常短：

使用本仓库的 CLAUDE.md 和 migrate-ruby-api skill。
只处理本次 issue 指定的 API 迁移。
每个批次不超过 8 个文件。
运行相关测试并记录失败。
不要提交，先给我审查 diff 和风险。

这就是 Fable 5 时代提示词的变化：不是越长越好，而是把稳定知识沉淀到文件、技能、hook 和测试里。会写一次性神奇提示词的人很多，能把提示词变成团队工程制度的人更少。

7. 网页和小游戏原型：社区最容易复现的创新场

网页和小游戏是今天最适合普通开发者复现的 Fable 5 项目方向。原因很简单：反馈快、可截图、可运行、可分享。一个好原型不需要复杂后端，也能测试模型对布局、交互、状态和审美的综合能力。

不过，真正的提示词不能只说“做一个好看的页面”。应该先定义产品目标和验收方式：

做一个可玩的浏览器小游戏原型。

主题：
太空维修机器人在 90 秒内修复飞船线路。

技术：
- React + Canvas；
- 不使用外部图片，必要素材用 CSS/Canvas 绘制；
- 支持键盘和触摸；
- 保持 60fps 优先。

玩法要求：
- 开始、运行、暂停、失败、胜利、重开；
- 玩家移动、收集零件、躲避故障电弧；
- 难度随时间增加；
- UI 不遮挡画面。

验收：
- 首屏无需说明文档即可开始；
- 手机宽度 390px 不重叠；
- 失败后可一键重开；
- 输出自测清单。

Fable 5 在这类任务上的优势，是能更稳定地把“好看”和“可玩”同时保住。弱模型往往会生成漂亮但不可玩的页面，或者能玩但视觉很粗糙。强模型更容易把状态机、动画循环、碰撞检测、分数系统、暂停重开和响应式 UI 一起考虑。

但这里也有一个误区：不要把所有项目都做成大而全。社区里最值得看的小游戏，不一定是代码量最大的，而是循环最完整的。一个 300 行的可玩原型，往往比 3000 行但状态混乱的项目更有价值。

四种提示词模式

把这些项目放在一起，可以总结出四种比较稳定的 Fable 5 提示词模式。

模式一：迁移协议

适合大型代码库迁移、框架升级、API 替换。

核心写法：

• 明确“不改变公共行为”。
• 先扫描范围，再分批执行。
• 每批次限制文件数量。
• 修改后必须运行测试。
• 输出未处理点和风险。

模式二：规格转产品协议

适合研究工具、内部系统、专业小应用。

核心写法：

• 先把长规格拆成数据模型、流程、页面和验收样本。
• 不急着写代码。
• 要求模型显式标出不确定需求。
• 用户确认后再实现。

模式三：视觉状态循环

适合游戏、浏览器自动化、机器人和桌面助手。

核心写法：

• 只能根据当前画面和历史摘要决策。
• 每步输出画面理解、目标进度、下一动作。
• 检测重复动作。
• 保留失败恢复策略。

模式四：专业草稿刹车

适合法律、金融、医疗、合同、研究报告。

核心写法：

• 区分事实、推理、假设和建议。
• 每个事实性结论要有材料编号。
• 对不确定内容显式标注。
• 最终输出风险清单，而不是只交付漂亮文本。

这四种模式有一个共同点：它们都把模型放进约束系统里。强模型不是因为“无所不能”才有价值，而是因为在约束清楚的情况下，能做更长、更复杂、更接近真实工作的任务。

什么样的 Fable 5 项目值得继续跟进

以后再看 Fable 5 项目，可以用下面这张清单筛选：

如果一个项目只有“模型一次生成了很漂亮的结果”，它仍然值得欣赏，但工程价值有限。如果一个项目能把模型能力接到数据、工具、测试和人工验收里，即使视觉不炫，也更值得跟进。

最后的判断

Fable 5 这一轮真正的突破，不是又多了一个会写代码的模型，而是长任务模型开始进入专业项目：大规模迁移、研究工具、视觉 agent、法律草稿、金融评测、工程自动化和小游戏原型。

这些项目共同说明一件事：未来的竞争不只是模型能力，而是“模型 + 工具 + 提示词协议 + 验收系统”的组合。谁能把提示词从一次性指令变成可维护流程，谁就能更稳定地把强模型转化成生产力。

对个人开发者来说，最好的起点是网页工具和小游戏，因为反馈快、失败成本低。对团队来说，最好的起点是迁移、测试、内部工具和文档自动化，因为边界清楚、可验证。对专业行业来说，必须先设计审校和不确定性暴露机制，再谈自动生成。

Fable 5 不是魔法项目生成器。它更像一个高能力执行单元。你给它模糊愿望，它会给你惊艳但不可控的结果；你给它协议、工具和验收，它才可能变成真正能做项目的 agent。