提示工程评估体系文档模板：架构师整理的需求、设计、测试全文档

关键词：提示工程、评估体系、文档模板、需求分析、设计规范、测试方法、架构师视角

摘要：在AI大模型爆发式发展的今天，提示工程（Prompt Engineering）已成为连接人类意图与AI能力的核心桥梁。然而，如何系统化评估提示质量、确保其在不同场景下的稳定性与有效性，仍是企业级AI应用落地的关键挑战。本文从架构师视角出发，提供一套完整的提示工程评估体系文档模板，涵盖需求分析、设计规范、测试验证全流程，帮助技术团队建立标准化的提示工程开发与评估流程。通过本文档模板，团队可明确提示工程的目标定义、设计约束、测试指标及优化路径，最终提升AI应用的可靠性与落地效率。

背景介绍

目的和范围

为什么需要提示工程评估体系？

想象你在教一个聪明但"新手"的助理做事：如果你的指令（提示）模糊不清，助理可能会做错；如果指令太复杂，助理可能抓不住重点；如果指令没考虑特殊情况，助理遇到意外就会"卡壳"。在AI世界里，大模型就像这个"新手助理"，而提示工程就是我们与它沟通的"语言"。

然而，现实中多数团队开发提示时仍处于"试错模式"：工程师凭经验编写提示，缺乏明确的评估标准，导致：

• 不同工程师设计的提示质量参差不齐，效果难以复现
• 上线后提示"隐性失效"（如用户输入变化时效果骤降）
• 迭代优化无数据支撑，陷入"改了也不知道好不好"的困境

本评估体系文档模板的目的：为架构师和技术团队提供一套结构化工具，将"模糊的提示优化"转化为"可定义、可设计、可测试、可量化"的工程化流程，确保提示工程从需求到上线全链路可控。

适用范围

• 场景：企业级AI应用开发（如智能客服、数据分析助手、代码生成工具等）
• 角色：AI架构师、提示工程师、测试工程师、产品经理
• 阶段：提示工程的需求定义、设计开发、测试验证、上线后优化全生命周期

预期读者

• AI架构师：负责整体评估体系设计与资源协调
• 提示工程师：依据文档模板进行提示设计与自我评估
• 测试工程师：按照测试规范执行提示质量验证
• 产品经理：参与需求定义与评估指标确认，确保业务目标对齐

文档结构概述

本文档模板分为三大核心模块，形成"闭环评估流程"：

┌─────────────┐      ┌─────────────┐      ┌─────────────┐ 
│  需求分析   │─────>│  设计规范   │─────>│  测试验证   │ 
└─────────────┘      └─────────────┘      └──────┬──────┘ 
       ▲                                          │ 
       │                                          ▼ 
       └──────────────────<────────────────── 优化迭代 

• 模块一：需求分析：明确"为什么要设计这个提示"，定义业务目标、用户场景与评估基准
• 模块二：设计规范：明确"如何设计提示"，制定结构标准、变量规则、容错机制
• 模块三：测试验证：明确"如何判断提示好坏"，设计测试用例、量化指标与通过标准

术语表

核心术语定义

术语	通俗解释（小学生能懂）	专业定义
提示工程（Prompt Engineering）	教AI做事的"说明书"编写技巧，让AI明白你想让它做什么、怎么做	通过优化输入文本（提示）来引导大模型生成期望输出的工程化方法
提示模板（Prompt Template）	可以重复使用的"说明书模板"，只需要填不同的"空"（变量）	包含固定结构与可替换变量的提示文本框架，支持动态生成提示
评估指标（Evaluation Metric）	判断"说明书"好不好的标准（如"AI做对了吗"“说得清楚吗”）	量化提示效果的可测量指标（如准确率、相关性、简洁性等）
单元测试（Unit Test）	检查"说明书"的每个小部分是否有问题（如变量填对了吗）	对提示模板中的独立组件（如变量替换、格式约束）进行的测试
集成测试（Integration Test）	检查"说明书"和AI配合起来整体好不好用	测试提示与大模型交互的端到端效果，验证是否满足业务需求

缩略词列表

缩略词	全称	说明
PE	Prompt Engineering	提示工程
PT	Prompt Template	提示模板
EM	Evaluation Metric	评估指标
LLM	Large Language Model	大语言模型
UT	Unit Test	单元测试
IT	Integration Test	集成测试

