提示词工程框架搭建指南：5步实现从个人经验到团队资产

1. 为什么“会写提示词”和“搭建提示词工程框架”是两码事

很多人第一次接触大模型，都是从“帮我写一段文案”“给我生成一张图”开始的。输入一句话，得到一个还不错的结果，于是产生一种错觉：提示词不过就是“会说话”。但真正在项目里用过大模型的人都知道，单次对话能出好结果，和稳定、批量、可复用地产出好结果，中间隔着一整套工程化的距离。

我见过太多团队卡在同一个地方：某个人手里攒了几十条“神级提示词”，换个人用就废了，换个模型版本效果直接腰斩，业务量一上来全靠人肉复制粘贴。这不是提示词的问题，是没有框架的问题。提示词工程框架要解决的，就是把“个人经验”变成“团队资产”，把“碰运气”变成“可复现”。

这篇文章面向三类人：一是刚上手大模型、想把提示词用明白的开发者；二是需要把 AI 能力接进业务、但不知道怎么规范化的产品和技术负责人；三是做 AI 绘画、AI 编程、AI 内容生成，想沉淀自己提示词库的创作者。我会用 5 个步骤，把一套能落地的提示词工程框架讲清楚，每一步都告诉你为什么这么做、具体怎么操作、容易踩什么坑。

先给一个整体认知：提示词工程框架不是某个工具，也不是某个模板，而是一套结构化的方法论加配套的资产管理机制。它包含角色定义、任务拆解、上下文组织、输出约束、评测迭代五个核心环节。下面逐步展开。

2. 第一步：把角色和边界定死，别让模型自由发挥

2.1 角色定义到底在定义什么

新手写提示词最常见的问题是上来就提要求：“写一篇关于 XX 的文章”。模型不知道你是谁、给谁写、什么风格、多长、要不要专业术语。它只能按训练数据里最平均的分布去猜，结果就是那种“正确的废话”。

角色定义的本质，是给模型一个概率分布的锚点。大模型的输出本质是在给定上下文下预测下一个 token，你给的上下文越具体，它落到的分布区间就越窄，输出就越可控。所以角色不是写着玩的“你是一个资深专家”，而是要包含四个要素：

• 身份：模型扮演谁，决定知识调用范围
• 受众：输出给谁看，决定语言难度和表达方式
• 目标：这次任务要达成什么，决定内容取舍
• 边界：什么不能做、什么不该说，决定安全性和准确性

我拿一个实际例子对比。差的写法是：“你是一个文案专家，帮我写产品介绍。”好的写法是：

你是一名有 8 年 B2B SaaS 行业经验的产品市场经理。 你的读者是中小企业的 IT 负责人，他们关心成本、部署难度和售后。 本次任务是为我们的数据备份产品写一段 200 字以内的介绍。 要求：不用夸张形容词，突出“30 分钟完成部署”和“按量计费”两个卖点。 禁止：不要提“行业领先”“颠覆式”这类无法验证的表述。

后者为什么有效？因为它把“文案专家”这个宽泛身份，收窄到了“B2B SaaS 产品市场经理”，模型调用的语料和表达习惯立刻变了。受众一确定，用词深浅自动匹配。边界一写，那些空话套话就被压下去了。

2.2 系统提示词和用户提示词要分开管

这是很多人忽略的工程细节。系统提示词（system prompt）是长期稳定的角色设定和规则，用户提示词（user prompt）是每次变化的具体任务。把两者混在一起写，会导致两个问题：一是复用性差，每次都要重写角色；二是容易被用户输入覆盖，规则失效。

正确的做法是分层管理。系统层放不变的：身份、语气、安全规则、输出格式约定。用户层放变化的：具体任务、当次输入的数据、临时要求。我通常会在系统提示词里写死这几条：

你是 XX 领域的助手。 输出一律使用简体中文。 不确定的信息必须标注“待核实”，不得编造。 涉及数字和事实，必须给出推理过程。 每次回答先给结论，再给依据。

这几条看起来简单，但能挡掉大量问题。尤其是“不确定必须标注”和“先结论后依据”，前者抑制幻觉，后者提升可读性。实测下来，加了这两条之后，模型胡编乱造的比例明显下降。

注意：系统提示词不是越长越好。超过一定长度后，模型对中间部分的注意力会衰减，这叫“中间遗忘”。核心规则尽量放在开头和结尾，中间放次要说明。

2.3 边界设定里的三个常见误区

