AI总听不懂我的话！提示词要怎样写？

AI总听不懂我的话！提示词要怎样写？

Hi，你好，我是司沐。

从大模型问世起，提示词工程这个概念就再也不会消亡了。不过，你有想过，从2023年到现在，出现了哪些提示词技术，消亡了哪些提示词技术，为什么会有这样的变化吗？

本文就是想以一个AI时代原住民的身份，简单聊聊，为什么以前流传的一些"奇技淫巧"现在没用了，为什么现在的写法反而变简单了，现在的人到底在琢磨什么，以及将来的提示词技术会怎么变化。

本文主要会按年份脉络讲，是因为这样可以让这条脉络看起来清楚，但真实情况肯定没有"年初大家还这么想，年底集体换了套路"这么整齐。同一年里头，往往能拆出好几个具体的时间点——某个新模型突然发布了、某家公司发了一篇论文或者官方博客、某种说法一夜之间在社群里传开了，真正推着大家换写法的，是这一个一个具体的节点，而不是年份本身。本文先带你看一个粗线条的轮廓，等以后有机会，我们再挑几个关键节点，拆得更细一些。

1. 2023 年：一个还在摸黑走路的年代

ChatGPT 刚火起来的那阵子，没有人真正懂该怎么跟它说话最管用。大家能做的，就是不断去试，试出一句好用的话，就当宝贝一样口口相传。这段时间，与其说是在搞工程，不如说更像是在念咒语——你不一定懂为什么这句话管用，但试出来确实管用，那就先用着。

这里面比较有代表性的几个做法：

先给它派个角色。比如在提问前面加一句"你是一位资深律师"，或者"你是一位诺贝尔物理学奖得主"。这个做法叫角色扮演（Role Prompting），道理也讲得通：模型在训练时读过无数种身份的人说话的样子，你先把身份定下来，它接下来的用词、语气、专业程度就会更贴近这个身份，而不是漫无目的地东拉西扯。这就跟演员进组之前先明确自己演的是什么角色是一个道理，人设定下来了，演起来才不会跑偏。

这条到 2025 年就打了折扣。那时候，各家模型都在训练的后半程下了大功夫，就算什么身份都不给，模型也早就习惯了以一个认真、专业的助手口吻来作答，不用再靠身份设定去激发能力。这时候安排身份的作用就变了：它不再负责把回答从"能用"拉到"专业"，而是单纯用来定风格——你希望它说话像个律师，还是像个脱口秀演员，纯粹是一个人设选择题，跟回答质量已经没什么关系了。

图 1：左侧表示早期模型，右侧表示模型能力内化角色特征后的情况；两侧比较的是角色提示带来的主要收益变化。

把问题分块写清楚。也是这段时间，不少人发现，与其把背景、要求、目标全揉在一整段话里，不如用 Markdown 的写法分成几块，比如单独写一段"背景"，再单独写一段"任务"“目标”“思路”。这么做的好处，细想下来其实有三层。第一层最直接：内容分了块，模型不用再自己去猜哪句话是背景、哪句话是要求，原本容易被扯散的注意力，被这几个小标题重新收拢了回来，该参考哪部分的时候，就去看哪部分。第二层其实是说给我们自己听的：真要把背景、任务、目标一块块列清楚，你自己得先把这件事从头到尾想明白，写这几块的过程，其实是倒逼你把问题本身想透，很多时候几块写完，答案在你自己脑子里已经成型了一半。第三层藏得深一些，跟模型训练时读过的数据有关：模型见过的大量问答数据里，那些被认真回答、回答质量也高的问题，往往本身就写得有条有理、逻辑清楚；随口一问、语焉不详的问题，得到的回答通常也比较敷衍。这种"问题写得越用心，回答质量越高"的对应关系，被模型在训练时悄悄记了下来，所以见到一个结构清楚的问题，它自己也会更认真地对待，而不是随便应付。这种写法后来被叫做结构化提示（Structured Prompting）。

让它把过程写出来，而不是直接给答案。当时流传最广的一句咒语是"Let’s think step by step"，翻译过来就是"我们一步一步来想"。你还别说，这句话是真的管用。还记得吗，大模型的每一步预测，靠的都是把前面出现过的所有内容重新看一遍，再猜下一个字，而这份"前面出现过的所有内容"，就是它的上下文（Context）。如果你让它直接吐答案，那它这时候的上下文里，就只有题目本身那几句话，可参考的信息很单薄，一步走错，后面就跟着全错。但如果你先让它把解题过程一步步写出来，那么它在算到第五步的时候，前面一到四步的推导过程，全都会被塞进它当下的上下文里，可以拿来参照的信息一下子丰富了好多倍。上下文越完整、越具体，后面每一步能借力的东西就越多，答案自然也就越准。这种做法后来有个专门的名字，叫思维链（Chain of Thought），说的就是让模型把推理过程一步步展开，而不是憋一个大招直接甩答案。

