← 返回概念辨析

Concept Contrast Fable

提示词和提示工程,一砖一瓦是材料,全套图纸是工程

提示词是你向模型发出的单次输入文本——一个指令、一个问题、一段上下文。提示工程是一套系统化的设计方法,涉及模板设计、质量控制、版本管理、评估流程和持续迭代。把单个 prompt 叫成 prompt engineering,相当于把一块砖叫做建筑工程。

寓言

一封密信和一个密信司,前者是纸上的字,后者是整套传信机制

边关军营靠密信调兵。将军写一封信,说明敌情、目的和禁忌,斥候照信行事。信写得清楚,一次行动便顺;信写得含糊,斥候可能走错山口。

有次将军把‘天黑后探北坡’改成‘暮鼓后探北坡’,那晚行动顺了。副将以为只要把每封信写漂亮,军情就稳。副将开始收集漂亮句式,把“务必”“尽快”“谨慎”写满信纸。斥候读起来热血,却仍不知道遇到岔路该先保命还是先探明。

很快遇到连环任务:探路、回报、换哨、误报处理、紧急撤退。单封信再好,也挡不住斥候在不同情形下理解不一;有人漏带地图,有人不知道遇到俘虏该不该问。将军第一次补救,是把每次任务写得更长。长信带来新问题:斥候在雨夜看不完,关键限制夹在中间,很容易漏掉。

老参军于是建立密信司。常见任务有固定格式,危险词要避开,回信必须带证据,失败样本要入册复盘;新信发出前,还要用旧战例试读,看看会不会引出误解。密信司最初也只管模板。后来一次旧模板遇到新地形,差点误导斥候,他们才把测试和复盘也纳入职责。

密信司还规定,信发出去后要收回结果。斥候在哪里误解、哪句有用、哪句多余,都记入册。下一封信不是从灵感开始,而是从上次的错误开始。

副将后来仍会亲手写单封密信,但他知道那只是材料。真正让军营稳定的,是密信司背后的格式、测试、复盘和更新。没有这套办法,好句子只能偶尔救场。

后来军营分得清:一封密信,是某次行动的指令;密信司的整套办法,才是让许多密信持续可靠的工程。只改一句话能救一晚,管住写信、试信、复盘和迭代,才能守住一季战事。

提示词

用户向模型发送的单次输入文本,包含指令、问题、上下文和示例。它是一份具体的输入实例,是提示工程体系中产出的基本单元。

提示工程

系统化地设计、测试、迭代和管理提示词的方法论。涵盖模板设计、版本管理、质量评估、边界测试和持续优化流程,是一套工程实践而非单个文本。

故事对应

  • 一封军情信:单个 prompt——具体的输入文本实例
  • 傅书吏的职责:prompt engineering——格式设计、培训、质检、迭代
  • 年轻书吏加一行标注:一个 prompt 改动——文本修改只需几秒
  • 三个月落地:prompt engineering——制度调整、培训、流程适配
  • 标注被滥用(所有都标紧急):缺乏校验约束——engineering 需要质量门
  • 第二轮迭代加校验规则:prompt engineering 的完整循环——设计、测试、分析、迭代
  • 傅书吏的总结:改信和改制度是两套工作量和两种责任制

落到团队分工和交付预期

在团队里不要把 prompt 优化和 prompt engineering 当成一个角色。写 prompt 的人负责单次输入的构造和调试,可能是一次性的工作。做 prompt engineering 的人负责模板体系、评测基准、版本管理和迭代流程——这套工作会持续产品整个生命周期。外包 prompt 设计可能只拿到一堆文本,但 prompt engineering 需要和产品、数据、评测团队协同运作。立项时如果只报了一个 prompt 设计的工作量但承诺系统稳定性,三个月后一定会因为缺乏持续迭代机制而掉效果——新场景进来时你又得从零写。