大任务之前先找出自己不知道的：Thariq 的八种问法，本站在 Express 源码上试了找盲点、反过来问你和改动测验

这篇解决一个问题：交给 Claude 一个大任务，跑了很久，回来的结果不是你要的。问题往往不在模型，而在你交代的时候，有太多东西自己都没想到。

Anthropic 的 Thariq Shihipar 写过一篇短文讲这件事。他说 Fable 是第一个让他觉得“工作质量卡在我能不能把不清楚的地方说清楚”的模型。本文整理他的思路和八种问法，再在服务器上的 Express 源码里实测其中三种。

一、地图和实地

他用了一个比喻：你给 Claude 的提示词、skills、上下文是地图；代码库、真实世界、实际的约束是实地。两者之间的差距，他叫作“未知”。Claude 每碰到一个未知，就只能按它对你意图的最好猜测做决定。任务越大，碰到的未知越多。

而且光在开头做计划不够：有的未知要到实现的深处才冒出来，有的会告诉你这件事根本该换个做法。所以找未知是一个贯穿始终的过程：动手前、动手中、做完后都要找。

他把一件事要弄清的东西分成四类：

类别	是什么
已知的已知	你写进提示词里的：你告诉它你要什么
已知的未知	你知道自己还没想清楚的
未知的已知	你觉得理所当然、从来不会写下来，但一看到就认得出对不对的
未知的未知	你根本没考虑过的：不知道有这回事，也不知道能做到多好

交代得太细，Claude 会照着做，哪怕中途该换方向；交代得太粗，它会按行业惯例替你做选择，未必适合你。没把未知考虑进去，两头都会出错。

最重要的一步是告诉 Claude 你从哪里出发：你想到哪一步了，你对这个问题、这个代码库熟不熟，让它像一个一起想问题的伙伴那样跟你合作。

二、八种问法

阶段	问法	针对哪类未知	文章给的例子（大意）
动手前	找盲点	未知的未知	“我要加一个新的登录方式，但对这个代码库的认证模块一无所知。做一次 blind spot pass，帮我找出相关的 unknown unknowns，好让我更好地给你提需求。”原文建议直接用 blind spot pass 和 unknown unknowns 这两个词
动手前	头脑风暴和原型	未知的已知	“我要给这份数据做个看板，但我没什么审美，也不知道能做成什么样。做一个 HTML 页面，给我四个完全不同的设计方向。”“先别接后端，用假数据做一个工具栏的单文件 HTML 原型，我先看看布局。”
动手前	让它反过来问你	已知的未知	“一次问我一个问题，问清所有模糊的地方，先问那些答案会改变架构的。”
动手前	给参考	说不清楚的需求	“vendor/rate-limiter 里这个 Rust 库的退避行为正是我要的，读一下，在我们的 TypeScript 客户端里实现同样的语义。”他说最好的参考是源代码，比截图信息多得多，换一种语言也行
动手前	实现计划	最可能要改的决定	“用 HTML 写一份实现计划，把我最可能想改的决定放在前面：数据模型、新的类型接口、用户看得见的部分。机械的重构放到最后，那部分我信你。”
动手中	实现笔记	实现中冒出来的未知	“维护一个 implementation-notes.md。碰到逼你偏离计划的边界情况，选保守的做法，记在 Deviations 下面，然后继续。”
做完后	讲解和说服材料	审核的人和你一样的未知	“把原型、需求说明和实现笔记打包成一份能直接发到 Slack 拿到同意的文档，开头放演示动图。”
做完后	测验	你自己没看懂的改动	“我想确认自己理解了这次改动的全部。写一份 HTML 报告，讲背景、直觉、做了什么，最后附一组我必须答对的测验题。”他说自己只有全答对了才合并

几点补充：

头脑风暴放在几乎每次会话的开头。 他说这能帮他一开始就带着意图划定范围，Claude 常会找到他漏掉的高价值做法，也偶尔会只见树木不见森林；头脑风暴让他不至于把范围定得太窄或太宽。原型尽量早做：需求的一点点变化，在代码里可能是完全不同的实现，而让智能体撤回已经做的改动更难。
实现时开一个新会话。 计划满意之后，新开一个会话，把需求说明、原型这些产出交给它，上下文是干净的，信息一样不少。
用 HTML 写计划和报告，本站在《让 Claude Code 用 HTML 而不是 Markdown 输出》里写过为什么。

