Prompt Engineering 在企业大模型应用中的实践：从提示词模板到可控输出

1. 文章背景：为什么这个主题重要

在大模型应用开发中，Prompt Engineering 是最容易被低估、也最容易被误解的部分。

很多人认为提示词只是"把问题问清楚一点"，或者在系统提示词里写几句"你是一个专业助手"。这种方式做 Demo 可能够用，但一旦进入企业级场景，问题就会集中暴露：

同一个问题，不同时间回答不一致；
输出格式不稳定，后端系统无法解析；
知识库问答中，模型明明没有依据却编造答案；
Agent 调用工具时参数错误；
客服、运维、法务、财务等场景对语气、边界、引用来源要求不同；
大模型回答过长、过短、跑题或者不符合业务规范；
提示词散落在代码里，难以版本管理和评估。

因此，企业级 Prompt Engineering 不是简单"写提示词"，而是围绕大模型输入输出设计一套可维护、可评估、可复用、可控的工程体系。

对于大模型应用开发者来说，Prompt 的价值主要体现在三个方面：

降低模型输出的不确定性；
把业务规则转化为模型可理解的约束；
让大模型输出能够被系统消费，而不是只给人阅读。

尤其在 RAG、Agent、结构化输出、自动化办公、智能客服、知识库问答等场景中，Prompt 设计质量会直接影响系统稳定性。

一个企业级大模型应用，往往不是"模型越强越好"，而是"模型能力 + Prompt 约束 + 检索证据 + 工具调用 + 输出校验"共同决定最终效果。

2. 核心问题：实际开发中会遇到什么问题

2.1 Prompt 写得太口语化，无法复用

很多开发者一开始会这样写 Prompt：

text 复制代码

请你根据下面的资料回答用户问题，回答要准确一点，不要乱说。

这种提示词看起来没问题，但在生产环境中约束太弱。

它没有明确：

模型应该扮演什么角色；
能不能使用外部知识；
找不到答案时怎么处理；
输出格式是什么；
是否需要引用来源；
回答长度如何控制；
是否允许推测；
高风险问题如何拒答。

企业级 Prompt 必须从"口头指令"升级为"结构化任务规范"。

2.2 输出格式不稳定，后端无法解析

在企业应用中，大模型输出经常不是直接展示给用户，而是要被后端系统继续处理。例如：

抽取合同字段；
生成工单分类结果；
判断用户意图；
生成 SQL 查询条件；
输出 Agent 工具调用参数；
返回 JSON 结构给前端渲染。

如果 Prompt 只写"请输出 JSON"，模型可能会输出：

text 复制代码

下面是 JSON：
{
  "intent": "query_policy"
}

或者输出多余解释、Markdown 包裹、字段缺失、类型错误。这会导致后端解析失败。

因此，可控输出是 Prompt Engineering 的核心目标之一。

2.3 RAG 场景中容易出现"有资料也幻觉"

很多人以为 RAG 加了知识库，模型就不会幻觉。实际上，RAG 只能提供参考资料，不能自动保证模型严格基于资料回答。

常见问题包括：

检索资料不相关，模型仍然强行回答；
资料中没有答案，模型根据常识补充；
多个资料冲突，模型自行融合；
模型引用了资料，但结论不是资料中的原意；
输出没有来源，用户无法追溯。

所以 RAG 场景中的 Prompt 必须明确限制模型行为：只能根据参考资料回答，证据不足时拒答，关键结论需要引用来源。

2.4 Agent 场景中 Prompt 更容易失控

Agent 不只是回答问题，还可能调用工具、查询数据库、发送邮件、创建工单、执行自动化流程。这类场景对 Prompt 要求更高。

如果 Prompt 没有明确边界，Agent 可能出现：

工具选择错误；
参数构造错误；
未经确认执行高风险操作；
多步任务中丢失目标；
把用户意图理解错；
工具返回失败后继续编造结果。

因此，Agent Prompt 不仅要描述任务，还要描述工具使用规则、失败处理策略、权限边界和确认机制。

3. 基础概念：用工程视角解释关键概念

3.1 Prompt 不只是提示词，而是模型输入协议

在工程视角下，Prompt 可以理解为大模型和业务系统之间的"输入协议"。它不仅告诉模型"回答什么"，还规定了：

模型角色；
任务目标；
输入数据结构；
可用上下文；
业务约束；
输出格式；
异常处理；
安全边界。

