Fable 5 使用指南：先解除旧工作流的束缚

在 Fable 5 重新发布后，许多用户开始集中测试它的能力边界。围绕这一波使用热潮，Thariq 将原本计划中的主题演讲临时改为一场更具时效性的分享，主题可概括为：如何为 Fable 这类新模型建立一套实用操作指南。

这场分享主要分为四个部分。

1. 为 Fable 设定背景

开场部分讨论了为什么 Fable 5 值得被单独研究。核心前提是：当模型能力发生代际变化时，用户不能继续完全沿用旧的交互方式，否则很可能无法观察到模型真正的新能力。

2. “解除束缚”：不要让旧提示词限制新模型

分享中提出一个关键观点：模型表现出的限制，往往并不完全来自模型本身，而是来自我们给它套上的“外壳”——包括调用方式、工作流、提示词结构，以及对模型能力的先入为主判断。

换句话说，当面对一类新模型时，用户需要主动检查：

• 当前提示词是否是为旧模型设计的；
• 当前工作流是否默认模型只能完成较窄任务；
• 是否因为过度约束，导致模型无法展现新的行为模式；
• 是否需要换一种交互格式来引出更强能力。

分享中特别提到，HTML 在某些任务中展现出“异常有效”的提示与组织能力。这一例子被用来说明：有时模型能力的释放，不只取决于模型参数或基准测试，也取决于用户是否找到了合适的表达与约束方式。

3. 找到你的“未知未知”

第二个重点是识别盲区。这里的思路与“解除束缚”相近，但方向不同：

• “解除束缚”是清理已经过时的已知假设；
• “发现未知”则是寻找那些你甚至不知道自己不知道的事情。

分享中列出了一些实用技巧：

让模型做一次“盲点检查”

可以明确要求模型检查当前方案中的未知风险、遗漏假设和潜在盲区。

要求模型头脑风暴“完全不同的设计方向”

不要只让模型沿着已有方案优化，而是要求它提出差异足够大的替代路径。

让模型反过来采访你

让模型提出高影响力问题，帮助你澄清目标、约束、优先级和潜在风险。这与“拷问式提问”类似，但重点放在影响最大的关键问题上。

使用参考材料

在迁移、重构或复杂工程任务中，可以提供参考文档、旧实现、目标架构等材料，让模型在更完整的上下文中工作。

维护 implementation-notes.md

建议保留一份持续更新的实现笔记，记录模型在需求不充分时替你做出的决策。这有助于后续审查、回滚和团队协作。

让模型反向测验你

不仅要检查模型是否理解任务，也要检查你自己是否真正理解了方案、风险与实现细节。

4. 面对生产力跃迁带来的心理落差

分享中还提到一个更偏情绪层面的变化：过去可能需要几周完成的编码工作，现在可能在数小时内完成。

这类变化会带来明显的心理落差。开发者不仅需要适应工具能力的提升，也需要重新理解自己的价值位置：从“亲手完成大量实现”，转向更高层次的目标定义、判断、整合和价值创造。

5. 更“不讲理”地提出要求

最后一部分强调，面对能力更强的模型，用户可以更大胆地提出要求。

分享中有一句核心表述：“权衡并不是真实存在的。” 其含义并不是工程中没有约束，而是说：当模型能力明显增强后，用户不应过早接受“好、快、便宜只能选两个”的旧式预设。

对于 Fable 这类模型，使用者可以尝试同时要求：

• 更高质量；
• 更快交付；
• 更低成本；
• 更完整的方案；
• 更少妥协。

不过，分享也提醒：构建变得更容易，创造价值依然困难。

这意味着，模型可以显著降低实现门槛，但它并不会自动替代产品判断、用户洞察、商业价值和长期维护能力。

对开发者的启发

这场分享的价值不在于给出一套固定提示词模板，而在于提醒开发者：面对新一代模型，首先要重新审视自己的使用方式。

更值得尝试的做法包括：

• 定期更新提示词和工作流，而不是沿用旧模型时代的习惯；
• 主动要求模型指出盲区，而不是只让它执行命令；
• 让模型参与需求澄清、方案分歧和风险识别；
• 记录模型替你做出的隐性决策；
• 把精力更多放在目标、价值和判断上，而不只是代码产出速度。

Fable 5 的讨论仍在继续，但至少从这场分享来看，一个明确趋势是：模型能力提升后，真正需要升级的不只是模型本身，也包括用户与模型协作的方式。