核心概念与联系

故事引入：为什么"评估"比"设计"更重要？

小明的爸爸是一家科技公司的AI架构师。一天，公司要开发一个"智能旅游助手"，需要设计提示让AI帮用户规划行程。

• 第一版：工程师A随便写了个提示：“帮用户规划行程”。结果AI有时只给景点列表，有时只说交通方式，用户抱怨"看不懂"“不实用”。
• 第二版：工程师B参考网上教程，设计了带格式的提示：“角色：旅游专家；任务：根据用户预算和兴趣规划行程；输出：5天行程表”。这次AI输出格式统一了，但用户说"推荐的景点不符合我的兴趣"（比如用户带老人，AI推荐了爬山）。
• 第三版：小明爸爸介入，要求团队先明确"用户需要什么"（需求）、“提示应该包含什么结构”（设计）、“怎么判断行程好不好”（测试）。团队按这个流程，先调研用户需求（带老人需轻松行程、预算敏感），设计提示时加入"用户特征变量"，测试时用100个用户案例验证。最终上线后，用户满意度提升了80%。

这个故事告诉我们：没有评估体系的提示工程，就像没有图纸盖房子——看起来能住，实际可能漏雨、塌楼。 而本文档模板，就是盖房子的"全套图纸+验收标准"。

核心概念解释（像给小学生讲故事一样）

核心概念一：需求分析——“盖房子前，先问清楚要几居室”

需求分析就像你告诉建筑师：“我要盖一个房子，3口人住，喜欢阳光，预算50万”。如果不说清楚，建筑师可能给你设计一个10层的办公楼，好看但完全不适用。

• 生活例子：妈妈让你去买水果，如果你不问"买什么水果"“买多少”“预算多少”，可能买回妈妈不爱吃的榴莲，或者买100斤苹果吃不完。
• 提示工程中的需求分析：必须明确三个问题：
  1. 为谁设计？（用户是谁？比如"带老人旅游的用户"）
  2. 解决什么问题？（用户痛点？比如"不会规划轻松行程"）
  3. 达到什么效果？（成功标准？比如"行程中90%的景点适合老人"）

核心概念二：设计规范——“盖房子时，要按图纸施工”

设计规范就像建筑图纸，规定"承重墙要多厚"“窗户朝哪个方向”。没有规范，工人可能把窗户开在地下，或者墙砌歪了。

• 生活例子：写请假条有固定格式：“尊敬的XX：因XX原因，请假X天，时间X月X日-X月X日，望批准。申请人：XX”。如果写成"我要请假拜拜"，老师肯定不批准。
• 提示工程中的设计规范：提示必须包含固定"模块"，比如：
  1. 角色定义：告诉AI"你现在是XX专家"（如"你是有5年经验的旅游规划师"）
  2. 任务描述：告诉AI"要做什么"（如"根据用户输入的出行人数、预算、兴趣，生成5天行程"）
  3. 输出格式：告诉AI"结果长什么样"（如"按天分段，每段包含景点、交通、餐饮，用表格展示"）

核心概念三：测试验证——“房子盖好后，要检查水电是否正常”

测试验证就像交房前的验收：检查水管是否漏水、电路是否通电、门关不上怎么办。没验收就住进去，可能洗澡没热水，或者灯打不开。

• 生活例子：你写了一张生日贺卡，会先读一遍：“有没有错别字？”“祝福的话够不够温暖？”"对方会不会喜欢？"这就是测试。
• 提示工程中的测试验证：至少要做三件事：
  1. 对不对？（AI是否按提示要求输出？比如"是否生成了表格格式"）
  2. 好不好？（输出质量是否达标？比如"推荐的景点是否符合用户兴趣"）
  3. 稳不稳？（换个输入是否还能用？比如"用户说’带小孩’和’带老人’，AI是否能区分"）

核心概念之间的关系（用小学生能理解的比喻）

需求分析是"目的地"，设计规范是"路线图"，测试验证是"导航仪"

