Emergent 教程：从产品简报到可部署全栈 MVP

Emergent 的优势不是把一句想法变成一张漂亮页面，而是把产品简报逐步转成带认证、数据库、业务逻辑、第三方集成和部署的全栈 MVP。要获得稳定结果，关键不是连续追加提示词，而是先收紧范围，再让 Agent 按可验证的阶段工作。

本教程用“客户反馈门户”作为示例：客户登录后提交反馈，团队成员可以分类、更新状态和回复；后续再增加付费团队空间。这个案例覆盖大多数 SaaS 首版都会遇到的角色、数据、权限、通知和部署问题。正式操作前可先阅读 Emergent 评测，了解 credits、GitHub 和生产风险。

第一步：定义一个可以验收的 MVP

不要从“帮我做一个比某某更好的 SaaS”开始。先写清楚：

• 用户是谁：客户、团队成员、管理员。
• 核心问题：客户反馈散落在邮件和聊天工具里。
• 首版必须完成：登录、提交反馈、状态跟踪、团队回复、基础搜索。
• 暂不实现：复杂计费、AI 自动分类、多语言、移动 App、企业 SSO。
• 成功标准：新用户能在五分钟内注册、提交反馈并看到状态变化。
• 风险边界：不用真实客户数据，不连接生产支付，不上传机密文件。

范围越小，越容易判断生成结果是否正确，也越不容易在错误架构上浪费 credits。

第二步：准备产品简报

可以把下面模板作为第一次输入：

Build a responsive full-stack customer feedback portal.

Users:
- Customer: sign up, submit feedback, view status and replies
- Team member: review, tag, change status, and reply
- Admin: manage team members and workspace settings

Core entities:
- User
- Workspace
- Feedback
- Tag
- Reply

MVP flows:
1. Customer creates an account and joins a workspace
2. Customer submits feedback with title, description, and optional category
3. Team member changes status: New, Reviewing, Planned, Completed
4. Customer sees status history and replies
5. Users can search and filter their own workspace data

Constraints:
- Every record belongs to one workspace
- Customers cannot view other customers' private feedback
- Do not build billing yet
- Use test data only
- Include loading, empty, validation, permission-denied, and error states

Before coding, ask questions about ambiguous permissions and data relationships.

第一次提示词应包含实体、角色、关键流程、权限和暂不实现项。视觉描述放在最后，避免界面风格掩盖业务问题。

第三步：先审查规划，不要马上接受生成

当 Emergent 提出澄清问题时，重点确认：

1. 一个用户能否加入多个 workspace。
2. Feedback 是私有、团队可见还是公开路线图。
3. Team member 能否删除客户内容。
4. 状态变化是否需要历史记录。
5. Reply 是否允许客户和团队双向发送。
6. 数据删除后是否需要保留审计信息。
7. 搜索和筛选只在当前 workspace 内生效。
8. 邮件通知首版是真实发送还是仅保留占位。

如果这些问题没有答案，先停在规划阶段。后面再补权限通常比一开始定义清楚更费 credits。

第四步：验证数据模型和权限

至少应看到 User、Workspace、Membership、Feedback、Tag、Reply 或等价结构。不要只使用 User 上的一个 role 字段来代表所有工作区权限，否则同一用户加入多个团队时会失效。

建议的最小关系：

• Workspace 有多个 Membership。
• Membership 连接 User、Workspace 和 workspace role。
• Feedback 必须包含 workspace_id 与 creator_id。
• Reply 必须关联 feedback_id、author_id 和可见范围。
• 状态变化应记录操作者与时间。
• 所有列表和详情查询必须按当前 workspace 过滤。

创建两个工作区、三个不同角色的测试账户，尝试直接修改 URL 或请求参数访问另一工作区数据。只要能看到或修改不属于自己的记录，就不能继续部署。

第五步：把核心流程分批完成

不要同时要求登录、支付、通知、后台和 AI 分类。按以下顺序更稳：

批次 A：认证与工作区

先完成注册、登录、退出、重置密码、创建工作区和邀请成员。检查未登录访问、过期会话、重复邮箱和无权限页面。

批次 B：反馈闭环

实现提交反馈、列表、详情、状态变化和回复。要求每个动作都有成功、加载、空状态、验证错误和服务器错误提示。

批次 C：搜索与筛选

添加状态、标签、创建者和日期筛选。数据量增大时应使用服务端分页，避免一次读取全部记录。

批次 D：通知与运营功能

最后再增加邮件、Webhook、导出和分析。所有外部服务先使用测试凭证，记录失败重试和速率限制。

