问题：AI 编程工具越用越多，Prompt 和 Skill 怎么管？
同时用好几个 AI 编程工具时，真正的麻烦往往不是「缺 Prompt」，而是缺收纳这些东西的地方。
同一个 Prompt 改了几版，最后放在哪，过几天就开始记不清。SKILL.md 装了一堆，Claude Code、Cursor、Codex、Windsurf、Gemini CLI 各有各的目录。看见一个好 Skill，想装又不是不想装——真正麻烦的是路径在哪、怎么还需要手动复制过去、以后怎么同步、换台机器之后还要不要重新来一遍。
PromptHub 就是被这些返工一点点逼出来的。这个项目在 GitHub 上已经收获 650+ Star，说明踩过这些坑的小伙伴不止一个。
到 0.4.7 版本，PromptHub 已经迭代了很久。最早想收的只是 Prompt，后来越做越发现：真正开始失控的，不是某一句提示词，而是 Prompt、Skill、平台目录、安装方式、版本维护这一整套资产。
Prompt 太分散，但只是第一层
聊天窗口里一份，备忘录里一份，代码库里再放几份，社交媒体刷到新的又顺手存一份。等到真的要复用时，最常见的状态不是「没有」，而是「明明记得写过，但忘了放在哪」。
更糟的是：
- 同一个 Prompt 改了好几版，最后只剩一堆散文件，不知道哪一版是最新、哪一版能用
- 在 Claude Code 里装了个 Skill，过段时间换 Cursor，又想装同一个，才发现根本找不到原文件在哪
- 换一台机器，想把这套东西迁移过去，光是「哪些要迁移」「怎么迁移」「迁移之后还能不能用」就够折腾半天
问题还会往前走：
- Prompt 不只要存，还会反复改版本
- 有些 Prompt 不是一段死文本，而是有变量、有模板、有上下文槽位
- SKILL.md 开始变成长期资产，不再只是临时试验文件
- 不同 AI 工具各有各的 skills 目录，迁移和分发越来越费劲
- 同一个 Skill 装进不同平台后，后续维护也会变得零碎
苏米注：这个问题我深有体会。之前用 Claude Code 和 Cursor 时，同一个 Skill 在两个工具里各有一份，改了一个忘了改另一个，最后根本不知道哪个是最新的。PromptHub 解决的核心问题就是「资产台账」——你知道自己手里到底有哪些可复用的工作流部件，它们放在哪、装在哪、怎么延续。
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 管理的是整套资产链路
到现在，PromptHub 已经不只是「存东西」的工具了。它往外补的，基本都是在使用中反复遇到的几层返工：
Prompt 层
- 本地管理 Prompt
- 变量模板
- 历史版本和版本对比
- 搜索、收藏、不同视图
Skill 层
- 扫描本地已有 Skill
- 预览 Skill 文件结构
- 编辑和查看 Skill 内容
- 版本差异对比
分发层
- Skill 商店
- 多平台 skills 目录安装
- 复制和软链接两种模式
资产沉淀层
- 本地存储
- 备份和恢复
- WebDAV 同步
为什么首先做成了本地版
PromptHub 选择本地优先，不只是因为技术实现顺手。更重要的是，Prompt、Skill、知识片段、模板、工作流配置，这些东西本来就带着很强的积累属性。它们不是一次性聊天记录，会越来越像我们的个人资产和工作资产。
对重度使用者来说，如果这些东西默认全飘在外面，心里就不踏实。今天换模型，明天换工具，后天换平台，最后最容易丢的往往不是对话本身，而是那些已经沉淀下来的结构：常用 Prompt、长期 Skill、模板变量、目录关系、版本脉络。
纯云端收藏更适合临时记录，平台内管理更适合单一工具。但只要开始跨目录、跨平台、跨机器迁移，这两条路都会露出短板：资产不在一个地方，版本也不在一个地方。
所以至少在 PromptHub 这条产品线上，它的设计原则是：
- 核心资产优先放本地
- 同步能力可以有，但同步是延伸
这也是为什么它后面会补备份、恢复和 WebDAV 这类能力。因为真正需要被保存下来的，不只是文本，而是一整套工作习惯。
不是功能堆叠，而是角色变化
一开始收纳的是 Prompt。后来收纳的是 Prompt 和 Skill。再后来收纳的，是 Prompt、Skill、平台目录、版本和分发方式之间的关系。
当这些东西都开始进入同一个界面里，PromptHub 的角色就已经变了。它不再只是一个「放东西的地方」，更像一个工作台。
如果只是做收藏夹，功能到一半就差不多封顶了。但如果做的是工作台，后面每往前推一步，都会遇到新的结构问题：安装、同步、版本、来源、迁移、兼容、管理边界。
苏米注：这个思路值得借鉴。很多工具都是从「小功能」长成了「工作台」，关键在于是否抓住了用户的核心痛点——不是功能多，而是「我能把所有相关的东西放在一个地方管理」。
适合谁用
PromptHub 不是所有人现在都必须装的一类工具。如果还停在偶尔写两句 Prompt、偶尔试一个模型，很多问题还没有长出来，感觉不会特别明显。
但如果你是下面这类情况，可能已经开始觉得乱了：
- 已经长期在用 AI 编程工具
- 手里已经积累了一批 Prompt 和 Skill
- 会在多个平台之间切换
- 已经开始在意迁移、维护、同步和资产沉淀
对这些小伙伴来说，最大的变化往往不是「功能多了一个」，而是终于不用每次换工具、换目录、换机器时，再把这一层东西从头理一遍。