夜雨聆风AI 写完代码提交合并时，盯着几百行的 diff 来看，估计一会儿眼睛就受不了。可是又不敢不看——生怕漏检查哪里，回头又是一轮返工。
Claude Code 团队的工程师最近说了句挺反常识的话：这个动作，从一开始就放错了位置。
不是你看得不够仔细。是检查点，放错了层。
一、十条建议，其实是一张新的分工表
6 月 9 日，Anthropic 发了 Claude Fable 5。同一天，Claude Code 团队的工程师 Thariq Shihipar 就在 X 上甩出了 10 条针对新模型的工作流建议。后来被 48 万粉的大 V Rohan Paul 一转，直接刷屏了。（Thariq 的原帖访问受限，下面内容是综合转述帖和几个聚合页交叉还原的，已经尽量滤掉了转述里的噪声。）
大多数人看完，就当 10 个并列的技巧，收藏，关掉。
但你要是换个分法，按「这件事到底归人，还是归 AI」重新分组，会发现它根本不是技巧清单，而是一张分工表。
总纲（第 1 条）：把检查方式从「做没做对」换成「在不在做正确的事」。
这两个有什么区别？打个比方，你带一个能力很强的新人：你不会逐行 review 他每次提交，但方案评审你一定会参加。这一条其实是给你换岗——从质检员变成定方向的人。后面九条，全是换岗后的操作手册。
人的活，全在结构层（第 2 到 6 条）：
• 提前把完整的业务背景给够，别一上来就钻实现细节 • 从一份小 spec 起步，让 AI 反过来访谈你，把歧义和风险一次性问完 • 让它先出几版不同方向的快速 HTML mockup，写代码之前就把方向对齐 • 给业务背景（比如「这是个下个月就下线的临时功能」），别给死约束（比如「函数不许超过 50 行」） • 方向定了，再给清晰的目标和验收方法
AI 的活，全在执行层（第 7 到 10 条）：
• 用 /goal命令，让它一直干到目标达成• 用 Workflows 并行执行、自我验证 • 把前面两步拼成一句咒语：「设一个目标完整实现这份 spec，然后用一个 workflow 验证每个部分」 • 敢于给大任务，把 Fable 5 当成一个能完成以前不可能任务的模型
你发现没有，人的那五条，没有一条发生在代码层。上下文、spec、mockup、业务边界、验收标准，全是「写代码之前」的事。
这就是检查点搬家：你的精力，从「事后趴在 diff 上」，整体挪到「事前把结构定清楚」。
为什么偏偏是现在搬？得看一个时间上的巧合。
十条发布的同一天，Fable 5 在一个叫 FrontierCode 的新基准上拿到了 29.3%。这个榜由 20 多位顶级开源项目的维护者亲手出题，评分标准只有一句话：「这个 PR，我愿不愿意合并。」
一天前，这个榜的最高分还是 Opus 4.8 的 13.4%。一天之间，翻倍。（这两个数字都是该榜最难子集的口径，而且基准才发布两天，建议当「方向参考」，别当精确事实记。）
翻倍说明什么？说明模型第一次让「放手让它跑完」的期望收益，压过了「每一步都盯着」的安全收益。检查点搬家这件事，才从一种理想主义，变成了性价比上的最优解。
再往前翻，这也不是孤例。
Thariq 今年 3 月发过 Skills 使用九条，4 月发 Session 管理六条（讲 context rot、讲 /rewind），5 月写《HTML is the new markdown》主张用 HTML 写 spec，6 月就是这十条。每一篇，都绑着一个新功能。
串起来看是一条很清楚的轨迹：官方教你检查的位置，从代码行，到上下文，再到 spec 和目标，一路往上搬。
二、这套打法你可能眼熟：先列结构，再执行
把十条压扁了看，它跟我之前用 AI 给孩子做科普绘本时踩出来的方法，是同一个路子。
当时的教训很惨：直接跟 AI 说「画一张地球剖面图」，必翻车。因为你逼着它一个人同时扛两件事，既要「想清楚该画哪些结构」，又要「画得好看」，结果两头都塌。
后来我把它拆成两步。
第一步，只让它动脑：先别画，列一份结构清单，该有哪些要素、配什么短标签、要避开哪些常见错误。
第二步，才让它动手：严格照着清单渲染，只管版式和配色。
最值钱的发现不是这个拆法本身，而是拆完之后才看清的一点：表现层那段提示词，成了一个万能模板，换任何主题都一个字不用改。第一步天天换，第二步永远不变。
Thariq 这十条，就是这个两步法放大到整个工程协作的版本。逐项都能对上号：
/goal | |
共同的母模式，就一句话：结构与执行，分家。
人占住结构层，管业务语义、价值判断、验收标准，这恰恰是 AI 最难替代的那一块。AI 占住执行层，管实现、自测、修复，这恰恰是它一天比一天强的那一块。
更有意思的是这条分界线的移动轨迹。
2025 年，官方最佳实践还在教「怎么让它把活干对」，那会儿人还在执行层里陪着跑。2026 上半年，变成教「怎么管理它的注意力」，人退到了上下文层。Fable 5 之后，教「怎么管理它的方向」，人又退到了目标层。
模型每强一代，人就往上退一格。但「结构与执行分离」这条原则，一次都没变过。
所以别死记那十条。十条只是当前这代模型能力下切出来的一个截面，半年后姿势大概率会换。原则才是那个不动点。学会原则，姿势自己会长出来。
三、能直接抄的，和先别全信的
光讲道理没用，给你能上手的。
先说两段可以原样抄走的。
spec 访谈开场白（对应第 3 条）。现在每个不那么琐碎的任务，我都用它开场：
这是背景和一份粗略的 spec。先别写代码，先访谈我：把你觉得有歧义、有风险、需要我拍板的问题，一次性列出来问完。
组合咒语（第 9 条原话）：
设一个目标完整实现这份 spec，然后用一个 workflow 验证每个部分。
前提是你的版本够新：/goal 命令 5 月 12 日随 v2.1.139 上线，Workflows 5 月 28 日随 Opus 4.8 上线。老版本没这两个开关，咒语念了也不灵。
**再说三处，先别全信。**这是调研时交叉验证抠出来的边界。
第一，官方自己留了余地：能用一句话说清的改动，跳过 plan，直接干。别把十条理解成「凡事先开个会」。小任务硬走一遍 spec 访谈，那点固定开销反而亏。这也是社区对 plan-first 打法吐槽最集中的地方，就一个字：贵。
第二，十条是按理想环境写的：干净的仓库、管够的预算。可现实里那种祖传大仓库，业务逻辑长在几个老员工的脑子里，你让 AI 来访谈你，很多问题你自己都答不上来。「方向对不对」这个判断，到头来还是结结实实落回人身上，而这恰恰是最难的部分，十条没替你解决。
第三，29.3% 的另一面，是七成的产出仍然到不了「可合并」那条线。检查点上移，不等于不检查。关键路径上的 diff，该抽查还得抽查，只是别再把「逐行看」当成唯一的、默认的检查方式。
Thariq 这十条最大的价值，其实不是教你十个动作。是它低头承认了一件事：模型再强，「什么值得做、做到什么程度才算好」，依然是人的活。
结构层，暂时还是我们的。能守多久，看下一代模型。