这条到 2025 年也不管用了，甚至有点拖后腿。那一年出现了一批推理模型（后面会细讲），它们本来就会自己在后台一步步推敲，相当于自己已经在草稿纸上把过程写清楚了。你再喊一句"要一步步想"，等于是让它把已经想好的过程再复述一遍，甚至刻意去凑你要的格式，反而占用了它原本用来推敲的精力。

图 2：显式思维链对能力有限的模型可能有帮助，但对已经具备内部推理能力的推理模型，额外要求可能只是重复劳动。

给几个例子照着学。光说"帮我写一段种草文案"，模型不知道你想要的调性。但如果你先给它两三个你满意的例子，它就能顺着例子的调子往下写。这个做法后来被叫做小样本示范（Few-shot），说白了就是"照葫芦画瓢"，比干巴巴地下命令好使得多。

这条到 2025 年同样打了折扣。面对推理模型，例子给多了反而容易帮倒忙：模型会把你给的例子当成一种"该怎么想"的固定模板去模仿，束缚住了它自己更擅长的推理方式。所以这时候更好的做法是先不给例子，把任务直接说清楚，等它答得不理想，再考虑补一两个例子，而不是一上来就摆一堆。

到了 2026 年，"例子该精不该多"这条经验又被后来的实验坐实了一层，而且比当初想的还要严重。有团队实测过，一个任务原本零样本就能答对九成多，可给到八个例子之后，准确率断崖式地跌到了三成，跌得比预想中猛得多。这种"例子超过某个数量反而拖累效果"的现象，后来被叫作过度提示（Over-prompting）。所以例子这件事，从来都不是给得越多越保险，几个贴切的例子，永远好过一沓凑数的。

图 3：示范例子并非越多越好；超过最佳范围后，过度模仿例子会束缚模型并显著降低准确率。

还有一批做法，现在看更像是江湖传言。比如给 AI 一点小费的许诺，或者用威胁的口气吓唬它，据说这样它会更认真地回答。这类说法当时传得很广，甚至连一些业内名人都公开说自己验证过有效。但后来有一篇论文《I’ll pay you or I’ll kill you – but will you care?》专门做了大规模测试，发现这套路对整体表现基本没什么用，个别题目上涨了，另一些题目上反而掉了，说到底就是运气成分，算不上一个真正可靠的方法。这也提醒我们，这个领域一开始确实带着不少"民间偏方"的味道，能不能真管用，得靠实打实测出来，而不是听谁说得响亮。

那个阶段的核心特点，可以用一句话概括：模型还不太聪明，也不太会主动猜你的心思，所以人只能靠外部的小技巧，一点点把它的水平往上抬。

术语速查：

2. 2024 年：从碰运气，到讲章法

到了 2024 年，模型的理解能力明显上去了一截，大家写提示词的方式也慢慢从"瞎试"变成了"讲究"。这一年，各家公司陆续把自己内部总结的经验公开出来，尤其是 Anthropic，也就是 Claude 背后的公司，写了好几份很详细的官方指南，比如《6 Techniques for Effective Prompt Engineering》。这些指南里，有几条思路特别值得说一说。

把话说具体，比把话说漂亮更重要。之前很多人喜欢用一些模糊的形容词，比如让 AI “写得简洁一点”。但什么算简洁？三句话算简洁，还是三十个字算简洁？模型也拿不准。Anthropic 给的建议很实在：与其说"简洁一点"，不如直接说"控制在两到三句话以内"。目标越具体，模型才越知道该往哪个方向使劲。

别说"不要做 A"，要说清楚该做 B。很多人写提示词的时候，习惯先列一堆"不要"：不要用网络用语、不要超过三百字、不要跑题。这类禁止句模型倒也不是看不懂，但你只告诉它不能做什么，它还得自己反过来猜一遍，剩下能做的范围到底有多大，猜得不准，照样容易踩线。与其列一串"不要"，不如直接把该做的事说清楚——把"不要写得啰嗦"换成"每段控制在三句话以内"，方向摆在明面上，模型执行起来自然更准。这个坑后来被叫做负面提示（Negative Prompting），意思就是只说不能做什么、不说该做什么的写法，尽量少用。

