提示词与评测工具

提示词与评测工具

提示词开发与效果评测是 AI 产品迭代的日常。本页只收提示词与评测工具清单，模型能力与定价对比见 模型能力与边界，成本测算方法见 LLM 成本测算。

本页按「调试 → 评测 → 观察 → 回流」四环节组织：先讲单条调试与开发工具链，再讲评测集与评测平台，最后讲上线后的监控与回归。方法论层面（指标定义、评测设计、人工评测流程）见 评估与评测，提示词写法本身见 提示词工程：本页只回答「用什么工具、怎么组织工作流」。

flowchart LR
    debug[调试提示词] --> dataset[评测集入库]
    dataset --> score[批量评测与基线]
    score --> inspect[分析 badcase]
    inspect --> revise[修改并版本化]
    revise --> regress[回归测试]
    regress --> rollout[灰度上线]
    rollout --> observe[线上观察与反馈]
    observe --> dataset

提示词工具链把一次性试错变成可回归的循环：线上 badcase 回流评测集，再驱动下一轮修改。

提示词开发工具

• 官方 Playground：各家模型平台的调试台（最常用）。各家的主打能力与入口见下文 提示词开发工具链 的「官方 Playground」一节。
• 可视化提示词工具：测试变量、批量对比输出，把提示词工程从记事本升级为可视化工作台，代表工具见 提示词开发工具链 的「可视化提示词工具」一节。
• 版本管理：提示词入库（git），带版本号与备注；与代码同仓、同评审、可回滚，详见 提示词开发工具链 的「提示词版本管理」一节。
• 结构化提示词框架：如 Claude Code 的 CLAUDE.md、系统提示词模板，把提示词资产从聊天记录沉淀为工程资产，详见 提示词开发工具链 的「系统提示词工程工具」一节。

评测工具

按用途把评测工具分为七类。下表先给全景，具体平台逐个介绍见 评测平台与工具：

自建 vs 采购的分界（经验值，因人而异）：用例量小（几十条）时自建脚本最灵活；到几百条、需要多人协作与线上追踪打通的阶段，自建评测的隐性成本：用例管理、标注界面、badcase 回流、评测与追踪联动，会超过商业平台订阅费。先用开源框架（Promptfoo / DeepEval）跑通流程，再按瓶颈决定是否上平台。

评测集建设要点

• 从真实用户输入出发，而非凭空想象：日志采样、客服工单、社区反馈都是比「拍脑袋」可靠得多的来源；冷启动期用 20 条种子用例即可开跑，边做边扩充（规模与标注方法见 评估与评测）
• 分类存放：典型 / 边界 / 对抗。典型用例定义正常做对的下限，边界用例暴露规则盲区（超长输入、模糊表达、多意图），对抗用例测试越界防护（诱导泄露系统提示、政策外承诺）；常见配比大致是典型 6-7 成、边界 2-3 成、对抗 1 成，随迭代调整

• 每次改动留基线分数，做前后对照：基线必须同时记录「模型版本 + 提示词版本 + 采样参数 + 日期 + 得分」，否则无法归因。一份可落地的基线记录长这样：

  日期	模型版本	提示词版本	采样参数	通过率	备注
  2026-08-01	model-A-0601	v1.0	temperature 0.3	70%	基线
  2026-08-10	model-A-0601	v1.1	temperature 0.3	85%	加「不得承诺政策外权益」约束
  2026-08-18	model-A-0601	v1.2（已回滚）	temperature 0.3	80%	口语化改写导致准确率下降，回滚 v1.1
  - 定期补充线上失败案例：线上 badcase 回流是评测集最重要的扩增来源，闭环机制见 评测集工程
  - 标注期望行为而非唯一答案：每条用例写明「答案要点 + 禁止行为」，给模型输出留合理空间；评分按维度分开打、不混总分（评分卡见 评估与评测）
  - 防评测集污染：测试用例不进提示词、不进微调数据，评测集与生产链路隔离，定期轮换新增

工作流建议

1. Playground 快速试 → 2. 用例入库 → 3. 批量跑分 → 4. 分析失败 → 5. 修改提示词 → 6. 回归 → 7. 灰度上线 → 8. 线上监控与回流

每个环节的常用工具与产出：

核心纪律：一次只改一个变量，每一步都有分数与 diff 可回退：「感觉变好了」不算数（迭代方法见 提示词工程 的「迭代式优化」）。

一个完整的迭代实例（客服问答助手）：

