order: 7 title: 第 3 章：Prompt 为什么会失败？ tag: - LLM category: - LLM date: 2025-12-30 12:15:07 keywords: LLM应用开发
在大模型应用开发之初，demo版、或者初版的设计一般大同小异，比如以企业知识库助手为例，第一版实现通常是这样的：
“你是一个企业知识库助手，请根据公司文档回答用户的问题。”
从实际的表现来看，demo还行，但是离生产使用，总是差点意思：
- 回答流畅（大模型的输出一般还是很可以的，至少语言组织天赋应该胜过很多像我这样比较潦草的人了🤣）
- 语气专业（即使回答内容有误，也是一股正经、理直气壮，这就是让开发者感到为难的地方了~）
- 但事实经常对不上（例如把 “3 个工作日审批” 说成 “5 个工作日”，把 “部门经理审批” 漏掉）
那么问题来了：
Prompt 已经写了，为什么系统还是不可靠？
3.1 一个必须先纠正的认知误区
很多小伙伴可能会有下面这个潜意识
“Prompt 是给模型下指令的。”
但如果你还记得第一部分的结论，就会意识到：
LLM 并不会‘执行指令’，它只是在延续文本。
这是啥意思呢，又表明什么呢？
Prompt不是命令（模型没有 “理解指令并执行” 的能力，它只是根据上下文概率生成下一个词）Prompt是上下文的一部分（模型会把 Prompt 当作 “对话历史” 的开头，然后 “接话”）Prompt的作用，是改变生成空间的形状（通过调整上下文，让模型更可能生成符合预期的内容）
如果你在上下文中留下了模糊空间，大模型“自由合理地填满这些空白”，就是必然会出现的结果了
举个例子来解释下上面的说法
当用户问 “公司的病假工资怎么算？”，如果 Prompt 只说 “根据公司文档回答”，模型会怎么做？
它会先从训练数据中回忆 “一般公司的病假工资规则”（比如 “按基本工资的 80% 发放”），再尝试把这个 “常识” 套进 “公司文档” 的语境里
即使文档中明确写的是 “按全额工资发放”，模型也可能因为 “常识更熟悉” 而优先输出错误内容。
3.2 企业场景下，Prompt 最常见的三类失败模式
失败模式一：角色边界缺失
“你是一个知识库助手。”
这个描述在自然语言中是清晰的，但对模型来说，信息几乎为零。
问题在于：
- 这个角色是否可以使用常识？（比如用户问 “打印机坏了怎么办”，是否可以推荐 “重启试试” 这种通用经验？）
- 是否可以综合多份资料？（比如用户问 “跨部门协作流程”，是否允许整合《部门沟通规范》和《项目管理手册》的内容？）
- 是否允许推断 “合理但未写明” 的结论？（比如文档说 “员工入职满 1 年可休年假”，是否可以推断 “不满 1 年不可休”？）
没有被否定的行为，都会被模型视为“允许”。
在企业场景中，这种 “默认允许” 往往是灾难的源头。
比如某公司文档只写了 “经理级以上可申请弹性工作”，模型可能会 “合理推断”“主管级以下不可申请”
但实际上，文档漏写了 “主管级满足条件也可申请”，导致员工权益受损。
失败模式二：信息来源未被工程化
“请结合你所知道的内容回答。”
从模型视角看：
- “你所知道的内容” = 训练语料（互联网上的通用知识、其他公司的制度、甚至过时的信息） + 当前上下文（可能包含的部分文档片段）
而在企业知识库助手中，我们真正想要的是：
一个“被严格限制的信息子集”（即 “仅当前提供的公司内部文档”）。
这也是为什么后续 RAG 的核心价值，并不只是“补充知识”，而是： 缩小生成空间。
举个具体案例：
某公司 2025 年更新了差旅费标准（住宿上限从 800 元调整为 1000 元），但模型训练数据截止到 2024 年。
如果 Prompt 没有严格限制 “仅用提供的 2024 年文档”，当用户问 “出差住宿能报多少” 时，模型会优先输出训练数据中的 800 元
因为对它来说，“旧知识” 比 “新文档片段” 更 “熟悉”。
失败模式三：输出目标不可判定
“请详细说明相关内容。”
这类 Prompt 最大的问题不是“不清楚”，而是：
你无法客观判断它有没有答对。
详细” 是多详细？“相关” 是哪些相关？当输出结果出现时，你只能凭感觉说 “好像对” 或 “好像不对”，但无法用明确的标准验证。
一旦输出目标不可判定：
- 系统无法测试（无法写自动化用例验证 “是否符合详细说明的要求”）
- 系统无法评估（无法量化 “回答准确率”，只能靠人工主观打分）
- 系统也无法迭代（不知道改 Prompt 后是变好还是变坏）
例如，当用户问 “报销流程有几步” 时，“详细说明” 可能输出 “先填单、再审批、最后报销”（3 步），也可能输出 “填单需附发票、审批分部门和财务、报销到账约 3 天”（包含额外信息）。
这两种输出都符合 “详细”，但前者漏了关键步骤（如 “发票校验”），却无法通过明确规则判定错误。
3.3 本章小结
到这里，我们可以给出一个工程层面的总结：
Prompt 失败的根本原因，不是表达能力不足，而是约束设计不足。
Prompt 的核心职责不是 “告诉模型该怎么说”（比如 “用专业语气”“分点回答”），而是：
明确告诉模型：哪些内容是被允许生成的，哪些不是。
既然我们已经找到了 Prompt 失败的根源是 “约束设计不足”，那么解决方案就不再是 “优化措辞”，而是构建一套系统化的约束框架。Prompt 不应该是零散的指令集合，而需要有稳定、可复用的结构来承载这些约束
—— 这正是第 4 章要探讨的核心：如何通过工程化的结构设计，让 Prompt 真正成为可靠的 “约束系统”。