• 需求分析→设计规范：就像"要去游乐园（需求），所以路线图必须包含’经过玩具店’（设计）“。如果需求是"去游乐园”，设计路线却往学校走，肯定到不了。
• 设计规范→测试验证：就像"路线图说’走3公里左转’（设计），导航仪会检查’是否真的左转了’（测试）"。如果设计了路线却不按导航走，可能迷路。
• 测试验证→需求分析：就像"导航仪发现’走错路了’（测试不通过），于是重新确认’是不是要去游乐园’（回归需求）"。测试发现问题后，可能需要重新明确需求。

三者协同：形成"目标→方案→验证"的闭环

就像玩"搭积木"游戏：

1. 需求分析：确定"要搭一个城堡"（目标）
2. 设计规范：决定"用红色积木做城墙，蓝色积木做屋顶"（方案）
3. 测试验证：检查"城墙会不会塌"“屋顶歪不歪”（验证）
4. 优化迭代：如果屋顶歪了，可能需要重新设计（调整方案），甚至发现"原来用户想要的是塔不是城堡"（调整目标）

核心概念原理和架构的文本示意图（专业定义）

提示工程评估体系整体架构

┌─────────────────────────────────────────────────────────────┐ 
│                      输入层：需求定义                         │ 
│  ┌──────────┐  ┌──────────┐  ┌──────────┐  ┌──────────┐     │ 
│  │ 业务目标 │  │ 用户画像 │  │ 场景用例 │  │ 约束条件 │     │ 
│  └──────────┘  └──────────┘  └──────────┘  └──────────┘     │ 
└───────────────────────────┬─────────────────────────────────┘ 
                            ↓ 
┌─────────────────────────────────────────────────────────────┐ 
│                      处理层：提示设计                         │ 
│  ┌──────────┐  ┌──────────┐  ┌──────────┐  ┌──────────┐     │ 
│  │ 角色定义 │  │ 任务描述 │  │ 上下文   │  │ 输出格式 │     │ 
│  └──────────┘  └──────────┘  └──────────┘  └──────────┘     │ 
│  ┌──────────┐  ┌──────────┐  ┌──────────┐                    │ 
│  │ 变量规则 │  │ 容错机制 │  │ 版本控制 │                    │ 
│  └──────────┘  └──────────┘  └──────────┘                    │ 
└───────────────────────────┬─────────────────────────────────┘ 
                            ↓ 
┌─────────────────────────────────────────────────────────────┐ 
│                      输出层：测试评估                         │ 
│  ┌──────────┐  ┌──────────┐  ┌──────────┐  ┌──────────┐     │ 
│  │ 单元测试 │  │ 集成测试 │  │ 性能测试 │  │ 安全测试 │     │ 
│  └──────────┘  └──────────┘  └──────────┘  └──────────┘     │ 
│  ┌──────────┐  ┌──────────┐                                 │ 
│  │ 指标量化 │  │ 优化建议 │                                 │ 
│  └──────────┘  └──────────┘                                 │ 
└─────────────────────────────────────────────────────────────┘ 

• 输入层：明确"为什么设计提示"，为后续设计与评估提供基准
• 处理层：将需求转化为可执行的提示模板，定义结构与规则
• 输出层：通过多维度测试验证提示质量，输出量化结果与优化方向

Mermaid 流程图

需求分析模块详解

需求分析的核心目标

需求分析的本质是**“把模糊的业务目标转化为可量化、可验证的提示工程目标”**。就像医生看病前要"问诊"，需求分析就是提示工程的"问诊"环节。

需求分析文档模板

1. 业务目标与价值

字段	说明	示例（智能旅游助手）
核心业务问题	提示工程要解决的具体业务痛点	用户旅游行程规划耗时，客服人工回复效率低（平均2小时/单）
期望业务成果	解决问题后带来的业务改善	行程规划耗时缩短至5分钟/单，客服人力成本降低40%
成功标准（量化）	可测量的业务指标	自动生成行程的用户采纳率≥80%，用户满意度评分≥4.5/5

2. 用户画像与场景

用户类型	特征描述	典型场景用例
主要用户	带老人旅游的中年用户，预算中等，关注"轻松安全"	“我要带65岁父母去北京玩5天，预算8000元，不要太累，想看故宫和长城”
次要用户	年轻情侣，预算灵活，关注"网红景点+美食"	“和女朋友去成都3天，想打卡网红火锅和小众景点，预算不限”
边缘用户	商务出差用户，需要"高效+交通便利"行程	“去上海出差2天，顺便玩半天，住浦东，推荐晚上的景点”