每完成一批就让 Agent 列出修改文件、测试结果和已知限制，然后同步 GitHub 或保存稳定版本。

第六步：正确处理 Secrets 和第三方集成

连接 Stripe、邮件、OAuth、数据库或外部 API 时：

• 使用环境变量或平台 Secrets，不把 Key 写进提示词和前端代码。
• 区分测试与生产凭证。
• 服务端 Key 不能出现在浏览器包中。
• Webhook 必须验证签名并处理重复事件。
• 数据库使用最小权限账户。
• 记录外部 API 的计费、速率限制、数据保留和商业条款。

如果 Agent 为了演示把 Secret 写进代码，立即撤销并轮换该凭证。不要只删除文件，因为密钥可能已进入历史记录或日志。

第七步：增加支付前先固定授权逻辑

需要订阅时，先定义：

• 谁购买：个人用户还是 workspace。
• 套餐控制哪些功能和容量。
• 试用开始与结束条件。
• 支付失败、取消、退款和恢复订阅后的状态。
• Webhook 重复到达时如何避免重复开通。
• 管理员能否手动调整套餐。
• 前端显示与服务端权限是否一致。

支付页面成功不代表订阅系统正确。必须用测试模式覆盖成功、取消、失败、过期和重复回调，并确认服务端才是最终权限来源。

第八步：建立测试清单

至少验证：

功能

• 注册、登录、退出和找回密码。
• 创建工作区、邀请成员和移除成员。
• 提交、编辑、搜索、筛选反馈。
• 状态变化、回复和通知。
• 管理员与普通用户权限差异。

异常

• 空字段、超长内容和非法文件。
• 重复点击提交。
• 网络中断和接口超时。
• 过期登录与无权限请求。
• 外部 API 失败。
• 数据库返回空值或重复记录。

非功能

• 手机、平板和桌面响应式。
• 键盘操作、焦点和对比度。
• 主要页面加载性能。
• 日志不包含密码、Token 和敏感正文。
• 删除账户和数据导出的处理。

让 Agent 生成测试可以加快覆盖，但关键业务仍要人工运行一遍。

第九步：尽早连接 GitHub

Standard 及以上支持 GitHub。完成认证和第一条核心流程后就同步，不要等项目“完全做好”。

建议做法：

1. 建立初始可运行版本。
2. 每个功能批次单独提交。
3. 为环境变量提供示例名，不提交真实值。
4. 使用分支测试较大修改。
5. 在发布前保留可回滚标签或 commit。
6. 导出数据库结构和迁移说明。
7. 记录平台外恢复应用所需的步骤。

GitHub 只能保存代码，不能自动保存托管数据库、Secrets 和运行时配置，这些要单独备份。

第十步：部署前执行门禁

Emergent 区分首次部署、重新部署和替换部署。发布前：

• 确认正在操作正确的应用和环境。
• 备份生产数据库。
• 检查生产环境变量和回调 URL。
• 确认预览数据不会被误认为生产数据。
• 了解重新部署是否保留数据库与已有 Secrets。
• 了解替换部署是否迁移数据。
• 检查域名、HTTPS、Cookie 和隐私政策。
• 确认当前账户显示的部署 credits 扣费规则。

官方帮助页可能在产品更新后存在说明差异，结算和部署确认页应作为当前依据。

第十一步：控制 credits

• 先规划，再生成。
• 一次只做一个可验收批次。
• 不用“全部重做”修复局部问题。
• 每轮提示词引用具体页面、实体和错误。
• 先让 Agent 解释根因，再批准修改。
• 稳定节点及时提交 GitHub。
• 用测试数据复现问题，避免长篇模糊描述。
• 定期查看 credit usage，超过预算就缩小范围。

免费版适合验证；Standard 通常是私有 MVP 与 GitHub 工作流的起点；Pro 更适合长上下文、复杂 Agent 和高频构建。价格和额度应以 Emergent 官方价格页 为准。

最终上线检查

• 所有角色和 workspace 权限都已测试。
• 无生产密钥出现在代码、提示词或日志中。
• 支付 Webhook 已验证签名与幂等性。
• 数据库有备份、恢复和迁移方案。
• GitHub 中存在可回滚版本。
• 关键流程覆盖成功与失败状态。
• 移动端和无障碍检查通过。
• 第三方代码、字体、图片和 API 许可已核对。
• 隐私政策、数据删除和联系渠道已经准备。
• 当前 credits 与托管成本在预算内。

Emergent 能显著缩短从想法到全栈 MVP 的距离，但最稳的工作流仍然是“明确边界、分批构建、逐步验收、尽早备份、谨慎部署”。