← 返回概念解读

Concept Fable精修版

提示工程

Prompt Engineering · LLM Interaction

先读故事。这里不急着给定义,先让问题自己长出来。

寓言故事

给聪明学徒写清差事的人

边关有个密信司,专替将军写给斥候的指令。早年将军想到什么写什么:去北坡看看、别惊动敌人、天黑前回。聪明斥候能懂,新人常误会。

一次斥候把‘看看粮车’理解成数车轮,漏了护卫人数;另一次把‘不要交战’理解成连被发现也不回报。将军才知道,信写得顺口,不等于能稳定引出行动。将军第一次以为问题在斥候粗心,罚了两人。后来换了最老练的斥候,仍在同一句话上犹豫,才承认问题从信里就开始了。

密信司开始整理格式:先写目标,再写边界,再写可用工具和回报样式;危险任务要给反例,含糊词要换成可检查的描述。每封新信先让两名新人试读,看会不会走偏。第一套格式太死,所有任务都套同样长度。急探信被写得像军令长文,慢任务又缺少足够背景,密信司只好按任务类型分模板。

后来战况变化,密信司还会复盘失败信件,留下可复用句式,也删掉会诱发误解的写法。写信从灵感活,变成持续测试、改写和维护的手艺。复盘时,他们不只看哪封信成功,还看成功是否靠斥候自行猜对。靠猜赢来的胜利,下一次仍可能输。

密信司还建立试信场。让新人、老兵和外地斥候分别读同一封信,若三人走向不同,就说明信还不能上战场。

后来将军也接受,有些失败不是斥候不勇敢,而是指令没有把意图、边界和回报方式传清。把这件事工程化,是为了少让前线靠猜。

后来边关战事更急,将军反而更依赖密信司。越是时间短,越不能临场发明含糊说法;事先沉淀好的格式和反例,能让急令更短,也更不容易走偏。

一条好指令能帮一次行动;一套写、试、评、改的办法,才能让许多行动稳定。真正的功夫在反复让意图变得可执行、可检查。

揭示

这个故事讲的是:提示工程

Prompt Engineering 是设计提示词来引导模型行为、提高任务表现的实践,不改变模型权重。它包括明确目标、提供上下文、设定约束、给出示例、规定输出格式和迭代评测。企业 Agent 中,提示工程不能替代工具、权限和流程设计,但它是把业务意图稳定传给模型的关键接口。

它重要的地方在于:它不只是一个术语,而是在真实 AI / Agent 系统里会反复出现的结构性问题。理解它,才能判断什么时候该加模型,什么时候该改流程,什么时候该补治理。

隐喻映射

  • 聪明学徒:大语言模型
  • 写得好一点:含糊 prompt
  • 认真、准确、专业:空泛修饰词
  • 读者、目标、必填项、禁区:任务上下文和约束
  • 好样稿和坏样稿:few-shot examples 与反例
  • 沉淀模板并记录效果:提示词管理和评测迭代
  • 错误可定位:prompt、上下文、格式或工具边界的诊断
  • 最后洞察:Prompt Engineering 是把业务任务转译成模型可执行指令的工程实践

Soloharness 判断

这个概念的实战价值,是帮你把“看起来聪明的 AI 功能”拆成可交付、可验收、可治理的工作单元。

promptfew-shot promptingchain-of-thoughtsystem message