在AI大模型应用开发中你是否遇到过这样的困扰精心构思的提问换来的却是模型答非所问、逻辑混乱或信息不全的回复或者看着别人用简单的指令就能让AI生成结构清晰、内容丰富的答案而自己的尝试却总是效果不佳这背后往往不是模型能力的问题而是提示词Prompt的功力深浅。提示词工程作为连接人类意图与AI能力的桥梁已成为开发者、产品经理乃至普通用户必须掌握的核心技能。本文将从零开始系统性地拆解提示词的写作技巧与优化调试全流程并通过“旅游景点推理”和“人岗匹配逻辑推理”两个实战案例手把手带你掌握如何设计出高效、精准的提示词真正释放大模型的潜力。无论你是刚接触AI应用开发的新手还是希望提升提示词设计效率的进阶开发者本文都将提供一套可复现、可落地的完整方法论。1. 提示词Prompt的核心概念与价值在深入技巧之前我们首先要理解什么是提示词以及它为何如此重要。1.1 什么是提示词Prompt简单来说提示词就是你与大型语言模型LLM进行对话时输入的文本指令或问题。它是你向模型传达任务需求、背景信息、格式要求以及期望输出风格的唯一渠道。模型根据你的提示词结合其内部的海量知识生成相应的回复。一个常见的误解是将提示词简单等同于“提问”。实际上一个优秀的提示词更像是一份给AI的“工作任务书”或“产品需求文档PRD”它需要清晰、无歧义地定义任务目标、上下文、约束条件和交付标准。1.2 为什么提示词如此关键大模型本身是一个拥有巨大潜力的“通才”但它并不知道你具体想让它做什么。提示词的质量直接决定了模型潜力的发挥程度。控制输出质量与相关性模糊的提示词会导致模型自由发挥可能产生无关、冗余或错误的信息。清晰的提示词能将模型的注意力聚焦在特定领域和任务上。引导复杂推理与逻辑对于需要多步推理、分析或决策的任务如本文的案例结构化的提示词可以引导模型遵循特定的思维链条避免逻辑跳跃。标准化输出格式在应用开发中我们通常需要模型返回结构化的数据如JSON、列表以便程序后续处理。通过提示词约束输出格式可以极大简化数据解析的复杂度。提升开发效率与成本精心设计的提示词往往能用更少的交互轮次得到更准确的结果减少了调试时间和API调用次数从而间接降低了使用成本。1.3 提示词工程的应用场景提示词工程几乎贯穿所有LLM应用场景内容生成撰写文章、邮件、脚本、广告文案。信息提取与总结从长文档中提取关键信息、生成摘要。代码辅助解释代码、生成代码片段、调试、重构。复杂问题求解数学计算、逻辑推理、策略分析。智能体Agent构建为智能体定义角色、能力、工具使用规则和工作流程。数据转换将自然语言描述转换为SQL查询、JSON数据或正则表达式。理解了提示词的基础价值我们就可以开始搭建一个有效的提示词了。一个被广泛认可的高质量提示词通常包含以下几个核心要素。2. 高质量提示词的通用结构CRISPE框架与实践虽然提示词设计没有绝对固定的公式但业界总结出了一些高效的框架如CRISPE框架由Matt Nigh提出它为我们提供了一个结构化的思考路径。CRISPE代表Capacity and Role (能力与角色) 你希望AI扮演什么角色例如资深旅游规划师、人力资源专家Result (结果) 你期望的最终输出是什么例如一个包含景点、理由和预算的JSON对象Instructions (指令) AI需要遵循的具体步骤和规则是什么Steps (步骤) 拆解任务为更小的、可顺序执行的子步骤。Parameters (参数) 对输出的格式、长度、风格等限制条件。Examples (示例) 提供输入输出的例子进行少样本学习Few-Shot Learning。下面我们用一个简单的例子来具象化这个框架。示例生成一份会议纪要糟糕的提示词“总结一下今天的会议。”应用CRISPE框架优化后的提示词你是一名专业的会议秘书擅长从杂乱对话中提取关键决策和行动项。 你的任务是根据提供的会议转录文本生成一份结构清晰、 actionable 的会议纪要。 请按照以下步骤操作 1. 首先通读全文识别会议主题、参与人员和日期。 2. 然后提取讨论中的所有关键议题。 3. 对于每个议题总结达成的共识或做出的决策。 4. 最后列出所有明确的行动项Action Items包括负责人Owner和截止日期Deadline。 请确保你的输出格式严格遵循以下模板 --- **会议主题** [主题] **日期** [日期] **参会人** [名单] **一、关键议题与决策** 1. [议题1]: [决策摘要] 2. [议题2]: [决策摘要] ... **二、行动项Action Items** - [任务描述] | 负责人: [姓名] | 截止日: [日期] - [任务描述] | 负责人: [姓名] | 截止日: [日期] --- 以下是一个例子 输入文本“小王说我们下季度重点推A产品小李负责市场材料周五前给初稿。老张认为定价可以再调研下周一会给出报告。” 输出 --- **会议主题** 下季度产品规划会 **日期** 2023-10-27 **参会人** 小王小李老张 **一、关键议题与决策** 1. 产品重点 确定下季度重点推广A产品。 2. 定价策略 认为当前定价需进一步调研暂未最终决定。 **二、行动项Action Items** - 完成A产品市场推广材料初稿 | 负责人: 小李 | 截止日: 2023-10-29周五 - 提交A产品定价调研报告 | 负责人: 老张 | 截止日: 2023-10-30下周一 --- 现在请为以下会议转录文本生成纪要[此处插入真实的会议文本]通过对比可以看出结构化的提示词极大地提升了输出结果的确定性、完整性和可用性。在实际开发中我们通常会将这个结构固化成一个可复用的“提示词模板”。3. 环境准备与工具选择在开始实战前我们需要准备好实验环境。本文的示例将使用 OpenAI 的 GPT 系列模型如 gpt-3.5-turbo, gpt-4的API进行演示因为其具有广泛的可用性和稳定性。你也可以使用其他兼容 OpenAI API 的模型或本地部署的模型如通义千问、DeepSeek、GLM等只需调整API端点即可。3.1 基础环境准备Python环境 确保安装 Python 3.8 及以上版本。推荐使用虚拟环境venv或conda管理依赖。安装必要库 我们将使用openai这个官方库来调用API。pip install openai获取API密钥 访问 OpenAI 平台 (platform.openai.com) 注册并获取你的 API Key。请妥善保管此密钥不要直接提交到代码仓库。3.2 项目结构与初始化创建一个新的项目目录并初始化你的环境变量和基础代码。# 文件config.py # 用于管理配置避免密钥硬编码 import os from dotenv import load_dotenv load_dotenv() # 从 .env 文件加载环境变量 class Config: OPENAI_API_KEY os.getenv(OPENAI_API_KEY) OPENAI_BASE_URL os.getenv(OPENAI_BASE_URL, https://api.openai.com/v1) # 默认为官方可替换为其他兼容端点 MODEL_NAME os.getenv(MODEL_NAME, gpt-3.5-turbo) # 默认使用 3.5-turbo可根据需要改为 gpt-4 等# 文件.env (请勿提交至版本控制系统) OPENAI_API_KEYsk-your-actual-api-key-here # OPENAI_BASE_URLhttps://api.xxx.com/v1 # 如果使用第三方代理或本地模型可修改此项 # MODEL_NAMEgpt-4# 文件llm_client.py # 封装一个简单的LLM调用客户端 import openai from config import Config openai.api_key Config.OPENAI_API_KEY openai.base_url Config.OPENAI_BASE_URL def get_completion(prompt, modelConfig.MODEL_NAME, temperature0.7, max_tokens1000): 调用ChatCompletion API获取模型回复。 Args: prompt (str): 完整的提示词。 model (str): 模型名称。 temperature (float): 创造性0-2之间越高越随机。 max_tokens (int): 生成的最大token数。 Returns: str: 模型的回复内容。 try: response openai.chat.completions.create( modelmodel, messages[ {role: user, content: prompt} ], temperaturetemperature, max_tokensmax_tokens ) return response.choices[0].message.content except Exception as e: print(f调用API时发生错误: {e}) return None现在我们已经搭建好了最简化的实验环境。接下来我们将进入核心环节通过两个实战案例深入演练提示词的设计、迭代与优化过程。4. 实战案例一旅游景点推理与推荐系统场景用户提供一些模糊的、非结构化的旅行偏好描述我们需要让AI推理出用户可能喜欢的景点类型并生成具体的推荐列表。4.1 需求分析与提示词初版设计假设用户输入是“我下个月想去个暖和点的地方喜欢有历史感的小镇不要太商业化预算中等大概玩3-5天。”我们的目标输出是一个结构化的推荐方案。根据CRISPE框架设计第一版提示词# 文件scenario_travel_v1.py prompt_v1 帮我推荐一些旅游地点。 用户说{user_input} user_input 我下个月想去个暖和点的地方喜欢有历史感的小镇不要太商业化预算中等大概玩3-5天。 full_prompt prompt_v1.format(user_inputuser_input) response get_completion(full_prompt) print(第一版提示词回复) print(response)运行结果可能类似可以考虑去云南的大理古城那里气候温暖古城很有历史韵味商业化程度相对丽江低一些。或者浙江的乌镇、西塘江南水乡风格历史感浓厚但周末可能人比较多。国外的话可以考虑泰国的清迈古城氛围很好消费也不高。问题分析回复是开放式的文本虽然给出了建议但缺乏结构信息点如具体匹配哪些用户需求、预算估算、行程安排分散不利于程序化处理或用户清晰对比。4.2 提示词优化增加角色、结构化输出与推理链我们进行优化明确AI的角色要求其先推理再推荐并输出JSON格式。# 文件scenario_travel_v2.py prompt_v2 你是一名资深的旅行规划专家擅长根据用户模糊的描述精准挖掘其深层需求。 请遵循以下步骤为用户提供旅行推荐 1. **需求解析** 仔细分析用户的原始描述提取出关于“气候”、“偏好类型”、“商业化程度”、“预算”、“旅行时长”等维度的明确需求点。 2. **景点推理** 基于提取的需求点推理出符合所有条件的景点类型和大致地理区域。 3. **具体推荐** 给出2-3个具体的景点或目的地推荐。对于每个推荐必须说明 - 推荐名称 - 推荐理由需逐一对应步骤1中提取的需求点 - 大致预算范围按用户“中等预算”和天数估算 - 一个简单的3-5天行程亮点建议 请将最终输出组织成一个JSON对象包含以下字段 - “extracted_requirements”: 一个对象包含从用户描述中解析出的各个需求维度及其值。 - “reasoning”: 一段文字描述你从需求到景点类型的推理过程。 - “recommendations”: 一个数组每个元素是一个推荐对象包含 “name”, “reasons”, “budget_estimate”, “itinerary_highlights” 字段。 用户描述{user_input} user_input 我下个月想去个暖和点的地方喜欢有历史感的小镇不要太商业化预算中等大概玩3-5天。 full_prompt prompt_v2.format(user_inputuser_input) response get_completion(full_prompt, temperature0.3) # 降低temperature使输出更确定 print(第二版结构化提示词回复) print(response)优化后的运行结果示例{ extracted_requirements: { climate: 暖和, preference: 有历史感的小镇, commercialization: 低不要太商业化, budget: 中等, duration: 3-5天 }, reasoning: 用户核心需求是‘温暖’、‘历史小镇’和‘低商业化’。‘温暖’将目的地限定在中国南方、东南亚或南欧等地区。‘历史小镇’排除了纯自然风光和现代都市。‘低商业化’进一步排除了过度开发的知名古镇。结合‘中等预算’和‘3-5天’适合选择交通便利、住宿选择多、无需长途跋涉的国内外目的地。, recommendations: [ { name: 安徽黟县宏村及周边古村落, reasons: 1. 气候春季下个月皖南气候温和宜人。2. 历史感徽派建筑古村落世界文化遗产历史底蕴深厚。3. 商业化相比周庄、乌镇宏村、西递等商业化程度较低更原生态。4. 预算国内游交通住宿餐饮总体属于中等消费。5. 时长3-5天足够游览宏村、西递、南屏等2-3个核心村落。, budget_estimate: 人均2000-3500元人民币含交通、住宿、门票、餐饮, itinerary_highlights: Day1: 抵达黄山北站乘车至黟县入住宏村民宿夜游月沼。Day2: 深度游览宏村下午前往西递。Day3: 探访南屏或屏山古村体验徽州文化。Day4-5: 可选爬黄山或返程。 }, { name: 泰国清迈古城及周边, reasons: 1. 气候泰国北部冬季凉爽但下个月仍属温暖舒适季。2. 历史感兰纳王朝古都古城内寺庙林立如契迪龙寺历史氛围浓郁。3. 商业化古城区域虽为旅游区但仍有大量宁静巷弄和本地生活气息周边村落更原始。4. 预算东南亚旅行性价比高中等预算可覆盖。5. 时长3-5天可充分游览古城、素贴山、夜间动物园等。, budget_estimate: 人均3000-5000元人民币含国际机票、当地消费, itinerary_highlights: Day1: 抵达清迈入住古城内酒店漫步古城寺庙。Day2: 上午素贴山双龙寺下午宁曼路闲逛。Day3: 参加烹饪课程或大象保护营一日游。Day4: 清莱白庙黑庙一日游较赶或放松享受按摩、夜市。Day5: 购物返程。 } ] }效果对比第二版提示词的输出发生了质的飞跃。它不再是随意的文本而是包含了清晰的推理过程、结构化的需求提取和标准化的推荐信息。这种JSON格式的输出可以被前端应用直接解析和渲染极大提升了开发效率。4.3 进阶优化引入外部知识Few-Shot与风格控制有时仅靠指令可能无法让模型完全理解我们想要的“风格”或“深度”。这时可以提供一两个示例Few-Shot Learning。假设我们希望推荐理由更简洁行程亮点用“标签”形式呈现。# 文件scenario_travel_v3.py prompt_v3 你是一名资深的旅行规划专家。请根据用户描述输出结构化的旅行推荐JSON。 请参考以下示例的格式和风格 示例输入 “我想带孩子6岁暑假出去玩要凉快有自然风光能玩水设施安全一周左右。” 示例输出 { “extracted_requirements”: {“season”: “暑假”, “group”: “亲子6岁”, “climate”: “凉快”, “preference”: “自然风光玩水”, “safety”: “设施安全”, “duration”: “7天”}, “reasoning”: “亲子、夏季、避暑、亲水是核心需求。需选择气候凉爽、有成熟亲子水上项目、安全设施完善的山区或海滨度假区。”, “recommendations”: [ { “name”: “贵州黔东南荔波小七孔及周边” “reasons”: “夏季凉爽、喀斯特山水、亲子徒步、水上森林项目安全有趣” “budget_estimate”: “人均4000-6000元” “itinerary_tags”: [“避暑胜地”, “亲子徒步”, “水上森林”, “民族村寨”] } ] } 现在请处理新的用户请求。 用户描述{user_input} 请严格按照上述示例的JSON格式输出推荐理由reasons请用简短短语概括行程亮点请用标签itinerary_tags数组表示。 user_input 我下个月想去个暖和点的地方喜欢有历史感的小镇不要太商业化预算中等大概玩3-5天。 full_prompt prompt_v3.format(user_inputuser_input) response get_completion(full_prompt, temperature0.1) # 更低的温度确保格式严格遵循示例 print(第三版Few-Shot示例提示词回复) print(response)通过提供示例我们能够更精准地“训练”模型使其输出的格式、语言风格和详细程度都更符合我们的预期。这是提示词工程中非常强大的技巧。5. 实战案例二人岗匹配逻辑推理场景在招聘或内部推荐系统中我们需要根据一份职位描述JD和一份候选人简历CV让AI进行初步的逻辑匹配给出匹配度分析和具体理由。5.1 构建基础匹配提示词这是一个典型的比较-分析-推理任务。初版提示词可能很简单# 文件scenario_job_v1.py jd 职位高级Python后端开发工程师 职责 - 负责公司核心业务系统的后端API设计与开发。 - 参与系统架构设计保证高并发、高可用性。 - 编写高质量、可维护的代码并进行单元测试。 - 与前端、产品、测试团队协作确保项目顺利交付。 要求 - 计算机相关专业本科及以上学历5年以上Python开发经验。 - 精通 Django/Flask/FastAPI 等至少一种Web框架。 - 熟悉 MySQL/PostgreSQL 数据库有性能优化经验。 - 熟悉 Redis、Kafka、Elasticsearch 等中间件。 - 有微服务架构和容器化Docker/K8s经验者优先。 - 良好的沟通能力和团队协作精神。 cv 张三男30岁 教育背景某大学软件工程硕士 工作经历 - A公司2019-至今 高级软件工程师 - 使用 Django 开发电商平台后端日均处理订单100万。 - 主导了从单体架构到微服务基于K8s的拆分项目。 - 使用 PostgreSQL 作为主数据库并设计了读写分离和缓存策略Redis。 - 使用 Kafka 处理用户行为日志异步流。 - B公司2016-2019 软件工程师 - 参与 Flask 框架的金融数据分析平台开发。 技能 - 编程语言Python精通 Java熟悉 - Web框架Django5年 Flask2年 FastAPI1年 - 数据库PostgreSQL精通 MySQL熟练 Redis精通 - 中间件Kafka熟练 Elasticsearch了解 - 运维Docker熟练 Kubernetes熟练 AWS了解 - 其他Git Linux 单元测试pytest prompt_v1 f 请分析以下职位描述JD和候选人简历CV判断该候选人是否适合这个职位。 JD {jd} CV {cv} response get_completion(prompt_v1) print(第一版基础匹配提示词回复) print(response)结果分析模型可能会给出一个总体评价如“比较匹配”并罗列一些技能点。但缺乏系统性的量化分析和结构化输出对于“为什么匹配”、“哪里不匹配”、“风险点是什么”等问题解答不够深入。5.2 优化为结构化匹配报告我们需要一个更严谨的分析框架输出可供HR或面试官快速决策的报告。# 文件scenario_job_v2.py prompt_v2 f 你是一名资深的技术招聘专家。请对以下职位描述JD和候选人简历CV进行深度匹配分析并生成一份结构化报告。 **分析框架** 1. **硬性条件匹配** 对比学历、工作年限等硬性要求。 2. **核心技术栈匹配** 逐条对比JD中的技术要求框架、数据库、中间件、架构等与CV中的技能描述区分“完全匹配”、“部分匹配”、“不匹配”和“超出预期”。 3. **职责经验匹配** 分析CV中的项目经历是否覆盖JD中的核心职责。 4. **综合匹配度与评级** 给出一个0-100分的匹配度分数以及“强烈推荐”、“推荐”、“待定”、“不推荐”的评级。 5. **核心优势** 列出候选人最具竞争力的2-3个点。 6. **潜在风险与疑问** 指出可能存在的风险或需要在面试中进一步澄清的问题。 7. **面试建议** 提出2-3个针对性的面试考察方向。 请将分析结果组织成以下JSON格式 {{ “hard_requirements_match”: {{“status”: “符合/不符合”, “details”: “...”}}, “tech_stack_analysis”: [ {{“skill”: “Python”, “jd_requirement”: “精通”, “cv_level”: “精通”, “match”: “完全匹配”}}, // ... 更多技能 ], “experience_match”: “一段文字描述说明项目经历与职责的契合度”, “overall”: {{ “score”: 85, “rating”: “推荐”, “summary”: “总体匹配度较高的候选人” }}, “strengths”: [“优势1”, “优势2”], “risks_questions”: [“风险或问题1”, “风险或问题2”], “interview_focus”: [“建议考察方向1”, “建议考察方向2”] }} JD {jd} CV {cv} response get_completion(prompt_v2, temperature0.2) print(第二版结构化报告提示词回复) print(response)优化后的输出示例节选{ “hard_requirements_match”: {“status”: “符合”, “details”: “JD要求本科及以上5年以上Python经验。候选人为硕士学历Python相关经验超过6年2016至今完全符合。”}, “tech_stack_analysis”: [ {“skill”: “Python”, “jd_requirement”: “5年以上经验”, “cv_level”: “6年以上精通”, “match”: “完全匹配”}, {“skill”: “Django/Flask/FastAPI”, “jd_requirement”: “精通至少一种”, “cv_level”: “Django(5年精通), Flask(2年), FastAPI(1年)”, “match”: “完全匹配且超出预期”}, {“skill”: “MySQL/PostgreSQL”, “jd_requirement”: “熟悉有性能优化经验”, “cv_level”: “PostgreSQL(精通), MySQL(熟练)” “match”: “完全匹配”}, {“skill”: “Redis, Kafka, Elasticsearch”, “jd_requirement”: “熟悉”, “cv_level”: “Redis(精通), Kafka(熟练), Elasticsearch(了解)”, “match”: “大部分匹配ES仅为了解”}, {“skill”: “微服务与容器化(Docker/K8s)”, “jd_requirement”: “有经验者优先”, “cv_level”: “有主导微服务拆分和K8s经验熟练”, “match”: “完全匹配且为突出优势”} ], “experience_match”: “候选人近期在A公司的经历与JD职责高度契合1. 使用Django开发高并发电商平台匹配‘核心系统API开发’。2. 主导微服务架构拆分匹配‘系统架构设计’和‘高并发高可用’。3. 涉及数据库优化和缓存匹配‘性能优化’。4. 技术栈全面覆盖JD要求。”, “overall”: { “score”: 88, “rating”: “强烈推荐”, “summary”: “候选人在核心技术栈、项目经验和架构能力上与职位要求高度匹配尤其在微服务实战经验方面是显著加分项。” }, “strengths”: [“拥有高并发电商平台的核心开发与架构经验”, “具备从零到一的微服务拆分和容器化落地实战经验”, “技术栈与JD要求几乎完全吻合”], “risks_questions”: [“对Elasticsearch仅为了解若岗位对ES深度使用需评估”, “简历未明确提及单元测试的具体实践和覆盖率需面试中考察”], “interview_focus”: [“深入考察其主导的微服务拆分项目中遇到的挑战和解决方案”, “询问在高并发场景下具体的数据库性能优化案例和指标”, “了解其对测试驱动开发TDD或代码质量保障的理解和实践”] }这份报告为招聘决策提供了极具价值的参考它将主观的印象转化为客观、结构化的分析数据。5.3 调试与迭代处理边界情况在实际应用中我们会遇到各种边界情况例如简历信息模糊、JD要求矛盾等。提示词需要具备一定的鲁棒性。案例技能描述模糊假设CV中写的是“熟悉后端开发”而JD要求“精通Python”。我们可以在提示词中增加处理逻辑... **分析规则补充** - 当CV中对某项技能的描述比较模糊如“熟悉”、“了解”、“有接触”时在匹配分析中标记为“待核实”并将其列入“潜在风险与疑问”。 - 如果JD中的某项要求是“必须”项而CV中完全未提及则匹配状态为“缺失”并显著影响总体评分。 ...通过不断模拟各种边界案例并调整提示词中的“分析规则”我们可以让整个系统更加健壮和可靠。6. 提示词的优化调试与高级技巧设计出初版提示词只是第一步持续的优化调试Prompt Tuning才是工程化的关键。6.1 核心调试参数在调用API时有几个关键参数直接影响输出Temperature温度 控制输出的随机性。值越低如0.1-0.3输出越确定、保守、一致值越高如0.7-1.0输出越有创造性、多样性。对于需要稳定、结构化输出的任务如生成JSON、代码建议使用较低的温度。Max Tokens最大生成长度 限制模型回复的长度。设置过小会导致输出被截断设置过大会浪费资源。需要根据任务预估。Top-p (核采样) 另一种控制随机性的方式与temperature通常配合使用。通常保持默认值即可。6.2 迭代优化流程定义清晰的成功标准 首先明确什么是“好”的输出。是可解析的JSON是特定的语气还是覆盖了所有关键信息点编写初始提示词 使用CRISPE等框架写出第一版。使用代表性输入进行测试 准备一批涵盖典型和边界情况的测试用例。评估输出 对照成功标准检查输出结果。常见问题包括格式错误、遗漏信息、幻觉编造信息、逻辑矛盾、不遵循指令等。分析失败原因并修订提示词格式错误 在提示词中强化格式要求提供更清晰的示例Few-Shot。遗漏信息 在指令部分更明确地列出所有需要输出的项目使用“必须”、“确保”、“包含”等强动词。幻觉 要求模型“基于给定信息回答”并指出“如果信息不足请明确说明‘根据提供信息无法判断’”。逻辑问题 将复杂任务分解为更细的步骤Chain-of-Thought让模型逐步推理。重复测试与修订 这是一个循环过程直到在大多数测试用例上达到满意的效果。6.3 高级技巧思维链与自洽性检查对于极其复杂的推理任务可以显式要求模型展示其思考过程。请通过逐步推理来解答以下问题 问题{复杂问题} 请你 1. 首先理解问题并识别已知条件和未知目标。 2. 其次拆解解决问题的可能步骤。 3. 然后逐步执行每个步骤并进行计算或逻辑推断。 4. 最后整合所有步骤的结果给出最终答案并检查答案是否合理。此外可以要求模型进行“自我验证”在给出最终答案后请从另一个角度重新审视你的推理过程和答案检查是否存在逻辑漏洞或计算错误。7. 常见问题与排查清单在提示词开发过程中你可能会遇到以下典型问题问题现象可能原因排查与解决思路输出格式不符合要求1. 提示词中对格式的描述不够清晰或强制。2. Temperature 参数过高导致随机性太大。3. 模型能力有限无法稳定输出复杂格式。1. 使用JSON Schema描述或提供精确的示例。2. 降低Temperature(如设为0.1)。3. 换用更强大的模型如从 gpt-3.5-turbo 升级到 gpt-4。4. 将任务拆分先让模型生成文本再用代码进行后处理格式化。模型“幻觉”编造信息1. 提示词未限制模型仅使用给定上下文。2. 上下文信息不足模型被迫补全。3. 问题本身具有误导性或歧义。1. 在提示词开头明确指令“请严格根据以下提供的信息回答问题不要使用外部知识。”2. 提供更充分、准确的上下文信息。3. 让模型对不确定的部分输出“未知”或“信息不足”。输出冗长或过于简短1. Max Tokens 设置不合理。2. 提示词中未指定长度要求。3. 模型对任务理解有偏差。1. 调整Max Tokens参数。2. 在提示词中明确要求输出长度如“请用大约200字总结”。3. 通过示例Few-Shot展示理想的输出长度和详略程度。忽略部分指令1. 提示词过长指令被淹没。2. 多条指令之间存在冲突或优先级不明确。3. 指令表述不够直接。1.精简提示词将核心指令放在最前或最后。2. 使用编号、分段、加粗等方式使指令更醒目。3. 使用“必须”、“务必”、“首先…然后…”等词语强调指令顺序和重要性。不同模型间效果差异大不同模型如GPT-4 vs. Claude vs. 国内大模型对提示词的敏感度和遵循能力不同。1. 为不同的目标模型分别调试和优化提示词。2. 如果追求稳定性选择对指令遵循能力公认更强的模型。3. 构建一个简单的提示词适配层针对不同模型微调指令表述。8. 工程最佳实践与安全考量将提示词工程应用到生产环境时需遵循以下最佳实践版本化管理 像管理代码一样管理提示词。使用Git等工具对提示词模板进行版本控制记录每次修改的原因和效果。参数化与模板化 不要将提示词硬编码在业务逻辑中。应将提示词设计成模板将变量如用户输入、上下文进行参数化替换。可以使用类似Jinja2的模板引擎。# 示例使用字符串格式化或模板引擎 prompt_template 你是{role}。请完成以下任务{task} 上下文{context} 要求{requirements} filled_prompt prompt_template.format(role客服助手, task回复用户咨询, contextcontext, requirementsrequirements)测试与评估 建立提示词的测试集和评估标准。可以自动化测试输出格式、关键信息点是否包含、是否产生幻觉等。监控与日志 在生产环境记录提示词和对应的模型输入输出用于分析效果、排查问题和持续优化。成本控制 提示词的长度直接影响API调用成本按Token计费。在保证效果的前提下尽量精简提示词移除冗余描述。安全与伦理防止提示词注入Prompt Injection 永远不要将未经处理的用户输入直接拼接进提示词。应对用户输入进行清洗或使用更安全的模板填充方式。避免偏见与有害输出 在系统指令System Prompt中明确模型的行为准则例如“你是一个公正、无害的助手”。对于敏感场景如招聘需在结果中声明“AI分析仅供参考最终决策需由人类完成”。内容过滤 对于生成内容应建立后置的内容安全过滤机制。提示词工程是一门实践性极强的技能。从理解基础概念开始到掌握CRISPE等结构化框架再到通过旅游推荐、人岗匹配等实战案例进行深度演练最后学习优化调试方法和工程化实践这条路径能帮助你系统性地提升与大模型协作的效率。记住最好的提示词往往是迭代出来的。不要期望一蹴而就大胆尝试、细心分析、持续优化你就能设计出真正高效、可靠的AI指令让大模型成为你手中得心应手的强大工具。