chat
PoC（Proof of Concept，概念验证阶段）
在你要 从零打造一个 LeetCode 平台 的项目里，PoC（Proof of Concept，概念验证阶段）最核心的目标不是“功能齐全”，而是要证明这个想法能跑通、体验流畅、能让真实用户产生正向反馈。
我们可以把它理解成：
“最小可用力扣”，必须能支撑完整的刷题闭环（从题目 → 编码 → 提交 → 判题 → 得分反馈）。
🧭 一、PoC 阶段的核心目标
目标：验证这四件事是否可行
- 🚀 用户能完整体验一次“刷题闭环”
- 🧠 评测系统性能可接受（秒级反馈）
- 📊 数据结构设计合理，可扩展
- ❤️ 用户感知到“成就感与价值”
换句话说：
不是做全，而是跑通一个核心体验。
🧩 二、PoC 阶段核心能力清单（按优先级排序）
| 模块 | 核心能力 | 核心验证点 | 为什么是 PoC 必须 |
|---|---|---|---|
| 🧱 1️⃣ 题库管理系统 | - 题目基本结构（题干、输入输出、样例） - 分类、难度字段 |
能否以结构化数据保存和读取题目 | 平台的内容基础，没有题库，什么都无法跑 |
| ⚙️ 2️⃣ 在线判题引擎（Judge Server） | - 支持多语言（起步支持 Java/Python） - 沙箱运行（防止恶意代码） - 比对输入输出 - 限制运行时间与内存 |
稳定性 + 性能 + 安全性 | 是平台的“心脏”，必须先证明能跑、能判、不卡死 |
| 💻 3️⃣ 在线代码编辑器 | - 基础代码输入区 + 运行按钮 - 前端与判题系统通信（WebSocket/REST） - 展示结果：通过/失败/错误类型 |
用户交互体验是否顺滑 | 用户的“第一感受”来源 |
| 👤 4️⃣ 用户登录 & 提交记录 | - 用户注册 / 登录 - 保存用户提交历史 - 支持查看每题提交状态 |
是否能跟踪用户行为数据 | 后续成长记录、积分体系的基础 |
| 📈 5️⃣ 提交结果反馈面板 | - 显示执行状态：Accepted / Wrong Answer / Time Limit - 显示耗时、内存、测试详情 |
用户能否感知性能反馈 | 即时反馈 = 用户成就感的来源 |
| 🧩 6️⃣ 基础题目详情页 | - 展示题目描述 + 示例 + 编辑框 + 提交入口 | “解题体验”闭环是否流畅 | 验证整体 UI/UX 是否可用 |
| 🎯 7️⃣ 基础题目列表页 | - 按难度/状态/分类筛选 - 每题显示通过情况 |
是否能浏览并选择题目 | 刷题入口的核心逻辑 |
🧠 三、PoC 阶段可以先不做的功能（延后阶段）
| 模块 | 可延后原因 |
|---|---|
| 题解讨论区 | 内容依赖用户量，初期可直接引导到外部资源（GitHub、博客） |
| 排行榜 / 勋章 / 积分 | 先验证核心体验再做激励体系 |
| 比赛系统 | 需要规模用户和题库支持，PoC 阶段不具备条件 |
| 会员付费 / 企业招聘 | 需形成价值闭环后再考虑商业变现 |
| AI 辅导 / 推荐题单 | 非关键路径，属于差异化提升阶段 |
⚡ 四、PoC 阶段推荐的技术架构（轻量可扩展）
| 层级 | 技术栈建议 | 说明 |
|---|---|---|
| 前端 | Vue 3 + Monaco Editor + Tailwind | 轻量快速实现在线代码编辑与交互 |
| 后端 | Spring Boot / NestJS | 快速搭建 REST API、用户与题库管理 |
| 判题引擎 | 独立服务（Python / Go 实现） | 通过消息队列或 API 调用执行代码沙箱 |
| 沙箱 | Docker / Firejail | 防止恶意代码破坏系统 |
| 数据库 | MySQL | 存储题库、用户、提交记录 |
| 消息通信 | RabbitMQ / Redis Stream（可选） | 异步执行判题任务 |
| 文件存储 | 本地 / MinIO | 保存题目输入输出用例 |
🧱 五、PoC 阶段最小数据库设计示例
1️⃣ users 表
id | username | password | created_at
2️⃣ problems 表
id | title | description | difficulty | tags | input_example | output_example
3️⃣ submissions 表
id | user_id | problem_id | code | language | status | time_ms | memory_kb | created_at
📈 六、PoC 验收标准（可量化）
| 验收点 | 验收方式 | 成功标准 |
|---|---|---|
| 用户能从题目列表进入题目详情 | 手动测试 | 页面加载正常 |
| 用户能输入代码并提交 | UI 测试 | 点击提交后，触发判题任务 |
| 判题系统能返回结果 | 单元测试 + 压力测试 | 单题平均响应 < 3 秒 |
| 用户能查看提交记录 | API 测试 | 正确展示历史数据 |
| 基础性能稳定 | 压测 | 同时 10 用户无异常 |
| 用户首次体验正反馈 | 小范围试用 | 80% 反馈“体验流畅、能用” |
🧩 七、PoC 阶段完成后，你能回答的关键问题
完成 PoC 后，你应能清晰验证以下问题：
| 问题 | 验证意义 |
|---|---|
| 我能完整跑通一次解题体验吗？ | 基本可用性 |
| 判题系统性能是否够快？ | 技术可行性 |
| 数据结构是否支持扩展？ | 可扩展性 |
| 用户是否获得“解题成就感”？ | 产品价值验证 |
| 系统是否安全隔离代码执行？ | 工程安全性 |
🔮 八、总结一句话
PoC 阶段的关键，不是“多”，而是“通”。 通一条完整的刷题链路： 题目 → 编辑代码 → 提交判题 → 反馈结果 → 记录数据。
做到这一点，你就有了「最小可验证力扣」， 后续只需在此基础上堆叠学习体验（题单、积分、讨论区）和职业价值（面试题、竞赛、会员）， 即可逐步演化为完整的力扣生态。
