五步框架：从零构建高质量AI提示词工程实战指南

1. 为什么大多数人写提示词都在做无用功

我见过太多人把提示词当成“咒语”来用。打开对话框，敲一句“帮我写个方案”，结果不满意，就换一句“请帮我写一个高质量的方案”，还是不满意，再改成“你是一个资深专家，请帮我写一个非常高质量的方案”。折腾半小时，输出质量原地踏步。

问题出在哪？他们把提示词工程理解成了“措辞优化”，而实际上它是一套结构化的需求表达系统。你写提示词的水平，本质上取决于你把模糊需求翻译成精确指令的能力。这跟写代码之前要先画架构图是一个道理——你不会上来就敲业务逻辑，你会先想清楚模块怎么分、数据怎么流、边界在哪。

我刚开始接触大模型的时候也走过弯路。那时候觉得提示词就是“会说话就行”，直到有一次用AI辅助做竞品分析，输出全是正确的废话，我才意识到：模型不缺知识，缺的是你告诉它“用哪部分知识、按什么结构、输出给谁看”。后来我花了两周时间，把提示词拆成了五个可复用的模块，输出质量直接上了一个台阶。这套框架我用了大半年，从写代码、做方案、分析数据到生成原型图，基本没翻过车。

这篇文章就是把这套框架完整拆开，从底层逻辑到实操步骤，再到常见坑的排查，全部讲透。不管你是刚接触AI提示词的新手，还是已经用过一段时间但输出不稳定的人，这套方法都能直接抄作业。核心关键词就两个：AI提示词和提示词工程，但我会把它们拆成你能直接上手操作的东西，而不是停留在概念层面。

2. 五步框架的整体设计与底层逻辑

2.1 为什么是五步而不是三步或十步

市面上讲提示词的文章很多，有说“角色+任务+格式”三步走的，也有列十几条技巧的。三步太粗，遇到复杂任务就兜不住；十几步太碎，记都记不住，更别说用了。

我总结的五步是：角色锚定、上下文注入、任务拆解、输出约束、迭代校准。这五步覆盖了从“让模型知道它是谁”到“让模型知道做到什么程度算好”的完整链路。每一步解决一个特定问题，缺了哪一步，输出就会在某个维度上失控。

举个例子。你让模型“写一个Python爬虫”，这是任务。但如果不告诉它“你是资深后端工程师，代码要符合PEP8，异常处理要完整”，它可能给你一个能跑但极其粗糙的脚本。如果不给它“目标网站的结构特征”，它可能用错选择器。如果不约束“输出只要代码不要解释”，它可能给你一大段文字说明。如果不做迭代校准，你可能永远不知道它在哪个环节理解偏了。

五步框架的价值在于：每一步都是一个检查点。输出不好的时候，你可以快速定位是哪一步没做到位，而不是盲目地换措辞。

2.2 框架背后的核心原理：降低模型的“猜测成本”

大模型的工作原理是基于概率生成文本。你给的指令越模糊，它需要“猜”的空间就越大。猜对了是运气，猜错了是常态。

这就像你让一个装修师傅“把墙弄好看点”。他可能刷白、可能贴壁纸、可能做艺术漆，每一种都“好看”，但未必是你想要的。如果你说“客厅电视背景墙，现代简约风格，浅灰色乳胶漆，不要壁纸”，他就不需要猜了。

提示词工程的核心就是把模型的猜测成本降到最低。角色锚定告诉它“用谁的经验来猜”，上下文注入告诉它“基于什么信息来猜”，任务拆解告诉它“按什么顺序来猜”，输出约束告诉它“猜成什么样算合格”，迭代校准则是“猜偏了怎么拉回来”。

这五个环节环环相扣。少了角色，模型会用通用视角回答，深度不够；少了上下文，模型会用训练数据里的平均答案，针对性不强；少了任务拆解，模型会按自己的理解组织内容，结构可能混乱；少了输出约束，格式和篇幅不可控；少了迭代校准，你无法系统性地优化。

2.3 这套框架适合什么场景

这套框架的适用范围非常广。我实测下来，以下几类任务效果最明显：

• 代码生成与调试：比如“AI写代码+规则设定+提示词工程”这个热词场景，用五步框架可以生成结构清晰、注释完整、异常处理到位的代码，而不是那种“能跑但不敢用”的片段。
• 数据分析与预测：像“AI预测Airbnb房价提示词”这类任务，需要模型理解数据字段、选择建模思路、输出可解释的结果，五步框架能确保它不跑偏。
• 产品原型与设计：比如“让墨刀AI生成App原型图又快又准”，关键在于把页面结构、交互逻辑、视觉风格拆解清楚，这正是任务拆解和输出约束要解决的问题。
• 内容创作与策划：从写文章到做方案，角色锚定和上下文注入能显著提升输出的专业度和针对性。

