问题
用 Flowise 等工具把 AI agent / chatflow 部署到生产的团队，改了 prompt 或流程后没有任何版本管理：没有历史快照、没有归属人、没有 traceability，也没有在打上 production 标签前跑测试的机制，只能盲改盲发。GitHub 上有用户明确提出需要 "A way to version flows, and test new flows before production"。Mistral 推出的 Studio 也把同一问题总结为 prompts 和 skills 缺少 "versioned, owned, and traceable" 的 system of record，说明这是行业级缺口。注意：用户痛感评分为 3（中等），不是火烧眉毛的问题。
目标用户
正在用 Flowise 等可视化编排工具构建并部署 AI agent / chatflow 的中小团队和独立开发者。市场规模有限：目前只有一个中等热度的 GitHub feature request（score 11, 4 条评论）作为直接用户需求证据，属于早期缝隙市场。
解决方案
核心功能：
- 版本快照与 diff：每次修改 flow / prompt 自动存档，可并排对比任意两个版本
- 上线前回归测试：给 flow 配一组测试用例（输入→期望输出），新版本须通过测试才能标记为 production
- 版本化 API 调用：调用方通过 API 指定 flow 版本号，实现灰度和快速回滚
- 归属与追溯：记录每个版本的 owner 和变更原因，形成 audit trail
AI 的角色： 产品本身管理的是 AI 产物（prompt、agent flow），可用 LLM 辅助生成测试用例和 diff 摘要，但核心是工程化的版本控制系统而非生成工具。
为什么是现在
Mistral 在 2026 年推出 Studio，把 prompt 与 skill 的版本化、归属、可追溯作为核心定位，说明头部厂商刚刚开始承认这个缺口；同时 Flowise 用户在 2024 年提出的版本管理需求至今仍是 feature request，两者之间存在独立工具的时间窗口。但需要注意：这是来自 launch 和 feature request 的间接证据，不是直接的用户付费痛点。
MVP 范围
第一版做： 针对 Flowise 这类工具的一个独立版本管理侧车——flow/prompt 快照存档、版本 diff、上线前跑一组回归测试用例、把测试通过的版本标记为 production，并在 API 调用时指定版本号。
明确不做： 不做自己的编排器、不替代 Flowise、不做团队权限和审批流、不做多框架适配（先只支持一个平台）。
风险
竞争风险： Mistral Studio 已把 "versioned, owned, traceable" 作为核心卖点，Flowise 官方 feature request 意味着原工具自己迟早会内建版本管理，届时独立侧车工具的存在空间被压缩。
平台依赖： 作为第三方挂在 Flowise 等工具上，API 变动、官方内建功能都会直接打击产品。
付费不明： 两处信号均无付费意愿，开发者工具市场对这类 "锦上添花" 功能付费习惯弱。
痛感中等： pain 评分仅 3，用户可能长期忍受现状，不做任何采购。
已有产品
信号证据
这张卡片依据的原始讨论。摘录保持原文，点“原文”查看上下文。
Mistral AI News10月2日新品发布
“Studio gives AI prompts & skills a system of record—versioned, owned, and traceable.”
Prompts and skills for AI products lack a system of record for versioning, ownership and traceability.原文
GitHub Issues · FlowiseAI/Flowise7月25日功能请求▲ 114 条评论
“A way to version flows, and test new flows before production.”
Users want a way to version flows, and to test new flows before production.原文