第一站:Prompt Engineering#

模型本质:预测下一个字,不是思考#

把大模型那层外壳扒掉,里面其实就一个东西:一个巨大的参数文件,干的活只有一件——根据你输入的内容,预测下一个字最该是什么。

关键认知:

  • 是"预测",不是"思考"

  • 本质上是在顺着你给的方向往下猜

  • 你给的输入越模糊,它猜的范围越散

  • 你给的输入越具体,它猜得越准

输入越模糊 → 猜测范围越散 → 输出越不可控
输入越具体 → 猜测范围越窄 → 输出越精准

提示词配方#

最早,瓶颈卡在一个最朴素的地方:模型不是不会,是你没把话说明白。于是大家摸出一套"提示词配方":

配方要素

作用

示例

角色设定

圈定输出视角与风格

"你是一位资深数据分析师"

背景

提供任务上下文

"公司 Q3 营收同比下降 15%"

参考资料

注入领域知识

"以下是近三年财报数据…"

明确任务

指定要做什么

"请生成一份归因分析报告"

约束

限定边界与禁止项

"不超过 500 字,不引用未提供的数据"

输出格式

规定结构

"Markdown 表格 + 三段结论"

把这些组装好,让模型稳定吐出你要的东西——这就是 Prompt Engineering。

瓶颈:怎么说#

Prompt Engineering 解决的核心瓶颈是"怎么说"。

效果差异示例:

输入方式

提示词

效果

模糊

"帮我分析这份数据"

漫谈式输出,命中率低

具体

"你是数据分析师,基于以下 Q3 数据,找出营收下降的三个主因,用 Markdown 表格输出,每个主因不超过 100 字"

精准、结构化、可用

同样的模型,"加个排序"式的随意指令与完整配方指令之间,效果可以差十倍

局限:变不出模型不知道的事实#

Prompt Engineering 的天花板很快被顶到:

提示词变不出模型不知道的事实。

当任务变复杂时:

  • 模型训练数据中没有的事实 → 提示词无法凭空生成

  • 需要实时外部信息 → 提示词无法获取

  • 需要多步骤推理链 → 单轮提示词难以稳定支撑

  • 需要操作外部工具/环境 → 提示词本身无此能力

瓶颈被顶到了下一层:不只是怎么说,而是给模型什么。这催生了 Context Engineering。

适用场景#

Prompt Engineering 最适合的场景:

  • 一问一答的短链路任务:单轮或少量多轮对话

  • 知识在模型训练范围内:不依赖外部实时信息

  • 输出以文本为主:不需要操作工具或环境

  • 质量容错空间较大:偶尔偏差可接受

当任务超出这些边界——需要进入环境"干活"、需要长链路推理、需要稳定可重复——Prompt Engineering 就需要被纳入更大的 Context Engineering 体系。

← 返回 索引页 | 上一节 01-瓶颈外移 | 下一节 03-Context Engineering