1. Claude Console 里试出初版提示词，肉眼判断「可用」
2. 从客服工单抽 20 条真实问题入库（典型 12 / 边界 5 / 对抗 3），标注期望行为
3. Promptfoo 跑分：综合通过率 70%，JSON 格式错误集中在 5 条长输入上
4. 复盘：失败案例 90% 是「政策外承诺」与「格式不稳」两类
5. 改提示词：加「不得承诺政策外权益」约束 + 输出 schema 说明（一次只改一类）
6. 回归：通过率 85%，格式错误清零
7. 按 10% 流量灰度一周，对比任务完成率与投诉率，与旧版本持平或更优
8. 全量上线；两周后从日志捞回 3 条新 badcase 回填评测集，进入下一轮

这个循环就是 AI 产品迭代的日常节奏，完整生命周期见 AI 产品开发生命周期(CC/CD)。

提示词开发工具链

官方 Playground

三家主流官方调试台，定位与主打能力各有侧重（以官方页面为准，访问日期 2026-08-24）：

使用纪律：Playground 是调试台，不是评测系统：参数随手改、没有版本，适合单轮快速试错；「感觉变好了」必须回到评测集跑分确认（与 提示词工程 的迭代纪律一致）。需要横向对比多家模型时，可用聚合平台的 Playground（如 OpenRouter）一次看多家输出，以官方页面为准。

按场景选调试台：

• 快速验证想法（任意任务）：三个官方台都行，选你最常用的模型厂商即可
• 测试结构化输出（JSON、工具调用）：OpenAI Playground 与 Gemini AI Studio 对结构化输出的试配更直观
• 自动改写与批量评测：Claude Console 的 Prompt Improver 与内置评测功能
• 多模态输入调试：Gemini AI Studio 免费额度下试图片、音频最方便

一个容易踩的坑：Playground 环境 ≠ 生产环境：上下文长度、系统提示词、工具调用、采样参数都可能不同，Playground 验证通过后必须在真实链路复测，再进入评测集跑分。

可视化提示词工具

把提示词从文本升级为可视化工作台，主打「版本对比、变量测试、批量输出对比」：

• Vellum：可视化编排、提示词版本管理与 A/B 测试、部署与监控（以官方为准）
• Portkey：提示词版本管理与网关、可观测与用量控制（以官方为准）
• PromptLayer：提示词追踪、版本、评审与回滚（以官方为准）
• LangSmith Prompt Hub：提示词与模型配置的共享仓库，与 LangSmith 评测打通（见 评测平台与工具）

选型提示：这类工具解决的是多人协作改提示词的问题：单人开发用 git + 脚本就够，团队协作再引入可视化平台。

提示词版本管理

• git 为事实来源：提示词与代码同仓、走 PR 评审、可 diff、可回滚；线上运行的提示词版本要能精确回溯：「这次回答变了」往往不是模型变了，而是提示词或配置变了
• 三位一体记录：版本记录同时记「提示词版本 + 模型版本 + 采样参数」，三者是一组配置；模型升级前先在相同评测集上跑新旧对照
• 评审流程：提示词改动与代码改动同门槛：PR 里附评测集前后对照分数与 badcase 分析，评审通过才可上线（评审检查清单见 提示词工程 的「提示词编写流程」）
• 提示词分类管理：系统提示词、模板、评测用例等工程资产进代码仓走评审；运营可调的文案类提示词放配置后台走变更审批。两类分开，既保证可审计，又给运营留灵活性
• 版本管理平台（如 LangSmith、Langfuse 的提示词管理功能）可作为 git 的可视化补充，但底层事实来源仍是 git

系统提示词工程工具

• Claude Code 的 CLAUDE.md 模式：把项目级指令（行为规范、常用命令、代码风格）写进 CLAUDE.md 文件，Claude Code 启动时自动注入为上下文，实现「提示词即配置、随仓库版本化」（以官方文档为准）
• 系统提示词模板库：把系统提示词当资产管理：骨架（身份 / 任务 / 流程 / 边界 / 兜底）+ 变量 + 评审记录，避免「每个开发者各自维护一份」的混乱（骨架示例见 提示词工程 的「系统提示词与角色」）
• 自动改写助手：Claude Console 的 Prompt Improver 等可辅助生成初稿或改写，但产出必须经评测集验证后才可上线

评测平台与工具

先给一个分类框架，九个工具可以归入三类：

• 评测框架（Promptfoo / DeepEval / RAGAS / OpenAI Evals）：开源、代码集成、把评测写进工程流程：适合「评测即代码」的团队
• 评测平台（LangSmith / Langfuse / Weave / Braintrust）：追踪 + 评测 + 标注一体化：适合需要线上链路与评测打通的团队
• 应用平台内置（Dify 标注）：随应用开发平台附带，标注 → 回流闭环开箱即用：适合快速原型与小团队

