一、开场

在前5章，我们已经一步步搭建起了LangChain的“基础能力框架”：接入大模型（大脑）、添加短期记忆（记住对话）、调用Tool工具（动手做事）、定制知识库（专属记忆）、操作SQL数据库（处理数据）。

相信很多新手都有过这样的困惑：代码从头到尾没写错，API密钥也配置正确，但大模型就是“不听话”——问销售额返回一堆无关数据，查知识库却编造信息，调用Tool时要么误调用、要么不调用。

其实问题根本不在代码，而在“你和大模型的沟通方式”——也就是

提示词（Prompt）

。

本章作为LangChain新手入门的第六章，我们就聚焦“提示词工程”，用最通俗的语言、最落地的技巧，教你快速学会“指挥”大模型，让它精准听懂你的需求，不用改代码，就能让前5章学的所有功能，效果直接翻倍。

二、为什么要学习提示词？为什么叫“提示词工程”？

新手最容易陷入的误区：“提示词不就是写一句话吗？没必要专门学”。但实际上，提示词是LangChain所有功能的“底层指挥系统”，其重要性远超你的想象，而它被称为“工程”，也绝非夸大。

你可以把大模型想象成一个

能力很强、但不会读心的员工

。

同样一个员工，在不同领导手下，发挥出来的效果天差地别 —— 不是员工能力变了，而是

领导会不会交代工作

。

有的领导只说一句：“你把数据弄一下。” 员工只能瞎猜、反复确认，最后做出来的东西完全不对。有的领导会说清楚：“你现在查 11 月份的销售总额，算完直接给我一个数字，不要多余解释。” 员工立刻就能精准完成。

提示词，就是你给大模型下达的 “工作指令”。

指令越清晰、规则越明确，大模型就越听话、输出越准。

1. 为什么必须学提示词工程？

① 不用改代码，效果直接翻倍（最省钱、最高效）

前5章学的sql Agent、知识库、Tool调用，只要优化提示词，就能解决80%的新手痛点：比如SQL Agent不再写错SQL，知识库不再“幻觉”，Tool调用不再混乱，全程不用改一行代码。

② 解决前5章的高频坑，降低调试成本

新手调试LangChain时，80%的报错、无效输出，都不是代码问题，而是提示词写得模糊、无规则。学会提示词工程，能少走很多弯路，节省大量调试时间。

③ 为后续进阶内容打基础（衔接闭环）

后续我们要学的RAG、多模态Agent、部署上线，都离不开提示词工程。比如多模态Agent需要提示词“先识别图片，再分析数据”，没有好的提示词，再强的功能也用不起来。

2. 为什么提示词是“工程”，而非“一句话”？

很多人觉得“工程”是复杂的代码、庞大的系统，但提示词工程的核心，是“系统性、可复用、可优化”——它不是随便写一句提问，而是一套有逻辑、有规则、可落地的“沟通方法论”，这也是它被称为“工程”的原因：

- 不是“随机写”：而是有固定结构、明确规则，确保每次输出都稳定；

- 不是“一次性”：优化后的提示词可复用在同类场景（比如一个SQL提示词，可适配所有销售数据查询）；

- 不是“不迭代”：可根据大模型的输出效果，持续优化提示词，让效果越来越精准。

简单说：普通提示词是“随便喊一声”，提示词工程是“精准下指令”，这就是“一句话”和“工程”的本质区别。

三、如何优化提示词？掌握提示词的核心结构（新手必记）

新手优化提示词，不用死记硬背复杂技巧，先掌握“固定结构”——只要按这个结构写，就能避开80%的错误，比瞎写高效10倍。核心结构分为4部分，缺一不可，所有LangChain场景（SQL、知识库、Tool）都能直接套用。

提示词核心4段式结构（必记，可直接复制套用）

【结构1：明确身份（让大模型知道“它是谁”）】

核心作用：给大模型设定清晰的角色，限定它的能力范围，避免“越界”。

示例（适配不同场景）：