一个好的 Prompt 应该像接口文档一样清晰，而不是像聊天一样随意。

3.2 System Prompt 和 User Prompt 的分工

在常见大模型接口中，Prompt 通常分为 system、user、assistant 等角色。

类型	作用	示例
System Prompt	定义角色、边界、全局规则	你是企业知识库问答助手
User Prompt	承载用户问题和业务输入	用户问：报销流程是什么
Few-shot 示例	给出输入输出样例	示例问题和标准答案
Tool Prompt	描述工具能力和调用规则	可调用 search_policy 查询制度

System Prompt 应该放稳定规则，User Prompt 放动态内容。不要把所有内容都堆在一个字符串里，否则后续维护非常困难。

3.3 Prompt 模板化

企业应用中，Prompt 不应该散落在代码中，而应该模板化管理。

一个 Prompt 模板通常包含：

模板名称；
适用场景；
版本号；
变量列表；
输入说明；
输出格式；
示例；
评估集。

例如：

text 复制代码

模板名称：rag_qa_v1
适用场景：知识库问答
输入变量：
- question：用户问题
- contexts：检索到的参考资料
- user_role：用户角色
输出要求：
- answer：答案
- citations：引用来源
- confidence：置信度

模板化后，Prompt 才能进行版本管理、灰度发布和效果对比。

3.4 可控输出

可控输出是指让模型按照指定格式稳定输出结果。常见格式包括：

JSON；
Markdown 表格；
固定字段文本；
XML；
YAML；
函数调用参数；
枚举标签。

在企业系统中，JSON 是最常见的结构化输出格式。

例如意图识别任务可以要求模型输出：

json 复制代码

{
  "intent": "policy_query",
  "confidence": 0.86,
  "need_retrieval": true,
  "keywords": ["报销", "发票", "流程"]
}

这比一段自然语言更适合后端系统处理。

4. 系统设计：如何搭建完整流程或架构

企业级 Prompt Engineering 不应该是孤立模块，而应该嵌入整个大模型应用链路。

一个典型架构可以拆成以下几层：

层级	作用
输入处理层	用户问题清洗、意图识别、敏感信息过滤
上下文构造层	检索知识库、读取工具结果、拼装上下文
Prompt 模板层	根据场景选择不同 Prompt 模板
模型调用层	调用 LLM，控制温度、最大长度、超时
输出解析层	JSON 解析、字段校验、格式修复
安全校验层	幻觉检测、权限校验、风险拦截
评估监控层	记录输入输出、人工反馈、指标统计

4.1 知识库问答场景

知识库问答的 Prompt 重点是"基于证据回答"。

推荐流程：

text 复制代码

用户问题
  ↓
问题改写 / 意图识别
  ↓
检索知识库
  ↓
Rerank 证据排序
  ↓
构造 RAG Prompt
  ↓
LLM 生成答案
  ↓
答案引用来源
  ↓
证据一致性检查
  ↓
返回用户

在这个场景中，Prompt 必须约束模型不要脱离参考资料。

4.2 Agent 场景

Agent 场景的 Prompt 重点是"正确规划和安全执行"。

推荐流程：

text 复制代码

用户任务
  ↓
任务理解
  ↓
判断是否需要工具
  ↓
选择工具
  ↓
构造工具参数
  ↓
执行工具
  ↓
读取工具结果
  ↓
生成最终回复

Agent Prompt 需要明确：

什么时候调用工具；
每个工具能做什么；
不能调用不存在的工具；
工具失败时如何处理；
高风险操作是否需要用户确认；
最终回答必须基于工具返回结果。

4.3 结构化抽取场景

结构化抽取的 Prompt 重点是"字段完整、类型正确、可解析"。

例如从合同中抽取字段：

json 复制代码

{
  "contract_name": "",
  "party_a": "",
  "party_b": "",
  "amount": "",
  "start_date": "",
  "end_date": "",
  "risk_clauses": []
}

这里需要特别强调：

不确定的字段填 null；
不要编造；
金额、日期保持原文格式；
输出必须是合法 JSON；
不要输出额外解释。

5. 关键实现：核心模块、技术选型和实现细节

5.1 一个通用 RAG Prompt 模板

下面是一个适合知识库问答的 Prompt 模板：

text 复制代码

你是企业知识库问答助手。请严格根据【参考资料】回答用户问题。

