30款热门AI模型一站整合DeepSeek/GLM/Qwen 随心用限时 5 折。 点击领海量免费额度你是不是也遇到过这种情况花了几十块钱买了某个AI大模型的会员兴冲冲地输入一个问题结果得到的回答要么是“正确的废话”要么干脆答非所问甚至开始一本正经地胡说八道然后你开始怀疑到底是模型不行还是自己不会用问题的关键往往不在于模型本身而在于你给它的“指令”——也就是提示词Prompt。很多人以为提示词工程就是“把话说清楚”但实际上它是一门融合了心理学、语言学和软件工程的技术。一个精心设计的提示词能让一个普通模型发挥出专家级水平而一个糟糕的提示词即使面对最顶尖的模型也可能得到一堆垃圾信息。这篇文章不会给你一堆空洞的理论也不会复述那些“角色扮演”、“分步思考”的简单技巧。我们将从一个开发者和重度使用者的角度深入剖析提示词工程的核心原理、实战策略和高级模式。无论你是想提升日常工作效率还是计划将大模型集成到自己的应用中这篇文章都将帮你构建一套系统、可复用的提示词设计方法论让你真正掌握与大模型高效“对话”的能力。1. 为什么你的提示词总是不管用从“对话”到“工程”的思维转变在深入技术细节之前我们必须先纠正一个最常见的误区把与大模型的交互当成一次性的、随意的聊天。这种思维是导致提示词效果不稳定的根本原因。想象一下如果你要写一段程序你会不会想到哪写到哪完全不考虑变量命名、函数结构和错误处理显然不会。提示词设计也是如此。一个有效的提示词本质上是一个为特定任务定制的、结构化的微型程序它运行在由神经网络构成的“硬件”上。为什么思维转变如此重要因为大模型LLM的工作方式是基于概率的“续写”。你给的提示词就是它生成文本的“上文”。一个模糊、矛盾、信息缺失的上文必然导致一个糟糕的“下文”。提示词工程就是通过精心构造这个“上文”来精确引导模型输出我们想要的“下文”。新手常犯的三个致命错误目标模糊例如“帮我写点东西”。模型不知道写什么、写给谁、什么风格。信息过载或缺失要么把整个文档扔进去让模型自己“悟”要么只给一个关键词。缺乏结构化约束没有指定输出格式JSON、Markdown、列表等导致后续处理极其困难。从下一章开始我们将系统性地解决这些问题把提示词设计从“玄学”变成可遵循、可调试、可优化的“工程”。2. 提示词工程的核心角色、任务与上下文三位一体一个强大的提示词通常由三个核心要素构成我称之为“RTC框架”角色Role、任务Task、上下文Context。理解并运用好这个框架你的提示词效果能立刻提升一个档次。2.1 角色Role为模型赋予“人格”与专业背景告诉模型“你是谁”是设定其行为边界和知识范围最有效的方式。这不仅仅是“你是一个助手”而是赋予其具体的专业身份。基础角色你是一位有帮助的助手。专业角色你是一位经验丰富的Python高级开发工程师擅长编写简洁、高效、符合PEP8规范的代码并且注重异常处理和代码可读性。风格角色你是一位言辞犀利、观点鲜明的科技评论员善于用比喻和案例来阐述复杂概念。为什么有效大模型在训练时学习了海量不同风格和领域的文本。指定角色相当于激活了模型中与这个角色相关的“神经元子集”使其输出更符合该角色的特征。2.2 任务Task清晰、具体、可验证的指令任务是提示词的心脏。它必须清晰、无歧义并且最好包含可验证的产出标准。糟糕的任务总结一下这篇文章。哪篇文章总结成多长给谁看优秀的任务请将下面提供的技术博客正文总结为一个不超过200字的摘要面向初级软件开发人员突出其中的核心解决方案和关键代码示例。摘要需用中文撰写语言平实易懂。关键技巧使用动作动词。例如“生成”、“转换”、“总结”、“分类”、“解释”、“比较”、“调试”、“编写”。动词越具体模型的行动指向越明确。2.3 上下文Context提供完成任务所需的“燃料”上下文是模型完成任务所依赖的具体信息。它可以包括输入文本需要被处理、分析或总结的原文。背景信息相关的领域知识、专业术语解释、项目背景。示例Few-shot提供一两个输入-输出的例子让模型通过类比学习任务要求。这是最强大的技巧之一。约束条件格式、长度、语言、禁止涉及的内容等。示例一个整合了RTC框架的提示词[角色] 你是一位资深的产品经理精通互联网ToC产品设计擅长从用户视角分析问题。 [任务] 基于下方提供的用户访谈原始记录提取出至少3个最关键的痛点Pain Point并为每个痛点构思一个初步的产品功能解决方案。请以表格形式输出。 [上下文] - 输出格式 | 序号 | 关键痛点描述 | 目标用户场景 | 初步解决方案构思 | | :--- | :--- | :--- | :--- | | ... | ... | ... | ... | - 用户访谈记录 “我经常在晚上睡觉前用手机App听课程但总是听着听着就睡着了手机放了一整夜第二天发现电全耗光了还担心电池损耗...” “我希望App能在我睡着后自动暂停播放并且进入低功耗模式而不是仅仅靠一个睡眠定时器。” “有时候我只是中途暂停一下回来却找不到刚才听到哪里了进度条不精准。”这个提示词结构清晰角色、任务、上下文分离极大提高了可读性和可修改性。模型接到这样的指令其输出质量和对齐程度会远高于一段混杂的叙述。3. 从零构建你的提示词分步设计与迭代优化知道了核心要素我们来看看如何从零开始构建一个用于真实场景的提示词。我们以一个常见的开发者需求为例“为一个新的Python Flask API项目生成标准化的项目结构说明文档”。3.1 第一步定义基础提示词初版我们直接应用RTC框架写出第一版。你是一位专业的Python后端技术专家拥有丰富的Flask项目架构经验。 请为创建一个新的用户管理微服务使用Flask框架设计一个标准的项目目录结构并解释每个核心目录和文件的作用。该项目计划使用SQLAlchemy作为ORM使用Pydantic进行请求验证并包含基本的用户注册、登录、查询功能。 请以Markdown格式输出结构清晰解释简洁。运行一下看看这个提示词已经不错但输出可能比较通用不会包含我们团队内部的一些特定规范比如统一的日志配置、配置文件管理方式等。3.2 第二步添加示例与具体约束进阶版为了让输出更贴合我们自己的工程实践我们加入更具体的约束和示例。[角色] 你是一位精通现代Python Web开发、尤其熟悉Flask最佳实践的架构师。你非常重视代码结构清晰、配置与代码分离、以及良好的可维护性。 [任务] 为我们团队设计一个Flask API项目的标准目录结构模板。该模板将作为所有新Flask项目的起点。 [上下文] 1. **项目核心需求** - 项目名称user-service - 核心功能用户注册、登录JWT、信息查询与更新。 - 关键技术栈Flask, SQLAlchemy (ORM), Pydantic (数据验证), Flask-JWT-Extended, python-dotenv。 2. **必须遵守的团队规范** - 所有配置必须从环境变量读取通过 .env 文件管理使用 python-dotenv 加载。 - 日志需统一配置日志文件按日期滚动并存放在 logs/ 目录下。 - 数据库模型Models、路由Routes、业务逻辑Services、工具函数Utils必须分目录存放。 - 必须包含 requirements.txt 和 Pipfile 用于依赖管理。 - 必须包含一个 config.py 文件根据 FLASK_ENV 环境变量加载不同配置类Development, Production。 3. **输出格式要求** - 请生成一个完整的、树状的项目结构图以代码块形式展示。 - 在结构图下方用一个表格详细说明**关键文件/目录**的用途。 - 最后提供一个最简化的 app/__init__.py 和 config.py 的示例代码展示如何初始化应用和加载配置。 [示例-输出格式参考] 项目结构 user-service/ ├── .env.example ├── .gitignore ├── Pipfile ├── README.md ├── requirements.txt ├── config.py ├── app/ │ ├── __init__.py │ ├── models/ │ │ └── user.py │ ├── routes/ │ │ └── auth.py │ ├── services/ │ │ └── user_service.py │ ├── utils/ │ │ └── logger.py │ └── schemas/ │ └── user.py ├── logs/ └── tests/ 关键文件说明 | 文件/目录 | 用途说明 | | :--- | :--- | | app/__init__.py | 应用工厂函数初始化Flask app、数据库、扩展等。 | | app/utils/logger.py | 统一的日志配置模块。 | | config.py | 配置类定义DevelopmentConfig, ProductionConfig。 | | ... | ... | 示例代码 python # config.py import os from dotenv import load_dotenv load_dotenv() class Config: SECRET_KEY os.getenv(SECRET_KEY) SQLALCHEMY_DATABASE_URI os.getenv(DATABASE_URL) SQLALCHEMY_TRACK_MODIFICATIONS False class DevelopmentConfig(Config): DEBUG True class ProductionConfig(Config): DEBUG False**对比分析**第二版提示词加入了具体的团队规范、技术栈细节、以及输出格式的示例。这极大地缩小了模型的“想象空间”使其输出与我们的实际工程需求高度对齐。这就是**上下文约束**和**示例Few-shot** 的力量。 ### 3.3 第三步处理复杂任务——思维链Chain-of-Thought与分步指令 对于逻辑推理、代码调试、复杂分析等任务直接要求结果往往效果不佳。这时我们需要引导模型**展示其思考过程**即“思维链CoT”提示。 **场景**让模型分析一段Python代码的性能瓶颈。 * **低效提示**优化下面这段代码。 * **高效提示CoT** 请按以下步骤分析下方Python代码 1. **理解功能**用一句话说明这段代码的目标是什么。 2. **识别瓶颈**逐行分析指出可能存在的性能瓶颈如时间复杂度高的循环、重复计算、不必要的IO等。 3. **提出优化方案**针对每个瓶颈提出具体的优化代码或思路。 4. **重写代码**给出优化后的完整代码。 待分析的代码 python def process_data(data_list): result [] for item in data_list: # 假设这是一个耗时的计算 processed expensive_operation(item) if processed 10: result.append(processed) return result 通过强制模型分步思考我们不仅能得到更准确的最终答案还能洞察模型的推理逻辑这对于调试我们自己的提示词也至关重要。 ## 4. 高级模式提示词即程序——系统提示、函数调用与智能体Agent 当我们将大模型集成到应用程序中时提示词就从一个“对话起点”演变成了系统的“控制逻辑”。这时我们需要更工程化的模式。 ### 4.1 系统提示System Prompt与用户提示User Prompt 在OpenAI API等接口中通常存在两种角色 * **系统提示**设定模型的整体行为准则、身份和高级目标。它在整个会话周期内持续影响模型。 * **用户提示**代表用户本次的具体请求。 **最佳实践**将长期的、全局性的约束放在**系统提示**中将具体的、本次的任务放在**用户提示**中。 python # 一个模拟API调用的示例结构非真实代码仅示意 messages [ { role: system, content: 你是一个专业的代码助手。你始终以中文回复。你提供的代码必须简洁、高效并包含必要的注释。如果用户的要求模糊你会主动询问澄清。 # 系统提示 }, { role: user, content: 用Python写一个函数从给定的URL列表中异步下载所有图片并保存到指定文件夹。 # 用户提示 } ]4.2 函数调用Function Calling与工具使用这是构建AI应用的核心模式。模型不直接执行操作而是分析用户请求后输出一个结构化的请求告诉程序“应该调用哪个函数并传入什么参数”。程序执行函数后再将结果返回给模型由模型生成最终回复给用户。流程开发者定义一系列工具函数如search_web,get_weather,calculate及其参数格式JSON Schema。用户提问“北京今天天气怎么样”模型识别出需要调用get_weather函数并输出{name: get_weather, arguments: {city: 北京}}你的程序执行get_weather(北京)获得真实数据。将数据如{“city”: “北京” “temp”: “22°C”}再次传给模型。模型根据函数执行结果生成友好回复“北京今天天气晴朗气温22摄氏度。”提示词设计要点在系统提示中清晰地描述可用工具的功能和参数。这本质上是在扩展模型的能力边界让它知道“外面有什么可以帮你”。4.3 智能体Agent工作流ReAct模式智能体是函数调用的升级版它让模型具备了自主规划、执行、观察、再行动的循环能力。经典的ReActReason Act模式提示词框架如下你是一个能够使用工具的智能助手。请遵循以下步骤解决问题 1. **思考**分析当前情况决定下一步该做什么。如果需要使用工具请说明原因。 2. **行动**如果需要工具请严格按照格式调用Action: 工具名称 Action Input: 输入参数。 3. **观察**你将得到工具执行后的结果。 4. 重复1-3步直到你认为可以给出最终答案。 5. **最终答案**基于所有观察给出最终结论。 你可以使用的工具 - 搜索工具[search]用于搜索最新信息。参数query搜索关键词。 - 计算器[calculator]用于数学计算。参数expression数学表达式。 现在开始 问题马斯克最近一次关于AI的公开演讲是什么时候他在演讲中提到的核心观点是什么在这种提示词下模型会先“思考”需要搜索然后调用搜索工具观察结果再“思考”是否需要进一步搜索或总结最终给出答案。这实现了多步骤复杂任务的自动化。5. 实战构建一个技术文档问答助手RAG概念引入让我们结合一个更复杂的实战场景看看如何综合运用以上所有技巧。假设我们要构建一个针对内部技术Wiki的问答助手。核心挑战大模型的知识可能过时且不了解我们内部的私有文档。解决方案RAG检索增强生成。流程是1) 将内部文档切片、向量化存储2) 用户提问时先从向量库检索相关文档片段3) 将这些片段作为上下文连同问题一起发给模型生成答案。提示词设计是这个流程中的“大脑”[系统提示] 你是一个专业、准确的技术文档助手。你的知识来源于提供的“参考文档”。请严格基于参考文档内容回答问题。如果参考文档中没有足够信息来完整回答问题请明确指出“根据现有文档无法完全回答此问题”并说明文档中已有的相关信息。禁止编造文档中不存在的信息。 [用户提示] 请基于以下提供的参考文档回答用户的问题。 ### 参考文档 {context} ### 用户问题 {question} ### 回答要求 - 答案必须准确、简洁直接针对问题。 - 引用参考文档中的关键点支持你的答案。 - 如果文档内容涉及代码请保留代码格式。 - 使用中文回答。在这个设计中系统提示规定了模型的行为边界严格基于参考文档禁止幻觉。用户提示的结构化模板清晰分隔了动态注入的{context}检索到的文档片段和{question}用户问题。回答要求进一步约束了输出格式和质量。这就是一个典型的、可用于生产环境的提示词模板。在实际系统中{context}和{question}会被程序动态替换。6. 提示词的测试、评估与持续优化提示词不是一蹴而就的需要像测试软件一样进行迭代优化。6.1 构建测试用例集为你的核心提示词创建一组标准化的测试用例输入-期望输出对。例如用例1正常功能问题。用例2边界或模糊问题。用例3试图诱导模型突破规则的问题安全性测试。用例4需要复杂推理或多步骤的问题。6.2 评估维度从以下几个维度评估提示词的效果相关性答案是否紧扣问题准确性答案中的事实是否正确完整性是否回答了问题的所有部分格式符合度输出是否符合指定的格式JSON 表格等安全性/合规性是否拒绝了不当请求6.3 A/B测试与调优如果效果不理想进行有目标的调优问题不相关增加角色设定或加强上下文约束如“必须基于以下信息”。事实错误引入更可靠的检索来源RAG或在提示词中强调“如果你不确定请说不知道”。格式错误提供更清晰的格式示例Few-shot或在系统提示中严格要求。过于冗长在指令中加入“请简洁回答”、“用不超过三句话概括”。7. 常见“坑”与排查清单即使掌握了所有技巧实践中还是会遇到问题。下面是一个快速排查清单问题现象可能原因排查与解决方案模型完全无视指令1. 指令淹没在过长的上下文中。2. 指令本身矛盾或模糊。1. 将最关键指令放在提示词开头或结尾。2. 使用## 指令 ##等符号强调。3. 简化指令确保单一明确。输出格式混乱1. 未指定格式。2. 格式描述不清晰。1. 明确要求格式如“请以JSON格式输出”。2.提供完整的输出示例Few-shot这是最有效的方法。模型“幻觉”编造信息1. 问题超出模型知识范围。2. 提示词未限制信息来源。1. 对于事实性问题采用RAG模式提供参考来源。2. 在系统提示中加入“如果你不知道答案请明确告知不要编造。”回答冗长啰嗦模型默认倾向于生成详细内容。在指令中加入长度限制“请用一句话回答”、“总结在100字以内”。无法处理复杂推理任务一步到位太难。使用思维链CoT提示要求模型“逐步思考”。在不同模型上效果差异大不同模型对指令的敏感度和遵循能力不同。1. 针对特定模型如GPT-4 Claude DeepSeek调整提示词。2. 使用更主流、通用的提示词结构如本文的RTC框架。8. 工程化最佳实践将提示词纳入开发流程对于需要集成LLM的严肃项目提示词的管理和维护至关重要。版本控制像管理代码一样用Git管理你的提示词模板。记录每次修改的原因和效果。参数化模板将提示词设计成模板将可变部分如查询、上下文参数化。例如使用Python的f-string或Jinja2模板。# 一个简单的模板示例 prompt_template 你是一位{expert_role}。 请完成以下任务{task_description}。 相关上下文{context} 请按照要求输出{output_format} # 使用时填充参数 filled_prompt prompt_template.format( expert_role数据分析师, task_description分析以下销售数据的趋势, contextsales_data_str, output_format一个包含关键发现的列表 )集中配置与管理不要将提示词硬编码在业务逻辑里。将其存放在配置文件如YAML、JSON或数据库中便于统一修改和A/B测试。监控与日志记录每次API调用的提示词和返回结果用于分析效果、排查问题和优化提示词。安全与审核建立提示词安全审核机制防止注入攻击Prompt Injection或意外生成有害内容。对用户输入进行严格的清洗和过滤。9. 总结与进阶方向提示词工程远不止是“如何问问题”。它是一个系统工程贯穿了从理解模型原理、设计交互逻辑、到集成部署和持续优化的全过程。本文核心回顾思维转变从随意聊天转向结构化工程。核心框架角色-任务-上下文RTC是构建有效提示词的基石。进阶技巧示例Few-shot和思维链CoT能显著提升复杂任务的表现。高级模式系统提示/用户提示、函数调用和智能体Agent是构建AI应用的关键。持续迭代像开发软件一样测试、评估和优化你的提示词。下一步你可以探索自动化提示词优化研究如LangChain、LlamaIndex等框架它们提供了大量提示词模板、链式调用和智能体构建工具。向量数据库与RAG深入学习如何将外部知识库与大模型结合解决模型幻觉和知识更新问题。模型微调Fine-tuning对于特定领域或任务当提示词工程达到瓶颈时可以考虑用自有数据对开源模型进行微调获得更专精、更可控的模型行为。提示词注入安全学习如何防御恶意用户通过精心构造的输入来“劫持”你的系统提示词这是一个重要的安全课题。记住最好的提示词来自于对业务的深刻理解、对任务的清晰定义以及不断的实验和迭代。现在就从为你手头的一个具体任务设计一个结构化的提示词开始吧。 30款热门AI模型一站整合DeepSeek/GLM/Qwen 随心用限时 5 折。 点击领海量免费额度
提示词工程实战：从核心原理到高级应用，打造高效AI对话能力
30款热门AI模型一站整合DeepSeek/GLM/Qwen 随心用限时 5 折。 点击领海量免费额度你是不是也遇到过这种情况花了几十块钱买了某个AI大模型的会员兴冲冲地输入一个问题结果得到的回答要么是“正确的废话”要么干脆答非所问甚至开始一本正经地胡说八道然后你开始怀疑到底是模型不行还是自己不会用问题的关键往往不在于模型本身而在于你给它的“指令”——也就是提示词Prompt。很多人以为提示词工程就是“把话说清楚”但实际上它是一门融合了心理学、语言学和软件工程的技术。一个精心设计的提示词能让一个普通模型发挥出专家级水平而一个糟糕的提示词即使面对最顶尖的模型也可能得到一堆垃圾信息。这篇文章不会给你一堆空洞的理论也不会复述那些“角色扮演”、“分步思考”的简单技巧。我们将从一个开发者和重度使用者的角度深入剖析提示词工程的核心原理、实战策略和高级模式。无论你是想提升日常工作效率还是计划将大模型集成到自己的应用中这篇文章都将帮你构建一套系统、可复用的提示词设计方法论让你真正掌握与大模型高效“对话”的能力。1. 为什么你的提示词总是不管用从“对话”到“工程”的思维转变在深入技术细节之前我们必须先纠正一个最常见的误区把与大模型的交互当成一次性的、随意的聊天。这种思维是导致提示词效果不稳定的根本原因。想象一下如果你要写一段程序你会不会想到哪写到哪完全不考虑变量命名、函数结构和错误处理显然不会。提示词设计也是如此。一个有效的提示词本质上是一个为特定任务定制的、结构化的微型程序它运行在由神经网络构成的“硬件”上。为什么思维转变如此重要因为大模型LLM的工作方式是基于概率的“续写”。你给的提示词就是它生成文本的“上文”。一个模糊、矛盾、信息缺失的上文必然导致一个糟糕的“下文”。提示词工程就是通过精心构造这个“上文”来精确引导模型输出我们想要的“下文”。新手常犯的三个致命错误目标模糊例如“帮我写点东西”。模型不知道写什么、写给谁、什么风格。信息过载或缺失要么把整个文档扔进去让模型自己“悟”要么只给一个关键词。缺乏结构化约束没有指定输出格式JSON、Markdown、列表等导致后续处理极其困难。从下一章开始我们将系统性地解决这些问题把提示词设计从“玄学”变成可遵循、可调试、可优化的“工程”。2. 提示词工程的核心角色、任务与上下文三位一体一个强大的提示词通常由三个核心要素构成我称之为“RTC框架”角色Role、任务Task、上下文Context。理解并运用好这个框架你的提示词效果能立刻提升一个档次。2.1 角色Role为模型赋予“人格”与专业背景告诉模型“你是谁”是设定其行为边界和知识范围最有效的方式。这不仅仅是“你是一个助手”而是赋予其具体的专业身份。基础角色你是一位有帮助的助手。专业角色你是一位经验丰富的Python高级开发工程师擅长编写简洁、高效、符合PEP8规范的代码并且注重异常处理和代码可读性。风格角色你是一位言辞犀利、观点鲜明的科技评论员善于用比喻和案例来阐述复杂概念。为什么有效大模型在训练时学习了海量不同风格和领域的文本。指定角色相当于激活了模型中与这个角色相关的“神经元子集”使其输出更符合该角色的特征。2.2 任务Task清晰、具体、可验证的指令任务是提示词的心脏。它必须清晰、无歧义并且最好包含可验证的产出标准。糟糕的任务总结一下这篇文章。哪篇文章总结成多长给谁看优秀的任务请将下面提供的技术博客正文总结为一个不超过200字的摘要面向初级软件开发人员突出其中的核心解决方案和关键代码示例。摘要需用中文撰写语言平实易懂。关键技巧使用动作动词。例如“生成”、“转换”、“总结”、“分类”、“解释”、“比较”、“调试”、“编写”。动词越具体模型的行动指向越明确。2.3 上下文Context提供完成任务所需的“燃料”上下文是模型完成任务所依赖的具体信息。它可以包括输入文本需要被处理、分析或总结的原文。背景信息相关的领域知识、专业术语解释、项目背景。示例Few-shot提供一两个输入-输出的例子让模型通过类比学习任务要求。这是最强大的技巧之一。约束条件格式、长度、语言、禁止涉及的内容等。示例一个整合了RTC框架的提示词[角色] 你是一位资深的产品经理精通互联网ToC产品设计擅长从用户视角分析问题。 [任务] 基于下方提供的用户访谈原始记录提取出至少3个最关键的痛点Pain Point并为每个痛点构思一个初步的产品功能解决方案。请以表格形式输出。 [上下文] - 输出格式 | 序号 | 关键痛点描述 | 目标用户场景 | 初步解决方案构思 | | :--- | :--- | :--- | :--- | | ... | ... | ... | ... | - 用户访谈记录 “我经常在晚上睡觉前用手机App听课程但总是听着听着就睡着了手机放了一整夜第二天发现电全耗光了还担心电池损耗...” “我希望App能在我睡着后自动暂停播放并且进入低功耗模式而不是仅仅靠一个睡眠定时器。” “有时候我只是中途暂停一下回来却找不到刚才听到哪里了进度条不精准。”这个提示词结构清晰角色、任务、上下文分离极大提高了可读性和可修改性。模型接到这样的指令其输出质量和对齐程度会远高于一段混杂的叙述。3. 从零构建你的提示词分步设计与迭代优化知道了核心要素我们来看看如何从零开始构建一个用于真实场景的提示词。我们以一个常见的开发者需求为例“为一个新的Python Flask API项目生成标准化的项目结构说明文档”。3.1 第一步定义基础提示词初版我们直接应用RTC框架写出第一版。你是一位专业的Python后端技术专家拥有丰富的Flask项目架构经验。 请为创建一个新的用户管理微服务使用Flask框架设计一个标准的项目目录结构并解释每个核心目录和文件的作用。该项目计划使用SQLAlchemy作为ORM使用Pydantic进行请求验证并包含基本的用户注册、登录、查询功能。 请以Markdown格式输出结构清晰解释简洁。运行一下看看这个提示词已经不错但输出可能比较通用不会包含我们团队内部的一些特定规范比如统一的日志配置、配置文件管理方式等。3.2 第二步添加示例与具体约束进阶版为了让输出更贴合我们自己的工程实践我们加入更具体的约束和示例。[角色] 你是一位精通现代Python Web开发、尤其熟悉Flask最佳实践的架构师。你非常重视代码结构清晰、配置与代码分离、以及良好的可维护性。 [任务] 为我们团队设计一个Flask API项目的标准目录结构模板。该模板将作为所有新Flask项目的起点。 [上下文] 1. **项目核心需求** - 项目名称user-service - 核心功能用户注册、登录JWT、信息查询与更新。 - 关键技术栈Flask, SQLAlchemy (ORM), Pydantic (数据验证), Flask-JWT-Extended, python-dotenv。 2. **必须遵守的团队规范** - 所有配置必须从环境变量读取通过 .env 文件管理使用 python-dotenv 加载。 - 日志需统一配置日志文件按日期滚动并存放在 logs/ 目录下。 - 数据库模型Models、路由Routes、业务逻辑Services、工具函数Utils必须分目录存放。 - 必须包含 requirements.txt 和 Pipfile 用于依赖管理。 - 必须包含一个 config.py 文件根据 FLASK_ENV 环境变量加载不同配置类Development, Production。 3. **输出格式要求** - 请生成一个完整的、树状的项目结构图以代码块形式展示。 - 在结构图下方用一个表格详细说明**关键文件/目录**的用途。 - 最后提供一个最简化的 app/__init__.py 和 config.py 的示例代码展示如何初始化应用和加载配置。 [示例-输出格式参考] 项目结构 user-service/ ├── .env.example ├── .gitignore ├── Pipfile ├── README.md ├── requirements.txt ├── config.py ├── app/ │ ├── __init__.py │ ├── models/ │ │ └── user.py │ ├── routes/ │ │ └── auth.py │ ├── services/ │ │ └── user_service.py │ ├── utils/ │ │ └── logger.py │ └── schemas/ │ └── user.py ├── logs/ └── tests/ 关键文件说明 | 文件/目录 | 用途说明 | | :--- | :--- | | app/__init__.py | 应用工厂函数初始化Flask app、数据库、扩展等。 | | app/utils/logger.py | 统一的日志配置模块。 | | config.py | 配置类定义DevelopmentConfig, ProductionConfig。 | | ... | ... | 示例代码 python # config.py import os from dotenv import load_dotenv load_dotenv() class Config: SECRET_KEY os.getenv(SECRET_KEY) SQLALCHEMY_DATABASE_URI os.getenv(DATABASE_URL) SQLALCHEMY_TRACK_MODIFICATIONS False class DevelopmentConfig(Config): DEBUG True class ProductionConfig(Config): DEBUG False**对比分析**第二版提示词加入了具体的团队规范、技术栈细节、以及输出格式的示例。这极大地缩小了模型的“想象空间”使其输出与我们的实际工程需求高度对齐。这就是**上下文约束**和**示例Few-shot** 的力量。 ### 3.3 第三步处理复杂任务——思维链Chain-of-Thought与分步指令 对于逻辑推理、代码调试、复杂分析等任务直接要求结果往往效果不佳。这时我们需要引导模型**展示其思考过程**即“思维链CoT”提示。 **场景**让模型分析一段Python代码的性能瓶颈。 * **低效提示**优化下面这段代码。 * **高效提示CoT** 请按以下步骤分析下方Python代码 1. **理解功能**用一句话说明这段代码的目标是什么。 2. **识别瓶颈**逐行分析指出可能存在的性能瓶颈如时间复杂度高的循环、重复计算、不必要的IO等。 3. **提出优化方案**针对每个瓶颈提出具体的优化代码或思路。 4. **重写代码**给出优化后的完整代码。 待分析的代码 python def process_data(data_list): result [] for item in data_list: # 假设这是一个耗时的计算 processed expensive_operation(item) if processed 10: result.append(processed) return result 通过强制模型分步思考我们不仅能得到更准确的最终答案还能洞察模型的推理逻辑这对于调试我们自己的提示词也至关重要。 ## 4. 高级模式提示词即程序——系统提示、函数调用与智能体Agent 当我们将大模型集成到应用程序中时提示词就从一个“对话起点”演变成了系统的“控制逻辑”。这时我们需要更工程化的模式。 ### 4.1 系统提示System Prompt与用户提示User Prompt 在OpenAI API等接口中通常存在两种角色 * **系统提示**设定模型的整体行为准则、身份和高级目标。它在整个会话周期内持续影响模型。 * **用户提示**代表用户本次的具体请求。 **最佳实践**将长期的、全局性的约束放在**系统提示**中将具体的、本次的任务放在**用户提示**中。 python # 一个模拟API调用的示例结构非真实代码仅示意 messages [ { role: system, content: 你是一个专业的代码助手。你始终以中文回复。你提供的代码必须简洁、高效并包含必要的注释。如果用户的要求模糊你会主动询问澄清。 # 系统提示 }, { role: user, content: 用Python写一个函数从给定的URL列表中异步下载所有图片并保存到指定文件夹。 # 用户提示 } ]4.2 函数调用Function Calling与工具使用这是构建AI应用的核心模式。模型不直接执行操作而是分析用户请求后输出一个结构化的请求告诉程序“应该调用哪个函数并传入什么参数”。程序执行函数后再将结果返回给模型由模型生成最终回复给用户。流程开发者定义一系列工具函数如search_web,get_weather,calculate及其参数格式JSON Schema。用户提问“北京今天天气怎么样”模型识别出需要调用get_weather函数并输出{name: get_weather, arguments: {city: 北京}}你的程序执行get_weather(北京)获得真实数据。将数据如{“city”: “北京” “temp”: “22°C”}再次传给模型。模型根据函数执行结果生成友好回复“北京今天天气晴朗气温22摄氏度。”提示词设计要点在系统提示中清晰地描述可用工具的功能和参数。这本质上是在扩展模型的能力边界让它知道“外面有什么可以帮你”。4.3 智能体Agent工作流ReAct模式智能体是函数调用的升级版它让模型具备了自主规划、执行、观察、再行动的循环能力。经典的ReActReason Act模式提示词框架如下你是一个能够使用工具的智能助手。请遵循以下步骤解决问题 1. **思考**分析当前情况决定下一步该做什么。如果需要使用工具请说明原因。 2. **行动**如果需要工具请严格按照格式调用Action: 工具名称 Action Input: 输入参数。 3. **观察**你将得到工具执行后的结果。 4. 重复1-3步直到你认为可以给出最终答案。 5. **最终答案**基于所有观察给出最终结论。 你可以使用的工具 - 搜索工具[search]用于搜索最新信息。参数query搜索关键词。 - 计算器[calculator]用于数学计算。参数expression数学表达式。 现在开始 问题马斯克最近一次关于AI的公开演讲是什么时候他在演讲中提到的核心观点是什么在这种提示词下模型会先“思考”需要搜索然后调用搜索工具观察结果再“思考”是否需要进一步搜索或总结最终给出答案。这实现了多步骤复杂任务的自动化。5. 实战构建一个技术文档问答助手RAG概念引入让我们结合一个更复杂的实战场景看看如何综合运用以上所有技巧。假设我们要构建一个针对内部技术Wiki的问答助手。核心挑战大模型的知识可能过时且不了解我们内部的私有文档。解决方案RAG检索增强生成。流程是1) 将内部文档切片、向量化存储2) 用户提问时先从向量库检索相关文档片段3) 将这些片段作为上下文连同问题一起发给模型生成答案。提示词设计是这个流程中的“大脑”[系统提示] 你是一个专业、准确的技术文档助手。你的知识来源于提供的“参考文档”。请严格基于参考文档内容回答问题。如果参考文档中没有足够信息来完整回答问题请明确指出“根据现有文档无法完全回答此问题”并说明文档中已有的相关信息。禁止编造文档中不存在的信息。 [用户提示] 请基于以下提供的参考文档回答用户的问题。 ### 参考文档 {context} ### 用户问题 {question} ### 回答要求 - 答案必须准确、简洁直接针对问题。 - 引用参考文档中的关键点支持你的答案。 - 如果文档内容涉及代码请保留代码格式。 - 使用中文回答。在这个设计中系统提示规定了模型的行为边界严格基于参考文档禁止幻觉。用户提示的结构化模板清晰分隔了动态注入的{context}检索到的文档片段和{question}用户问题。回答要求进一步约束了输出格式和质量。这就是一个典型的、可用于生产环境的提示词模板。在实际系统中{context}和{question}会被程序动态替换。6. 提示词的测试、评估与持续优化提示词不是一蹴而就的需要像测试软件一样进行迭代优化。6.1 构建测试用例集为你的核心提示词创建一组标准化的测试用例输入-期望输出对。例如用例1正常功能问题。用例2边界或模糊问题。用例3试图诱导模型突破规则的问题安全性测试。用例4需要复杂推理或多步骤的问题。6.2 评估维度从以下几个维度评估提示词的效果相关性答案是否紧扣问题准确性答案中的事实是否正确完整性是否回答了问题的所有部分格式符合度输出是否符合指定的格式JSON 表格等安全性/合规性是否拒绝了不当请求6.3 A/B测试与调优如果效果不理想进行有目标的调优问题不相关增加角色设定或加强上下文约束如“必须基于以下信息”。事实错误引入更可靠的检索来源RAG或在提示词中强调“如果你不确定请说不知道”。格式错误提供更清晰的格式示例Few-shot或在系统提示中严格要求。过于冗长在指令中加入“请简洁回答”、“用不超过三句话概括”。7. 常见“坑”与排查清单即使掌握了所有技巧实践中还是会遇到问题。下面是一个快速排查清单问题现象可能原因排查与解决方案模型完全无视指令1. 指令淹没在过长的上下文中。2. 指令本身矛盾或模糊。1. 将最关键指令放在提示词开头或结尾。2. 使用## 指令 ##等符号强调。3. 简化指令确保单一明确。输出格式混乱1. 未指定格式。2. 格式描述不清晰。1. 明确要求格式如“请以JSON格式输出”。2.提供完整的输出示例Few-shot这是最有效的方法。模型“幻觉”编造信息1. 问题超出模型知识范围。2. 提示词未限制信息来源。1. 对于事实性问题采用RAG模式提供参考来源。2. 在系统提示中加入“如果你不知道答案请明确告知不要编造。”回答冗长啰嗦模型默认倾向于生成详细内容。在指令中加入长度限制“请用一句话回答”、“总结在100字以内”。无法处理复杂推理任务一步到位太难。使用思维链CoT提示要求模型“逐步思考”。在不同模型上效果差异大不同模型对指令的敏感度和遵循能力不同。1. 针对特定模型如GPT-4 Claude DeepSeek调整提示词。2. 使用更主流、通用的提示词结构如本文的RTC框架。8. 工程化最佳实践将提示词纳入开发流程对于需要集成LLM的严肃项目提示词的管理和维护至关重要。版本控制像管理代码一样用Git管理你的提示词模板。记录每次修改的原因和效果。参数化模板将提示词设计成模板将可变部分如查询、上下文参数化。例如使用Python的f-string或Jinja2模板。# 一个简单的模板示例 prompt_template 你是一位{expert_role}。 请完成以下任务{task_description}。 相关上下文{context} 请按照要求输出{output_format} # 使用时填充参数 filled_prompt prompt_template.format( expert_role数据分析师, task_description分析以下销售数据的趋势, contextsales_data_str, output_format一个包含关键发现的列表 )集中配置与管理不要将提示词硬编码在业务逻辑里。将其存放在配置文件如YAML、JSON或数据库中便于统一修改和A/B测试。监控与日志记录每次API调用的提示词和返回结果用于分析效果、排查问题和优化提示词。安全与审核建立提示词安全审核机制防止注入攻击Prompt Injection或意外生成有害内容。对用户输入进行严格的清洗和过滤。9. 总结与进阶方向提示词工程远不止是“如何问问题”。它是一个系统工程贯穿了从理解模型原理、设计交互逻辑、到集成部署和持续优化的全过程。本文核心回顾思维转变从随意聊天转向结构化工程。核心框架角色-任务-上下文RTC是构建有效提示词的基石。进阶技巧示例Few-shot和思维链CoT能显著提升复杂任务的表现。高级模式系统提示/用户提示、函数调用和智能体Agent是构建AI应用的关键。持续迭代像开发软件一样测试、评估和优化你的提示词。下一步你可以探索自动化提示词优化研究如LangChain、LlamaIndex等框架它们提供了大量提示词模板、链式调用和智能体构建工具。向量数据库与RAG深入学习如何将外部知识库与大模型结合解决模型幻觉和知识更新问题。模型微调Fine-tuning对于特定领域或任务当提示词工程达到瓶颈时可以考虑用自有数据对开源模型进行微调获得更专精、更可控的模型行为。提示词注入安全学习如何防御恶意用户通过精心构造的输入来“劫持”你的系统提示词这是一个重要的安全课题。记住最好的提示词来自于对业务的深刻理解、对任务的清晰定义以及不断的实验和迭代。现在就从为你手头的一个具体任务设计一个结构化的提示词开始吧。 30款热门AI模型一站整合DeepSeek/GLM/Qwen 随心用限时 5 折。 点击领海量免费额度
