为什么做这个项目
团队里每个人都在自己的笔记、聊天记录和代码注释里维护 Prompt。结果是：同一个意图存在五六个版本，谁也不知道哪个在用、哪个已过时，新成员入职后只能靠口口相传。
目标使用者是需要频繁与模型协作的小团队。他们不需要一个重型平台，只需要一个能把 Prompt 当成代码资产管理的轻量工具：有版本、有测试、有复用入口。
我是怎么做的
把 Prompt 管理做成一个基于文件系统的工具，而不是数据库应用。每个 Prompt 是一个 Markdown 文件，frontmatter 存元信息，正文存完整 Prompt 内容。这样做的好处是天然支持 Git 版本管理和代码评审。
关键设计：
- 变量占位：用
{{variable}}语法标注可替换变量，运行时注入。变量类型在 frontmatter 声明，工具会校验调用时是否传入匹配的值。 - 快照测试：每个 Prompt 可以绑定一组测试用例（输入 + 期望特征）。修改 Prompt 后跑一次测试，快速发现回归。不做精确断言，因为模型输出本就不确定。
- CLI 优先：所有操作通过命令行完成，不建 Web 界面。团队按工程师习惯工作流集成到现有开发流程中。
结果与收获
团队内部用了两个月后，Prompt 复用率明显提高，新成员上手时间从约一周缩短到两天。版本化让“这个改动谁做的、为什么做”有了可追溯的记录。
限制是：非工程师角色使用门槛较高，需要熟悉命令行和 Git。实践认识是——Prompt 管理的核心矛盾不是工具能力，而是治理习惯。工具能提供结构和约束，但“是否愿意把 Prompt 当成代码维护”是团队文化问题，工具只能降低门槛，不能替代共识。