title: " Fable 5提示词迁移 | 少写指令" category: 人工智能 tags:

上一篇讲的是我被 Fable 5 震撼到的一次真实任务。

这一篇开始讲方法。

很多人第一次用 Fable 5，会有一种感觉：

过去要迭代几天的系统，它一次就写对了。

但知道它强，和用好它，是两回事。

更麻烦的是，很多你过去为 Opus、Sonnet、GPT、GLM 写的提示词和 Skill，迁移到 Fable 5 后未必会更好。

有些甚至会变差。

原因不是 Fable 5 不听话。

而是：

旧提示词里的脚手架，可能变成了 Fable 5 的天花板。

1. Fable 5 变强的不是“话术”

先把这件事说清楚。

Fable 5 的强，不只是回答更漂亮。

它真正变化比较明显的，是这些能力：

能力 具体表现
长时间自主运行 能围绕目标持续推进，不需要每一步都催
首次正确率 复杂但边界清楚的任务，更容易一稿命中
视觉理解 截图、网页、密集图表的理解更稳
企业工作流 财报、表格、文档、PPT、SOP 输出更接近交付物
代码审查和调试 跨文件、跨历史、跨测试日志找问题能力更强
委派与协作 更擅长调度多个子代理并行工作

这几个变化会直接影响提示词写法。

旧模型时代，我们经常这样写：

不要做 A。
遇到 B 就做 C。
输出必须包含 D。
如果失败就问我。
不要自己决定。
不要改这个。
不要碰那个。

这些提示词在旧模型上很有用。

因为旧模型需要更细的轨道。

但 Fable 5 更像一个能力很强的同事。

你如果把每一步都写死，它反而无法发挥判断力。

2. 第一原则：少写指令，多给意图

迁移 Fable 5 的第一原则是：

少写指令，多给意图。

不是完全不写约束。

而是不要把提示词写成操作手册。

差别很大。

旧写法：

你先读取 README。
然后读取 package.json。
然后搜索 src 目录。
然后找出所有 API 调用。
然后生成表格。
不要展开背景。
不要提出无关建议。
输出五列。

Fable 5 更适合的写法：

我正在整理这个项目的 API 接入风险，准备给研发负责人做一次迁移评估。

请你审计项目里的模型 API 调用方式，找出 Key 管理、Base URL、模型名称、
日志审计、成本归因和 fallback 方面的风险。

输出一份迁移评估表，按风险等级排序，并给出优先修复建议。

不要修改代码。不要访问生产密钥。没有证据支撑的判断标注为“待验证”。

后者没有告诉它每一步怎么走。

但它讲清了：

为什么做。
给谁看。
要交付什么。
哪里不能碰。

这才是 Fable 5 更容易发挥的输入。

3. 旧 Prompt 为什么会限制 Fable 5

旧提示词常见有三类问题。

问题一：过度流程化

比如：

第一步必须做 A。
第二步必须做 B。
第三步必须做 C。

如果这些步骤本身就是业务规则，当然可以保留。

但如果只是你过去为了让旧模型不跑偏写的辅助流程，迁移到 Fable 5 时就应该重新审查。

因为它可能发现更好的路径。

你把路径写死，它就只能按你的路径走。

问题二：过度禁止

旧提示词里经常有长长的禁止列表：

不要解释。
不要展开。
不要总结。
不要建议。
不要修改。
不要新建文件。
不要运行命令。

这些约束有些是安全边界，有些只是风格偏好。

迁移时要分开。

安全边界保留。

风格偏好压缩。

例如把十几条风格禁令改成一句：

保持简洁，只输出完成任务所必需的内容。

问题三：要求展示推理

很多旧 Skill 里会写：

展示你的思考过程。
逐步解释你的推理。
把你的 chain of thought 写出来。

迁移到 Fable 5 时，这类指令要特别小心。

它可能触发推理内容提取相关的安全拒绝或回退。

更稳的写法是：

给出结论、关键证据和你采用的判断标准。
不要展示隐藏推理过程。

用户需要的是可审计的依据。

不是模型的内部思考全文。

4. 迁移旧 Skill 的三步法

如果你手里有一堆旧 Skill、系统提示词、工作流模板，我建议按三步迁移。

