提示词工程这件事我踩过的坑比大多数人写过的提示词还多。最开始我也觉得不就是“你是一个专业的XX”加几句要求吗直到同一个模型、同一个任务别人跑出来的结果稳定可用我跑出来的东西时好时坏才发现问题根本不在模型而在于我从来没把提示词当成一个“工程”来做。这篇内容就是把我这两年反复折腾出来的一套框架完整拆开讲从角色设定到上下文管理从输出约束到评测迭代五个步骤每一步都告诉你为什么这么做、不这么做会出什么问题。不管你是刚接触大模型的新手还是已经在用AI辅助编程、绘画、写作的老手这套框架都能直接拿去用读完你对提示词工程的认知大概率会超过身边95%的人这话我不夸张。1. 先搞清楚提示词工程到底在解决什么问题1.1 提示词不是玄学是信息传递的压缩与解压很多人把提示词当成“咒语”觉得某些词组合在一起就能让模型变聪明。这个理解方向就偏了。大模型本质上是一个根据上文预测下文的概率机器你给的提示词就是它预测的“上文条件”。提示词工程的核心是把你脑子里那个模糊的需求压缩成模型能准确解压的文本指令。压缩得越精准解压出来的结果就越接近你的预期。我举个实际例子。你写“帮我写个爬虫”模型只能猜你要爬什么、用什么语言、数据存哪里、要不要处理反爬。但如果你写“用Python的requests和BeautifulSoup写一个爬取某图书网站前10页书名的脚本结果存成CSV每行一个书名遇到请求失败重试3次每次间隔2秒”模型几乎不需要猜直接就能给出可运行的代码。这两者的差距就是提示词工程要解决的问题。1.2 为什么大多数人写的提示词效果不稳定效果不稳定的根源通常有三个。第一是信息缺失你默认模型知道一些它其实不知道的背景比如你的项目结构、你的代码规范、你的审美偏好。第二是约束模糊你说“写得好一点”“专业一些”但“好”和“专业”没有可操作的判定标准模型只能随机发挥。第三是没有评测环节你改了一版提示词感觉好像好了一点但到底好了多少、是不是真的好了全靠感觉下次换个任务又回到原点。我早期做AI绘画提示词的时候就吃过这个亏。同一组提示词有时候出图很惊艳有时候完全不能用我一直以为是模型随机性太强。后来我把每次的提示词、参数、出图结果都记录下来对比才发现问题出在我对“古风人物”这个描述太笼统模型每次理解的风格方向都不一样。加上具体的服饰朝代、发型特征、光影氛围之后出图的稳定性直接上了一个台阶。1.3 这套五步框架适合谁用这套框架不挑模型不管你是用通用大模型做文本任务还是用专门的编程助手写代码或者用绘画模型出图底层逻辑是通的。适合的人群包括经常用AI辅助编程但结果时好时坏的开发者、做AI绘画需要稳定出图风格的设计师、用大模型做内容生成但总需要反复修改的运营人员以及任何想把AI真正用进工作流而不是当玩具玩的人。你不需要懂模型训练也不需要会调参只需要会打字、会思考、会记录就能把这套框架跑起来。2. 第一步角色与目标锚定让模型知道“你是谁、要干嘛”2.1 角色设定的真正作用不是“扮演”而是激活知识域很多人写角色设定就是“你是一个资深的Python工程师”然后就没有然后了。这个写法不能说错但浪费了角色设定的大部分价值。角色设定的本质是通过一个身份标签去激活模型训练数据中与该身份相关的知识分布。你给“资深Python工程师”模型会倾向于调用编程相关的表达方式和知识你给“资深Python工程师擅长写高并发后端服务注重代码可读性和异常处理”模型调用的知识就更聚焦。我做过一个对比测试同一个代码生成任务角色设定只写“你是程序员”和写“你是有10年经验的Python后端工程师代码风格遵循PEP8习惯用类型注解异常处理必须记录日志”后者的输出在类型注解覆盖率和日志完整性上明显更好。这不是玄学是因为更具体的角色描述把模型的输出空间收窄到了你想要的区域。2.2 目标描述要包含“交付物”和“验收标准”角色之后紧接着就是目标。目标描述最常见的毛病是只说了“做什么”没说“做成什么样算完成”。比如“帮我优化这段代码”优化到什么程度是跑得更快、读起来更清晰、还是占用内存更少没有验收标准模型就只能按自己的理解来。我的做法是把目标拆成三层交付物形态是一段代码、一个表格、还是一份文档、核心要求必须满足的硬性条件、验收标准怎么判断做完了。举个例子不要说“帮我分析这份销售数据”而要说“分析这份销售数据输出一个Markdown表格包含每个月的销售额、环比增长率、Top3产品增长率保留两位小数如果某月数据缺失用‘暂无’标注”。这样模型给出的结果你几乎不需要二次加工。2.3 实操一个完整的角色与目标锚定模板下面这个模板是我用了很久的你可以直接套角色你是一位[具体身份]有[X]年[具体领域]经验擅长[具体技能1]、[具体技能2]工作风格是[风格描述]。 任务基于我提供的[输入材料说明]完成[具体任务]。 交付物[交付物形态和格式要求] 硬性要求 1. [要求1] 2. [要求2] 3. [要求3] 验收标准[可判定的完成标准]注意角色描述不要堆砌无关头衔比如“你是北大毕业、曾在硅谷工作、精通十种语言的全栈工程师”这种信息对任务没有帮助反而稀释了关键指令的权重。角色设定只保留与当前任务直接相关的经验和技能。3. 第二步上下文与约束设计把“潜台词”变成“明规则”3.1 上下文不是越多越好而是要“刚好够用”大模型的上下文窗口是有限的你塞进去的每一段文字都在占用模型的注意力。很多人喜欢把一堆背景资料全贴进去觉得信息越多模型越懂实际上无关信息会干扰模型对关键指令的识别。我管这个叫“上下文噪音”。正确的做法是只提供完成任务必需的最小上下文。比如你要模型帮你改一段代码的bug你需要提供这段代码本身、报错信息、你期望的正确行为。你不需要提供整个项目的所有文件除非bug涉及跨文件调用。如果你不确定哪些信息是必需的可以先给最小集模型如果追问再补充这比一次性塞一大堆然后得到一堆废话要高效得多。3.2 约束条件的三种类型和写法约束是提示词里最容易被忽略但影响最大的部分。我把约束分成三类格式约束规定输出的结构。比如“用JSON输出”“每个要点不超过20字”“代码必须包含注释”。格式约束的好处是让输出可直接被程序解析或直接使用减少人工整理。内容约束规定输出必须包含或不能包含什么。比如“必须引用我提供的原文”“不要编造不存在的数据”“如果信息不足明确说‘信息不足’而不是猜测”。内容约束是防止模型幻觉的重要手段。风格约束规定输出的语气和表达方式。比如“用口语化的方式解释”“避免使用专业术语”“像给小学生讲课一样”。风格约束在做科普内容或面向非专业读者时特别有用。3.3 实操用“约束清单”替代“散装要求”我习惯把约束写成清单形式每条约束独立一行方便模型逐条遵守也方便我自己检查有没有遗漏。一个典型的约束清单长这样约束条件 - 输出语言中文 - 输出格式Markdown二级标题用##三级标题用### - 代码语言Python 3.10 - 代码必须包含类型注解和docstring - 如果涉及不确定的信息用[待确认]标注 - 总字数控制在800-1200字之间 - 不要使用“总之”“综上所述”等总结性词汇提示约束清单不要超过10条超过10条说明你的任务可能太复杂应该拆成多个子任务分步完成。一次让模型做太多事每件事都做不精。4. 第三步输出格式与示例锚定让结果“开箱即用”4.1 为什么格式约束能大幅提升可用性你有没有遇到过这种情况模型给了一段很好的分析但格式乱七八糟你得花十分钟重新排版才能用。这就是没有做格式约束的代价。格式约束的价值在于它让模型的输出直接进入你的工作流而不是还要经过一道人工整理。我做过一个实验让模型生成产品需求文档不加格式约束时输出是一大段文字我需要手动拆分模块、提取要点、调整层级。加上“用Markdown输出每个功能模块用二级标题功能描述用无序列表验收标准用表格”之后输出直接可以贴进文档系统。省下来的时间不是一点半点。4.2 Few-shot示例给模型一个“抄作业”的样板Few-shot就是给模型几个输入输出的例子让它照着例子的模式来。这个方法在格式要求复杂或者风格要求特殊的时候特别管用。比如你要模型把技术文档改写成面向小白的科普文你给一个改写前后的对比示例模型就能抓住你要的“通俗程度”和“表达方式”。示例的选择有讲究。示例要覆盖典型情况不要只给一个最简单的例子。示例要标注清楚输入和输出避免模型混淆。示例数量控制在2-3个太多会占用大量上下文且边际收益递减。我通常用两个示例一个标准情况一个边界情况这样模型既知道常规怎么做也知道特殊情况怎么处理。4.3 实操格式模板加示例的组合拳下面是我做数据提取任务时常用的组合输出格式要求 严格按照以下JSON结构输出不要添加任何额外字段 { product_name: 产品名称, price: 价格保留两位小数, rating: 评分1-5分, review_summary: 评价摘要不超过50字 } 示例 输入某产品售价199.9元评分4.5用户评价“性价比很高物流快但包装有点简陋” 输出{product_name: 某产品, price: 199.90, rating: 4.5, review_summary: 性价比高物流快包装简陋}这种写法几乎消除了模型自由发挥的空间输出可以直接被程序消费。5. 第四步分步拆解与思维链引导攻克复杂任务5.1 复杂任务为什么要拆大模型在处理多步骤推理任务时如果直接让它给最终答案中间步骤容易被跳过或出错。这就像你让一个人心算三位数乘法他可能算错但你让他把每一步写下来正确率就高很多。思维链Chain of Thought的核心就是让模型把推理过程显式地写出来。我试过让模型直接判断一段代码有没有安全漏洞准确率一般。但改成“先列出这段代码涉及的所有输入点然后逐个分析每个输入点是否有校验最后给出结论”准确率明显提升。因为分步之后模型不会跳过任何一个检查环节。5.2 分步拆解的三种常用模式顺序拆解任务有明确的先后顺序比如“先读取数据再清洗再分析最后可视化”。这种最简单按步骤列出来就行。分支拆解任务有不同的情况需要分别处理比如“如果用户输入是中文走A流程如果是英文走B流程”。这种需要把条件和对应操作写清楚。迭代拆解任务需要反复优化比如“先写初稿然后从逻辑性、可读性、准确性三个维度自我审查根据审查结果修改输出修改后的版本”。这种适合写作和代码优化类任务。5.3 实操用“步骤指令”替代“一句话需求”对比一下这两种写法一句话需求“帮我写一个用户登录功能。”步骤指令请按以下步骤完成用户登录功能的开发 1. 设计数据库表结构包含用户名、密码哈希、创建时间字段 2. 编写注册接口密码使用bcrypt加密存储 3. 编写登录接口验证密码后返回JWT token 4. 编写中间件验证请求头中的token有效性 5. 为每个接口编写单元测试覆盖正常和异常情况 每一步完成后输出该步骤的代码和简要说明再进行下一步。后者出来的代码结构完整、考虑周全前者出来的代码往往缺东少西。差别就在于你有没有把“思考过程”外化给模型。实操心得分步拆解的时候每一步的粒度要适中。太粗了模型还是会跳步太细了步骤太多模型容易在中间迷失。我的经验是每个步骤对应一个可独立验证的小交付物比如一个函数、一个表格、一段分析这样既不会太粗也不会太细。6. 第五步评测与迭代让提示词越用越准6.1 没有评测的提示词优化都是自嗨这是我最想强调的一点。很多人改提示词全靠“感觉”觉得这版好像好一点就留着用下次遇到问题又不知道从哪改起。正确的做法是建立一套简单的评测机制固定一组测试输入每次修改提示词后跑一遍对比输出质量。评测不需要多复杂哪怕你只是手动给每次输出打个分比如1-5分记录在表格里都比凭感觉强。我自己的评测表包含这几列测试用例编号、输入摘要、输出评分、主要问题、修改动作。坚持记录一个月你就能看出哪些修改真正有效哪些只是心理安慰。6.2 迭代的方向从“加指令”到“换结构”新手优化提示词的习惯是不断加指令“再加一条要求”“再补充一个约束”。加到十几条之后提示词变得又长又乱模型反而抓不住重点。这时候应该换思路不是加指令而是换结构。比如把散装的约束整理成分组清单把一段式的任务描述改成分步骤指令把模糊的风格要求换成具体的示例。结构的调整往往比增加指令更有效。我自己的经验是当提示词超过500字效果还不理想时不要继续加字而是重新组织结构通常能砍掉一半字数同时提升效果。6.3 实操一个可持续迭代的提示词管理方法我管理提示词的方式很简单每个提示词存成一个独立文件文件头部用注释记录版本号和修改说明文件内容就是提示词正文。每次修改前先复制一份旧版本改完后用固定测试集跑一遍对比新旧版本的输出。如果新版本在测试集上表现更好就保留否则回滚。# prompt_v3.md # 版本v3 # 修改说明将角色描述从“资深工程师”细化为“有10年Python后端经验注重代码可读性” # 测试结果代码类型注解覆盖率从60%提升到95%异常处理完整性从70%提升到90% # 日期2024-XX-XX [提示词正文...]这个方法看起来笨但极其有效。它让你对每一次修改都有据可查不会出现“改了半天不知道改好还是改坏了”的情况。6.4 常见问题速查表问题现象可能原因排查方向解决动作输出格式不稳定格式约束不具体检查是否有明确的格式模板添加JSON schema或Markdown模板内容空洞泛泛角色和目标太宽泛检查角色是否具体到技能层细化角色描述增加验收标准模型编造信息缺少内容约束检查是否允许模型“不知道”添加“信息不足时明确说明”约束复杂任务出错没有分步引导检查任务是否一步到位拆成步骤指令逐步输出风格忽好忽坏缺少示例锚定检查是否有Few-shot示例添加2-3个输入输出示例改了提示词没效果没有评测机制检查是否有固定测试集建立评测表记录每次修改避坑技巧不要在一次修改中同时改多个地方。比如你既改了角色描述又改了输出格式结果变好了你不知道是哪个改动起了作用变差了也不知道该回滚哪个。每次只改一个变量这是做实验的基本素养。7. 把这五步串起来一个完整的实战案例7.1 案例背景用AI辅助生成产品原型描述假设你要用大模型帮你把一个模糊的产品想法转化成结构化的原型描述方便后续用原型工具生成界面。原始需求只有一句话“做一个记账App的原型描述。”这个需求直接丢给模型输出大概率是一堆泛泛而谈的功能列表没法直接用。7.2 按五步框架重构提示词第一步角色与目标锚定角色你是一位有8年经验的移动端产品经理擅长记账类工具的产品设计熟悉个人财务管理场景。 任务基于我提供的产品想法输出一份结构化的App原型描述文档。 交付物Markdown格式的原型描述文档包含页面清单、每个页面的元素说明、页面跳转关系。 验收标准每个页面至少包含3个核心元素跳转关系用文字描述清楚不出现“等等”“类似”等模糊表述。第二步上下文与约束设计背景目标用户是25-35岁的上班族核心需求是快速记录日常开销并查看月度统计。 约束条件 - 页面数量控制在5-8个 - 每个页面的元素用无序列表列出 - 跳转关系用“页面A - 页面B触发条件”的格式 - 不要涉及技术实现细节 - 输出语言为中文第三步输出格式与示例锚定输出格式示例 ## 页面名称首页 - 元素1本月支出总额大字号显示 - 元素2最近5笔交易列表 - 元素3快速记账按钮固定在底部 跳转关系 - 首页 - 记账页点击快速记账按钮 - 首页 - 统计页点击本月支出总额第四步分步拆解请按以下步骤输出 1. 先列出所有页面名称和一句话功能说明 2. 然后逐个页面展开元素说明 3. 最后统一整理跳转关系第五步评测与迭代拿到输出后检查页面数量是否在5-8个之间、每个页面元素是否不少于3个、跳转关系是否完整。如果某个页面元素太少在下一版提示词中针对该类页面增加“至少包含5个元素”的约束。7.3 迭代后的效果对比第一版输出只有3个页面元素描述很笼统跳转关系缺失。按框架重构后输出包含6个页面每个页面4-6个元素跳转关系完整直接可以拿去原型工具里落地。这个案例说明的不是模型变强了而是提示词的结构变对了。8. 关于提示词工程我踩过的几个真实坑8.1 坑一以为提示词越长越好刚开始做提示词工程的时候我总觉得写得越多模型越懂。有一次我写了一个800多字的提示词结果模型输出反而比200字版本更差。后来才明白长提示词里有很多重复和无关信息稀释了核心指令的权重。现在我的原则是能用200字说清楚的事绝不写500字。8.2 坑二忽略模型的“不知道”权利早期我从来不告诉模型“不知道就说不知道”结果它遇到信息不足的情况就开始编。有一次我让它分析一份数据数据里缺了几个字段它直接给我编了一套数字出来我还差点信了。从那以后我每条提示词里都会加一句“如果信息不足明确说明缺少什么信息不要猜测”。8.3 坑三不做版本管理改乱了回不去有段时间我改提示词改得很随意直接在原文件上改改完发现效果不如之前想回滚却找不到旧版本。后来养成习惯每次修改前先复制一份文件名带上版本号和日期改完对比测试。这个习惯救了我好几次。8.4 坑四拿单一案例判断提示词好坏我曾经用一条测试用例判断提示词改得好不好结果换了一个场景就翻车了。后来我固定用5条覆盖不同情况的测试用例来评测虽然麻烦一点但判断准确多了。单一案例的偶然性太大不能作为决策依据。9. 进阶方向从提示词工程到上下文工程9.1 提示词工程的边界在哪里提示词工程能解决的是“单次交互”的质量问题。但当你需要模型处理一个持续的任务、需要它记住之前的对话、需要它调用外部工具的时候光靠提示词就不够了。这时候就进入了上下文工程的范畴。上下文工程关注的是如何在多轮对话中管理上下文窗口、如何动态注入相关信息、如何让模型在长任务中保持一致性。比如你做一个客服机器人提示词只定义了它的角色和回复风格但上下文工程要解决的是怎么把用户的历史订单信息、当前会话状态、知识库检索结果合理地组织进每次请求里。9.2 提示词工程和Agent技能的区别现在很多人讨论AgentAgent的核心能力包括规划、工具调用、记忆管理。提示词工程是Agent的基础但Agent还需要额外的机制。打个比方提示词工程是教一个人怎么说话Agent是教一个人怎么做事——他不仅要会说话还要会拆解任务、会使用工具、会记住做过什么。所以提示词工程是基本功但不是终点。9.3 给想深入的人的建议如果你已经把五步框架跑熟了想继续深入我的建议是第一开始记录和分析你的提示词在不同模型上的表现差异理解模型特性第二学习如何把提示词和外部数据源结合比如让模型基于检索到的文档回答问题第三尝试把重复性的提示词任务自动化比如用脚本批量调用模型并自动评测输出。这三步走下来你对提示词工程的理解会从“技巧”层面上升到“系统”层面。最后分享一个我最近的小发现把提示词里的“请”“帮我”这类礼貌用语去掉换成直接的指令式表达输出质量反而更稳定。我猜是因为礼貌用语对模型来说是噪音直接说“输出以下内容”比“请帮我输出以下内容”更清晰。当然这个发现不一定对所有模型都成立你可以自己试试看。