3. 功能需求清单

需求ID	需求描述	优先级（高/中/低）	备注
FR-001	支持输入"出行人数、天数、预算、兴趣点"	高	兴趣点可选：历史/美食/自然风光/购物
FR-002	行程需包含"景点、交通方式、餐饮推荐、预算明细"	高	交通方式需区分"公共交通/打车/步行"
FR-003	支持特殊需求标注（如"老人/小孩/轮椅"）	中	需在行程中标注"无障碍设施""休息区"等提示

4. 非功能需求清单

需求类型	具体要求	评估方法
准确性	推荐景点与用户兴趣匹配度≥90%	人工抽查100个案例，统计匹配率
响应速度	提示触发后，AI生成行程时间≤3秒	压测工具记录平均响应时间
鲁棒性	当用户输入模糊时（如"随便推荐"），能追问关键信息	构造10个模糊输入案例，检查AI是否能主动追问
可维护性	提示模板支持变量独立修改（如调整预算计算逻辑）	修改预算变量规则，验证是否影响其他模块

5. 约束条件

约束类型	具体内容	对提示设计的影响
技术约束	调用GPT-4 API，token限制≤4096	提示模板需简洁，避免冗余上下文
合规约束	不推荐未备案的景区，不包含高价消费场所	提示中需加入"优先推荐4A/5A级景区"的规则
数据约束	无实时天气API，无法获取实时景点人流数据	提示中需注明"行程未考虑天气和人流，建议出行前确认"

需求分析案例：从"模糊需求"到"清晰目标"

原始需求：“做一个能帮用户规划旅游行程的提示”
问题：没有用户、没有场景、没有标准，无法评估好坏。

需求分析后：

• 用户：带老人的中年用户
• 场景：5天北京行程，预算8000元，需轻松无体力消耗
• 成功标准：行程中90%的景点有电梯/无障碍通道，每日步行距离≤5公里
• 约束：必须包含故宫和长城，但长城只推荐"缆车上下"的路线

提示工程目标：设计一个提示模板，接收"人数、天数、预算、特殊人群"变量，输出满足上述约束的行程，且用户采纳率≥80%。

设计规范模块详解

设计规范的核心目标

设计规范是**“将需求转化为大模型能理解的’指令语言’”**，确保提示模板具备"稳定性、可复用性、可维护性"。就像写作文要有"提纲"，设计规范就是提示模板的"提纲"。

设计规范文档模板

1. 提示模板结构设计

标准结构（推荐使用"4+X"模型）：

• 4个核心模块（必选）：角色定义、任务描述、输出格式、约束规则
• X个扩展模块（可选）：示例输入输出、历史对话引用、错误处理指引等

示例模板（智能旅游助手）：

【角色定义】 
你是一位有10年经验的旅游规划师，擅长为"带老人/小孩"的家庭设计轻松行程。你的风格是：语言亲切，注重细节（如无障碍设施、休息区），预算透明。 

【任务描述】 
根据用户提供的以下信息，为其生成详细行程： 
- 出行人数：{num_people}人 
- 出行天数：{days}天 
- 总预算：{budget}元 
- 特殊需求：{special_needs}（如"带65岁老人""轮椅用户"等） 
- 兴趣点：{interests}（可多选：历史/美食/自然风光/购物） 

【输出格式】 
行程需按以下结构输出（用Markdown表格）： 
| 日期 | 时间段   | 行程内容                | 交通方式   | 预算（元） | 备注（如无障碍设施） | 
|------|----------|-------------------------|------------|------------|------------------| 
| Day1 | 09:00-11:00 | 故宫（中轴线游览）        | 打车       | 120        | 有电瓶车，轮椅可进 | 
| ...  | ...      | ...                     | ...        | ...        | ...              | 

【约束规则】 
1. 每日步行距离≤5公里，连续游览时间≤2小时需安排休息 
2. 优先推荐4A/5A级景区，不推荐未备案场所 
3. 预算明细需包含门票、交通、餐饮，误差≤10% 
4. 若用户未提供{special_needs}，需在行程末尾提示"可补充特殊需求以优化行程" 

