1. 为什么“会写提示词”和“提示词工程”是两码事很多人第一次接触大模型都是从“帮我写个周报”“解释一下这段代码”开始的。用久了会发现一个尴尬的事实同样一个模型有人问出来的答案能直接当交付物有人问出来的东西连自己都不想看第二遍。差距不在模型在提示词的组织方式。我见过太多人把提示词当成“许愿”一句话丢过去然后抱怨模型不行。也见过另一类人他们手里有一套固定的框架每次遇到新任务先套框架再填内容出来的结果稳定得像是流水线生产。后者做的这件事就是提示词工程。提示词工程不是玄学也不是“会说话就行”。它本质上是一套把模糊需求翻译成模型可执行指令的系统方法。你不需要成为算法工程师但你需要理解模型是怎么“读”你的话的以及为什么有些结构能让它读得更准。这篇文章要讲的就是一套我反复用过、也带着团队新人跑过的5步搭建AI提示词工程框架的方法。它不依赖某个特定模型DeepSeek、GPT、Claude、通义千问都能套。读完你至少能搞清楚三件事提示词到底由哪些模块组成、每个模块为什么必须存在、以及怎么用这套框架把“碰运气”变成“可复现”。适合谁看如果你已经在用大模型干活但结果时好时坏如果你带团队想让大家的产出质量拉齐如果你在准备AI相关的比赛或项目需要一套能写进文档的方法论——这套框架就是给你准备的。2. 五步框架的整体设计与选型逻辑2.1 为什么是五步而不是三步或十步市面上讲提示词的文章有的列了十几个技巧有的只给一个万能模板。技巧多了记不住模板少了不够用。五步这个粒度是我在实际项目中反复压缩和扩展之后找到的平衡点。三步太粗角色、任务、格式。听起来简洁但真到复杂场景就崩了。比如你要模型做一份竞品分析光说“你是分析师分析一下竞品输出报告”它给你的东西大概率是泛泛而谈。因为缺少了约束条件和推理路径这两个关键层。十步太碎把“设定角色”拆成“设定身份”“设定语气”“设定知识背景”把“输出格式”拆成“段落结构”“表格结构”“标点规范”。拆到最后写提示词比写代码还累而且很多步骤在简单任务里根本用不上。五步的划分逻辑是这样的角色与目标、上下文与约束、推理路径、输出规范、迭代机制。前四步构成一次完整的指令投递第五步是让这套东西能持续变好的闭环。每一步解决一个特定的失效模式缺一个都会在某个场景下出问题。2.2 每一步解决什么核心问题角色与目标解决的是“模型该用什么知识库和语气来回答”。你不设定它就默认用通用助手的口吻什么都知道一点什么都不深。上下文与约束解决的是“模型该在什么范围内回答”。没有约束模型会自由发挥给你一堆正确但没用的废话。约束包括字数、格式、必须包含的要素、必须排除的内容。推理路径解决的是“模型该怎么一步步想到答案”。对于复杂任务直接要结果容易出错让它先列步骤再给结论准确率会明显提升。这就是常说的“思维链”思路但我不喜欢把它神秘化本质上就是让模型把草稿纸上的过程也写出来。输出规范解决的是“结果长什么样才能直接用”。很多人忽略这一步结果拿到一堆文字还要自己重新排版。把格式要求写清楚模型能直接输出Markdown表格、JSON、代码块省掉二次加工。迭代机制解决的是“这次好了下次怎么更好”。没有复盘和版本管理每次都是从零开始碰运气。有了迭代机制你的提示词会像代码一样越改越稳。2.3 这套框架和“系统提示词工程”“Skill Agent”的区别最近热词里经常出现“系统提示词工程”和“Skill Agent”很多人搞混。简单说系统提示词工程是平台侧的事是模型厂商或应用开发者写死在系统里的指令用户改不了。我们这里讲的是用户侧的提示词工程是你每次对话时输入的那段话。Skill Agent则是把提示词和外部工具、工作流打包成一个可调用的技能。比如一个“生成App原型图”的Agent背后可能调用了墨刀AI的接口加上一套固定的提示词模板。你如果要做Agent这套五步框架就是设计Agent内部提示词的基础。先能把单次提示词写好再谈封装和自动化。3. 核心细节拆解与每步实操要点3.1 第一步角色与目标——别只写“你是专家”“你是一个资深程序员”——这种角色设定太泛了。模型看到“资深程序员”脑子里激活的是所有编程相关的语料包括前端、后端、算法、运维。它不知道你具体要什么。有效的角色设定要包含三个要素领域、经验层级、当前任务视角。比如你要模型帮你审查一段Python代码的性能问题角色可以这样写你是一个有十年经验的Python后端工程师擅长高并发场景下的性能调优现在需要以代码审查者的视角找出下面这段代码中可能导致响应延迟的瓶颈。领域是“Python后端”经验层级是“十年”任务视角是“代码审查者”。这三个信息一给模型激活的知识范围就收窄了回答的针对性会明显提升。目标设定也有讲究。不要写“帮我优化代码”要写“找出所有时间复杂度高于O(n log n)的操作并给出替代方案”。目标越具体模型越不容易跑偏。实操心得角色设定不要超过三句话。写多了模型反而会抓不住重点。我试过写一大段角色背景结果模型在回答里反复提这个背景反而干扰了核心任务。3.2 第二步上下文与约束——给模型画一个圈上下文是告诉模型“这件事的背景是什么”约束是告诉模型“你不能做什么”。上下文包括数据来源、业务场景、已知条件、相关背景。比如你要模型帮你分析一份销售数据上下文要写清楚“这是某电商平台过去三个月的订单数据包含字段有订单号、用户ID、商品类目、金额、下单时间”。约束包括字数限制、格式限制、内容边界。比如“不要给出具体的投资建议”“不要引用2023年之前的数据”“回答控制在500字以内”。这里有个容易踩的坑约束写得太少模型会自由发挥约束写得太死模型会变得机械。我的经验是硬约束不超过三条软约束可以多给。硬约束是必须遵守的比如“输出必须是JSON格式”软约束是尽量满足的比如“尽量用简洁的语言”。还有一个细节如果你给模型提供了参考材料一定要明确告诉它“优先使用以下材料中的信息如果材料中没有相关内容明确说明‘材料中未提及’”。否则模型会用自己的知识补全导致信息失真。3.3 第三步推理路径——让模型把草稿纸交出来对于简单任务这一步可以省略。但对于需要多步推理的任务比如数学计算、逻辑分析、方案对比让模型先写推理过程再给结论准确率会高很多。具体怎么写有两种方式。一种是显式步骤直接告诉模型“请按以下步骤思考第一步识别问题中的关键变量第二步列出可能的解决方案第三步对比各方案的优缺点第四步给出推荐方案”。另一种是隐式引导写“请先分析问题背景再逐步推导最后给出结论”。模型会自动展开推理。我实测下来显式步骤在复杂任务上更稳尤其是涉及计算的时候。比如你要模型帮你算一个建模比赛里的参数优化问题直接写“请先写出目标函数再写出约束条件然后给出求解思路最后给出具体参数值”比只写“帮我优化参数”效果好得多。注意事项推理路径不是越长越好。如果任务本身很简单强行让模型写一堆步骤反而会增加出错概率。判断标准是如果你自己动手做这件事需要打草稿那就让模型也打草稿如果你自己心算就能出来那就不需要。3.4 第四步输出规范——让结果直接能用输出规范是很多人忽略的一步但它是提升效率的关键。你想想如果模型输出的东西还要你手动整理成表格那省下来的时间又还回去了。输出规范要写清楚格式、结构、字段、示例。格式可以是Markdown、JSON、YAML、纯文本。结构可以是“先总结再分点”“先表格再说明”“按时间顺序排列”。字段是如果你要JSON要明确每个key的名称和类型。示例是给一个输出样例让模型照着填。比如你要模型帮你生成一组测试用例输出规范可以这样写请以JSON数组格式输出每个元素包含以下字段case_id字符串格式为TC-001、description字符串测试场景描述、steps字符串数组操作步骤、expected字符串预期结果。示例[{case_id: TC-001, description: 登录成功, steps: [输入正确用户名, 输入正确密码, 点击登录], expected: 跳转到首页}]有了这个规范模型输出的东西可以直接导入测试管理工具省掉手工录入的环节。3.5 第五步迭代机制——把一次性成功变成可复现前面四步做完你大概率能得到一个不错的结果。但下次遇到类似任务你还能不能得到同样好的结果不一定。因为模型有随机性同样的提示词跑两次结果可能不一样。迭代机制要解决的就是这个问题。具体做法包括版本记录每次修改提示词记录改了什么、为什么改、效果如何。可以用简单的文本文件也可以用Notion、飞书文档。我习惯在提示词末尾加一个注释块写清楚版本号和修改说明。A/B测试同一个任务准备两版提示词跑同样的输入对比输出质量。不要凭感觉判断哪个好要定标准。比如“信息完整度”“格式正确率”“人工修改耗时”。失败案例收集把模型输出不好的案例存下来分析是哪个模块出了问题。是角色设定不够具体还是约束条件有遗漏还是推理路径跳步了定位到具体模块改起来就有方向。参数固化如果你用的是API把temperature、top_p这些参数也记录下来。同样的提示词temperature从0.7调到0.2输出风格会差很多。找到适合当前任务的参数组合固定下来。实操心得我自己的提示词库是按“任务类型”分类的每个类型下面有基础模板和若干变体。新任务来了先找最接近的模板改几个变量就能用。这样比每次从零写快得多而且质量有底线。4. 完整实操流程与关键环节实现4.1 场景设定用AI辅助生成App原型图的需求描述假设你是一个产品经理需要让AI帮你生成一个“社区团购App”的原型图描述。这个描述后续会喂给墨刀AI或其他原型工具。你的目标是输出的描述要足够详细让原型工具能直接生成可用的界面。这个任务看起来简单但实际做起来容易出问题。如果你只写“帮我生成一个社区团购App的原型描述”模型给你的东西大概率是“首页、商品列表、购物车、个人中心”这种级别的概括原型工具拿到之后只能生成几个空白页面。用五步框架来拆解这个任务。4.2 第一步到第四步的具体填写角色与目标你是一个有五年经验的移动端产品经理擅长社区电商类产品的交互设计。现在需要为一个社区团购App生成一套完整的页面原型描述目标是让原型工具能够直接根据描述生成可交互的界面。上下文与约束这个App的目标用户是25-45岁的社区家庭用户核心功能是“今日下单、次日自提”。主要页面包括首页、商品详情页、购物车、订单确认页、自提点选择页、个人中心。约束条件每个页面的描述不超过200字必须包含页面元素的位置关系必须说明核心交互逻辑不要涉及支付和物流的具体实现细节。推理路径请按以下步骤生成第一步列出每个页面的核心功能点第二步描述页面的布局结构从上到下、从左到右第三步说明页面内的交互逻辑比如点击某个按钮后跳转到哪里第四步用一段话总结该页面的设计意图。输出规范请以Markdown格式输出每个页面一个二级标题标题格式为“页面名称XXX”。每个页面下面用无序列表列出布局元素用有序列表列出交互步骤。最后附一个表格汇总所有页面之间的跳转关系。4.3 实际输出与效果分析按照上面的框架模型输出的内容大概是这样的节选页面名称首页顶部搜索栏占满宽度左侧为定位图标显示当前社区名称中部轮播图展示今日爆款商品高度约为屏幕的三分之一下部商品分类网格每行四个图标包含“蔬菜水果”“肉禽蛋品”“日用百货”等底部导航栏包含“首页”“分类”“购物车”“我的”四个标签交互步骤点击搜索栏跳转到搜索页面点击轮播图跳转到对应商品详情页点击分类图标跳转到分类商品列表页点击底部导航“购物车”跳转到购物车页面这个输出直接复制到墨刀AI的原型生成功能里基本能生成一个可用的首页框架。对比没有框架的提示词输出质量差距非常明显。我实测过用框架生成的描述原型工具一次生成可用页面的比例大概在70%左右不用框架这个比例不到30%。差距主要来自布局描述的具体性和交互逻辑的完整性。4.4 参数选择与调整记录在这个场景里我用的模型是DeepSeek-V2temperature设为0.3。为什么是0.3因为原型描述需要的是稳定、结构化的输出不需要太多创意发挥。temperature太高模型会在布局描述里加入一些不存在的元素太低又会导致描述过于死板缺乏合理的交互联想。top_p设为0.9保持一定的多样性但不过度发散。max_tokens设为2000因为六个页面的描述加起来大概在1500字左右留一些余量。如果你用的是其他模型参数可能需要微调。但核心原则不变结构化输出任务temperature往低了调创意生成任务temperature可以适当调高。5. 常见问题与排查技巧实录5.1 模型不按格式输出怎么办这是最常见的问题。你明明写了“请以JSON格式输出”模型还是给你一段文字。原因通常有三个第一输出规范写得太靠后。模型在生成时前面的内容权重更高。如果输出规范放在最后模型可能已经“忘记”了。解决办法是把格式要求提前或者在推理路径里也提一句“最后请按XX格式输出”。第二格式要求不够具体。只写“JSON格式”不够要写清楚key的名称、value的类型、嵌套结构。最好给一个完整的示例。第三模型能力限制。有些小模型对复杂格式的遵循能力确实弱。如果换了写法还是不行考虑换模型或者把格式要求拆成多轮对话先让模型生成内容再让它转换格式。5.2 输出内容太泛、没有深度模型给你的东西像是从百科里抄的正确但没用。这通常是上下文和约束没写好。检查你的提示词里有没有这些信息具体的业务场景、已知的数据或条件、你期望的分析角度。如果这些都没有模型只能给你通用答案。另一个技巧是给反面例子。比如“不要写‘建议优化用户体验’这种空话要写‘将按钮从右下角移到拇指热区范围内’这种可执行的动作”。模型看到反面例子会主动避开那些泛泛的表述。5.3 推理路径导致输出太长让模型写推理过程结果它写了2000字的分析最后结论只有两句话。这在需要快速拿到结果的场景里很烦人。解决办法是限制推理长度。在推理路径里加一句“推理过程控制在200字以内直接给出关键判断依据”。或者把推理和输出分开先让模型在“草稿模式”下推理你确认后再让它“按结论模式”输出。我自己的习惯是对于日常任务推理路径只写“简要说明判断依据”不展开。对于复杂决策才让它完整推理。5.4 常见问题速查表问题现象可能原因排查动作解决技巧输出格式不对格式要求太靠后或太模糊检查输出规范的位置和具体性提前格式要求给出完整示例内容泛泛而谈上下文和约束不足检查是否提供了业务场景和具体条件加入反面例子明确禁止空话推理太长推理路径未限制长度检查是否有字数约束加“推理控制在XX字以内”角色设定无效角色描述太泛检查是否包含领域、层级、视角收窄到具体任务场景结果不稳定参数未固定或提示词有歧义检查temperature和措辞固定参数消除歧义表述模型忽略约束约束太多或太靠后检查硬约束数量硬约束不超过三条放在前面5.5 独家避坑技巧技巧一用“如果你不确定请明确说明”代替“不要瞎编”。后者会让模型变得过度保守该回答的也不回答了。前者给了模型一个安全的退出路径反而能提高有效回答的比例。技巧二把最重要的约束放在提示词的开头和结尾各一次。模型对首尾信息的注意力更高中间部分容易被稀释。这不是玄学是注意力机制的特性。技巧三迭代时一次只改一个模块。同时改角色和约束你无法判断是哪个改动起了作用。保持其他模块不变单独调整一个变量才能积累出有效的经验。技巧四建立自己的“提示词片段库”。把常用的角色描述、约束条件、输出格式存成片段写新提示词时直接拼装。我自己的片段库里有几十个条目写新提示词的时间从半小时缩短到五分钟。6. 从单次提示词到提示词工程体系的扩展6.1 把五步框架变成团队规范一个人用这套框架效率提升是线性的。一个团队用这套框架效率提升是指数级的。因为提示词可以复用、可以评审、可以版本管理。具体做法在团队内部建一个共享的提示词库按任务类型分类。每个提示词必须包含五步框架的完整结构。新人写提示词先从库里找最接近的模板改完提交评审。评审的重点不是“写得好不好”而是“五步是否完整、约束是否明确、输出是否可直接使用”。我们团队跑这套流程大概三个月后新人上手大模型任务的时间从两周缩短到三天。因为不需要从头理解“怎么跟模型说话”直接套框架就行。6.2 和AI编程提示词的结合最近“AI编程提示词”很火很多人用Cursor、Copilot写代码。其实编程场景特别适合这套框架。角色设定为“资深XX语言工程师”上下文里贴入相关代码和报错信息推理路径要求“先分析报错原因再给出修改方案最后说明修改可能影响的其他模块”输出规范要求“给出完整的修改后代码块并标注修改行”。我试过用这套框架让模型帮我重构一段复杂的Python数据处理代码一次通过率比直接说“帮我优化这段代码”高很多。关键就在于推理路径让模型先分析了依赖关系避免了改一处崩三处的情况。6.3 建模比赛中的提示词工程应用建模比赛里AI提示词可以帮你做很多事理解题目背景、查找相关算法、生成论文框架、甚至辅助写代码。但比赛场景有个特点时间紧、任务重、不能出错。这时候提示词的稳定性比创意性更重要。我的建议是比赛前就准备好几套针对常见任务的提示词模板比如“算法选型分析”“数据预处理方案”“论文摘要生成”。比赛时直接填空不要现场发挥。另外比赛里经常需要处理敏感数据或保密题目用AI辅助时要注意不要泄露关键信息。可以把数据脱敏后再喂给模型或者只让模型处理方法论层面的问题具体数据自己算。6.4 提示词工程的边界与局限说了这么多提示词工程的好处也得说说它的边界。提示词工程不能让弱模型变成强模型。如果模型本身不具备某种能力再好的提示词也问不出来。它能做的是把模型已有的能力更稳定地激发出来。提示词工程也不能替代领域知识。你不懂业务就写不出好的约束条件你不懂代码就判断不了模型给的方案对不对。提示词工程是放大器不是替代品。最后提示词工程不是一劳永逸的。模型在更新任务在变化你的提示词库也需要持续维护。把它当成一个需要定期整理的工具箱而不是一次性的作业。我个人在实际操作中的体会是这套五步框架最大的价值不是让你“会写提示词”而是让你有一套可以跟别人讨论、可以传承、可以改进的方法。以前大家交流提示词只能说“我试了一个写法效果不错”现在可以说“我的约束模块写得不够具体导致输出泛化你帮我看看怎么改”。从感觉驱动变成工程驱动这才是提示词工程真正的意义。