不适合的场景也有：纯事实查询（“今天天气怎么样”）不需要这么复杂；创意发散类任务（“帮我想100个名字”）可以适当简化约束，否则会限制模型的创造力。

3. 每一步的核心细节与实操要点

3.1 角色锚定：不是写“你是一个专家”就完事了

很多人写角色就是“你是一个资深XX专家”，这基本等于没写。因为“资深专家”太泛了，模型不知道用哪个领域的知识、什么年代的实践、什么风格的表达。

有效的角色锚定要包含三个要素：领域+经验年限+输出风格。

比如你要生成一个React组件，不要写“你是一个前端专家”，要写“你是一个有8年React开发经验的前端工程师，熟悉Hooks和TypeScript，代码风格偏向函数式编程，注释简洁但关键逻辑必须说明”。

再比如你要做竞品分析，不要写“你是一个分析师”，要写“你是一个在SaaS行业做了5年竞品分析的产品经理，擅长用SWOT和波特五力模型，输出风格是结论先行、数据支撑、不写废话”。

这里有个细节：经验年限不是随便写的。3年和8年的区别在于，8年经验意味着模型会调用更复杂的模式识别和更成熟的判断逻辑。我实测下来，写“8年”比写“资深”的输出质量高出一截，因为“资深”太模糊，而具体数字给了模型一个明确的“经验密度”信号。

还有一个坑：不要给模型设太多角色。有人写“你是一个既懂技术又懂业务还懂设计的全栈专家”，这种角色等于没有角色，模型会回到通用模式。一个提示词只锚定一个核心角色，需要多角色协作就分多次调用。

3.2 上下文注入：给模型“喂”它不知道的信息

模型的知识来自训练数据，它不知道你的项目背景、业务约束、用户特征。上下文注入就是把这些信息补给它。

上下文分三类：

• 背景信息：项目是做什么的、目标用户是谁、当前处于什么阶段。
• 约束条件：技术栈限制、预算限制、时间限制、合规要求。
• 参考素材：已有的代码片段、数据样本、设计稿描述、竞品链接。

我见过最常见的错误是：上下文给太多，但没有重点。有人把整个需求文档粘贴进去，几千字，模型反而抓不住关键。正确的做法是分层给：先给一段话概括背景，再给关键约束的列表，最后给必要的参考素材。

比如做“AI漫剧提示词”这个场景，上下文可以这样写：

背景：我们要生成一个3分钟短漫剧的分镜脚本，目标平台是短视频，受众是18-25岁年轻人。 约束：每集不超过5个场景，每个场景不超过3句对白，风格偏轻松搞笑，不能出现暴力或敏感内容。 参考：第一集已经确定主角是一个外卖员和一只会说话的猫，冲突点是外卖超时。

这样模型就知道该往哪个方向生成，而不是给你一个通用的剧本模板。

3.3 任务拆解：把“大活”切成“小活”

这是五步里最容易被忽略但最关键的一步。你让模型“写一个完整的App”，它大概率会给你一个框架，但细节经不起推敲。你把它拆成“先设计数据库表结构，再写API接口，再写前端页面，最后写部署脚本”，每一步的输出质量都会高很多。

任务拆解的核心原则是：每个子任务都有明确的输入和输出。

比如“AI编程提示词”这个场景，不要写“帮我写一个用户登录功能”，要拆成：

1. 设计用户表结构，包含字段名、类型、约束、索引。
2. 写登录接口的伪代码，包含参数校验、密码加密、token生成、异常处理。
3. 写前端登录表单的React组件，包含表单校验、loading状态、错误提示。
4. 写单元测试用例，覆盖正常登录、密码错误、账号不存在三种情况。

每个子任务单独调用一次模型，输出质量比一次性生成高得多。而且这样做还有一个好处：你可以逐步验证。第一步的表结构不对，后面就不用继续了，省时间。

3.4 输出约束：告诉模型“做到什么程度算好”

输出约束包括四个方面：格式、篇幅、风格、禁止项。

格式约束最常用的是Markdown、JSON、表格、代码块。比如“输出必须是JSON格式，包含code、message、data三个字段”，这样模型就不会给你一段散文。

篇幅约束要具体。“写详细一点”是无效约束，“每个部分不少于300字”才是有效约束。但也要注意，篇幅约束太死会导致模型凑字数，所以最好配合“信息密度”要求，比如“每个要点必须有具体例子或数据支撑，不要写空话”。

风格约束包括语气、人称、专业度。比如“用口语化表达，像朋友聊天”“用正式书面语，适合放在技术文档里”“结论先行，每段第一句是核心观点”。

禁止项是最容易被忽略但最有效的约束。比如“不要使用‘首先、其次、最后’这种连接词”“不要写总结段”“不要出现‘通过本文’‘综上所述’这类表达”。你禁止什么，模型就会避开什么。

