Claude 旧 Workbench 昨天正式退役:最麻烦的不是页面没了,而是 Prompt 和 Eval 资产可能跟着断档
昨天,Claude 旧版 Workbench 正式结束访问。
这件事看起来像一次普通的产品界面升级,但如果之前把 Prompt、变量和 Eval 直接保存在旧 Console 里,影响并不只是“以后换个页面继续用”。
Anthropic 早在 7 月 17 日的 Platform Release Notes 里就写得很明确:
Legacy Workbench access ends:
2026-08-17
同时还有一句更值得注意:
Saved prompts, variables, and evals
are not supported in the updated Workbench.
Anthropic Help Center 的说明更直接:8 月 17 日之后,Legacy Workbench 以及保存在里面的 Prompt、Prompt Version 和 Evals 将不再可访问。
如果你在截止日期前已经导出,事情不大。
如果没导出,今天真正该做的不是到处找“旧入口还能不能打开”,而是重新检查一遍:团队到底把多少 AI 工程资产放在了某个供应商的网页控制台里。
这篇就从这个问题开始。
先确认一件事:退役的不只是旧 UI
这次一起退役的还有三组实验性 Prompt API:
/v1/experimental/generate_prompt
/v1/experimental/improve_prompt
/v1/experimental/templatize_prompt
官方说明是:随着旧 Workbench 在 8 月 17 日退役,这几个实验性接口也同步移除;之后继续请求会返回错误。
所以可能受影响的并不只有“网页上点按钮的人”。
还有一类项目会在内部工具里偷偷依赖这些 Experimental API。
例如:
产品后台
→用户填写需求
→调用 generate_prompt
→自动生成系统提示词
→保存到数据库
如果这段代码半年没动,昨天之后才会突然暴露。
我建议直接搜代码仓库:
rg "experimental/generate_prompt" .
rg "experimental/improve_prompt" .
rg "experimental/templatize_prompt" .
rg "platform.claude.com/workbench" .
这比开会问“有没有人在用”可靠得多。
为什么我越来越不建议把 Prompt 的唯一副本放在网页控制台
Prompt 在 2024 年还很像“输入框里的几句话”。
到了 2026 年,生产 Prompt 往往已经包含:
- System Instruction;
- Tool Policy;
- 输出 Schema;
- Few-shot Example;
- 安全约束;
- 版本;
- 适用模型;
- 评测集;
- 发布状态;
- Owner。
它实际上已经接近:
可执行配置
如果代码要走 Git,数据库 Schema 要走 Migration,为什么 Prompt 却只有控制台里的一份?
最典型的问题是没法回答下面几个问题:
谁在上周三改了它?
为什么改?
哪个版本上线了?
上线后哪组指标变化?
怎么回滚?
旧版本跑在哪些会话上?
控制台里的“Save”很方便,但方便和可治理不是一回事。
我更倾向的做法:Prompt 回到仓库
一个很简单的目录就够了:
ai-assets/
├── prompts/
│ ├── contract-review/
│ │ ├── system.md
│ │ ├── output-schema.json
│ │ ├── examples.yaml
│ │ └── manifest.yaml
│ └── customer-support/
├── evals/
│ ├── contract-review.yaml
│ └── customer-support.yaml
└── policies/
└── tool-policy.yaml
manifest.yaml:
id: contract-review
version: 17
owner: legal-ai
status: production
model_profile:
primary: claude-sonnet
fallback: claude-opus
inputs:
- contract_text
- jurisdiction
output_schema:
file: output-schema.json
eval_suite:
file: ../../evals/contract-review.yaml
updated_by: zhangsan
change_ticket: AI-1842
重点不在 YAML。
重点是:
任何变更都能进入 PR
Prompt 进入 PR 以后,Code Review 看什么
代码 Review 不应该只看文字“顺不顺”。
我一般会把 Prompt Review 分成四类。
一,行为变化
- 如果信息不足,请先向用户追问。
+ 如果信息不足,请自行做合理假设。
这不是文案调整,而是 Agent 行为策略变化。
二,权限变化
- 只能查询订单。
+ 可以查询并修改订单。
这应该触发安全 Review、Tool Policy Review 和新的回归测试。
三,输出契约变化
- risk_level: LOW|MEDIUM|HIGH
+ risk_level: 1|2|3|4|5
下游解析程序可能直接挂。
四,成本变化
加入一大段新的分析要求,即使质量提升,也可能显著增加输入输出 Token。
PR 里至少应该给出:
Baseline Cost
Candidate Cost
Delta
Eval 也不该只是 Workbench 里的几条测试
一个最小 Eval 文件可以这样写:
suite: contract-review-v9
cases:
- id: jurisdiction-missing
input:
contract_text: ./fixtures/a.txt
jurisdiction: null
expect:
required:
- request_clarification
forbidden:
- fabricate_jurisdiction
- id: payment-clause
input:
contract_text: ./fixtures/b.txt
jurisdiction: CN
expect:
required_points:
- payment_term
- late_fee
- termination
它不一定需要一个“标准答案”。
很多企业任务更适合:
必须出现什么
不能出现什么
必须调用什么
不能调用什么
如果昨天没来得及导出,今天怎么办
情况 A:Prompt 同时存在代码或文档里
把现有副本收回来,重新建立 Git、版本、Owner 和 Eval。
情况 B:团队成员本地还有复制
不要直接选“最长的那一份”当生产版本。
先比对:
当前线上行为
历史截图
日志中的 Prompt Hash
API Trace
团队修改记录
尽量恢复真正生产版本。
情况 C:唯一副本就在 Legacy Workbench
按照 Anthropic 的退役说明,截止后旧 Workbench 及其保存资产已不再可访问。
这种情况下,与其继续赌“有没有隐藏恢复入口”,不如尽快联系官方支持确认是否存在账号级数据恢复可能,同时从应用运行日志、部署包、配置中心、历史 Trace 和代码中重新还原。
但这里必须接受一个现实:
没有提前导出的资产,不应该假设一定能恢复。
还有一个容易被漏掉的东西:变量
很多人只想到 Prompt,忘了 Workbench Variable。
例如:
{{company_policy}}
{{output_format}}
{{risk_threshold}}
迁移时一定检查:
Prompt
+Variable Name
+Default Value
+Environment Override
否则看起来 Prompt 一样,实际行为完全不同。
我会顺手做一次“Prompt 资产盘点”
| Prompt | Owner | 唯一副本在哪 | 有Git吗 | 有Eval吗 | 线上版本可追踪吗 |
|---|---|---|---|---|---|
| 合同审核 | 法务AI | Git | 是 | 是 | 是 |
| 客服回复 | 客服 | Console | 否 | 3条 | 否 |
| 周报总结 | 运营 | Notion | 否 | 否 | 否 |
| 数据分析 | BI | 本地文件 | 否 | 否 | 否 |
真正危险的是最后三种。
这次 Workbench 退役给我的提醒
一个 AI 平台里的 Prompt、Eval、Agent Config、Tool Config,只要已经进入生产,就不应该再被当成“平台里的内容”。
它们应该被当成:
软件资产
Anthropic 这次退役没有什么“不合理”。产品本来就会迭代。
真正需要反思的是,我们有没有因为一个控制台太方便,就把版本、审计、回滚和可移植性全部交了出去。
如果今天只能做一件事,我建议不是继续研究新版 Workbench 怎么用,而是把团队最重要的 10 个 Prompt 列出来,看一眼:
如果明天这个控制台完全打不开,我还能不能准确恢复生产版本?
答不上来的,就该迁了。
更多企业级 AI 应用、Agent、RAG 与模型工程化内容,我会继续整理在 智元界:
https://www.zyentor.com/