Phase 3 - 智能与硬件扩展

引入 AI 与 FPGA 云实验能力，形成平台的差异化与技术深度。

⁋ 3.1 - AI 数据采集与基础能力建设

建立面向AI功能的数据采集与基础处理能力，为后续代码纠错、学情分析等功能提供数据基础与接口支撑。

AI 相关数据范围定义

需要明确系统中哪些数据将用于 AI 能力，例如：实验提交内容、提交次数、提交时间、评分结果等。核心工程问题是：避免 “没有数据却想做AI”。需要重点围绕 “学生做实验的过程数据”，而不是泛泛收集日志。

提交数据结构扩展

需要在 Submission 表中扩展字段，例如：提交内容摘要（content_text）、代码类型（language）、是否通过（passed，可选）。核心工程问题是：让数据对 AI “有意义”，而不是只有 file_path 这种不可分析的数据。MVP 阶段可以只支持文本或代码文件。

提交内容解析与文本提取

需要实现基础的文件解析能力，将学生上传的文件（如代码文件、文本）转化为可分析的文本内容（存入数据库或缓存）。核心工程问题是：AI 无法直接处理文件路径，必须有 “文本数据”。可以先支持简单格式（如 .txt / .py / .c）。

行为数据轻量埋点记录

需要记录学生行为数据，例如：提交次数、提交时间间隔、是否临近截止时间提交等。核心工程问题是：为后续学情分析提供数据基础。这些数据可以通过已有字段计算，也可以额外记录。

AI 服务接口预留

需要在 ai-service 中预留接口，例如 /ai/analyze-submission、/ai/suggest-fix。核心工程问题是：让 AI 能力 “模块化”，而不是写死在业务逻辑中。即使初期只是 mock 数据，也要把接口结构搭好。

简单 AI 能力接入

需要接入一个基础 AI 能力（例如调用大模型 API），实现最简单功能：输入提交内容 → 返回简单分析（如 “可能存在语法错误”）。核心工程问题是：打通 “数据 → AI → 返回结果” 的完整链路。这一阶段不追求准确，只追求 “能跑通”。

AI 结果存储与关联

需要将 AI 分析结果与 Submission 关联存储（例如增加 ai_feedback 字段）。核心工程问题是：避免每次都重复调用 AI，同时为后续展示提供数据。

前端 AI 反馈展示最小实现

需要在实验提交页面或提交记录中展示 AI 反馈结果。核心目标是：让 AI 能力 “可见”，而不是只存在后端。展示可以非常简单，例如一段文本提示。

AI 流程联调与验证

需要验证完整流程：提交实验 → 触发AI分析 → 返回结果 → 前端展示。核心工程问题是：确保 AI 能力真正融入业务流程，而不是孤立功能。

⁋ 3.2 - 代码智能纠错系统

基于已有 AI 能力，对学生提交的代码进行自动分析与错误提示，提供基础纠错建议，提升学习辅助能力。

纠错功能范围定义

需要明确纠错系统的能力边界，例如：语法错误提示、简单逻辑问题提示、代码规范建议等。核心工程问题是：避免把问题做成 “自动评测系统”。本阶段不判断 “对不对”，只提示 “可能哪里有问题”。

提交代码识别与语言分类

需要在提交解析阶段识别代码类型（如 C / Python / Java），并在调用 AI 时传入语言信息。核心工程问题是：AI 分析必须有上下文，否则结果质量很差。可以通过文件后缀或简单规则判断语言类型。

构建 AI 纠错提示模板

需要设计标准化 Prompt，例如 “你是一个编程老师，请检查以下代码是否有错误，并给出简要建议……”。核心工程问题是：让 AI 输出稳定、可控，而不是随机回答。这一块决定了最终效果质量。

实现代码纠错接口

需要在 ai 模块中实现接口（如 /ai/code-review），接收代码文本并调用 AI 服务返回分析结果。核心工程问题是：将 AI 能力封装成标准服务接口，供后端业务调用，而不是散落在各处。

纠错结果结构化处理

需要对 AI 返回结果进行简单结构化，例如问题描述、建议修改。核心工程问题是：避免前端只能展示一大段文本，可以做基础分段或标记，提升可读性。

提交后自动触发 AI 分析