3.5 迭代校准：不是重写，而是定位问题

输出不满意的时候，大多数人的做法是重新写一遍提示词。这是效率最低的方式。正确的做法是定位是哪一步出了问题。

如果输出方向不对，检查角色锚定和上下文注入。如果输出结构混乱，检查任务拆解。如果输出格式不对，检查输出约束。如果输出质量不稳定，检查是不是某一步的指令有歧义。

我常用的校准方法是增量修改：保留原来的提示词，只改一个变量，看输出变化。比如先改角色描述，看输出风格是否变化；再改上下文，看针对性是否提升。这样你能清楚地知道每个变量的影响。

还有一个技巧：让模型自己解释它的理解。在提示词最后加一句“在开始任务之前，先用一句话概括你对这个任务的理解”。如果它的理解和你的预期有偏差，你立刻就能发现，不用等它生成完再返工。

4. 完整实操流程与关键环节实现

4.1 从零搭建一个代码生成提示词

假设我们要生成一个Python函数，功能是“从Airbnb房源数据中预测房价”。这是一个典型的“AI预测Airbnb房价提示词”场景。

第一步，角色锚定。

你是一个有10年经验的机器学习工程师，擅长用Python做数据分析和预测建模，代码风格偏向scikit-learn和pandas，注释只写关键逻辑，不写废话。

第二步，上下文注入。

背景：我有一个Airbnb房源数据集，包含以下字段：房间类型、容纳人数、卧室数、床数、浴室数、最低住宿天数、评论数、评分、地理位置（经纬度）、价格。 约束：数据量约5万条，有缺失值，价格分布右偏。目标是用回归模型预测价格，要求模型可解释，不能是黑盒。 参考：之前用线性回归做过，R²只有0.45，效果不好。

第三步，任务拆解。

请按以下步骤完成：

1. 数据预处理：处理缺失值、异常值、类别特征编码。
2. 特征工程：构造新特征，比如“每卧室价格”“评论频率”等。
3. 模型选择：对比线性回归、随机森林、梯度提升树，选最优。
4. 模型评估：用交叉验证，输出R²、MAE、特征重要性。
5. 输出完整代码，包含注释和运行说明。

第四步，输出约束。

格式：Python代码块，每个步骤之间用注释分隔。 篇幅：代码不超过200行，注释不超过总行数的20%。 风格：代码符合PEP8，变量命名清晰，函数职责单一。 禁止：不要使用深度学习框架，不要写与任务无关的示例数据。

第五步，迭代校准。

在开始写代码之前，先用三句话说明你的建模思路和预期效果。

这样一套下来，模型输出的代码基本可以直接跑，而且结构清晰、注释到位。我实测过，比直接说“帮我写个预测房价的代码”质量高出一个量级。

4.2 参数选择与计算过程

在提示词工程中，有几个参数需要根据任务类型调整：

这些参数不是固定的，需要根据实际输出调整。比如代码生成时如果发现模型总是写多余的注释，可以降低温度到0.2；如果发现生成的方案太保守，可以提高温度到0.6。

4.3 实操现场记录：一次完整的提示词调试

我拿“让墨刀AI生成App原型图”这个场景做一次完整记录。

初始提示词：

帮我生成一个外卖App的原型图。

输出问题：生成了一个通用的五页面原型，没有特色，页面元素堆砌，交互逻辑不清晰。

定位问题：角色锚定缺失，上下文注入不足，任务拆解没有，输出约束没有。

修改后提示词：

你是一个有5年经验的移动端产品经理，擅长用墨刀做高保真原型，设计风格偏向简洁实用，注重交互效率。

背景：我们要做一个面向大学校园的外卖App，核心用户是学生，核心场景是“宿舍点餐，30分钟内送达”。竞品有美团和饿了么，但我们的差异点是“只服务本校食堂和周边500米内商家”。

请按以下步骤生成原型图描述：

1. 首页：展示推荐商家、搜索栏、分类入口、购物车悬浮按钮。
2. 商家详情页：菜单列表、加购按钮、评价摘要、配送时间提示。
3. 购物车页：商品列表、数量调整、备注输入、结算按钮。
4. 订单跟踪页：配送地图、骑手信息、预计送达时间、联系骑手按钮。
5. 个人中心：订单历史、地址管理、优惠券、设置。

输出格式：每个页面用Markdown表格描述，包含“区域名称、元素类型、交互说明”三列。 禁止：不要出现与校园外卖无关的功能，不要写技术实现细节。

输出结果：五个页面的结构清晰，每个页面的元素和交互都有明确说明，直接可以照着在墨刀里拖拽实现。这就是五步框架的威力。

5. 常见问题与排查技巧实录

5.1 输出质量不稳定的排查思路

输出质量忽好忽坏，通常不是模型的问题，而是提示词有歧义。排查顺序如下：