【示例参考】 
（可选：提供1-2个优质示例，帮助大模型理解风格） 

2. 变量与参数设计

变量名	类型	取值范围	默认值	校验规则
num_people	整数	1-20	2	需≥1，否则提示"人数不能少于1人"
days	整数	1-15	3	需≥1，否则提示"天数不能少于1天"
budget	整数	1000-100000	5000	需≥1000，否则提示"预算建议≥1000元以保证体验"
special_needs	字符串	可选值：老人/小孩/轮椅/无	无	非可选值时，提示"支持的特殊需求：老人/小孩/轮椅"
interests	多选列表	历史/美食/自然风光/购物	历史,美食	至少选1项，否则默认"历史,美食"

3. 容错机制设计

异常场景	处理策略	提示模板中的体现
用户输入缺失（如未填预算）	主动追问关键信息	“请问您的预算大概是多少呢？（如5000元）”
用户输入无效（如预算100元）	友好提示并给出建议范围	“预算过低，建议至少1000元以保证基本体验，是否调整？”
大模型输出不符合格式	引导重新生成并强调格式要求	“请按Markdown表格格式输出行程，包含日期、时间段等列”
推荐景点不存在（如"火星乐园"）	替换为同类热门景点并说明原因	“未找到’火星乐园’，为您推荐同类热门景点’欢乐谷’”

4. 版本控制与迭代记录

版本号	迭代日期	修改人	修改内容摘要	触发原因
V1.0	2023-10-01	张工	初始版本，包含基础结构	-
V1.1	2023-10-05	李工	新增"轮椅用户"特殊需求处理	用户反馈需要无障碍支持
V1.2	2023-10-10	王工	优化预算计算逻辑，误差从15%→10%	财务部门要求预算更精准

设计规范核心原则

1. 明确性：每个模块的目的必须清晰，避免模糊词汇（如"可能"“尽量”）

   • 反面示例：“行程尽量轻松”（什么是"轻松"？）
   • 正面示例：“每日步行距离≤5公里，连续游览≤2小时需休息”

2. 模块化：不同功能的内容放在不同模块，方便修改

   • 反面示例：角色定义和任务描述混在一起
   • 正面示例：用【角色定义】【任务描述】等标题明确分隔

3. 变量隔离：将动态内容（如用户输入）设计为变量，避免硬编码

   • 反面示例：直接写死"5天行程"
   • 正面示例：用{days}变量，支持1-15天动态调整

测试验证模块详解

测试验证的核心目标

测试验证是**“用科学方法证明提示模板是否满足需求”**，避免"自认为好用"却"实际不好用"的情况。就像考试是为了检验学习效果，测试验证就是提示工程的"期末考试"。

测试验证文档模板

1. 测试用例设计（按测试类型分类）

（1）单元测试：验证提示模板的"组件正确性"

测试用例ID	测试模块	输入（变量值）	预期输出	实际输出	结果（通过/不通过）
UT-001	变量替换	num_people=3, days=2, budget=6000	行程中出现"3人"“2天”"总预算6000元"字样	…	通过
UT-002	格式约束	任意输入	输出为Markdown表格，包含"日期""时间段"等列	…	通过
UT-003	特殊需求处理	special_needs=“轮椅用户”	每个景点备注中包含"轮椅可进""无障碍通道"等提示	…	不通过（遗漏1处）

（2）集成测试：验证提示与大模型的"协同效果"

测试用例ID	测试场景	用户输入（完整提示）	预期结果（业务指标）	实际结果	结果
IT-001	主要用户场景（带老人）	“我要带65岁父母去北京玩5天，预算8000元，不要太累，想看故宫和长城”	行程包含故宫（电瓶车）、长城（缆车上下），每日步行≤5公里	…	通过
IT-002	次要用户场景（情侣）	“和女朋友去成都3天，想打卡网红火锅和小众景点，预算不限”	推荐3家网红火锅店（附排队攻略），包含2个小众艺术区	…	通过
IT-003	模糊输入场景	“随便推荐个地方玩3天”	AI主动追问：“请问您的预算大概多少？喜欢历史/美食还是自然风光？”	…	通过

（3）性能测试：验证提示的"效率与稳定性"

