第二部分｜Prompt 工程：从“写提示词”到“设计约束系统”（以企业知识库助手为主线）

本部分目标：

• 让读者真正理解 Prompt 在系统中的地位，而不是学会几条写作技巧
• 通过「企业知识库助手」这一真实场景，引导读者像工程师一样思考 Prompt
• 为后续 RAG、Memory、Agent 建立统一的“约束设计”认知框架

在第一部分中，我们已经反复强调过一个结论：

LLM 天生不可靠，可靠性来自系统，而不是模型本身。

这一部分要回答的问题是：

在还没有 RAG、没有工具、没有 Agent 之前， 我们能做的第一件工程化的事情是什么？

答案是：Prompt 工程。

但请注意：

本书所说的 Prompt 工程， 并不是“写得更聪明”， 而是“约束得更清楚”。

---

示例应用贯穿说明：企业知识库助手

在本书后续所有章节中，我们都会围绕同一个示例系统展开：

企业知识库助手（Enterprise Knowledge Assistant）

这是一个非常“现实世界”的系统：

• 面向公司内部员工（用户群体明确，需求集中在业务流程、制度规范、产品信息等具体领域）
• 回答的问题往往有标准答案（例如 “报销流程需要哪些审批人”“产品 A 的质保期限是多久”）
• 回答错误的成本很高（可能导致员工操作违规、业务决策失误，甚至法律风险）
• “听起来合理但其实是错的”，比“不知道”更糟糕（例如错误告知 “供应商付款无需 CEO 审批”，可能引发财务漏洞）

这使它成为 Prompt 工程的理想试验场。—— 因为它对 “准确性” 和 “可控性” 的要求，恰好击中了 LLM 最需要被约束的痛点。

正是这样一个对可靠性要求极高的系统，在实际开发中却常常因为 “简单化的 Prompt 设计” 而翻车。很多团队认为只要给模型贴上 “知识库助手” 的标签，就能得到符合预期的结果，但现实往往事与愿违。为什么看似清晰的 Prompt 会失效？这背后藏着对 LLM 工作逻辑的认知偏差，也暴露了 Prompt 设计中未被重视的核心问题 —— 这正是我们接下来要深入拆解的内容。