
AI Prompt 管理平台
精准编排每一次AI对话
上个月,一个做 AI 客服的朋友跟我吐槽了一件事。他们公司的运营同学发现,客服机器人的回答语气太生硬了,用户反馈不好。于是运营去找产品,产品去找研发,研发说:"好的,我改一下代码。"
然后流程是这样的:改代码 → 提 PR → Code Review → 合并到主分支 → 跑 CI → 发布上线耗时:整整一天半。
而实际上,改的内容只有一句话——把 Prompt 里的"请用专业、客观的语气回答"改成"请用温和、亲切的语气回答"。
就这一句话。
产品经理崩溃了:"我就改一句话,怎么跟上坟一样?"
这不是个例。随着 AI 应用在企业里越铺越广,"改 Prompt 要发版"这件事,正在成为整个 AI 研发流程里最不合理的瓶颈。
为什么 Prompt 变成了"烫手山芋"?
我们得先搞清楚一件事:Prompt 到底是什么?
很多人觉得 Prompt 就是一段文本,跟代码里的注释差不多,随手写写就行。但真正做过 AI 应用的人都知道,Prompt 是连接业务逻辑和大模型的唯一桥梁。 同一个问题,换一种问法,大模型给出的答案质量可以天差地别。
这意味着 Prompt 不是一段"文本",而是一个"核心配置资产"。它决定了你的 AI 客服是"智能助手"还是"人工智障"。它决定了你的 AI 代码助手是"提升效率"还是"制造 bug"。它决定了你的 AI 数据分析师是"一针见血"还是"胡言乱语"。
所以问题来了:既然 Prompt 这么重要,为什么在大多数公司里,它的管理方式还停留在"散落各地"的原始状态?
你可以回想一下你或者你团队的做法:
这些做法在项目初期都"能跑"。但当你的 AI 应用从 Demo 走向生产,从 1 个 Prompt 变成 100 个 Prompt,从 1 个人用变成 10 个人协作时,问题就来了。
三个让人崩溃的真实场景
场景一:"我就改一个词,为什么要发版?"
这是最典型的痛点。
运营说:"把客服 Prompt 里的'抱歉'改成'非常抱歉'。" 开发说:"好的,我改代码,走发版流程。"
一个词的修改,需要经过完整的 CI/CD 流水线。如果团队还有灰度发布、分批上线等流程,可能要到第二天才能生效。
这不是人的问题,是流程的问题。 你让运营直接改代码?不可能。你让开发放下手头的工作去改一行字?效率太低。
场景二:"我改了 Prompt,但不知道到底有没有效果"
假设你终于说服团队把 Prompt 从代码里抽出来了,存在了数据库里。运营同学改了客服 Prompt,语气确实变温和了。
但问题是——你怎么知道这次修改是变好了还是变差了?
原来的版本成功率 95%,新版只有 90%?原来的版本平均响应 500ms,新版变成了 800ms?原来的版本每次消耗 2000 Token,新版变成了 3500?
没有任何数据,一切靠感觉。 而 AI 应用的特点恰恰是:改了一句话,效果可能天翻地覆,但你不知道。
场景三:"100 个微服务实例,我改的 Prompt 怎么同步过去?"
如果你的 AI 应用部署在微服务架构里,可能同时有几十上百个实例在运行。每个实例都引用了同一个 Prompt。
当你修改了这个 Prompt 之后,怎么让所有实例立刻用上新版本?
改一个 Prompt,发现有一半的实例还在用旧版本——这种"薛定谔的 Prompt"让人抓狂。
把 Prompt 当成代码来管理

