GitHub：FrankDengAI/Prompt-Studio: Local web app: turn speech or casual text into polished prompts, then stream-chat with any OpenAI-compatible API (Ollama-ready) or Deepseek or others. Keys stay on your machine.https://github.com/FrankDengAI/Prompt-Studio

大模型普及之后，真正卡住大多数人的，往往不是「有没有模型用」，而是「我明明知道自己要什么，为什么一说出口，模型就像听不懂」。这种挫败感很微妙：它不是系统报错那种干脆的失败，而是一种缓慢的、消耗信任的失配——你觉得自己表达的是意图，模型读到的是模糊；你觉得自己加的是约束，模型读到的是噪音。久而久之，很多人把问题归结为「模型不够聪明」，却很少回头想：也许缺的不是智商，而是中间那一层把人类自然语言翻译成「模型可执行的契约」的工序。提示词工程被说得玄乎，本质上就是在干这件事：把混沌的诉求，压成边界清晰、结构可读、可被模型稳定响应的文本。可这件事如果每次都靠人肉在输入框里反复试、反复改，成本会高到让人想放弃；如果又不得不把密钥交给各种来路不明的网页工具，心里的不安全感又会把成本再翻一倍。

正是在这种背景下，我想写一篇长文，推荐一个名字很朴素、野心却不小的开源项目：Prompt Studio（提示词工坊）。它不是什么「全自动 Agent 宇宙」的宏大叙事，也不是又一个聊天壳子；它更像一张工作台——左边允许你保留「人话」的粗糙与温度，可以是键盘敲出来的碎碎念，也可以是浏览器语音听写下来的口语（中文场景下，Chrome 的 Web Speech API 往往更顺）；中间由你选定的、符合 OpenAI 兼容协议的大模型，把这段话改写成更结构化、更可执行的提示词；右边则把结果交还给你，让你仍然拥有最后一笔编辑权。真正进入多轮对话、流式吐出回复的，是右侧定稿后的文本。这一条链路看似简单，却触及一个很深刻的分工：模型可以帮你「起草契约」，但签字权仍在你手里。润色与对话在工程上是两次独立请求，在体验上却连成一种习惯——先把自己说清楚，再让模型把「给模型看的话」说清楚，最后才进入你来我往的对话。这种节奏，比一上来就对着模型空喊「帮我写」要稳得多，也比把提示词完全外包给黑箱模板要诚实得多。

若再往深里想一层，Prompt Studio 真正吸引我的，并不是某一个炫酷单点，而是一种克制的产品伦理。它默认在你自己的机器上跑：FastAPI 作后端，原生 HTML/CSS/JS 作前端，没有为了「显得现代」而叠一层又一层的构建链。你的 API Key 落在本机的 config/providers.json 或 .env 里，由你决定要不要接云端；项目并不会把你的密钥托管到作者的服务器上去完成某种「云端魔法」。在「什么都想上云、什么都想收集数据」的风气里，这种本地优先反而成了一种稀缺品——它不是反云，而是把「数据与密钥流经何处」交回给使用者判断。更务实的一点是：当你既没有配置云端 Key、也还没有一份有效的多线路配置时，它会尝试给你写好本机 Ollama 的预设，让你在零云端账号的前提下也能把整条流程跑通。这当然不等于「免费午餐」：Ollama 吃的是你的显卡或 CPU 与电费，云端 API 则各自有各自的计费与限额，那些打着「永久免费万能接口」旗号的神话，在这个项目相关的讨论里也不该被重复。诚实交代边界，反而让推荐变得可信——你知道自己付的是什么代价，也就更愿意把时间花在这个工具上，而不是花在事后骂「被标题党骗了」上。

从能力上看，它把「风格」做成了可感知的档位：轻松自然、标准清晰、严格分点、学术规范——同一句话在不同档位下，输出的骨架与语气会明显不同。这不是简单扩写几个形容词，而是在用系统提示层面的设计，推动模型往不同的协作协议靠拢：有时你需要的是亲切说明，有时你需要的是可交付的条目，有时你需要的是可被同事直接转发的工作邮件式的 clarity。再加上任意 OpenAI 兼容的 chat/completions 端点、页面里可视化的厂商预设、流式 SSE 与可随时停止的生成、左侧与右侧各自的快捷键、浏览器本地防抖保存草稿——这些细节堆在一起，会形成一种很实在的手感：它不是演示用的 Demo，而是可以日复一日打开的那类软件。若你偏工程化，还可以绕过网页，直接调用 /api/refine 与 /api/chat，把「润色—对话」嵌进自己的脚本或内部工具链；密钥仍然只该待在服务端配置里，这是一条不该被省略的安全常识。若你关心隐私，也要明白：语音识别的第一段旅程发生在浏览器生态里，是否触及浏览器厂商的策略，与这个项目的后端无关——这不是推卸，而是把责任边界划清楚，使用者反而知道该在哪里多留一个心眼。

浏览器打开 http://127.0.0.1:8765/ 即可。Windows 也可尝试双击 run.bat。若要接云端，可复制 config/providers.example.json 为 config/providers.json 按字段填写，或使用 .env、或在页面「配置模型」里保存——三条路殊途同归，都是把配置写回你掌控的本地文件；含真实 Key 的文件切勿推上公开仓库，这是写博客与做开源时共同的底线。若将服务暴露到公网，还应考虑关闭网页随意写配置的能力（例如通过环境变量限制 ALLOW_PROVIDER_MUTATIONS），把运维权收回到可信边界之内。

最后说几句给正在犹豫要不要点进 GitHub 的人听。我们这一代人正在经历一场语言接口的迁移：从对编译器说话，到对模型说话；从语法错误，到意图歧义。工具的价值，不在于替你想，而在于降低「意图—契约」之间的摩擦。Prompt Studio 在这件事上走得不算激进，却因此格外耐看——MIT 协议，维护者 README 中署名为 Zihan Deng，你 Star 一下、留个 Issue 或 PR，都是对这类「肯把边界写清楚、肯把密钥留在用户侧」的开源作品最真实的支持。若本文对你有用，转载时请保留项目链接；若你发现文中有与最新仓库不符之处，以 GitHub 上的 README 与源码为准，那才是最活的文档。

本文档供 CSDN 等渠道发布时参考，可整段搬运或按个人文风微调；技术细节以仓库现行说明为准。