MVP 工程手册：在 6 周内交付有用的 0→1 产品

任何小团队都可以复制的实用范围、冲刺和 CI/CD 蓝图。

为什么需要另一个 MVP 指南？

大多数 MVP 失败是因为范围蔓延、脆弱的基础设施或缓慢的反馈循环——而不是缺乏想法。本指南专注于一条最小但可靠的路径，让真实用户快速接触到真实产品，同时有足够的质量关卡来避免重写。

第 0 周：定义"完成"并消除不确定性

• 一句话问题陈述
• 三个主要用例
• 一个成功指标（例如，首次任务完成或首次付款）
• 不可协商项：认证、审计日志、基本可观察性、备份
• 明确搁置的锦上添花功能

成果物：一页 PRD 和简单系统草图（客户端 → API → 数据库 → 第三方）。

第 1-2 周：交付运行骨架

• 代码库：单体仓库或两个（网页/移动 + API）
• 选择无聊、经过验证的技术栈（例如，Next.js/React + Node/Laravel + Postgres）
• 实现：认证、角色、种子数据、功能标志、错误跟踪、健康检查
• 在第 3 天前部署到预发环境

质量关卡：代码检查、核心领域单元测试、预提交钩子、CI 在 10 分钟内完成。

# .github/workflows/ci.yml (示例) name: CI on: [push, pull_request] jobs: build_test: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: actions/setup-node@v4 with: { node-version: '20' } - run: npm ci - run: npm run lint && npm test -- --ci

第 3-4 周：交付薄垂直切片

以用户可见的切片形式交付功能，而非层。

切片模板

1. 小规格（给定/当/则）
2. API 契约 + 正常路径测试
3. UI 状态：空、加载中、错误、成功
4. 遥测：事件 feature_used
5. 文档：CHANGELOG 中 5 行 + 一个简短的 GIF 用于 QA

第 5-6 周：稳定并证明价值

• 为顶级流程添加验收测试
• 对最慢端点进行负载测试（目标 p95 < 500 毫秒）
• 备份 + 恢复演练
• 可观察性仪表板：错误、延迟、注册、首次成功率
• 发布说明 → 试点用户

MVP 基线检查清单

• 带速率限制和安全密码存储的认证
• 授权（最小权限）
• 输入验证和请求大小限制
• 集中式日志记录 + 错误警报
• 每日备份 + 恢复测试
• 用于风险变更的功能标志
• 基本隐私页面 + 条款；收集最少的 PII

不会撒谎的估算

只估算接下来两周。对待办事项使用T 恤尺寸，并在拆分故事后将 S/M/L 转换为小时。只跟踪已完成的故事点来设置下一个冲刺的容量。

关于架构的说明

偏好简单：单一 Postgres、单一 API 服务、单一网页应用。只为真正的瓶颈添加队列或微服务。复杂性每天都会让你付出代价。

待办事项示例（前 6 周）

• 注册/登录、电子邮件验证、密码重置
• 组织 + 角色（所有者、用户）
• 核心对象 CRUD + 搜索
• 导入 CSV（正常路径）
• 事件跟踪 + 简单仪表板
• Stripe 测试支付（如相关）
• 通过功能标志的管理员切换
• 文档：入门 + 常见问题

要测量什么（以及为什么）

• 激活：完成首个核心任务的注册用户百分比
• 延迟 p95：用户感知速度
• 错误率：每 1000 个请求的警报数
• 留存率（周环比）：用户是否回来？

无惧发布

1. 每个 PR 通过 CI
2. 预发环境在合并时自动部署；生产环境需要手动批准和功能标志
3. 回滚计划 = 上一个容器标签 + 数据库迁移回退步骤
4. 发布后审计：主要错误、修复时间、下一步缓解措施

常见陷阱（及出路）

• 无休止的打磨：固定时间盒；交付给 5 个真实用户
• 框架购物：选择你已经了解的框架
• 过早扩展：更多实例无法治愈糟糕的查询——先进行性能分析
• 分析杂烩：只跟踪与成功指标相关的 3 个事件；不要更多

可复制的资源

• OWASP ASVS（基线安全）
• 十二要素应用（运维理智）
• GitHub Actions 市场测试/代码检查操作

\