他自己的例子：Fable 的发布视频是用 Claude Code 从头剪到尾的，而他不是做视频的。他先让 Claude 讲清楚 Whisper 这类转写是怎么工作的、能不能用 ffmpeg 准确剪掉“嗯”和长停顿；不确定画面能不能跟着说话的字走，就先让它用 Remotion 做一个原型；画面发灰，他知道是调色的问题但不懂调色，一开始想让 Claude 出几个版本挑，后来发现自己根本不知道什么样算好，于是改成先让 Claude 教他调色。本站做视频的两篇在这里。

三、本站实测

实测环境
日期	2026-10-16
代码	Express 5.3.0 的源码，本站之前实测用过的那份（上面有几个做修 bug 演示时留下的提交）
Claude Code	2.1.300，用 `claude -p` 跑，接着问用 `--resume`；模型是默认的 Opus 5.5，不是原文说的 Fable
权限	只放行读文件的 `Read`、`Grep`、`Glob`，写报告那一步加上看 git 记录的命令和 `Write`；不许改代码、不许跑测试
接口	通过酷站AI 中转站，不是直连官方

找盲点：一个看起来很简单的需求

我们装作一个对 Express 完全不熟的人，提了一个需求：

我要在这个仓库里给 req 加一个新的属性，按自定义的规则解析子域名，比如能正确处理 example.co.uk 这种两段的顶级域名。但我对 Express 的 request 对象、它的设置项和测试都完全不熟。先别写代码。请做一次 blind spot pass，帮我找出这件事上我的 unknown unknowns，讲给我听，好让我接下来能更好地给你提需求。

它读了 8 轮代码，列了十条，分成需求本身、request 对象、设置项、测试和交付四组。挑几条：

难点在规则从哪来，不在拆字符串。 程序看不出 co.uk 是一个整体，业界的做法是查 Public Suffix List，而这份列表有几千条、会更新、还分 ICANN 段和私有段（github.io 这类算不算后缀，要你定）。
现有功能可能已经够用。 Express 有一个 subdomain offset 设置，默认值是 2。如果应用只服务一个固定域名，app.set('subdomain offset', 3) 就能正确处理 example.co.uk，不用新加属性。
req.xxx 是原型上的惰性 getter，每访问一次算一次，而且只有 getter 没有 setter，别的中间件如果给同名属性赋值，严格模式下会直接抛错。
输入来自 req.hostname，坑不少： 开了 trust proxy 时它读的是客户端可以伪造的 X-Forwarded-Host，用子域名区分租户的话就是安全问题；它不转小写；末尾带点、IPv6、IP、localhost、没有 Host 头、punycode 形式的国际化域名都要定行为。
改的是框架本身。 要提交到上游的话，Express 的维护者大概率不愿意把这么大的依赖放进核心。

最后它反过来列了五个要我回答的问题。

我们核对了它引用的几处：subdomain offset 默认值确实在 lib/application.js 第 98 行设成 2，defineGetter 确实在 lib/request.js 第 524 行。一个“加个属性”的小需求，真正要先定的事至少有五六件，其中最值钱的一条是：可能根本不用写代码。

让它反过来问你：一次一个问题

接着在同一个会话里：

先别给方案。像面试一样，一次只问我一个问题，问清楚这件事里还模糊的地方。先问那些答案会改变整体设计的问题。

它每次只问一个，给几个选项，并且说明为什么先问这个：

这个改动最后给谁用？ 自己的 fork、提交到上游、还没想好。它解释：提交到上游的话方案要缩得很小，比如只让 subdomain offset 接受一个函数；自己用的话怎么做都行。我们答：只在公司内部的 fork 里用。
同一个应用要同时处理哪些域名？ 只有一个固定的主域名、几个后缀段数相同的、后缀段数不同的、事先不知道的。它解释：前两种用现有设置就行，可能一行代码都不用改；只有后两种才需要新属性；最后一种基本只能用完整的 Public Suffix List。我们答：所有请求都是 *.example.co.uk。
它先给出结论：tobi.ferrets.example.co.uk 在默认设置下得到 ["example", "ferrets", "tobi"]，多了一个 example；设成 3 就是 ["ferrets", "tobi"]。然后问：既然一行配置就能解决，你还想新加一个属性，是出于什么考虑？ 选项里有“之前不知道有这个设置”“想要的结果格式不一样”“担心以后接入别的域名”“有些请求的 Host 不是这个域名”。

第 3 个问题里的两个结果，我们在服务器上写了几行代码验证过，和它说的一样。