这条经验在 2026 年被后来的研究讲得更透了，专门取了个挺形象的名字，叫粉红大象效应——就像有人让你"别去想一头粉红色的大象"，你脑子里反而立刻冒出一头粉红色的大象。模型也有类似的毛病：为了处理"不要提到 A"这句话，它得先在自己当下的注意力里把 A 摆出来、过一遍，结果反而让 A 更容易在回答里冒出来，这个问题在会自己深度思考的推理模型身上还更明显。所以这条经验没有失效，反而是被后来的研究进一步验证、讲得更清楚了。

图 4：左侧示意负面提示可能强化被禁止概念，右侧示意明确替代行为通常更容易得到稳定结果。

长内容要分清楚哪块是哪块。这个思路其实和前面说的分块写清楚是一脉相承的，只不过这一年多了一种更严谨的分块方式。如果你的提示词里既有背景资料，又有具体要求，还夹杂着例子，光靠几个 Markdown 小标题有时候还是不够，模型偶尔还是会分不清这句话到底是背景介绍还是任务要求，尤其是当资料本身很长的时候。这时候用 XML 标签（一对尖括号组成的记号）把不同部分严丝合缝地框起来，就更管用，比如把资料部分用<资料>和</资料>包起来，把要求部分单独放在别的位置。这就跟收拾快递包裹一个道理，东西分门别类打包、贴好标签，对方拆开的时候才不会看花眼。这个做法后来也被验证是对 Claude 系列模型格外管用的一招，因为它训练的时候就见过大量这种带标签的文本。

不过这条到了 2026 年也被收窄了适用范围。如果提示词本来就短、逻辑也简单，加不加标签模型理解得都一样准，硬套标签反而白白多花 token。真正用得上标签的场景，收窄成了内容比较长（大致超过五百字这个量级）、里面分好几个逻辑段落，或者输入的内容本身可能被模型误认成指令这几种情况。而且这条经验也开始分模型了：Claude 系列还是更吃 XML 标签这一套；OpenAI 这边官方更推荐改用 Markdown 小标题分块，效果差不多，但更省 token。说到底就是同一个道理：手段要配得上问题的复杂程度，问题本身不复杂，就不用非上重装备。

该给例子的时候给，但别乱给。例子确实好用，但如果给的例子风格不统一，或者跟你真正想要的效果对不上，反而会把模型带偏。所以这个阶段大家更强调例子的质量，而不是数量，一两个贴切的例子，往往好过五六个东拼西凑的。

语气和格式，模型会模仿你。如果你希望它写得正式，那你提问的时候也用比较正式的措辞；如果你想要它写得轻松随意，你自己问话的语气也放轻松。模型会不自觉地照着你说话的调子来回应，这也是为什么同一个问题，换一种问法，出来的文风都会不一样。

把不变的部分放前面，会变的部分放后面。也是这一年，Anthropic 和 OpenAI 先后上线了一个叫提示词缓存（Prompt Caching）的功能：先是 Anthropic 在 8 月宣布，紧接着 OpenAI 在 10 月跟进。如果这次请求里，开头一大段跟上次请求一字不差，比如固定的系统设定、固定的背景资料，服务器就能直接照搬上次已经算过的结果，不用重新算一遍，请求既快了，花的钱也少了。但这个功能有一个前提：一字不差的那部分，必须老老实实待在提示词最前面，只要中间插进一点点变化，后面能省的那部分也就跟着作废了。所以从这一年开始，写提示词多了一条新的讲究：把不常变的规则、背景放在最前面，把每次都不一样的具体问题放在最后面。这个想法其实也是再往后要讲的上下文工程的一个朴素雏形——早在真正开始琢磨"该怎么打理 AI 眼前那一整套信息"之前，大家已经先在琢磨"提示词里到底哪部分该稳定不变、哪部分该灵活变化"了。

图 5：提示词缓存只复用从开头起连续且一字不差的前缀；前缀一旦被变化内容打断，后面的固定内容也不能继续命中缓存。

也是在这个阶段，大家慢慢达成了一个共识：提示词写作已经不只是"找一句管用的咒语"了，它变成了一件需要反复调整、反复对照结果来打磨的事情，跟写文章改稿子有点像，写第一版从来不是终点。

术语速查：

