对大多数团队来说,prompt engineering 就是不断试错。你调整一个系统提示词,执行几次,觉得「感觉好像有点改善」,然后就继续下一步。没有版本历史纪录、无法比较第 14 次迭代与第 11 次迭代的差异,也没有系统化的回馈机制将生产环境的品质与提示词变更连结起来。
我们开发了 Prompt Engineering Studio 来解决这个问题。这是一个直接内嵌在 recipe 编辑器中的可折叠面板——不是另一个独立页面,也不是另一个工具。五个页签就在提示词文字框旁边:Token Budget、Variables、Versions、Few-Shot 和 Optimizer。迭代在情境中进行,而非在互不相关的 workflow 中执行。
版本追踪与差异比较
每次提示词变更都会在 Firestore 子集合中建立一个版本。每个版本都会储存:
| 栏位 | 说明 |
|---|---|
| 版本编号 | 自动递增的整数 |
| 模板文字 | 当时的完整提示词模板 |
| 相似度分数 | 透过正规化的 Levenshtein 距离与前一版本比较,得出 0-100 的分数 |
| 作者 | 进行变更的人员 |
| 变更日志 | 自由格式的变更内容与原因描述 |
品质指标会按版本追踪:总执行次数、成功次数、按赞次数、按踩次数、回馈比率,以及平均 token 使用量。这些指标会在 Redis 中快取 5 分钟,让 UI 保持回应速度,而不会在每次开启面板时频繁查询 Firestore。
差异检视器会逐行显示任意两个版本之间的比较。新增的内容以绿色呈现,删除的内容以红色呈现,并附带统计资料摘要变更的行数。相似度分数会以颜色标示:绿色表示相似度 >= 90%(微幅调整)、琥珀色表示相似度 >= 50%(中等程度重写)、红色表示相似度 < 50%(大幅变更)。
**回复版本是非破坏性的。**还原到先前版本时会以旧内容建立新版本——它不会覆写历史纪录。第 15 版可能与第 8 版完全相同,这没问题。完整的变更链始终会被保留。
即时 Token 预算视觉化
Token Budget 页签会在您输入时即时呈现条形图,显示上下文视窗的使用状况。五个标示区段会细分 token 的使用分布:
| 区段 | 预算 |
|---|---|
| System | 200 token 开销(系统提示词框架) |
| Glossary | 500 token 上限 |
| Few-Shot | 2,000 token 上限 |
| RAG Context | 4,000 token 上限 |
| User Prompt | 根据文字长度 / 4 估算 |
视觉化会依据模型调整。选择 Claude,条形图会缩放至 200K token。切换到 GPT-4o,会重新缩放至 128K。切换到 Gemini,会延伸至 1M。比例会相应调整,让您立即看出在某个模型的上下文视窗中绰绰有余的提示词,在另一个模型中可能会过于紧绷。
三个警告层级会自动触发:
- 使用率 >80% ——琥珀色警告,建议您修剪上下文或 few-shot 范例
- 使用率 >90% ——红色警告,表示有很高的截断风险
- 剩余输出空间 <1,000 token ——明确警告模型没有足够空间产生有用的回应
按键输入会延迟 500ms 更新,因此图表保持回应速度,而不会在每个字元输入时都重新计算。
变数检查器
Variables 页签会在您编辑提示词模板时即时侦测 {{variable}} 和 {{fragment:name}} 参考。每个侦测到的变数都会与 recipe 的 inputSchema 交叉比对,并指派四种状态之一:
- Matched(绿色)——变数同时存在于模板和 schema 中。所有内容都正确连接。
- Orphan(琥珀色)——变数出现在模板中,但未在 schema 中定义。提示词参考了在执行时不会有值的内容。
- Unused(红色)——变数在 schema 中定义,但从未在模板中参考。您收集了无用的输入。
- Fragment(蓝色)——对可重复使用提示词片段的
{{fragment:name}}参考。
对于已匹配的变数,检查器会从历史执行资料中提取范例值,让您无需离开编辑器就能看到真实的输入内容。这能找出一类常见的错误:schema 定义了 companyName 栏位,但模板却参考 {{company_name}}。
Few-Shot 范例管理
Few-Shot 页签让您可以将成功的执行结果钉选为精选范例。每个钉选的范例都有可编辑的输出栏位——您可以修正或改进模型的原始回应,以建立黄金标准示范。
品质评分决定哪些范例会在执行时浮现。每个范例从基础分数 50 开始。按赞加 40 分,按踩减 30 分。bakeoff 评估的评分也会加权计入。
在执行时,系统支援三种检索策略:
| 策略 | 运作方式 |
|---|---|
| Feedback-based | 选择获得按赞的执行结果,并多样化以避免重复范例 |
| Recent | 选择最近的成功执行结果 |
| Similar | 透过 embedding 使用余弦相似度寻找与当前输入最接近的执行结果 |
钉选的精选范例永远优先于动态检索的范例。它们会先被注入,剩余的预算则由策略选取的范例填充。
所有 few-shot 范例都会以 <few_shot_examples> XML 区块的形式注入提示词中,受限于 2,000 token 预算。如果您的精选范例超过预算,系统会从分数最低的范例开始截断。
AI 驱动的优化器
Optimizer 页签提供三个层级的提示词改进,从手动逐步升级到全自动。
第一层级:使用者触发分析
点击「分析」,优化器会提取该 recipe 最近 50 次成功执行的结果,将它们分成按赞和按踩两组,并将分布情况传送给 Claude Sonnet 4.6 进行结构化分析。模型会返回一系列建议,每个建议包含:
| 栏位 | 说明 |
|---|---|
| Section | 要变更的提示词部分 |
| Original text | 该区段的当前提示词文字 |
| Suggested text | 建议的替换文字 |
| Rationale | 为何此变更应能改善输出品质 |
| Confidence | 0-100 分数,表示模型的确定程度 |
您可以审查每个建议,并选择套用(在编辑器中内嵌替换)或 A/B 测试(建立 bakeoff,在生产环境中比较当前提示词与建议)。
第二层级:自动触发建议
当一个 recipe 累积了 5 个或更多按踩评价时,优化器会在无需使用者介入的情况下自动产生 1-3 个改进建议。这些建议会在 Optimizer 页签上显示为通知徽章。
此层级的速率限制为每个 recipe 每小时一次,以防止建议疲劳。其意图是温和的提醒——「您的使用者对此 recipe 的输出不满意,这里有一些想法」——而不是大量涌现的变更。
第三层级:品质漂移修正
此层级由 Quality Guard 系统在侦测到 recipe 输出品质随时间下降时触发。优化器会分析漂移时段中排名前 5 与后 5 的执行结果,识别出品质下降的模式,并产生针对性的提示词变更。
第三层级还可以自动触发迷你 bakeoff——在当前提示词与建议修订版之间建立结构化 A/B 比较,导向真实的生产流量。这完全闭合了循环:品质下降,系统提出修正,对真实输入进行测试,然后回报结果。
速率限制保持保守:修正建议限制为每 24 小时一次,自动触发的 bakeoff 限制为每 7 天一次。提示词优化应该是谨慎的,而不是失控的回馈回圈。
为何它存在于编辑器中
Studio 是一个面板,而不是一个页面。这是一个刻意的设计决策。Prompt engineering 是迭代性的——您变更一行,检查 token 预算,瞥一眼差异,执行测试。在不同工具之间切换会打断流程。
当 Studio 折叠时,您拥有一个干净的编辑器。当它展开时,您需要的每个讯号——token 使用率、变数健康状况、版本历史、few-shot 范例、优化建议——都在一个页签之外。无需导航,无需载入画面,无需失去情境。
可用性
Prompt Engineering Studio 在 Pro 方案及以上提供。版本追踪、token 预算管理和变数检查包含在 Pro 方案中。Few-shot 管理与 AI 驱动的优化器(所有三个层级)在 Pro 和 Enterprise 方案中提供。