提示词基础
你没写清的地方，模型一定会自己补一个。所以效果不好时，第一个该问的不是它行不行，而是你哪一句没说。
这一栏讲怎么把 AI 用起来，从你最常做的那件事开始：把一个活交给它，拿回能用的结果。这件事的成败，大半在你开口之前就定了——提示词是需求文档，不是咒语；你没写清的地方，它一定会自己补一个。所以效果不好的时候，第一个该问的不是「它行不行」，而是「我哪一句没说」。
读完你能回答：
- 输出不对时，按什么顺序回查自己漏了什么，补的时候先动哪一处？
- 为什么抄来的「万能提示词」到你手里就不灵，补上条件它又灵了？
- 哪些加词其实一点用都没有，什么时候才轮到换模型？
效果不对，先回查自己
这是本篇最想让你带走的姿态。看到输出不对，人的第一反应是「模型不行」，接着换模型、换工具、往上叠形容词——这些动作全都在错的方向上使劲。
正确的第一反应只有一句：它在哪里自作主张了？那个地方我是不是没说？输出里的每一处「不对」，几乎都能对应到需求文档里的一处空白。它没有违背你，它只是在你没写的那一行填了自己的答案。
这个姿态之所以值得反复强调，是因为它可操作：换模型是在赌，回查自己是在修。
回查按下面的顺序走，从最容易漏的开始：
- 背景类：给谁看、什么场景、有什么前情。漏了它，产出放之四海而皆准，也因此毫无用处。
- 要求类：具体要它做出什么、分几步、按什么维度。漏了它，它挑最常见的那种解释。
- 限制类：不许做什么、只能用什么材料、不确定时怎么办。漏了它，它会自由发挥，还会编。
- 验收类：输出几条、多长、什么格式、要不要编号。漏了它，每次结构都不一样，程序接不住。
这四类就是四个部件，单独一篇展开。这里你只需要记住顺序：先查自己漏了什么，再考虑换别的东西。
找到空白之后，补齐的动作有四步
如果手上已经有一段效果不理想的提示词，按下面的顺序补，比重写一遍省力。
- 把脑子里的「当然」找出来。落笔时你心里默认着「当然是给 B 端客户看的」，默认「当然是中文」，也默认「当然不能提竞品」——而这些「当然」，模型一条都读不到。把它们逐条写成明文。
- 加一句「不要什么」。只给正面要求常常不够用；把禁区列出来，收窄速度更快。明说不要感叹号、不要营销腔、不要编造数据——一条禁令差不多能顶三条正面要求。
- 给一个例子。你只要能拿出一个「照这样写就对了」的样本，它胜过你写三段形容词。给例子这件事单独有一篇。
- 说清楚什么算做完。要求「输出三条、每条不超过 20 字、用编号列出」，和只写一句「简明扼要地总结一下」，效果差得很远。
这四步里，前两步几乎总是回报最大的——因为默认假设和禁区，恰好是最不容易被自己看见的两处空白。
每补一个条件，可能范围就少一片
回到它猜下一个字的机制：每一步都在算「接下来最可能的是什么词」。注意，这里的「最可能」有一个比较对象，那就是它眼前已经拿到的全部内容。
所以一句「写篇文案」递过去，等于把可能性开到最大——受众是谁？卖什么？写多长？什么调性？全是空白。可它不能停在原地，必须接着往下写，那就只能挑训练语料里最常见的那种写法。你拿到的那段东西于是四平八稳、挑不出错，也没人会被它打动。
条件补得越多，它能落脚的地方就越少。加上「给已经用了三个月的老用户看」，面向新用户的那些写法就全被排除了；再加上「一百字以内、不许用感叹号」，剩下的空间已经跟你要的八九不离十。这种收窄是看得见的：同一件事，描述得越具体，两次跑出来的差别就越小。两家厂商的官方提示指南其实都在讲这一点——具体、可验证、条件说透。openai-promptanthropic-prompt
反过来看，收窄不了任何范围的话，效果就是零。「请认真思考」也好，「这对我很重要」也好，都没有带来半点新信息，模型没有任何理由因此改变输出。真正管用的是具体条件：把格式写出来、把例子贴上、把不许出现的词列清楚。
换句话说，提示词工程不是去找某个神奇句式，而是把该说的都说清楚——这也是为什么别人的「万能提示词」抄过来不好用：那段话收窄的是他们的范围，不是你的。
把它当成一个聪明的新同事
有个类比很好用：把模型当成刚入职的同事——活干得漂亮，对你们公司却一无所知。
他聪明，哪个领域都接得住话。可你们卖什么、用户在哪儿、上一版方案为什么被打回、写东西习惯用什么口吻，他一概不知。交代任务时你没提的那些事，他只能自己填，填错了也不会回头找你确认。
你会怎么给这样一个新同事派活？交付对象是谁、要拿到什么结果、红线在哪里、做到什么程度算完成——这四件事你一定会说清。提示词要交代的，也正是这四件。
这个类比还能解释一个常见困惑：为什么别人分享的「万能提示词」到你手上就不灵。因为那段文字里装满了他们的业务背景和约束条件，跟你的对不上。结构可以照搬，内容搬不过来。
三个误解，同一处根子
它们背后是同一个假设：你没说的地方，它会替你补对。
误解一：存在一句咒语。网上流传的「秘籍」大多是这个形态。判断方法很简单：把这句话删掉，输出会变吗？不会变，它就没有作用。唯一有点例外的是让它先推演再作答，那确实有用，但原因不是咒语，是多写就是多算。
误解二：写得越长越好。不对。起作用的是信息密度，字数本身没有价值——指望堆字数把没说的补上，和指望一句咒语是同一种偷懒：该空着的地方照样空着。不相干的背景堆得越多，关键指令被冲得越淡，成本还跟着涨。更糟的是篇幅一长，最关键的那句话很容易沉到中段去，而中段正是注意力最容易松掉的地方。
误解三：它理解了我的意思。它没有「理解」这回事，做的是统计意义上的延续。平时看不出这两者的差别，一旦出错就非常刺眼：换成人，任务描述有歧义时会先来问一句；它不会。它会自己挑一种解释，然后理直气壮地做到底。于是歧义带来的损失，账全记在你头上——这也正是开头那个「先回查自己」的由来。
换模型救不了的那部分
到这里，这篇讲的其实只有一件事：输出里每一处让你不满意的地方，先去需求文档里找对应的那片空白。多数「模型不行」的评价，走完前面那四步就消失了。
剩下的那些，不靠继续加词，靠的是有尺子地改：一次只动一处，用同一批样例比出它到底变好还是变坏——提示词怎么迭代讲的就是这套方法。
至于什么时候才轮到换模型、加检索、上微调，那是另一个判断。四个部件都补齐了、样例也跑过几轮，失败仍然集中在同一类输入上，才说明问题不在你怎么说；在那之前换模型，通常只是让同一类错误换一种写法出现。