三个问题问下来，原本要写的一个新属性，变成了“先确认是不是改一个设置就够了”。这就是文章说的：答案会改变架构的问题先问。

做完后：读改动、做测验

这一步开一个新会话，换一件事：这份代码在 5.3.0 之后有 4 个提交（是之前做修 bug 演示时留下的：一次“重构”、一次修复、一次补文档、一次补测试）。我们让它写报告、出测验：

我想确认自己完全理解了这个仓库在 v5.3.0（cf6722b）之后的全部改动，也就是 cf6722b..HEAD 的几个提交。请写一份 HTML 报告，存到 notes-h57/changes.html：讲清背景和直觉、每个提交做了什么、为什么、有什么风险。报告最后附一组测验题，我必须全部答对才会合并。答案不要写进报告里。

报告有四节：req.subdomains 是怎么算出来的、逐个提交、整体风险、测验。它的核心结论：

和 5.3.0 相比，运行时行为没有任何变化。 那次“重构”删掉了 req.subdomains 里的 .reverse()，其实改错了行为，下一个提交又改了回来，两者正好抵消；lib/ 的净变化只有补文档时加的 3 行注释。
风险： 中间那个改错的提交上测试是不通过的，会干扰 git bisect，建议合并前把它和修复的提交一起删掉；新加的注释说“IP 不会被按点拆分”不够准确，带方括号的 IPv6 地址照样会被拆开；测试和给 AI 看的 CLAUDE.md 混在同一个提交里。

第二条风险我们验证了：Host 是 [::ffff:127.0.0.1]:3000 时，req.subdomains 返回 ["0","[::ffff:127"]，确实被按点拆开了。它也说明了哪些结论没有验证：跑测试和 node 的命令没有放行，那几处是读代码推出来的。

测验一共 10 道题，从“默认设置下 a.b.c.example.com 的 req.subdomains 是什么”，到“如果原样保留这 4 个提交，会带来哪两个具体问题、你会怎么整理这段历史”。

我们接着在同一个会话里答了 3 道，故意答错一道：第 2 题问在那个改错的提交上，tobi.ferrets.example.com 返回什么，我们答“还是 ["ferrets","tobi"]，因为只删了 reverse，取哪几段没变”。它判第 1、4 题对，第 2 题错，并讲清了错在哪：slice 砍掉的总是数组开头的几段，而开头是哪几段正是由 reverse() 决定的；去掉它以后砍掉的是 tobi 和 ferrets，返回的是 ["example","com"]，子域被丢掉、剩下主域，意思完全颠倒。它也照我们的要求，没有透露其余 7 题的答案。

只看 diff 的话，那一行的删除很容易被当成无害的简化。测验逼你把它推一遍。

花费

全部按 Claude Code 估算的官方价：找盲点加三轮问答约 0.38 美元，写报告加判题约 0.67 美元，一共约 1.05 美元。

用 --resume 接着问时注意：--output-format json 输出里的 total_cost_usd 是整个会话累计的，不是这一次调用的。我们第三轮问答显示 0.38 美元，其实那一轮只读了 4 万多个缓存的 token、写了 634 个 token，自己只花了两三美分。

四、怎么用到自己的工作里

进一块不熟的代码、做一件没做过的事，先找盲点，并且说清楚你熟什么、不熟什么。
找完盲点，让它一次问一个问题，指定先问会改变设计的。这一步常常能把任务缩小，甚至取消。
说不清楚的，给它一份源代码当参考。
计划写成 HTML，把你最可能改的决定放在最前面；满意之后开新会话实现，让它维护实现笔记，偏离计划时记下来。
做完以后，让它出测验，答对了再合并；要拿别人的同意，让它把原型、说明和笔记打包成一份讲解。
长任务做歪了，先别怪模型：多半是该在前面多花点时间弄清未知，或者计划里没给你和 Claude 留出调整的余地。

这几种问法对 Opus 5.5 也一样管用，本站的实测用的就是它。原文讲的是 Fable，篇幅很短，以上的问法都按原文的意思整理，没有逐句翻译。上下文还该怎么给，见《Claude 5 这一代模型的上下文怎么写》。

没有实测的部分

八种问法里，本站实测了找盲点、反过来问你、测验三种。头脑风暴和原型、给参考、实现计划、实现笔记、讲解材料，按原文整理，没有实测。

参考

Thariq Shihipar：A field guide to Claude Fable 5: Finding your unknowns（Claude 博客，2026-07-06）