把任务说清楚

你打出去的那句话，只是模型看到的整份材料的最后一行。

一、模型看到的远不止一句话

我们习惯把发给模型的输入叫作prompt（提示词）。从语言模型续写文本的角度看，前面的文字既是开头，也控制着后面生成什么；进入聊天界面以后，它更容易被理解成对话框里的一条要求。

但对一个智能体来说，指令分散在很多地方。运行它的那层外壳会提供系统指令与工具说明；项目文件夹里的配置文件可能约定项目规则；加载的技能会给出特定任务的做法；你还会不断补充目标。代码、文件、历史消息和工具返回的结果也一起进入上下文。模型下一步做什么，受到这整堆材料的影响。只盯着最后那一句话去解释它的行为，会漏掉大半原因。

flowchart TB
  U["你输入的任务与目标"] --> CTX["整份上下文"]
  H["外壳的系统指令与工具说明"] --> CTX
  A["项目文件夹里的配置文件"] --> CTX
  S["技能文件里的做法"] --> CTX
  T["工具返回的文件与命令输出"] --> CTX
  CTX --> M["模型决定下一步做什么"]

这里还要区分指令与材料。工具返回的一段文章可能是你要分析的对象，它出现在上下文里，却没有因此获得给智能体下命令的资格。来源、作用范围和优先级，都属于组织上下文时要考虑的事情。

所以「提示词工程」逐渐扩展成了上下文工程（Context Engineering）：关心模型在做决定时能看到什么——哪些是目标，哪些是约束，哪些是证据，哪些只是过时的过程记录。写好一句话当然有用，把相关文件、已有实现和验证结果放到合适的位置，往往同样重要。

二、写清楚「完成」是什么

模型具有很强的指令遵循能力，前提是要有值得遵循的指令。上下文里的要求越明确、越容易验证，模型就越有机会判断自己距离目标还差什么；要求含糊时，它可能很早就认为已经完成了。

「一句话生成一个赛车游戏」可以产生很漂亮的演示。但你心里想的，可能是有真实地图、特定美术资源、某种驾驶手感的赛车游戏；模型交出的，也许只是一个能移动、会碰撞、有速度感的网页。它未必在任何一步明显违背了指令，却在一连串默认选择之后，做出了另外一个产品。这正是上一章说的缺口：镜头怎么跟随，车怎样转向，地图从哪里来，撞车以后发生什么，每个省略都留下了选择空间。模型可以把这些选择做得相互一致，但「一致」保证不了「正好是你想的」。

个人主页是另一个例子。「根据我的公开信息，制作一个现代风格的主页」，看似清楚，其实「现代」这个词没有排除多少可能：模板、渐变、卡片和装饰都能被解释成现代风格。如果你在意的是特定字体、颜色、留白、信息顺序和排版，就应当把这些具体要求或参考写出来。几个形容词，通常代替不了一份设计。

有一个很实用的检查办法：让另一个人只看你的要求和最终产物，能不能判断任务已经完成？「做得专业一点」很难判定；「页面首先展示研究方向和近期工作，手机上无需横向滚动，所有项目入口都能打开」就提供了可以检查的行为。不能完全机械判断的审美，也可以通过示例、对比和反馈逐步说明。

三、三道写作题：多约束遵循与它的边界

有个疑问值得先摆出来：如果模型只是反复计算下一个字出现的概率，它怎样同时满足很多约束？一次模型前向计算的结构和深度是有限的，它无法在这一瞬间任意增加计算步骤。但它可以把中间结果写进上下文，再利用这些结果继续生成；遇到不确定的地方，可以先尝试一种分解，检查后发现不合适，再修改。理解思维链的一个直觉就是：把一串输出看成能够存放中间状态的工作纸。更多输出可能换来更多计算深度，它是否有效，取决于有没有找到能推进问题的步骤，以及能不能识别错误。

为了把「同时满足多个约束」的难度具体摆出来，有三道故意刁难人的写作题。

第一道：写八句中文诗，句首依次是「计算机学院真牛逼」，讲一个与动物相关的故事，「二零二六九月一日」八个字还要依次出现在八句中，并且押韵。一个尝试是这样的：

计成二兔越山冈　算到零时雪满塘　机警狐衔二袋粮　学随六雁辨风向
院中九犬忽声扬　真到月明逢恶狼　牛守一夜迎晨光　逼得日升狼遁荒

检查时可以先竖读句首，再逐句寻找指定字，最后看句尾和故事。藏头与嵌字都能对上，句尾也有相近的韵感，但「方向」的「向」与其他句尾在普通话拼音里并不完全相同，有些句子读起来明显是在凑约束。这个例子展示的是模型能够寻找并修补一个多约束解，它没有宣告模型写出了好诗。

第二道：一句话十八个汉字，全部带相同偏旁，还要有意义和故事性。一个例子是：

洪涝淹没江港渔浦，油污漂浮，沈涛泅渡济溺。

去掉标点可以数出十八个字，都带三点水；把「沈涛」读作人名，故事就是洪灾与油污中有人游过去救助溺水者。这里的检查比较直接，但「都含三点水」与「词典里都归为同一部首」仍然是两个要求。要交给程序验收，就得先决定检查的究竟是哪一个。

