一套实用框架，用于识别并解决制约 AI 辅助编程工作的四类未知量。
AI translation, not an official translation. Refer to the original for technical details.
Adapted from @trq212# 寓言野外指南：找出你的未知量 与 Claude Fable 5 协作一再让我重温一个老道理：地图不是疆域。 地图是对待完成工作的表征，即我的提示词、技能和上下文——也就是我提供给 Claude 的内容。疆域则是工作真正发生的地方——代码库、现实世界及其实际约束。 地图与疆域之间的差距，就是我所说的"未知量"。当 Claude 遭遇未知量时，它需要根据对我意图的最佳猜测来做出决策。工作量越大，Claude 可能遇到的未知量就越多。 Fable 是第一个让我感受到——工作质量的瓶颈在于我能否厘清其未知量的模型。 重要的是，提前规划并不总是够用的。你可能在深入实现时才发现未知量，或者你的未知量会指引你意识到：其实应该用完全不同的方式来解决这个问题。 我发现，与 Fable 协作是一个迭代过程，需要在实现前、实现中和实现后不断发现未知量。 我在这里制作了一些用于发现未知量的示例制品，但请务必回过头来建立直觉，判断何时该使用它们。(https://thariqs.github.io/html-effectiveness/unknowns/) ## 了解你的未知量 你的未知量是什么？当我带着一个问题来找 Claude 时，我通常从四个维度来分解它： - 已知的已知：这基本上就是我提示词里的内容。我告诉智能体我想要什么？ - 已知的未知：我还没弄清楚，但我知道自己没弄清楚的是什么？ - 未知的已知：太显而易见以至于我从不会写下来，但一旦看到就能认出的是什么？ - 未知的未知：我完全没有考虑到的是什么？我不知道自己不了解的知识是什么？我知道某件事能好到什么程度吗？ 最优秀的智能体编程者拥有相对较少的未知量。看 Boris 或 Jarred 这样的人写提示词，我明显感受到他们对自己想要的东西了如指掌，极为详尽。他们与代码库和模型行为都高度同步。(https://www.google.com/url?q=https://www.linkedin.com/in/bcherny&sa=D&source=editors&ust=1783101769343560&usg=AOvVaw0NSN4RLOEaJ_k7bIWfat2t) (https://www.google.com/url?q=https://www.linkedin.com/in/jarred-sumner-a8772425&sa=D&source=editors&ust=1783101769343738&usg=AOvVaw1jFeuVIbBffAC5464Tk_TD) 但他们同样会预设未知量的存在。从很多意义上说，减少并规划你的未知量，正是智能体编程的核心技能。好在这是一项可以通过与 Claude 协作来不断提升的技能。 ## 帮助 Claude 更好地帮助你 指导 Claude 是一种微妙的平衡。如果你过于具体，Claude 会遵照你的指示行事，即便在更适合转向时也不例外。如果你过于模糊，Claude 则往往会基于行业最佳实践做出选择和假设，而这些未必适合你的任务。 当你没有考虑到自己的未知量时，两种方式都会失败。你不知道路上何时会遇到障碍，也不知道路何时畅通无阻，但你仍然希望 Claude 能够适时偏转。 Claude 能帮助你更快地发现未知量。它能以极快的速度检索你的代码库和互联网，对于大多数话题的了解也远超你，还能从失败中更快地迭代。 这一过程中最重要的一点，是向 Claude 提供关于你出发点的上下文。例如，告诉它你目前的思考进展到哪一步；坦诚你对这个问题和代码库的熟悉程度；让它像一个思考伙伴一样与你协作。 我此前写过关于将 HTML 与 Claude 结合使用的文章，几乎在所有这些场景中，HTML 制品都是可视化和呈现内容的最佳方式。(https://x.com/trq212/status/2052809885763747935) 在这篇文章中，我详细介绍了我用来发现这些未知因素的一些模式。我并非每次都会用到每一种技术，但拥有这套技术集合是非常有用的。 # 实施前 ## 盲点扫描 开始工作时，你能做的最有用的事情之一就是了解自己的盲点。例如，如果你正在代码库的一个新区域编写功能，或者使用 Claude 来帮助你完成不熟悉的工作（比如迭代设计），你很可能会有大量的"未知的未知"。 你可能不知道该问什么问题，不知道什么是好的结果，不知道过去已经做了哪些工作，也不知道该避开哪些坑。 为此，你可以请 Claude 帮助你找出"未知的未知"并向你解释它们。我喜欢直接使用"盲点扫描"和"未知的未知"这两个词。向它说明你是谁以及你了解什么，通常对此很重要。 示例提示词： - "我正在添加一个新的身份验证提供商，但对这个代码库中的身份验证模块一无所知。你能做一次盲点扫描，帮我找出相关的未知盲点，让我能更好地向你提问吗？" - "我不知道什么是调色，但我需要给这段视频调色。你能帮我理解关于调色的未知盲点，让我能更好地提问吗？" ## 头脑风暴与原型 当我在一个存在大量"已知的未知知识"的领域工作时——涉及到那些只有亲眼看到才知道如何定义的标准——我喜欢请 Claude 和我一起头脑风暴并制作原型。 在原型阶段早期识别并明确"已知的未知知识"极具价值，因为在实施阶段才发现它们可能（相对而言）代价高昂。功能或规格上的细微改动可能导致代码实现截然不同，而且让你的智能体回滚之前的改动也会更加困难。 例如，你可能只是想看看在某个框架中添加一个按钮后的视觉效果，而不必去配置后端路由或在前端维护额外的状态。 视觉设计对我来说就是这样——很难用语言表达，但一眼看到就知道自己想要什么。在这些情况下，我会请 Claude 对一个产出物提出几种不同的设计方案。 我几乎每次编码会话都以探索或头脑风暴阶段开始。这帮助我从一开始就带着明确意图来界定项目范围。Claude 经常能找到我本会错过的高价值方案，但有时也会只见树木不见森林。头脑风暴能防止我设定的范围过窄或过宽。 示例提示词： - "我想为这些数据做一个仪表盘，但我没什么审美，也不知道什么是可能的。给我做一个 HTML 页面，包含 4 种风格迥异的设计方向，让我来做出反应。" - "在接入任何东西之前，先用假数据做一个单独的 HTML 文件，模拟新的编辑器工具栏。我想在你动真正的应用之前，先对布局做出判断。" - "这是我的大致问题：用户在引导流程后流失。搜索代码库，从成本最低到最雄心勃勃，头脑风暴 10 个我们可以干预的地方。我会告诉你哪些方向让我感兴趣。" ## 访谈式问询 完成充分的头脑风暴之后，我可能仍然存在一些未知因素。 在这种情况下，我会请 Claude 就任何未知因素或模糊之处来访谈我。在请 Claude 进行访谈时，尽量向它提供关于你问题的背景信息，以引导它的提问。以下是一些示例。 示例提示词： - "每次只问我一个问题，内容关于任何不明确的地方，优先问那些我的回答会影响架构设计的问题。" ## 参考资料 有时候你无法详细描述你想要什么。例如，你可能没有合适的语言来表达，或者事情太复杂，需要花相当长的时间才能说清楚。 在这种情况下，最好的答案是提供参考资料。虽然你可以附上图表、文档或图片，但最好的参考资料毫无疑问是源代码。 如果你有一个以某种方式实现了某些功能的库，或者你非常喜欢某个设计组件，只需将 Fable 指向该文件夹，告诉它要找什么，即使是用不同的语言编写的也没关系。 Claude Design 的工作方式也是如此。你不必手动提交文件（当然你也可以这样做）。你可以将它指向你喜欢的某个网站上的模块，它读取的是底层代码，而不仅仅是截图。这能提供关于标记、结构以及组件实际构建方式的更丰富的细节。 示例提示词： - 这个位于 vendor/rate-limiter 的 Rust crate 实现了我想要的确切退避行为。读取它，并在我们的 TypeScript API 客户端中用相同的语义重新实现。 ## 实施计划 当我认为自己准备好开始实施时，我倾向于请 Claude 为我整理一份实施计划供我审阅，重点关注最可能发生变化的部分，例如审查数据模型、类型接口或用户体验流程。这样可以让 Claude 将我实际可能需要修改的地方呈现出来。 示例提示词： - "用 HTML 写一份实施计划，但将我最可能调整的决策放在最前面：数据模型变更、新的类型接口，以及任何面向用户的内容。把那些机械性的重构埋到最后，那部分我信任你。" ## 实施过程中 ## 实施说明 一旦我对计划感到满意，我会开启一个新会话，并将所有产出物传入提示词。例如，我可能会传入一个规格文件和一个原型，请 Agent 来实施它。 但事实是，无论你做了多少规划，总有一些未知的未知潜伏在那里。Agent 在工作过程中可能会发现，由于在代码中遇到了某个边界情况，需要采取不同的处理方式。 我会请 Claude Code 维护一个临时的"implementation-notes.md"（或 .html）文件，用于记录它所做的决策，以便我们从下一次尝试中学习。(https://www.google.com/url?q=http://implementation-notes.md&sa=D&source=editors&ust=1783101769359369&usg=AOvVaw1Iqvg51JpzkrkRtHHIjyOL) 示例提示词： - "维护一个 implementation-notes.md 文件。如果你遇到边界情况，被迫偏离计划，请选择保守方案，将其记录在'偏差'部分，然后继续。" (https://www.google.com/url?q=http://implementation-notes.md&sa=D&source=editors&ust=1783101769359896&usg=AOvVaw1wFqbnqbAuO_GYnGk8_1bh) # 实施后 ## 推介材料与说明文档 发布某个东西最重要的环节之一，就是获得认可和批准。在最终文档中构建推介材料和说明文档有助于： - 当审阅者和你最初一样面对相同的未知信息时，加速他们的理解 - 当专家希望看到你已经考虑到他们预期会出现的未知因素和常见故障点时，加速审批流程 示例提示词： - "将原型、规格文档和实施说明打包成一份文档，让我可以直接丢到 Slack 上获取认可。以演示 GIF 开头。" ## 测验 在漫长的工作会话之后，Claude 可能已经完成了比我意识到的多得多的事情。阅读代码差异只能让我粗浅地了解发生了什么，因为大部分行为将取决于现有的代码路径。 在提供大量上下文之后，让 Claude 考我这次更改的相关知识，有助于我理解发生了什么。只有在完美通过测验之后，我才会合并代码。 示例提示： - "我想确保自己理解这次变更中发生的一切。给我生成一份 HTML 报告，让我阅读并理解其中的变更内容、背景信息、直觉解释、所做的事情等，并在底部附上一个关于这些变更的测验，我必须通过它。" ## 这一切如何汇聚在一起：Fable 的发布 Fable 的发布视频完全由 Claude Code 剪辑完成。这对我来说是一个全新的领域，我绝不是什么专家。（https://www.google.com/url?q=https://x.com/ClaudeDevs/status/2064399512664526853&sa=D&source=editors&ust=1783101769363678&usg=AOvVaw1MyZd5YMjjShztWHzo8N9u） 所以我从自己已知的部分入手。我知道 Claude 可以使用代码来剪辑视频和进行转录，但我不确定其准确性是否足够高。于是我请 Claude 向我解释 Whisper 这类转录工具的工作原理，以及是否能够使用 ffmpeg 精确剪掉诸如"嗯"或长时间停顿之类的内容。 我希望 Claude 能创建一个与我说话节奏同步的 UI，但不确定它是否能够做到，于是我让 Claude 使用 Remotion 和转录内容制作一个原型视频，以验证这个方案是否可行。 最后，视频本身看起来有些暗淡，我知道这是调色的结果，但我并不真正了解调色是什么。我的第一次尝试是让 Claude 做几个变体供我挑选，但我意识到在调色方面我根本不知道"好看"是什么样子。于是，我转而请 Claude 教我调色相关知识，以发现自己的未知盲区。 你可以在这里观看更深入的讲解。（https://x.com/trq212/status/2064826394589442448/video/1） ## 匹配地图与领土 模型越来越强大，配合正确的方法，你能实现的就越来越多。当一个长周期任务返回错误结果时，很可能是因为你需要花更多时间来界定你的未知项，或者创建一个允许 Claude 在其中灵活发挥的实施计划。 每一次讲解、头脑风暴、访谈、原型和参考资料，都是在问题变得昂贵之前，以低成本发现你所不知道的事情的方式。 所以，从请 Claude 帮你发现你的未知项开始，开启你的下一个项目吧。