1. 检查角色锚定是否具体。“资深专家”换成“8年经验的后端工程师，擅长高并发场景”。
2. 检查上下文是否充分。模型是否知道项目背景、目标用户、约束条件。
3. 检查任务拆解是否清晰。每个子任务是否有明确的输入和输出。
4. 检查输出约束是否可执行。“写详细一点”换成“每个部分不少于300字，必须有具体例子”。
5. 检查是否有禁止项遗漏。模型是否在写你不想要的内容。

我整理了一个速查表：

5.2 三个我踩过的坑

第一个坑：角色写太多。我曾经写“你是一个既懂前端又懂后端还懂运维的全栈工程师”，结果模型输出什么都沾一点，什么都不深。后来改成“你是一个专注React前端开发的工程师”，输出质量立刻提升。

第二个坑：上下文给太多。有一次我把整个需求文档粘贴进去，三千多字，模型反而抓不住重点，输出偏离核心需求。后来改成“背景一段话+约束列表+参考素材”，效果好了很多。

第三个坑：不做迭代校准。早期我输出不满意就重写提示词，浪费了大量时间。后来学会增量修改，每次只改一个变量，效率提升至少三倍。

5.3 进阶技巧：让模型自己优化提示词

这是一个很少人用的技巧：让模型帮你改提示词。

具体做法是：把你写的提示词和不满意的输出一起发给模型，然后说“这是我的提示词和输出结果，请分析提示词中哪些地方导致了输出问题，并给出修改建议”。

模型会从它的视角指出哪些指令有歧义、哪些约束不够具体、哪些信息缺失。我试过几次，它指出的问题往往是我自己没意识到的。比如有一次它说“你的角色描述中没有指定输出语言，我默认用了英文”，我才发现忘了加“用中文输出”。

这个技巧特别适合调试复杂提示词，相当于让模型站在“被指令方”的角度给你反馈。

6. 框架的扩展与组合应用

6.1 多轮对话中的提示词管理

五步框架不仅适用于单次调用，也适用于多轮对话。在多轮场景中，每一轮都可以看作一次完整的五步循环，但角色锚定和上下文注入可以继承，只需要更新任务拆解和输出约束。

比如做“系统提示词工程和skill agent有什么区别”这个主题的研究，第一轮让模型解释概念，第二轮让模型对比差异，第三轮让模型给出应用场景。每一轮的角色和上下文不变，只改任务和约束。

这里有个技巧：在对话开始时就把角色和上下文固定下来，后续每轮只发任务和约束。这样既节省token，又保持输出风格一致。

6.2 与其他工具的配合

五步框架可以和很多工具配合使用。比如：

• 与DeepSeek-V2配合：用五步框架写规划提示词，让模型生成任务分解和优先级排序，再用生成的结果去驱动其他工具。
• 与墨刀AI配合：用五步框架生成页面结构和交互描述，直接导入墨刀生成原型图。
• 与代码编辑器配合：用五步框架生成代码片段，直接粘贴到IDE中运行和调试。

核心思路是：五步框架负责“想清楚”，其他工具负责“做出来”。你想得越清楚，工具执行得越准确。

6.3 从提示词工程到上下文工程

现在行业里在提“大模型提示词工程与上下文工程”，其实五步框架已经包含了上下文工程的雏形。上下文注入这一步，本质上就是在管理模型的“工作记忆”。

进一步的扩展是：把上下文分成静态和动态两部分。静态上下文是项目背景、角色设定、长期约束，每次调用都带上；动态上下文是当前任务的具体信息、最新数据、临时约束，每次调用时更新。

这样做的好处是，你可以建立一个“上下文模板库”，针对不同类型的任务预置不同的上下文组合，用的时候直接调用，不用每次从头写。

7. 我个人的实操体会

这套五步框架我用了大半年，最大的感受是：提示词工程不是玄学，是工程。工程意味着有方法、有步骤、可复现、可优化。你不需要天赋，只需要按步骤执行，然后根据反馈调整。

另一个体会是：不要追求一次完美。我见过很多人写提示词，改来改去不满意，最后放弃了。其实第一版能到60分就够了，然后通过迭代校准逐步提升到80分、90分。迭代的成本远低于重写的成本。

最后分享一个小技巧：建立自己的提示词库。每次调出一个好用的提示词，就把它保存下来，标注适用场景和关键参数。下次遇到类似任务，直接调用并微调，效率会越来越高。我现在有几十个常用提示词模板，覆盖代码生成、数据分析、内容创作、产品设计等场景，基本能做到“拿来即用”。

这个框架后续还可以继续扩展，比如加入“多模型对比”环节，同一个提示词分别发给不同模型，对比输出质量；或者加入“自动化校准”环节，用脚本批量测试不同参数组合，找到最优配置。这些我还在摸索中，有新的心得再分享。