SH

Soloharness

概念 · 辨析 · Agent

← 返回概念辨析

Concept Contrast Fable

管信息环境的和写单条指令的工程

提示工程关注单条消息的措辞、结构和示例。上下文工程关注模型每次调用时眼前能看到什么——文档片段、历史对话、系统指令、工具输出——以及这些信息的组织、排序和裁剪方式。把两者混为一谈,会导致在措辞上反复优化而忽略信息环境的结构性缺陷。

寓言

粥铺里熬粥的师傅和管灶台的师傅

南街粥铺有两个师傅。刘师傅专门熬粥——火候、米水比例、搅动的圈数、下料的时机。一碗粥端上桌,客人说好喝,他说米得泡三刻、火得文三分。张师傅不管熬粥,他管整个灶台——哪口锅在什么位置、柴堆得多高、水缸离灶多近、蒸笼摞几层、早上谁第一个进来开灶门。

外人不觉得张师傅也重要。粥是熬出来的,灶台又不会熬粥。可有一年冬天柴房进水,湿柴点不着,刘师傅的火候表完全失效——他只练过干柴上面的粥。张师傅重新排了灶眼、调了烟道、把两口锅的位置对调,用半干柴照样把粥熬出八成水平。

还有一次换新米。刘师傅换了米水比例和搅法,粥确实好喝了两成。但下面两个月客人越来越少——不是粥不好喝,是端上桌的粥总是温的。查下来发现李师傅改了煮粥顺序,先煮好的倒进保温桶等后面的,桶的位置离灶台远了两尺,端碗要多走十二步。熬粥的功夫是对的,粥上桌的状态是错的。

张师傅做了一件事让所有人心服。他把灶台上的每一种变化画成一张总图:什么米、什么柴、什么桶在什么位置、先做什么后做什么、谁什么时候进灶房。他不在图上画怎么熬粥。刘师傅的粥方被贴在图的最下面——三条写满,后面写一句“其他看总图”。

两个师傅的差别在某一天彻底清晰。来了一个贵客,点名要一碗只能做一次的粥——材料只有一份。刘师傅把火调到最文,眼睛盯着每一圈。张师傅清空了整个灶台——只剩一口锅、一捆干柴、一盆水、一人守着。粥成了。刘师傅说火候定生死,张师傅说灶台决定火候能不能生效。

年轻学徒进铺子后先跟张师傅学三个月——看灶台布局、进出路线、材料顺序、故障时候该换什么。第四个月才去找刘师傅学熬粥。先知道手上端的是哪口锅,再学锅里的东西怎么煮。

灶台不比锅重要,但灶台错了锅用不上。铺子后来把两人的台座分开:客人要换口味找刘师傅改方子,出餐速度慢、接不住大单、换材料就翻车——这些事找张师傅看灶台。粥方是一句话,灶台是一整套信息环境。

上下文工程

管理模型每次调用时的信息环境——系统指令、历史对话、检索片段、工具输出的组织、排序和裁剪。决定了模型能看到什么,以及这些信息如何影响推理。

提示工程

设计和优化单条提示的措辞、结构和示例,以提高模型对该调用的响应质量。关注的是信息“怎么说“而不是“给什么”。

故事对应

  • 刘师傅熬粥:提示工程,关注单次调用的配方(措辞、结构、示例)
  • 张师傅管灶台:上下文工程,管理整个信息环境的布局、顺序和可达性
  • 湿柴火候表失效:提示配方在信息环境变化时效果大减
  • 粥是好喝的但是温的:信息环境中的流程缺陷抵消了单条指令的优化收益
  • 灶台变化总图:上下文工程输出是信息环境的整体设计而非单条指令
  • 清空灶台只为熬一碗:极端场景下信息环境决定了指令能否生效

落到 LLM 应用性能瓶颈定位

模型回答质量差时,先查上下文工程,再调提示。常见陷阱是反复改提示措辞,而真正的问题是检索召回不全、历史对话截断过早、工具输出格式不对或者信息组织顺序混乱。一个有效的自检流程:先画当前调用的完整信息流——从系统指令到最新用户输入之间的所有内容排成时间线,看哪些信息缺失、哪些冗余、哪些顺序错。画完图再改提示,而不是对着结果猜该加什么词。上下文工程和提示工程的投入比通常在重型应用里应该倒过来——七成精力放在信息环境,三成放在措辞。