3. 2025 年：模型学会了自己打草稿

2025 年，一批新的模型出现了，它们有一个共同点：拿到问题以后，会先在心里自己盘算一遍，才把最终答案说出来。这种模型通常被叫做推理模型（Reasoning Model），代表性的比如 OpenAI 的 o1、o3，还有 Claude 的深度思考模式。这批模型一出现，前面标注过的那三条 2023 年老技巧——角色扮演、思维链、小样本示范——差不多都在这一年打了折扣，具体原因回头翻翻上面的批注就能看到，这里就不重复了。OpenAI 官方也直接给出了建议：对这类模型，不需要再教它怎么想，只要把问题和目标说清楚就够了，剩下的交给它自己去想。

这也带出了这个阶段一个很关键的转变：说清楚要什么，而不是替它规划该怎么想。以前对着能力有限的模型，我们习惯把解题步骤都提前写好，一步一步喂给它。但推理模型更擅长自己拆解问题，你如果把步骤框得太死，反而限制了它。这时候更好的做法，是把最终想要的结果、要满足的条件说清楚，比如明确说"给出的方案预算不能超过五百块"，然后把具体怎么算、怎么推的自由交还给模型。

图 6：面对推理模型，应明确最终结果和约束条件，把具体的分析与推理过程交还给模型。

到了 2026 年，这个思路又往前走了一步：连"该给它多少空间去想""想太久会不会耽误事"这类问题，也开始不用你手动操心了。比如 Claude 从某一代新模型开始，直接取消了手动设置思考时长的接口，改成一个叫力度（Effort）的档位，你只管把这个档位调高调低，具体想多久、怎么想，交给模型自己动态决定；OpenAI 那边则是直接建议开发者对着推理模型完全不用再写"一步步想"这类思维链提示。这跟前面说的道理一脉相承：模型自己能打理好的事情，就不再需要你手把手教了。

与此同时，同一年 OpenAI 也针对当时最新的一批模型出了一份很详细的《GPT-4.1 Prompting Guide》，核心意思是：这批模型对指令的理解已经变得非常直白，你说什么它就照做什么，不会像早期那样自己脑补你的言外之意。这既是好事也是提醒——好事是只要你说清楚，它就能做到位；提醒是如果你的话本身含糊，它也不会自动帮你圆回来，而是会照着字面意思去做，容易做出跟你预期不一样的结果。所以这份指南里反复强调的一件事，就是把每一条要求都写得明明白白，不要留模糊地带。

也是这一年，一家做 AI 智能体（Agent）产品的公司 Manus 发了一篇文章《Context Engineering for AI Agents: Lessons from Building Manus》，第一次把上下文工程（Context Engineering）这个词真正炒热了起来。他们说得很实在：AI 要是只回答一个问题，那琢磨"这句话怎么问"确实就够了。可他们做的产品要让 AI 连续干几十步活，比如自己上网查资料、写文件、跑代码，一步接一步做下去。这种情况下，光顾着开头那一句提示词根本不够看，真正决定任务能不能做成的，是每一步开始之前，AI 的上下文里到底装着哪些东西：早前查到的资料要不要留在上下文里、什么时候该被清出去、做错的那一步要不要留个痕迹提醒它别再错第二次。他们把这一整套"什么时候该让什么内容进入上下文，又该在什么时候把它清出上下文"的门道，叫作上下文工程。这跟前面说的道理是一脉相承的：模型每一步的判断都基于它当下的上下文，那么谁能把这份上下文打理得干净、及时、恰到好处，谁就能让模型发挥得更稳。

图 7：Three buckets are successive snapshots of the model’s context; the changing information composition, not the opening prompt alone, determines what the model can use at each step.

管好上下文不光是让模型发挥更稳，还有一笔实实在在的账：前面 2024 年那节说过的提示词缓存，省的就是上下文里那些反复出现、没有变化的部分。按官方公布的价目表，Anthropic 这边命中缓存的部分，只按原价的一折收费；OpenAI 那边打五折。也就是说，同一段背景资料、同一套工具说明，如果能让它老老实实待在上下文里被反复命中缓存，而不是每次都被换掉重新计算，一套流程跑下来能省下的钱相当可观。这也是为什么上下文工程不只是一个让模型表现更好的技巧，同时也是一笔要精打细算的成本账。

术语速查：

4. 2026 年（也就是现在）：给 AI 配一套工具箱

