title: " Fable 5 Prompt四要素 | 首次命中" category: 人工智能 tags:
- 大模型API中转站
- 4SAPI
- Claude Fable 5
- Prompt
- Effort
- 企业级API
- 模型路由 description: "给 Claude Fable 5 写复杂任务提示词时，最稳的结构是背景、请求、输出格式、约束。本文给出可复制模板、财务和代码审计案例、简洁风格指令、effort 档位选择方法，并说明如何用 4SAPI 做不同任务的模型路由和成本控制。"
上一篇讲了 Fable 5 的提示词迁移。
核心一句话：
少写指令，多给意图。
这一篇讲更具体的写法。
如果你要让 Fable 5 处理一个复杂任务，最稳的 Prompt 结构是四块：
背景。
请求。
输出格式。
约束。
这四块不是为了显得专业。
而是为了让模型一次就知道：
为什么做。
具体要什么。
交付成什么样。
哪里不能越界。
1. 最小可行 Prompt 结构
模板如下：
我正在为[服务对象]做[更大的任务]。
他们需要[这份输出用来支撑什么决策或动作]。
请求：[一句话说清你具体要什么]
输出格式：[结果如何组织和交付：篇幅、结构、语言、表格、清单]
约束：[过程中绝不允许发生的事：不做什么、不假定什么、不碰什么]
这就是 Fable 5 的最小可行结构。
你不需要每次都套得很死。
但只要任务稍微复杂，这个结构就很有用。
因为 Fable 5 不缺执行能力。
它缺的是你给它一个清楚的任务空间。
2. 背景：告诉它为什么做
背景不是废话。
背景决定模型会主动联想到什么。
差的写法：
分析这份报表。
好一点的写法：
我正在为 CFO 做 Q3 财务复盘。
她需要用这份分析向董事会展示各区域的风险和机会。
这两句话会显著改变输出。
模型知道对象是 CFO，就会更关注：
经营指标。
风险。
机会。
董事会可读性。
数据口径。
而不是泛泛解释每个数字。
在企业级大模型接入里，背景尤其重要。
比如：
我正在为研发负责人做模型 API 统一入口迁移评估。
这份输出会用于决定哪些项目先接入 4SAPI，哪些项目暂时保留官方直连。
这会让 Fable 5 自动关注：
Base URL。
API Key。
模型路由。
日志审计。
成本归因。
fallback。
生产风险。
你不需要把每一步都列出来。
它会自己补齐很多专业联想。
3. 请求：一句话说清具体要什么
请求要短。
不要在请求里塞完整流程。
好的请求通常像这样：
分析 Q3 损益表，标注所有同比波动超过 5% 的项目。
或者：
审计当前项目的模型 API 调用方式，找出迁移到 4SAPI 前必须处理的风险。
或者：
把这个旧 Skill 改写成适合 Fable 5 的版本，删除过度约束，保留安全边界。
请求最怕两种问题。
第一种是太空：
优化一下。
帮我看看。
做得更好。
第二种是太碎：
先做 A，再做 B，然后做 C，如果遇到 D 就 E，最后……
Fable 5 更适合：
目标清楚。
路径留白。
边界明确。
4. 输出格式：别让它猜交付物
Fable 5 很会发挥。
所以你要告诉它交付物是什么。
例如：
输出格式：一页高管摘要，包含汇总表、Top 3 风险和 Top 3 机会。
每个板块不超过三句话。用中文。
或者：
输出格式：Markdown 表格。列为风险等级、证据位置、影响、建议动作、是否需要人工确认。
或者：
输出格式：先给结论，再给操作步骤。步骤不超过 8 条，每条只写必要动作。
输出格式不是为了限制模型。
而是为了减少返工。
企业场景尤其要避免这种结果：
模型说了很多。
看起来很有道理。
但不能直接放进汇报、工单、PR、SOP。
所以要提前告诉它：
这是给谁看的。
要多短。
要表格还是清单。
要不要证据。
要不要行动项。
5. 约束：写不可越过的边界
约束不是越多越好。
但关键边界必须写。
尤其是这些：
| 场景 | 约束示例 |
|---|---|
| 财务分析 | 不要假定数据中未出现的数字 |
| 代码审计 | 不要修改代码，只输出风险 |
| 生产运维 | 不要执行部署、删除、DNS 切换 |
| 客服回复 | 不要直接发送消息，只生成草稿 |
| 4SAPI 接入 | 不要输出真实 API Key |
| 文档生成 | 没有证据的结论标注为“待验证” |
一个完整例子：
约束：不要生成幻灯片。不要发送任何邮件。
不要假定收入数据中未出现的数字。
超出数据支持范围的结论标注为“推测”。
注意，这些约束不是旧模型时代那种低价值碎规则。
它们是安全边界和交付边界。
Fable 5 主动性越强，这些边界越重要。
6. 四要素评分卡
写完 Prompt 后，不要急着跑。
先用这张小表打分：
| 维度 | 0 分 | 1 分 | 2 分 |
|---|---|---|---|
| 背景 | 没有说明用途 | 只说了任务领域 | 说明了服务对象和决策场景 |
| 请求 | 很模糊 | 大致明确 | 一句话能判断是否完成 |
| 输出格式 | 让模型自由发挥 | 有大概结构 | 明确篇幅、结构、字段和语言 |
| 约束 | 没有边界 | 有零散禁止 | 明确安全边界和证据边界 |
总分 8 分。
经验上：
0-3 分：很容易跑偏。
4-5 分：能跑，但返工多。
6-7 分：适合大多数复杂任务。
8 分：适合交给 Fable 5 长程执行。
这张评分卡的价值，是防止你把“我脑子里很清楚”误以为“模型也很清楚”。
Fable 5 很强，但它仍然只能处理你给出的任务空间。
7. 四类可复制场景模板
模板一：财务复盘
我正在为 CFO 做季度经营复盘。
这份输出会用于董事会沟通，重点是风险、机会和需要管理层决策的事项。
请求：分析这份 Q3 损益表和区域数据，找出同比波动超过 5% 的项目，
并解释它们对下季度经营的影响。
输出格式：一页高管摘要。包含总览表、Top 3 风险、Top 3 机会、
需要确认的数据口径。每个板块不超过三句话。
约束：不要假定表格里不存在的数字。
超出数据支持范围的判断标注为“推测”。
不要生成幻灯片，不要发送邮件。
模板二：客服知识库更新
我正在维护企业客服知识库。
这份输出会用于决定哪些用户问题应该沉淀成标准问答。
请求：阅读这批客服对话，提取高频问题、已有答案缺口和建议新增的知识库条目。
输出格式：Markdown 表格。列为问题、出现次数、现有知识库是否覆盖、
建议答案、是否需要产品确认。
约束：不要编造产品功能。没有客服记录支撑的问题标注为“待验证”。
不要直接更新正式知识库，只生成草稿。
模板三：研发迁移评估
我正在为研发团队做大模型 API 统一入口迁移。
这份输出会用于判断哪些服务先迁移到 4SAPI，哪些服务保留官方直连。
请求：审计当前项目中的模型调用方式，找出 Key、Base URL、模型路由、
日志审计和成本治理方面的问题。
输出格式：按 P0/P1/P2 输出风险清单。每条包含证据位置、影响、建议动作、
是否需要人工确认。
约束：不要读取或输出真实密钥。不要修改生产配置。
没有证据的判断标注为“待验证”。
模板四：内容选题系统
我正在做一个 AI 技术博客选题系统。
读者是企业研发、独立开发者和内容创作者，关注模型接入、Agent 工作流和成本治理。
请求：根据这批素材，拆出 5 个可以独立成文的选题，并给出每篇的标题、
核心观点、目标读者和 4SAPI 的自然植入位置。
输出格式：表格 + 每篇 5 条大纲。
标题控制在 30 字左右，避免营销腔。
约束：不要照搬素材原句。不要编造官方政策。
涉及最新价格、规则、模型可用性时标注“需发布前核对”。
这些模板不需要逐字照用。
你真正要学的是结构：
服务对象。
决策用途。
具体请求。
交付格式。
不可越界。
8. 代码审计示例
下面是一条可以直接改的 Prompt：
我正在为研发团队做一次企业级大模型 API 接入审计。
这份审计会用于决定项目是否统一接入 4SAPI，并评估上线前的 Key 权限、
日志审计、模型路由和成本治理风险。
请求：审计当前代码库中所有模型 API 调用、Agent 工作流和相关配置，
找出迁移前必须处理的问题。
输出格式：按 P0/P1/P2 分级输出。每条包含证据位置、影响、建议动作、
是否需要人工确认。
约束：不要修改代码。不要读取或输出真实密钥。
没有文件、日志或配置证据支撑的判断标注为“待验证”。
这条 Prompt 没有告诉它先读哪个文件。
但 Fable 5 会知道要查：
.env 示例。
配置文件。
SDK 初始化。
Base URL。
模型名称。
调用日志。
fallback 逻辑。
错误处理。
成本统计。
这就是给意图的好处。
9. 风格指令要短
Fable 5 在高 effort 下有一个特点：
它可能会过度展开。
比如：
调研你不会采用的备选方案。
把 PR 描述写成论文。
解释太多背景。
注释逐行说明代码做了什么。
旧做法是列一堆禁止项。
更推荐一句短指令：
保持简洁。只输出完成任务所必需的内容。
不展开不会采用的备选方案。
注释只写“为什么”，不写“是什么”。
如果默认输出已经够好，就不要加这句。
Fable 5 的一个迁移原则是：
先测试默认表现，再加最少规则。
10. effort 档位怎么选
Fable 5 的 effort，本质是在质量、延迟、成本之间做权衡。
一个实用决策表：
| 任务 | 建议 effort |
|---|---|
| 简单摘要、格式转换、标题改写 | low 或 medium |
| 普通代码修改、文档整理、表格分析 | high |
| 复杂架构设计、长程 Agent、生产故障排查 | high 或 xhigh |
| 关键上线前审查、重大方案评审 | xhigh |
不要什么都上高档。
因为 Fable 5 在高 effort 下会主动收集更多上下文、做更多推敲。
这对复杂任务是优点。
对简单任务就是浪费。
建议：
默认 high。
任务能完成但太慢、太展开，就降到 medium。
任务质量要求极高且愿意等，再上 xhigh。
简单任务不要用高 effort。
11. 用 4SAPI 做 effort 和模型路由
企业里不要让所有任务都直接打到 Fable 5 高 effort。
更合理的是通过 4SAPI 或同类大模型 API 中转站做路由：
| 任务类型 | 推荐路由 |
|---|---|
| 简单摘要 | 低成本模型 |
| 普通客服分类 | 快速模型 |
| Prompt/Skill 迁移 | Fable 5 high |
| 长程代码审计 | Fable 5 high 或 xhigh |
| 最终审查 | Fable 5 或强推理模型 |
| 安全拒绝触发 | fallback 到合适模型或人工 |
这样你能在 4SAPI 日志里看到：
哪个任务用了 Fable 5。
用了什么 effort。
花了多少钱。
是否一次命中。
是否发生 fallback。
人工是否返工。
Prompt 写得好不好，最终也要回到数据上。
如果某类任务 high 和 xhigh 的成功率差不多，就不要长期用 xhigh。
如果某类任务 medium 经常返工，升 high 反而可能更便宜。
12. 一条通用模板
最后给一条可复制模板：
我正在为[服务对象]做[更大的任务]。
这份输出会用于[具体决策、交付物或后续动作]。
请求：请你[一句话描述具体任务]。
输出格式：
- 先给一句话结论
- 再给[表格/清单/步骤/方案]
- 每条都包含[证据/影响/建议/负责人/优先级]
- 用[中文/英文]，控制在[长度]以内
约束：
- 不要[高风险动作]
- 不要假定[数据里没有的内容]
- 没有证据的判断标注为“待验证”
- 涉及[生产、密钥、发送、删除、部署]时先暂停确认
风格：保持简洁，只输出完成任务所必需的内容。
这条模板不是万能咒语。
但它足够稳。
尤其适合：
项目审计。
代码迁移。
SOP 优化。
企业 API 网关接入。
4SAPI 路由方案设计。
长程 Agent 任务启动。
13. 总结
Fable 5 Prompt 的核心不是写长。
而是写准。
记住四要素：
背景：为什么做。
请求：具体要什么。
输出格式：交付成什么样。
约束：哪里不能越界。
再配合 effort 控制：
简单任务别上高档。
复杂任务给足推理。
企业场景用 4SAPI 记录路由、成本和结果。
下一篇继续讲更难的一层：
长时间自主运行时，怎么管上下文。
检查点、边界、进度证据、记忆文件和最终汇报。