刚开始接触 AI 应用开发时我对 Prompt 的理解很简单。说白了不就是给大模型写一句提示吗比如“你是一个客服助手请回答用户问题”或者“请帮我总结下面这段内容”。看起来更像写文案不像写代码。但这段时间看了一些 AI 应用实践也自己试着用 Spring Boot 接入大模型 API 后我慢慢发现Prompt 这东西没有想象中那么“随便”。如果只是自己平时用 AI 聊天Prompt 写得随意一点问题不大。但如果要把大模型能力放进一个真实业务系统里Prompt 就会开始影响接口返回、用户体验、系统稳定性甚至影响业务结果。所以我现在对这个问题的理解是Prompt 不完全等同于传统代码但在 AI 应用里它确实承担了一部分“代码”的职责。为什么一开始觉得 Prompt 不像代码做 Java 后端这几年代码在我心里一直是比较明确的东西。比如 Controller 接参数Service 写业务逻辑Mapper 查数据库Redis 做缓存MQ 做异步处理。每一段代码都有比较清晰的输入和输出。代码写错了编译可能过不了逻辑写错了测试能测出来接口返回不对日志里也能查。但 Prompt 不一样。它是一段自然语言。你写一句话大模型返回一段内容。看起来不像代码那样严谨也没有固定的语法检查。很多时候改几个字模型输出就可能发生变化。比如你写请帮我总结下面这段内容。和写请用三句话总结下面这段内容要求简洁不要添加原文没有的信息。这两个 Prompt 的结果就可能差不少。如果只是自己用这种差异无所谓。但如果是在业务系统里比如客服回答、合同摘要、知识库问答、数据分析解释那差异就变得重要了。因为用户看到的最终结果很可能就是 Prompt 影响出来的。Prompt 在 AI 应用里像什么从后端角度看我觉得 Prompt 有点像几种东西的混合。它像配置。比如不同业务场景使用不同 Prompt。客服助手是一套文档总结是一套代码解释是一套运营文案生成又是一套。这些内容不太适合全部写死在代码里后面大概率需要配置化管理。它也像模板。很多 Prompt 不是固定一句话而是由系统规则、用户输入、知识库内容、历史对话一起拼出来的。比如你是一个企业知识库助手。 请只根据下面提供的资料回答用户问题。 如果资料里没有答案请直接说明暂时无法确认。 资料内容 {context} 用户问题 {question}这里的{context}和{question}就像模板变量后端需要在调用模型前动态填充。它还像业务规则。比如要求模型不能编造、不能回答某些范围外的问题、必须返回 JSON、必须按固定格式输出。这些其实都是规则只不过不是用 Java 的 if else 写出来而是通过自然语言告诉模型。所以 Prompt 不是传统意义上的代码但它确实在控制系统行为。为什么不能把 Prompt 随便写在代码里第一版 Demo 里很多人可能会直接这样写String prompt 你是一个专业助手请回答用户问题 question;这样写当然能跑但如果后面场景多起来就会很难维护。比如产品说客服助手回答要更温和一点。运营说生成文案时不要太夸张。测试说知识库问答不能回答资料外的问题。安全同事说敏感问题要拒答。这时候如果 Prompt 全散落在 Java 代码里就会出现几个问题不知道哪个接口用了哪个 Prompt改一句话还要重新发版线上效果变差后不好回滚很难对比不同版本的效果测试时不知道具体测的是哪一版 Prompt这和我们以前把业务参数写死在代码里是一样的。刚开始方便后面就麻烦。所以我觉得稍微正式一点的 AI 应用Prompt 至少应该被当成一种可管理的资源。可以先简单一点放到配置文件里。再往后可以存到数据库里带上场景、版本、状态、创建人、更新时间等字段。比如设计一张表prompt_template - id - scene_code - template_content - version - status - create_time - update_time这样后端调用模型前先根据场景读取对应 Prompt 模板再填充用户问题、知识库内容等变量。这就更接近工程化了。Prompt 也需要测试传统接口上线前我们一般会测正常情况、异常情况、边界情况。Prompt 其实也需要类似的测试。比如一个知识库问答 Prompt我们至少要测资料里有答案时能不能回答准确资料里没有答案时会不会乱编用户问范围外问题时能不能拒绝用户故意诱导时会不会绕过限制输出格式是否稳定多轮对话时是否还能保持上下文这些测试不一定都能做到完全自动化但至少要有一批固定测试问题。每次修改 Prompt 后都拿这些问题跑一遍看回答有没有明显变差。这个过程有点像回归测试只不过测试对象从 Java 代码变成了 Prompt 和模型输出。我以前觉得 Prompt 调优可能就是凭感觉改现在发现真要用在系统里还是要尽量留下记录。哪一版 Prompt 改了什么为什么改效果有没有提升都应该能查到。否则线上出问题时只能靠回忆很难定位。Prompt 和后端代码怎么配合在一个 Spring Boot 项目里我觉得 Prompt 不应该孤立存在。它需要和后端代码配合。比如用户发起一个问题后端可能要做这些事校验用户输入是否合法根据用户身份判断知识库权限从数据库或向量库里检索相关内容读取对应场景的 Prompt 模板把问题、上下文、业务数据填充进去调用大模型接口解析模型返回结果记录日志和调用耗时返回给前端这里面 Prompt 只是其中一环但它会直接影响模型回答。后端代码负责确定性的部分比如权限、数据、接口、日志、异常处理。Prompt 负责指导模型怎么基于这些信息生成回答。所以做 AI 应用时不是把业务逻辑都丢给 Prompt也不是完全不信 Prompt。更合理的方式是确定性的事情交给代码不确定的表达和生成交给模型。比如订单是否存在应该由后端查数据库决定订单状态是什么应该以后端数据为准至于怎么用自然语言告诉用户可以交给模型组织。这样边界会清楚很多。我的理解如果非要回答“Prompt 到底算不算代码”我现在会这么说Prompt 不是传统代码因为它没有明确的语法、编译过程和稳定输出。但在 AI 应用里Prompt 应该被当成工程资产来管理。它会影响系统行为也会影响用户看到的结果所以不能只当成一句临时文案。对 Java 后端来说学习 Prompt 不只是学习怎么把话说得更清楚更重要的是学习怎么把 Prompt 放进后端系统里管理。比如Prompt 模板化Prompt 配置化Prompt 版本管理Prompt 测试用例Prompt 调用日志Prompt 效果评估Prompt 和业务数据的边界划分这些东西看起来不像传统 CRUD但背后的思路还是工程化。最后做 AI 应用时Prompt 可能不会像 Java 代码那样被编译也不会像 SQL 那样有明确的执行结果但它确实在影响系统输出。如果只是个人试用可以随便写。但如果要进入业务系统就应该认真对待。我现在越来越觉得AI 应用开发的难点不只是“怎么调用大模型”而是怎么把模型、Prompt、业务数据、后端接口这些东西组合成一个稳定的服务。下一篇我准备从后端视角继续聊从接口开发角度理解大模型一次请求背后到底发生了什么。