title: " 辅助模型整理Fable 5上下文包 | 少喂垃圾"
category: 人工智能
tags:
- 大模型API中转站
- 4SAPI
- Claude Fable 5
- 辅助模型
- 上下文工程
- 日志审计
- 企业AI网关
description: "高级模型不是吃得越多越好。本文讲如何用低成本辅助模型先整理材料索引、证据摘录、敏感信息脱敏、缺口清单和决策记录，再通过 4SAPI 把干净上下文包交给 Fable 5。"
上一篇讲辅助模型给 Fable 5 写任务书。
这一篇讲第二件事：
高级模型有长上下文，不等于你应该把所有东西都塞进去。
很多人用 Fable 5、Opus、GPT 这类强模型时，会有一个坏习惯：
text
聊天记录全贴。
日志全贴。
README 全贴。
旧方案全贴。
报错截图全贴。
然后说：你自己看。
模型可能真的能看。
但问题是：
text
它花了昂贵 token 读了很多无关内容。
它可能被旧结论污染。
它可能把未验证信息当事实。
它可能看到你本来不该发出去的敏感字段。
所以，Fable 5 上场前，应该先有一个便宜模型做“上下文打包员”。
在 4SAPI 里，这可以是一个独立阶段：
text
context_pack -> low_cost_model
execute -> fable5
review -> reviewer_model
这篇就讲上下文包怎么做。
1. 上下文包不是摘要
先区分两个概念。
摘要是：
上下文包是：
text
把任务需要的证据、材料、边界和缺口整理成可执行输入。
摘要可能会丢证据。
上下文包不能。
摘要可以比较自由。
上下文包必须可追溯。
例如你让 Fable 5 排查部署失败。
差的上下文：
好的上下文包：
text
任务：
排查 Docker Compose 部署后 app 容器无法连接 Postgres。
证据：
E-001 app 日志 2026-07-03 21:18: connect ECONNREFUSED db:5432
E-002 docker compose ps 显示 db 容器 restarting
E-003 db 日志显示 password authentication failed for user app
已确认：
- Postgres 端口没有暴露公网
- app 使用 Docker 内部服务名 db
- .env 中真实密码未提供，只提供字段名
待验证：
- POSTGRES_PASSWORD 和 DATABASE_URL 是否一致
- db volume 是否来自旧初始化
边界：
- 不删除 volume
- 不重建数据库
- 只给只读排查步骤
这才是 Fable 5 需要的上下文。
2. 辅助模型先做材料清单
上下文整理的第一步不是总结。
是列清单。
让辅助模型先输出：
text
有哪些材料。
每份材料是什么类型。
是否与任务相关。
是否包含敏感信息。
是否需要给 Fable 5。
可以用这张表：
| 材料 | 类型 | 相关性 | 是否敏感 | 处理方式 |
|---|
| README.md | 项目说明 | 高 | 低 | 摘出运行方式 |
| .env | 环境变量 | 高 | 高 | 不传真实值，只传变量名 |
| docker logs | 日志 | 高 | 中 | 脱敏后摘关键行 |
| access.log | 访问日志 | 中 | 高 | 聚合状态码和路径 |
| 旧部署方案 | 历史方案 | 中 | 低 | 标注未验证 |
| 聊天记录 | 背景 | 低 | 中 | 只提取已确认边界 |
辅助模型的第一个任务就是：
这一步省下的 token，往往比你想象的大。
3. 脱敏比摘要更重要
整理上下文包时，脱敏优先级高于摘要。
尤其是这些内容：
text
API Key。
数据库密码。
Cookie。
Authorization header。
邮箱、手机号、订单号。
服务器 IP 和内网拓扑。
云厂商 AccessKey。
Webhook secret。
辅助模型可以先做脱敏检查：
text
请扫描这段材料，判断是否包含敏感信息。
只输出敏感类型、位置描述和建议处理方式。
不要复述敏感值本身。
注意最后一句：
很多人让模型“帮我脱敏”，结果模型先把敏感值再输出一遍。
这就尴尬了。
更稳的做法是让辅助模型输出：
text
第 12 行疑似数据库密码，替换为 [DB_PASSWORD]。
第 27 行疑似 Bearer Token，整行删除。
第 44 行疑似用户邮箱，保留域名统计即可。
如果涉及企业生产日志，建议先在本地用脚本脱敏，再让模型处理。
模型脱敏是辅助，不是唯一防线。
4. 上下文包的五个模块
我建议给 Fable 5 的上下文包固定成五块：
text
任务书。
材料索引。
证据摘录。
已确认事实。
待验证问题。
严格来说是六块，因为还要有边界。
但边界已经在任务书里出现，这里只补关键上下文。
模块一：任务书
来自第161期。
只保留最终版，不带辅助模型的追问过程。
模块二：材料索引
告诉 Fable 5 有哪些材料，而不是把所有材料全贴上。
text
M-001 README.md：包含项目启动方式和环境变量说明。
M-002 docker-compose.yml：包含 app、db、redis 三个服务。
M-003 app.log：最近 200 行应用错误日志，已脱敏。
M-004 nginx.conf：反向代理配置，已隐藏域名。
模块三：证据摘录
只摘关键行。
每条要有编号。
text
E-001 app.log 第 48 行：connect ECONNREFUSED db:5432。
E-002 db.log 第 17 行：database files are incompatible with server。
E-003 docker compose ps：db 状态为 restarting。
模块四：已确认事实
只写已经验证的。
text
F-001 app 和 db 在同一个 compose network。
F-002 生产数据库端口没有暴露公网。
F-003 本轮没有执行 volume 删除。
模块五：待验证问题
不要让辅助模型猜。
不确定就列为待验证。
text
Q-001 DATABASE_URL 中的用户名是否和 POSTGRES_USER 一致。
Q-002 当前 volume 是否来自旧版本 Postgres。
Q-003 应用启动时是否早于数据库 ready。
模块六：边界
再次强调危险动作。
text
禁止删除数据库 volume。
禁止修改生产 DNS。
禁止输出真实密钥。
所有写操作先给计划，等待人工确认。
5. 让辅助模型做“证据索引”，不要做根因判断
辅助模型整理日志时，很容易忍不住判断根因。
比如：
如果它只是低成本模型，这种判断可能不够稳。
更好的要求是：
text
你只做证据索引，不做最终根因判断。
请把日志里可能相关的错误按时间顺序列出来，
每条保留时间、组件、错误类型、关键字段。
不要推断根因。
输出示例：
| 证据 | 时间 | 组件 | 关键内容 | 备注 |
|---|
| E-001 | 21:18 | app | ECONNREFUSED db:5432 | app 连不上 db |
| E-002 | 21:18 | db | password authentication failed | 认证失败 |
| E-003 | 21:19 | app | retry 5 times | 应用有重试 |
然后把这张表给 Fable 5。
让 Fable 5 做根因判断。
这就是“便宜模型做搬运，强模型做判断”。
6. 代码项目的上下文包怎么做
如果任务是代码审计或改造，辅助模型可以先给 Fable 5 准备代码地图。
不要直接把全仓库塞进去。
代码地图可以包括：
text
项目技术栈。
入口文件。
关键模块。
模型 API 调用位置。
配置读取方式。
测试命令。
已知失败日志。
禁止修改的目录。
示例：
text
代码地图：
- Next.js 项目，app router。
- API 路由在 app/api/。
- 模型调用集中在 src/lib/llm.ts 和 src/jobs/summarize.ts。
- 4SAPI Base URL 当前硬编码在 src/lib/llm.ts。
- 测试命令：npm test。
- 禁止修改 prisma/migrations 和 production compose 文件。
Fable 5 拿到这张地图后，再决定读哪些文件。
这比“请扫描整个项目”更省。
7. 内容写作的上下文包怎么做
如果任务是写文章，也不要把所有素材一股脑塞进去。
辅助模型可以先整理：
text
核心事件。
用户观点。
不能重复的旧稿内容。
必须自然植入的 4SAPI 位置。
读者画像。
标题方向。
禁止夸大或违规的表述。
示例：
text
写作上下文包：
主题：
辅助模型如何服务 Fable 5 这种高级模型。
读者：
企业研发、独立开发者、内容创作者。
本文新角度：
不是讲 Fable 5 Prompt 四要素，而是讲前置辅助模型如何整理任务书和上下文包。
避免重复：
不要重复第151期“少写指令，多给意图”。
不要重复第153期 CONTEXT/EVIDENCE/HANDOFF 三件套。
4SAPI 植入：
开头讲多模型路由。
中间讲 intake-key 和 fable-task-key。
结尾讲成本审计。
这就是把写作也当工程。
Fable 5 负责写出好文章。
辅助模型负责把边界和差异点讲清楚。
8. 运维任务的上下文包怎么做
运维类任务最需要上下文包。
因为风险高。
辅助模型应该整理：
text
服务器环境。
服务列表。
端口。
最近变更。
错误日志。
只读验证结果。
禁止动作。
需要人工确认的动作。
示例：
text
运维上下文包：
环境：
- Ubuntu 22.04
- Docker Compose 部署
- app + postgres + nginx
现象：
- HTTPS 可访问首页
- 登录接口 500
最近变更：
- 23:10 更新应用镜像
- 23:15 修改 DATABASE_URL
证据：
- E-001 app 日志显示 Prisma connection error
- E-002 docker compose ps 显示 db healthy
- E-003 nginx access 日志 POST /login 返回 500
边界：
- 不删除数据库
- 不重启整机
- 不修改 DNS
- 先给只读验证步骤
Fable 5 再根据这份包给排查路径。
9. 4SAPI 日志里要记录上下文版本
如果你把上下文包作为一个阶段，就要给它版本。
例如：
text
task_id: deploy-login-500
context_pack_id: ctx-20260703-001
context_model: low-cost-model
execute_model: fable5
context_tokens: 4200
execute_tokens: 18000
sensitive_scan: passed
这样以后复盘时能知道：
text
Fable 5 判断错，是模型问题，还是上下文包漏了证据？
成本高，是上下文太长，还是执行阶段展开太多？
敏感信息有没有在进入强模型前被处理？
同一个任务有没有反复打包？
没有上下文版本，复盘就会变成猜。
10. 辅助模型的上下文包 Prompt
可以直接复制：
text
你是 Fable 5 上下文打包员，通过 4SAPI 接入。
你的任务：
- 读取用户提供的材料。
- 整理成一份可交给 Fable 5 的上下文包。
- 不解决问题本身。
- 不做最终根因判断。
输出结构：
1. 任务概述
2. 材料索引
3. 证据摘录
4. 已确认事实
5. 待验证问题
6. 敏感信息处理建议
7. 禁止动作和人工确认点
8. 建议是否升级到 Fable 5
规则：
- 每条证据都要编号。
- 没有证据的判断不得写成事实。
- 发现 API Key、密码、Cookie、Authorization、个人信息时，不要复述原值。
- 长日志只保留时间、组件、错误类型和关键行。
- 不要建议删除、重启生产、修改 DNS、清空数据库等高风险动作。
这条 Prompt 的关键是：
否则辅助模型会越界。
11. 什么内容不要给 Fable 5
即使 Fable 5 很强，也不是所有上下文都该给它。
下面这些要谨慎：
| 内容 | 处理方式 |
|---|
| 真实 API Key | 不传，只传变量名 |
| 数据库密码 | 不传，只传连接方式 |
| 用户隐私数据 | 聚合或脱敏 |
| 超长访问日志 | 先聚合状态码、路径、时间段 |
| 历史聊天废话 | 只提取已确认决定 |
| 未验证猜测 | 标注为待验证，不写成事实 |
| 生产账号权限 | 不传，人工操作 |
上下文工程不是让模型看一切。
而是让模型看该看的。
12. 总结
Fable 5 这种高级模型，不是吃得越多越聪明。
它需要的是：
text
干净材料。
明确证据。
已确认事实。
待验证问题。
清楚边界。
辅助模型的价值，就是把混乱输入整理成上下文包。
4SAPI 的价值，是把这个过程变成可路由、可审计、可计费的企业级大模型接入流程：
text
低成本模型打包上下文。
Fable 5 做关键判断。
复核模型检查结果。
日志记录每一步成本和证据版本。
下一篇继续：
text
辅助模型怎么帮 Fable 5 做 Prompt 压测。
任务书解决目标。
上下文包解决证据。
压测解决稳定性。
