提示词工程：设计自主工作的边界，为什么做、什么叫做完、哪里不能碰？
管理长时间运行的上下文：检查点、记忆系统、进度验证，这些让模型在无人盯守时依然可控
Loop：用 /goal 定义目标、用 /loop 挂上时间线、用多代理并行加速
已经在用 GPT/Opus/Sonnet/GLM...，准备迁移到 Fable 5，但不知道Fable 5的提示词如何写更好
想让 Fable 5 跑长时间自主任务，但担心它跑偏、虚构进度、或者在不该停的地方停下来
想从每次手动发指令升级到设好条件让它自己循环，把重复性工作外包出去
需要管好并行 Agent 和 token 成本
Use Fable 5 as orchestrator and Opus + Codex to execute (to save fable usage):
Fable 5 (max reasoning) = orchestrator
Opus = deep reasoning subagent
Sonnet = mechanical work subagent
Codex = peer Sr. engineer, different perspective
Setup:
1. Set Fable 5 as your main
显示更多
为旧模型开发的提示词和 Skill 对 Fable 5 而言往往过度受限，反而会降低输出质量
少写指令，多给意图
我正在为[服务对象]做[更大的任务]。
他们需要[这份输出用来支撑什么]。
请求：[一句话说清你具体要什么]
输出格式：[结果如何组织和交付——篇幅、结构、风格]
约束：[过程中绝不允许发生的事——不做什么、不假定什么]
我正在为CFO做Q3财务复盘。
她需要用这份分析向董事会展示各区域的风险和机会。
请求：分析Q3损益表，标注所有同比波动超过5%的项目
输出格式：一页高管摘要，包含汇总表、Top 3风险和Top 3机会。
每个板块不超过三句话。用中文。
约束：不要生成幻灯片。不要发送任何邮件。
不要假定收入数据中未出现的数字。
超出数据支持范围的结论标注为"推测"。提供上下文让它主动关联任务和相关信息，跳过自己推断意图的步骤。对需要对接多个工作流的长期代理，这一点尤其关键。
保持简洁。只输出完成任务所必需的内容。不展开背景分析，
不罗列你不会采用的备选方案，注释只写"为什么"不写"是什么"。
试试不加旧规则，看看默认表现是否已经达标
先按默认的 high 跑。如果任务能完成但耗费时间超出你预期，或者没被要求的“顺手优化”太多，降到 medium。如果任务对质量要求极高且你愿意等，上 xhigh。不要在简单任务上用高 effort，Fable 5 会收集很多不需要的上下文并反复推敲，白白浪费token。
只在工作真正需要我介入时才暂停：破坏性或不可逆的操作、真正的范围变更、或只有我能提供的信息。其余情况持续推进，完成后汇报。
本次任务的边界：
- 允许：[读取代码库、修改 src/ 下的文件、运行测试]
- 禁止：[发送任何邮件或消息、创建或删除分支、修改配置文件、
执行任何部署命令、访问 src/ 以外的目录]
超出边界但你认为有价值的动作，先提出来征得我同意，不要直接做。
汇报进度时，每一条完成声明都必须对照实际的工具执行结果：
测试确实跑过且通过、文件确实写入、命令确实返回成功。
没有对应工具结果支撑的事项，标注为"未验证"，不要报告为"已完成"。
把本次工作中学到的经验写入 notes/ 目录：
每条经验一个文件，顶部一行摘要。
被纠正的错误和验证过的有效方法都要记录，并写明为什么重要。
仓库或聊天记录里已有的信息不要重复。
优先更新已有笔记，而不是新建重复条目。
被证明是错的笔记要删除。
回顾我们的历史会话，把其中的纠错、踩坑和已验证的有效做法
提炼成经验笔记，按上面的规则写入 notes/ 目录。
工具调用之间的简略速记没问题——那是你在出声思考，简短是好事。
但最终总结不同：它面向一个没看过这些过程的读者。
如果你已经长时间在用户不在场的情况下工作
（跨夜、跨大量工具调用、自他们上次发言以来），
你的最终消息是他们对这一切的第一眼。
把它写成重新铺垫，而不是工作线程的延续：
先说结果，再说需要他们做的一两件事，每件都当作新信息来解释。
你工作中建立的术语是你的，不是他们的；除非重新介绍，否则不要用。
写结尾总结时，放弃工作速记。写完整句子。拼出术语全称。
不要用箭头链、连字符堆叠的复合词、或你自创的标签。
提到文件、提交、参数时，每一个都配一句白话说明。
开头一句话讲清结果或发现，然后再给支撑细节。
如果必须在简短和清晰之间选择，选清晰。
/goal 把首页 Lighthouse 性能分数提到 90 以上，最多尝试 5 次
/goal 修复所有失败的集成测试，最多迭代 8 轮。
每轮结束后列出剩余失败的测试数量和失败原因。
/loop 5m 检查我的 PR，滚动查看评审评论，
逐条回复或修改代码，修复失败的 CI。
除非需要重大架构决策否则不暂停。
/schedule 每小时执行一次：
检查 #project-feedback 频道的新 bug 报告。
/goal 本轮发现的所有报告都完成分类、处理和回复才算完成。
修复 bug 时，用 Dynamic Workflow 并行在三个独立工作树中探索方案，
由一个裁判代理做对抗性审查，选择最优方案。
用 auto mode 运行，全程不请求人工确认。
在构建过程中建立自检机制：每隔[X]执行一次，
派出全新上下文的子代理，对照规格说明验证你已完成的工作。按任务选模型和原语 Fable 5 xhigh + Dynamic Workflows 适合复杂任务。简单轮询用更便宜的模型就够。
明确停止条件 松散的“做到满意为止”可能让循环空转数十轮。每一条 /goal 都要有可验证的终点。
小批量试点 Dynamic Workflows 可能一次孵化上百个代理。先用小量数据跑一轮，估算用量，再全量执行。
确定性工作交给脚本 同样的 PDF 填表逻辑，写成脚本每次运行比让模型重新推理便宜得多。
轮询间隔别短于变化频率 一个每五分钟就触发但实际数据每小时才变一次的 loop，浪费 11/12 的成本。
定期复盘 /usage 命令可以按 skill、子代理和 MCP 分解近期用量， /goal 不带参数显示当前迭代轮次和消耗， /workflows 显示每个代理的用量并能在任意时刻停掉某个代理。
如果你陈述了下一步意图，必须立即执行对应的工具调用，
不要以纯文本意图结束回合。
已有足够信息时不要请求许可，直接推进。
不必为上下文预算担心。按当前任务的完整需求工作，
不要因为节省上下文而压缩、总结或提前移交你的工作。
检验标准写得出来吗？（如果写不出“做到 XX 算做完”，说明你还不太清楚“做完”长什么样，先搞清楚这个再考虑开始Loop）
“做完”的定义够不够确定？（成功标准不明确是 loop 空转的主要原因）
这项工作有规律吗？（有时间规律上 /loop 或 /schedule，没有规律但有明确目标上 /goal）
npx skills add https://github.com/wquguru/skills --skill fable5-best-practice