需要在学生提交实验后自动触发 AI 分析流程（可以同步或异步）。核心工程问题是：将 AI 功能嵌入业务流程，而不是手动点击才触发。建议 MVP 阶段直接同步执行（简单实现）。

纠错结果存储与版本关联

需要将 AI 分析结果存入 Submission 表（或独立表），并与具体提交记录绑定。核心工程问题是：支持历史记录与多次提交分析，避免覆盖或丢失数据。

前端纠错反馈展示

需要在提交结果页面展示 AI 纠错建议，例如 “可能存在语法错误”、“建议检查变量定义”。核心目标是：让学生 “看得懂、用得上”，而不是一段复杂分析。可以简单分块展示。

手动触发 “再次分析”

可以提供一个按钮，让用户手动重新触发 AI 分析。核心工程问题是：支持用户主动交互，而不是完全自动流程。

纠错系统联调与效果验证

需要验证完整流程：提交代码 → AI分析 → 返回结果 → 前端展示。核心工程问题是：确保整个链路稳定可用，并对不同代码进行测试（正常代码 / 错误代码）。

⁋ 3.3 - 学情分析与个性化推荐

基于学生实验行为与成绩数据，构建基础学习情况分析能力，并提供简单个性化建议，增强平台的教学辅助价值。

学情分析指标定义

需要明确分析的核心指标，例如：提交次数、平均成绩、提交时间分布、是否临近截止时间提交等。核心工程问题是：避免 “有数据但不知道分析什么”。指标应尽量直接从现有数据中获取，而不是新增复杂采集逻辑。

学生维度数据聚合

需要按学生维度对数据进行聚合，例如统计每个学生的提交次数、平均分、完成实验数量等。核心工程问题是：从 “单条记录” 提升到 “整体表现”。可以通过简单 SQL 聚合实现（count / avg / group by）。

行为特征轻量分析计算

需要基于已有数据计算简单行为特征，例如是否经常临近截止时间提交、是否多次重复提交、成绩是否波动较大。核心工程问题是：把 “原始数据” 转化为 “可解释行为”，为后续推荐提供依据。

学情标签生成

需要根据行为特征生成简单标签，例如 “高频提交型”、“拖延型”、“稳定表现型”。核心工程问题是：让分析结果 “可读、可展示”，而不是一堆数字。这一步非常关键，直接影响展示效果。

个性化建议生成

需要基于标签或数据调用 AI 生成简单建议，例如 “你经常在截止前提交，建议提前安排时间”。核心工程问题是：让系统从 “分析” 变成 “有指导意义”。这一块可以复用 3.1 的 AI 接口。

班级层面教师视角统计

需要为教师提供整体统计，例如班级平均分、提交分布、完成率。核心工程问题是：从单个学生扩展到教学整体，帮助教师理解班级情况。

数据可视化展示

需要在前端展示分析结果，例如简单图表（柱状图 / 折线图）或统计卡片。核心目标是：让分析结果直观可理解。不需要复杂图表库，简单实现即可。

学情分析接口设计与实现

需要在后端实现数据分析接口，例如 /analytics/student/{id}、/analytics/course/{id}。核心工程问题是：将分析能力模块化，便于前端调用与扩展。

分析系统联调与验证

需要验证完整流程：数据收集 → 统计分析 → 标签生成 → 建议输出 → 前端展示。核心工程问题是：确保分析结果真实可信且稳定。

⁋ 3.4 - FPGA 云实验服务

构建基础云实验执行能力，支持学生提交硬件代码并在服务器端进行编译或模拟执行，返回结果输出，为后续真实 FPGA 接入提供架构基础。

云实验能力范围定义

需要明确本阶段支持的能力，例如：Verilog / VHDL 代码提交、基础语法检查、简单仿真（或模拟执行）。核心工程问题是：避免直接做真实硬件远程控制系统。MVP 阶段目标是 “代码能在云端跑一次并返回结果”。

实验类型扩展（硬件实验标识）

需要在 Experiment 表中增加实验类型字段，例如：type = software / fpga。核心工程问题是：让系统区分不同实验执行逻辑，为后续云执行流程做分支处理。

FPGA 提交内容结构设计

