在实际的大模型应用开发中我们常常面临一个困境直接向模型提问得到的回答可能过于简略、缺乏逻辑甚至偏离核心意图。尤其是在处理复杂推理、多步骤任务或需要结构化输出的场景时简单的“一问一答”模式显得力不从心。这时提示词工程中的两种核心策略——Zero-Shot 和 Chain of ThoughtCoT——便成为提升模型输出质量和可靠性的关键。它们并非高深的理论而是可以立即应用于项目中的实践技巧能够显著改善大模型的表现有时甚至能让输出的有效信息量直接翻倍。本文旨在为开发者提供一个清晰的实战指南。我们将从零开始解释 Zero-Shot 和 CoT 提示词的核心概念与适用场景然后通过具体的代码示例展示如何在实际项目中设计和应用这两种提示策略。你将学习到如何通过简单的提示词结构调整引导模型进行更深入的思考从而获得更准确、更详尽、更具逻辑性的回答。无论你是正在构建 AI Agent、开发基于大模型的应用程序还是希望在日常工作中更高效地使用 ChatGPT 等工具掌握这些提示词技术都将使你事半功倍。1. 理解 Zero-Shot 与 CoT 提示词从直接回答到引导思考在深入代码之前我们必须先厘清两个核心概念Zero-Shot 和 Chain of Thought (CoT)。它们代表了两种不同层级的模型交互方式。1.1 Zero-Shot 提示基于指令的直接推理Zero-Shot 学习指的是模型在没有针对特定任务进行过显式训练即没有见过该任务的任何示例的情况下仅根据自然语言指令来执行任务。在提示词工程中Zero-Shot 提示通常意味着我们给模型一个清晰、具体的任务描述期望它直接给出答案。通俗理解就像你问一个知识渊博但没做过某件具体事的朋友“如何给自行车换轮胎” 他基于通用知识和逻辑直接告诉你步骤。这就是 Zero-Shot。技术定义模型利用其预训练阶段获得的世界知识和语言模式对给定的新指令进行理解和响应不依赖于任务相关的示例Few-Shot。作用与示例 一个典型的 Zero-Shot 提示可能如下请将以下英文句子翻译成中文“The rapid development of artificial intelligence is reshaping various industries.”模型会直接输出“人工智能的快速发展正在重塑各个行业。”容易误解的地方 很多人认为 Zero-Shot 就是“问得简单”。其实不然它的核心是“无示例”。即使问题很复杂只要不提供参考样例也属于 Zero-Shot 范畴。其效果高度依赖于提示词本身的清晰度和完整性。对于复杂问题单纯的 Zero-Shot 可能无法激发模型的全部推理潜力。1.2 Chain of Thought (CoT) 提示模拟人类的逐步推理Chain of Thought (CoT) 提示是一种引导大模型展示其推理过程的技术。它要求模型在给出最终答案前先一步步地阐述其思考逻辑就像一个人在草稿纸上演算一样。通俗理解同样问“如何给自行车换轮胎”你补充说“请一步一步地思考列出需要的工具然后描述每个步骤的注意事项。” 朋友就会先想“需要扳手、新轮胎…”再一步步说“先松开快拆杆…”。这就是 CoT。技术定义通过在设计提示词时明确要求模型“逐步推理”或展示“思考过程”来解锁模型在复杂推理任务如数学问题、逻辑谜题、多步骤规划上的更强性能。CoT 可以是 Zero-Shot CoT直接要求模型逐步思考也可以是 Few-Shot CoT提供几个包含推理步骤的示例。作用与示例 对于数学问题“小明有5个苹果吃了2个又买了3个现在有几个”Zero-Shot 可能直接输出“6个”。而 CoT 提示会这样设计请逐步推理以下问题 问题小明有5个苹果吃了2个又买了3个现在有几个 让我们一步一步思考模型可能会输出1. 开始时小明有5个苹果。 2. 他吃了2个所以剩下 5 - 2 3个苹果。 3. 他又买了3个所以现在有 3 3 6个苹果。 因此现在有6个苹果。关键价值CoT 不仅让答案更可信因为你能看到推理过程更重要的是对于许多复杂任务展示思考步骤这个行为本身就能显著提高模型得出正确答案的概率。它迫使模型将问题分解减少了“跳跃式”错误。1.3 如何选择Zero-Shot 还是 CoT选择哪种策略取决于任务复杂度、对可解释性的要求以及对输出一致性的需求。策略适用场景优点缺点Zero-Shot1. 简单信息提取、分类、翻译。2. 创意生成如写诗、起名。3. 对响应速度要求高且任务直接。1. 提示词简单交互直接。2. 计算开销小响应快。3. 适合集成到自动化流程中。1. 复杂任务上容易出错或回答肤浅。2. 答案缺乏可解释性难以调试。3. 对提示词措辞非常敏感。CoT1. 数学计算、逻辑推理。2. 多步骤规划如旅行计划、项目拆解。3. 需要验证答案正确性的场景。4. 希望模型输出结构化思考过程。1. 大幅提升复杂任务的准确率。2. 输出具有可解释性便于人工复核。3. 思考过程本身可能包含有价值的信息。1. 提示词更长可能消耗更多 tokens。2. 响应时间相对更长。3. 需要设计如何要求“逐步思考”。在实际的 AI Agent 开发中两者常常结合使用。例如Agent 接收到用户请求后先使用 CoT 提示进行任务规划和分解然后在执行每个子任务时使用 Zero-Shot 提示调用相应的工具或能力。2. 环境准备与基础工具链在开始编写提示词之前我们需要一个能够与大模型交互的环境。这里我们以 OpenAI 的 GPT 系列模型为例使用 Python 的openai库进行演示。其他模型平台如国内的大模型平台的 API 调用方式类似主要区别在于 API 端点和参数。2.1 安装必要的 Python 库首先确保你的 Python 环境建议 3.8并安装openai库。同时我们也会安装python-dotenv来管理密钥。pip install openai python-dotenv2.2 获取并配置 API 密钥访问 OpenAI 平台 (platform.openai.com) 注册并创建 API Key。在项目根目录创建一个名为.env的文件将密钥写入OPENAI_API_KEY你的-api-key-here重要永远不要将.env文件提交到版本控制系统如 Git。确保它在.gitignore中。2.3 创建基础工具函数创建一个 Python 脚本例如prompt_utils.py编写一个通用的模型调用函数。这有助于我们后续集中测试不同的提示词。import os from openai import OpenAI from dotenv import load_dotenv # 加载环境变量 load_dotenv() # 初始化客户端 client OpenAI(api_keyos.getenv(OPENAI_API_KEY)) def call_gpt(prompt, modelgpt-3.5-turbo, temperature0.7, max_tokens1000): 调用 OpenAI ChatCompletion API 的通用函数。 参数: prompt (str): 发送给模型的提示词。 model (str): 使用的模型名称。 temperature (float): 采样温度控制随机性 (0-2)。值越低输出越确定。 max_tokens (int): 生成的最大 token 数。 返回: str: 模型生成的回复内容。 try: response client.chat.completions.create( modelmodel, messages[ {role: user, content: prompt} ], temperaturetemperature, max_tokensmax_tokens ) return response.choices[0].message.content.strip() except Exception as e: print(f调用 API 时出错: {e}) return None # 简单测试连接 if __name__ __main__: test_prompt 请说‘你好世界’ result call_gpt(test_prompt) if result: print(测试成功模型回复, result) else: print(测试失败请检查网络和 API 密钥。)运行这个脚本如果看到“你好世界”的输出说明环境配置成功。3. Zero-Shot 提示词实战从简单到复杂我们将通过几个逐渐复杂的例子展示如何设计有效的 Zero-Shot 提示词。3.1 基础任务信息提取与格式化假设我们需要从一段自由文本中提取公司名、职位和日期并格式化为 JSON。低效的 Zero-Shot 提示从下面文本找信息。 文本张三曾在2020年至2022年间于ABC科技担任高级软件工程师。这种提示过于模糊模型可能回复一句自然语言如“张三在ABC科技做高级软件工程师从2020年到2022年”不符合程序化处理的需求。高效的 Zero-Shot 提示请从以下文本中提取“人物姓名”、“公司名称”、“职位”和“任职起止时间”并以严格的 JSON 格式输出键名分别为name, company, position, tenure。 文本张三曾在2020年至2022年间于ABC科技担任高级软件工程师。 要求 1. 只输出 JSON 对象不要有任何额外解释。 2. 时间格式统一为“YYYY-MM - YYYY-MM”。代码实现def extract_info_zero_shot(text): prompt f 请从以下文本中提取“人物姓名”、“公司名称”、“职位”和“任职起止时间”并以严格的 JSON 格式输出键名分别为name, company, position, tenure。 文本{text} 要求 1. 只输出 JSON 对象不要有任何额外解释。 2. 时间格式统一为“YYYY-MM - YYYY-MM”。 result call_gpt(prompt, temperature0.1) # 低温度保证输出稳定 return result text 李四于2019年3月加入XYZ金融担任数据分析师直至2023年12月离职。 print(extract_info_zero_shot(text))预期输出{name: 李四, company: XYZ金融, position: 数据分析师, tenure: 2019-03 - 2023-12}关键点指令清晰明确告诉模型要做什么提取、输出什么格式JSON、键名是什么。约束明确“只输出 JSON 对象”避免了模型添加多余的自然语言描述。参数调整temperature0.1使输出更确定适合格式化任务。3.2 进阶任务代码生成与解释Zero-Shot 也常用于生成代码片段。关键在于明确需求、输入输出格式和使用的技术栈。提示词设计请编写一个 Python 函数函数名为 find_common_elements。 功能接受两个列表作为输入参数 list1 和 list2返回这两个列表的交集共同元素列表。 要求 1. 返回的列表中元素顺序不限但需去重。 2. 请在函数内部添加清晰的注释。 3. 在函数下方提供一个调用示例展示当 list1 [1, 2, 2, 3], list2 [2, 3, 4, 5] 时的输出。代码调用def generate_code_zero_shot(): prompt 请编写一个 Python 函数函数名为 find_common_elements。 功能接受两个列表作为输入参数 list1 和 list2返回这两个列表的交集共同元素列表。 要求 1. 返回的列表中元素顺序不限但需去重。 2. 请在函数内部添加清晰的注释。 3. 在函数下方提供一个调用示例展示当 list1 [1, 2, 2, 3], list2 [2, 3, 4, 5] 时的输出。 result call_gpt(prompt, modelgpt-4) # 代码生成任务可以使用更强的模型 return result print(generate_code_zero_shot())预期输出示例def find_common_elements(list1, list2): 找出两个列表的交集共同元素。 参数: list1 (list): 第一个列表 list2 (list): 第二个列表 返回: list: 包含两个列表共同元素的列表已去重 # 使用集合set的交集操作来高效地找到共同元素并自动去重 common_set set(list1) set(list2) # 将集合转换回列表并返回 return list(common_set) # 调用示例 list1 [1, 2, 2, 3] list2 [2, 3, 4, 5] result find_common_elements(list1, list2) print(f列表 {list1} 和 {list2} 的交集是{result}) # 输出列表 [1, 2, 2, 3] 和 [2, 3, 4, 5] 的交集是[2, 3]为什么有效提示词定义了函数签名、功能、非功能性要求注释、示例引导模型生成符合工程规范的代码。3.3 Zero-Shot 的常见陷阱与优化即使指令清晰Zero-Shot 也可能出问题。以下是常见陷阱及优化方法陷阱1模型“自由发挥”输出格式不符。现象要求输出 JSON模型却输出 Markdown 表格或自然语言。优化在提示词中强化格式指令并使用“分隔符”明确指示范围。例如请将以下文本摘要为不超过50字。你的回答必须严格按以下格式输出 【摘要】[这里填写摘要内容] 原文{text}陷阱2对于模糊或多义指令模型选择错误理解。现象提问“这个功能怎么实现”模型可能回答技术A而你期望技术B。优化增加上下文限定。例如“在 Python Django 框架下如何实现用户上传图片的功能请给出核心视图和模型代码。”陷阱3模型忽略指令中的细节约束。现象要求“列出3个优点”模型列出了5个。优化将关键约束放在提示词开头或结尾并加粗虽然模型不识别 Markdown但能感知强调。例如“必须只列出3个不能多也不能少。”4. Chain of Thought (CoT) 提示词实战解锁复杂推理当任务涉及计算、逻辑判断或多步骤决策时CoT 提示的价值就凸显出来。我们通过数学问题、逻辑推理和商业分析三个场景来实践。4.1 基础 CoT解决数学应用题我们从一个经典的数学问题开始对比 Zero-Shot 和 CoT 的效果。Zero-Shot 尝试可能失败problem “一个水池有一个进水口和一个出水口。单独打开进水口6小时可以注满水池。单独打开出水口8小时可以放完整池水。如果同时打开进水口和出水口需要多少小时可以注满水池” prompt_zs f”请解决问题{problem}” result_zs call_gpt(prompt_zs, temperature0) print(“Zero-Shot 回答”, result_zs)模型可能直接给出一个错误答案如“24小时”因为它没有展示计算过程可能混淆了效率概念。CoT 提示实现def solve_math_problem_cot(problem): prompt f”””请逐步推理解决以下数学问题。在给出最终答案前请先展示你的完整计算步骤和思考过程。 问题{problem} 让我们一步一步思考””” result call_gpt(prompt, model“gpt-4”, temperature0) # 使用 GPT-4 以获得更好的推理能力 return result result_cot solve_math_problem_cot(problem) print(“CoT 回答\n”, result_cot)预期输出示例让我们一步一步思考 1. 进水口效率6小时注满所以每小时进水占水池的 1/6。 2. 出水口效率8小时放空所以每小时出水占水池的 1/8。 3. 同时打开时每小时净进水量为进水效率减去出水效率1/6 - 1/8 (4/24 - 3/24) 1/24。 4. 这意味着每小时水池能注入 1/24 的水。 5. 要注满整个水池即注入量为1所需时间为 1 ÷ (1/24) 24 小时。 因此同时打开进水口和出水口需要 24 小时可以注满水池。通过强制模型展示步骤我们不仅得到了答案更获得了答案的可信度验证。即使最终答案数字相同CoT 过程也证明了其正确性。4.2 进阶 CoT多条件逻辑决策假设我们要开发一个 AI Agent根据用户输入的需求决定调用哪个内部工具如“查天气”、“设闹钟”、“算数学”。任务分析用户请求“我明天早上8点要开会顺便看看天气怎么样如果下雨记得提醒我带伞”并输出一个结构化的执行计划。CoT 提示设计user_request “我明天早上8点要开会顺便看看天气怎么样如果下雨记得提醒我带伞。” cot_prompt f””” 你是一个任务规划助手。请分析用户的请求并逐步推理出需要执行哪些子任务以及这些子任务之间的逻辑关系。 用户请求“{user_request}” 请按以下步骤思考 1. **理解核心需求**用户这句话里包含了几个独立的意图 2. **分解子任务**将每个意图转化为一个可执行的具体任务例如调用某个API、设置一个提醒。 3. **分析依赖关系**这些任务之间有顺序要求吗哪个任务必须先执行其结果会影响后续任务 4. **制定执行计划**根据以上分析输出一个清晰的 JSON 数组每个元素代表一个任务包含 task_name任务名、action执行动作、depends_on依赖的任务ID没有则填null和 condition执行条件没有则填null。 请先展示你的思考过程然后在最后输出 JSON 数组。 “”” plan_result call_gpt(cot_prompt, model“gpt-4”, max_tokens1500) print(plan_result)预期输出包含思考过程和最终计划思考过程 1. **理解核心需求**用户请求包含三个意图a) 为明天早上8点的会议设置提醒b) 查询明天的天气c) 基于天气结果下雨生成一个带伞的提醒。 2. **分解子任务** - 任务A创建日历事件或闹钟时间为“明天早上8点”标题为“开会”。 - 任务B调用天气查询API地点为用户当前位置或默认城市时间为“明天”。 - 任务C评估任务B的结果如果天气状况包含“雨”则创建一条提醒“明天开会记得带伞”。 3. **分析依赖关系** - 任务B查天气和任务A设提醒可以并行因为它们互不依赖。 - 任务C条件提醒依赖于任务B的结果。必须在任务B完成后根据其输出决定是否执行。 4. **制定执行计划**任务A和B可同时发起任务C等待B。 [ { “task_id”: 1, “task_name”: “设置会议提醒”, “action”: “创建日历事件时间明天 08:00标题‘开会’”, “depends_on”: null, “condition”: null }, { “task_id”: 2, “task_name”: “查询明日天气”, “action”: “调用天气API查询指定位置明天的天气状况”, “depends_on”: null, “condition”: null }, { “task_id”: 3, “task_name”: “生成带伞提醒”, “action”: “创建提醒内容‘明天开会记得带伞’”, “depends_on”: [2], “condition”: “weather_condition includes ‘rain’” } ]这个 CoT 过程将一个模糊的用户指令转化为了一个结构化的、可被 AI Agent 调度引擎直接解析的执行计划。思考过程确保了计划的合理性。4.3 Zero-Shot CoT一种特殊的强大技巧除了上面这种显式要求“逐步思考”的 CoT还有一种更简洁有力的技巧称为Zero-Shot CoT。它的核心是在问题末尾直接加上一句魔法短语“让我们一步一步地思考。”英文“Let‘s think step by step.”研究表明仅添加这句话就能在众多推理基准测试上大幅提升大模型特别是大型模型的性能。它相当于激活了模型的内部推理机制。示例对比# 标准 Zero-Shot prompt1 “如果3台机器3分钟生产3个零件那么100台机器生产100个零件需要多少分钟” answer1 call_gpt(prompt1, temperature0) print(“标准 Zero-Shot:”, answer1) # 可能错误地回答“100分钟” # Zero-Shot CoT prompt2 “如果3台机器3分钟生产3个零件那么100台机器生产100个零件需要多少分钟让我们一步一步地思考。” answer2 call_gpt(prompt2, temperature0) print(“\nZero-Shot CoT:”, answer2)Zero-Shot CoT 可能输出让我们一步一步地思考。 1. 3台机器3分钟生产3个零件意味着1台机器3分钟生产1个零件。 2. 所以1台机器生产1个零件需要3分钟。 3. 那么100台机器同时工作生产1个零件只需要3分钟 / 100台 0.03分钟不对这里逻辑错了。重新思考。 4. 正确理解3台机器3分钟生产3个零件其生产效率是 3零件 / (3台 * 3分钟) 1/3 零件/(台*分钟)。即每台机器每分钟生产1/3个零件。 5. 100台机器每分钟生产 100 * (1/3) 100/3 个零件。 6. 要生产100个零件需要的时间是 100零件 / (100/3 零件/分钟) 3分钟。 因此100台机器生产100个零件需要3分钟。可以看到仅仅添加了“让我们一步一步地思考”这句话模型就从直接给出一个直觉性错误答案转变为展示一个正确的推理过程并得出正确答案。这是提升模型在推理任务上表现的最简单、最有效的方法之一。5. 在 AI Agent 开发中融合 Zero-Shot 与 CoT在真实的 AI Agent 系统中Zero-Shot 和 CoT 并非互斥而是协同工作。一个典型的 Agent 决策循环可能如下意图理解与规划使用 CoTAgent 收到用户请求后使用 CoT 提示分析请求拆解成子任务并规划执行顺序。工具调用与执行使用 Zero-Shot对于每个具体的子任务如“查询天气”、“调用计算器”Agent 使用清晰、格式化的 Zero-Shot 提示来调用相应的工具或 API。结果综合与回答可能使用 CoT将各个子任务的结果汇总可能需要再次使用 CoT 进行逻辑综合最终生成面向用户的自然语言回答。下面是一个简化的模拟示例展示这个流程class SimpleAgent: def __init__(self): self.tools { “calculator”: self._tool_calculator, “weather”: self._tool_weather, “calendar”: self._tool_calendar } def _tool_calculator(self, expression): “”“模拟计算器工具。实际应调用真实API。”“” # 这里简单模拟实际应用需做安全评估和异常处理 try: return eval(expression) # 警告生产环境切勿使用eval处理用户输入 except: return “计算错误” def _tool_weather(self, location): “”“模拟天气查询工具。”“” weather_db {“北京”: “晴25°C”, “上海”: “多云28°C”, “广州”: “雷阵雨30°C”} return weather_db.get(location, “未知地点”) def _tool_calendar(self, event): “”“模拟日历工具。”“” return f“已创建日程‘{event}’” def plan_with_cot(self, user_input): “”“使用 CoT 进行任务规划。”“” planning_prompt f””” 用户说“{user_input}” 请分析用户需要完成哪些事情并规划执行步骤。输出一个简单的 JSON 列表每个元素包含 tool工具名和 params参数。 例如[{{“tool”: “calculator”, “params”: “22”}}, {{“tool”: “weather”, “params”: “北京”}}] 请只输出 JSON。 “”” plan_json_str call_gpt(planning_prompt, temperature0.1, max_tokens500) # 简单解析生产环境需更健壮 import json try: return json.loads(plan_json_str) except: return [] def execute_with_zero_shot(self, plan): “”“使用 Zero-Shot 方式执行规划好的任务。”“” results [] for task in plan: tool_name task.get(“tool”) params task.get(“params”, “”) if tool_name in self.tools: result self.tools[tool_name](params) results.append({“tool”: tool_name, “result”: result}) else: results.append({“tool”: tool_name, “result”: “未知工具”}) return results def run(self, user_input): print(f“用户输入: {user_input}”) print(“\n[Agent CoT 规划中...]”) plan self.plan_with_cot(user_input) print(f“执行计划: {plan}”) print(“\n[Agent 执行任务...]”) execution_results self.execute_with_zero_shot(plan) print(“\n[执行结果汇总:]”) for res in execution_results: print(f“ {res[‘tool’]}: {res[‘result’]}”) # 最后可以再用一个简短的 Zero-Shot 提示来生成对用户的回复 summary_prompt f””” 根据以下原始请求和执行结果生成一句给用户的友好回复。 用户请求{user_input} 执行结果{execution_results} 回复 “”” final_reply call_gpt(summary_prompt, temperature0.7, max_tokens200) print(f“\nAgent 最终回复: {final_reply}”) # 运行示例 agent SimpleAgent() agent.run(“帮我算一下(1527)*3等于多少再看看北京的天气”)这个示例展示了 Agent 如何利用 CoT 进行规划将复杂请求分解为工具调用序列然后利用 Zero-Shot 高效执行每个具体工具任务。这种模式是构建复杂、可靠 Agent 系统的基石。6. 提示词工程常见问题与排查即使掌握了 Zero-Shot 和 CoT在实际应用中仍会遇到各种问题。以下是典型问题及其排查路径。6.1 问题一模型输出不符合格式要求现象要求输出 JSON模型却输出了 Markdown 或纯文本。排查与解决检查指令清晰度是否在提示词开头或结尾明确强调了格式尝试使用“必须”、“严格”、“只输出”等强约束词。使用分隔符用“json”和“”包裹示例明确指示格式。调整温度Temperature将temperature参数调低如设为 0 或 0.1减少随机性使输出更稳定。提供输出示例Few-Shot如果问题持续在提示词中提供一个完整的输出示例。这不再是 Zero-Shot但能有效解决格式问题。6.2 问题二CoT 推理过程冗长或偏离主题现象模型确实在“逐步思考”但步骤过于繁琐或中途跑题。排查与解决优化引导词不要只说“逐步思考”可以给出更具体的思考框架。例如“请按以下步骤推理1. 提取已知条件2. 确定求解目标3. 列出相关公式或逻辑4. 分步计算5. 得出结论。”限制输出长度设置max_tokens参数防止生成过长内容。使用更强的模型GPT-4 在遵循复杂指令和逻辑连贯性上通常优于 GPT-3.5-turbo。后处理截断如果只需要最终答案可以在代码中提取 CoT 输出最后一部分的结论。6.3 问题三模型忽略提示词中的部分约束现象提示词要求“列出3点”模型列出了5点要求“用中文回答”模型用了英文。排查与解决位置很重要将最重要的约束放在提示词的开头或结尾。模型对这两部分的内容更敏感。重复强调对于关键约束可以用不同方式重复说明。系统消息Role如果使用 ChatCompletion API可以利用system角色消息来设定全局约束。例如messages [ {“role”: “system”, “content”: “你是一个严谨的助手必须严格遵守用户的指令。用户要求列出几点你就必须列出几点不能多也不能少。”}, {“role”: “user”, “content”: “列出云计算的三个主要优点。”} ]检查模型版本某些早期或较小规模的模型遵循指令的能力较弱。6.4 问题四在复杂 Agent 流程中提示词失效现象单个提示词测试良好但嵌入到多轮对话或复杂 Agent 逻辑中后模型行为出现偏差。排查与解决检查对话历史确保传递给模型的 messages 列表是正确的没有混杂无关的历史消息导致上下文被污染。隔离测试将出问题的提示词和当时的完整对话历史提取出来单独调用 API 测试看是否是代码逻辑问题。简化上下文如果对话历史很长尝试只保留最近几轮关键对话或使用摘要技术压缩历史。为 Agent 设定明确角色在系统消息中为 Agent 设定一个稳固的角色身份如“你是一个专业的数学解题助手”有助于其在长对话中保持行为一致。7. 最佳实践与扩展方向7.1 Zero-Shot 与 CoT 提示词设计清单在编写提示词前可以对照此清单检查Zero-Shot 提示词检查清单[ ]角色是否明确了模型扮演的角色例如“你是一位资深软件架构师”[ ]任务是否清晰、无歧义地描述了要完成的具体任务[ ]上下文是否提供了完成任务所需的背景信息例如技术栈、业务场景[ ]输入是否明确了输入数据的格式和位置例如“以下是用户查询{query}”[ ]输出是否明确规定了输出的格式、长度、语言等要求例如“输出一个 JSON 对象”、“用中文回答”、“不超过100字”[ ]约束是否有需要特别注意的约束条件例如“不能使用 for 循环”、“必须引用来源”[ ]示例对于特别复杂的格式要求是否考虑加入一个输出示例此时变为 Few-ShotCoT 提示词检查清单[ ]触发词是否包含了引导逐步思考的短语例如“让我们一步一步思考”、“请展示你的推理过程”[ ]思考框架对于复杂问题是否提供了思考步骤的框架或模板[ ]中间输出是否需要模型在思考过程中输出中间变量或判断[ ]最终答案是否明确要求模型在思考后给出一个明确的最终结论[ ]格式分离是否要求模型将“思考过程”和“最终答案”用明显标记如“### 答案”分开便于程序化提取7.2 扩展方向从提示词到智能体Agent系统掌握了基础的 Zero-Shot 和 CoT你可以向更高级的 Agent 架构进发ReAct (Reasoning Acting) 框架结合 CoTReasoning和工具调用Acting让 Agent 在思考下一步该做什么的同时决定调用哪个工具形成“思考-行动-观察”的循环。这是当前构建复杂 Agent 的主流范式。提示词模板化与外部化将常用的高质量提示词如需求分析 CoT、代码审查 Zero-Shot保存为模板文件或数据库记录根据任务动态填充变量。这提升了提示词的可维护性和复用性。提示词链Prompt Chaining将一个复杂任务拆解为多个子任务每个子任务由一个专门的提示词可能是 Zero-Shot 或 CoT驱动前一个提示词的输出作为后一个的输入。这有助于管理复杂任务的上下文长度和逻辑。自我反思与修正Self-Reflection让 Agent 生成答案后再使用一个 CoT 提示词对自己答案的准确性、完整性进行批判性检查并提出修正。这可以显著提升输出的可靠性。7.3 环境与生产建议版本管理像管理代码一样管理你的提示词。使用版本控制系统如 Git来跟踪提示词的迭代和优化。测试与评估为关键提示词建立测试集包含各种边界用例定期运行测试以评估其性能稳定性。监控与日志在生产环境中记录模型输入提示词和输出特别是当输出不符合预期时。这些日志是优化提示词和改进系统的最宝贵材料。成本与延迟CoT 提示词通常更长会消耗更多 tokens增加成本和响应时间。在追求效果和平衡成本之间需要做出权衡。对于简单任务优先使用高效的 Zero-Shot。安全与合规永远不要将未经验证的用户输入直接拼接到提示词中防止提示词注入攻击。对模型输出进行必要的安全检查如内容过滤后再展示给用户。从清晰的 Zero-Shot 指令到引导深度思考的 CoT 提示本质上是与大型语言模型进行有效沟通的艺术。其核心在于理解模型的“思维”模式并通过精心设计的文本来引导它朝着我们期望的方向工作。开始实践的最佳方式就是从手头的一个具体任务出发尝试用不同的提示词策略去解决它观察并分析模型的输出差异逐步积累属于你自己的提示词设计经验。 大模型提示词实战：Zero-Shot与Chain of Thought核心策略解析
在实际的大模型应用开发中我们常常面临一个困境直接向模型提问得到的回答可能过于简略、缺乏逻辑甚至偏离核心意图。尤其是在处理复杂推理、多步骤任务或需要结构化输出的场景时简单的“一问一答”模式显得力不从心。这时提示词工程中的两种核心策略——Zero-Shot 和 Chain of ThoughtCoT——便成为提升模型输出质量和可靠性的关键。它们并非高深的理论而是可以立即应用于项目中的实践技巧能够显著改善大模型的表现有时甚至能让输出的有效信息量直接翻倍。本文旨在为开发者提供一个清晰的实战指南。我们将从零开始解释 Zero-Shot 和 CoT 提示词的核心概念与适用场景然后通过具体的代码示例展示如何在实际项目中设计和应用这两种提示策略。你将学习到如何通过简单的提示词结构调整引导模型进行更深入的思考从而获得更准确、更详尽、更具逻辑性的回答。无论你是正在构建 AI Agent、开发基于大模型的应用程序还是希望在日常工作中更高效地使用 ChatGPT 等工具掌握这些提示词技术都将使你事半功倍。1. 理解 Zero-Shot 与 CoT 提示词从直接回答到引导思考在深入代码之前我们必须先厘清两个核心概念Zero-Shot 和 Chain of Thought (CoT)。它们代表了两种不同层级的模型交互方式。1.1 Zero-Shot 提示基于指令的直接推理Zero-Shot 学习指的是模型在没有针对特定任务进行过显式训练即没有见过该任务的任何示例的情况下仅根据自然语言指令来执行任务。在提示词工程中Zero-Shot 提示通常意味着我们给模型一个清晰、具体的任务描述期望它直接给出答案。通俗理解就像你问一个知识渊博但没做过某件具体事的朋友“如何给自行车换轮胎” 他基于通用知识和逻辑直接告诉你步骤。这就是 Zero-Shot。技术定义模型利用其预训练阶段获得的世界知识和语言模式对给定的新指令进行理解和响应不依赖于任务相关的示例Few-Shot。作用与示例 一个典型的 Zero-Shot 提示可能如下请将以下英文句子翻译成中文“The rapid development of artificial intelligence is reshaping various industries.”模型会直接输出“人工智能的快速发展正在重塑各个行业。”容易误解的地方 很多人认为 Zero-Shot 就是“问得简单”。其实不然它的核心是“无示例”。即使问题很复杂只要不提供参考样例也属于 Zero-Shot 范畴。其效果高度依赖于提示词本身的清晰度和完整性。对于复杂问题单纯的 Zero-Shot 可能无法激发模型的全部推理潜力。1.2 Chain of Thought (CoT) 提示模拟人类的逐步推理Chain of Thought (CoT) 提示是一种引导大模型展示其推理过程的技术。它要求模型在给出最终答案前先一步步地阐述其思考逻辑就像一个人在草稿纸上演算一样。通俗理解同样问“如何给自行车换轮胎”你补充说“请一步一步地思考列出需要的工具然后描述每个步骤的注意事项。” 朋友就会先想“需要扳手、新轮胎…”再一步步说“先松开快拆杆…”。这就是 CoT。技术定义通过在设计提示词时明确要求模型“逐步推理”或展示“思考过程”来解锁模型在复杂推理任务如数学问题、逻辑谜题、多步骤规划上的更强性能。CoT 可以是 Zero-Shot CoT直接要求模型逐步思考也可以是 Few-Shot CoT提供几个包含推理步骤的示例。作用与示例 对于数学问题“小明有5个苹果吃了2个又买了3个现在有几个”Zero-Shot 可能直接输出“6个”。而 CoT 提示会这样设计请逐步推理以下问题 问题小明有5个苹果吃了2个又买了3个现在有几个 让我们一步一步思考模型可能会输出1. 开始时小明有5个苹果。 2. 他吃了2个所以剩下 5 - 2 3个苹果。 3. 他又买了3个所以现在有 3 3 6个苹果。 因此现在有6个苹果。关键价值CoT 不仅让答案更可信因为你能看到推理过程更重要的是对于许多复杂任务展示思考步骤这个行为本身就能显著提高模型得出正确答案的概率。它迫使模型将问题分解减少了“跳跃式”错误。1.3 如何选择Zero-Shot 还是 CoT选择哪种策略取决于任务复杂度、对可解释性的要求以及对输出一致性的需求。策略适用场景优点缺点Zero-Shot1. 简单信息提取、分类、翻译。2. 创意生成如写诗、起名。3. 对响应速度要求高且任务直接。1. 提示词简单交互直接。2. 计算开销小响应快。3. 适合集成到自动化流程中。1. 复杂任务上容易出错或回答肤浅。2. 答案缺乏可解释性难以调试。3. 对提示词措辞非常敏感。CoT1. 数学计算、逻辑推理。2. 多步骤规划如旅行计划、项目拆解。3. 需要验证答案正确性的场景。4. 希望模型输出结构化思考过程。1. 大幅提升复杂任务的准确率。2. 输出具有可解释性便于人工复核。3. 思考过程本身可能包含有价值的信息。1. 提示词更长可能消耗更多 tokens。2. 响应时间相对更长。3. 需要设计如何要求“逐步思考”。在实际的 AI Agent 开发中两者常常结合使用。例如Agent 接收到用户请求后先使用 CoT 提示进行任务规划和分解然后在执行每个子任务时使用 Zero-Shot 提示调用相应的工具或能力。2. 环境准备与基础工具链在开始编写提示词之前我们需要一个能够与大模型交互的环境。这里我们以 OpenAI 的 GPT 系列模型为例使用 Python 的openai库进行演示。其他模型平台如国内的大模型平台的 API 调用方式类似主要区别在于 API 端点和参数。2.1 安装必要的 Python 库首先确保你的 Python 环境建议 3.8并安装openai库。同时我们也会安装python-dotenv来管理密钥。pip install openai python-dotenv2.2 获取并配置 API 密钥访问 OpenAI 平台 (platform.openai.com) 注册并创建 API Key。在项目根目录创建一个名为.env的文件将密钥写入OPENAI_API_KEY你的-api-key-here重要永远不要将.env文件提交到版本控制系统如 Git。确保它在.gitignore中。2.3 创建基础工具函数创建一个 Python 脚本例如prompt_utils.py编写一个通用的模型调用函数。这有助于我们后续集中测试不同的提示词。import os from openai import OpenAI from dotenv import load_dotenv # 加载环境变量 load_dotenv() # 初始化客户端 client OpenAI(api_keyos.getenv(OPENAI_API_KEY)) def call_gpt(prompt, modelgpt-3.5-turbo, temperature0.7, max_tokens1000): 调用 OpenAI ChatCompletion API 的通用函数。 参数: prompt (str): 发送给模型的提示词。 model (str): 使用的模型名称。 temperature (float): 采样温度控制随机性 (0-2)。值越低输出越确定。 max_tokens (int): 生成的最大 token 数。 返回: str: 模型生成的回复内容。 try: response client.chat.completions.create( modelmodel, messages[ {role: user, content: prompt} ], temperaturetemperature, max_tokensmax_tokens ) return response.choices[0].message.content.strip() except Exception as e: print(f调用 API 时出错: {e}) return None # 简单测试连接 if __name__ __main__: test_prompt 请说‘你好世界’ result call_gpt(test_prompt) if result: print(测试成功模型回复, result) else: print(测试失败请检查网络和 API 密钥。)运行这个脚本如果看到“你好世界”的输出说明环境配置成功。3. Zero-Shot 提示词实战从简单到复杂我们将通过几个逐渐复杂的例子展示如何设计有效的 Zero-Shot 提示词。3.1 基础任务信息提取与格式化假设我们需要从一段自由文本中提取公司名、职位和日期并格式化为 JSON。低效的 Zero-Shot 提示从下面文本找信息。 文本张三曾在2020年至2022年间于ABC科技担任高级软件工程师。这种提示过于模糊模型可能回复一句自然语言如“张三在ABC科技做高级软件工程师从2020年到2022年”不符合程序化处理的需求。高效的 Zero-Shot 提示请从以下文本中提取“人物姓名”、“公司名称”、“职位”和“任职起止时间”并以严格的 JSON 格式输出键名分别为name, company, position, tenure。 文本张三曾在2020年至2022年间于ABC科技担任高级软件工程师。 要求 1. 只输出 JSON 对象不要有任何额外解释。 2. 时间格式统一为“YYYY-MM - YYYY-MM”。代码实现def extract_info_zero_shot(text): prompt f 请从以下文本中提取“人物姓名”、“公司名称”、“职位”和“任职起止时间”并以严格的 JSON 格式输出键名分别为name, company, position, tenure。 文本{text} 要求 1. 只输出 JSON 对象不要有任何额外解释。 2. 时间格式统一为“YYYY-MM - YYYY-MM”。 result call_gpt(prompt, temperature0.1) # 低温度保证输出稳定 return result text 李四于2019年3月加入XYZ金融担任数据分析师直至2023年12月离职。 print(extract_info_zero_shot(text))预期输出{name: 李四, company: XYZ金融, position: 数据分析师, tenure: 2019-03 - 2023-12}关键点指令清晰明确告诉模型要做什么提取、输出什么格式JSON、键名是什么。约束明确“只输出 JSON 对象”避免了模型添加多余的自然语言描述。参数调整temperature0.1使输出更确定适合格式化任务。3.2 进阶任务代码生成与解释Zero-Shot 也常用于生成代码片段。关键在于明确需求、输入输出格式和使用的技术栈。提示词设计请编写一个 Python 函数函数名为 find_common_elements。 功能接受两个列表作为输入参数 list1 和 list2返回这两个列表的交集共同元素列表。 要求 1. 返回的列表中元素顺序不限但需去重。 2. 请在函数内部添加清晰的注释。 3. 在函数下方提供一个调用示例展示当 list1 [1, 2, 2, 3], list2 [2, 3, 4, 5] 时的输出。代码调用def generate_code_zero_shot(): prompt 请编写一个 Python 函数函数名为 find_common_elements。 功能接受两个列表作为输入参数 list1 和 list2返回这两个列表的交集共同元素列表。 要求 1. 返回的列表中元素顺序不限但需去重。 2. 请在函数内部添加清晰的注释。 3. 在函数下方提供一个调用示例展示当 list1 [1, 2, 2, 3], list2 [2, 3, 4, 5] 时的输出。 result call_gpt(prompt, modelgpt-4) # 代码生成任务可以使用更强的模型 return result print(generate_code_zero_shot())预期输出示例def find_common_elements(list1, list2): 找出两个列表的交集共同元素。 参数: list1 (list): 第一个列表 list2 (list): 第二个列表 返回: list: 包含两个列表共同元素的列表已去重 # 使用集合set的交集操作来高效地找到共同元素并自动去重 common_set set(list1) set(list2) # 将集合转换回列表并返回 return list(common_set) # 调用示例 list1 [1, 2, 2, 3] list2 [2, 3, 4, 5] result find_common_elements(list1, list2) print(f列表 {list1} 和 {list2} 的交集是{result}) # 输出列表 [1, 2, 2, 3] 和 [2, 3, 4, 5] 的交集是[2, 3]为什么有效提示词定义了函数签名、功能、非功能性要求注释、示例引导模型生成符合工程规范的代码。3.3 Zero-Shot 的常见陷阱与优化即使指令清晰Zero-Shot 也可能出问题。以下是常见陷阱及优化方法陷阱1模型“自由发挥”输出格式不符。现象要求输出 JSON模型却输出 Markdown 表格或自然语言。优化在提示词中强化格式指令并使用“分隔符”明确指示范围。例如请将以下文本摘要为不超过50字。你的回答必须严格按以下格式输出 【摘要】[这里填写摘要内容] 原文{text}陷阱2对于模糊或多义指令模型选择错误理解。现象提问“这个功能怎么实现”模型可能回答技术A而你期望技术B。优化增加上下文限定。例如“在 Python Django 框架下如何实现用户上传图片的功能请给出核心视图和模型代码。”陷阱3模型忽略指令中的细节约束。现象要求“列出3个优点”模型列出了5个。优化将关键约束放在提示词开头或结尾并加粗虽然模型不识别 Markdown但能感知强调。例如“必须只列出3个不能多也不能少。”4. Chain of Thought (CoT) 提示词实战解锁复杂推理当任务涉及计算、逻辑判断或多步骤决策时CoT 提示的价值就凸显出来。我们通过数学问题、逻辑推理和商业分析三个场景来实践。4.1 基础 CoT解决数学应用题我们从一个经典的数学问题开始对比 Zero-Shot 和 CoT 的效果。Zero-Shot 尝试可能失败problem “一个水池有一个进水口和一个出水口。单独打开进水口6小时可以注满水池。单独打开出水口8小时可以放完整池水。如果同时打开进水口和出水口需要多少小时可以注满水池” prompt_zs f”请解决问题{problem}” result_zs call_gpt(prompt_zs, temperature0) print(“Zero-Shot 回答”, result_zs)模型可能直接给出一个错误答案如“24小时”因为它没有展示计算过程可能混淆了效率概念。CoT 提示实现def solve_math_problem_cot(problem): prompt f”””请逐步推理解决以下数学问题。在给出最终答案前请先展示你的完整计算步骤和思考过程。 问题{problem} 让我们一步一步思考””” result call_gpt(prompt, model“gpt-4”, temperature0) # 使用 GPT-4 以获得更好的推理能力 return result result_cot solve_math_problem_cot(problem) print(“CoT 回答\n”, result_cot)预期输出示例让我们一步一步思考 1. 进水口效率6小时注满所以每小时进水占水池的 1/6。 2. 出水口效率8小时放空所以每小时出水占水池的 1/8。 3. 同时打开时每小时净进水量为进水效率减去出水效率1/6 - 1/8 (4/24 - 3/24) 1/24。 4. 这意味着每小时水池能注入 1/24 的水。 5. 要注满整个水池即注入量为1所需时间为 1 ÷ (1/24) 24 小时。 因此同时打开进水口和出水口需要 24 小时可以注满水池。通过强制模型展示步骤我们不仅得到了答案更获得了答案的可信度验证。即使最终答案数字相同CoT 过程也证明了其正确性。4.2 进阶 CoT多条件逻辑决策假设我们要开发一个 AI Agent根据用户输入的需求决定调用哪个内部工具如“查天气”、“设闹钟”、“算数学”。任务分析用户请求“我明天早上8点要开会顺便看看天气怎么样如果下雨记得提醒我带伞”并输出一个结构化的执行计划。CoT 提示设计user_request “我明天早上8点要开会顺便看看天气怎么样如果下雨记得提醒我带伞。” cot_prompt f””” 你是一个任务规划助手。请分析用户的请求并逐步推理出需要执行哪些子任务以及这些子任务之间的逻辑关系。 用户请求“{user_request}” 请按以下步骤思考 1. **理解核心需求**用户这句话里包含了几个独立的意图 2. **分解子任务**将每个意图转化为一个可执行的具体任务例如调用某个API、设置一个提醒。 3. **分析依赖关系**这些任务之间有顺序要求吗哪个任务必须先执行其结果会影响后续任务 4. **制定执行计划**根据以上分析输出一个清晰的 JSON 数组每个元素代表一个任务包含 task_name任务名、action执行动作、depends_on依赖的任务ID没有则填null和 condition执行条件没有则填null。 请先展示你的思考过程然后在最后输出 JSON 数组。 “”” plan_result call_gpt(cot_prompt, model“gpt-4”, max_tokens1500) print(plan_result)预期输出包含思考过程和最终计划思考过程 1. **理解核心需求**用户请求包含三个意图a) 为明天早上8点的会议设置提醒b) 查询明天的天气c) 基于天气结果下雨生成一个带伞的提醒。 2. **分解子任务** - 任务A创建日历事件或闹钟时间为“明天早上8点”标题为“开会”。 - 任务B调用天气查询API地点为用户当前位置或默认城市时间为“明天”。 - 任务C评估任务B的结果如果天气状况包含“雨”则创建一条提醒“明天开会记得带伞”。 3. **分析依赖关系** - 任务B查天气和任务A设提醒可以并行因为它们互不依赖。 - 任务C条件提醒依赖于任务B的结果。必须在任务B完成后根据其输出决定是否执行。 4. **制定执行计划**任务A和B可同时发起任务C等待B。 [ { “task_id”: 1, “task_name”: “设置会议提醒”, “action”: “创建日历事件时间明天 08:00标题‘开会’”, “depends_on”: null, “condition”: null }, { “task_id”: 2, “task_name”: “查询明日天气”, “action”: “调用天气API查询指定位置明天的天气状况”, “depends_on”: null, “condition”: null }, { “task_id”: 3, “task_name”: “生成带伞提醒”, “action”: “创建提醒内容‘明天开会记得带伞’”, “depends_on”: [2], “condition”: “weather_condition includes ‘rain’” } ]这个 CoT 过程将一个模糊的用户指令转化为了一个结构化的、可被 AI Agent 调度引擎直接解析的执行计划。思考过程确保了计划的合理性。4.3 Zero-Shot CoT一种特殊的强大技巧除了上面这种显式要求“逐步思考”的 CoT还有一种更简洁有力的技巧称为Zero-Shot CoT。它的核心是在问题末尾直接加上一句魔法短语“让我们一步一步地思考。”英文“Let‘s think step by step.”研究表明仅添加这句话就能在众多推理基准测试上大幅提升大模型特别是大型模型的性能。它相当于激活了模型的内部推理机制。示例对比# 标准 Zero-Shot prompt1 “如果3台机器3分钟生产3个零件那么100台机器生产100个零件需要多少分钟” answer1 call_gpt(prompt1, temperature0) print(“标准 Zero-Shot:”, answer1) # 可能错误地回答“100分钟” # Zero-Shot CoT prompt2 “如果3台机器3分钟生产3个零件那么100台机器生产100个零件需要多少分钟让我们一步一步地思考。” answer2 call_gpt(prompt2, temperature0) print(“\nZero-Shot CoT:”, answer2)Zero-Shot CoT 可能输出让我们一步一步地思考。 1. 3台机器3分钟生产3个零件意味着1台机器3分钟生产1个零件。 2. 所以1台机器生产1个零件需要3分钟。 3. 那么100台机器同时工作生产1个零件只需要3分钟 / 100台 0.03分钟不对这里逻辑错了。重新思考。 4. 正确理解3台机器3分钟生产3个零件其生产效率是 3零件 / (3台 * 3分钟) 1/3 零件/(台*分钟)。即每台机器每分钟生产1/3个零件。 5. 100台机器每分钟生产 100 * (1/3) 100/3 个零件。 6. 要生产100个零件需要的时间是 100零件 / (100/3 零件/分钟) 3分钟。 因此100台机器生产100个零件需要3分钟。可以看到仅仅添加了“让我们一步一步地思考”这句话模型就从直接给出一个直觉性错误答案转变为展示一个正确的推理过程并得出正确答案。这是提升模型在推理任务上表现的最简单、最有效的方法之一。5. 在 AI Agent 开发中融合 Zero-Shot 与 CoT在真实的 AI Agent 系统中Zero-Shot 和 CoT 并非互斥而是协同工作。一个典型的 Agent 决策循环可能如下意图理解与规划使用 CoTAgent 收到用户请求后使用 CoT 提示分析请求拆解成子任务并规划执行顺序。工具调用与执行使用 Zero-Shot对于每个具体的子任务如“查询天气”、“调用计算器”Agent 使用清晰、格式化的 Zero-Shot 提示来调用相应的工具或 API。结果综合与回答可能使用 CoT将各个子任务的结果汇总可能需要再次使用 CoT 进行逻辑综合最终生成面向用户的自然语言回答。下面是一个简化的模拟示例展示这个流程class SimpleAgent: def __init__(self): self.tools { “calculator”: self._tool_calculator, “weather”: self._tool_weather, “calendar”: self._tool_calendar } def _tool_calculator(self, expression): “”“模拟计算器工具。实际应调用真实API。”“” # 这里简单模拟实际应用需做安全评估和异常处理 try: return eval(expression) # 警告生产环境切勿使用eval处理用户输入 except: return “计算错误” def _tool_weather(self, location): “”“模拟天气查询工具。”“” weather_db {“北京”: “晴25°C”, “上海”: “多云28°C”, “广州”: “雷阵雨30°C”} return weather_db.get(location, “未知地点”) def _tool_calendar(self, event): “”“模拟日历工具。”“” return f“已创建日程‘{event}’” def plan_with_cot(self, user_input): “”“使用 CoT 进行任务规划。”“” planning_prompt f””” 用户说“{user_input}” 请分析用户需要完成哪些事情并规划执行步骤。输出一个简单的 JSON 列表每个元素包含 tool工具名和 params参数。 例如[{{“tool”: “calculator”, “params”: “22”}}, {{“tool”: “weather”, “params”: “北京”}}] 请只输出 JSON。 “”” plan_json_str call_gpt(planning_prompt, temperature0.1, max_tokens500) # 简单解析生产环境需更健壮 import json try: return json.loads(plan_json_str) except: return [] def execute_with_zero_shot(self, plan): “”“使用 Zero-Shot 方式执行规划好的任务。”“” results [] for task in plan: tool_name task.get(“tool”) params task.get(“params”, “”) if tool_name in self.tools: result self.tools[tool_name](params) results.append({“tool”: tool_name, “result”: result}) else: results.append({“tool”: tool_name, “result”: “未知工具”}) return results def run(self, user_input): print(f“用户输入: {user_input}”) print(“\n[Agent CoT 规划中...]”) plan self.plan_with_cot(user_input) print(f“执行计划: {plan}”) print(“\n[Agent 执行任务...]”) execution_results self.execute_with_zero_shot(plan) print(“\n[执行结果汇总:]”) for res in execution_results: print(f“ {res[‘tool’]}: {res[‘result’]}”) # 最后可以再用一个简短的 Zero-Shot 提示来生成对用户的回复 summary_prompt f””” 根据以下原始请求和执行结果生成一句给用户的友好回复。 用户请求{user_input} 执行结果{execution_results} 回复 “”” final_reply call_gpt(summary_prompt, temperature0.7, max_tokens200) print(f“\nAgent 最终回复: {final_reply}”) # 运行示例 agent SimpleAgent() agent.run(“帮我算一下(1527)*3等于多少再看看北京的天气”)这个示例展示了 Agent 如何利用 CoT 进行规划将复杂请求分解为工具调用序列然后利用 Zero-Shot 高效执行每个具体工具任务。这种模式是构建复杂、可靠 Agent 系统的基石。6. 提示词工程常见问题与排查即使掌握了 Zero-Shot 和 CoT在实际应用中仍会遇到各种问题。以下是典型问题及其排查路径。6.1 问题一模型输出不符合格式要求现象要求输出 JSON模型却输出了 Markdown 或纯文本。排查与解决检查指令清晰度是否在提示词开头或结尾明确强调了格式尝试使用“必须”、“严格”、“只输出”等强约束词。使用分隔符用“json”和“”包裹示例明确指示格式。调整温度Temperature将temperature参数调低如设为 0 或 0.1减少随机性使输出更稳定。提供输出示例Few-Shot如果问题持续在提示词中提供一个完整的输出示例。这不再是 Zero-Shot但能有效解决格式问题。6.2 问题二CoT 推理过程冗长或偏离主题现象模型确实在“逐步思考”但步骤过于繁琐或中途跑题。排查与解决优化引导词不要只说“逐步思考”可以给出更具体的思考框架。例如“请按以下步骤推理1. 提取已知条件2. 确定求解目标3. 列出相关公式或逻辑4. 分步计算5. 得出结论。”限制输出长度设置max_tokens参数防止生成过长内容。使用更强的模型GPT-4 在遵循复杂指令和逻辑连贯性上通常优于 GPT-3.5-turbo。后处理截断如果只需要最终答案可以在代码中提取 CoT 输出最后一部分的结论。6.3 问题三模型忽略提示词中的部分约束现象提示词要求“列出3点”模型列出了5点要求“用中文回答”模型用了英文。排查与解决位置很重要将最重要的约束放在提示词的开头或结尾。模型对这两部分的内容更敏感。重复强调对于关键约束可以用不同方式重复说明。系统消息Role如果使用 ChatCompletion API可以利用system角色消息来设定全局约束。例如messages [ {“role”: “system”, “content”: “你是一个严谨的助手必须严格遵守用户的指令。用户要求列出几点你就必须列出几点不能多也不能少。”}, {“role”: “user”, “content”: “列出云计算的三个主要优点。”} ]检查模型版本某些早期或较小规模的模型遵循指令的能力较弱。6.4 问题四在复杂 Agent 流程中提示词失效现象单个提示词测试良好但嵌入到多轮对话或复杂 Agent 逻辑中后模型行为出现偏差。排查与解决检查对话历史确保传递给模型的 messages 列表是正确的没有混杂无关的历史消息导致上下文被污染。隔离测试将出问题的提示词和当时的完整对话历史提取出来单独调用 API 测试看是否是代码逻辑问题。简化上下文如果对话历史很长尝试只保留最近几轮关键对话或使用摘要技术压缩历史。为 Agent 设定明确角色在系统消息中为 Agent 设定一个稳固的角色身份如“你是一个专业的数学解题助手”有助于其在长对话中保持行为一致。7. 最佳实践与扩展方向7.1 Zero-Shot 与 CoT 提示词设计清单在编写提示词前可以对照此清单检查Zero-Shot 提示词检查清单[ ]角色是否明确了模型扮演的角色例如“你是一位资深软件架构师”[ ]任务是否清晰、无歧义地描述了要完成的具体任务[ ]上下文是否提供了完成任务所需的背景信息例如技术栈、业务场景[ ]输入是否明确了输入数据的格式和位置例如“以下是用户查询{query}”[ ]输出是否明确规定了输出的格式、长度、语言等要求例如“输出一个 JSON 对象”、“用中文回答”、“不超过100字”[ ]约束是否有需要特别注意的约束条件例如“不能使用 for 循环”、“必须引用来源”[ ]示例对于特别复杂的格式要求是否考虑加入一个输出示例此时变为 Few-ShotCoT 提示词检查清单[ ]触发词是否包含了引导逐步思考的短语例如“让我们一步一步思考”、“请展示你的推理过程”[ ]思考框架对于复杂问题是否提供了思考步骤的框架或模板[ ]中间输出是否需要模型在思考过程中输出中间变量或判断[ ]最终答案是否明确要求模型在思考后给出一个明确的最终结论[ ]格式分离是否要求模型将“思考过程”和“最终答案”用明显标记如“### 答案”分开便于程序化提取7.2 扩展方向从提示词到智能体Agent系统掌握了基础的 Zero-Shot 和 CoT你可以向更高级的 Agent 架构进发ReAct (Reasoning Acting) 框架结合 CoTReasoning和工具调用Acting让 Agent 在思考下一步该做什么的同时决定调用哪个工具形成“思考-行动-观察”的循环。这是当前构建复杂 Agent 的主流范式。提示词模板化与外部化将常用的高质量提示词如需求分析 CoT、代码审查 Zero-Shot保存为模板文件或数据库记录根据任务动态填充变量。这提升了提示词的可维护性和复用性。提示词链Prompt Chaining将一个复杂任务拆解为多个子任务每个子任务由一个专门的提示词可能是 Zero-Shot 或 CoT驱动前一个提示词的输出作为后一个的输入。这有助于管理复杂任务的上下文长度和逻辑。自我反思与修正Self-Reflection让 Agent 生成答案后再使用一个 CoT 提示词对自己答案的准确性、完整性进行批判性检查并提出修正。这可以显著提升输出的可靠性。7.3 环境与生产建议版本管理像管理代码一样管理你的提示词。使用版本控制系统如 Git来跟踪提示词的迭代和优化。测试与评估为关键提示词建立测试集包含各种边界用例定期运行测试以评估其性能稳定性。监控与日志在生产环境中记录模型输入提示词和输出特别是当输出不符合预期时。这些日志是优化提示词和改进系统的最宝贵材料。成本与延迟CoT 提示词通常更长会消耗更多 tokens增加成本和响应时间。在追求效果和平衡成本之间需要做出权衡。对于简单任务优先使用高效的 Zero-Shot。安全与合规永远不要将未经验证的用户输入直接拼接到提示词中防止提示词注入攻击。对模型输出进行必要的安全检查如内容过滤后再展示给用户。从清晰的 Zero-Shot 指令到引导深度思考的 CoT 提示本质上是与大型语言模型进行有效沟通的艺术。其核心在于理解模型的“思维”模式并通过精心设计的文本来引导它朝着我们期望的方向工作。开始实践的最佳方式就是从手头的一个具体任务出发尝试用不同的提示词策略去解决它观察并分析模型的输出差异逐步积累属于你自己的提示词设计经验。