给 AI 交代了一长串要求，结果还是差点意思；收集了不少提示词和技能，真正用起来又总觉得不顺手。到底是模型能力不够，还是我们的用法也需要调整？
最近读到 Anthropic 两位工程师的三篇文章，刚好从三个角度谈到了这个问题。先看这张总结图，再分别展开。
根据参考图重绘，图中篇名为中文概括。前两篇来自 Thariq Shihipar，第三篇来自 Felix Rieseberg，原文链接见文末。
一、提问技巧：找到你的未知
Thariq 提到了一个比喻：交给 AI 的提示词、背景资料，是一张地图；实际需要完成的工作，才是它要走进去的真实世界。地图没有标注的地方，AI 就得根据自己的理解做判断，任务越复杂，这样的地方也越多。找到你的未知原文
所以，需求写得长，不代表我们真的把事情想周全了。比如让 AI 帮忙修一张照片，懂摄影的人可以说出曝光、白平衡、肤色应该怎么调；不懂的人大概率只能说“这张有点灰，帮我调高级一点”。这里的“高级”，可能看到之后就能判断喜不喜欢，但开口之前，确实不知道该怎么描述。更麻烦的是，有些影响观感的因素，我们压根就没注意到。
Thariq 把这些情况分为四类：
- 已知的已知：明确知道照片要发给谁、用在哪里。
- 已知的未知：知道自己不懂调色，需要先了解。
- 未知的已知：心里有偏好，但看到具体版本才想起该怎么描述。
- 未知的未知：连哪些因素会影响效果，都还没意识到。
他建议通过盲点检查、访谈、原型等方式找出遗漏，而且在执行过程中也继续澄清新问题。
放到刚才修图的场景里，可以先让 AI 解释这张图有哪些问题、有哪些调整方向，顺便把不懂的词讲清楚；如果有些偏好实在说不出来，就让它做几个差异明显的版本，看完再选。拿着具体的东西交流，总比反复说“再高级一点”强。
我觉得这个思路最有用的地方，是让人不用等到能写出一份完美的要求，才开始使用 AI。我们找设计师、编辑合作，本来也需要来回沟通，为什么到了 AI 这里，就总期待一句话把它安排明白呢？它问问题、给选项的过程，也可以帮助我们把自己的想法理顺。
不过，共同讨论出来的答案也得检查。修图就看实际导出的成品，查资料就回到原始来源核对。聊得顺畅和事情做对，终究是两回事。
二、上下文工程：给规则做减法
“上下文”可以理解为 AI 干活时拿到的整套材料，除了当前这句话，还包括系统提示词、长期说明、记忆、Skill（可复用的任务指南）等。
Thariq 在第二篇文章里提到，Anthropic 团队为更先进的模型，删掉了 Claude Code 超过 80% 的系统提示词，在他们自己的编码评测中，没有观察到可测量的损失。原因之一是，有些限制是过去模型能力不足时加上的，现在却可能妨碍它发挥；来自不同地方的指令，也可能互相冲突。上下文工程原文
这有点像带新人。刚入职时，把流程交代得细一点很正常。但人家已经能独立负责事情了，还要求他照着入职第一天的小抄干活，能力也就只能表现到那份小抄允许的程度。人可能会有意见，AI 则可能认真地把一堆没必要的步骤走完，再礼貌地告诉你，任务已完成。
尤其有些提示词是从不同地方拼起来的，每一段单独看都很有道理，放到一起却未必合适。一会儿要求尽可能简洁，一会儿又要求任何观点必须充分展开；既要自然口语化，又要每节都有总结。最后的文章句句像结论，读着却累，这也未必全是模型的问题。
原文建议让上下文保持轻量，需要时再加载相关信息。不过，“删掉八成”这个数字不能直接照抄。他们有具体的模型和评测作为前提，而你那些只有自己知道的特殊要求，仍然得交代。文章写给谁看、哪些内容不适合公开，这些事情不会因为模型变聪明，就自动出现在它脑子里。
真要动手清理，可以先找一条过去为了解决某次错误加上的要求，去掉它，用几件有代表性的任务做个对照：原来的问题还会不会出现，有没有少一些无用的步骤，结果是否更好。这样至少知道自己删掉的是什么，不至于把“精简上下文”又变成一次凭感觉的折腾。
三、心智的野心：目标可以再大一点
第三篇把问题往前推了一步：我们想让 AI 做的事情，会不会从一开始就小了？
Felix 把使用 AI 的野心分为速度、高度、深度和广度。速度很好理解，同样的事情做得更快，也是最容易想到的一种用法。其他三个方向，则值得多琢磨一下。更有野心原文
高度，是再往上想一层，自己最终要什么。 比如把文档转成十页 PPT，这是一个明确的任务。但这场演示究竟是为了介绍事情，还是为了让会上做出一个决定？如果是后者，那更值得先做的，也许是从材料里找出需要讨论的分歧、缺失的证据。至于最后到底做几页，可以往后放一放。
深度，是把专业的方法真正用上。 让 AI 总结一本书，和让它帮助自己理解一本书，需要做的工作就不一样。围绕核心判断找反例、换一个立场讨论、出几个必须理解内容才能回答的问题，再把答不上的部分带回原文看，这就比收下一份摘要多走了几步。
广度，是尝试自己不熟悉的领域和工具。 做演示时，除了让它整理文字，也可以尝试用图表解释数据，用动画展示过程，或者做一个能现场操作的小模型。有些想法过去因为自己不会、找人做又麻烦，刚想到就放弃了。现在可以重新评估一下，至少先看看能做成什么样。
上面这些是我顺着文章想到的例子。Felix 还特别提醒，专业的口吻并不等于专业的方法，需要相应的数据、工具和外部验证。
这点很有必要。给 AI 安排一个“二十年经验的专家”身份确实容易，但如果分析行业时没有查过真实数据，点评设计时连实际效果都没看过，挂什么头衔也没用。目标可以放大，解决问题需要的材料和检查手段也得跟上。
最后
这三个观点里，我最认同的是：别太早给自己，也给工具下结论。暂时说不清要求，可以先聊；以前留下来的规矩，可以重新检查；过去觉得做不了的事情，也可以拿出来试试。
做完之后，再看看哪些地方依然没想清楚，哪些限制确实有必要。图里的“完整闭环”，放到实际使用中，大概就是这样不断尝试、修正的过程。模型当然还有很多毛病，但自己的用法是否合适，也值得一起检查。
参考文章：
- Thariq Shihipar：A field guide to Claude Fable 5: Finding your unknowns
- Thariq Shihipar：The new rules of context engineering for Claude 5 generation models
- Felix Rieseberg：How to be more ambitious: A tutorial for humans with models
