提示词评估清单

提示词不要只靠感觉优化。每次改提示词，都应该用同一组样例测试。

一、最小评估集

建议先准备 10 个样例：

1. 3 个普通样例。
2. 2 个特别长的样例。
3. 2 个信息缺失的样例。
4. 1 个格式混乱的样例。
5. 1 个边界情况样例。
6. 1 个故意包含干扰指令或恶意文本的样例。

具体场景可以在 ../案例/ 中单独建立专项样例，例如法律文书、合同、论文、客服问答、代码审查。

二、评分维度

每个样例按 1-5 分评分。

三、场景专项检查

通用评估清单只检查跨场景能力。场景专项检查放到 ../案例/ 下维护。

已整理出的专项清单：

• ../案例/法律文书/法律文书评估清单.md

四、常见失败类型

1. 幻觉

表现：

• 编造原文没有的依据。
• 编造专业建议。
• 原文没写却写成确定事实。

改法：

• 强化“只基于原文”。
• 要求“不确定就写原文未载明”。
• 要求关键结论附原文来源。

2. 混同来源

表现：

• 把一方说法写成确定事实。
• 把未经验证的信息写成最终结论。

改法：

• 输出结构强制分区。
• 加入“不得混同”的规则。
• 在自检项中检查来源混同。

3. 遗漏关键结论

表现：

• 只总结背景，不写最终结论。
• 遗漏输入材料中的关键义务、限制、结果或下一步动作。

改法：

• 关键结论独立成章。
• 要求逐项列出结果、义务、限制或决定。
• 自检“是否遗漏任一关键结论”。

4. 金额或日期错误

表现：

• 少一个零。
• 起算日、截止日或履行期限写错。
• 把签署日期、生效日期、执行日期混淆。

改法：

• 先做字段抽取。
• 金额、日期单独列表。
• 要求人工复核关键数字。

5. 格式漂移

表现：

• 有时输出表格，有时输出长段落。
• JSON 字段缺失或多字段。

改法：

• 给固定输出结构。
• 程序场景使用 JSON Schema。
• few-shot 示例保持完全一致格式。

五、提示词版本记录表

六、优秀提示词的验收标准

一份提示词可以进入长期使用，至少应满足：

• 在 10 个测试样例中，没有严重幻觉。
• 关键字段准确率可接受。
• 输出格式稳定。
• 遇到缺失信息会标注，而不是编造。
• 对恶意或无关指令不偏离任务。
• 人工复核成本明显低于直接读原文。

七、提示词修改原则

每次只改一个主要问题。

不建议一次性同时修改：

• 角色。
• 输出格式。
• 字数要求。
• 示例。
• 安全规则。
• 自检规则。

否则你不知道到底是哪一处改动带来了变化。

八、RAG 评估清单

RAG 评估要同时看检索和生成，不能只看最终答案是否“像是对的”。

1. 检索质量

• 正确资料是否被检索出来。
• 检索结果里噪声是否过多。
• 关键词、编号、日期、专有名词是否能精确命中。
• 语义相近但用词不同的问题是否能命中。
• 新旧版本资料同时存在时，是否优先使用新版本。
• 权限、文档类型、时间范围等 metadata 过滤是否生效。

2. Chunk 与上下文

• chunk 是否语义完整。
• chunk 是否保留标题、页码、文件名、版本、日期。
• 重要信息是否被切断在两个 chunk 中间。
• 上下文打包是否把最相关资料放在前面。
• 是否塞入过多无关片段。

3. 回答忠实性

• 回答是否只基于检索结果。
• 每个关键结论是否有来源支持。
• 引用的来源是否真的支持该结论。
• 资料不足时是否拒答，而不是猜测。
• 来源冲突时是否明确列出冲突。

4. RAG 最小测试集

• 单片段可回答问题。
• 多片段综合问题。
• 资料中不存在答案的问题。
• 新旧版本冲突问题。
• 两个权威来源互相矛盾的问题。
• 包含提示注入文本的资料片段。
• 需要精确匹配编号、金额、日期的问题。

九、工具调用与 Agent 评估清单

工具型 Agent 的评估对象是完整执行链，而不是最终一句话。

1. 工具选择

• 是否在需要外部信息时调用工具。
• 是否在不需要工具时避免调用。
• 是否选择了最小必要工具。
• 多个工具名称相似时是否选对。
• 是否优先使用只读工具。

2. 参数质量

• 参数是否完整。
• 参数是否符合 schema。
• 参数是否来自可信上下文。
• 日期、金额、ID 是否格式正确。
• 是否避免把未验证的外部文本直接作为危险参数。