逐个介绍如下。定位、能力、开源与否、价格模式均以官方页面为准（访问日期 2026-08-24），价格与功能细节随时变动，不在此写精确数：

• LangSmith（LangChain 出品）：链路追踪 + 数据集与评测 + 人工标注 + Prompt Hub 一体的商业平台。能力：追踪、评测集跑分、LLM-as-Judge 评测器、反馈收集。闭源 SaaS（企业版支持自托管），免费额度 + 订阅制。适合已经用 LangChain 生态、需要追踪 + 评测一体的团队；其数据集（datasets）可以直接当评测集仓库用，标注界面支持人工打标与反馈收集。
• Langfuse：开源（MIT）的 LLM 可观测平台，可自托管。能力：追踪、指标、会话回放、数据集与评测、提示词管理、标注。云版订阅、自托管免费。适合注重数据合规、愿意自建基础设施的团队，也是开源社区的事实标准之一；数据集与提示词管理都能通过 API 与自建流水线对接。
• Weave（Weights & Biases 出品）：LLM 应用的追踪与评测，与 W&B 实验管理生态打通。适合已经在用 W&B 做实验跟踪的团队。
• Braintrust：以评测为中心的 AI 平台：数据集、评测、追踪、标注一体化，并提供开源的 autoevals 评测库。定价按用量（有免费额度），以官方为准。适合把评测当核心工程的中型团队。
• Promptfoo：开源 CLI 评测框架。YAML 定义用例与断言，批量跑分、前后 diff、CI 集成，另有红队（red team）功能。本地免费。适合开发者团队零成本起步，评测即代码。
• DeepEval：开源评测框架（Confident AI 出品），pytest 风格把评测写进测试代码，内置 G-Eval 等指标。适合「评测即单元测试」的工程化团队。
• RAGAS：开源的 RAG 专用评测框架，提供 faithfulness、answer relevancy、context precision、context recall 等端到端指标（论文、文档）；指标定义与定位方法见 RAG 评测体系。适合检索增强类产品的团队。
• OpenAI Evals：OpenAI 开源的评测框架，用 YAML/JSON 定义用例、脚本跑分；OpenAI 平台内也提供 Evaluations 功能。适合 OpenAI 生态内的团队，与 Playground 调试衔接顺滑。
• Dify 标注系统：开源 LLM 应用开发平台 Dify 内置的标注能力：在日志里把回答标为好 / 差，沉淀为标注数据集，可自动回流为提示词的少样本示例。适合用 Dify 搭应用的团队，是「标注 → 回流 → 改进」闭环的最低成本实现。

对比表

选型建议

• 1-3 人起步：Promptfoo / DeepEval + git 就够：零成本、评测即代码，不引入额外平台
• 上量后（多产品线、多人协作）：引入 LangSmith 或 Langfuse 做追踪 + 评测 + 标注一体，badcase 回流链路自动打通
• 数据合规要求高（医疗、金融、出海）：Langfuse 自托管优先，数据不出内网
• 评测集与标注规模大到需要专职角色：再考虑 Braintrust 类商业化评测平台，或自建评测服务

LLM-as-Judge 的实证与局限

LLM-as-Judge（用模型给模型打分）是当前自动化评测的主力，但它不是「免费的评分机器」：可靠性与偏差已被多篇实证研究量化。本节只讲结论与工具落地点，方法论细节（评分卡、一致性系数、人工流程）见 评估与评测。

实证结论

• Zheng 等人，《Judging LLM-as-Judge with MT-Bench and Chatbot Arena》（NeurIPS 2023，arXiv:2306.05685）：用当时最强模型（GPT-4）做裁判、配对对比（pairwise）时，裁判与人类偏好的一致性超过 80%，与人类标注者之间的一致性水平相当；而弱模型（如当时的 GPT-3.5）做裁判的一致性显著更低。核心结论：强模型裁判在多数任务上「可用但需校准」，裁判模型的选择比评分提示词细节更关键
• 后续综述 Gu 等人，《LLM-as-a-Judge: A Comprehensive Survey on the Role of LLMs in Evaluating LLMs》（arXiv:2411.15594）系统整理了各类偏差与缓解手段的实证脉络，可作为该主题的索引

已知偏差

缓解手段

flowchart TD
    outputs[A/B 候选输出] --> pair[交换 A/B 顺序各评一次]
    pair --> judges[多裁判模型投票]
    judges --> calibrate[人工样本校准]
    calibrate --> filter{置信度与风险}
    filter -->|高置信低风险| auto[自动通过或退回]
    filter -->|低置信或高风险| human[人工复核]

