如果你的手也里同时在用好几个 AI 编程工具，现在的麻烦往往不是缺 Prompt。
缺的是收纳这些东西的东西。
同一个 Prompt 改了几版，最后放在哪，过几天就开始记不清。SKILL.md 装了一堆，Claude Code、Cursor、Codex、Windsurf、Gemini CLI 各有各的目录。看见一个好 Skill，想装又不是不想装——真正麻烦的是路径在哪、怎么还需要手动复制过去、以后怎么同步、换台机器之后还要不要重新来一遍。
我做 PromptHub，就是被这些返工一点点逼出来的。这个项目在 GitHub 上已经收获 650+ Star，说明踩过这些坑的小伙伴不止我一个。
到我手头这版，PromptHub 已经迭代到 0.4.7。最早想收的只是 Prompt，后来越做越发现：真正开始失控的，不是某一句提示词，而是 Prompt、Skill、平台目录、安装方式、版本维护这一整套资产。
Prompt 太分散，但只是第一层
聊天窗口里一份，备忘录里一份，代码库里再放几份，社交媒体刷到新的又顺手存一份。等到真的要复用时，最常见的状态不是”没有”，而是”明明记得写过，但忘了放在哪”。
这还算好的。更糟的是：
同一个 Prompt 改了好几版，最后只剩下一堆散文件，根本不知道哪一版是最新、哪一版能用。在 Claude Code 里装了个 Skill，过段时间换 Cursor，又想装同一个，才发现根本找不到原文件在哪。再换一台机器，想把这套东西迁移过去，光是”哪些要迁移””怎么迁移””迁移之后还能不能用”这些问题，就够折腾半天。
但问题还会往前走：
-
• Prompt 不只要存，还会反复改版本 -
• 有些 Prompt 不是一段死文本，而是有变量、有模板、有上下文槽位 -
• SKILL.md开始变成长期资产，不再只是临时试验文件 -
• 不同 AI 工具各有各的 skills 目录，迁移和分发越来越费劲 -
• 同一个 Skill 装进不同平台后，后续维护也会变得零碎
乱掉的其实不是一句提示词，而是围着它长出来的整套东西。
我后来越来越明确地意识到，真正需要被收起来的，是 Prompt、Skill、目录、安装和版本一起构成的这层资产管理。
PromptHub 不只是收藏夹，更是工作台
如果只把 PromptHub 理解成 Prompt 管理器，其实也没什么问题，这是最基础的功能：
-
• 管理 Prompt 的标题、描述、正文和分类 -
• 支持变量模板，把一份 Prompt 变成可复用模板 -
• 保留历史版本，方便对比和回滚 -
• 做搜索、收藏和不同视图切换
但事情还是没有结束。
因为当工作流开始往 Claude Code、Cursor、Codex、Windsurf、Gemini CLI 这些工具里延伸时，Prompt 已经不再是唯一资产了。SKILL.md 也开始变成资产，而且它比 Prompt 更麻烦。
Prompt 放在本地，最多是不好找。Skill 放在本地，如果没有一套像样的管理方式，很快就会变成另一种更难收拾的混乱：目录散、来源散、版本散、平台散。
所以 PromptHub 后来慢慢长成的，不是一个资料夹，而是一个本地优先的 Prompt + Skill 工作台。
Skill 为什么值得单独做一块
在 Claude Code、Cursor、Codex 这些工具的重度使用场景里，Prompt 之外的 Skill 资产会越来越多。
我们会开始沉淀：
-
• 一套特定任务的提示结构 -
• 一组固定的执行边界 -
• 配套的文档、脚本和资源 -
• 某个平台能直接识别和安装的 SKILL.md
这时候它就不像一句输入了，更像一个可迁移的能力包。
如果粗略拆开来看：
-
• Prompt 更像一次输入 -
• MCP 更像工具入口 -
• Skill 更像把指令、边界、资源和工作方式包在一起的可复用单元
Prompt 管理工具能解决的，多半是“怎么存”“怎么搜”“怎么复用”。但一旦对象从 Prompt 变成 Skill，问题就会升级成另一层：
-
• 它装在哪个工具 -
• 它对应哪个 skills 目录 -
• 它来自哪里 -
• 它和本地资源、脚本、说明文件是什么关系 -
• 它更新之后要怎么继续维护
也就是说，真正麻烦的不是写出一个 SKILL.md。真正麻烦的是，它一旦开始在多个工具之间流动，就必须被当成一种长期资产来管理。
这也是 PromptHub 为什么会把 Skill 单独拎出来做，而不是把它继续塞在”Prompt 附件”那个角落里。这不是单纯想多做一个模块，而是 Prompt 管理已经不够承接这种对象了。
PromptHub 管理的是整套资产链路
到现在，PromptHub 已经不只是“存东西”的工具了。它往外补的，基本都是我自己在使用里反复遇到的几层返工：
Prompt 这一层
-
• 本地管理 Prompt -
• 变量模板 -
• 历史版本和版本对比 -
• 搜索、收藏、不同视图
Skill 这一层
-
• 扫描本地已有 Skill -
• 预览 Skill 文件结构 -
• 编辑和查看 Skill 内容 -
• 版本差异对比
分发这一层
-
• Skill 商店 -
• 多平台 skills 目录安装 -
• 复制和软链接两种模式
资产沉淀这一层
-
• 本地存储 -
• 备份和恢复 -
• WebDAV 同步
从结果上看，这套东西更像一张资产台账。不是“我有多少 Prompt”，而是“我现在手里到底有哪些可复用的工作流部件，它们放在哪，装在哪，怎么延续”。
为什么首先做成了本地版
我一直想把这件事做成本地优先，不只是因为技术实现顺手。
更重要的是，Prompt、Skill、知识片段、模板、工作流配置，这些东西本来就带着很强的积累属性。它们不是一次性聊天记录，会越来越像我们的个人资产和工作资产。
对重度使用者来说，如果这些东西默认全飘在外面，心里就不踏实。今天换模型，明天换工具，后天换平台，最后最容易丢的往往不是对话本身，而是那些已经沉淀下来的结构：常用 Prompt、长期 Skill、模板变量、目录关系、版本脉络。
纯云端收藏更适合临时记录，平台内管理更适合单一工具。但只要开始跨目录、跨平台、跨机器迁移，这两条路都会露出短板：资产不在一个地方，版本也不在一个地方。
所以至少在 PromptHub 这条产品线上，我更愿意把它做成这样：
-
• 核心资产优先放本地 -
• 同步能力可以有，但同步是延伸
这也是为什么它后面会补备份、恢复和 WebDAV 这类能力。因为真正需要被保存下来的，不只是文本，而是一整套工作习惯。
不是功能堆叠，而是角色变化
我现在更愿意这样看待它：
一开始我是在收纳 Prompt。后来收纳的是 Prompt 和 Skill。再后来收纳的，是 Prompt、Skill、平台目录、版本和分发方式之间的关系。
当这些东西都开始进入同一个界面里，PromptHub 的角色就已经变了。它不再只是一个“放东西的地方”，更像一个工作台。
这种变化也是为什么它会一路往前迭代。如果只是做收藏夹，功能到一半就差不多封顶了。但如果做的是工作台，后面每往前推一步，都会遇到新的结构问题：安装、同步、版本、来源、迁移、兼容、管理边界。
PromptHub 不是功能列表，是这些问题自己。
适合哪些小伙伴拿去用
PromptHub 不是所有人现在都必须装的一类工具。如果还停在偶尔写两句 Prompt、偶尔试一个模型，很多问题还没有长出来，感觉不会特别明显。
但如果你是下面这类情况，可能已经开始觉得乱了：
-
• 已经长期在用 AI 编程工具 -
• 手里已经积累了一批 Prompt 和 Skill -
• 会在多个平台之间切换 -
• 已经开始在意迁移、维护、同步和资产沉淀
对这些小伙伴来说，最大的变化往往不是”功能多了一个”，而是终于不用每次换工具、换目录、换机器时，再把这一层东西从头理一遍。
如果手头正卡在这一层，可以直接去 GitHub 看看这个项目。我也会继续往下做，添加更多功能。
我还会继续把它往前做
PromptHub 还远没有到头。但走到现在，我对它的定位已经越来越清楚了。
它不是一个“顺手做出来的 Prompt 小工具”，想解决的也不是“让大家多存几句提示词”。我更想把它继续做成一张稳定的本地工作台，把 Prompt、Skill 和多平台工作流里最容易散掉的那层资产收住。
如果这层东西继续往前长，后面迟早会有更多小伙伴遇到同一个问题：
Prompt 不难写。难的是，写出来之后，它怎么和 Skill、目录、安装、版本一起被稳定地收住。
如果一定要给 PromptHub 现在的定位下一个更准确的说法，我更愿意叫它：
一个安全的 Prompt 与 Skill 资产工作台。