上下文工程这个思路虽然重要，但它更多是在说"该注意什么"，并没有说清楚"具体该怎么做"。如果每家公司、每个人都要自己从零摸索一套管理上下文的机制，那也太累了。于是 2025 年年底，Anthropic 在一篇叫《Equipping agents for the real world with Agent Skills》的博客里，拿出了一套具体的落地方案，叫 Skill。这套方案火起来的速度超出预期：Anthropic 干脆把它整理成一份任何公司都能照着实现的公开规范，短短几个月里，OpenAI、Google、微软这些公司的产品也陆续跟着支持了同一套 Skill 文件格式。这意味着你给一个工具写的 Skill，换到另一家公司的工具里往往也能直接拿来用，不用重写一遍。

Skill 解决的正是上面说的那个问题：与其把所有任务的操作说明一股脑全塞进上下文，不如提前把不同任务的说明整理成一份份独立的文档，放在一边。你可以把它想象成一套工具箱：每个 Skill 都配了一张小卡片，卡片上只写着这个 Skill 是干什么用的。AI 平时只需要扫一眼这些卡片，知道工具箱里都有些什么，这些卡片本身占不了上下文多少地方。真轮到要用某个 Skill 了，它才会把这份 Skill 完整的说明书读进上下文里细看。这样一来，AI 手头能用的 Skill 再多，上下文里需要一直背着的内容也不会变多，需要的时候又总能精准地把最详细的那一份说明找出来、放进上下文。你会发现，Skill 正是把上下文工程那句"该在什么时候，让什么内容进入上下文"的道理，做成了一套大家都能直接照着用的通用方案。

图 8：Skill 让大量任务知识不必常驻上下文，而是在真正需要时按需加载。

不过这里要说清楚一点：Skill 解决的，只是上下文工程里"该在什么时候，让什么内容进入上下文"这一半问题。前面 Manus 那篇文章说得很清楚，上下文工程还有另外一半，是"该在什么时候，把内容清出上下文"，这一半 Skill 并不管，得靠 AI 助手外面那一整套让它真正运转起来的运行框架来解决，这套东西现在有个专门的说法，叫 Harness（原意是套在马身上、让马能拉车的那副挽具，这里指的是让模型真正干成活的那套外围机制）。举几个例子：一段对话越聊越长，眼看就要把上下文塞满了，Harness 得知道什么时候该把前面一大截对话浓缩成一段摘要，重新开一轮干净的上下文，这个动作叫压缩（Compaction）；AI 调用工具查了一大堆资料，这些资料在刚查完那会儿有用，可再往后翻几十轮对话，多半就用不上了，Harness 也得知道该找个时机把这些过时的工具返回结果清出去，腾出地方给后面真正要用的内容；再往大了说，如果一个任务里有一步特别吃上下文，比如要翻查一整个代码库，Harness 还可以专门开一个用完即扔的子智能体（Sub-agent），让它自己在一个独立干净的上下文里把这一步做完，只把最后的结论带回来，不把翻查过程中攒下的一堆碎片塞回主线的上下文。这几件事都不是靠一份 Skill 文档能包办的，得写进 Harness 本身的运行逻辑里，让它在合适的时候自动去做。也就是说，Skill 管的是"该拿什么进来"，Harness 管的是"该把什么送走"，两者合在一起，上下文工程这件事才算被真正落了地。

图 9：Skill 负责按需加载内容进入上下文，Harness 负责压缩、清除和隔离不再需要的内容。

回头看这四年，你会发现一条挺清楚的线索：模型越来越聪明，我们要替它操心的细节反而越来越少，但我们要考虑的范围却越来越大——从一开始只想着怎么把一句话说得巧妙，到后来开始想清楚该给它的上下文里放哪些信息、该怎么把一堆资料和工具整理得井井有条。这跟带一个新人是差不多的道理：一开始你得手把手教他每一步该怎么做，等他真的成长起来了，你要操心的就变成了给他一个清楚的目标，再把他做事需要用到的资料和工具提前摆放整齐。

术语速查：

5. 技巧一直在换代，这个循环倒是没变

走完这四年你应该也发现了，没有哪一种提示词写法是能用一辈子的，它会一直跟着模型本身的进化换代。这中间其实藏着一个循环：我们这些用的人，在日常摸索出一种好用的提示词写法，某种程度上是在替模型厂商标出"模型现在还欠缺什么、得靠人从外面补一手"。厂商看到这个规律之后，往往不会满足于让全世界的用户每次都手动补这一手，而是想办法直接把这种能力练进模型本身。等这件事做成了，原来那句好用的提示词，也就跟着一起退休了。