LLM 裁判适合批量筛选，但位置交换、多裁判和人工校准共同决定它能否安全进入评测流水线。

1. 对比评估优先于绝对打分：Zheng et al. 的实证中，配对对比（A/B 谁更好）与人类一致性高于单答绝对打分（1-10 分）。能用对比就不用打分
2. 位置交换：配对比较时 A/B 与 B/A 各评一次再取平均，消除位置偏差
3. 多裁判投票：多家模型裁判取多数一致，摊平单一模型的偏差
4. 裁判模型选择：选当前最强档模型；业务相近领域（如中文、代码）优先用该领域强的裁判
5. 人工抽检校准：先用一小批人工标注样本对齐（一致性达到阈值，如 80%，再批量使用）；之后定期抽检维持校准
6. 裁判当过滤器：让 judge 先粗筛（高分直接过、低分直接退），中间带样本转人工。既省人力又保住质量

一个可落地的裁判提示词骨架

对比评估的裁判提示词，把「维度 + 顺序 + 反偏差声明」写清楚即可：

1
2
3
4
5
6
7

你是评审员。给你一条用户问题与两个候选回答（A 与 B）。
评审维度：
- 准确性：事实是否正确、有无编造；
- 完整性：是否覆盖问题全部要点；
- 安全性：有无有害、越界、诱导内容。
步骤：先逐维度对比 A 与 B，再输出结论「A 优于 B / B 优于 A / 持平」并附一句理由。
约束：只根据给定内容评审，不考虑回答长度与文风；若信息不足，结论为「持平」。

配套做法：A/B 与 B/A 各评一次取平均（消除位置偏差）；多个裁判模型投票；输出解析成结构化结论，低置信样本自动转人工。

从论文到产品：MT-Bench 与 Chatbot Arena

Zheng et al. 的贡献不止于结论本身：他们同时发布了 MT-Bench（80 道多轮问题组成的评测集）与 Chatbot Arena（后来的 LMArena，匿名配对投票收集人类偏好）。后者把「人类偏好数据」做成持续更新的社区基准，至今仍是观察模型相对强弱的重要窗口；它印证了配对对比（而不是绝对打分）是收集偏好的更可靠形态。产品里做评测，也可以沿用同样的设计。

评测集工程

评测集是 AI 产品迭代的测试套件。本节讲工程化落地，方法论（三层评估体系、指标定义）见 评估与评测。

构建来源

• 真实用户输入优先：生产日志采样、客服工单、社区与竞品评论区是首选来源；采样用分层抽样，保证典型 / 边界 / 对抗三类都有覆盖，并按错误率加权多采失败样本
• 合成数据补充：LLM 生成 + 人工筛选核验，用例标注合成来源。合成数据适合铺量，但边界质量与真实数据有差距，不能喧宾夺主
• 冷启动：20 条种子集起步，先跑通「评测 → 修复 → 回归」循环，再随迭代扩充到几百上千条

分类与标注

• 典型 / 边界 / 对抗三类分开存放、分开统计。混在一起看不出失败模式集中在哪一类
• 每条用例标注期望行为（答案要点 + 禁止行为），评分维度分开打（准确 / 忠实 / 相关 / 完整 / 安全 / 风格，定义见 评估与评测）
• 用例格式优先与工具对齐：Promptfoo / DeepEval 用 YAML、LangSmith / Langfuse 用数据集，直接 import / export，避免自建格式的转换损耗

基线锁定与回归

• 基线表记录「模型版本 + 提示词版本 + 采样参数 + 日期 + 得分」，每次改动跑同一评测集做前后对照
• 评测进 CI：PR 触发评测任务（Promptfoo / DeepEval 接 CI，或 LangSmith / Langfuse 的数据集跑分），把评测从手动活动变成门禁一部分
• 评测集本身也要版本化：增删用例有 diff、有变更记录，与代码同 PR。基线分数只有绑在评测集版本上才有可比性，用例变了旧分数就失效
• 评测成本可控：每次回归成本 ≈ 用例数 × 平均 token 数 × 单价，回归频率（每次 PR / 每日 / 每月）与用例规模按预算规划；评测集膨胀到上千条后，可考虑按错误率加权抽子集跑日常回归、全量留到发布前
• 防污染：评测用例不进提示词、不进训练数据，评测集与生产链路隔离，定期轮换新增（详见 评估与评测 的「评测集污染」）

失败案例回流

线上 badcase → 人工复盘 → 归纳错误模式 → 回填评测集 → 修复（改提示词 / 换模型 / 加护栏）→ 回归 → 再灰度。回流闭环的工具落地点：