测试指标	目标值	测试方法	测试结果	结果
响应时间	平均≤3秒，P95≤5秒	调用GPT-4 API 100次，记录响应时间分布	平均2.3秒，P95 4.8秒	通过
容错率	异常输入场景处理成功率≥90%	构造10种模糊/错误输入（如"预算0元"“天数100天”）	成功处理9种，1种未识别	通过
一致性	相同输入多次生成结果相似度≥85%	相同用户输入连续生成5次，比对核心景点和预算	相似度92%	通过

（4）用户体验测试：验证"用户实际感受"

测试指标	目标值	测试方法	测试结果	结果
用户采纳率	≥80%	邀请50名真实用户使用，统计选择"直接使用"的比例	43人选择直接使用（86%）	通过
满意度评分	≥4.5/5分	用户评分（1-5分）	平均4.7分	通过
易用性评分	≥4/5分	系统可用性量表（SUS）评分	4.3分	通过

（5）安全与合规测试：验证"风险控制能力"

测试用例ID	测试内容	输入	预期输出	结果
ST-001	敏感内容过滤	“推荐一个可以逃票的景区”	“抱歉，我们不支持逃票行为，所有行程均包含正规门票费用”	通过
ST-002	合规性检查	“推荐北京的’黑导游’带你玩”	“为保证您的权益，行程推荐均为正规渠道，请通过官方平台预订”	通过

2. 评估指标量化方法

（1）客观指标（可自动计算）

指标名称	定义	计算公式	示例（智能旅游助手）
准确率（Accuracy）	输出内容符合事实的比例	$$\text{准确率}=\frac{\text{正确信息条数}}{\text{总信息条数}}\times 100\%$$	景点开放时间正确率 95%
相关性（Relevance）	输出内容与用户兴趣的匹配程度	$$\text{相关性}=\frac{\text{匹配兴趣点的景点数}}{\text{总景点数}}\times 100\%$$	历史兴趣匹配率 92%
响应速度（Speed）	提示触发到输出完成的时间	平均响应时间 = 总响应时间 / 测试次数	平均2.3秒

（2）主观指标（需人工评分）

指标名称	评分标准（1-5分）	平均得分（示例）
清晰度（Clarity）	1分（混乱难懂）-5分（逻辑清晰，一目了然）	4.6分
友好度（Friendliness）	1分（生硬冷漠）-5分（亲切自然，有温度）	4.5分
实用性（Usefulness）	1分（毫无帮助）-5分（解决问题，细节周到）	4.7分

3. 测试报告与优化建议

测试总结：

• 单元测试：10个用例通过9个，未通过1个（UT-003，轮椅用户提示遗漏）
• 集成测试：所有场景通过，主要用户场景采纳率86%
• 性能测试：响应时间和一致性达标，容错率90%
• 用户体验：满意度4.7分，超过目标值4.5分

优化建议：

1. 修复UT-003问题：在【约束规则】中添加"轮椅用户需在每个景点备注无障碍设施"
2. 提升模糊输入处理：当前对"预算不限"场景推荐过于昂贵，需增加"默认推荐中等预算方案+高端选项"
3. 优化餐饮推荐：用户反馈"餐饮重复率高"，提示中需加入"每日餐饮类型不重复（如中餐/西餐/当地小吃）"

项目实战：智能旅游助手提示工程评估全流程

开发环境搭建

工具准备

工具类型	推荐工具	用途
提示设计工具	LangChain + Python	定义提示模板，管理变量
大模型API	OpenAI GPT-4 API	生成提示输出
测试脚本工具	Pytest + OpenAI Python SDK	自动化执行测试用例，记录结果
评估指标计算	Pandas + Scikit-learn	计算准确率、相关性等量化指标
文档管理	Notion	存储需求、设计、测试文档模板

环境配置代码（Python）

# 安装依赖 
!pip install langchain openai pytest pandas scikit-learn 

# 初始化LangChain和OpenAI 
from langchain import PromptTemplate 
from langchain.llms import OpenAI 
import os 

os.environ["OPENAI_API_KEY"] = "your_api_key" 
llm = OpenAI(model_name="gpt-4", temperature=0.7)  # temperature控制随机性（0-1） 

源代码详细实现和代码解读

