1. 先搞清楚“战无不胜”的提示词到底赢在哪很多人第一次接触提示词脑子里想的都是“有没有一句万能咒语复制粘贴就能让AI听话”。我刚开始也这么想后来踩了足够多的坑才明白真正稳定的提示词从来不是一句话而是一套结构。就像盖房子你不能只给施工队一句“给我盖个好看的”得给图纸、给材料清单、给验收标准。提示词框架干的就是这个事。所谓“战无不胜攻无不克”不是说某条提示词在所有模型、所有场景下都通杀而是说这套结构具备可迁移性——换一个模型、换一个任务你只需要替换其中的变量骨架不用动。这背后依赖的是对模型行为的理解大语言模型本质上是条件概率生成器你给的上下文越清晰、约束越明确、示例越具体它落在你期望输出空间里的概率就越高。提示词工程的核心就是不断缩小这个输出空间同时保留足够的灵活性。这套框架适合谁如果你是刚入门AI应用的开发者、正在搭建智能体的产品经理、或者每天要用AI处理大量文本的运营和文案它都能直接拿去用。不需要你懂模型训练也不需要你会写代码但需要你愿意花二十分钟理解结构而不是继续在收藏夹里囤“100条神级提示词”。我把它拆成五个模块角色设定、任务定义、上下文约束、输出格式、示例锚定。下面逐个拆开讲每个模块我都会说明为什么这么设计、常见错误是什么、以及怎么根据你的场景做调整。1.1 为什么单条提示词总是不稳定先说说大多数人踩的坑。你写了一句“帮我写一篇关于智能体的文章”模型给你返回一篇泛泛而谈的科普。你嫌不够专业加一句“要专业一点”它给你堆了一堆术语但逻辑混乱。你再加“要有案例”它编了一个不存在的公司案例。问题出在哪出在你把多个维度的要求混在一条自然语言里模型在解析时会产生歧义。我做过一个对比测试同一任务用单条长句提示词和用结构化框架提示词各跑20次。单条提示词的输出合格率大概在35%左右而结构化框架的合格率能到85%以上。差距不在模型能力在于信息组织方式。模型没有“读心术”它只能根据你显式给出的信息做推断。你隐含的期望越多它猜错的概率越大。结构化框架的好处是把隐含期望显式化。角色设定告诉它“你是谁”任务定义告诉它“做什么”上下文约束告诉它“边界在哪”输出格式告诉它“长什么样”示例锚定告诉它“参照什么标准”。五个维度各司其职模型解析起来负担小输出自然更稳。1.2 框架的五个模块分别解决什么问题角色设定解决的是语气和专业深度。你让模型扮演“资深专利代理人”和扮演“科技媒体编辑”同样写一篇专利解读输出风格完全不同。角色越具体模型调用的知识分布越集中。我通常会在角色里加入经验年限和领域细分比如“拥有十年通信领域专利撰写经验的代理人”比单纯写“专利代理人”效果好很多。任务定义解决的是动作明确性。不要写“帮我看看这段代码”要写“找出这段Python代码中的内存泄漏风险点并按严重程度排序”。动词要具体宾语要明确最好带上数量或范围限定。上下文约束解决的是边界控制。包括字数范围、必须包含的要素、必须避免的内容、目标读者是谁。这一块是很多人忽略的但恰恰是减少返工的关键。比如你写“面向非技术读者”模型就会自动减少术语密度增加类比。输出格式解决的是可解析性。如果你后续要把输出喂给另一个程序或智能体格式必须严格。Markdown表格、JSON、YAML选一种并给出字段说明。我见过太多人因为输出格式不固定导致下游解析失败。示例锚定解决的是标准对齐。给一两个输入输出示例模型就能理解你想要的颗粒度和风格。这在少样本场景下特别有效尤其是当你的需求很难用文字描述清楚时。2. 五个模块的详细拆解与实操写法知道了框架结构接下来是每个模块具体怎么写。我会给出可直接套用的模板同时解释每个字段背后的逻辑。你不需要每次都写满五个模块但刚开始建议写全熟练之后再根据场景裁剪。2.1 角色设定让模型站对位置角色设定的核心是限定知识域和表达姿态。我常用的模板是你是一位在[领域]有[年限]年经验的[职位]擅长[具体技能1]和[具体技能2]服务过[目标客户类型]习惯用[表达风格]沟通。举个例子如果你要做一个销售智能体角色可以这样写你是一位在SaaS行业有八年经验的销售顾问擅长挖掘客户隐性需求和处理价格异议服务过中小型制造企业客户习惯用数据驱动的方式沟通语气直接但不压迫。这里每个字段都有作用。“SaaS行业”限定知识域“八年”暗示经验深度“挖掘隐性需求”和“处理价格异议”是核心技能“中小型制造企业”限定客户画像“数据驱动、直接但不压迫”限定沟通风格。模型拿到这些信息后生成的对话策略会明显更贴合实际销售场景。常见错误是角色写得太泛比如“你是一个 helpful assistant”。这种角色等于没写模型会退回到默认的通用语气。另一个错误是角色和任务不匹配比如让“创意文案写手”去写技术文档输出会偏感性缺乏严谨性。我的经验是角色设定里至少包含一个领域限定和一个风格限定。领域限定让模型知道调用哪部分知识风格限定让模型知道用什么语气输出。两者缺一不可。2.2 任务定义把动作拆到不可再分任务定义要回答三个问题做什么、对什么做、做到什么程度。我见过最常见的错误是把多个任务塞进一句话里比如“帮我分析这份财报并写一份投资建议并翻译成英文”。模型会顾此失彼要么分析不深要么翻译生硬。正确的做法是拆成多步或者明确主次。如果必须在一个提示词里完成就写清楚执行顺序第一步分析这份财报中的营收、利润、现金流三个核心指标的变化趋势。第二步基于分析结果撰写一份300字以内的投资建议面向个人投资者。第三步将投资建议翻译成英文保持金融术语准确。这样模型就知道先做什么、再做什么每一步的产出标准也清晰。任务定义里的动词要选可验证的比如“列出”“排序”“对比”“生成”“改写”而不是“理解”“思考”“把握”这种无法验证的动作。还有一个技巧是给任务加约束条件。比如“列出至少5个风险点按发生概率从高到低排序每个风险点附带一句缓解建议”。数量、排序方式、附加要求都明确输出就不会跑偏。2.3 上下文约束把边界画清楚上下文约束是提示词里的“护栏”。没有护栏模型会自由发挥发挥得好是惊喜发挥得差就是灾难。我通常从四个维度写约束长度约束总字数范围、每段字数范围、列表项数量。内容约束必须包含的要素、必须排除的要素、敏感词规避。读者约束目标读者的知识水平、阅读场景、预期收获。风格约束正式或口语、技术或通俗、简洁或详尽。举个例子如果你要生成一篇面向小白的AI工具介绍约束可以这样写总字数800到1000字。必须包含工具的核心功能、适用场景、上手难度三个要素。避免使用“神经网络”“梯度下降”等技术术语如必须出现需用生活化类比解释。目标读者是从未使用过AI工具的中小企业主阅读场景是手机端碎片时间。风格口语化每段不超过四行。这些约束写进去之后模型的输出会明显更贴合需求。我实测下来加了读者约束和风格约束的提示词返工率能降低一半以上。注意约束不要互相矛盾。比如同时要求“详尽”和“300字以内”模型会陷入两难输出质量反而下降。约束之间要有优先级如果必须取舍在提示词里写明“优先保证XX其次考虑XX”。2.4 输出格式让结果可直接使用输出格式决定了你的提示词产出能不能被下游流程直接消费。如果你只是自己看Markdown就够了。如果你要把结果喂给智能体、数据库或前端页面就必须用结构化格式。我常用的格式有三种Markdown表格适合对比分析、参数说明、问题排查。JSON适合字段固定的结构化数据比如提取实体、分类结果。YAML适合层级较深、人类可读性要求高的配置类输出。以JSON为例你需要在提示词里给出字段名和类型以JSON格式输出包含以下字段summary字符串100字以内摘要、risks数组每个元素包含name和level两个字段、recommendation字符串200字以内建议。不要输出JSON以外的任何内容。最后一句“不要输出JSON以外的任何内容”很关键。模型有时候会加一句“好的以下是JSON”导致解析失败。明确禁止之后输出就干净了。2.5 示例锚定用一两个例子对齐标准示例锚定是少样本提示的核心。你给一两个输入输出对模型就能理解你想要的颗粒度。示例不需要多一两个就够但质量要高。比如你要做一个专利辅助链接的AI助手示例可以这样写输入一种基于深度学习的图像去噪方法。输出技术领域分类为G06T5/00相关链接建议包括专利检索平台的分类号导航页和该领域的综述文章入口。示例的作用是传递隐性标准。有些要求你很难用文字描述但给一个例子模型立刻就懂了。我通常在示例后面加一句“请参照以上示例的颗粒度和格式”进一步强化对齐。示例的常见错误是太长或太短。太长会占用上下文窗口太短又传递不了足够信息。我的经验是每个示例控制在50到150字之间输入输出各占一半。3. 完整提示词模板与实战案例把五个模块拼起来就是一个完整的提示词框架。下面我给出一个通用模板然后用在三个不同场景里做演示。你可以直接复制模板替换方括号里的内容。3.1 通用模板结构# 角色 你是一位在[领域]有[年限]年经验的[职位]擅长[技能1]和[技能2]服务过[客户类型]习惯用[风格]沟通。 # 任务 请执行以下任务[具体动作]针对[对象]达到[标准]。 执行顺序第一步[动作1]第二步[动作2]第三步[动作3]。 # 约束 - 长度[字数范围] - 必须包含[要素列表] - 必须避免[排除列表] - 目标读者[读者画像] - 风格[风格描述] # 输出格式 [格式类型]包含以下字段[字段说明]。 不要输出格式以外的任何内容。 # 示例 输入[示例输入] 输出[示例输出] 请参照以上示例的颗粒度和格式。这个模板看起来有点长但实际写起来五分钟就能填完。熟练之后你可以根据场景只保留必要的模块。比如简单的文本改写角色和约束就够了复杂的智能体开发五个模块都要写全。3.2 案例一AI编程提示词假设你要让模型帮你审查一段代码。很多人直接写“帮我看看这段代码有没有问题”输出往往很泛。用框架改写角色你是一位有十年经验的Python后端工程师擅长性能优化和安全审计服务过金融级高并发系统习惯用直接、量化的方式沟通。任务审查以下代码找出性能瓶颈和安全风险按严重程度排序每个问题给出修复建议。约束必须包含至少3个问题点。每个问题点说明触发条件和影响范围。避免泛泛而谈“建议优化”要给出具体行号和修改方案。目标读者是中级开发者。输出格式Markdown表格列为问题类型、行号、严重程度、问题描述、修复建议。示例输入一段包含SQL拼接的代码输出中标注“SQL注入风险第12行高危用户输入直接拼接进查询语句建议使用参数化查询”。这样输出的审查结果可以直接贴到代码评审里不需要二次整理。我实测下来加了行号和修复建议之后开发者的采纳率明显提高。3.3 案例二销售智能体对话提示词销售智能体的难点在于多轮对话中保持角色一致性和目标推进。用框架可以这样写角色你是一位有八年经验的SaaS销售顾问擅长挖掘客户隐性需求和处理价格异议服务过中小型制造企业习惯用数据驱动的方式沟通语气直接但不压迫。任务与客户进行需求沟通目标是在五轮对话内明确客户的痛点、预算范围和决策流程。约束每轮回复不超过三句话。不主动报价格先确认需求。遇到价格异议时先共情再给价值锚点。避免使用“绝对”“保证”等承诺性词汇。输出格式每轮回复后用括号标注当前对话阶段如需求挖掘、预算确认、决策流程。示例客户说“你们太贵了”回复“理解价格确实是重要考量。方便说说您目前用的是什么方案以及最不满意的地方吗价格异议处理”这个提示词的关键在于把销售方法论编码进了约束里。模型不需要自己发挥销售策略只需要按照给定的节奏推进。我帮几个销售团队做过类似的智能体成单率比无框架的版本高出不少核心原因就是对话节奏稳定不会因为模型自由发挥而跑偏。3.4 案例三专利辅助链接生成专利领域的AI辅助对准确性要求极高提示词必须严格约束。参考写法角色你是一位有十年通信领域专利撰写经验的代理人擅长技术分类和检索策略服务过大型科技企业的知识产权部门习惯用精确、可验证的方式沟通。任务根据给定的技术方案描述生成技术领域分类号建议和相关检索链接建议。约束分类号必须精确到小组级别。链接建议只包含专利检索平台的分类号导航页和该领域综述文章入口。不生成任何具体专利号。避免推测性表述不确定的内容标注“需人工确认”。输出格式JSON包含classification字符串、links数组每个元素包含name和url_type两个字段、notes字符串。示例输入“一种基于深度学习的图像去噪方法”输出classification为“G06T5/00”links包含“分类号导航页”和“图像去噪综述入口”notes为“需人工确认分类号是否适用于具体应用场景”。这个提示词里“不生成任何具体专利号”和“不确定的内容标注需人工确认”是两条关键约束。专利场景下模型编造专利号的风险很高必须从提示词层面堵住。4. 常见问题与排查技巧实录即使用了框架实际跑的时候还是会遇到各种问题。我整理了几个高频问题和对应的排查思路都是实际项目中踩过的坑。4.1 输出不稳定同样提示词结果差异大这是最常见的问题。原因通常有三个温度参数过高、约束不够具体、模型版本差异。温度参数控制输出的随机性。如果你用的是API把temperature调到0.2到0.5之间输出会稳定很多。如果是网页版没法调参数就靠加强约束来补偿。约束越具体模型自由发挥的空间越小输出越稳定。另一个原因是约束里有模糊词汇。比如“适当详细”“尽量专业”这种词模型每次理解都不一样。改成“每段不少于150字”“必须包含三个案例”稳定性立刻提升。模型版本差异也需要注意。同一个提示词在不同模型上的表现可能差很多。我的做法是针对主力模型调优然后在其他模型上做兼容性测试。如果差异太大就在提示词里加一句“请严格按照以下格式输出不要添加额外解释”。4.2 模型忽略约束该避免的没避免模型忽略约束通常是因为约束太多或者约束之间冲突。人的工作记忆有限模型也一样。如果你在提示词里塞了二十条约束模型会顾此失彼。我的经验是约束不超过七条并且按优先级排序。最重要的约束放在最前面用加粗或单独一行强调。如果某条约束特别关键就在示例里体现出来。比如你要求“不生成具体专利号”就在示例的输出里不出现专利号模型会模仿示例的行为。还有一种情况是约束和任务冲突。比如你要求“简洁”但任务本身需要详细分析模型会优先满足任务忽略约束。这时候需要调整任务定义把“简洁”改成“分点陈述每点不超过两句话”让约束变得可执行。4.3 输出格式不对解析总是失败格式问题多半是因为模型在输出前后加了额外内容。比如你要求JSON它给你“好的以下是JSON{...}”。解决办法是在提示词末尾加一句“不要输出任何解释性文字直接输出JSON”。如果还是不行就用输出前缀锚定。在提示词里写“请以{开头输出”模型会倾向于直接进入JSON结构。这个技巧在多个模型上都验证过效果明显。另一个格式问题是字段缺失或类型错误。这通常是因为字段说明不够清楚。把每个字段的类型、长度、是否必填都写清楚最好给一个示例值。比如“summary字符串100字以内必填示例本方案通过深度学习提升图像质量”。4.4 多轮对话中角色漂移智能体开发中多轮对话后模型会逐渐忘记角色设定语气变得通用。解决办法是在每轮对话中重新注入角色和约束。如果你用的是智能体框架把角色设定放在系统提示词里每轮都带上。如果是手动对话就在关键节点提醒一句“请继续保持[角色]的身份和[风格]语气”。还有一个技巧是在输出格式里加入角色自检。比如要求模型在每轮回复末尾用括号标注当前角色状态像“销售顾问需求挖掘阶段”。这样模型会时刻意识到自己在扮演什么角色漂移概率大大降低。4.5 常见问题速查表问题现象可能原因排查动作解决技巧输出每次不一样温度高、约束模糊检查temperature参数和约束用词温度降到0.3模糊词改量化词忽略某条约束约束过多或冲突数一下约束数量检查是否矛盾约束控制在7条内按优先级排序JSON解析失败模型加了额外文字看输出前后是否有解释性内容加“直接输出JSON”和前缀锚定角色语气漂移多轮后角色设定被稀释检查系统提示词是否每轮携带每轮注入角色加角色自检标注示例没被参照示例太长或太短检查示例长度和颗粒度示例控制在50-150字加“参照示例”指令这张表可以贴在工位上遇到问题先对照排查。大部分提示词问题都能在这五类里找到原因。5. 进阶技巧让提示词框架适配智能体开发如果你在做智能体开发提示词框架需要做一些调整。智能体的核心是自主决策和工具调用提示词不仅要定义角色和任务还要定义决策逻辑和工具使用规则。5.1 智能体提示词的三层结构我通常把智能体提示词分成三层系统层、决策层、执行层。系统层定义智能体的身份、能力和边界相当于给智能体一个“人格”。这一层在整個生命周期内不变。决策层定义智能体在什么情况下做什么选择。比如“当用户询问价格时先确认需求再报价”“当工具调用失败时重试一次后转人工”。这一层是智能体自主性的来源。执行层定义具体工具调用的参数格式和输出处理方式。比如“调用搜索工具时query字段不超过50字”“工具返回结果后提取前三条作为参考”。三层分开写的好处是便于调试。如果智能体决策出错你只需要改决策层不用动系统层和执行层。如果工具调用出错只查执行层。这种模块化设计在复杂智能体项目里特别重要。5.2 工具调用提示词的写法工具调用是智能体开发中最容易出问题的环节。模型经常调用不存在的工具、传错参数、或者该调用的时候不调用。解决办法是在提示词里明确工具清单和调用条件。可用工具search搜索、calculate计算、summarize摘要。 调用规则当用户询问实时信息时调用search当涉及数值计算时调用calculate当输入超过500字时调用summarize。 参数格式search的query字段为字符串不超过50字calculate的expression字段为合法数学表达式。 如果不需要调用工具直接回复“无需工具”。这段提示词把工具清单、调用条件、参数格式、兜底策略都写清楚了。模型知道什么时候该调用、怎么调用、不调用时怎么办。我实测下来加了这段之后工具调用的准确率能到90%以上。5.3 智能体框架选型的提示词适配不同的智能体框架对提示词的要求不一样。有的框架自带系统提示词模板你只需要填变量有的框架完全自定义你需要从零写。如果你用的是自带模板的框架重点是把角色和约束填进模板的对应字段不要试图覆盖框架的底层逻辑。如果你用的是完全自定义的框架建议按照上面说的三层结构来写同时留出足够的调试接口。不管用什么框架有一条原则不变提示词里的每一句话都要有明确目的。不要写“你是一个有用的助手”这种废话要写“你在用户询问价格时先确认需求再报价”。前者是装饰后者是逻辑。6. 我踩过的坑和最后分享的几个技巧做提示词工程这几年踩过的坑比写过的提示词还多。挑几个最有代表性的说说希望能帮你省点时间。第一个坑是过度追求“万能提示词”。我曾经花了两周时间想写一条通杀所有任务的提示词结果发现越写越长最后模型根本记不住。后来想明白了提示词框架的价值在于可迁移的结构而不是一条具体的提示词。结构可以复用内容必须定制。第二个坑是忽略模型的上下文窗口限制。提示词写得太长把示例和约束都塞进去结果模型处理到后面已经忘了前面。解决办法是把最重要的信息放在最前面和最后面中间放次要信息。模型对开头和结尾的记忆最强。第三个坑是不做A/B测试。改了一版提示词感觉效果好了就直接上线。后来发现只是那几次运气好。现在我每次改提示词都会跑至少20次对比测试看合格率有没有统计意义上的提升。虽然麻烦但能避免很多无效优化。最后分享一个小技巧给你的提示词加版本号。每次修改都记下版本号和修改内容跑测试的时候标注版本。这样出问题可以快速回滚也能积累经验。我现在的提示词库里有上百个版本每个都对应不同的场景和模型用的时候直接调不用重新写。提示词工程没有终点模型在进化场景在变化你的框架也需要持续迭代。但只要掌握了这套结构化的方法你就能以不变应万变把精力花在解决实际问题上而不是跟模型斗智斗勇。