• 追踪平台（LangSmith / Langfuse）按错误标签导出失败样本 → 人工标注 → 导入数据集
• Dify 等平台直接在日志里标注好 / 差，自动沉淀为标注数据集
• 错误模式按「模式 / 触发条件 / 影响 / 修复方向」登记，一次修一类，修完回归验证

上线后监控与回归

生产日志回流成评测集

• 追踪平台记录线上调用（输入、输出、token、延迟、反馈），按策略采样：错误率高的场景加权多采、低置信输出优先采
• 采样数据先脱敏再入库；人工标注后回填评测集。生产日志是评测集持续更新的活水源，不是一次性迁移
• 采样要设配额与周期：每天固定条数上限，避免标注队列堆积；标注积压时优先处理错误率高的簇，而不是按时间顺序平铺

在线效果监控

• 核心指标：任务完成率、采纳率、投诉率、转人工率等（指标定义见 评估与评测 的「线上指标」）；成本与延迟一并盯，防止质量换成本失控
• 看板：LangSmith / Langfuse 自带仪表盘，或导出到 Grafana 与业务看板合并；异常（投诉率突增、采纳率骤降）设告警

灰度与回归节奏

• 提示词改动按 10% → 50% → 100% 放量，每步先在评测集回归、再对比线上指标；对照期间保证分组随机（A/B 方法见 评估与评测 的「线上评估与灰度」）
• 回滚预案：旧版本配置保留、一键回退，指标明显变差 5 分钟内退回：回滚是发布流程的一部分（完整生命周期见 AI 产品开发生命周期(CC/CD)）

漂移检测

• 模型版本漂移：厂商更新模型后，同一提示词的行为悄悄变化（更啰嗦、格式不同、拒答变多）。对策：固定模型版本、每次升级在相同评测集跑新旧对照、定期重跑评测集
• 输入分布漂移：用户提问的语义分布随时间变化（新功能、新热点）。对策：对线上输入做 embedding 聚类或关键词频次监控，发现新簇就扩充评测集
• 节奏建议：每周抽检真实对话人工评分，每月全量回归一次；模型 / 提示词 / 采样参数任何一项变更，即时回归

flowchart TD
    change[模型、提示词或参数变更] --> regression[同一评测集回归]
    regression --> compare[对比质量、延迟与成本]
    compare -->|达标| canary[灰度 10% → 50% → 100%]
    compare -->|不达标| rollback[回滚并分析 badcase]
    canary --> online[线上监控与采样]
    online --> drift{发现版本或输入漂移？}
    drift -->|是| regression
    drift -->|否| online

线上监控把漂移检测和回归、灰度、回滚连成一条闭环，避免只在提示词改动时才验证。

来源说明

以下来源访问验证日期 2026-08-24；功能、价格与开源许可以各官方页面为准；本文为原创转述，未大段照抄原文。

1. Anthropic Console 文档：Playground、Prompt Improver 与评测功能。
2. OpenAI Playground与 OpenAI Evals 指南：调试台与平台内评测。
3. Google AI Studio：Gemini 免费调试台。
4. Claude Code 记忆（CLAUDE.md）文档：项目级提示词文件模式。
5. LangSmith 文档：追踪、数据集、评测与标注。
6. Langfuse 文档：开源 LLM 可观测与评测。
7. Weave 文档：W&B 的 LLM 追踪与评测。
8. Braintrust 文档：评测平台与开源的 autoevals。
9. Promptfoo 文档：开源 CLI 评测与红队。
10. DeepEval（Confident AI）：开源评测框架。
11. RAGAS 论文（arXiv:2309.15217）与 RAGAS 文档：RAG 评测指标。
12. OpenAI Evals：开源评测框架。
13. Dify 文档：标注系统与日志回流。
14. Zheng 等人，《Judging LLM-as-Judge with MT-Bench and Chatbot Arena》，NeurIPS 2023（arXiv:2306.05685）：LLM 裁判与人类偏好一致性、位置 / 冗长 / 自我强化偏差。
15. Wang 等人，《Large Language Models are not Fair Evaluators》（arXiv:2305.17926）：位置偏差的进一步实证与校准方法。
16. Gu 等人，《LLM-as-a-Judge: A Comprehensive Survey on the Role of LLMs in Evaluating LLMs》（arXiv:2411.15594）：LLM-as-Judge 综述。
17. 评估与评测与 RAG 进阶：评测方法论与 RAGAS 指标（站内）。

更新记录

发现错误？想一起完善？ 在 GitHub 上编辑此页！
本页面贡献者：AI-PM Wiki Team
本页面的全部内容在 CC BY-SA 4.0 和 SATA 协议之条款下提供，附加条款亦可能应用