第三道：所有字同音，写一段有现代背景的文言故事，不能照搬已有的同音文。一个尝试用不同声调的 yi 音字，写一个翻译器误译、送修、恢复正常的故事。这立即暴露出另一项规格选择：「同音」是否要求声调也相同？作者靠字形区分意思，读者看文字还能猜出情节，念出来却可能几乎无法理解。

四、上下文里的规则会争夺注意力

把要求写进上下文，可以让模型在生成过程中反复利用它：项目约定使用中文，或者提交信息不添加某种署名，它就有机会在相关时刻纠正自己的输出。不过，「在上下文里」保证不了「每次都会正确遵循」。

提示词还会带来副作用。你说「白色背景，不要半透明效果」，模型可能把这句话变成代码里的注释：「白色背景（不要半透明效果）」。它完成了背景设置，却也把原本只用于沟通的要求带进了产物。一个看似合理的修补办法随之出现：再加一条永久规则，禁止把用户要求写进注释。但每遇到一次问题就增加一条规则，上下文会越来越长，约束之间也越来越难协调，这属于有代价的增强。

更合适的做法，是区分长期适用的简短规则与当前任务需要的细节：项目层面留下真正稳定的约定；特定任务的做法按需加载；能够直接检查的要求，尽量写成代码和验证结果。白色背景可以由具体样式和渲染结果确认，不必依靠越来越长的自然语言劝诫。上下文工程因此也包含取舍：删去一段无关说明，有时和增加一条关键要求同样有效。模型需要的并非尽可能多的文字，需要的是此刻做决定时用得上的信息。

五、「你是一位审稿人」，还不够

把任务换成论文审稿：假装自己是某个顶级会议的审稿人，阅读指定论文，写一份约一千英文词的评审意见，并判断是否应该接收。模型很容易写出一份看起来像审稿意见的文本：概括贡献，列出优点与不足，再给出一个建议。问题是，它究竟完成了多少判断？「扮演审稿人」可以提示语气和输出结构，却没有把一个好审稿人的方法自动交给它。

论文的信息密度非常高。作者给出了答案，也替读者选好了问题、术语、比较对象和衡量标准。顺着文章走完一遍才开始评价，很容易在不知不觉中接受作者的整个框架：你以为自己在批判性思考，其实只是在作者划好的场地里打转。

可以把审稿工作拆成三条不同的路线。

1. 从判据出发：先还原论文声称的贡献，再问每项贡献需要达到什么标准、证据在哪里。
2. 审查证据：把核心主张、实验支持、未验证假设和替代解释一项项对应起来。
3. 站到复现者或反方的位置：重算一个关键结果，寻找最小反例，明确什么观察会推翻结论。

这几条路线的价值来自问题不同；若一开始就共享同一个总体印象，最后可能只得到同一个判断的三份润色。独立形成初步意见，再比较分歧，才更容易发现原先没有看到的东西。

这也说明人的方法怎样影响机器的结果。你不必替它读完每一行，但需要知道什么算有根据的判断、哪些证据缺失值得追问。当一套做法多次有效，就可以把它写成技能文件：技能看起来是一段提示词，真正值得保存的，是成功经验里的搜索策略、判断标准和检查点。

六、完成的语义包含失败

「写完」这两个字听起来只有一个方向：把东西做出来。实际的任务里，完成有第二种形态——说清楚为什么没做完。

如果关键条件无法验证，合理的结果应当是一份说明：哪里没完成、缺少什么证据、下一步需要谁提供什么。例如要求「把这份名单导入系统，并确认教务里的班级人数一致」，如果教务处接口当天维护，正确的交付包含三样：导入已经做了的部分、接口返回的原话、等接口恢复后要补的那一步核对。把这些状态说清楚，智能体才能更可靠地决定继续尝试，还是需要新的信息。

反过来，如果验收标准只写「导入成功」，它就很可能在接口报错之后写一句「已完成」交差。这未必是它在撒谎，更可能是你给的标准允许了这个结果。

七、把要求写成一段能直接粘贴的话

四段结构落到纸面上，长这样。同一个任务，左边是模糊版，右边是改写版。

改写版比模糊版长了四倍，换来两样东西：你可以自己对着检查，模型也知道做到哪一步算完。写这种要求通常不超过五分钟，返工的次数会明显减少。

四段里最容易写漏的两段

四段都重要，但漏得最多的是材料与验收这两段，它们各有各的漏法。

材料漏掉的是路径和原文。「就那个文件」在你自己脑子里指向很清楚，在模型那里指向一片空白。把完整路径写出来，把报错原文整段贴进去，把它该看的那几行引出来，这一步花不了两分钟，却能省掉一整轮追问。让模型引用路径和行号还有个额外好处：它没法轻易编造，因为路径和行号你可以立刻核对。这也是减少凭空捏造最便宜的手段。

验收漏掉的是失败分支。大多数人的验收只写「怎样算做完」，不写「怎样算没做完」。补上这一半，模型才不会在卡住的时候硬交一句「已完成」。一条完整的验收通常包含三个问句：用什么动作检查、检查结果长什么样算通过、不通过的时候交回什么。

最后还有一条使用顺序上的经验：先写目标与验收，再写材料与约束。目标和验收决定了这件事值不值得做，材料和约束只决定怎么做得更省事。顺序反过来，很容易花半小时整理材料，最后发现目标本身就写错了。

自测