第一个误区是把“禁止”写得太抽象。比如“不要输出有害内容”，模型对“有害”的理解和你不一致。要具体到场景，比如“不要对用户的健康状况给出诊断性结论，只能建议就医”。

第二个误区是只写禁止不写替代。你告诉模型“不要用专业术语”，它可能变得过于口语化。更好的写法是“避免术语，如果必须使用，紧跟一句大白话解释”。

第三个误区是忽略输出长度和格式的边界。不写长度，模型可能给你 50 字也可能给你 2000 字。不写格式，它可能用散文也可能用列表。这些都要在边界里明确。

3. 第二步：任务拆解，把大目标切成模型能执行的原子步骤

3.1 为什么一步到位往往做不好

大模型在单次推理里能处理的逻辑深度是有限的。你让它“读一篇文章，总结观点，翻译成英文，再改写成推文”，它很可能在某个环节偷懒或者串味。这不是模型笨，是任务复杂度超过了单次上下文窗口的有效处理能力。

任务拆解的核心思路，是把复合任务拆成有明确输入输出的原子任务，每个原子任务只做一件事。这样做的好处有三个：每步可单独验证、出错能定位、中间结果可复用。

我拿“用 AI 生成一份竞品分析报告”举例。一步到位的写法是：“分析这三个竞品，输出一份报告。”拆解之后是这样：

1. 提取每个竞品的核心功能列表
2. 对比功能差异，输出对比表
3. 分析每个竞品的定价策略
4. 总结各自的优劣势
5. 给出针对性的建议

每一步的输出都是下一步的输入。第 1 步错了，你能立刻发现是信息提取的问题，而不是等到最后报告出来才发现方向偏了。

3.2 拆解的粒度怎么把握

拆得太粗没效果，拆得太细成本高。我的经验是：一个原子任务，模型在一次回答里能稳定完成，且输出可以用一两句话验证对错。如果一步的输出需要你花很长时间检查，说明拆得还不够细。

还有一个判断标准：如果某一步的提示词里出现了“然后”“接着”“同时”这类连接词，通常意味着这里可以拆。因为这些词背后往往是多个独立动作。

对于 AI 绘画这类场景，拆解逻辑不太一样。绘画提示词通常按“主体 + 风格 + 构图 + 光影 + 画质”几个维度组织，每个维度是一组关键词。比如生成古风人物形象，主体是“身着唐制齐胸襦裙的女子”，风格是“工笔重彩”，构图是“半身像，居中”，光影是“柔和侧光”，画质是“高清，细节丰富”。这本质上也是一种拆解，把模糊的“画个古风美女”拆成可控的维度。

3.3 上下文工程：拆解之后怎么把信息传下去

拆解带来的新问题是：每一步怎么知道前面发生了什么。这就是上下文工程要解决的。上下文工程和提示词工程的区别在于，提示词工程关注“怎么说”，上下文工程关注“给模型看什么”。

常见的上下文组织方式有三种：

我一般用结构化状态。比如每一步的输出都存成一个 JSON，下一步只取需要的字段。这样既控制了长度，又保证了关键信息不丢。举个实际的结构：

{ "step": 2, "task": "功能对比", "input": { "product_a_features": ["..."], "product_b_features": ["..."] }, "output": { "comparison_table": "...", "key_differences": ["..."] } }

下一步要用的时候，直接把key_differences塞进提示词就行，不用把整个历史对话都带上。

提示：上下文不是越多越好。无关信息会稀释模型的注意力。每次传上下文之前问自己一句：这条信息对当前这一步的判断有影响吗？没有就删掉。

4. 第三步：输出约束，让结果从“能用”变成“好用”

4.1 格式约束是最容易被低估的环节

很多人觉得格式是小事，内容好就行。但在工程场景里，格式不对等于不可用。你要把模型输出接进下游系统，它给你一段散文，你还得再写个解析器，成本反而更高。

格式约束要在提示词里写死。常用的几种：

• JSON：适合结构化数据，接 API 首选
• Markdown 表格：适合对比展示
• 有序列表：适合步骤说明
• 固定字段：适合信息抽取

写 JSON 约束的时候，最好给一个示例结构。模型对示例的遵循度远高于纯文字描述。比如：

请按以下 JSON 格式输出，不要添加任何额外文字： { "summary": "一句话总结", "points": ["要点1", "要点2"], "confidence": "high/medium/low" }

“不要添加任何额外文字”这句很关键。不加的话，模型很可能在 JSON 前后加一句“好的，以下是结果”。

4.2 质量约束：怎么让输出更靠谱

