Orchids / Bud 失败拆解：能把一句话变成应用，为什么还是没成为独立平台

G｜增长系统：第一次生成很容易，第二次发布才算留存

AARRR 拆解

O｜市场机会：用户买的是能上线的结果

三层需求

S｜战略定位：从独立建站入口变成 Figma 的能力资产

时间线

C｜竞品分析：竞争轴是责任链，而不是生成速度

P｜产品设计：从“描述—生成”补齐“验证—负责—退出”

用户真正走过的六步

1. 描述需求。 用户在 dashboard 消息框写下页面、工具或应用的目标。系统需要先追问用户、权限、数据和成功条件，而不是直接扩大任务范围。Orchids FAQ 确认了自然语言创建全栈应用的入口。3
2. 生成项目。 系统生成 Next.js / TypeScript 项目，并按需要接入数据库、认证、第三方 API 或 Stripe。用户需要看到依赖、调用权限、数据流和生成失败的原因。3
3. 验证结果。 测试需要覆盖登录、权限边界、数据删除、支付回调、外部 API 失败和恶意输入。BBC 报道的安全测试表明，拥有代码与设备权限的 Agent 会把生成错误升级成现实影响。5
4. 编辑与版本。 用户需要同时拥有 Visual Edits、代码手动修改、项目历史和版本恢复，并能看见每次模型改动的差异。Orchids FAQ 列出了这些能力，但公开页面没有提供恢复成功率和回滚耗时。3
5. 发布与监控。 自定义域名和 analytics 只能解决入口问题；生产使用还需要错误日志、权限审计、成本告警、健康检查和人工接管按钮。Orchids FAQ 公开了域名与 analytics，日志、审计和接管指标未披露。3
6. 迁移与维护。 用户要带走源代码、数据库、环境变量、域名、部署配置、日志和版本历史。官方停运页将 ZIP、GitHub、Vercel 和 Supabase 分开说明，说明迁移必须按系统组件逐项完成。4

安全应当成为产品承诺

• 权限范围： Agent 能读什么、写什么、调用什么外部服务。
• 变更清单： 哪些文件、数据库表、环境变量和部署设置发生了变化。
• 验证结果： 自动测试覆盖什么，哪些结果由人工确认，哪些风险仍未验证。
• 回滚入口： 用户能否在一次操作中恢复到上一个可用版本。
• 成本上限： 模型调用、重试、托管和人工支持的累计费用。
• 退出包： 源代码、数据、依赖、配置、日志和迁移说明是否能在本地复现。

E｜商业模式：订阅收入要先覆盖“生成之后”的成本

L｜洞察提炼：生成器必须对结果负责

1. 自然语言降低了入口成本，也扩大了交付承诺

2. Agent 权限决定了安全责任的上限

3. 代码可导出，系统才可能退出

4. 平台收编是战略信号，经营证明仍需另找

D｜决策分析：先验证可负责的工作流，再扩大入口

给创始人的测试表

给投资人

1. 要求团队把注册、首次生成、首次发布、第二次发布和 D90 留存放在同一 cohort 表中；“生成项目数”单独列为能力指标。3
2. 把 BBC 报道的安全测试当作尽调问题入口，要求查看权限模型、修复记录、第三方测试和事故响应，而不是把报道直接等同于停运原因。5
3. 把收入拆成订阅、托管、团队协作和增值服务，逐项核对模型调用、云资源、人工支持和退款成本；截至公开材料，相关经营数字均为未披露。
4. 把任何并购或团队加入平台的结果列为战略信号，另设独立阶段门验证留存、复购、迁移和正贡献毛利。1

给采购方

1. 先拿一个低风险内部工具做完整演练，要求供应商展示代码、数据、环境变量、权限、日志和版本历史。
2. 让两名成员共同完成一次需求变更，再故意引入错误，记录谁批准了变更、谁能回滚，以及恢复花了多长时间。
3. 在签约前完成第二云环境迁移；官方停运页展示的 ZIP、GitHub、Vercel 和 Supabase 路径可以作为迁移清单的起点。4
4. 将模型重试、托管、数据库、人工接管和安全响应写入总拥有成本，而不是只比较每月订阅价格。

90 天验证计划

• 第 1—30 天： 选择一个固定场景，锁定用户、权限、数据、成功条件和迁移目标；完成 20 个任务的首次发布基线。
• 第 31—60 天： 让同一批用户完成第二次发布和一次故障回滚；记录模型改动、人工接管、权限告警、失败原因和每次任务成本。
• 第 61—90 天： 在第二个环境重建项目，比较迁移前后的功能、数据和观测能力；同时核算收入减去模型、托管、支持与安全成本后的贡献毛利。