PromptHub 就是为解决这些问题而生的。
核心思路非常简单:像管理代码一样管理 Prompt。
代码怎么管的?Git 版本控制、CI/CD 流水线、Code Review、发布回滚。Prompt 也应该有这些能力。
但 Prompt 和代码有一个关键区别:Prompt 需要被非技术人员修改,而且修改频率远高于代码。 你不能让运营同学去 Git 上提 PR。
所以 PromptHub 的设计思路是:既要有代码级的管理能力,又要有内容运营级的操作体验。
具体来说,它做了这五件事:
第一件事:热加载——改完 3 秒生效,不用发版
这是 PromptHub 最核心的能力。
当你或者你的运营同学在 Web 管理后台修改了一个 Prompt 并点击"发布"后,3 秒之内,所有引用了这个 Prompt 的微服务实例都会自动切换到新版本。
怎么做到的?三级架构:
当 Prompt 被发布时,PromptHub 通过 Redis Pub/Sub 广播一条"缓存驱逐"消息,所有订阅了该消息的微服务实例收到后,立刻清空对应 Prompt 的本地缓存。下一次请求到来时,自动从 Redis 拉取最新版本。整个过程不需要重启任何服务,不需要修改任何代码,不需要走任何发版流程。
第二件事:Git 式版本管理——改坏了?一键回滚
PromptHub 为每个 Prompt 维护了完整的版本历史。
每一个 Prompt 都有三个状态:草稿 → 已发布 → 已废弃。
每次编辑保存都会生成一个新版本,记录修改人和修改时间。你可以随时查看任意两个版本之间的差异对比(Diff),也可以一键回滚到任意历史版本。
这不是"覆盖",是"切换"。 历史版本永远保留,不会丢失。这意味着你可以大胆地试。改错了?没关系,点一下回滚,立刻回到之前的版本。改对了?看看效果数据,确认后再放心使用。
第三件事:效果看板——每次调用都清清楚楚
PromptHub 的效果统计体系,让"改完 Prompt 不知道好不好"这件事成为历史。
每次通过 SDK 调用 Prompt 时,你只需要在代码里加一行 client.report(),PromptHub 就会自动记录:
所有这些数据,在 Web 管理后台里自动汇总成可视化图表。你可以看到每个 Prompt 的调用量趋势、Token 消耗曲线、延迟分布图、成功率饼图。以前你只能靠"感觉"判断 Prompt 改得好不好,现在你有数据说话。
第四件事:模板变量——一个 Prompt 应对千万种场景
AI 应用里最常见的情况是:同一个 Prompt 模板,填入不同的变量,生成不同的内容。
比如一个客服 Prompt 可能是这样的:
你是{{company_name}}的客服助手。
请用{{tone_style}}的语气回答用户问题。
当前用户是{{user_name}},他的问题是:{{question}}不同的用户,不同的公司,不同的语气风格,但 Prompt 的结构是一样的。
PromptHub 原生支持 {{变量名}} 的模板语法。你只需要定义一次 Prompt 模板,然后在调用时传入不同的变量值,PromptHub 自动帮你渲染出最终文本。
而且它会自动校验:你定义了哪些必填变量?调用时有没有全部传入?没有传入的话,会直接报错告诉你缺了什么。
这个功能看起来简单,但实际用起来非常实用——它把 Prompt 从"一段固定文本"变成了"一套可配置的规则系统"。
第五件事:Java SDK——一行注解接入,零侵入
对于 Java 生态的团队,PromptHub 提供了 Spring Boot Starter。你只需要在 pom.xml 里加一个依赖,然后在代码里:
@Autowired
private PromptHubClient client;
// 渲染 Prompt
String rendered = client.render("order_query", Map.of("orderId", "12345"));
// 上报执行结果
client.report(rendered.getReportId(), true, 1000, 500, 4.5);不需要自己搭缓存,不需要自己写序列化。 所有复杂的工程问题,PromptHub 已经在 SDK 里帮你解决了。
谁适合用 PromptHub?
为了避免误会,我们明确说一下 PromptHub 不做什么:
它就像是你 AI 应用里的"配置中心"——但比配置中心更懂 Prompt,比数据库更懂缓存,比自己手写更省时间。
如果你符合以下任意一种情况,PromptHub 就是为你准备的:


开源地址
PromptHub 已在 Gitee 开源
🏠 开源地址:
https://gitee.com/sjz_zy/prompt-hub
欢迎 Star,欢迎提 Issue,欢迎一起来完善。让管理 Prompt 这件事,变得更简单~