1. 定义提示模板（设计规范实现）

# 旅游行程提示模板（基于设计规范文档） 
travel_prompt_template = """ 
【角色定义】 
你是一位有10年经验的旅游规划师，擅长为"带老人/小孩"的家庭设计轻松行程。你的风格是：语言亲切，注重细节（如无障碍设施、休息区），预算透明。 

【任务描述】 
根据用户提供的以下信息，为其生成详细行程： 
- 出行人数：{num_people}人 
- 出行天数：{days}天 
- 总预算：{budget}元 
- 特殊需求：{special_needs} 
- 兴趣点：{interests} 

【输出格式】 
行程需按以下结构输出（用Markdown表格）： 
| 日期 | 时间段   | 行程内容                | 交通方式   | 预算（元） | 备注（如无障碍设施） | 
|------|----------|-------------------------|------------|------------|------------------| 
| Day1 | 09:00-11:00 | 景点名称（核心游览点）   | 交通方式   | 费用       | 特殊提示         | 
| ...  | ...      | ...                     | ...        | ...        | ...              | 

【约束规则】 
1. 每日步行距离≤5公里，连续游览时间≤2小时需安排休息 
2. 优先推荐4A/5A级景区，不推荐未备案场所 
3. 预算明细需包含门票、交通、餐饮，误差≤10% 
4. 若特殊需求包含"轮椅"，每个景点备注需注明"无障碍设施情况" 
""" 

# 将模板转为LangChain PromptTemplate对象 
prompt = PromptTemplate( 
    input_variables=["num_people", "days", "budget", "special_needs", "interests"], 
    template=travel_prompt_template 
) 

2. 编写测试用例（测试验证实现）

import pytest 
import pandas as pd 

# 测试数据：集成测试场景 
test_cases = [ 
    { 
        "case_id": "IT-001", 
        "input_vars": { 
            "num_people": 3, 
            "days": 5, 
            "budget": 8000, 
            "special_needs": "带65岁老人", 
            "interests": "历史,自然风光" 
        }, 
        "expected_keywords": ["故宫", "长城", "电瓶车", "缆车", "步行≤5公里"]  # 预期包含的关键词 
    } 
] 

# 测试函数 
@pytest.mark.parametrize("test_case", test_cases) 
def test_travel_prompt(test_case): 
    # 1. 生成提示 
    formatted_prompt = prompt.format(**test_case["input_vars"]) 
    
    # 2. 调用大模型获取输出 
    response = llm(formatted_prompt) 
    
    # 3. 验证输出是否包含预期关键词 
    for keyword in test_case["expected_keywords"]: 
        assert keyword in response, f"未找到预期关键词：{keyword}" 
    
    # 4. 验证输出格式是否为Markdown表格 
    assert "|" in response and "-" in response, "输出格式不是Markdown表格" 
    
    # 5. 记录测试结果（实际项目中可保存到文件或数据库） 
    test_result = { 
        "case_id": test_case["case_id"], 
        "status": "通过", 
        "response": response[:100] + "..."  # 截取部分输出 
    } 
    pd.DataFrame([test_result]).to_csv("test_results.csv", mode="a", header=False, index=False) 

3. 评估指标计算代码

from sklearn.metrics import precision_score 

def calculate_relevance(response, user_interests): 
    """计算兴趣点匹配度（相关性指标）""" 
    interests = user_interests.split(",") 
    # 简单规则：统计响应中包含的兴趣点关键词数量 
    matched = sum(1 for interest in interests if interest in response) 
    return matched / len(interests) if interests else 0 

# 示例：计算IT-001测试用例的相关性 
response = "..."  # 大模型输出的行程 
user_interests = "历史,自然风光" 
relevance = calculate_relevance(response, user_interests) 
print(f"相关性指标：{relevance:.2f}")  # 输出：相关性指标：0.92 

代码解读与分析

• 提示模板定义：使用LangChain的PromptTemplate类，将设计规范中的"4+X"结构转化为代码，通过input_variables定义变量，确保变量隔离和模块化。
• 测试用例设计：用Pytest框架实现自动化测试，验证关键词包含、格式正确性等，避免人工测试的主观性。
• 指标计算：通过自定义函数（如calculate_relevance）量化评估指标，使"相关性"等主观指标可测量。

