Fable 5.1 擅长的是 跨步骤、可恢复的难任务 ：改大仓库、长程终端操作、带工具的知识工作。Prompt 若仍写成「帮我优化一下这段代码」，模型会自己补目标，结果往往偏题或路径过长。5.1 比 5 更听中途指令、更少乱走捷径，但仍需要你把 成功标准、边界和工具 写清楚。
一、和短聊天模型不同的三点
- 目标要可验收
写「通过哪些测试 / 满足哪条性能指标 / 交付哪些文件」，少写「更好、更优雅」。 - 过程允许长，但要有检查点
5.1 适合数小时级会话；提示里应要求：阶段小结、失败回退、未完成项列表。 - 缓存与 effort 是 Prompt 的一部分
稳定前缀（人设、工具说明、仓库地图）便于缓存；简单任务不要默认 max effort，否则输出 Token 易膨胀。
二、推荐结构：八层 brief
按顺序写，可整段复用为系统提示模板：
| 层级 | 写什么 |
|---|---|
| 角色 | 资深工程师 / 评审者 / 研究员（选一个） |
| 目标 | 一句话业务结果 |
| 成功标准 | 可测试、可勾选的条目 |
| 上下文 | 仓库路径、语言版本、相关模块 |
| 约束 | 禁止改动的目录、风格、安全边界 |
| 工具 | 允许的 shell / 测试命令 / 浏览器 |
| 工作方式 | 先计划再改代码；每步验证；中途指令要合并执行 |
| 输出 | 摘要 + 文件列表 + 风险 + 未完成项 |
Fable 5.1 对「中途追加要求」更稳，仍建议在模板里写死：新指令与原任务一并完成，并分别汇报。
三、编程场景示例
1. 跨模块重构
你是熟悉本仓库的资深后端工程师。目标：将
billing模块的支付回调从同步改为幂等队列，不改变对外 HTTP 契约。成功标准：现有集成测试全部通过；同一
event_id重复投递不产生重复入账；文档docs/billing.md更新一节。约束：禁止修改
legacy/api/v1；禁止引入新的消息中间件，使用现有 Redis 队列。工作方式：先给出影响面与步骤计划，再逐文件修改；每步运行
make test-billing；若失败，先修测试再继续。结束后输出：变更文件列表、测试结果、残留风险。
2. 根因修复（避免只贴症状）
生产日志见附件。不要只做空指针防护。请定位根因（数据竞态 / 错误重试 / 配置）并给出最小修复。
成功标准：复现脚本
scripts/repro_race.py连续 20 次无失败；说明根因与为何旧写法会复发。
3. 代码评审
仅评审与本次 PR 相关的正确性、并发与安全问题。不要风格吹毛求疵。
输出：按严重级别列出问题；每条给文件位置、风险、建议改法；无问题写「无阻塞项」。
四、长程 Agent / 调研示例
目标：评估将 X 服务迁到 Y 方案的可行性，形成可执行结论。
允许使用：文档站点、仓库内
docs/、指定测试集群。约束：不修改生产配置；引用需标注来源。
工作方式：分阶段（现状 → 方案对比 → 风险 → 迁移步骤）；每阶段结束先写小结再进入下一阶段；发现假设不成立时回到上一阶段修正。
最终交付：一页结论、对比表、分周迁移计划、开放问题列表。
科研或数据类任务可要求「实验记录可复现、失败也保留结论」，与 5.1 在长程科研 Agent 上的加强方向一致。
五、常见反模式
| 反模式 | 更好的写法 |
|---|---|
| 「随便优化性能」 | 「p95 延迟从 X 降到 Y，基准脚本为 ...」 |
| 整库粘贴无重点 | 先列相关目录，再按需读文件 |
| 不设禁止项 | 「不得改 public API / 不得删测试」 |
| 全程 max effort | 小改用低/中档，难任务再升高 |
| 无验收 | 「测试命令与通过标准」写进同一段 |
六、Token 与成本相关的提示技巧
- 系统提示保持稳定，利于 cache read（5.1 缓存读更便宜）。
- 要求「计划不超过 N 条、实现前先确认」可减少无效大改。
- 明确「不要复述大段源码，只给 diff 级说明」。
- 多文件任务要求「一次只深度处理一个子系统」，降低上下文噪音。
七、接入与多模型
Prompt 模板可在 Claude 官方、云厂商与兼容网关之间复用，主要改模型 ID 与密钥。若需把 Fable 5.1 与 Codex、GLM 等放在同一工作流，可用分组 API 管理权限。
DDS Hub 采用 Model Group：先选分组再创建 Key，便于旗舰模型与日常模型分开。文档：https://www.ddshub.cc/docs 。
结语
Fable 5.1 的 Prompt Engineering，重点不是堆更长的形容词，而是 可验收目标、硬约束、工具边界与阶段检查点。把成功标准写进提示，模型更少改症状、更多改根因；再配合合理 effort 与缓存，长程任务才既强又控得住成本。先在一个真实仓库固化模板，再推广到团队默认 Agent 配置。