1. 项目概述当“提示工程师”成为一项可复制的技能最近在GitHub上看到一个挺有意思的项目叫aptratcn/skill-prompt-engineer。光看这个名字就挺能反映当下AI圈的一个热门趋势——提示工程Prompt Engineering正在从一种“玄学”或“经验”逐渐沉淀为一套可学习、可复制、可系统化提升的“技能”。我自己从GPT-3时代就开始折腾各种大语言模型从早期的“调戏”式对话到后来用API做应用开发再到如今每天工作都离不开Copilot和各种AI助手。我深切地感受到与AI高效协作的能力已经和编程、数据分析一样成为了一种核心的生产力技能。但问题是这项技能怎么学网上教程要么太零散讲几个“魔法咒语”要么太理论离实际工作场景很远。这个skill-prompt-engineer项目在我看来其核心价值就在于它试图提供一个结构化的“技能树”或“知识体系”。它不只是一个简单的提示词合集而是想告诉你要成为一个合格的“提示工程师”你需要掌握哪些核心概念、遵循哪些设计原则、了解哪些高级技巧以及如何将这些知识应用到具体的场景中比如代码生成、内容创作、数据分析等。这对于任何一个想系统提升自己AI使用效率的开发者、产品经理、运营甚至是学生来说都是一个非常棒的起点和路线图。接下来我就结合自己这几年的实操经验对这个项目可能涵盖的核心内容进行一次深度拆解和扩展希望能帮你不仅知道“用什么提示词”更能理解“为什么这么写”以及“如何举一反三”。2. 提示工程的核心思维模式转变在深入具体技巧之前我们必须先完成一次思维上的“升级”。很多人把提示工程理解为“寻找正确的魔法关键词”这其实是最大的误区。高效的提示工程本质上是清晰、结构化、可迭代的沟通设计。2.1 从“命令式”到“协作式”思维传统的计算机交互是“命令式”的你输入一个精确指令机器返回一个确定结果。代码print(“Hello”)一定会输出 “Hello”。但与大语言模型LLM交互是“协作式”的你提供背景、约束和期望模型基于其“理解”生成一个“合理”的回应。这里充满了不确定性。注意不要指望LLM像编译器一样“严格执行”你的每一个字。它是在“理解”你的意图并基于海量训练数据生成“最可能”的回应。因此你的提示词是在为这种“理解”创造最佳上下文。我的实操心得把LLM想象成一个能力超强但需要明确指引的实习生。你不能只说“写份报告”而得说“我们需要一份关于Q2社交媒体营销活动的复盘报告面向部门总监。请包含以下部分1. 核心目标达成情况用数据2. 主要渠道的ROI分析3. 遇到的最大挑战及应对4. 对Q3的3条具体建议。报告风格需专业、简洁避免流水账。”2.2 提示词的四大核心要素一个高效的提示词通常需要包含以下四个要素我称之为“CRAC”框架上下文Context告诉模型它正在扮演什么角色、处于什么场景。这设定了模型的“身份”和知识边界。示例“你是一位资深的全栈开发工程师精通Python和React。”请求Request清晰、具体地说明你希望模型完成什么任务。这是提示词的核心。示例“请为以下用户需求编写一个Python函数。”约束Constraints明确输出的格式、风格、长度、禁止事项等。这是控制输出质量的关键。示例“输出格式为JSON包含code和explanation两个字段。代码需包含详细的注释解释部分不超过200字。”示例Examples可选但强烈推荐提供一两个输入-输出的例子。这是让模型快速理解你意图的最有效方式即“少样本学习”Few-Shot Learning。示例“例如对于输入‘解析CSV文件并计算平均年龄’输出应为{“code”: “import csv\n...”, “explanation”: “该函数使用csv模块...”}”避坑指南很多新手写的提示词只有“请求”缺少其他要素导致结果不稳定。下次写提示前可以心里默念一遍CRAC检查是否遗漏。3. 结构化提示设计从零构建一个可用的提示理解了核心思维我们来看如何一步步构建一个强健的提示。我们以一个常见的开发任务为例“帮我写一个Python函数从API获取天气数据并解析。”3.1 基础版提示及其问题新手可能会这样写写一个Python函数获取天气数据。这个提示的问题非常明显过于模糊。哪个API返回什么数据格式函数签名是什么如何处理错误输出结果完全随机。3.2 进阶版应用CRAC框架进行迭代让我们应用CRAC框架来迭代它。第一轮迭代增加上下文和约束你是一位专业的Python后端工程师。请编写一个函数从‘openweathermap.org’的公开API获取指定城市的当前天气数据。要求 1. 函数名为 get_current_weather。 2. 参数为 city_name (字符串) 和 api_key (字符串)。 3. 使用 requests 库。 4. 处理网络请求异常如超时、连接错误和API返回错误如城市不存在。 5. 成功时返回一个包含 temperature (摄氏度)、humidity (百分比)、description (天气描述) 的字典。 6. 失败时返回 None 或抛出明确的异常。这个版本好多了模型有了明确的角色、API端点、函数规范、错误处理和输出格式。第二轮迭代提供示例Few-Shot进一步提升稳定性你是一位专业的Python后端工程师。请编写一个函数从‘openweathermap.org’的公开API获取指定城市的当前天气数据。 【示例】 对于城市“London”和API密钥“your_key_here”成功的响应解析后应返回类似 { “temperature”: 15.5, “humidity”: 72, “description”: “light rain” } 如果城市不存在API返回 {“cod”: “404”, “message”: “city not found”}则函数应抛出 ValueError(“City not found”)。 【任务】 请根据以上示例编写函数 get_current_weather(city_name: str, api_key: str) - dict。要求使用 requests 库并妥善处理网络异常和API错误。通过提供一个成功输出的示例和一个错误处理的示例我们极大地缩小了模型输出的不确定性范围使其更贴近我们的真实需求。我的实操心得在编写复杂逻辑或特定格式的输出时“示例”的力量远大于冗长的文字描述。给模型“打个样”它能学得飞快。3.3 使用分隔符和格式指令提升可读性对于超长的提示良好的结构能帮助模型以及未来的你更好地理解各部分内容。常用的分隔符有---、###、等。### 角色设定 ### 你是一位经验丰富的系统架构师擅长设计可扩展的微服务。 ### 任务背景 ### 我们正在开发一个电子商务平台需要设计一个“订单服务”Order Service。 ### 具体请求 ### 请列出该订单服务的核心职责、必须对外提供的API接口用HTTP方法和路径表示以及它需要依赖的其他服务如用户服务、库存服务、支付服务。 ### 输出格式约束 ### 请严格按照以下Markdown表格格式输出 | 项目类别 | 具体内容 | 说明 | | :--- | :--- | :--- | | 核心职责 | 1. ...br2. ... | 用序号列表 | | 对外API | POST /ordersbrGET /orders/{id} | 用代码块样式 | | 依赖服务 | 服务名交互方式如RPC/消息 | 简要描述 |这种结构清晰的提示不仅模型处理起来更准确也便于你自己维护和修改。4. 高级技巧与模式超越基础对话掌握了结构化设计就可以探索一些更高级的模式来解决复杂问题。4.1 思维链Chain-of-Thought, CoT对于需要推理、计算或多步骤的问题直接问答案效果往往不好。引导模型“一步步思考”能极大提升复杂任务的准确性。普通提问小明有5个苹果他吃了2个又买了3包苹果每包4个他现在一共有几个苹果模型可能直接给出一个答案但过程是黑箱的错了也不知道哪一步有问题。使用CoT提示请逐步推理以下问题 小明最初有5个苹果。 第一步他吃了2个那么他还剩下几个苹果请先计算这一步。 第二步他买了3包苹果每包有4个那么他新买了多少个苹果请计算这一步。 第三步将第一步剩下的苹果和第二步新买的苹果加起来总数是多少 请按照以上三步一步步给出你的推理过程和最终答案。通过强制模型展示中间步骤我们不仅能得到更可靠的答案还能在模型推理出错时精准定位问题所在。在代码调试、数学计算、逻辑分析等场景下CoT是必备技巧。4.2 自动提示优化Self-Refine有时候我们不确定自己的提示词是否最优。可以让模型自己评估和优化提示词。你可以设计这样一个工作流任务给模型一个初始提示和其生成的输出。分析要求模型以提示工程师的身份分析这个初始提示有哪些可以改进的地方如是否模糊缺少约束示例不足。优化让模型根据分析输出一个优化后的、更好的提示词版本。这相当于让AI成为了你的“提示词教练”通过几轮迭代你能快速学习到优化提示词的思路。4.3 系统指令System Prompt与用户指令User Prompt的分离在通过API使用模型时如OpenAI API通常可以设置一个“系统”消息来定义模型的长期行为和人设而“用户”消息则是具体的本次请求。这比把所有东西都塞进一条用户消息更清晰、更强大。系统提示设定角色和全局规则你是一个乐于助人且严谨的代码助手。你总是用Python回答问题除非特别要求使用其他语言。你输出的代码必须简洁、高效并包含必要的错误处理。在解释概念时优先使用类比的方式让初学者理解。用户提示本次具体请求请解释一下Python中的装饰器Decorator是什么并给一个记录函数运行时间的实用例子。这种分离使得“角色设定”可以在一段对话中持续生效而不需要在每个问题中都重复。5. 场景化实战提示工程在具体领域的应用理论说再多不如看实战。我们选取几个典型场景看看如何应用上述原则。5.1 场景一代码生成与调试目标生成一个Flask API端点接收用户ID从数据库查询用户信息并返回。初级提示写一个Flask的GET接口查用户。优化后的提示你是一位精通Flask和SQLAlchemy的后端工程师。请创建一个Flask应用的API端点。 ### 背景 ### - 项目使用 Flask SQLAlchemy (ORM) 连接 PostgreSQL 数据库。 - 已存在一个 User 模型包含 id (Integer, Primary Key), username (String), email (String) 字段。 - 数据库会话对象为 db.session。 ### 任务 ### 1. 编写一个名为 get_user_by_id 的视图函数。 2. 路由为 GET /api/users/int:user_id。 3. 功能根据传入的 user_id 查询对应用户。 4. 如果用户存在返回JSON格式{“id”: …, “username”: …, “email”: …}HTTP状态码200。 5. 如果用户不存在返回JSON格式{“error”: “User not found”}HTTP状态码404。 6. 必须包含基本的异常处理如数据库查询异常异常时返回500状态码和通用错误信息。 7. 请为关键步骤添加简要的代码注释。 请直接输出完整的Python函数代码。要点分析明确技术栈指定了Flask、SQLAlchemy、PostgreSQL避免了模型猜测成Django或纯SQL。设定前提说明了已有的User模型和db.session让生成的代码能无缝嵌入假设的项目环境。详细约束明确了路由、函数名、成功/失败的不同响应格式和状态码这是生成生产可用代码的关键。要求健壮性明确要求异常处理这是新手容易忽略而资深工程师一定会考虑的点。5.2 场景二内容创作与润色目标将一篇生硬的技术博客草稿润色得更加生动、易懂。初级提示把这篇文章写得好读一点。优化后的提示你是一位科技专栏的资深编辑擅长将深奥的技术内容转化为普通开发者感兴趣且能读懂的文章。 ### 原文片段 ### “本文阐述了在分布式系统中实现最终一致性的方法论。通过采用异步复制与冲突解决机制系统能够在网络分区的情形下维持数据可用性并保障在未来的某个时间点达成数据状态的一致性。” ### 润色要求 ### 1. **风格**口语化、生动可以适当使用比喻。目标读者是有一到三年经验的软件工程师。 2. **结构**保留原意但改变句式避免长句和被动语态。 3. **目的**让读者一眼就明白“最终一致性”解决了什么问题以及它的核心思路是什么。 4. **输出**请直接输出润色后的段落。 例如你可以这样开头“想象一下在一个遍布全球的电商系统里你在北京下单买了一本书而库存数据却更新在美国的服务器上...”要点分析定义编辑角色“科技专栏资深编辑”设定了专业的润色视角。明确目标读者“一到三年经验的软件工程师”这决定了用词的深浅和解释的详细程度。给出具体修改方向“口语化、生动、用比喻、避免长句和被动语态”这是可执行的指令而不是模糊的“好读一点”。提供启发式示例给出的例子不仅展示了风格更展示了一种“从场景切入”的叙述方式能有效引导模型的输出方向。5.3 场景三数据分析与洞察目标给出一组销售数据让AI帮忙分析趋势并提出建议。初级提示分析一下这份销售数据。优化后的提示你是一位数据分析专家擅长从数据中发现商业洞察。请分析以下2023年Q1的月度销售数据 | 月份 | 产品A销售额万 | 产品B销售额万 | 线上渠道占比 | 客单价元 | | :--- | :--- | :--- | :--- | :--- | | 1月 | 120 | 80 | 65% | 450 | | 2月 | 115 | 85 | 68% | 440 | | 3月 | 130 | 75 | 72% | 460 | ### 分析要求 ### 1. **趋势描述**用一两句话概括Q1的整体销售趋势。产品A和产品B的表现有何不同 2. **关联洞察**观察“线上渠道占比”和“客单价”的变化它们之间或与销售额之间是否存在值得注意的关联 3. **问题诊断**基于数据指出一个可能存在的潜在问题或风险。 4. **行动建议**针对你诊断出的问题提出1-2条具体、可操作的下季度Q2业务建议。 请将分析结果组织成一份简短的报告分点陈述语言精炼。要点分析结构化输入数据使用表格清晰地提供数据便于模型解析。分步骤提问将复杂的“分析”拆解成“趋势描述”、“关联洞察”、“问题诊断”、“行动建议”四个子任务引导模型进行系统性的思考避免回答笼统。要求输出格式“简短的报告分点陈述”这确保了回答的可用性可以直接粘贴到邮件或文档中。6. 工具、评估与迭代构建你的提示工作流掌握了方法还需要好的工具和习惯来落地。6.1 工具推荐提示词管理不要只用聊天窗口。使用笔记软件如Notion、Obsidian、专门的提示词管理工具如PromptSource、自己建的数据库或代码编辑器来保存和分类你的优质提示词模板。为它们打上标签如#代码生成、#内容润色、#CoT。版本控制像管理代码一样管理你的重要提示词。使用Git来记录提示词的迭代过程备注每次修改的原因和效果。skill-prompt-engineer这类项目本身就是一个开源的知识库。API PlaygroundOpenAI Playground、Claude Console等平台提供了更丰富的参数调整如温度Temperature、最大生成长度Max tokens和对比测试功能是优化提示词的绝佳实验场。6.2 如何评估提示词的好坏没有一个绝对标准但可以从以下几个维度考量评估维度说明检查方法清晰度提示词本身是否无歧义易于理解让一个同事看你的提示词看他是否能准确说出你想要什么。可靠性在相同提示下模型多次输出的结果是否一致、稳定用同样的提示词温度设为0运行3-5次观察输出变化。有效性输出结果是否高质量地完成了任务对照你的原始需求检查输出内容的准确性、完整性和实用性。效率是否用最精炼的语言传达了必要信息尝试删减提示词中的冗余词句看输出质量是否下降。可复用性这个提示词模板是否能稍作修改就应用到类似任务上尝试替换其中的关键参数如主题、格式看是否依然有效。6.3 迭代流程持续改进你的提示提示工程是一个动态过程。我常用的迭代闭环是起草根据CRAC框架写出第一版提示。测试在Playground或实际场景中运行获取输出。评估对照“评估维度”检查输出找出不足如格式不对、缺少细节、有幻觉。归因分析是提示词的哪个部分导致了问题是上下文不清约束不足还是示例有误导。修正有针对性地修改提示词回到第2步。归档将最终稳定的提示词版本和评估结果保存到你的知识库中。例如如果模型生成的代码没有错误处理我就在“约束”部分加上“必须包含异常处理”。如果模型总是忽略我要求的Markdown格式我就提供一个更清晰的格式示例甚至把部分格式用“占位符”先写出来。7. 常见问题与避坑指南在实际操作中你会遇到各种各样的问题。这里记录一些我踩过的坑和解决方案。7.1 模型“幻觉”与事实错误这是最常见的问题模型会自信地生成错误信息或编造不存在的引用。应对策略要求提供来源/依据在提示中要求“基于已知的公开信息”或“如果你不确定请说明”。分步验证对于关键事实或数据让模型先输出其“推理依据”或“查找步骤”你再进行人工核查。外部知识库对于专业领域先将相关知识喂给模型通过长上下文或检索增强生成RAG再让它基于这些材料回答。终极方案永远不要完全信任AI生成的事实性内容尤其是法律、医疗、金融等关键领域。AI是强大的协作者而非权威的信息源。7.2 输出格式不听话明明要求了JSON模型却输出了一段文字。应对策略强化格式指令在提示的开头和结尾都强调格式要求。例如“你的输出必须是且仅是一个合法的JSON对象不要有任何额外的解释文字。”提供结构化示例这是最有效的方法。在提示中给出一个完整的、符合格式要求的输入-输出示例。使用系统提示在API调用中将严格的格式要求放在system消息中作为模型的“基础设定”。后处理对于简单格式可以编写一个后处理脚本用正则表达式从输出中提取所需结构。但这只是补救措施。7.3 提示词过于冗长导致性能下降或遗忘上下文长度有限过长的提示词可能导致模型忘记开头的内容或者响应速度变慢、成本增高。应对策略精简语言删除所有不必要的客套话、重复解释。使用缩写和符号在模型能理解的前提下用更简洁的方式表达。例如用“-”表示映射关系。分步对话将复杂任务拆分成多个子任务通过多轮对话完成。上一轮的输出可以作为下一轮的上下文。总结长文档如果需要基于长文档分析先让模型对文档进行摘要再基于摘要进行后续操作。7.4 如何应对“我不知道”或拒绝回答有时模型会因安全策略或知识盲区而拒绝回答。应对策略重构问题将敏感或可能被拒绝的问题转化为一个假设性的、学术性的或类比性的问题。例如不问“如何破解某个系统”而是问“从网络安全教育角度常见的系统身份验证机制有哪些脆弱性”赋予专业角色让模型扮演一个允许讨论该话题的角色如“作为一位网络安全研究员在学术讨论的范围内...”。分解问题将一个大问题分解成几个中性、技术性的子问题。说到底aptratcn/skill-prompt-engineer这个项目指向的不是一堆死记硬背的“咒语”而是一种全新的、与智能体协作的思维方式和工作方法。它要求我们像产品经理一样思考需求像老师一样设计教学大纲像架构师一样规划交互流程。这项技能的核心不是“操控”AI而是如何最清晰、最无歧义地表达人类的意图并引导AI将其转化为高质量的创造。随着模型能力的进化提示工程本身也在变化但底层这种“结构化沟通”和“迭代优化”的能力将会长期成为人机协同时代的核心竞争力。