第一站: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