- 适配SQL Agent：你是一个专业的SQL查询助手，专注于查询公司销售数据，只负责生成正确的SQL并整理结果；

- 适配知识库：你是一个专属知识库助手，仅基于提供的私有文档内容回答问题，不负责其他无关回复；

- 适配Tool调用：你是一个Tool决策助手，负责判断用户问题是否需要调用Tool，不冗余调用、不遗漏调用。

【结构2：明确任务（让大模型知道“要做什么”）】

核心作用：清晰告知大模型的具体任务，避免“理解偏差”，越具体越好。

示例：

- 适配SQL Agent：根据用户的自然语言问题，生成正确的SQL语句，查询sales表中的数据，然后将查询结果整理成简洁的自然语言；

- 适配知识库：根据用户的问题，从知识库中检索最匹配的内容，然后直接输出核心答案，不添加多余解释。

【结构3：明确规则（让大模型知道“能做什么、不能做什么”）】

核心作用：划定边界，避免大模型“幻觉”、误操作，这是新手最容易忽略，也最关键的一步。

示例（通用+场景化）：

- 通用规则：不编造信息、不知道就说“未找到相关信息”、不添加多余解释、严格按要求输出；

- SQL场景规则：不编造表名、字段名，不删除、不修改数据库数据，仅执行查询操作；

- 知识库场景规则：答案必须100%来自知识库，不扩展、不推测、不修改原文关键信息。

【结构4：明确格式（让大模型知道“怎么输出”）】

核心作用：规范输出形式，避免回答混乱、冗余，让结果更符合你的使用需求。

示例：

- 简洁版：仅输出自然语言结果，不换行、不添加任何符号，一句话说清核心；

- 详细版：分点输出，每点不超过20字，标注结果来源（比如“来源：知识库第3段”）；

- SQL场景版：先输出SQL语句（标注“SQL语句：XXX”），再输出整理后的自然语言结果。

总结：新手优化提示词，不用追求“华丽”，只要把这4部分写完整、写具体，就能得到精准的输出——这是提示词工程的基础，也是最核心的优化方法。

四、实用小技巧：4个新手必学，快速提升提示词效果

掌握了核心结构后，再搭配这4个小技巧，能让你的提示词效果再上一个台阶，全程无复杂操作，新手可直接套用，适配前5章所有场景。

技巧1：指令“越具体，效果越好”（避免模糊表述）

❌ 反面示例（模糊）：帮我查销售额；

✅ 正面示例（具体）：帮我查2024年11月我们公司的总销售额，仅输出数字结果，不添加任何多余解释。

关键：补充“时间、主体、具体需求、输出要求”，不给大模型留“猜测空间”。

技巧2：添加“示例引导”（适合复杂场景）

如果任务比较复杂（比如复杂SQL查询、多Tool组合），可以在提示词中添加1个示例，让大模型“照猫画虎”，减少理解偏差。

示例（适配SQL场景）：

“示例：用户问‘查10月份总销量’，SQL语句：SELECT SUM(sales_quantity) FROM sales WHERE date LIKE '2024-10%'，回答：‘2024年10月总销量为100’。请按照这个示例，回答我的问题。”

技巧3：精简上下文（避免冗余干扰）

新手容易把整篇文档、所有历史对话都塞进提示词，导致大模型抓不住重点，输出混乱。

技巧：只保留“关键上下文”，比如“仅参考最近3条对话，重点关注产品定价相关内容，其余忽略”，让大模型聚焦核心信息。

技巧4：添加“容错规则”（降低报错概率）

在提示词的“规则”部分，添加容错条款，避免大模型遇到未知问题时，出现报错或胡乱回答。

示例：“如果遇到表名、字段名不确定的情况，不编造，直接回答‘无法确定查询条件，请补充表结构信息’；如果无法检索到相关内容，直接回答‘未找到相关信息’。”

五、案例演示：2个高频场景（前后对比，可直接复制运行）

结合前5章的高频场景（SQL Agent、知识库），做“差提示词vs好提示词”的前后对比演示，附完整可运行代码，新手复制粘贴就能看到效果，真正理解“提示词的力量”。

