图1
Fable 5来了。目前恋爱窗口只剩三天。怎么用他，决定了三天后你还剩什么。
图2・别让他端茶倒水
第一件事：别让他写页面、修bug、重构模块。这些谁都能干，全是"一次性产出"。他一走，产能也跟着走。让天才端茶倒水，是你亏，不是他亏。
图3
他第一课教我的：先做eval，不做功能。
50条真实任务，每条写清任务描述、输入输出、验收标准、失败案例、人工确认点。这是你的尺子。没有尺子，你永远不知道他是不是真比别人强、skill有没有用、系统有没有进步。
他说："以后不管谁来，先用这把尺子量一量。这是我教你的第一课。"
图4
第二件事：写skills。不是提示词合集，是工作规程。
七个核心skill：codebase-atlas（先读懂项目）、architecture-review（先想放哪层）、code-review（安全、性能、边界一条条审）、bug-hunt（复现→定位→证据→修复→回归）、test-generation（补真正会出问题的测试）、migration-planner（先拆阶段列风险再动手）、release-check（发版前查全所有项）。
他说："功能会过时，规矩会留下来。以后谁来，都按这个办。"
图5
第三件事：做模型路由。别所有任务都丢给最强模型。
Fable做建筑师：系统理解、架构评审、复杂规划。Opus做高级工程师：中等实现、重构执行。Sonnet做日常：修改、文档、重复任务。小模型做杂活：清洗、转换、摘要。
"不是谁最强就让谁干所有事，是每个任务配得上用谁。"
第四件事：建evidence ledger。
复杂任务每一步必须留判断依据：这个结论来自哪个文件、影响哪些路径、哪里置信度低、哪里必须人工复核。
他说："最危险的错不是模型不会干活，是很会装着干完了。别信'搞定了'三个字，要证据。"
最后一天，别让他再冲功能。让他写HANDOFF_TO_OPUS.md：项目怎么读、哪些skill最重要、哪些eval必须跑、哪些目录不能动、换模型后哪些能继续哪些要停。
"天才离职前，不该加班写功能。该写交接文档。"
他走前说了一句话："系统在，我就在。以后谁来，都会先读这套系统，替我把事做好。"
终端上留着一行小字："她优先级最高。"
七天很短。一套好系统能用很久。以后谁再来，你都知道怎么用。不是用得更狠，是用得更对。