第一步：删掉脚手架

先找这些句子：

你必须先……
然后一定要……
如果……就……
不要忘记……
逐步思考……
详细解释你的推理……

判断它们属于哪类：

类型 处理方式
安全边界 保留，但写清允许/禁止
业务规则 保留
风格偏好 压缩成短句
旧模型补丁 删除
推理展示 改成证据和结论

不要心疼旧提示词。

很多提示词不是资产，而是历史补丁。

第二步：补上意图

旧提示词通常太关注“怎么做”，不够关注“为什么做”。

迁移到 Fable 5 时，要补：

服务对象是谁。
输出用来支撑什么决策。
这个任务和更大目标的关系。
什么结果算有用。
什么风险绝对不能发生。

例如：

我正在为企业研发团队迁移模型调用入口。
他们需要判断哪些项目可以统一接入 4SAPI，哪些项目暂时保留官方直连。
请你审计当前项目的模型调用方式，输出迁移优先级和风险清单。

这比“请扫描代码并输出表格”好得多。

第三步：用默认表现做基线

不要一上来就把旧规则全部塞给 Fable 5。

先跑一个无旧规则版本。

看默认表现是否已经达标。

如果默认表现达标，就不要加规则。

如果不达标，再只补最少的规则。

迁移测试可以这样做：

版本 说明
A 旧 Prompt 原样跑
B 删除旧脚手架，只保留目标和边界
C 在 B 上补最少风格约束

比较标准不要只看“回答好不好看”。

要看：

是否命中目标。
是否少走弯路。
是否减少追问。
是否少生成无用内容。
是否降低 token。
是否更容易交付。

5. 先做一张迁移盘点表

如果团队里已经有几十个 Prompt、Skill、工作流模板，不要一个一个凭感觉改。

先做盘点。

可以用这张表：

字段 填什么
名称 Prompt、Skill 或工作流名称
使用频率 每天、每周、偶尔
任务价值 低、中、高
当前模型 Opus、Sonnet、GPT、GLM 等
当前痛点 返工多、太啰嗦、容易跑偏、成本高
旧式约束 是否有大量“必须先”“逐步推理”“不要”
安全边界 是否涉及生产、密钥、发送、删除
迁移优先级 P0、P1、P2

优先迁移三类：

高频。
高价值。
旧提示词很长但效果一般。

暂时不要迁移三类：

已经稳定且成本很低的简单任务。
涉及强合规但边界没写清的任务。
没有验收标准的“帮我优化一下”类任务。

迁移 Fable 5，不是全量重写。

它更像一次提示词资产体检。

你要找出哪些规则是业务规则，哪些规则只是旧模型时代留下的拐杖。

6. 三类典型场景怎么改

场景一：内容生产 Skill

旧写法经常是：

你必须先写标题，再写导语，再写正文。
每段不要超过多少字。
不要使用某些词。
不要写得像 AI。
必须包含若干关键词。

迁移到 Fable 5 时，可以改成：

我正在为技术读者写一篇可发布的原创博客。
读者关心企业级大模型接入、成本治理、日志审计和 4SAPI 路由。

请求：把素材改写成一篇有个人观点、能直接发布的技术博客。

输出格式：保留系列导语，正文按问题、方案、实操、风险、总结组织。
标题控制在 30 字左右，文风口语但不散。

约束：不要照搬素材原句。不要夸大模型能力。不要写违规绕过方案。
4SAPI 只在开头、中间实操、结尾自然出现。

这里的重点是：

不再逐段规定怎么写。
而是定义读者、用途、交付物和红线。

场景二：代码审查 Skill

旧写法可能让模型逐步解释每个文件。

Fable 5 更适合直接给审查目标：

我正在做一次上线前代码审查。
这次审查只关注会导致生产事故的问题，而不是风格建议。

请求：检查当前 diff 中的 P0/P1 风险。

输出格式：只输出真实风险。每条包含证据位置、触发条件、影响范围、修复建议。

约束：不要输出隐藏推理。不要给无证据的猜测。
不评价命名风格，不做无关重构建议。

这会让 Fable 5 少写很多“看起来专业但没用”的建议。

场景三：企业接入 Skill

