1. 为什么现在必须把提示工程当成一门正经手艺来学我最早接触提示工程是在一个内部知识库问答项目上当时团队里所有人都觉得这东西没什么技术含量——不就是把问题写清楚一点吗结果第一版上线之后用户问“报销流程是什么”模型洋洋洒洒写了一堆公司差旅制度完全答非所问。后来我们花了整整两周时间把提示词从一句话扩展成包含角色设定、输出格式约束、边界条件说明的完整模板准确率才从不到四成拉到八成以上。那次经历让我彻底改变了对提示工程的看法它不是“会说话就行”而是一套需要系统设计、反复迭代、可度量可优化的工程方法。这篇文章想做的事情很明确把提示工程从“玄学调参”变成“有章可循的工程实践”。我会从最基础的概念讲起逐步深入到结构化提示设计、与Java后端框架的集成方式、函数调用机制、以及在实际项目中踩过的坑和总结出的排查技巧。无论你是刚听说提示工程这个名词的新手还是已经在项目里用过但总觉得效果不稳定的开发者都能从里面找到可以直接拿去用的东西。特别是如果你在用Spring Boot做后端开发想把自己的业务系统和AI能力结合起来那第三、四部分的内容应该会对你有直接帮助。需要提前说明的是提示工程这个领域变化非常快新的模型、新的API、新的最佳实践几乎每个月都在更新。但底层的那套思维方式——如何拆解任务、如何约束输出、如何验证效果——是相对稳定的。我会把重点放在这些不变的东西上同时给出当前阶段比较成熟的工具选型和实操方案。2. 提示工程的核心概念与设计思路拆解2.1 提示工程的本质到底是什么很多人把提示工程理解成“写提示词”这个说法不算错但太窄了。提示工程的本质是通过自然语言指令来编程大模型的行为。你写的每一段提示词其实都是在给模型下达一组约束条件你是谁、你要做什么、你不能做什么、你输出的格式是什么样、遇到不确定的情况怎么处理。这跟写代码时的函数签名、参数校验、异常处理在逻辑上是同构的。区别在于传统编程的约束是确定性的——你写if (x 0)它就一定按这个逻辑走。而提示工程的约束是概率性的——你告诉模型“只输出JSON格式”它大概率会遵守但不是百分之百。所以提示工程的核心挑战就变成了如何用概率性的手段尽可能逼近确定性的结果。这就解释了为什么同一个任务不同人写出来的提示词效果差异巨大。好的提示工程不是堆砌华丽的辞藻而是精确地消除歧义、缩小模型的输出空间、在关键节点设置校验和兜底机制。2.2 结构化提示的四个核心组件经过多个项目的迭代我总结出一个比较通用的结构化提示框架包含四个核心组件角色定义告诉模型它现在是什么身份。这个身份会直接影响它的知识调用范围和表达风格。比如“你是一个有十年经验的Java后端架构师”和“你是一个刚入门的编程学习者”面对同一个问题给出的回答深度和角度完全不同。任务描述用尽可能精确的语言说明要做什么。这里的关键是动词要具体。“分析这段代码”就不如“找出这段代码中可能导致空指针异常的位置并按严重程度排序”来得有效。输出约束规定输出的格式、长度、语言风格。可以是JSON Schema、Markdown模板、或者简单的“不超过200字”。输出约束越明确后续程序化处理的成本越低。边界条件说明什么情况下应该拒绝回答、什么情况下需要追问、什么情况下要标注不确定性。这一块最容易被忽略但在生产环境中恰恰最重要。2.3 为什么选择Spring AI作为集成方案市面上做AI应用集成的框架不少Python生态里有LangChain、LlamaIndexJava生态里Spring AI是比较成熟的选择。我选Spring AI主要基于几个考虑第一和现有技术栈的契合度。大部分国内后端团队用的是Spring BootSpring AI本身就是Spring生态的一部分依赖注入、配置管理、AOP这些机制可以直接复用学习成本低。你不需要为了接一个AI能力就把整个技术栈换掉。第二抽象层次合理。Spring AI把不同模型提供商的API抽象成了统一的接口ChatClient、EmbeddingClient、VectorStore这些核心概念在不同模型之间是通用的。这意味着你前期用某个模型做原型验证后期切换到另一个模型时业务代码基本不用改。第三Function Calling的原生支持。这是我认为Spring AI最有价值的部分。它让大模型可以调用你预先定义好的Java方法把自然语言指令转换成具体的业务操作。比如用户说“帮我查一下上个月的订单”模型可以自动调用你写好的订单查询接口把参数提取出来传进去再把结果组织成自然语言返回。当然Spring AI也不是没有缺点。它的版本迭代比较快不同版本之间API有变动文档有时候跟不上代码。另外国内模型提供商的适配程度参差不齐有些需要自己写Adapter。这些在实际操作中都需要注意。2.4 提示工程和传统开发的关系我经常被问到的一个问题是提示工程会不会取代传统开发我的判断是短期内不会但会改变开发的侧重点。传统开发的核心是逻辑实现——你把业务规则翻译成代码计算机精确执行。提示工程的核心是意图理解——你把用户的模糊需求翻译成结构化指令模型概率性地执行。两者是互补关系不是替代关系。在实际项目中比较合理的分工是确定性的业务逻辑用传统代码实现不确定性的意图理解和内容生成用提示工程实现。比如订单金额计算、库存扣减这些必须精确的操作绝对不能让模型来做但用户咨询的分类、回复话术的生成、非结构化文本的提取这些用提示工程效率会高很多。3. 核心细节解析与实操要点3.1 提示词编写的五个关键原则原则一具体优于抽象。不要写“帮我优化这段代码”要写“找出这段代码中的性能瓶颈给出具体的优化方案包括修改前后的代码对比”。模型不知道你的优化目标是什么你不说清楚它就只能猜。原则二示例优于描述。如果你希望模型按照某种特定格式输出最好的办法不是描述这个格式而是直接给一两个输入输出的示例。这叫Few-shot Learning在实际项目中效果非常明显。我做过对比测试同一个抽取任务纯描述版本的准确率大概在65%左右加上三个示例之后能到85%以上。原则三分步优于一步到位。复杂任务不要指望一个提示词解决。把它拆成多个步骤每一步的输出作为下一步的输入。比如做合同审查可以先让模型提取关键条款再让模型判断每个条款的风险等级最后让模型生成审查报告。每一步的提示词都可以单独优化和验证。原则四约束优于放任。明确告诉模型什么不能做比告诉它什么能做更重要。比如“如果问题涉及具体法律建议请回复‘建议咨询专业律师’不要自行给出法律意见”。这种边界约束在生产环境中是必须的。原则五迭代优于一次成型。提示词不是写一次就完事的。你需要建立一套评估机制用一批测试用例来量化提示词的效果然后根据bad case不断调整。我一般会维护一个至少包含50条测试用例的评估集每次修改提示词都跑一遍确保没有引入新的问题。3.2 输出格式控制的实操技巧让模型输出结构化数据是提示工程中最常见的需求之一。我试过几种方案各有优劣方案一JSON Schema约束。在提示词中直接给出JSON Schema要求模型按照这个结构输出。优点是结构清晰后续解析方便。缺点是模型有时候会“自由发挥”加一些Schema里没有的字段或者在某些字段上输出不符合类型要求的内容。方案二模板填充。给模型一个Markdown模板让它把内容填进去。这种方式对格式的控制力比JSON Schema弱一些但模型的理解成本更低不容易出错。方案三分步提取。先让模型用自然语言回答再用第二个提示词把自然语言转换成结构化数据。这种方式准确率最高但成本也最高因为要调用两次模型。在实际项目中我的选择策略是如果对格式要求非常严格比如要直接入库用方案三如果只是展示用方案二就够了方案一适合对格式有一定要求但可以容忍少量偏差的场景。3.3 Spring AI中ChatClient的配置要点Spring AI的ChatClient是核心入口配置的时候有几个容易踩坑的地方Configuration public class AiConfig { Bean public ChatClient chatClient(ChatClient.Builder builder) { return builder .defaultSystem(你是一个专业的客服助手只回答与产品相关的问题。) .defaultOptions(ChatOptions.builder() .temperature(0.3) .maxTokens(2000) .build()) .build(); } }temperature参数这个值控制输出的随机性。做信息抽取、分类这种需要稳定输出的任务时建议设在0.1到0.3之间做创意生成、文案撰写时可以调到0.7到0.9。我见过有人所有场景都用默认值0.7结果做数据抽取时模型总是“自由发挥”加了temperature0.1之后问题就解决了。maxTokens参数控制输出的最大长度。设得太小会导致回答被截断设得太大浪费资源。我的经验值是简单问答500中等复杂度任务1500长文生成3000以上。另外要注意maxTokens是输入加输出的总限制不是单独的输出限制计算的时候要把提示词的长度也算进去。defaultSystem系统提示词。这里定义的角色和约束会应用到所有通过这个ChatClient发起的请求。适合放一些全局性的规则比如“始终用中文回答”“不要编造不存在的信息”等。3.4 Function Calling的工作机制与实现Function Calling是提示工程从“聊天”走向“干活”的关键一步。它的基本原理是你在调用模型时除了传入用户消息还传入一组函数定义包括函数名、参数说明、返回值类型。模型在理解用户意图后如果判断需要调用某个函数就会返回一个函数调用请求包含函数名和参数。你的程序执行这个函数把结果再传回给模型模型根据结果生成最终回复。在Spring AI中实现Function Calling的基本步骤public class OrderQueryService implements FunctionOrderQueryRequest, OrderQueryResponse { Override public OrderQueryResponse apply(OrderQueryRequest request) { // 实际的订单查询逻辑 return orderRepository.findByUserIdAndDateRange( request.userId(), request.startDate(), request.endDate() ); } }然后在构建ChatClient时注册这个函数ChatClient chatClient builder .defaultFunctions(orderQueryService) .build();模型在收到“帮我查一下上个月的订单”这样的请求时会自动提取出userId和日期范围调用orderQueryService然后把查询结果组织成自然语言返回给用户。这里有几个实操中总结的注意事项函数的参数描述要尽可能详细模型是根据描述来判断如何提取参数的函数的返回值不要太大如果返回几百条记录模型处理起来会很慢而且容易出错最好在函数内部做聚合或分页对于可能失败的操作函数内部要做好异常处理返回明确的错误信息而不是让异常直接抛出去。4. 实操过程与核心环节实现4.1 从零搭建一个提示工程实验环境在正式开始写业务代码之前我建议先搭一个简单的实验环境用来快速验证提示词效果。这个环境不需要太复杂一个Spring Boot项目加上几个REST接口就够了。首先创建项目用Spring Initializr生成基础结构依赖选择Spring Web、Spring AI。然后在application.yml中配置模型连接信息spring: ai: dashscope: api-key: ${AI_API_KEY} chat: options: model: qwen-plus temperature: 0.3这里用环境变量来管理API Key不要直接写在配置文件里更不要提交到代码仓库。我见过不止一个项目因为把Key硬编码在代码里导致泄露的。接下来写一个最简单的测试接口RestController RequestMapping(/api/ai) public class AiTestController { private final ChatClient chatClient; public AiTestController(ChatClient chatClient) { this.chatClient chatClient; } PostMapping(/chat) public String chat(RequestBody String message) { return chatClient.prompt() .user(message) .call() .content(); } }启动项目用curl或者Postman发一个请求确认能正常收到模型回复。这一步看起来简单但经常有人卡在依赖冲突或者配置错误上。如果遇到启动报错先检查Spring AI的版本和Spring Boot的版本是否匹配这是最常见的问题来源。4.2 构建一个可复用的提示词模板系统直接在代码里拼接字符串来构造提示词在项目初期可以但很快就会变得难以维护。我的做法是建立一个提示词模板系统把提示词从代码中抽离出来用独立的文件管理。目录结构大概是这样resources/ prompts/ customer-service/ system.txt greeting.txt complaint-handling.txt >Component public class PromptTemplateManager { private final ResourceLoader resourceLoader; private final MapString, String cache new ConcurrentHashMap(); public String getPrompt(String category, String name, MapString, String variables) { String key category / name; String template cache.computeIfAbsent(key, k - { Resource resource resourceLoader.getResource(classpath:prompts/ k .txt); try { return resource.getContentAsString(StandardCharsets.UTF_8); } catch (IOException e) { throw new RuntimeException(提示词模板加载失败: k, e); } }); String result template; for (Map.EntryString, String entry : variables.entrySet()) { result result.replace({{ entry.getKey() }}, entry.getValue()); } return result; } }这样做的好处是提示词的修改不需要重新编译代码非技术人员也可以参与优化提示词可以纳入版本管理每次修改都有记录不同环境的提示词可以分开管理比如测试环境和生产环境用不同的模板。4.3 实现一个带Function Calling的智能客服这是我认为最能体现提示工程价值的场景。用户用自然语言提问系统自动判断意图调用相应的业务接口组织回复。首先定义几个核心函数Bean Description(根据用户ID查询订单列表支持按时间范围筛选) public FunctionOrderQueryRequest, ListOrderSummary orderQueryFunction() { return request - { return orderService.queryOrders( request.userId(), request.startDate(), request.endDate() ); }; } Bean Description(查询指定商品的库存和价格信息) public FunctionProductQueryRequest, ProductInfo productQueryFunction() { return request - { return productService.getProductInfo(request.productId()); }; }然后在ChatClient中注册这些函数并设置系统提示词你是一个电商平台的智能客服助手。你可以帮助用户查询订单、了解商品信息、处理售后问题。 当用户的问题涉及订单查询时调用orderQueryFunction。 当用户的问题涉及商品信息时调用productQueryFunction。 当用户的问题超出你的能力范围时礼貌地告知用户并建议联系人工客服。 回复要简洁友好不要编造不存在的信息。实际运行的时候用户说“我上周买的那个耳机还没到”模型会自动提取出时间范围上周和商品关键词耳机调用订单查询函数然后根据返回结果生成回复。整个过程用户感知不到函数调用的存在体验上就是一个能“办事”的客服。4.4 提示词效果的量化评估方法提示词改来改去怎么知道改好了还是改坏了我的做法是建立一套评估流程。第一步准备测试集。从真实业务数据中抽取至少50条有代表性的输入覆盖正常情况、边界情况、异常情况。每条数据标注期望的输出结果。第二步定义评估指标。常用的有准确率输出完全正确的比例、格式合规率输出符合格式要求的比例、平均响应时间、Token消耗量。第三步自动化跑批。写一个测试类遍历测试集调用模型对比输出和期望结果生成评估报告。Test public void evaluatePrompt() { ListTestCase testCases loadTestCases(); int correct 0; int formatValid 0; for (TestCase tc : testCases) { String output chatClient.prompt() .user(tc.getInput()) .call() .content(); if (isFormatValid(output)) formatValid; if (isCorrect(output, tc.getExpected())) correct; } System.out.printf(准确率: %.2f%%, 格式合规率: %.2f%%%n, correct * 100.0 / testCases.size(), formatValid * 100.0 / testCases.size()); }这套流程看起来简单但坚持做下来的团队不多。我的观察是凡是认真做了评估的团队提示词质量提升速度至少是不做评估团队的三倍。因为有了量化反馈你就知道每次修改到底是在进步还是在退步而不是凭感觉猜。5. 常见问题与排查技巧实录5.1 模型不按格式输出怎么办这是最高频的问题。你明明在提示词里写了“只输出JSON”模型还是给你加了一段解释文字。排查思路首先检查提示词中格式约束的位置。如果格式要求放在最后模型遵守的概率会更高因为大模型对末尾内容的注意力更强。其次检查是否有相互矛盾的指令。比如你既要求“详细解释”又要求“只输出JSON”模型就会困惑。最后考虑用Few-shot的方式给一两个正确输出的示例这比任何描述都有效。如果以上都试过了还是不行可以在程序层面加一层兜底用正则表达式从输出中提取JSON部分忽略前后的解释文字。虽然不够优雅但在生产环境中很实用。5.2 Function Calling不触发或者参数提取错误模型没有调用预期的函数通常有几个原因函数的Description写得不够清楚模型不知道什么时候该用用户输入太模糊模型无法确定参数函数参数的类型定义和实际传入的不匹配。我的经验是函数的Description要写得像给一个新同事介绍这个函数一样详细。不要只写“查询订单”要写“根据用户ID和时间范围查询订单列表返回订单号、商品名称、金额、状态等信息”。参数描述也要具体比如“userId: 用户的唯一标识通常是10位数字”。参数提取错误的话可以在提示词中加一些示例展示什么样的输入应该提取出什么样的参数。另外对于日期这种容易出错的参数建议在函数内部做格式兼容处理不要指望模型每次都输出完全正确的格式。5.3 响应速度慢和Token消耗过高这两个问题经常一起出现。主要原因通常是提示词太长、上下文太多、或者maxTokens设置过大。优化方向精简系统提示词去掉那些模型本来就知道的常识性内容对于长对话场景不要把所有历史消息都传给模型只保留最近几轮相关的用更小的模型处理简单任务只在复杂任务上调用大模型。我做过一个优化把一个客服场景的系统提示词从800字压缩到300字去掉了所有“你是一个专业的...”这类套话只保留核心约束和示例。响应时间从平均3.2秒降到1.8秒Token消耗减少了四成而准确率几乎没有变化。5.4 模型输出内容不准确或编造信息这是最危险的问题尤其是在面向用户的场景中。模型编造信息业内叫“幻觉”的根本原因是它在不确定的时候倾向于“猜一个看起来合理的答案”而不是承认自己不知道。应对策略在提示词中明确要求“如果信息不足请回复‘我需要更多信息’而不是猜测”对于关键信息要求模型标注来源或置信度在程序层面加校验比如模型输出的订单号必须在数据库中存在否则拒绝返回给用户。还有一个实用技巧在提示词中给模型一个“逃生通道”。比如“如果你不确定答案可以回复‘这个问题我需要转接人工客服’”。这样模型在不确定的时候有一个安全的退路而不是硬编一个答案。5.5 常见问题速查表问题现象可能原因排查方向解决方案输出格式不符合要求格式约束不明确或位置靠前检查提示词中格式要求的位置和表述格式要求放末尾加Few-shot示例Function Calling不触发函数描述不清晰检查函数的Description和参数说明补充详细描述加调用示例响应速度慢提示词过长或模型选择不当统计输入Token数精简提示词简单任务用小模型输出内容编造模型在不确定时猜测检查是否有“不知道”的退路加边界约束程序层校验同一输入结果不稳定temperature设置过高检查temperature参数抽取类任务设为0.1-0.3长对话后质量下降上下文超出窗口限制检查对话轮数和Token数只保留最近相关轮次5.6 几个我踩过的坑第一个坑是过度依赖系统提示词。我一开始把所有约束都放在系统提示词里结果发现模型对系统提示词的遵守程度会随着对话轮次增加而下降。后来改成在每轮用户消息中也重复关键约束效果稳定了很多。第二个坑是忽略Token计费。早期做原型的时候没注意一个提示词写了2000多字每天跑几千次月底一看账单吓了一跳。后来养成了习惯每写一个提示词都先估算Token数能用500字说清楚的就不要写到1000字。第三个坑是没有版本管理。提示词改来改去有一天发现效果变差了想回滚到之前的版本结果发现没有记录改了什么。现在我的做法是提示词文件和代码一样纳入Git管理每次修改都写清楚改了什么、为什么改、效果变化如何。第四个坑是用测试环境的提示词上生产。测试的时候用的是一批比较规范的输入效果很好。上线之后遇到各种奇怪的用户输入模型表现大打折扣。后来在测试集中专门加了一批“脏数据”——错别字、口语化表达、中英文混杂——覆盖这些情况之后线上表现才稳定下来。6. 提示工程的进阶方向与个人体会6.1 从单轮提示到多轮Agent单轮提示能解决的问题是有限的。当任务需要多步推理、需要调用多个工具、需要根据中间结果调整策略时就需要Agent架构。Agent的本质是一个循环模型思考下一步做什么执行动作观察结果再思考下一步直到任务完成。在Spring AI中实现Agent的基本思路是定义一个包含可用工具列表的系统提示词让模型在每一步输出“思考”和“行动”程序解析行动并执行把结果反馈给模型循环直到模型输出“完成”。这个模式在社区里通常叫ReActReasoning Acting。我实际用下来Agent模式适合处理那些步骤不固定、需要动态决策的任务比如复杂的数据分析、多步骤的信息收集。但对于步骤固定的任务用传统的Workflow模式预先定义好每一步会更稳定、更可控。6.2 提示工程与RAG的结合RAG检索增强生成解决的是模型知识截止和私有知识的问题。基本流程是把用户问题向量化在向量数据库中检索相关文档把检索结果作为上下文传给模型让模型基于这些上下文回答。提示工程在RAG中的关键作用是约束模型只基于检索到的内容回答。如果不加这个约束模型会混合使用检索内容和自己的训练知识导致答案不可控。我的做法是在提示词中明确写“只根据以下参考资料回答问题。如果参考资料中没有相关信息请回复‘根据现有资料无法回答该问题’。”另外检索结果的质量直接影响最终效果。我一般会在检索后加一个重排序步骤用模型对检索到的文档片段按相关性打分只把最相关的几条传给生成模型。这个步骤增加了一点延迟但准确率提升很明显。6.3 我个人在实际操作中的体会做了这么多项目我最大的体会是提示工程的上限取决于你对业务的理解深度而不是你对模型技巧的掌握程度。一个对业务了如指掌的人即使提示词写得朴素效果也往往比一个技巧娴熟但不了解业务的人好。因为提示工程的本质是把业务规则翻译成模型能理解的语言。你只有真正理解业务中的每一个判断逻辑、每一个边界情况、每一个例外场景才能写出精确的提示词。技巧只是辅助业务理解才是核心。另一个体会是不要追求一步到位要建立快速迭代的机制。提示词优化是一个持续的过程上线只是开始。你需要建立一套从用户反馈到提示词改进的闭环让系统能够持续进化。我现在的做法是每周review一次bad case从中找出共性问题针对性地优化提示词然后跑评估集验证效果。最后分享一个我觉得很实用的技巧让模型自己解释它的推理过程。在提示词中加一句“请先说明你的推理步骤再给出最终答案”不仅能提高答案的准确率还能在出错的时候帮你定位问题出在哪一步。这个技巧在调试复杂任务时特别有用。