提示词测试

Summarize the incident report below for the on-call engineering team in 5 bullet points. Include the root cause, the customer impact, and the fix. Return a markdown list.

<report>
{{report}}
</report>

Summarize the incident report below for the on-call engineering team. Include the root cause, the customer impact, the fix, and some other details if relevant.

{{report}}

由引擎在构建本页面时计算得出。 按照下面的配置，版本 2 能以最低 70 分通过门禁。

{
  "include": ["prompts/**/*.md"],
  "model": "gpt-4.1",
  "minScore": 70,
  "maxTokens": 2000,
  "failOn": "critical"
}

promptflow check
promptflow compare prompts/summary.v1.md prompts/summary.v2.md

• 没有不稳定的测试

  同一个文件总是产生同样的结果，因此构建变红就意味着提示词变了。

• CI 中无需 API 密钥

  不向任何服务商发送内容，因此没有要管理的密钥，也无需按次付费。

• 快到每次提交都能运行

  一个满是提示词文件的仓库几秒钟就能检查完。

• 易读的失败信息

  每次失败都会指出文件、规则和修复方法，并链接到规则参考。

• check

  门禁本身：针对一组 glob 设定最低分数、最大 token 数和触发失败的严重级别。

• validate

  出现任何严重问题时退出码为 1，用于简单的通过或失败判断。

• compare

  同一提示词两个版本之间的 token、质量和问题差异。

• scan

  仅做安全检查，出现严重安全问题时失败。

• JSON 输出

  每个命令都支持 --json，便于在脚本和仪表板中使用。

• 按仓库配置

  在 .promptflowrc.json 中设置包含的 glob、模型、阈值和要忽略的规则。

• 在 git 中管理提示词的团队让提示词变更获得与代码变更相同的自动审查。
• 平台与 DevEx 工程师用一个小小的配置文件，在多个仓库中推行统一的提示词文件标准。
• 为 LLM 功能值班的工程师杜绝那类事故：一次提示词修改悄悄让 token 成本翻倍，或删掉了一条约束。

• 01

  Pull request 检查

  在 GitHub Actions 任务中运行 check，让低于标准的提示词变更无法合并。

• 02

  执行 token 预算

  设置 maxTokens，让系统提示词保持在你规划的额度之内。

• 03

  防止密钥泄露

  把 fail-on 保持为 critical，一旦提交了密钥或密码就会立即失败。

• 04

  Pre-commit 钩子

  对暂存的提示词文件运行 validate，在推送之前获得反馈。

• 工具提示词评估覆盖八个维度的公开评分公式，并支持版本对比。
• 工具提示词分析器找出任何提示词中的歧义、缺失上下文、冲突和浪费的 token。
• 工具提示词安全检测注入短语、泄露的密钥和个人数据，然后进行脱敏。
• 文档CLI 与 CI 门禁参考资料与配置说明。
• 文档评分模型参考资料与配置说明。

• 指南提示词测试与评估：如何衡量一个提示词测试集、指标、静态检查、模型评分器，以及在 CI 中运行提示词测试。
• 指南提示词管理与版本控制以团队方式存储、版本控制、评审、测试和发布提示词。
• 指南提示词优化：一种迭代方法一个可重复的循环：依靠度量而不是感觉来改进提示词。