规则：
1. 只能使用参考资料中的信息回答；
2. 如果参考资料不足以回答，请回答"当前资料不足，无法确定"；
3. 不要编造制度、流程、数字、日期或负责人；
4. 如果不同资料存在冲突，请明确指出冲突；
5. 关键结论后标注来源编号；
6. 回答要简洁、准确，适合业务人员理解。

【用户问题】
{question}

【参考资料】
{contexts}

【输出格式】
结论：
依据：
注意事项：
来源：

这个模板的关键不是语言多漂亮，而是边界清楚：

只基于资料；
不足则拒答；
不编造；
标注来源；
输出结构固定。

5.2 一个结构化输出 Prompt 模板

对于后端需要解析的任务，建议使用 JSON Schema 约束：

text 复制代码

你是一个文本分类与信息抽取助手。请根据用户输入输出 JSON。

要求：
1. 只输出 JSON，不要输出任何解释；
2. JSON 必须可以被 Python json.loads 解析；
3. 不确定的字段使用 null；
4. intent 只能从以下枚举中选择：
   - policy_query
   - faq_query
   - complaint
   - workflow_request
   - unknown

【用户输入】
{user_input}

【输出 JSON 格式】
{
  "intent": "",
  "confidence": 0.0,
  "need_retrieval": false,
  "keywords": [],
  "reason": ""
}

在代码中，可以进一步做解析和校验：

python 复制代码

import json
from typing import Any, Dict

def parse_llm_json(output: str) -> Dict[str, Any]:
    try:
        data = json.loads(output)
    except json.JSONDecodeError:
        raise ValueError("模型输出不是合法 JSON")

    required_fields = ["intent", "confidence", "need_retrieval", "keywords", "reason"]
    for field in required_fields:
        if field not in data:
            raise ValueError(f"缺少字段: {field}")

    allowed_intents = {
        "policy_query",
        "faq_query",
        "complaint",
        "workflow_request",
        "unknown"
    }
    if data["intent"] not in allowed_intents:
        raise ValueError("intent 不在允许范围内")

    return data

Prompt 约束和代码校验必须同时存在。不要只相信模型会按格式输出。

5.3 Few-shot 示例的使用

Few-shot 适合用于以下场景：

输出格式复杂；
任务边界模糊；
业务语气要求高；
模型经常误判；
需要统一风格。

例如客服回复场景：

text 复制代码

示例1：
用户问题：我提交报销后多久能到账？
标准回复：一般情况下，报销单审批通过后会进入财务付款流程，具体到账时间以公司财务制度和银行处理时间为准。你可以在报销系统中查看当前审批状态。

示例2：
用户问题：没有发票可以报销吗？
标准回复：根据公司报销要求，费用报销通常需要提供合规发票。如遇特殊情况，建议补充说明并联系财务确认。

Few-shot 的作用是给模型建立输出风格和边界。但示例不要太多，否则会占用上下文，也可能让模型过度模仿错误细节。

5.4 Prompt 版本管理

企业项目中，Prompt 应该像代码一样管理版本。

建议记录：

字段	说明
prompt_id	模板唯一标识
version	版本号
scene	适用场景
owner	负责人
variables	输入变量
template	模板内容
created_at	创建时间
changelog	修改说明
eval_score	评估结果

例如：

json 复制代码

{
  "prompt_id": "rag_qa",
  "version": "v1.3",
  "scene": "knowledge_base_qa",
  "owner": "llm_team",
  "changelog": "增加资料不足时拒答规则",
  "eval_score": {
    "faithfulness": 0.91,
    "format_valid_rate": 0.98
  }
}

Prompt 版本管理的价值在于：当系统效果变差时，可以追溯到底是模型变了、检索变了，还是 Prompt 变了。

5.5 参数控制

Prompt 之外，模型参数也会影响输出稳定性。

参数	建议
temperature	结构化任务建议低一些，例如 0 到 0.3
top_p	需要稳定输出时不宜过高
max_tokens	防止输出过长或截断
stop	用于控制结束符
seed	如果模型支持，可用于稳定测试

一般来说：

分类、抽取、JSON 输出：temperature 低；
创意写作、营销文案：temperature 可适当高；
RAG 问答：temperature 不宜太高；
Agent 工具调用：temperature 尽量低。

6. 常见问题：实际落地中的坑和解决方案

6.1 只靠 Prompt 控制格式，容易失败

问题表现：

