Thariq (@trq212)
2026-07-04
D
原文
---
title: "Fable 实践指南：发现你的未知项"
author: "Thariq (@trq212)"
source_url: "https://x.com/trq212/status/2073100352921215386"
published_at: "2026-07-03T17:43:35.000Z"
fetched_at: "2026-07-04T15:40:57Z"
updated_at: "2026-07-04T16:19:23Z"
language: "zh"
review_status: "draft"
---
# Fable 实践指南：发现你的未知项
使用 Claude Fable 5 时，我不断重新学到一个老道理：任务描述不等于真实任务。
我交给 Claude 的 prompt、skills 和上下文，只是对待完成工作的描述；真正的工作发生在代码库、现实世界，以及其中真实存在的约束里。
任务描述和真实任务之间的差距，就是我所说的*未知项*。当 Claude 遇到一个未知项时，它需要基于对我意图的最佳猜测做决定。做的工作越多，Claude 可能遇到的未知项就越多。
Fable 是第一个让我觉得工作质量受限于“我能否把未知项说明白”的模型。
重要的是，提前规划并不总是足够。你可能会在实现深处发现未知项；也可能是你的未知项提醒你，其实应该用完全不同的方式来解决这个问题。
我发现，和 Fable 一起工作，是一个在实现前、实现中、实现后不断发现自己未知项的迭代过程。
我做了一些**[用于发现未知项的示例 artifact（产物）](https://thariqs.github.io/html-effectiveness/unknowns/)**，但请务必回来继续读，建立什么时候该用它们的直觉。
### 了解你的未知项
你的未知项是什么？当我带着一个问题来找 Claude 时，我通常会从 4 个角度拆解它：
- **已知的已知：** 本质上就是我 prompt 里的内容。我告诉 agent 自己想要什么？
- **已知的未知：** 有哪些东西我还没弄清楚，但我知道自己还没弄清楚？
- **未知的已知：** 有什么东西明显到我永远不会写下来，但只要看到就能认出来？
- **未知的未知：** 有什么东西我完全没有考虑过？有什么知识是我不知道自己不知道的？我知道一件事可以做到多好吗？
最擅长用 agent 写代码的人，通常会让未知项变得更少。看 [Boris](https://www.google.com/url?q=https://www.linkedin.com/in/bcherny&sa=D&source=editors&ust=1783101769343560&usg=AOvVaw0NSN4RLOEaJ_k7bIWfat2t) 或 [Jarred](https://www.google.com/url?q=https://www.linkedin.com/in/jarred-sumner-a8772425&sa=D&source=editors&ust=1783101769343738&usg=AOvVaw1jFeuVIbBffAC5464Tk_TD) 写 prompt，我很明显能感觉到，他们非常细致地知道自己想要什么。他们既和代码库深度同步，也和模型行为深度同步。
但他们也会预设未知项。在很多方面，减少并提前规划你的未知项，就是 agentic coding 这项**技能**本身。幸运的是，这是一项你可以通过和 Claude 一起工作来提高的技能。
### 让 Claude 更好地帮你
给 Claude 下指令是一种微妙的平衡。如果你太具体，Claude 会照着你的指令走，即使转向可能更合适。如果你太含糊，Claude 往往会根据业界最佳实践做选择和假设，而那些做法未必适合你的任务。
如果你没有把未知项考虑进去，两边都会失败。你不知道什么时候路径上会布满障碍，也不知道什么时候路径其实很清楚、但你仍然希望 Claude 能够转向。
Claude 能帮你更快发现自己的未知项。它能极快地搜索你的代码库和互联网，而且它对一般主题知道得比你多得多。它也能更快地从失败中迭代。
这个过程中最重要的一点，是给 Claude 关于你起点的上下文。比如，告诉它你思考到了哪一步；说明你对这个问题和代码库有多少经验；让它像思考伙伴一样和你一起工作。
我之前写过如何把 [HTML 和 Claude](https://x.com/trq212/status/2052809885763747935) 结合使用。在几乎所有这类情况下，HTML artifact（可视化产物）都是把它可视化、呈现出来的最佳方式。
这篇文章会详细说明我用来揭示这些未知项的一些模式。我不是每次都会用到每一种技巧，但拥有这样一组技巧很有用。
## 实现前
### 盲区检查
开始工作时，你能做的最有用的事情之一，是理解自己的盲区。比如，如果你要在代码库的新区域里写一个功能，或者用 Claude 帮你做不熟悉的工作，比如迭代一个设计，你很可能会有很多**未知的未知**。
你可能不知道该问什么问题，不知道好的结果长什么样，不知道过去做过哪些历史工作，也不知道要避开哪些坑。
要做到这一点，你可以请 Claude 帮你找出自己的未知的未知，并向你解释它们。我喜欢直接使用“blindspot pass”和“unknown unknowns”这两个原词。告诉它你是谁、你知道什么，通常也很重要。
**示例 prompt：**
- “我正在添加一个新的 auth provider，但我对这个代码库里的认证模块一无所知。你能做一次 blindspot pass，帮我弄清楚与我相关的 unknown unknowns，并帮我更好地给你写 prompt 吗？”
- “我不知道什么是调色，但我需要给这个视频调色。你能教我理解自己关于调色的 unknown unknowns，让我能更好地写 prompt 吗？”
### 头脑风暴和原型
当我在一个有大量**未知的已知**的领域工作时——也就是那些我只有看到才知道如何定义标准的东西——我喜欢请 Claude 和我一起头脑风暴、做原型。
在原型阶段尽早识别并说出未知的已知，极其有价值，因为等到实现过程中才发现它们，代价可能会（相对）更高。功能或 spec 里的一个小改动，可能会导致代码实现发生巨大变化，而且你的 agent 要回滚之前的修改也会更困难。
比如，你可能只是想看看在某个 frame 上加一个按钮是什么效果，而不想为此接上后端路由，或在前端维护额外状态。
视觉设计对我来说很难用语言说清楚，但我看到时就知道自己想要什么。在这些情况下，我会要求它为一个 artifact 提供几种设计方向。
我也几乎会用一次探索或头脑风暴阶段开启每一次编码会话。这能帮助我带着定义项目范围的意图开始。Claude 经常会找到我本来会错过的高价值做法，有时也会只见树木不见森林。头脑风暴可以避免我把范围定得过窄或过宽。
**示例 prompt：**
- “我想给这些数据做一个仪表盘，但我没有视觉品味，也不知道可能做到什么程度。给我做一个 HTML 页面，包含 4 个差异很大的设计方向，好让我对它们做出反应。”
- “在接任何真实逻辑之前，先用假数据做一个单文件 HTML，模拟新的编辑器工具栏。我想在你碰真实应用之前，先对布局做出反应。”
- “这是我的粗略问题：用户在 onboarding 之后流失。搜索代码库，头脑风暴 10 个我们可以介入的位置，从最便宜到最有野心排序。我会告诉你哪些让我有感觉。”
### 访谈
一旦我做了足够多的头脑风暴，我很可能仍然有未知项。
在这种情况下，我会请 Claude 围绕任何未知项或模糊之处采访我。让 Claude 采访你时，试着给它关于你问题的上下文，引导它提问。下面是一些例子。
**示例 prompt：**
- “一次问我一个问题，采访我关于任何模糊之处的想法；优先问那些我的回答会改变架构的问题。”
### 参考
有时候，你无法详细描述自己想要什么。比如，你可能缺少相应语言；也可能事情太复杂，说清楚需要花很久。
在这种情况下，最好的答案是参考。你可以提供图表、文档或图片，但绝对最好的参考是*源代码*。
如果你有一个库用某种方式实现了某个东西，或者有一个你非常喜欢的设计组件，那就直接把 Fable 指向那个文件夹，告诉它该看什么，即使它用的是另一种语言。
Claude Design 也是这样工作的。你不必递给它一个文件（当然也可以这么做）。你可以把它指向你喜欢的网站上的某个模块，它会读取底层代码，而不只是看截图。这会提供关于标记结构、整体结构，以及组件实际构建方式的丰富得多的细节。
**示例 prompt：**
- vendor/rate-limiter 里的这个 Rust crate 实现了我想要的精确 backoff 行为。读取它，然后在我们的 TypeScript API client 里重新实现同样的语义。
### 实现计划
当我觉得自己已经准备好实现时，我通常会请 Claude 组合一份实现计划供我审阅，重点放在最可能发生变化的部分，比如审阅数据模型、类型接口或 UX flow。这样 Claude 就能浮现出我可能确实需要修改的东西。
**示例 prompt：**
- “用 HTML 写一份实现计划，但开头先放我最可能想调整的决定：数据模型变化、新的类型接口，以及任何面向用户的东西。机械性重构放到底部，那部分我信任你。”
### 实现中
### 实现笔记
当我对计划满意后，我会新开一个 session，并把所有 artifact 传进 prompt。比如，我可能会传入一个 spec 文件和一个原型，然后请一个 agent 去实现它。
但事实是，无论你规划得多充分，总会有未知的未知潜伏着。agent 可能会在工作过程中发现，因为代码里的某个边界情况，它需要换一种做法。
我会让 Claude Code 维护一个临时的 ‘[implementation-notes.md](https://www.google.com/url?q=http://implementation-notes.md&sa=D&source=editors&ust=1783101769359369&usg=AOvVaw1Iqvg51JpzkrkRtHHIjyOL)’（或 .html）文件，在里面记录它做出的决定，这样我们能从下一次尝试中学习。
**示例 prompt：**
- “维护一个 [implementation-notes.md](https://www.google.com/url?q=http://implementation-notes.md&sa=D&source=editors&ust=1783101769359896&usg=AOvVaw1wFqbnqbAuO_GYnGk8_1bh) 文件。如果你遇到某个边界情况，迫使你偏离计划，就选择保守选项，把它记在 ‘Deviations’ 下，然后继续。”
## 实现后
### 提案和解释材料
发布某个东西时，最重要的部分之一，是获得认同和批准。在最终文档里制作提案和解释型产物会有帮助：
- 当审阅者一开始也带着和你一样的未知项时，加速理解
- 当专家想确认你已经考虑到他们本来也会预判到的未知项和常见失败点时，加速批准
**示例 prompt：**
- “把原型、spec 和实现笔记打包成一个单一文档，我可以直接丢到 Slack 里争取认同。开头放 demo GIF。”
### 小测验
经过一次很长的工作 session 之后，Claude 可能完成了比我意识到的多得多的事情。阅读代码 diff 只能让我浅浅理解发生了什么，因为很多行为会取决于现有代码路径。
让 Claude 在给我大量上下文之后，对这个改动测验我，有助于我理解发生了什么。只有当我完美通过测验后，我才会合并。
**示例 prompt：**
- “我想确保自己理解这次变更里发生的一切。给我一份关于这些变更的 HTML 报告，让我带着上下文、直觉、实际做了什么等内容去阅读和理解，并在底部放一个关于这些变更的小测验，我必须通过它。”
### 这套方法如何合在一起：发布 Fable
[Fable 的发布视频](https://www.google.com/url?q=https://x.com/ClaudeDevs/status/2064399512664526853&sa=D&source=editors&ust=1783101769363678&usg=AOvVaw1MyZd5YMjjShztWHzo8N9u)完全由 Claude Code 剪辑。这对我来说是一个新领域，而我绝不算专家。
所以我从自己确实知道的东西开始。我知道 Claude 可以用代码来编辑视频并做转录，但不确定它是否足够准确。然后我请 Claude 向我解释 Whisper 这类转录是如何工作的，以及我是否能用 ffmpeg 准确剪掉“嗯”之类的口头填充词或大段停顿。
我希望 Claude 创建一个 UI，让它和我正在说的词对齐计时，但我不确定它能不能做到，所以我请 Claude 用 Remotion 和一份转录文本创建一个原型视频，看看这是否可行。
最后，视频本身看起来有点灰暗。我知道这是调色的结果，但我其实不知道什么是调色。我第一次尝试，是让 Claude 做几个变体供我挑选，但我意识到，在调色这件事上，我并不知道“好”是什么样子。于是，我改为请 Claude 教我关于调色的知识，以发现我的未知项。
你可以在[**这里观看更深入的解释**](https://x.com/trq212/status/2064826394589442448/video/1)。
### 让任务描述贴近真实任务
模型越好，你用正确方法能达成的事情就越多。当一个长程任务返回了错误结果，很可能说明你需要花更多时间定义自己的未知项，或者创建一份实现计划，让 Claude 能够在穿过这些未知项时即兴调整。
每一份解释材料、头脑风暴、访谈、原型和参考，都是一种低成本方式，能在修复代价变高之前，让你发现自己原本不知道的东西。
所以，下一个项目开始时，请先让 Claude 帮你找到自己的未知项。