01 / Problem
Prompt 工程的"暗债"：改了，但不知道坏了什么
LLM 应用开发团队面临一个隐性的工程债问题：
- Prompt 变更无版本管理：大多数团队把 Prompt 存在数据库字段或飞书文档里，没有 Git 化的版本对比。
- 没有回归测试：修改一个 Prompt 修复了场景 A，可能在场景 B 引入了回退，但没人知道。
- 成本不透明：不同 Prompt 版本对 token 消耗的影响无法量化，优化无从下手。
- 多模型对比困难：换模型前无法客观对比 GPT-4 vs Claude 在具体任务上的质量差异。
"我们改 Prompt 就像在黑暗里摸索开关，每次修改都是一次赌博。"
— 某 AI 创业公司 CTO，GitHub Issue 中
02 / Insight
关键洞察：Prompt 工程需要"代码工程化"的工具链
💡
Prompt 是代码，但我们用管理文档的方式管理它。代码有 Git / CI / Test Coverage，Prompt 什么都没有。这个工具该做的事只有一件：把软件工程的最佳实践搬到 Prompt 领域。
- 测试用例才是核心资产：好的 Eval 集比好的 Prompt 更有长期价值，因为它能驱动所有未来的迭代。
- 评估维度必须与业务指标挂钩：通用的"准确率"没有意义，必须定义"在我们的场景下，什么叫好的回答"。
- PM 需要可读的结果，不是 BLEU score：工程师看指标，但决策者需要"这次改动让用户满意度 +3%"这样的翻译。
03 / PRD Excerpt
PRD 节选：核心 CLI 命令设计
prompt-eval / CLI Design v1.0Open Source
eval run对当前 Prompt 运行完整测试套件，输出各维度评分与 vs 上一版本的 diff
eval compare指定两个版本/两个模型，输出并排对比报告（支持导出 HTML）
eval add交互式添加新测试用例，支持正样本/负样本/边界样本标注
eval cost估算当前 Prompt 在指定流量下的月度 token 成本，支持多模型对比
eval watch监听 Prompt 文件变化，自动运行回归测试（CI/CD 集成友好）
🎯
设计原则：零依赖启动，5分钟上手。不需要向量数据库，不需要注册账号，不需要任何基础设施。
pip install prompt-eval && eval init 然后就能工作——这个决策驱动了 70% 的 Star 增长。04 / Prototype
CLI 输出与 Web Dashboard
terminal · prompt-eval run --compare v1.2..v1.3
Running eval suite: customer_support_v2 (48 cases)...
⚠ 3 regression cases detected. Run `eval diff --regressions` to inspect.
📊 Full report: ./reports/v1.2_vs_v1.3.html
05 / Data
开源增长数据
| 月份 | Stars | Contributors | Issue 关闭率 |
|---|---|---|---|
| 2024.07 (launch) | 47 | 1 | — |
| 2024.09 | 180 | 3 | 71% |
| 2025.01 | 420 | 8 | 84% |
| 2025.05 (Now) | 820 | 12 | 91% |
增长拐点出现在 2024.10，一篇关于"如何量化 Prompt 改动的 ROI"的博客被 Hacker News 转发，带来了 200+ Stars 的单日增量。
06 / Reflection
复盘
✓ What Worked
零依赖是最强的增长杠杆
"5分钟能跑起来"消除了最大的尝试门槛。90% 的 Star 用户是在试用后才 Star 的，不是看了介绍 Star 的。
✓ What Worked
把 PM 视角写进文档
README 用产品思维写，不只讲怎么用，讲"你为什么需要这个"。这让非工程师也能理解价值，转发传播率更高。
⚠ What Didn't
过早支持太多评估维度
v1.0 有 12 个评估维度，让新用户不知道从哪里开始。v1.2 精简为 4 个核心维度 + 自定义扩展，上手率提升 58%。
⚠ What Didn't
开源维护的时间成本被严重低估
Issue 回复、PR 审核、文档更新每周耗费 8+ 小时。如果重来，会更早建立贡献者指南，更早找 Co-maintainer。