需要定义 FPGA 实验的提交内容格式，例如 Verilog 代码文件、输入参数。核心工程问题是：让提交数据可以被后端处理，而不是仅存文件路径。建议与 3.1 的文本解析机制复用。

云端执行服务设计

需要在 fpga-service 中实现 “执行服务”，负责接收代码并进行处理（编译 / 模拟）。核心工程问题是：将 “执行逻辑” 从主业务中解耦，形成独立模块，未来可以替换为真实 FPGA。

基础编译 / 仿真能力接入

需要选择一个可行方案，例如使用开源工具（如 Verilog 模拟器）或用脚本模拟执行结果。核心工程问题是：保证系统能返回 “有意义的结果”。如果时间有限，可以先做 “模拟执行”（例如返回固定波形 / 日志）。

执行任务调度与隔离

需要确保每次执行任务是独立的，例如使用 Docker 容器运行代码，避免互相影响。核心工程问题是：防止用户代码影响服务器稳定性。MVP 阶段可以简化为单任务执行，但要有隔离意识。

执行结果结构设计

需要定义执行结果格式，例如编译是否成功、错误信息、输出结果（日志 / 波形描述）。核心工程问题是：统一结果结构，方便前端展示。

提交 → 执行 → 返回结果流程打通

需要在学生提交 FPGA 实验后触发执行流程，并将结果返回并存储。核心工程问题是：建立完整云实验链路，而不是孤立执行功能。

前端执行结果展示

需要在前端展示执行结果，例如编译成功 / 失败、错误提示、简单输出信息。核心目标是：让学生 “看到实验结果”，即使不是完整硬件输出。

云实验流程联调与验证

需要验证完整流程：提交代码 → 云端执行 → 返回结果 → 前端展示。核心工程问题是：确保流程稳定可靠，并测试异常情况（代码错误、执行失败等）。

⁋ 3.5 - AI 与硬件能力前端集成

将 AI 分析能力与云实验能力整合到统一前端体验中，使用户在一个连贯界面中完成提交、分析与实验结果查看，形成完整技术闭环。

AI 能力入口整合

需要将 AI 功能（代码纠错、学习建议）统一整合到 “提交结果” 或 “实验详情” 页面，而不是分散在多个入口。核心工程问题是：避免功能碎片化，用户不知道在哪里使用 AI。建议以 “提交结果页” 为核心入口。

提交结果页面结构重构

需要对提交结果页面进行结构化设计，将以下内容整合展示：提交状态（成功 / 失败）、AI 纠错建议（3.2）、云实验结果（3.4）。核心工程问题是：将多个系统结果统一在一个视图中，避免用户在不同页面来回切换。

AI 纠错结果可视化优化

需要对 AI 返回的纠错结果进行优化展示，例如分块显示问题列表、修改建议。核心工程问题是：提升可读性与理解效率，避免一大段文本影响体验。可以使用卡片或列表结构。

学情分析入口与展示整合

需要在用户个人页面或课程页面中增加 “学习分析” 入口，展示 3.3 的结果（标签 + 建议 + 简单统计）。核心工程问题是：让 AI 分析 “可访问且有价值”，而不是隐藏功能。

FPGA 云实验结果展示优化

需要对云实验结果进行清晰展示，例如编译结果（成功 / 失败）、输出日志、简单结果说明。核心工程问题是：让硬件实验结果 “可理解”，而不是仅返回原始输出。

多能力协同展示设计

需要在同一流程中体现多能力协同，例如：提交代码 → AI提示错误 → 云执行结果 → 学情分析建议。核心工程问题是：让用户感知 “系统很智能”，而不是多个独立功能拼接。

状态与流程反馈优化

需要在前端展示 AI 分析中 / 云执行中 的状态，例如 loading、进度提示等。核心工程问题是：避免用户等待时无反馈，提升交互体验。

能力开关与降级处理

需要考虑当 AI 或云执行不可用时的处理，例如显示 “暂不可用” 或提供基础结果。核心工程问题是：保证系统稳定性，避免因高级功能失败影响整体体验。

前后端集成联调与流程验证

需要验证完整流程：提交 → AI 分析 → 云执行 → 展示 → 学情更新。核心工程问题是：确保所有能力协同工作，而不是单点可用。