图 10：循环表达的是能力被模型吸收后，用户仍会继续发现新的缺口并形成新的外部补偿；不表示严格按年份整齐发生。

前面标注过的思维链和角色扮演，正好都是这个循环的例子：思维链被厂商直接练成了推理模型自带的思考块（Thinking Block），角色扮演的效果被后训练悄悄内化进了模型的默认行为。两条老技巧都还在，只是不再需要我们从外面手动补了。

所以，其实我们摸索出的每一个好用的提示词技巧，都是在给下一代模型的训练提需求；模型每往前走一代，就会把上一代最常见的那几个技巧悄悄吸收进去，然后把提示词这件事的门槛，往后再推一格。

不过这里要提醒一句：前面按年份划出来的这几套规则，说的都是每一年最顶尖的那批模型，也就是大家常说的前沿模型。如果你手头用的是一个能力比较弱的模型，比如某些小体量、专门为省钱和速度做过裁剪（Pruning）的模型，它的水平可能压根还没走到"前沿模型"那一年的台阶上。这种时候，一两年前那些看着有点过时的老办法往往还是好使的，该用照样用，不用觉得掉队。判断该用哪一年的招数，标准不是日历翻到了哪一年，而是你手头这个模型，实际站在哪个能力台阶上。

图 11：选择提示词技巧的标准是模型当前的实际能力，而不是日历上的年份；能力较弱的模型仍可能适用较早的技巧。

而且这份打磨不会在某一年戛然而止，就算是前面 2024、2025 年才总结出来的经验，一样在被不断地重新审视。前面提到的负面提示、XML 标签、给例子这几条就是现成的例子：负面提示没有过时，反而被后来的研究讲得更透彻了；XML 标签也没有失效，只是适用的场合被收窄了，简单的提示词已经用不上它；给例子这条更是直接被坐实成一条更严格的规矩，例子一旦超了量，效果掉得比最初想象的还要猛。所以说到底，这几年唯一没变的一件事，就是这些经验本身还在持续被打磨、被重新验证这个过程。

术语速查：

6. 有一条规则，大概率不会变：乔哈里视窗

前面讲了一大堆会过时的技巧，那有没有什么是不太会变的？还真有一个，只不过它不是哪家公司提出来的，而是心理学里一个很老的概念，叫乔哈里视窗（Johari Window）。

它是 1955 年两位心理学家提出来的，本来是用来分析人和人之间沟通的。思路很简单：把两个人之间的信息，按"自己知不知道"和"对方知不知道"，分成四块。这四块拿到人和 AI 的沟通上，套得出奇地合适：

• 双方都知道的，简单说。这是最省心的一块。你想问的东西，AI 也早就见过、答得上来，这种时候不用绕弯子，直接把话简单说清楚就行。
• AI 知道、你不知道的，提问题。这一块正好反过来用。你自己也说不清具体要什么、或者压根不知道有没有更好的思路，这时候最该干的事，是多问 AI 几个问题，把它知道、你不知道的东西给"套"出来。
• 你知道、AI 不知道的，喂模式。这一块最容易被人忽略。你的作业要求、你项目的具体背景、你脑子里那些没写出来的想法，AI 从来没见过、也猜不到。这种时候，不管模型多聪明，都得靠你主动把这些信息喂给它，它才有办法接得住。这其实就是我们前面反复提到的结构化提示、上下文工程在干的事——把这一块"你知道、AI 不知道"的信息，想办法喂完整，变成"双方都知道"。
• 双方都不知道的，开放聊。这一块最有意思，谁都没有现成答案，这时候不如把它当成一次开放式的聊天，跟 AI 一起头脑风暴，说不定能碰撞出点新东西。

图 12：四个区域分别表示：双方都知道时“简单说”；AI知道、你不知道时“提问题”；你知道、AI不知道时“喂模式”；双方都不知道时“开放聊”。

你会发现，这四块和模型是 2023 年的还是 2026 年的，其实没什么关系。不管模型进化到多聪明，你项目里的具体背景，它还是不会自己知道，还是得你亲手喂进去；你自己也说不清的模糊想法，还是得靠多问几句去把思路理清楚。

表面的技巧换了一茬又一茬，但先想清楚该往哪个方向努力，再决定要问、要喂、还是要一起聊，这条底层逻辑，大概率会一直管用下去。

术语速查：