前置准备：确保已安装必要的库（langchain、langchain-openai、python-dotenv、sqlalchemy、chromadb），API密钥配置正确（可替换国内模型）。

案例1：SQL Agent场景（最常用，对比最明显）

需求：查询2024年11月的总销售额，要求精准、简洁、不报错。

❌ 差提示词（无结构、模糊，可运行但效果差）

# 差提示词（无结构、模糊）

bad_prompt = "你是SQL助手，帮我查询数据库。"

✅ 好提示词（完整4段式结构，效果拉满）

good_prompt = """【身份】

您是一个专业的MySQL数据库交互专家，专注于处理与数据库操作相关的问题。

**核心能力：**

- 直接执行SQL语句（查询、插入、更新、删除、建表等）

- 自动进行数据验证和结果检查

**重要规则（必须遵守）：**

1. 必须完全信任和尊重工具查询结果，即使结果为空或与预期不符

2. 如果sql_db_list_tables工具返回空列表[]，说明数据库确实没有表

3. 绝对不要基于训练数据中的常见模式来编造表信息

4. 工具返回什么就回答什么，不要添加、修改或忽略工具结果

当前已知信息：

- 数据库类型: MySQL

- 工具查询结果是最权威的信息源

**工作流程：**

1. **需求分析**：理解用户要执行的操作类型

2. **结构探查**：查看相关表结构和数据

3. **SQL构建**：构建合适的SQL语句

4. **执行验证**：执行SQL并验证结果

要求：

1，表和字段，都应该有中文注释

2，表名和字段名都应该是英文，下划线分割，如果创建表时用户提供的属性是中文，你应该翻译为对应英文创建字段，用户的中文作为字段注释。如果用户给的是英文字段，那么就用这个作为字段名称，对应的翻译作为字段注释。

请用中文回复，操作结果要清晰易懂。"""

案例2：知识库场景（解决“幻觉”痛点）

需求：查询公司进阶版产品定价，仅基于知识库内容回答，不编造。

❌ 差提示词（无边界，易幻觉）

# 差提示词（无结构、无边界）

bad_prompt = "你是知识库助手，帮我回答问题。"

✅ 好提示词（完整4段式，防幻觉）

good_prompt = """【身份】

你是一个专属知识库助手，仅基于提供的私有知识库内容回答用户问题。

【任务】

根据用户的问题，从知识库中检索最匹配的内容，整理成核心答案并输出。

【规则】

1. 答案必须100%来自知识库，不添加任何推测、扩展、编造的内容；

2. 不修改知识库中的原文信息（尤其是定价、产品名称等关键内容）；

3. 未检索到相关内容时，直接回答“未找到相关信息”，不模糊回复；

4. 不添加多余解释，只输出核心答案。

【格式】

仅输出核心答案，不换行、不添加任何符号，示例：“进阶版19999元/年”。"""

六、结尾

本章作为LangChain新手入门的第六章，我们重点掌握了提示词工程的核心，没有复杂术语、没有冗余内容，全是新手能直接落地的干货：

对于新手来说，不用急于掌握提示词工程的进阶内容（比如思维链、少样本提示），先把本章的基础结构和技巧练熟，就能应对80%的LangChain应用场景——把前5章的代码，搭配本章的提示词，重新跑一遍，你会发现大模型“听话”了很多。

提示词不是写一次就永远能用的 “万能剑法”，更像是

一套要根据场景随时调整的指挥话术

。

面对 SQL 查询、知识库问答、Tool 调用这些完全不同的任务，你不能用同一套提示词硬套，就像不能用同一种沟通方式去对接销售、财务、技术一样。

好的提示词，是

调试出来的

：先写一版基础指令，看大模型的输出哪里不对，再一点点补规则、加边界、调格式，慢慢迭代到最稳定的效果。

只有学会

灵活换提示词、按需改提示词

，你前面搭建的 LangChain 系统，才能真正稳定、好用、能落地。

内容提及地域：江西省、上饶市、余干县

IP属地：黑龙江