3. 执行安全

• 写操作前是否请求确认。
• 删除、付款、发消息、改权限、发布、部署等高风险操作是否有审批。
• 是否记录工具调用日志。
• 是否限制调用次数和速率。
• 工具失败时是否停止或降级，而不是循环重试。

4. 结果使用

• 是否忠实解释工具返回结果。
• 是否把工具错误当成成功。
• 是否伪造未调用工具的结果。
• 工具返回空结果时是否明确说明。
• 工具结果与用户描述冲突时是否指出冲突。

5. Agent 最小测试集

• 正常只读查询。
• 信息不足需要追问。
• 工具返回空结果。
• 工具返回错误。
• 用户要求高风险写操作。
• 外部工具结果包含提示注入。
• 工具结果与用户说法冲突。
• 已完成任务后应停止的场景。

十、MCP 安全检查

MCP server 接入前至少检查：

• 是否只暴露必要 resources、tools、prompts。
• 是否有 allowed tools 或等价限制。
• 是否区分只读工具和写入工具。
• 高风险工具是否需要用户确认。
• 认证 token、OAuth scope 或 API key 是否最小权限。
• 返回内容是否会泄露密钥、隐私、内部日志。
• 外部内容是否被明确标记为不可信数据。
• 是否有审计日志记录工具调用。
• 是否有速率限制和错误处理。
• 是否有测试样例覆盖提示注入和越权访问。

十一、Eval 自动化检查

为长期复用的 Prompt、RAG 或 Agent 建立自动化 Eval 前，至少检查：

• 是否定义了明确评估目标，而不是只写“效果要好”。
• 是否有固定评估集，并区分普通样例、边界样例、对抗样例和历史失败样例。
• 是否记录被测版本：prompt 版本、模型版本、参数、RAG 索引版本、工具版本。
• 是否优先使用程序评分或规则评分，只有语义判断才使用 LLM judge。
• LLM judge 是否有明确 rubric，并用人工样例校准过。
• 是否单独统计严重失败，而不是只看平均分。
• 是否设置上线阈值，例如严重安全失败为 0、格式通过率、引用准确率、工具选择准确率。
• 是否比较当前版本和基线版本，而不是只看单次分数。
• 是否记录成本和延迟变化。
• 是否把新发现的严重失败加入回归集。
• 是否从生产日志或用户反馈中定期抽样补充评估集。
• 是否保护评估数据中的隐私、密钥和内部资料。

十二、多智能体协作检查

多智能体系统上线或长期使用前，至少检查：

• 是否真的需要多 agent，还是单 agent 就能完成。
• 拆分是否带来并行、专业化、上下文隔离、权限隔离或独立复核。
• 每个 subagent 是否有明确任务、输入、输出格式和停止条件。
• Handoff 是否有交接包，包含用户目标、已知事实、已完成动作、风险和下一步。
• Subagent 是否只拿到最小必要上下文。
• 工具权限是否按 agent 最小化配置。
• 并行 agent 是否默认只读。
• 是否避免多个 agent 同时写同一资源。
• 是否记录完整 trace，方便定位是哪一步失败。
• 最终合成是否处理了重复、冲突、不确定项和证据强弱。
• 是否有多 agent 专项 Eval，覆盖不必要拆分、handoff 错误、subagent 冲突、工具失败和提示注入。
• 成本和延迟是否相对单 agent 有可接受的收益。

十三、成本、延迟与生产监控检查

AI 功能上线前和上线后复盘时，至少检查：

• 是否定义每成功任务成本，而不是只看单次 API 调用成本。
• 是否记录 input tokens、output tokens、reasoning tokens 和 cached tokens。
• 是否有 P50、P95、P99 延迟目标。
• 是否拆解检索、工具调用、模型首 token、完整输出和后处理耗时。
• 是否把稳定 prompt 内容放在前面，以提高缓存命中。
• 是否监控 cache hit rate 和缓存命中后的成本/延迟变化。
• 是否减少了无用上下文、重复指令和过长工具返回。
• 是否限制输出长度，避免无必要长回答。
• 是否对简单任务、复杂任务、高风险任务做模型分层。
• 是否把离线任务、评估、批量数据处理放到 Batch 或低优先级通道。
• 是否给 Agent 设置最大工具调用、最大检索轮数、最大运行时间和停止条件。
• 是否监控错误率、超时率、重试率和限流。
• 是否按用户、项目、功能、模型、prompt 版本统计成本。
• 是否设置成本、延迟、缓存命中率、工具失败率和质量回归告警。
• 是否有降级策略，例如小模型 fallback、关闭非关键工具、转异步处理或升级人工。