同样一个需求有人对着对话框敲一句话等模型“自由发挥”有人会先拆问题、补背景、定格式、给示例再把结果拉回来逐条验收。两边拿到的东西质量可能差一个量级。这个差距不在运气也不在“会不会用 AI”而在对 Prompt 工程的理解程度。这篇文章不聊某个新模型也不推荐某个一键包而是把“AI 高手”和普通用户之间那层 prompt 差距拆开讲清楚差距体现在哪几个维度、高手写 prompt 时到底在做什么、怎么用一套流程稳定写出高质量提示词、以及如何通过 API 批量评测 prompt而不是靠一次两次“感觉还行”就收工。如果你是做内容、写代码、做数据分析或者正在搭 Agent、RAG 应用但觉得模型输出总是不稳定这篇文章可以直接收藏。下面进入正题。1. 普通人 vs AI 高手prompt 差距到底在哪先看一个最常见的需求写一份项目复盘报告。普通用户可能会写“帮我写一份项目复盘报告。”高手会先在心里做几层拆解这份报告给谁看老板、客户还是团队内部项目背景是什么成功还是失败需要哪些模块结论、数据、问题分析、下一步计划有没有必须包含的关键信息输出格式是完整报告、要点列表还是可以直接贴到 PPT 里的提纲最后写出来的 prompt 可能是“你是一名有 10 年经验的产品项目负责人。背景我们做了一款企业内部协作工具原计划 6 个月上线实际上用了 8 个月中间经历了需求变更和团队人员调整。请输出一份项目复盘报告包含项目概况、目标达成情况、时间线与里程碑、核心问题与根因分析、经验教训、后续改进计划。面向对象是公司管理层语气专业、简洁不要用空话套话优先使用具体数据和事实。输出 Markdown 格式控制在 800 字以内。”两者看起来只是“一段话”和“一段更长的话”的区别实际上背后是完全不同的思考方式。对比维度普通用户做法AI 高手做法本质问题目标定义只说要做什么说清楚给谁看、解决什么问题、验收标准是什么目标不明确模型只能猜上下文补充直接提问补充背景、角色、限制条件、已有信息缺少上下文模型用默认知识填补任务拆解一句话概括拆成若干子任务并给出顺序大任务容易糊拆开才可控输出约束不写格式指定格式、篇幅、语气、引用要求没有约束输出风格随机调试方式结果不行就重问记录问题、改 prompt、小范围回归没有迭代只能碰运气验证意识看一眼觉得行就行用测试集批量验证统计成功率单次结果没有说服力系统化程度每次重新写沉淀模板、维护版本、接入流程不可复用每次从零开始从这张表能看出来AI 高手不是“会写长句子”而是把写 prompt 当成了一个工程问题。Prompt 工程就是围绕“如何稳定获得预期输出”建立的一套方法而不是某个神奇的万能句式。2. AI 高手级 Prompt 写作能力速览如果你想把 prompt 水平快速拉高可以先对照下面这份能力清单看看自己缺哪一块能力项说明对结果的影响需求澄清写 prompt 前先确认目标、受众、背景、限制、验收标准决定模型是“猜”还是“准确执行”角色设计给模型一个具体身份和工作背景显著影响语气、知识范围、回答深度任务拆解把复杂任务拆成多个小步骤降低逻辑混乱和漏项概率上下文构造把需要的信息放进 system prompt 或上下文窗口决定模型有没有足够依据回答输出格式控制明确 Markdown、JSON、表格、字数、层级让输出直接可用而不是再人工清洗示例驱动放一个或多个输入输出示例比单纯描述格式更有效约束与反例明确“不要做什么”列出避免的行为减少套话、编造和越界内容版本化与评测把 prompt 当代码管理建立小测试集批量验证保证修改一版 prompt 后其他场景不退化这套能力并不依赖某个特定模型。换 GPT、Claude、国产模型或者本地开源模型方法框架都是通用的只是模型能力越强容错率越高模型能力越弱越需要你把 prompt 写细。3. 适用场景与使用边界Prompt 工程适合谁大概包括这几类人内容创作者写文章、脚本、标题、文案需要稳定风格和结构。开发者用 AI 生成代码、做 Code Review需要输出可执行的代码而不是“建议”。产品经理 / 运营用 AI 做用户调研分析、竞品拆解、需求文档需要结构化输出。Agent 开发者写 system prompt、工具说明、任务路由规则prompt 质量决定 Agent 成功率。技术博主 / 讲师需要用多组 prompt 对比演示不能只靠运气。不适合谁如果你是那种“只要点一下按钮AI 就必须 100% 完美输出”的人那 Prompt 工程帮不了你。就算是最好的 prompt也不能保证大模型每次都完全一致需要配合温度参数、模型选择、输出校验和后处理。使用边界必须强调Prompt 不能用来绕过模型服务商的内容安全策略。如果 API 返回类似“your prompt was flagged as potentially violating our usage policy”的报错正确做法是检查自己写的提示词是否涉及违规内容并调整表述而不是封装“绕过滤”的模板。另外不要在 prompt 里上传未脱敏的个人信息、密钥、内部敏感文档。大模型会把这些内容发送到对应模型服务商可能无法做到完全私有化。涉及人脸、声音、商标、版权素材时还要确认是否有合法授权尤其是生成对外发布的内容。4. 从需求到高质量 Prompt 的五步流程下面是一套偏向通用工程化的写法每一步都可以直接用于你的日常工作。4.1 第一步澄清需求不要直接写 prompt在对话框里输入之前先回答 5 个问题这个任务的目标是什么受众是谁我掌握了哪些背景信息有什么限制条件什么样的输出算“合格”很多人跳过了第 1 步直接让 AI“写一篇周报”结果模型写出来的往往是泛泛的“本周完成了多项工作”句式。你实际上需要的是“面向部门周会的增量信息汇报”那就应该在 prompt 里说清楚。4.2 第二步设定角色与上下文角色不是装饰而是给模型一个“行为坐标系”。例如“你是一名资深后端工程师擅长 Java 和分布式系统。”“你是一名面向 C 端用户的公众号编辑讲究标题有信息量。”“你是一名数据分析师回答必须基于给定的数据表不能编造数字。”上下文则包括项目背景、已有信息、用户画像、时间范围。写上下文的原则是“只放与任务直接相关的信息避免无关长文本撑爆上下文窗口”。4.3 第三步拆分任务必要时排序如果是复杂任务不建议让模型一步完成。比如“帮我分析这份用户访谈记录并产出一份产品改进方案”属于大而全结果容易不聚焦。可以拆成先提取用户反馈中的高频问题对每个问题按严重程度排序针对 Top 3 问题给出改进方向最后输出一份带优先级的产品改进清单。在 prompt 里明确“先……再……最后……”模型会更容易按照顺序执行逻辑也更稳定。4.4 第四步明确输出格式与约束这是投入产出比最高的一步。很多普通用户觉得 AI 输出“不够好看”其实只是在 prompt 里少了一句“输出 Markdown 表格”或“控制在 500 字以内”。格式描述要具体“用 Markdown 表格输出”“每一条建议控制在 50 字以内”“先给结论再给原因”“代码块必须包含完整可运行示例”“不要使用‘首先/其次/最后’这类过渡词”约束要写限制也要写反例。比如你想让模型不要编造数据可以写“如果数据来源不足直接说明无法回答不要推测具体数值”。4.5 第五步给示例建立“参照系”示例是最强的控制方式。与其用文字描述“我希望你语气轻松一点”不如给一段示例“期望风格示例这个功能上线第一天就崩了复盘完发现不是代码问题而是需求阶段没有定义清楚边界。下面是我的完整梳理……”模型看过示例之后语气、结构、详略都会向你给的方向靠拢。5. 一套可复用的“高手级 Prompt 模板”把上面五步放进一个通用模板里就是你以后写复杂 prompt 的骨架。下面是一个 system prompt 结构示例可以直接替换字段后使用{ system_prompt: { role: 你是一名{具体角色}擅长{核心能力范围}。, context: 背景信息{项目/用户/业务背景}。, task: 请完成以下任务\n1. {子任务1}\n2. {子任务2}\n3. {子任务3}, format: 输出要求{Markdown/JSON/表格}{字数限制}{语气要求}。, constraints: 限制条件{禁止事项}。{当信息不足时如何应对}。, example: 参考示例\n输入{示例输入}\n输出{示例输出}, acceptance: 验收标准输出必须包含{关键要素}且满足{可衡量条件}。 } }实际使用时把这一段作为 system prompt 塞入 API 或 Web 对话框。下面是一个填好的例子“你是一名资深的 To B SaaS 产品经理擅长需求分析和功能优先级排序。背景我们正在设计一个客服工单系统客户反馈最多的是‘历史工单检索太慢’。请完成以下任务1. 分析历史工单检索慢的 5 个可能原因2. 针对每个原因给出对应的产品方案3. 按开发成本从低到高排序。输出要求使用 Markdown 表格表格列依次为‘可能原因、影响程度、产品方案、开发成本、优先级’。限制条件不要提“增加缓存”这种无法落地的泛泛方案方案要具体到功能设计层面。如果信息不足以判断原因可以提出需要进一步排查的数据指标不要强行下结论。”这个 prompt 已经把所有关键信息都固定下来即使换一个模型大概率也能得到结构一致的结果。6. 用 API 批量评测 Prompt 效果高手和普通用户还有一个关键差别普通用户看一次两次效果高手会把 prompt 放到一组测试用例上批量跑记录成功率。单次对话判断不出 prompt 好坏原因是大模型有随机性。同一个 prompt同样参数两次结果可能不完全一样。所以更可靠的做法是准备一个小型测试集例如 10 到 20 条代表性的输入然后批量调用 API逐条检查输出。下面给出一个通用的 Python 批量评测脚本接口路径和模型名需要按你自己使用的服务商调整。import os import time import requests API_URL os.getenv(API_URL, https://your-endpoint/v1/chat/completions) API_KEY os.getenv(API_KEY, ) SYSTEM_PROMPT 你是一名资深产品经理。 请根据用户输入输出一份包含【问题分析】和【改进建议】的结构化回答。 要求使用 Markdown 格式结论先行总字数控制在 300 字以内。 TEST_CASES [ 我们产品的注册转化率只有 2%你觉得问题出在哪, 用户反馈上传文件经常失败想知道怎么排查。, 新版本上线后老用户投诉操作路径变长怎么处理, ] def chat(system_prompt: str, user_content: str) - tuple: resp requests.post( API_URL, headers{Authorization: fBearer {API_KEY}}, json{ model: your-model, messages: [ {role: system, content: system_prompt}, {role: user, content: user_content}, ], temperature: 0.3, }, timeout120, ) resp.raise_for_status() data resp.json() content data[choices][0][message][content] usage data.get(usage, {}) return content, usage for idx, case in enumerate(TEST_CASES, start1): print(f 测试用例 {idx} ) print(f输入{case}) try: output, usage chat(SYSTEM_PROMPT, case) print(f输出{output[:500]}) print(ftoken 统计prompt{usage.get(prompt_tokens)}, completion{usage.get(completion_tokens)}) except Exception as e: print(f调用失败{e}) print() time.sleep(1)跑完之后不要只凭感觉打分。可以给每一条输出标记“通过 / 不通过”然后计算通过率。例如 20 条用例通过 17 条那这个 prompt 版本的通过率就是 85%。改动 prompt 后再跑一轮通过率是否下降一清二楚。如果你用的是命令行环境也可以用 curl 快速验证 API 是否连通curl -X POST $API_URL \ -H Authorization: Bearer $API_KEY \ -H Content-Type: application/json \ -d { model: your-model, messages: [ {role: system, content: 你是一个技术文档工程师。请用表格输出总共不超过5行。}, {role: user, content: 列出3种让程序启动变慢的常见原因。} ] }批量评测最大的价值不是证明某个 prompt“最好”而是防止你改进 A 场景时破坏了 B 场景。没有测试集的 prompt 改动本质上是裸奔。7. 常见 Prompt 错误与排查下面这些是我在平时项目中比较常见的 prompt 问题和排查方向你可以对照使用问题现象可能原因排查方向改进方式输出过于泛泛目标不明确缺少背景和约束检查 prompt 是否写清了受众、用途、限制条件补充任务背景、输出要求、反例模型开始编造数据上下文缺少真实数据任务逼模型“给数字”检查是否提供了准确数据来源明确“没有数据时直接说不确定”输出格式不稳定没有指定格式或格式描述有歧义观察不同轮次格式差异直接给出 Markdown/JSON 示例回答太长或太短没有字数限制或模型对“简短”理解不稳定统计以往输出长度给出具体字数范围并附示例逻辑顺序混乱任务过大没有拆解子步骤观察模型是否跳步、漏点用“先……再……最后……”拆解任务每次结果差异大温度设置过高或 prompt 约束不足检查推理参数和 prompt 确定性降低 temperature增加格式与约束请求被内容策略拦截prompt 触发了服务商安全策略看返回错误信息中的策略提示修改表述遵守平台使用条款不要绕过上下文窗口超限塞了太多历史信息或大段文档检查 token 数量是否接近上限只保留与任务相关的内容或改用 RAG排查的思路其实和调试代码一样先看输入再看参数再看输出。不要一上来就怀疑“模型不行”。大部分情况模型只是根据你给的有限信息做了最合理的猜测。8. 从 Prompt 到 Skill、Agent 与 RAGPrompt 工程做到后面很多“AI 高手”已经不是单纯写一个 prompt而是把 prompt 放进更大的系统里。8.1 Prompt 与 Skill 的区别简单来说Prompt 是一段提示文本Skill 是把提示词、参数、工作流、校验逻辑打包在一起的一个可复用能力单元。在 Dify、Coze、FastGPT 这类平台上你可以把一个“周报生成 Skill”定义成包含固定 system prompt、输入字段模板、输出格式校验、甚至后续的数据处理步骤。这样在多个应用里复用而不是每次复制粘贴一段文字。8.2 Prompt 与 Agent 的分工Agent 和普通一问一答的区别在于它会规划、调用工具、观察结果、再继续执行。但你让 Agent 执行任务之前依然要写好 system prompt。它负责“指挥”prompt 负责“告诉它怎么指挥”。如果想让 Agent 稳定系统提示词里至少要包含Agent 的角色和目标可以调用哪些工具工具使用规则什么情况下调用哪个工具执行完工具后如何处理结果最终输出需要满足的格式8.3 Prompt 与 RAG 结合RAG 场景中的一个常见坑是模型拿到了检索内容但还是会按自己的“常识”自由发挥。解决方法是把“只能基于检索内容回答”写进 prompt。下面是一个 LangChain 风格的模板示意实际代码取决于你安装的 LangChain 版本from langchain.prompts import PromptTemplate rag_prompt PromptTemplate( template请基于以下检索到的资料回答问题。 背景{context} 问题{question} 规则 1. 只能使用资料中出现的信息 2. 如果资料不足以回答问题请直接回答“资料中没有相关信息”不要推测 3. 输出不超过 200 字使用简洁的中文。 参考资料 {context} , input_variables[context, question], ) formatted rag_prompt.format( context客服工单系统平均响应时长为 35 分钟超过 80% 用户的期望阈值。, question当前客服响应时长表现如何, ) print(formatted)这里的核心不是 LangChain API 本身而是“限制信息来源 承认不确定性”这两个约束。不管用什么框架都要保留这两条规则。至于 MCPModel Context Protocol则是把工具、资源和 prompt 统一成一种上下文协议让模型服务端可以稳定调用外部能力。它的具体接口会持续演进使用前先查对应文档不要照搬旧代码。9. 成本、延迟与资源观察Prompt 工程不只是“写词”还包括性能和成本意识。9.1 Token 消耗观察每次 API 调用返回里通常带有 usage 字段里面包含 prompt_tokens、completion_tokens。你需要关心两个数prompt_tokens你输入的 prompt 长度 测试数据长度。completion_tokens模型输出长度。如果 prompt 写得很长每次调用都要支付这部分 token在批量测试 20 条甚至更多用例时成本会被放大。长 prompt 如果带来明显收益可以接受如果只是一堆无关上下文建议删掉。9.2 延迟观察模型的输出延迟主要来自输出 token 数量。你要求“写一篇 3000 字的文章”和“输出 5 条要点”耗时差别会很大。在 Agent 场景里长时间等待还会拖垮整个流程。一个常见手法是分阶段主流程让模型输出精简结果需要长文时再单独调用一次生成完整内容。9.3 本地模型资源观察如果你在本地跑开源模型就不要只看 API 的 token 统计还要看显存和内存占用。可用的命令模板如下nvidia-smi重点观察显存使用率是否接近显卡上限。不同量化级别、不同上下文长度、不同并发数都会影响占用。实际数字需要以你本机的模型和参数为准不要照搬别人的“4G 够用”或“8G 不够”结论。降低本地资源占用通常可以从这几个方向入手使用量化模型、缩短上下文、降低 batch size、使用流式输出避免一次性生成过长内容。10. Prompt 工程最佳实践最后整理几条能在日常工作中直接落地的建议第一次测试先小参数运行。不要一开始就要求模型生成 5000 字长文先用 200 到 300 字验证结构是否正确。把 prompt 当代码管理。每次修改记录版本号写清楚改了什么。Prompt 文件放入 Git和代码一起维护。保留一套最小可运行配置。当你后面改了十几个版本后回退就靠它。建立小测试集。10 到 20 条覆盖典型场景的用例每次改 prompt 都要跑一遍。输入素材、输出结果、测试集分开目录管理。项目结构建议如下prompt-project/ prompts/ v1_system_prompt.txt v2_system_prompt.txt tests/ test_cases.json results_v2.csv outputs/ run_20250101/批量任务要加日志和失败重试。API 偶尔会超时脚本里要做异常捕获和重试。接口服务要限制访问范围。不要把带 API Key 的测试脚本暴露到公网不要提交包含密钥的代码到仓库。涉及人脸、声音、品牌、版权素材时确认授权后再生成和发布。发布或商用前做一次人工复核。Prompt 能够提高效率但不能完全替代人对内容的判断。11. 总结与下一步回到开头的问题你跟 AI 高手的 prompt 水平差距有多大从工具链和技术栈看其实没有不可逾越的鸿沟。差距主要在三件事一是有没有把模糊需求转换成结构化指令二是有没有建立测试集来验证 prompt 而不是靠感觉三是有没有把 prompt 沉淀成可复用的模板和流程。建议你先做三件事把文中给的通用模板填成自己业务场景的第一个版本找 10 条真实需求组成小测试集写一个 20 行的 Python 脚本批量跑一遍记录成功率。这三步做完你再回头看之前“一句话问 AI”的方式基本就回不去了。后续可以继续往三个方向扩展一是从单轮 prompt 走向多轮 Agent配合工具调用解决更复杂的任务二是把 prompt 放进 RAG 链路中让模型基于私有知识回答三是把常用能力封装成 Skill在业务系统里复用。Prompt 工程不是“背模板”而是建立一套写作、调试、评测、迭代的闭环。把这套闭环跑起来之后模型能力仍然会变但对结果质量的掌控力始终在你手里。建议收藏备用下次写 prompt 的时候拿出来对照检查一遍。
Prompt工程：从普通人到AI高手的系统化提升指南
同样一个需求有人对着对话框敲一句话等模型“自由发挥”有人会先拆问题、补背景、定格式、给示例再把结果拉回来逐条验收。两边拿到的东西质量可能差一个量级。这个差距不在运气也不在“会不会用 AI”而在对 Prompt 工程的理解程度。这篇文章不聊某个新模型也不推荐某个一键包而是把“AI 高手”和普通用户之间那层 prompt 差距拆开讲清楚差距体现在哪几个维度、高手写 prompt 时到底在做什么、怎么用一套流程稳定写出高质量提示词、以及如何通过 API 批量评测 prompt而不是靠一次两次“感觉还行”就收工。如果你是做内容、写代码、做数据分析或者正在搭 Agent、RAG 应用但觉得模型输出总是不稳定这篇文章可以直接收藏。下面进入正题。1. 普通人 vs AI 高手prompt 差距到底在哪先看一个最常见的需求写一份项目复盘报告。普通用户可能会写“帮我写一份项目复盘报告。”高手会先在心里做几层拆解这份报告给谁看老板、客户还是团队内部项目背景是什么成功还是失败需要哪些模块结论、数据、问题分析、下一步计划有没有必须包含的关键信息输出格式是完整报告、要点列表还是可以直接贴到 PPT 里的提纲最后写出来的 prompt 可能是“你是一名有 10 年经验的产品项目负责人。背景我们做了一款企业内部协作工具原计划 6 个月上线实际上用了 8 个月中间经历了需求变更和团队人员调整。请输出一份项目复盘报告包含项目概况、目标达成情况、时间线与里程碑、核心问题与根因分析、经验教训、后续改进计划。面向对象是公司管理层语气专业、简洁不要用空话套话优先使用具体数据和事实。输出 Markdown 格式控制在 800 字以内。”两者看起来只是“一段话”和“一段更长的话”的区别实际上背后是完全不同的思考方式。对比维度普通用户做法AI 高手做法本质问题目标定义只说要做什么说清楚给谁看、解决什么问题、验收标准是什么目标不明确模型只能猜上下文补充直接提问补充背景、角色、限制条件、已有信息缺少上下文模型用默认知识填补任务拆解一句话概括拆成若干子任务并给出顺序大任务容易糊拆开才可控输出约束不写格式指定格式、篇幅、语气、引用要求没有约束输出风格随机调试方式结果不行就重问记录问题、改 prompt、小范围回归没有迭代只能碰运气验证意识看一眼觉得行就行用测试集批量验证统计成功率单次结果没有说服力系统化程度每次重新写沉淀模板、维护版本、接入流程不可复用每次从零开始从这张表能看出来AI 高手不是“会写长句子”而是把写 prompt 当成了一个工程问题。Prompt 工程就是围绕“如何稳定获得预期输出”建立的一套方法而不是某个神奇的万能句式。2. AI 高手级 Prompt 写作能力速览如果你想把 prompt 水平快速拉高可以先对照下面这份能力清单看看自己缺哪一块能力项说明对结果的影响需求澄清写 prompt 前先确认目标、受众、背景、限制、验收标准决定模型是“猜”还是“准确执行”角色设计给模型一个具体身份和工作背景显著影响语气、知识范围、回答深度任务拆解把复杂任务拆成多个小步骤降低逻辑混乱和漏项概率上下文构造把需要的信息放进 system prompt 或上下文窗口决定模型有没有足够依据回答输出格式控制明确 Markdown、JSON、表格、字数、层级让输出直接可用而不是再人工清洗示例驱动放一个或多个输入输出示例比单纯描述格式更有效约束与反例明确“不要做什么”列出避免的行为减少套话、编造和越界内容版本化与评测把 prompt 当代码管理建立小测试集批量验证保证修改一版 prompt 后其他场景不退化这套能力并不依赖某个特定模型。换 GPT、Claude、国产模型或者本地开源模型方法框架都是通用的只是模型能力越强容错率越高模型能力越弱越需要你把 prompt 写细。3. 适用场景与使用边界Prompt 工程适合谁大概包括这几类人内容创作者写文章、脚本、标题、文案需要稳定风格和结构。开发者用 AI 生成代码、做 Code Review需要输出可执行的代码而不是“建议”。产品经理 / 运营用 AI 做用户调研分析、竞品拆解、需求文档需要结构化输出。Agent 开发者写 system prompt、工具说明、任务路由规则prompt 质量决定 Agent 成功率。技术博主 / 讲师需要用多组 prompt 对比演示不能只靠运气。不适合谁如果你是那种“只要点一下按钮AI 就必须 100% 完美输出”的人那 Prompt 工程帮不了你。就算是最好的 prompt也不能保证大模型每次都完全一致需要配合温度参数、模型选择、输出校验和后处理。使用边界必须强调Prompt 不能用来绕过模型服务商的内容安全策略。如果 API 返回类似“your prompt was flagged as potentially violating our usage policy”的报错正确做法是检查自己写的提示词是否涉及违规内容并调整表述而不是封装“绕过滤”的模板。另外不要在 prompt 里上传未脱敏的个人信息、密钥、内部敏感文档。大模型会把这些内容发送到对应模型服务商可能无法做到完全私有化。涉及人脸、声音、商标、版权素材时还要确认是否有合法授权尤其是生成对外发布的内容。4. 从需求到高质量 Prompt 的五步流程下面是一套偏向通用工程化的写法每一步都可以直接用于你的日常工作。4.1 第一步澄清需求不要直接写 prompt在对话框里输入之前先回答 5 个问题这个任务的目标是什么受众是谁我掌握了哪些背景信息有什么限制条件什么样的输出算“合格”很多人跳过了第 1 步直接让 AI“写一篇周报”结果模型写出来的往往是泛泛的“本周完成了多项工作”句式。你实际上需要的是“面向部门周会的增量信息汇报”那就应该在 prompt 里说清楚。4.2 第二步设定角色与上下文角色不是装饰而是给模型一个“行为坐标系”。例如“你是一名资深后端工程师擅长 Java 和分布式系统。”“你是一名面向 C 端用户的公众号编辑讲究标题有信息量。”“你是一名数据分析师回答必须基于给定的数据表不能编造数字。”上下文则包括项目背景、已有信息、用户画像、时间范围。写上下文的原则是“只放与任务直接相关的信息避免无关长文本撑爆上下文窗口”。4.3 第三步拆分任务必要时排序如果是复杂任务不建议让模型一步完成。比如“帮我分析这份用户访谈记录并产出一份产品改进方案”属于大而全结果容易不聚焦。可以拆成先提取用户反馈中的高频问题对每个问题按严重程度排序针对 Top 3 问题给出改进方向最后输出一份带优先级的产品改进清单。在 prompt 里明确“先……再……最后……”模型会更容易按照顺序执行逻辑也更稳定。4.4 第四步明确输出格式与约束这是投入产出比最高的一步。很多普通用户觉得 AI 输出“不够好看”其实只是在 prompt 里少了一句“输出 Markdown 表格”或“控制在 500 字以内”。格式描述要具体“用 Markdown 表格输出”“每一条建议控制在 50 字以内”“先给结论再给原因”“代码块必须包含完整可运行示例”“不要使用‘首先/其次/最后’这类过渡词”约束要写限制也要写反例。比如你想让模型不要编造数据可以写“如果数据来源不足直接说明无法回答不要推测具体数值”。4.5 第五步给示例建立“参照系”示例是最强的控制方式。与其用文字描述“我希望你语气轻松一点”不如给一段示例“期望风格示例这个功能上线第一天就崩了复盘完发现不是代码问题而是需求阶段没有定义清楚边界。下面是我的完整梳理……”模型看过示例之后语气、结构、详略都会向你给的方向靠拢。5. 一套可复用的“高手级 Prompt 模板”把上面五步放进一个通用模板里就是你以后写复杂 prompt 的骨架。下面是一个 system prompt 结构示例可以直接替换字段后使用{ system_prompt: { role: 你是一名{具体角色}擅长{核心能力范围}。, context: 背景信息{项目/用户/业务背景}。, task: 请完成以下任务\n1. {子任务1}\n2. {子任务2}\n3. {子任务3}, format: 输出要求{Markdown/JSON/表格}{字数限制}{语气要求}。, constraints: 限制条件{禁止事项}。{当信息不足时如何应对}。, example: 参考示例\n输入{示例输入}\n输出{示例输出}, acceptance: 验收标准输出必须包含{关键要素}且满足{可衡量条件}。 } }实际使用时把这一段作为 system prompt 塞入 API 或 Web 对话框。下面是一个填好的例子“你是一名资深的 To B SaaS 产品经理擅长需求分析和功能优先级排序。背景我们正在设计一个客服工单系统客户反馈最多的是‘历史工单检索太慢’。请完成以下任务1. 分析历史工单检索慢的 5 个可能原因2. 针对每个原因给出对应的产品方案3. 按开发成本从低到高排序。输出要求使用 Markdown 表格表格列依次为‘可能原因、影响程度、产品方案、开发成本、优先级’。限制条件不要提“增加缓存”这种无法落地的泛泛方案方案要具体到功能设计层面。如果信息不足以判断原因可以提出需要进一步排查的数据指标不要强行下结论。”这个 prompt 已经把所有关键信息都固定下来即使换一个模型大概率也能得到结构一致的结果。6. 用 API 批量评测 Prompt 效果高手和普通用户还有一个关键差别普通用户看一次两次效果高手会把 prompt 放到一组测试用例上批量跑记录成功率。单次对话判断不出 prompt 好坏原因是大模型有随机性。同一个 prompt同样参数两次结果可能不完全一样。所以更可靠的做法是准备一个小型测试集例如 10 到 20 条代表性的输入然后批量调用 API逐条检查输出。下面给出一个通用的 Python 批量评测脚本接口路径和模型名需要按你自己使用的服务商调整。import os import time import requests API_URL os.getenv(API_URL, https://your-endpoint/v1/chat/completions) API_KEY os.getenv(API_KEY, ) SYSTEM_PROMPT 你是一名资深产品经理。 请根据用户输入输出一份包含【问题分析】和【改进建议】的结构化回答。 要求使用 Markdown 格式结论先行总字数控制在 300 字以内。 TEST_CASES [ 我们产品的注册转化率只有 2%你觉得问题出在哪, 用户反馈上传文件经常失败想知道怎么排查。, 新版本上线后老用户投诉操作路径变长怎么处理, ] def chat(system_prompt: str, user_content: str) - tuple: resp requests.post( API_URL, headers{Authorization: fBearer {API_KEY}}, json{ model: your-model, messages: [ {role: system, content: system_prompt}, {role: user, content: user_content}, ], temperature: 0.3, }, timeout120, ) resp.raise_for_status() data resp.json() content data[choices][0][message][content] usage data.get(usage, {}) return content, usage for idx, case in enumerate(TEST_CASES, start1): print(f 测试用例 {idx} ) print(f输入{case}) try: output, usage chat(SYSTEM_PROMPT, case) print(f输出{output[:500]}) print(ftoken 统计prompt{usage.get(prompt_tokens)}, completion{usage.get(completion_tokens)}) except Exception as e: print(f调用失败{e}) print() time.sleep(1)跑完之后不要只凭感觉打分。可以给每一条输出标记“通过 / 不通过”然后计算通过率。例如 20 条用例通过 17 条那这个 prompt 版本的通过率就是 85%。改动 prompt 后再跑一轮通过率是否下降一清二楚。如果你用的是命令行环境也可以用 curl 快速验证 API 是否连通curl -X POST $API_URL \ -H Authorization: Bearer $API_KEY \ -H Content-Type: application/json \ -d { model: your-model, messages: [ {role: system, content: 你是一个技术文档工程师。请用表格输出总共不超过5行。}, {role: user, content: 列出3种让程序启动变慢的常见原因。} ] }批量评测最大的价值不是证明某个 prompt“最好”而是防止你改进 A 场景时破坏了 B 场景。没有测试集的 prompt 改动本质上是裸奔。7. 常见 Prompt 错误与排查下面这些是我在平时项目中比较常见的 prompt 问题和排查方向你可以对照使用问题现象可能原因排查方向改进方式输出过于泛泛目标不明确缺少背景和约束检查 prompt 是否写清了受众、用途、限制条件补充任务背景、输出要求、反例模型开始编造数据上下文缺少真实数据任务逼模型“给数字”检查是否提供了准确数据来源明确“没有数据时直接说不确定”输出格式不稳定没有指定格式或格式描述有歧义观察不同轮次格式差异直接给出 Markdown/JSON 示例回答太长或太短没有字数限制或模型对“简短”理解不稳定统计以往输出长度给出具体字数范围并附示例逻辑顺序混乱任务过大没有拆解子步骤观察模型是否跳步、漏点用“先……再……最后……”拆解任务每次结果差异大温度设置过高或 prompt 约束不足检查推理参数和 prompt 确定性降低 temperature增加格式与约束请求被内容策略拦截prompt 触发了服务商安全策略看返回错误信息中的策略提示修改表述遵守平台使用条款不要绕过上下文窗口超限塞了太多历史信息或大段文档检查 token 数量是否接近上限只保留与任务相关的内容或改用 RAG排查的思路其实和调试代码一样先看输入再看参数再看输出。不要一上来就怀疑“模型不行”。大部分情况模型只是根据你给的有限信息做了最合理的猜测。8. 从 Prompt 到 Skill、Agent 与 RAGPrompt 工程做到后面很多“AI 高手”已经不是单纯写一个 prompt而是把 prompt 放进更大的系统里。8.1 Prompt 与 Skill 的区别简单来说Prompt 是一段提示文本Skill 是把提示词、参数、工作流、校验逻辑打包在一起的一个可复用能力单元。在 Dify、Coze、FastGPT 这类平台上你可以把一个“周报生成 Skill”定义成包含固定 system prompt、输入字段模板、输出格式校验、甚至后续的数据处理步骤。这样在多个应用里复用而不是每次复制粘贴一段文字。8.2 Prompt 与 Agent 的分工Agent 和普通一问一答的区别在于它会规划、调用工具、观察结果、再继续执行。但你让 Agent 执行任务之前依然要写好 system prompt。它负责“指挥”prompt 负责“告诉它怎么指挥”。如果想让 Agent 稳定系统提示词里至少要包含Agent 的角色和目标可以调用哪些工具工具使用规则什么情况下调用哪个工具执行完工具后如何处理结果最终输出需要满足的格式8.3 Prompt 与 RAG 结合RAG 场景中的一个常见坑是模型拿到了检索内容但还是会按自己的“常识”自由发挥。解决方法是把“只能基于检索内容回答”写进 prompt。下面是一个 LangChain 风格的模板示意实际代码取决于你安装的 LangChain 版本from langchain.prompts import PromptTemplate rag_prompt PromptTemplate( template请基于以下检索到的资料回答问题。 背景{context} 问题{question} 规则 1. 只能使用资料中出现的信息 2. 如果资料不足以回答问题请直接回答“资料中没有相关信息”不要推测 3. 输出不超过 200 字使用简洁的中文。 参考资料 {context} , input_variables[context, question], ) formatted rag_prompt.format( context客服工单系统平均响应时长为 35 分钟超过 80% 用户的期望阈值。, question当前客服响应时长表现如何, ) print(formatted)这里的核心不是 LangChain API 本身而是“限制信息来源 承认不确定性”这两个约束。不管用什么框架都要保留这两条规则。至于 MCPModel Context Protocol则是把工具、资源和 prompt 统一成一种上下文协议让模型服务端可以稳定调用外部能力。它的具体接口会持续演进使用前先查对应文档不要照搬旧代码。9. 成本、延迟与资源观察Prompt 工程不只是“写词”还包括性能和成本意识。9.1 Token 消耗观察每次 API 调用返回里通常带有 usage 字段里面包含 prompt_tokens、completion_tokens。你需要关心两个数prompt_tokens你输入的 prompt 长度 测试数据长度。completion_tokens模型输出长度。如果 prompt 写得很长每次调用都要支付这部分 token在批量测试 20 条甚至更多用例时成本会被放大。长 prompt 如果带来明显收益可以接受如果只是一堆无关上下文建议删掉。9.2 延迟观察模型的输出延迟主要来自输出 token 数量。你要求“写一篇 3000 字的文章”和“输出 5 条要点”耗时差别会很大。在 Agent 场景里长时间等待还会拖垮整个流程。一个常见手法是分阶段主流程让模型输出精简结果需要长文时再单独调用一次生成完整内容。9.3 本地模型资源观察如果你在本地跑开源模型就不要只看 API 的 token 统计还要看显存和内存占用。可用的命令模板如下nvidia-smi重点观察显存使用率是否接近显卡上限。不同量化级别、不同上下文长度、不同并发数都会影响占用。实际数字需要以你本机的模型和参数为准不要照搬别人的“4G 够用”或“8G 不够”结论。降低本地资源占用通常可以从这几个方向入手使用量化模型、缩短上下文、降低 batch size、使用流式输出避免一次性生成过长内容。10. Prompt 工程最佳实践最后整理几条能在日常工作中直接落地的建议第一次测试先小参数运行。不要一开始就要求模型生成 5000 字长文先用 200 到 300 字验证结构是否正确。把 prompt 当代码管理。每次修改记录版本号写清楚改了什么。Prompt 文件放入 Git和代码一起维护。保留一套最小可运行配置。当你后面改了十几个版本后回退就靠它。建立小测试集。10 到 20 条覆盖典型场景的用例每次改 prompt 都要跑一遍。输入素材、输出结果、测试集分开目录管理。项目结构建议如下prompt-project/ prompts/ v1_system_prompt.txt v2_system_prompt.txt tests/ test_cases.json results_v2.csv outputs/ run_20250101/批量任务要加日志和失败重试。API 偶尔会超时脚本里要做异常捕获和重试。接口服务要限制访问范围。不要把带 API Key 的测试脚本暴露到公网不要提交包含密钥的代码到仓库。涉及人脸、声音、品牌、版权素材时确认授权后再生成和发布。发布或商用前做一次人工复核。Prompt 能够提高效率但不能完全替代人对内容的判断。11. 总结与下一步回到开头的问题你跟 AI 高手的 prompt 水平差距有多大从工具链和技术栈看其实没有不可逾越的鸿沟。差距主要在三件事一是有没有把模糊需求转换成结构化指令二是有没有建立测试集来验证 prompt 而不是靠感觉三是有没有把 prompt 沉淀成可复用的模板和流程。建议你先做三件事把文中给的通用模板填成自己业务场景的第一个版本找 10 条真实需求组成小测试集写一个 20 行的 Python 脚本批量跑一遍记录成功率。这三步做完你再回头看之前“一句话问 AI”的方式基本就回不去了。后续可以继续往三个方向扩展一是从单轮 prompt 走向多轮 Agent配合工具调用解决更复杂的任务二是把 prompt 放进 RAG 链路中让模型基于私有知识回答三是把常用能力封装成 Skill在业务系统里复用。Prompt 工程不是“背模板”而是建立一套写作、调试、评测、迭代的闭环。把这套闭环跑起来之后模型能力仍然会变但对结果质量的掌控力始终在你手里。建议收藏备用下次写 prompt 的时候拿出来对照检查一遍。