diff --git a/README.md b/README.md
index 58590fd..5961b9b 100644
--- a/README.md
+++ b/README.md
@@ -1,2 +1,6 @@
 # mine_ctf
 
+## Docs
+
+- [CTF Platform Plan](docs/ctf-platform-plan.md)
+
diff --git a/docs/ctf-platform-plan.md b/docs/ctf-platform-plan.md
new file mode 100644
index 0000000..92c3f5f
--- /dev/null
+++ b/docs/ctf-platform-plan.md
@@ -0,0 +1,474 @@
+# 学 / 练 / 考一体化 CTF 平台规划文档
+
+## 1. 文档目的
+
+本文档用于规划一套基于现有开源项目二次开发的 CTF 平台，目标是支持：
+
+- 学：课程化学习、知识点引导、实验闯关
+- 练：日常刷题、专题训练、战队训练、靶场实操
+- 考：正式考试、分班分组、限时考核、成绩导出
+
+规划重点不是“从零重写一个 CTF 平台”，而是“基于成熟开源项目快速搭建可持续演进的平台”。
+
+## 2. 建设目标
+
+### 2.1 总目标
+
+建设一套统一账号、统一题库、统一成绩、统一运维的 CTF 平台，让同一批题目可以在不同场景下复用：
+
+- 在学习场景中作为带引导的实验题
+- 在训练场景中作为刷题题或战队训练题
+- 在考试场景中作为正式考核题
+
+### 2.2 业务目标
+
+- 降低办赛、带队训练、组织考核的重复配置成本
+- 让题库从“赛事型资产”升级为“教学型资产”
+- 让用户成长路径可追踪：学过什么、练过什么、考得怎样
+- 让平台可以支持学校、培训营、企业内训三类典型场景
+
+### 2.3 非目标
+
+首期不建议把范围做得过大，以下内容建议暂不作为一期硬目标：
+
+- 完整 LMS 能力（长视频直播、作业批改、论坛社区）
+- 远程 AI 监考
+- 全量攻防演练平台
+- 完整 OJ / 编程题平台
+
+## 3. 现有开源项目选型判断
+
+### 3.1 结论先行
+
+推荐路线：
+
+- 以 `GZCTF` 作为题目运行与比赛引擎
+- 以自研“门户层 / 教学层 / 考试层”补齐学练考一体化能力
+- 课程编排、模块化学习路径可借鉴 `pwn.college dojo` 的组织方式
+- `CTFd` 适合作为备选方案，尤其适合 Python 团队或轻量活动场景
+
+### 3.2 选型对比
+
+| 项目 | 更适合做什么 | 优势 | 短板 | 结论 |
+| --- | --- | --- | --- | --- |
+| GZCTF | 比赛引擎、容器题运行、动态环境 | 原生支持 Docker / K8s、动态容器、动态 Flag、动态分值、分组与写作收集，偏实战赛事 | 学习路径、课程编排、考试流程管理仍需补齐；二开需考虑其授权与品牌要求 | 作为底座优先 |
+| CTFd | 轻量比赛平台、插件式扩展、主题定制 | 社区成熟、插件和主题机制完善、动态分值 / Hint / Unlock 链路成熟 | 容器题与隔离环境能力通常要依赖插件或外围系统，自带“学练考一体”能力不足 | 作为备选 |
+| pwn.college dojo | 学习编排与课程组织参考 | 课程 / 模块 / 挑战的组织模型清晰，适合“学”的层面借鉴 | 系统复杂，直接作为底座成本较高 | 作为设计参考，不建议直接做底座 |
+
+### 3.3 为什么更推荐 GZCTF
+
+对于“学、练、考一体”平台，最难的往往不是前台页面，而是下面这些底层能力：
+
+- 容器题的生命周期管理
+- 动态 Flag 和题目隔离
+- 并发下的稳定性
+- 比赛中的监控、日志、排行榜
+- 后续向靶场 / 实验环境扩展的空间
+
+GZCTF 在这些方面更贴近目标平台的核心诉求。如果后面考试和训练都需要大量 Web / Pwn / Misc 实验环境，GZCTF 更容易成为长期底座。
+
+### 3.4 选型注意事项
+
+- `GZCTF` 的官方资料显示其核心基于 AGPLv3，同时存在受限组件与商标要求，二开前要先确认对外部署方式、代码开放义务、品牌展示要求。
+- `CTFd` 为 Apache-2.0，更宽松，但平台核心能力更偏“赛事壳子 + 插件扩展”。
+- 如果团队主力是 Python，且一期重点是“题库管理 + 课程引导 + 轻考试”，CTFd 可更快起步。
+- 如果团队需要中长期支撑容器题、实训、校赛、结课考核，GZCTF 更值得投入。
+
+## 4. 产品定位与场景设计
+
+### 4.1 平台定位
+
+目标平台不是单纯办赛平台，而是“安全实训操作系统”，至少覆盖三类场景：
+
+1. 课程学习
+2. 日常训练
+3. 正式考核
+
+### 4.2 三大模式定义
+
+#### 学
+
+面向初学者与课程学习过程，强调引导和路径：
+
+- 按方向组织课程：Web、Pwn、Crypto、Reverse、Misc、AWD 基础等
+- 按模块组织知识点：基础、进阶、专题、综合
+- 每个模块绑定题目、附件、题解、讲义、视频或外链资料
+- 支持前置依赖与解锁规则
+- 支持练习记录、学习进度、掌握度统计
+
+#### 练
+
+面向平时训练和战队培养，强调自由度和强反馈：
+
+- 公开练习场
+- 专题训练营
+- 限时训练赛
+- 班级 / 战队内部排行榜
+- 靶机或容器环境一键启动、重置、续期
+
+#### 考
+
+面向正式考试和结业考核，强调过程可控与结果可审计：
+
+- 题单 / 试卷编排
+- 限时开放、迟到策略、交卷策略
+- 分班 / 分组 / 分考场
+- 随机抽题或 A/B 卷
+- 成绩冻结、申诉复核、成绩导出
+- 操作日志、提交记录、异常行为审计
+
+### 4.3 统一设计原则
+
+同一题目应当只维护一份“主数据”，在不同场景下用不同策略发布：
+
+- 学习模式：可见提示、可见知识点、可见题解、可多次重置
+- 训练模式：弱提示、开放时间长、强调排行榜与环境可用性
+- 考试模式：严格限制提示、限制可见性、强调审计与防泄题
+
+## 5. 核心能力规划
+
+### 5.1 统一账号与组织体系
+
+- 用户账号
+- 班级 / 训练营 / 战队 / 学院组织
+- 角色权限：学生、教练、讲师、命题人、管理员、考务
+- 单点登录预留：学校统一认证、企业 AD / OAuth
+
+### 5.2 统一题库
+
+每道题建议维护以下元数据：
+
+- 题目名称、方向、难度、标签
+- 题目类型：附件题、静态容器题、动态容器题
+- 知识点、前置知识、学习目标
+- 场景属性：可学习、可训练、可考试
+- 预计用时、建议人群、题解开放策略
+- 附件、容器镜像、Flag 策略、环境依赖
+- 风险等级：是否容易泄题、是否需独立环境、是否适合考试
+
+### 5.3 学习中心
+
+- 课程树 / 模块树
+- 学习路径解锁
+- 讲义 / 视频 / 外链资料挂载
+- 分步提示与题解控制
+- 学习进度、完成率、掌握度看板
+
+### 5.4 训练中心
+
+- 自由刷题
+- 专题闯关
+- 周赛 / 月赛 / 内部选拔赛
+- 战队协作模式
+- 环境重置、限时续期、实例回收
+
+### 5.5 考试中心
+
+- 题库抽题
+- 固定题单组卷
+- 分班分卷
+- 防串题策略
+- 审计日志与导出
+- 成绩单、班级统计、知识点维度分析
+
+### 5.6 内容运营与运维中心
+
+- 题目导入导出
+- 镜像构建与发布
+- 附件管理
+- 公告、通知、活动配置
+- 平台监控、容器监控、告警
+- 比赛 / 考试结束后的归档与复盘
+
+## 6. 推荐总体架构
+
+### 6.1 架构原则
+
+- 核心运行能力复用开源项目
+- 业务编排能力自研
+- 题目主数据与运行实例分离
+- 平台门户与比赛内核解耦
+
+### 6.2 分层架构
+
+```mermaid
+flowchart LR
+    A[统一门户 Frontend] --> B[业务中台 API]
+    B --> C[学习服务]
+    B --> D[训练服务]
+    B --> E[考试服务]
+    B --> F[用户与组织服务]
+    C --> G[统一题库服务]
+    D --> G
+    E --> G
+    D --> H[GZCTF 比赛/环境引擎]
+    E --> H
+    G --> H
+    B --> I[统计分析服务]
+    H --> J[(PostgreSQL/Redis/Object Storage)]
+    B --> J
+    H --> K[Docker / K8s]
+```
+
+### 6.3 模块拆分建议
+
+建议拆成两大域：
+
+#### A. 平台业务域
+
+- 门户前端
+- 账号与组织
+- 课程与学习路径
+- 训练计划
+- 考试编排
+- 数据分析
+
+#### B. 题目运行域
+
+- 比赛 / 练习实例
+- 动态容器
+- Flag 校验
+- 排行榜
+- 提交记录
+- 环境监控
+
+这样做的好处是：以后即使底层引擎从 GZCTF 调整为别的方案，平台层仍可保留。
+
+## 7. 一期建议范围（MVP）
+
+### 7.1 一期目标
+
+先验证“统一题库 + 训练 + 考试”能跑通，再补“课程化学习”。
+
+原因：
+
+- 训练和考试更接近 GZCTF / CTFd 的现有能力，落地更快
+- 学习中心需要更多内容运营和教学设计，见效略慢
+- 先把题库、环境、权限、成绩这些硬骨头打通，后续扩展最稳
+
+### 7.2 一期功能清单
+
+- 统一登录
+- 统一题库主数据
+- 题目与 GZCTF 实例映射
+- 公开练习场
+- 限时训练赛
+- 基础考试模式
+- 成绩导出
+- 基础统计报表
+- 题目发布审批流
+
+### 7.3 一期不做或弱化
+
+- 视频课程
+- 复杂学习画像
+- AI 助教
+- 高级反作弊
+- 多校区多租户强隔离
+
+## 8. 二期建议范围
+
+二期再把“学”补齐，形成真正的一体化闭环：
+
+- 课程中心
+- 模块化知识图谱
+- 学习路径解锁
+- 分步提示与题解策略
+- 教师面板
+- 班级画像
+- 训练推荐
+- 题目质量分析
+
+## 9. 三期建议范围
+
+- 多租户 / 多院系隔离
+- SSO 与组织同步
+- 高级防作弊策略
+- 题目工厂与 CI/CD
+- 自动化镜像体检
+- 资源预算与弹性扩缩容
+- 区域化部署与灾备
+
+## 10. 技术实现建议
+
+### 10.1 底座策略
+
+推荐采用“外包内核”思路：
+
+- GZCTF 负责比赛、容器、Flag、提交、排行等运行时能力
+- 自研业务服务负责课程、训练编排、考试编排、组织、报表
+
+不要一开始就深改 GZCTF 核心代码，优先采用：
+
+- API 集成
+- 主题定制
+- 外挂服务
+- 数据同步
+
+只有在 API 明显不够时，再考虑有边界地修改底层项目。
+
+### 10.2 题目内容流水线
+
+建议从一开始就建立题目标准化流程：
+
+1. 题目源码和附件放在 Git 仓库
+2. 容器题通过 CI 构建镜像
+3. 题目元数据同步到统一题库
+4. 题目按场景发布到学习 / 训练 / 考试
+5. 结束后回收环境并归档数据
+
+### 10.3 部署建议
+
+按阶段划分：
+
+- 本地开发：`Docker Compose`
+- 测试环境：`Docker + 单节点 K3s`
+- 生产环境：`K8s + PostgreSQL + Redis + MinIO + 监控告警`
+
+如果目标规模在校内 100 到 300 人，初期可以从 Docker 起步。
+如果目标是长期平台、公开赛事或多班并发考试，尽早上 K8s 更稳。
+
+### 10.4 数据与审计建议
+
+至少要保留以下数据：
+
+- 用户学习记录
+- 提交记录
+- 题目 solve / fail 数据
+- 环境启动与销毁日志
+- 成绩变更日志
+- 考试过程日志
+
+这些数据决定了后续是否能做：
+
+- 成绩复核
+- 异常行为分析
+- 题目难度校准
+- 学习推荐
+
+## 11. 关键风险与应对
+
+### 11.1 授权与合规风险
+
+风险：
+
+- 直接二开 GZCTF 可能涉及 AGPL、受限组件、商标展示要求
+
+应对：
+
+- 在立项阶段先做开源合规审查
+- 能用 API / 插件方式扩展，就先不深 Fork
+- 对外发布前准备版权说明、源码开放策略和品牌说明
+
+### 11.2 泄题与场景污染风险
+
+风险：
+
+- 同一题同时用于学习、训练、考试，容易泄题
+
+应对：
+
+- 题目增加场景标签与发布策略
+- 题解、Hint、附件按模式隔离
+- 考试题优先使用变体题或同知识点不同载体题
+
+### 11.3 容器资源与并发风险
+
+风险：
+
+- Web / Pwn 动态环境消耗大，考试高峰容易打满机器
+
+应对：
+
+- 题目按资源等级分层
+- 预热热点镜像
+- 配置实例回收策略
+- 提前做压测和限流
+
+### 11.4 内容生产瓶颈
+
+风险：
+
+- 平台搭好了，但课程和题库跟不上
+
+应对：
+
+- 优先做 1 到 2 个方向的精品专题
+- 建立题目模板和审核标准
+- 把命题、讲义、题解形成统一生产规范
+
+## 12. 建议里程碑
+
+### M0：2 周
+
+- 完成开源选型确认
+- 梳理授权与合规边界
+- 跑通 GZCTF 本地 PoC
+- 明确统一题库的数据模型
+
+### M1：4 到 6 周
+
+- 完成统一登录
+- 完成题库后台
+- 完成练习场 MVP
+- 打通题目发布与实例启动
+
+### M2：4 到 6 周
+
+- 完成训练赛模式
+- 完成基础考试模式
+- 完成成绩导出和基础报表
+
+### M3：4 到 8 周
+
+- 完成课程中心
+- 完成学习路径与进度跟踪
+- 完成教师 / 教练视角看板
+
+### M4：持续演进
+
+- 多租户
+- SSO
+- 监控告警完善
+- 自动化题目流水线
+- 更完整的数据分析
+
+## 13. 当前建议的落地路径
+
+最务实的落地方案是：
+
+1. 先把 `GZCTF + 统一题库后台 + 练习/考试编排` 做出来
+2. 用最小成本跑通一个真实场景，例如“校队训练营 + 结课考核”
+3. 通过一期积累用户、题目、流程数据
+4. 再把课程学习、知识图谱、推荐系统慢慢补上
+
+这样做比“一开始就做一个特别全的平台”更稳，也更容易真正上线。
+
+## 14. 下一步建议
+
+如果按这个方向继续推进，建议下一份文档直接进入下面三选一：
+
+1. `一期 PRD`：把 MVP 功能拆成页面、角色、流程、字段
+2. `技术架构设计`：把服务划分、数据流、部署拓扑画出来
+3. `题库模型设计`：把课程、题目、训练、考试之间的数据关系先定死
+
+## 15. 参考项目与资料
+
+- GZCTF 官方文档：https://gzctf.gzti.me/
+- GZCTF GitHub：https://github.com/GZTimeWalker/GZCTF
+- CTFd 官方文档：https://docs.ctfd.io/
+- CTFd GitHub：https://github.com/CTFd/CTFd
+- pwn.college dojo：https://github.com/pwncollege/dojo
+- pwn.college example-dojo：https://github.com/pwncollege/example-dojo
+
+## 16. 本文档的推荐决策
+
+如果现在就要拍板，我的建议是：
+
+- 底座选 `GZCTF`
+- 业务层自研
+- 一期先做“练 + 考”
+- 二期再补“学”
+- 题库从第一天起就按“同题多场景复用”设计
+
+这条路线综合了建设速度、长期扩展性和容器题支撑能力，整体风险最低。