2026 · Web 应用
MT-Prompt 提示词工作台
一个跑在局域网里的 Prompt 管理工具。所有内容存在访问设备的浏览器里，服务端不留数据，换设备靠导出 .prompt 包迁移。
做了什么
一个自部署的 Prompt 工作台，docker compose up -d --build 起来，局域网内浏览器访问就能用。能力围绕日常真的会做的几件事：
- Prompt 库：搜索、按图片/视频/收藏筛选、列表和网格两种视图、详情与编辑。
- 素材管理：给每条 Prompt 挂 PNG、JPEG、WebP、GIF、MP4、WebM。
- 本地生成器：用中文填需求，在浏览器内直接生成中英文两版 Prompt，不需要联网。
- 模板与技能库：模板、Skill、规则都存在当前浏览器的 Vault 里。
.prompt分享包：标准 ZIP 容器，可以只装 Prompt 和关联素材，也可以带上界面设置或整个知识库。
数据放在哪，为什么
所有用户数据——Prompt、素材、模板、Skill、界面设置、Provider 配置——都写在访问设备浏览器的 IndexedDB 里，容器文件系统是只读的，Compose 不声明任何数据卷。服务端只在你明确点击时，作为无状态代理去请求 OpenAI-compatible 的 Provider。
这样换来的好处是重建容器不会丢数据，代价也很直白：没有跨设备同步。每个浏览器配置文件有独立的 Vault，换电脑、换浏览器、清站点数据都不会自动跟过去，迁移得手动导出 .prompt 再导入。这是取舍，不是没做完。
有一条硬规则：.prompt 包永远不包含 Provider 地址、模型、密钥或等价字段。Provider 配置只留在当前浏览器，分享文件时不会连着密钥一起递出去。不过浏览器的站点数据并不等于系统凭据保险箱，公共设备上用完还是该手动清掉 Provider。
工程约束
npm run verify 一条命令跑完单元测试、生产边界测试、类型检查、Web 生产构建和 Chrome E2E。GitHub Actions 在 main 推送和 PR 上执行同一套门禁，另外还构建 Docker 镜像并检查容器健康状态——保证「本地能跑」和「容器里能跑」不会悄悄分叉。
仓库里的 database/、storage/、prisma/ 和旧 API 模块是早期版本的遗留，留着做迁移和审计参考，不在当前运行边界内。