chat
MVP（Minimum Viable Product，最小可行产品）
在我们谈 LeetCode 平台的 MVP（Minimum Viable Product，最小可行产品） 阶段时，目标不是“做完全部功能”，而是能让用户第一次真正体验到这个平台的核心价值 —— 即「在线刷题 + 即时反馈 + 社区交流」。
🎯 一、MVP 阶段的目标
✅ 验证用户愿意在这个平台上刷题、提交代码、得到反馈。 ✅ 验证技术可行性（在线代码执行、判题系统）。 ✅ 建立最小闭环（出题 → 做题 → 提交 → 反馈 → 讨论）。
🧱 二、MVP 阶段的核心能力清单（按优先级排序）
1️⃣ 题目管理与展示（核心内容）
目标：让用户能看到题目、理解题意、开始写代码。 能力点：
- 题目列表（分页、按难度筛选）
- 题目详情页（题目描述、输入输出示例、限制说明）
- 支持 Markdown / 富文本题面展示
🧩 为什么重要： 没有题目内容，平台就没有价值。题目是平台的“内容基石”。
2️⃣ 在线代码编辑与运行环境（核心体验）
目标：用户能写代码并在浏览器中运行。 能力点：
- 支持主流语言（Java、Python、C++ 至少一种）
- 基础代码编辑器（可用 Monaco Editor）
- “运行代码”按钮 + 显示执行结果（stdout、stderr、返回值）
🧩 为什么重要： 这是用户的关键体验点。代码能否运行、是否即时反馈，是留存关键。
3️⃣ 判题系统（最小可行版）
目标：自动验证代码的正确性。 能力点：
- 支持输入/输出对比（标准输入输出）
- 判题沙箱（Docker 隔离或安全执行）
- 支持“通过/失败/运行超时”等基本状态
🧩 为什么重要： 没有自动判题，就无法形成闭环，用户无法获得“反馈成就感”。
4️⃣ 用户系统（最小认证）
目标：能区分不同用户、保存提交记录。 能力点：
- 注册 / 登录（可支持邮箱或 GitHub 登录）
- 基本用户信息（用户名、头像、积分）
- 用户提交历史（题目 + 状态）
🧩 为什么重要： 没有登录体系，无法形成“成长”和“竞争”动力。
5️⃣ 提交记录与运行结果
目标：用户能看到自己代码执行的历史和结果。 能力点：
- 每次提交的状态（Accepted / Wrong Answer）
- 执行耗时 / 内存使用
- 运行日志（部分输出）
🧩 为什么重要： 用户需要“反馈”才能知道自己进步。
6️⃣ 社区讨论区（可选增强）
目标：让用户在题目下交流解法、互助学习。 能力点：
- 每题下方简易讨论区（按时间排序）
- Markdown 支持
- 点赞/回复基础交互
🧩 为什么重要： 讨论是用户粘性来源，但可以 MVP 阶段延后。先验证刷题体验是否足够吸引人。
7️⃣ 管理后台（最小出题能力）
目标：让管理员能上传/修改题目。 能力点：
- 登录后台
- 创建/编辑题目（标题、描述、样例、难度、标签）
- 上传测试用例文件
🧩 为什么重要： 平台要持续提供新题，这决定后续内容供给能力。
⚙️ 三、最小闭环示例
一个完整的用户路径：
登录 → 浏览题目 → 打开题目 → 输入代码 → 运行 → 提交 → 看到结果 → 记录保存。
只要这条路径跑通，LeetCode 的核心价值（练习与反馈） 就成立了。
🧭 四、MVP 成功验证指标
| 维度 | 验证指标 | 意义 |
|---|---|---|
| 用户体验 | 用户能流畅刷完1题 | 基本功能跑通 |
| 留存率 | 用户第二天回来刷题 | 体验有吸引力 |
| 技术稳定性 | 判题执行正确率 > 95% | 沙箱可靠 |
| 成本控制 | 判题单次执行 < 1s | 可扩展性验证 |
🧩 五、MVP 技术选型建议
| 模块 | 技术栈建议 |
|---|---|
| 前端 | Vue / React + Monaco Editor |
| 后端 | Java / Spring Boot |
| 判题 | Docker + 异步任务（如 RabbitMQ + Worker） |
| 数据库 | MySQL（题目、提交、用户） |
| 缓存 | Redis（队列、判题状态） |