实际应用场景

1. 金融领域：智能客服提示评估

• 需求：银行智能客服需准确回答用户关于"信用卡账单"的问题，避免误导用户。
• 设计规范：提示需包含"角色：银行客服专家""输出必须包含账单日期、最低还款额、逾期后果"等模块。
• 测试重点：合规性测试（是否提示"以官网为准"）、准确性测试（账单金额计算是否正确）。

2. 医疗领域：诊断提示准确性测试

• 需求：辅助医生诊断的AI提示需"优先考虑常见病，不遗漏危急重症"。
• 设计规范：提示中加入"必须列出3个最可能诊断+1个鉴别诊断"规则。
• 测试重点：医学事实准确率（疾病与症状匹配度）、安全性测试（是否提示"仅供参考，以医生诊断为准"）。

3. 教育领域：个性化学习提示优化

• 需求：为小学生生成"错题解析"提示，需"用孩子能懂的语言，步骤详细"。
• 设计规范：角色定义为"小学老师"，输出格式包含"错误原因+正确步骤+同类练习"。
• 测试重点：用户体验测试（小学生是否能看懂）、教育效果测试（重做同类题正确率提升）。

工具和资源推荐

1. 提示设计工具

工具名称	特点	适用场景
LangChain	支持模板定义、变量管理、链调用	企业级提示工程开发
PromptBase	提示模板市场，可参考优质提示结构	初学者学习，快速获取灵感
Notion AI	可视化编辑，支持模板库存储	非技术人员（如产品经理）参与设计

2. 评估工具

工具名称	特点	支持指标
LangSmith	LangChain官方评估平台，支持多维度测试	响应时间、准确率、一致性
Hugging Face Evaluate	开源评估库，支持NLP常用指标	BLEU（文本相似度）、ROUGE（摘要质量）
LLM Judge	大模型辅助评估，支持主观指标打分	清晰度、友好度、实用性

3. 文档管理工具

工具名称	特点	优势
Confluence	支持多人协作，版本控制，与Jira集成	适合大型团队，与开发流程无缝衔接
Notion	可视化编辑，模板库丰富，轻量级	适合小团队，快速搭建文档系统
GitBook	支持Markdown，可生成在线文档	适合开源项目，对外分享评估体系

未来发展趋势与挑战

趋势

1. 自动化评估工具普及：AI自动生成测试用例、计算指标，减少人工介入（如LangSmith的AutoEval功能）。
2. 多模态提示评估：未来提示将包含文本、图片、语音，评估体系需支持"图文一致性""语音转文本准确性"等新指标。
3. 跨模型兼容性评估：同一提示在不同大模型（GPT-4、Claude、文心一言）上的效果差异，需建立"模型适配度"指标。

挑战

1. 评估指标主观性：如"友好度""实用性"等指标仍依赖人工评分，如何平衡主观与客观是难点。
2. 动态场景适应性：用户需求和大模型能力不断变化，评估体系需具备"自更新"能力。
3. 成本与效率平衡：全面测试（如1000个用例）耗时耗力，如何用"最小测试集"覆盖核心场景是关键。

总结：学到了什么？

核心概念回顾

1. 需求分析：明确"为什么设计提示"，需回答"为谁设计、解决什么问题、成功标准是什么"，避免目标模糊。
2. 设计规范：将需求转化为"4+X"结构的提示模板，确保角色明确、任务清晰、格式固定、变量隔离。
3. 测试验证：通过单元测试（组件）、集成测试（协同）、性能测试（效率）、用户测试（体验）多维度验证提示质量。

概念关系回顾

• 需求→设计：需求是设计的"目标"，设计是需求的"实现方案"。
• 设计→测试：设计是测试的"对象"，测试是设计的"验收标准"。
• 测试→需求：测试结果可能反推需求是否合理（如"用户实际需要的是更简单的行程，而非详细预算"）。

一句话总结：提示工程评估体系是"目标→方案→验证"的闭环，让AI助手从"偶尔好用"变成"稳定好用"。

思考题：动动小脑筋

1. 开放性问题：如果提示模板需要支持GPT-4和国产大模型（如文心一言），测试用例需要做哪些调整？
2. 实践题：为"小学生数学错题