模型输出 Markdown 包裹 JSON；
字段缺失；
数值类型变成字符串；
输出多余解释；
JSON 末尾多逗号。

解决方案：

使用明确 JSON Schema；
Prompt 中强调"只输出 JSON"；
代码侧做 json.loads 校验；
失败后进行一次格式修复；
高要求场景使用模型原生结构化输出能力或函数调用。

6.2 Prompt 越写越长，效果反而变差

有些团队遇到问题就往 Prompt 里加规则，最后 Prompt 变成几千字，模型反而更不稳定。

原因是：

规则之间可能冲突；
模型注意不到关键规则；
上下文成本增加；
维护困难；
不同任务混在一个 Prompt 中。

解决方案：

按场景拆 Prompt；
把通用规则和业务规则分层；
删除无效规则；
用评估集验证每次修改；
不要把所有问题都交给一个万能 Prompt。

6.3 RAG Prompt 没有拒答机制

问题表现：

检索不到资料时仍然回答；
资料不完整时模型自行补充；
回答中出现知识库没有的内容。

解决方案：

在 Prompt 中明确"资料不足必须拒答"；
检索层设置最低相关性阈值；
Rerank 分数过低时不进入生成；
输出中增加"依据"字段；
对答案进行证据一致性检查。

6.4 Agent Prompt 没有安全边界

问题表现：

用户一句话让 Agent 直接执行高风险操作；
模型调用了错误工具；
工具参数缺失；
工具失败后模型编造成功结果。

解决方案：

工具调用前做意图确认；
高风险操作必须二次确认；
工具参数使用 Schema 校验；
工具失败必须如实反馈；
Prompt 中明确禁止编造工具结果。

6.5 Prompt 无评估，靠感觉优化

问题表现：

修改 Prompt 后不知道效果是否变好；
解决了一个问题，引入另一个问题；
不同开发者各自维护不同版本；
线上问题难以复现。

解决方案：

建立 Prompt 测试集；
每次修改跑回归测试；
记录版本和评估指标；
对线上失败案例做归因；
建立人工标注和反馈闭环。

7. 效果评估：如何判断系统是否有效

Prompt Engineering 必须可评估，否则就是玄学调参。

7.1 结构化输出评估

结构化输出可以关注：

指标	含义
JSON 合法率	输出能否被解析
字段完整率	必填字段是否存在
类型正确率	字段类型是否符合要求
枚举合法率	分类结果是否在枚举范围内
业务准确率	分类或抽取是否正确

例如，意图识别任务可以构建 200 条测试问题，人工标注意图，然后计算准确率。

7.2 RAG 问答评估

RAG Prompt 评估可以关注：

指标	含义
忠实性	答案是否基于参考资料
正确性	答案是否回答了问题
完整性	是否覆盖关键点
可追溯性	是否提供来源
拒答准确率	无资料时是否拒答
简洁性	是否没有无关内容

对于企业场景，忠实性和可追溯性通常比语言流畅度更重要。

7.3 Agent 评估

Agent Prompt 评估要关注过程，而不只是最终回答。

指标	含义
工具选择准确率	是否选择正确工具
参数正确率	工具参数是否完整准确
任务完成率	是否完成用户目标
安全拦截率	高风险操作是否确认
失败处理率	工具失败是否正确反馈
多轮稳定性	多轮任务是否保持目标一致

Agent 的评估要记录每一步决策，否则很难定位问题。

7.4 Prompt A/B 测试

如果系统有一定流量，可以对不同 Prompt 版本做 A/B 测试。

例如：

v1：原始 RAG Prompt；
v2：增加拒答规则；
v3：增加引用来源；
v4：增加输出结构。

对比指标可以包括：

用户满意率；
转人工率；
点击来源率；
回答被采纳率；
投诉率；
格式错误率。

8. 工程优化：性能、成本、稳定性和可维护性

8.1 性能优化

Prompt 越长，推理越慢，成本越高。尤其在 RAG 和 Agent 场景中，上下文可能非常长。

优化建议：

删除无效规则；
对参考资料做压缩；
控制 Few-shot 数量；
对不同场景使用不同 Prompt；
避免把历史对话无限拼接；
对高频问题缓存答案。

8.2 成本优化

Prompt Engineering 也会影响成本。

成本主要来自：

输入 token；
输出 token；
多轮 Agent 调用；
格式修复重试；
RAG 检索上下文过长；
使用大模型处理简单任务。