格式解决的是“能不能用”，质量解决的是“好不好用”。质量约束我通常从三个维度下手：

准确性：要求模型对不确定的内容标注。比如“如果信息来自推测，请在句末标注[推测]”。这一条能让你快速识别哪些内容需要人工复核。

完整性：明确要求覆盖哪些点。比如“必须包含成本、效率、风险三个方面的分析”。不写的话，模型可能只挑它擅长的说。

一致性：要求术语统一。比如“全文统一使用‘用户’而不是‘客户’‘消费者’混用”。这在长文生成里特别重要。

4.3 用少样本示例代替长篇解释

与其花 500 字解释你要什么风格，不如给 2 到 3 个示例。模型从示例里学到的模式，比从描述里学到的更准确。这叫少样本提示（few-shot）。

示例的选择有讲究：要覆盖典型情况，也要覆盖边界情况。比如做信息抽取，给两个正常示例，再给一个“信息缺失时怎么输出”的示例，模型就知道遇到缺失该怎么处理了。

示例的数量不是越多越好。2 到 5 个通常够用，太多会占用上下文还可能导致模型过度拟合示例的表面特征。我试过给 10 个示例，结果模型开始机械模仿示例的句式，反而失去了灵活性。

5. 第四步：评测与迭代，没有评测的框架都是自嗨

5.1 怎么建立一套能跑的评测机制

提示词写完不是终点，是起点。没有评测，你根本不知道改了一版是变好了还是变差了。评测机制不用很复杂，核心是固定测试集 + 明确评分标准。

测试集怎么建：从真实业务场景里挑 20 到 50 个典型输入，覆盖简单、中等、困难三档。每个输入配一个“期望输出”或者“期望特征”。比如做摘要任务，期望特征可以是“包含三个核心观点”“不超过 200 字”“没有事实错误”。

评分标准要可操作。不要用“好/中/差”这种模糊标准，用具体维度打分：

每次改完提示词，跑一遍测试集，看总分变化。这样你才知道改动是有效还是无效。

5.2 迭代的方向怎么找

评测跑完，分数低的地方就是迭代方向。但要注意区分两类问题：提示词问题和模型能力问题。有些任务模型就是做不好，你再怎么改提示词也没用，这时候要考虑换模型或者换方案。

判断方法：如果同一个任务，你换三种不同的提示词写法，效果都差不多且都不理想，大概率是模型能力边界。如果不同写法效果差异很大，说明还有优化空间。

迭代的常见手段包括：调整角色描述的颗粒度、增加或减少示例、改变任务拆解方式、调整输出约束的严格程度。每次只改一个变量，否则你分不清是哪个改动起了作用。

5.3 版本管理：别让提示词变成一次性消耗品

提示词要像代码一样管理。我见过太多团队，提示词散落在各个人的聊天记录和文档里，改了一版不知道旧版在哪，出了问题没法回滚。

最低成本的版本管理：用一个表格记录每次改动。字段包括版本号、改动内容、改动原因、评测分数、上线时间。再进一步，把提示词存成文件，用 Git 管理。系统提示词、用户提示词模板、示例库分开存放。

prompts/ system/ base.txt safety.txt tasks/ summarize_v3.txt extract_v2.txt examples/ summarize_examples.json

这样做的好处是，换模型的时候你可以快速对比新旧版本表现，而不是从头再来。

6. 第五步：资产化与复用，让框架真正产生复利

6.1 把提示词变成可组合的模块

框架搭到最后，你会发现很多提示词片段是通用的。比如“输出 JSON 格式”“不确定标注”“先结论后依据”这些约束，几乎每个任务都要用。把它们抽成模块，用的时候拼装，能省大量重复劳动。

我的做法是维护一个“约束库”和“角色库”。约束库放各种输出格式和质量要求，角色库放不同领域的身份设定。新建任务的时候，从库里挑合适的模块组合，再补上任务特有的部分。

这种模块化还有个好处：改一处，所有引用它的任务都受益。比如你发现“不确定标注”这条规则需要加强，改一次约束库，所有任务同步生效。

6.2 跨场景复用的实际案例

拿 AI 编程提示词和 AI 绘画提示词举例，表面看是两个完全不同的场景，但框架是相通的。

AI 编程场景：角色是“资深后端工程师”，任务是“根据需求写接口”，上下文是“现有代码结构和技术栈”，输出约束是“符合 PEP8 规范，带类型注解”，评测是“能否通过单元测试”。

