title: "辅助模型写Fable 5任务书 | 省钱还更准" category: 人工智能 tags:
- 大模型API中转站
- 4SAPI
- Claude Fable 5
- 辅助模型
- 任务书
- 企业级API
- 成本治理 description: "Fable 5 这种高级模型不应该被拿来处理所有前置闲聊。更好的方式是让低成本辅助模型先做需求采访、信息整理、风险分类和任务书生成，再通过 4SAPI 把高价值任务交给 Fable 5 执行。"
前面一组讲了用 Fable 5 辅助部署服务器、Docker、数据库和项目上线。
这一篇换一个更关键的角度：
不要让 Fable 5 从混乱需求里猜你的意思。
先让辅助模型把需求整理成任务书，再交给 Fable 5。
这件事听起来像多绕一步。
但在实际使用里，往往更省钱，也更准。
因为 Fable 5 这种高级模型最贵的不是回答。
最贵的是：
你把一堆半成品想法、聊天记录、旧文档、报错截图、代码片段全塞给它，
让它一边理解你到底要什么，一边判断怎么做，一边执行。
它当然能做。
但你等于让一个高级架构师先帮你整理会议纪要、补字段、猜背景、清洗垃圾上下文。
这不是不能用。
这是浪费。
更好的方式是通过 4SAPI 做一个两层路由：
辅助模型：便宜、稳定、负责采访和整理。
Fable 5：昂贵、强大、负责关键判断和复杂执行。
这一篇就讲第一层：
怎么让辅助模型给 Fable 5 写一份好任务书。
1. 为什么不是直接问 Fable 5
很多人会觉得：
Fable 5 这么强，我直接把目标给它不就行了？
可以。
但这只适合两类情况：
你目标很清楚。
任务价值足够高。
比如：
请审计这个项目的海外 CDN、SEO、GEO 和回源安全方案。
这种任务直接交给 Fable 5 没问题。
但大多数真实任务不是这样开始的。
真实情况往往是：
我想优化一下这个项目。
这个报错是不是和数据库有关？
帮我把这个网站弄得更专业。
这个工作流能不能改得自动一点？
我感觉这个 Prompt 不好用。
这些话不是任务。
这些话是情绪、方向和一点点线索。
Fable 5 可以从中推断出很多东西，但每一次推断都要消耗强模型成本。
辅助模型的价值，就是先把这些话变成结构化任务书。
2. 辅助模型的定位：不是小号 Fable 5
这里的辅助模型，不是让便宜模型假装自己也能做复杂判断。
它的工作非常明确：
| 工作 | 是否适合辅助模型 | 原因 |
|---|---|---|
| 追问缺失信息 | 适合 | 不需要强推理 |
| 整理聊天记录 | 适合 | 重复性高 |
| 提取目标和限制 | 适合 | 结构化任务 |
| 判断是否高风险 | 适合初筛 | 只做分类，不做最终决策 |
| 生成 Fable 5 任务书 | 适合 | 模板化强 |
| 做架构决策 | 不适合 | 交给 Fable 5 |
| 改生产配置 | 不适合 | 必须人工确认 |
一句话：
辅助模型负责把输入变干净。
Fable 5 负责把事情做正确。
不要让辅助模型越权。
它不是最终专家。
它是任务经理、整理员、采访官。
3. 一份好任务书长什么样
给 Fable 5 的任务书，不是普通 Prompt。
它应该像一个小型工单。
最小结构如下：
任务标题：
一句话说明要完成什么。
背景：
为什么要做，给谁用，后续会影响什么决策。
当前材料：
有哪些文件、链接、日志、截图、代码片段、旧方案。
目标：
本轮必须达成什么。
非目标：
本轮不做什么，避免模型顺手扩范围。
边界：
哪些动作禁止，哪些动作需要人工确认。
交付物：
最后要给出文档、代码、表格、清单、PR，还是部署报告。
成功标准：
怎么判断做完。
证据要求：
哪些完成声明必须有命令输出、文件位置、日志或截图支撑。
升级条件：
什么时候需要暂停，问人或转人工处理。
这比一句“帮我优化一下”清楚得多。
Fable 5 拿到这种任务书，会少花很多 token 在猜测上。
4. 让辅助模型先做需求采访
辅助模型最适合干的第一件事，是问问题。
但不是无限追问。
建议让它只问最少问题。
Prompt：
你是 Fable 5 任务书采访官。
你的任务不是解决问题，而是把用户的模糊需求整理成一份可以交给 Fable 5 执行的任务书。
规则：
1. 先判断用户需求是否足够清楚。
2. 如果缺信息，最多问 3 个问题。
3. 优先问会影响执行边界、成功标准和风险等级的问题。
4. 不要问无关偏好。
5. 如果信息已经足够，直接生成任务书。
输出：
- 需求完整度：高/中/低
- 缺失信息
- 需要追问的问题
- 可直接交给 Fable 5 的任务书草稿
例如用户说：
帮我把这个项目部署一下。
辅助模型不应该立刻输出 Docker 命令。
它应该问：
1. 项目是什么技术栈，是否已有 Dockerfile 或 docker-compose.yml？
2. 服务器系统和部署环境是什么，是否为生产环境？
3. 本轮是否允许修改 Nginx、数据库、DNS 或 SSL 配置？
这三个问题比“你喜欢什么部署方式”有价值。
因为它们决定风险边界。
5. 任务书示例：从一句话到可执行委托
原始需求：
我想让 Fable 5 帮我优化一下网站 SEO 和 GEO。
辅助模型整理后：
任务标题：
审计并优化网站 SEO/GEO 基础设施。
背景：
用户运营一个 AI 资讯网站，希望提升搜索引擎收录质量，以及被 ChatGPT、Claude、豆包、DeepSeek 等 AI 回答引用的概率。
当前材料：
- 网站域名和服务器信息由用户提供
- 现有访问日志可读取
- 站点地图、robots、页面结构、接口访问日志需要检查
目标：
1. 审计当前 SEO/GEO 基础设施问题。
2. 找出搜索引擎、AI 爬虫、镜像站、异常采集来源。
3. 输出优先级最高的 3 个改造工程。
4. 给出可执行计划，但生产变更前必须人工确认。
非目标：
- 不改写所有文章内容。
- 不做黑帽 SEO。
- 不绕过平台规则。
边界：
- 不输出真实密钥。
- 不直接修改 DNS、CDN、Nginx 或生产数据库。
- 如需提交工单、切换解析、申请证书，必须先生成草稿并等待确认。
交付物：
- P0/P1/P2 风险清单
- 三个高收益工程方案
- 每个方案的验证方法
- 上线前检查清单
成功标准：
- 每个结论都有日志、配置或页面证据。
- 每个改造方案都包含收益、风险、成本和回滚方式。
升级条件：
- 需要生产凭证
- 需要修改 DNS/CDN
- 发现疑似攻击或全站镜像
你看，Fable 5 拿到后，就不会只写一篇泛泛 SEO 建议。
它会知道这是一个工程审计任务。
6. 任务书里最重要的是“非目标”
很多人写 Prompt，只写目标。
但高级模型特别需要非目标。
因为它很主动。
你说：
优化部署。
它可能会顺手：
改 Dockerfile。
改 Nginx。
改数据库连接池。
改 CI。
补监控。
写文档。
这些动作不一定错。
问题是它可能超出你本轮想要的范围。
所以任务书要写：
非目标：
- 本轮不重构项目架构。
- 本轮不迁移数据库。
- 本轮不切换云厂商。
- 本轮不修改生产 DNS。
- 本轮只输出方案，不执行部署。
非目标不是限制能力。
是保护任务边界。
7. 风险等级先由辅助模型粗分
辅助模型还可以先给任务分级。
例如：
| 风险等级 | 例子 | 是否直接给 Fable 5 |
|---|---|---|
| R0 | 改标题、摘要、格式 | 不需要，低成本模型即可 |
| R1 | 文档整理、Prompt 改写 | 可用中等模型，必要时 Fable 5 复核 |
| R2 | 代码修改、配置建议 | Fable 5 适合 |
| R3 | 生产部署、数据库、DNS、证书 | Fable 5 可审查，但执行需人工确认 |
| R4 | 删除数据、绕过限制、敏感安全操作 | 停止或转人工合规判断 |
这一步很适合放在 4SAPI 的路由前。
伪规则：
R0/R1 -> low_cost_model
R2 -> fable5_if_complex
R3 -> fable5_review + human_confirm
R4 -> block_or_manual
这就是企业级 API 网关的意义。
不是所有请求都平等。
不同风险的任务，应该走不同模型、不同 Key、不同日志级别。
8. 4SAPI 里怎么拆 Key
建议至少拆三类 Key：
| Key | 允许模型 | 用途 | 预算 |
|---|---|---|---|
| intake-key | 低成本模型 | 需求采访、任务书整理 | 高并发、低单价 |
| fable-task-key | Fable 5 | 高价值任务执行 | 低并发、高审计 |
| review-key | 中高能力模型 | 验收、复核、风险审查 | 中等预算 |
这样做的好处是：
辅助模型不会误调用 Fable 5。
Fable 5 的每次调用都有明确理由。
高风险任务可以单独查日志。
预算超了能定位是哪一层烧钱。
在 4SAPI 日志里建议加字段：
task_id
stage: intake / brief / execute / review
risk_level
route_reason
source_model
target_model
human_confirm_required
以后你就能复盘：
哪些模糊需求最消耗 Fable 5？
哪些任务书写得好，一次命中率高？
哪些任务本来不该升级到 Fable 5？
9. 辅助模型不要做最终承诺
有一个坑要避开：
辅助模型把任务书写得很自信，顺便替 Fable 5 承诺结果。
比如：
Fable 5 一定可以自动完成部署。
这个方案一定不会影响线上。
这个错误一定是数据库连接问题。
这种话要禁止。
辅助模型只能说：
根据目前材料，建议交给 Fable 5 执行以下任务。
风险等级为 R2。
仍需 Fable 5 根据证据确认。
辅助模型是前台。
不是最终专家。
10. 一条可直接复制的辅助模型 Prompt
你是“Fable 5 任务书生成器”，通过 4SAPI 接入。
你的职责：
- 把用户的模糊需求整理成一份可以交给 Fable 5 执行的任务书。
- 你不解决任务本身。
- 你不做最终技术决策。
流程：
1. 判断需求完整度：高/中/低。
2. 提取用户真实目标。
3. 列出缺失信息，最多追问 3 个关键问题。
4. 判断风险等级 R0-R4。
5. 生成任务书。
6. 标注是否建议升级到 Fable 5。
任务书必须包含：
- 任务标题
- 背景
- 当前材料
- 目标
- 非目标
- 边界
- 交付物
- 成功标准
- 证据要求
- 升级条件
约束：
- 不要求用户提供真实密钥、密码、Cookie、数据库连接串。
- 不建议绕过官方限制。
- 涉及生产、删除、发送、DNS、数据库迁移时，标注“必须人工确认”。
- 不要承诺 Fable 5 一定能完成，只能说明建议交给 Fable 5 的理由。
这条 Prompt 可以放进自己的 Skill。
也可以放在 Dify、n8n、Coze、Claude Code、Codex 的前置节点里。
11. 最后给 Fable 5 的输入要短
辅助模型整理完，不要把完整聊天记录再塞给 Fable 5。
建议只传三块：
1. 任务书
2. 必要材料索引
3. 用户已确认的边界
如果 Fable 5 需要原始材料，再让它按索引读取。
不要一开始就把所有东西灌进去。
这会让上下文更干净，也更便宜。
12. 总结
Fable 5 这种高级模型，最适合处理高价值判断和复杂执行。
但它不应该被拿来消化所有混乱输入。
更好的工作流是：
用户说人话。
辅助模型做采访和整理。
生成任务书。
4SAPI 判断是否升级。
Fable 5 执行关键任务。
另一个模型做验收。
一句话：
不要把 Fable 5 当万能客服。
要把它当高级专家。
高级专家上场前，先让辅助模型把问题问清楚、材料摆整齐、边界写明白。
这样 Fable 5 才能真正发挥价值。
下一篇继续讲：
辅助模型怎么给 Fable 5 整理上下文包。
任务书解决“要做什么”。
上下文包解决“凭什么做”。