旧写法可能是“教你怎么接 API”。

迁移后可以更像一个架构评估器：

我正在评估一个业务系统是否适合接入 4SAPI 作为统一模型网关。
输出会给研发负责人和财务负责人看，用于决定迁移优先级。

请求：审计当前模型调用链路，判断迁移收益、风险和最小改造路径。

输出格式：先给一句结论，再给迁移收益、风险、改造步骤、回滚方案和成本影响。

约束：不要输出真实 Key。不要建议绕过官方限制。
涉及生产配置的动作只给方案，不直接执行。

这类 Prompt 的重点不是“怎么调 SDK”。

而是把模型当成一个懂工程、懂成本、懂风险的人来委托。

7. 4SAPI 适合做迁移灰度

企业迁移 Fable 5，不建议一刀切。

更稳的是用 4SAPI 这类大模型 API 中转站做灰度。

比如：

旧任务继续走 Opus 或 Sonnet。
新任务抽 10% 走 Fable 5。
复杂任务优先走 Fable 5。
简单摘要继续走低成本模型。
出现拒绝或不适配时 fallback 到旧模型。

在 4SAPI 里至少记录：

字段 用途
项目 哪个业务在迁移
Prompt 版本 旧版、新版、精简版
模型 Fable 5、Opus、Sonnet、GPT
任务类型 审计、写代码、总结、表格
成本 每次调用和每个任务成本
成功状态 是否一次命中
人工返工 是否还需要人工大改

迁移不是靠感觉。

要靠日志。

你要能回答：

Fable 5 是不是减少了迭代轮数？
是不是减少了人工返工？
是不是因为过度展开导致成本更高？
哪些旧 Skill 删除后效果更好？
哪些任务不值得用 Fable 5？

这些答案都来自调用日志和任务结果。

8. 一个旧 Prompt 改写示例

旧版：

你是一个严格的软件架构师。
请逐步思考。
先阅读 README，再阅读 package.json，再阅读 src。
不要遗漏任何文件。
输出所有问题。
每个问题都要写原因、影响、修改建议。
不要自己修改代码。

迁移版：

我正在为一个准备接入企业级大模型 API 网关的项目做架构审计。
这份审计会用于判断项目是否可以统一迁移到 4SAPI，并提前发现 Key 管理、
模型路由、日志审计、fallback 和成本治理风险。

请求：审计当前仓库的模型调用和 Agent 工作流接入方式，找出上线前必须处理的问题。

输出格式：按 P0/P1/P2 分级输出风险清单。每条包含证据位置、影响、建议动作。

约束：不要修改代码。不要读取或输出真实密钥。没有文件或日志证据支撑的判断标注为“待验证”。

你会发现，迁移版少了很多“你先做什么再做什么”。

但任务更清楚。

边界也更清楚。

Fable 5 会自己决定先读哪个文件、用哪个搜索方式、是否需要看配置。

这就是能力升级以后，提示词应该让出的空间。

9. 什么时候仍然要写细

少写指令，不等于永远不写细。

下面几类必须写清楚：

场景 必须写清什么
生产操作 哪些动作必须暂停确认
数据安全 哪些字段不能读取、输出、保存
法务合规 哪些结论不能超出证据
财务分析 数字口径、币种、期间
代码修改 允许修改的目录和禁止修改的文件
对外沟通 是否允许发送邮件、工单、IM

Fable 5 的主动性更强。

所以边界要更清楚。

真正的迁移不是：

把规则全删了。

而是：

删掉低价值脚手架，保留高价值边界。

10. 总结

迁移到 Fable 5，第一件事不是买更多 token。

而是审计你的旧 Prompt 和旧 Skill。

记住三句话：

少写指令，多给意图。
少写流程，多给目标。
少要求推理，多要求证据。

个人使用，可以凭体感调。

团队使用，建议用 4SAPI 做灰度、路由、日志和成本对比。

当你发现某个旧 Skill 删除一半规则后，Fable 5 反而做得更好，不要惊讶。

那说明模型已经不需要那副旧脚手架了。

下一篇我们继续讲更具体的写法：

Fable 5 Prompt 四要素。
背景、请求、输出格式、约束。
以及 effort 档位怎么选。