AI 绘画场景：角色是“插画师”，任务是“生成古风人物”，上下文是“参考风格和构图要求”，输出约束是“分辨率、比例、负面提示词”，评测是“是否符合描述、有无畸变”。

你看，五个环节一一对应。框架的价值就在于，你学会一套，能迁移到很多场景。这也是为什么我说“读完认知超 95% 的人”——大部分人停留在单点技巧，而框架是系统能力。

6.3 团队协作里的框架落地

一个人用框架和一群人用框架，难度不一样。团队落地最大的障碍是“各写各的”。解决办法是定规范：提示词必须包含哪几个部分、命名规则是什么、评测怎么跑、上线前谁审核。

我建议团队里设一个“提示词负责人”的角色，不一定是专职，但要有个人对提示词库的质量负责。新提示词入库要经过评测，改动要记录，定期清理失效的提示词。这些听起来像流程负担，但比起后期维护一堆没人敢动的“祖传提示词”，前期这点投入非常划算。

注意：框架不是越复杂越好。小团队两三个人，用表格加文件夹就够了，没必要上重型工具。框架的目的是解决问题，不是制造流程。

7. 实操中容易踩的坑和排查思路

7.1 输出不稳定，同样输入结果差异大

这是最常见的问题。原因通常有三个：一是提示词里有歧义，模型每次理解不同；二是温度参数设太高；三是上下文里有随机因素。

排查顺序：先把温度调到 0 或接近 0，看是否稳定。如果还不行，检查提示词里有没有“可以”“尽量”“适当”这类模糊词，全部换成明确要求。再不行，检查上下文里有没有每次都变的内容，比如时间戳、随机 ID。

7.2 模型不遵守格式约束

先检查约束是不是放在提示词末尾。模型对末尾内容的遵循度更高。如果还不行，加一句“如果无法按格式输出，请输出错误原因而不是自由发挥”。再不行，用少样本示例，给一个正确格式的例子。

还有一种情况是输出太长被截断，导致 JSON 不完整。这时候要么缩短输出要求，要么开启流式输出自己拼接。

7.3 任务拆解后，中间步骤信息丢失

这是上下文工程没做好。检查每一步的输出有没有结构化保存，下一步有没有把需要的字段传进去。常见错误是只传了自然语言摘要，把关键数字和专有名词丢了。

解决办法是中间结果用 JSON 存，传递的时候只取需要的字段，不要传整个历史。如果发现某一步经常丢信息，考虑在那一步的输出约束里明确要求“必须保留所有数字和专有名词”。

7.4 评测分数高但实际用起来不行

说明测试集和真实场景分布不一致。测试集太干净、太典型，真实输入往往更脏更乱。解决办法是从真实日志里采样做测试集，把那些“奇怪”的输入也纳入进来。

还有一种可能是评分标准偏了。比如你只评了格式没评内容，格式满分但内容空洞。这时候要调整评分维度和权重。

7.5 换模型后效果大幅波动

不同模型对提示词的敏感度不一样。有的模型对角色描述敏感，有的对示例敏感。换模型后不要直接套用旧提示词，先跑一遍评测，看哪些环节掉了，针对性调整。

一般来说，换模型后需要重新校准的地方包括：系统提示词的长度（不同模型的有效上下文不同）、示例的数量和形式、输出格式的严格程度。留出半天到一天做迁移测试，是值得的。

8. 我个人的一些实操体会

这套框架我用了挺长时间，最大的感受是：提示词工程的上限不在提示词本身，而在你对任务的理解深度。你如果自己都没想清楚要什么，模型更不可能给你。所以每次写提示词之前，我会先花几分钟把任务目标、输入输出、验收标准在纸上写一遍，写不清楚就说明还没想明白。

另一个体会是，不要追求“一次写完美”。提示词是迭代出来的，第一版能跑通就行，然后靠评测一步步优化。我见过有人花一整天憋一版“完美提示词”，结果一测全是问题，不如先出个 60 分的版本快速验证方向。

还有个小技巧：把提示词读给一个不了解这个任务的人听，如果他能听懂你要什么，说明提示词够清晰；如果他自己都听糊涂了，模型大概率也糊涂。这个方法帮我省了很多调试时间。

最后说一句关于工具的态度。现在各种提示词管理工具、评测平台很多，但工具解决的是效率问题，不是认知问题。框架想清楚了，用记事本也能跑；框架没想清楚，上再贵的工具也是白搭。先把这五步的逻辑吃透，再根据自己团队的情况选工具，顺序别反了。