过去大半年时间里我花了不少精力在提示词工程Prompt Engineering上。从一开始只会写“请帮我写一段代码”到后来能稳定地让大模型输出符合生产要求的接口代码、SQL 脚本和运维文档整个过程让我越来越确信提示词工程不是“玄学”也不是“会聊天就行”而是一项可以拆解、可训练、可评估的工程能力。这篇文章不是来聊感慨的而是结合我自己的项目实践把提示词工程的原理、技法、实战案例和避坑经验整理成一份系统教程。无论你是刚开始接触大模型应用开发还是已经在业务里集成 AI 能力相信都能从里面找到可以直接用的思路。1. 背景与核心概念1.1 什么是提示词工程提示词工程英文是 Prompt Engineering指的是通过设计、优化、迭代输入给大模型的指令文本让模型输出更稳定、更准确、更符合预期结果的过程。通俗一点理解大模型就像一个知识面很广但没什么“社会经验”的新同事。你问得模糊他答得含糊你给足背景、约束和示例他就能交出像样的活儿。提示词工程做的就是“把需求讲清楚”这件事只不过对话对象换成了模型。从专业定义来看提示词工程覆盖以下几个层次指令设计怎么写清楚任务目标、输出格式、约束条件。上下文编排如何在有限的上下文窗口里组织信息让模型理解背景。示例构造怎么给 Few-shot 示例帮助模型学会特定任务的套路。策略选择在什么场景下用思维链Chain of Thought、什么场景下用角色设定。结果评估如何判断提示词改得好不好如何持续迭代。1.2 提示词工程解决什么问题提示词工程的出现是因为大模型本身存在几个天然问题输出不稳定同样的输入不同时间调用结果可能差别很大。理解歧义自然语言天生模糊同一个词在不同语境下含义不同。幻觉问题模型可能编造不存在的事实、接口、API。格式不可控需要 JSON 结构输出时模型可能给你一大段解释文字。这些问题不能完全靠模型升级解决因为业务场景千差万别模型不可能内置所有任务的最优指令。提示词工程本质上是在模型能力和业务需求之间搭一座“可控的桥”。1.3 提示词工程的典型应用场景我整理了一下在项目中真实用到的场景供大家参考场景提示词核心目标典型输出代码生成生成符合项目风格的代码接口实现、工具函数代码解释快速理解陌生代码函数说明、调用关系单元测试生成边界用例pytest / JUnit 测试代码SQL 生成把自然语言转为 SQLSELECT / INSERT / UPDATE 语句文档生成从代码/日志生成文档README、接口文档、周报数据清洗从非结构化文本提取字段JSON 结构数据日志分析从报错日志定位根因原因分析、修复建议自动化脚本生成运维/部署脚本Shell、Python 脚本这些场景有一个共同特点任务规则明确、但表达维度多。如果提示词写得好输出质量会直线上升如果提示词随便写往往要反复重试好多次才能得到可用的结果。2. 提示词的核心原理要写好转义提示词不能只背模板。先理解大模型处理文本的基本机制再设计提示词效率会高很多。2.1 Token 与大模型的工作方式大模型并不像人一样逐字阅读文字它会把文本切分成 Token 再处理。Token 是模型处理文本的基本单位。1 个 Token 可能是一个完整的英文单词也可能是半个中文词语具体取决于模型的分词器Tokenizer。例如下面这行英文Hello, world!大概会被切成 3 个 TokenHello、,、world!。中文的分词粒度更细通常 1 个汉字到 1 个词会占用 1 到 2 个 Token。这对提示词工程的意义在于提示词越长消耗的 Token 越多成本越高上下文窗口有限提示词占用太多空间留给模型思考输出的空间就少设计提示词时要兼顾信息密度写清楚但不冗余。2.2 系统提示词与用户提示词在绝大多数大模型 API 中消息由角色Role区分。最常见的是三种system系统提示词定义模型的角色、行为边界、整体风格。user用户消息用户提交的具体任务。assistant助手消息模型的回复内容多轮对话中会把历史回复作为上下文。给一个直观的例子from openai import OpenAI client OpenAI() response client.chat.completions.create( modelgpt-4o, messages[ {role: system, content: 你是一名资深的Python后端工程师擅长代码审查回答要简洁专业。}, {role: user, content: 请帮我审查下面这段代码指出潜在问题...}, ], temperature0.3, ) print(response.choices[0].message.content)这里系统提示词的作用是“全局约束”。它不需要把任务说明写得很细而是告诉模型“你是谁”“应该用什么状态回答问题”。用户消息则负责承载具体任务。2.3 上下文窗口对提示词设计的影响上下文窗口指模型一次能接收的最大 Token 数量。不同模型差别很大有的几十万有的只有几千。虽然窗口越来越大但提示词设计仍然要考虑以下问题中间遗忘模型对上下文不同位置的关注度不一样通常开头和结尾的信息更容易被记住。信息冗余把大量无关信息塞进上下文会稀释有效指令的权重。成本问题每轮调用都要把上下文重新传给模型越长成本越高。基于这些限制推荐的做法是把最重要的指令放在 system 消息或用户消息开头。把最关键的限制条件放在末尾再次强调。避免把全网资料、整份日志无脑塞进上下文。3. 常用提示词技巧拆解这一节给出六个高频技巧。每个技巧我都按“用途 - 示例 - 关键点 - 坑位”四个角度展开。3.1 角色设定用途让模型以特定身份、专业水平、表达风格回答适合需要稳定输出风格的场景。示例你是一名有十年经验的数据库管理员DBA。 当我提供SQL语句时请从索引使用、锁竞争、事务隔离级别三个维度进行分析并使用Markdown表格输出分析结果。关键点角色描述越具体输出越稳定。加“十年经验”这类限定有助于稳定输出深度。角色设定后要紧接着说明任务边界。坑位角色设定不能替代任务指令。只写“你是数据库专家”不写具体要做什么模型依然不知道回答什么。3.2 思维链Chain of Thought用途让模型先思考再回答适合数学推理、逻辑分析、代码调试等复杂任务。示例请分析下面这段代码为什么会出现空指针异常并给出修复方案。 请先逐步分析执行流程列出可能为 null 的变量再给出最终结论。关键点显式要求模型“分步骤思考”能显著提升推理类任务准确率。适合对比方案、排查问题、数学计算等任务。输出时如果不需要思考过程可以要求“最终只给出结论和步骤清单”。坑位在简单任务上用思维链会浪费 Token还会让输出啰嗦。区分任务复杂度再决定是否使用。3.3 Few-shot 示例少样本提示用途通过 1 到 3 个输入-输出示例让模型模仿指定格式完成任务。示例请将用户反馈分类为“功能缺陷”“体验问题”“新需求”“其他”。 示例1 输入下载文件时总是提示网络错误 输出功能缺陷 示例2 输入希望增加深色模式 输出新需求 示例3 输入按钮位置有点奇怪不容易找到 输出体验问题 现在请分类 输入登录后跳转页面空白 输出关键点示例要覆盖典型情况和边界情况。示例数量 2~3 个即可太多会占用上下文。示例格式必须和期望输出格式严格一致。坑位示例之间如果格式不一致模型会“学坏”。比如示例输出里一会儿用 Markdown一会儿用纯文本实际输出就会不稳定。3.4 结构化输出约束用途让模型输出 JSON、XML、Markdown 表格等结构化内容方便程序直接解析。示例请提取以下简历中的候选人信息并以JSON格式返回JSON字段包括name姓名、years_of_experience工作年限整数、skills技能列表字符串数组。 不要输出任何解释文字。 简历内容 张三5年后端开发经验熟悉Java、Spring Boot、MySQL、Redis有高并发系统设计经验。预期输出{ name: 张三, years_of_experience: 5, skills: [Java, Spring Boot, MySQL, Redis] }关键点指定字段名、字段类型甚至枚举值。显式声明“不要输出解释文字”或“只输出 JSON”。复杂结构可以给一个 JSON Schema 或示例模板。坑位如果模型经常输出 Markdown 代码块包裹的 JSON即json ... 要么在提示词里禁止要么在程序里做兼容处理。生产环境建议写一个提取 JSON 的正则兜底。3.5 分隔符与格式控制用途把指令和用户输入明确区分防止提示词注入。示例下面的一条用户评论用 comment 标签包围请判断该评论的情感倾向正面/负面/中性并给出理由。 comment 商家发货速度很快但包装破损了客服处理倒是挺及时。 /comment关键点使用XML标签、、---等分隔符让模型区分“指令”和“待处理数据”。分隔符要和指令语义无关避免歧义。如果处理的是用户输入必须把输入当作数据而不是让模型执行其中的指令。坑位这是提示词注入防范的基础手段但不是全部。如果应用面向不可信用户输入还需要配合内容过滤和权限控制。3.6 迭代式追问用途先获取大致结果再逐步修正适合需求本身不够明确的场景。示例第一轮帮我写一个 Python 函数解析 nginx 访问日志。 第二轮太宽泛了请只提取访问时间、状态码、请求路径三个字段并返回 Pandas DataFrame。 第三轮再增加一个参数 threshold用于过滤状态码为 4xx 和 5xx 的请求。关键点每轮只增加一个明确约束。对比每轮输出找到最影响质量的调整点。这种交互式迭代在 Codex CLI、ChatGPT 等对话工具中效率很高。4. 实战案例用提示词工程完成一个代码任务这一节我把前面讲的技巧串起来做一个完整的实战。场景是使用 Codex CLI 这类命令行 AI 编程工具通过提示词工程完成一个“日志解析 统计”的小工具开发。4.1 环境准备Codex CLI 是 OpenAI 推出的命令行 AI 编程工具可以在终端中直接输入自然语言任务由 AI 生成代码、执行命令并返回结果。不同版本安装方式有所差异请以官方文档为准。我本地的环境大致如下操作系统macOS / Linux 运行时Node.js 18 命令行工具Codex CLI 语言环境Python 3.10使用前需要准备能够访问 Codex CLI 的工具环境API 密钥或对应平台登录凭证一个干净的测试目录方便让 AI 生成代码文件。如果还没有安装 Codex CLI可以在终端中运行安装命令然后通过codex命令进入交互模式。# 进入交互式命令行 codex进入后终端会变成类似对话窗口的样子可以输入自然语言任务。4.2 第一轮提示词明确任务目标先输入一个基础版本的需求请帮我创建一个Python脚本 parse_log.py功能是读取nginx访问日志文件统计每个请求路径的访问次数并按照访问次数降序输出前10条。日志格式如下 127.0.0.1 - - [10/Oct/2024:13:55:36 0000] GET /api/user HTTP/1.1 200 2326仔细观察这轮提示词我做了三件事指定输出文件名parse_log.py描述功能目标读日志、统计路径、输出前10给了一条日志样例消除日志格式歧义。这是提示词工程里非常关键的一步先让模型理解输入格式再让它干活。如果不给样例模型可能会猜测不同字段的位置写出各种不兼容的正则或 split 逻辑。4.3 第二轮提示词补充约束条件AI 生成的代码往往能跑但不够健壮。需要继续补充约束再优化一下这个脚本增加以下能力 1. 使用正则从日志行中提取请求路径不依赖空格简单切分 2. 对不匹配的行直接跳过不要报错 3. 通过命令行参数接收日志文件路径使用argparse实现 4. 输出结果时同时显示访问次数和路径格式如下 12 /api/user/list这一轮本质上是在“逐轮细化需求”。每增加一条约束模型的输出都会更接近生产代码。我在实际写提示词时通常会先给 70% 清晰度的需求让模型产生初稿再通过第二、第三轮补充限制而不是一开始就写一段几百字的复杂提示词。因为一次性给太多约束模型反而容易遗漏重点。4.4 验证与反思拿到模型生成的代码后不要直接放进业务项目里。先做这几件事在测试目录里创建一份样例日志运行脚本检查输出格式故意放一条格式错误的日志确认不会崩溃查看正则逻辑是否覆盖异常情况。示例测试命令python parse_log.py access.log如果结果符合预期再把脚本纳入项目如果不符合就继续调整提示词把“失败点”明确告诉模型。这个循环过程就是最朴素的提示词工程迭代。4.5 案例小结这个实战看起来简单但它体现了提示词工程在 AI 编程工具中的核心价值需求描述得越具体代码质量越高一次写不清可以多轮迭代AI 生成的代码必须人工验证不能盲目信任提示词不是写一次就完事而是要随着任务深入持续优化。5. 提示词评估与迭代方法提示词工程走到后面最大的问题不是“写不出来”而是“不知道当前版本好不好、下一步往哪改”。这时候需要引入评估机制。5.1 建立评估集建议准备 10 到 20 条固定测试用例覆盖典型场景大多数用户会遇到的输入边界场景空值、超长文本、特殊字符异常场景无效输入、诱导性输入、格式错误。每次修改提示词后用同一批用例跑一遍对比输出差异。5.2 评估维度维度说明示例指标准确率输出内容是否正确分类是否正确、提取字段是否准确格式合规是否严格遵循输出格式JSON 能否被解析稳定性多次调用结果是否一致同一输入输出差异程度信息密度是否有冗余内容是否包含多余解释安全性是否被注入或生成违规内容是否输出敏感内容5.3 迭代策略一次只改一个变量不要同时换 model、改 temperature、又重写提示词。改完之后无法判断哪一步起作用了。记录版本把提示词版本、模型版本、输出结果、评估分数记录到表格或文档里。用失败用例驱动迭代收集线上失败的输入加入评估集再有针对性地调整提示词。如果项目使用 Codex CLI 或类似 AI 编程工具也可以在连续交互中观察模型行为变化把其中有价值的提示词固定成模板沉淀为团队资产。6. 常见问题与排查思路在提示词工程的实践中我遇到过不少问题。下面整理成表格方便大家快速排查。问题现象常见原因解决思路输出格式不稳定JSON 偶尔带解释提示词约束不够强明确要求“只输出JSON”加示例程序侧做兼容解析回答内容空洞、套话多缺少示例和具体要求增加 Few-shot 示例指定输出结构和长度模型编造不存在的 API 或函数知识截止时间与训练数据限制提示词里要求“只基于指定文档回答”必要时提供文档片段作为上下文复杂推理任务答错未使用思维链提示词中显式要求“分步骤思考”或使用思维链策略提示词注入导致异常行为用户输入未被隔离用分隔符隔离数据对用户输入进行安全过滤多次调整提示词后效果反而变差缺少评估集盲目修改回到评估集逐条对比定位失效原因上下文被大量无关内容占满一次性放入过多资料精简上下文只保留与任务直接相关的信息排查提示词问题时推荐按以下步骤走先固定模型版本和参数排除变量干扰用最小化复现用例测试把问题缩小到某一段提示词从“任务目标 - 约束条件 - 示例格式”三个维度逐一检查修改后跑评估集确认没有引入新问题。7. 最佳实践与工程化建议提示词工程做到后面已经不是“写提示词”的问题而是“如何让提示词在团队和业务里高效落地”的工程问题。这部分是我个人收获最大的内容。7.1 把提示词当作代码管理不要只在聊天界面里写提示词复制粘贴完就忘了。到后期提示词的改动会直接影响线上输出质量建议把提示词存为模板文件纳入 Git 仓库文件和变更记录都要有版本备注线上使用的提示词版本要和评估记录一一对应。7.2 分层设计提示词我习惯把每一轮任务的提示词拆成三个层次全局系统层定义模型角色、通用安全边界、输出风格。任务指令层具体任务描述、约束条件、输出格式。数据内容层待处理的原文、日志、代码等输入数据。这样拆的好处是每层可以独立修改而不影响其他部分。比如换一个项目场景只需要替换“任务指令层”不需要动全局系统层。7.3 使用模板管理重复任务如果业务里经常做同一类任务例如“生成周报”“提取简历信息”“审查代码”可以把提示词抽象成模板只暴露少数变量。prompt_template 你是{role}。 请根据以下要求处理输入内容 要求{requirements} 输入内容 data {input_data} /data 输出格式{output_format} 这样既保证了输出一致性也降低了普通使用者写提示词的难度。7.4 控制成本与延迟提示词工程不只是质量问题也是成本问题长时间、长上下文对话会显著增加 Token 消耗每次迭代调用都会产生费用批量评估前先估算成本对线上高并发场景尽量精简提示词长度减少冗余内容。7.5 设置安全边界在面向外部用户的应用中提示词工程必须考虑安全问题对用户输入做长度限制、敏感词过滤使用分隔符隔离指令和数据重要操作删库、改配置、发消息必须由人工确认不能完全交给模型。这一点在 AI 编程工具上尤其重要。模型生成代码可以但执行命令时需要明确授权生产环境变更必须经过测试和审批流程。7.6 让失败驱动成长我最后想分享一个心态层面的建议提示词工程是一个“越做越有感觉”的领域。前期你可能觉得效果不稳定像抽盲盒一样。但当你开始记录版本、建立评估集、一次只改一个变量之后模型输出会越来越可控。真正让你进步的不是某一次“惊艳”的输出而是每一次“翻车”之后的复盘和调整。8. 总结与下一步方向提示词工程不是一句“帮我写个程序”那么简单它是一个贯穿需求分析、指令设计、结果评估、安全治理的完整过程。到现在为止每当我在 Codex CLI 或者各类大模型 API 里写提示词都会下意识地按这套思路走先想清楚任务目标和输入数据格式再设计角色、约束、示例和输出格式用最小用例验证再用评估集回归把稳定有效的提示词沉淀为模板和资产。如果你刚开始接触提示词工程我建议从两件事入手。第一找一个小任务比如用提示词生成一个 Python 工具函数反复修改提示词直到输出完全符合预期。第二准备一份自己的评估记录表把不同版本提示词的表现记录下来。提示词工程最迷人的地方在于它把“模糊的表达”变成“精确的指令”这个过程本身就会不断加深你对任务和模型的理解。希望这篇文章能给你一些可复用的思路也欢迎在实践后回来交流你踩过的坑。