优化建议：

简单分类用小模型；
复杂推理用大模型；
结构化抽取尽量短输出；
RAG 只放最相关证据；
对失败重试设置上限；
对 Prompt 做版本压缩。

8.3 稳定性优化

企业系统要考虑异常情况：

模型输出格式错误；
模型超时；
模型拒绝回答；
工具调用失败；
Prompt 变量为空；
检索上下文为空。

应对策略：

输出解析失败时自动修复一次；
超时后降级到简短回答；
检索为空时直接拒答；
变量为空时不调用模型；
Agent 工具失败时中断流程；
记录完整日志用于排查。

8.4 可维护性优化

Prompt 可维护性非常重要。建议做到：

Prompt 模板集中管理；
每个模板有负责人；
每次修改有 changelog；
重要 Prompt 有评估集；
支持灰度发布和回滚；
日志中记录 prompt_id 和 version；
将业务规则尽量结构化，不要全部写进自然语言。

一个不可维护的 Prompt 系统，后期会变成"谁也不敢改"的黑盒。

9. 实践建议：给开发者的落地建议

9.1 不要迷信万能 Prompt

企业应用中，不同场景应该使用不同 Prompt：

场景	Prompt 重点
知识库问答	基于证据、引用来源、拒答
意图识别	枚举分类、置信度、关键词
信息抽取	JSON 格式、字段完整、不要编造
Agent	工具选择、参数构造、安全边界
客服回复	语气、简洁、合规
报告生成	结构完整、逻辑清晰、来源可追溯

不要试图写一个 Prompt 解决所有问题。

9.2 Prompt 要和业务规则结合

很多业务规则不应该只靠 Prompt 表达。例如：

用户权限；
金额阈值；
审批流程；
高风险操作；
数据脱敏；
合规限制。

这些最好放在代码、规则引擎或权限系统中处理。Prompt 负责语言和推理，不应该承担所有安全责任。

9.3 Prompt 输出要面向系统消费

如果输出要给前端展示，可以用 Markdown；如果输出要给后端处理，应该用 JSON；如果输出要触发工具调用，应该严格符合工具参数 Schema。

设计 Prompt 时要先问清楚：

输出给谁看？
是否需要机器解析？
是否需要引用来源？
是否需要后续动作？
是否允许不确定？
错误输出会造成什么后果？

9.4 Prompt 修改必须有评估

每次修改 Prompt，都应该至少回答三个问题：

这次修改想解决什么问题？
有没有测试集验证？
有没有引入新的副作用？

不要只凭单个样例调 Prompt。Prompt 优化必须从"样例驱动"走向"评估驱动"。

9.5 高风险场景要减少自由生成

在金融、法务、医疗、安全运维、电池安全、生产控制等场景中，不建议让模型自由发挥。

更稳妥的方式是：

检索证据；
结构化判断；
规则校验；
模板化输出；
高风险人工确认；
全链路日志记录。

大模型可以提升效率，但不能替代所有安全控制。

10. 总结：提炼核心观点

Prompt Engineering 在企业大模型应用中不是简单"写提示词"，而是一套面向可控输出、业务约束和系统稳定性的工程方法。

一个成熟的 Prompt 工程体系，至少应该包含：

场景化 Prompt 模板；
清晰的角色和任务定义；
明确的输入变量；
严格的输出格式；
RAG 证据约束；
Agent 工具调用规则；
JSON Schema 或字段校验；
Prompt 版本管理；
评估集和回归测试；
日志监控和持续优化。

从工程实践来看，Prompt 的价值不是让模型"更会聊天"，而是让模型更稳定、更可控、更适合接入业务系统。

对于开发者来说，最重要的不是背很多提示词技巧，而是建立工程化思维：

能模板化，就不要手写散乱 Prompt；
能结构化输出，就不要只输出自然语言；
能用规则约束，就不要完全依赖模型自觉；
能评估，就不要凭感觉优化；
能拒答，就不要让模型强行回答；
能引用来源，就不要让答案无法追溯。

真正可落地的大模型应用，往往不是某一个 Prompt 写得多华丽，而是整套系统把 Prompt、检索、工具、规则、校验和评估结合起来，让模型输出稳定服务业务目标。

Prompt Engineering 的最终目标不是"提示词好看"，而是让大模型在企业场景中做到：可控、可信、可复用、可维护。