软件开发计划书
1. 文档说明
- 文档名称：AUBB（Academic Unified Builder Bench）软件开发计划书
- 版本：v2.0
- 状态：计划阶段提交稿
- 适用阶段：课程大作业计划阶段
- 编制依据：课程大作业要求、AUBB（Academic Unified Builder Bench）选题说明、现有项目文档结构
2. 项目背景与编制目的
2.1 项目背景
本项目选题为 AUBB（Academic Unified Builder Bench）。系统面向教师和学生，目标是在统一平台内完成课程组织、作业与实验发布、学生提交、自动评测、教师批改和成绩统计等教学活动。课程要求最终交付的不只是可运行系统，还包括能够连续反映分析、设计、实现和验收过程的正式文档，因此项目计划必须同时约束系统范围和文档边界。
2.2 编制目的
本计划书用于解决三个问题：
- 明确本期必须完成的能力范围，避免在需求分析和实现阶段持续扩张目标。
- 给后续需求、设计、测试、部署和用户手册提供统一口径，确保各文档围绕同一条教学主链路展开。
- 建立阶段出口、质量基线和风险应对规则，使后续工作可以按“是否满足条件”判断，而不是按口头约定推进。
3. 项目目标
3.1 交付目标
本项目的交付目标是形成一个可演示、可部署、可答辩的 AUBB（Academic Unified Builder Bench）平台。系统需围绕教学主链路完成闭环，保证教师能够完成课程组织和作业管理，学生能够完成课程参与和提交，系统能够返回评测结果，教师能够给出批改结论并查看成绩统计结果。
为支撑最终展示，交付版本至少应满足以下要求：
- 教师和学生两类用户能够进入各自可见的功能入口。
- 教师能够完成课程创建、课程维护、作业或实验发布。
- 学生能够加入课程、查看任务要求并完成提交。
- 系统能够对提交结果进行自动处理并反馈可读结论。
- 教师能够查看提交记录、补充批改结果并查看成绩汇总。
- 系统能够在演示环境中稳定运行，并支持按固定脚本完成演示。
3.2 文档目标
本计划书不仅约束交付范围，还约束后续文档应回答的问题。各类正式文档至少需要继承本计划书中的如下内容：
| 后续文档 | 需要承接的内容 |
|---|---|
| 软件需求规格说明书 | 角色边界、核心需求清单、用户场景、验收口径 |
| 软件概要设计说明书 | 模块边界、系统主流程、接口总览、数据流向 |
| 软件详细设计说明书 | 关键对象状态、接口规则、异常处理、页面与数据细节 |
| 测试报告 | 核心需求对应的测试项、主链路回归结果、演示流程验证结果 |
| 部署文档 | 演示环境所需组件、部署步骤、运行检查项 |
| 用户手册 | 教师端和学生端的典型操作路径与常见问题处理 |
后续文档可以增加细节，但不得偏离本计划书确定的基础范围、边界和阶段出口。
4. 项目范围与边界
4.1 基础交付范围
本期基础交付只围绕教学主链路展开。以下能力属于正式承诺范围，后续需求、设计、实现和测试都必须覆盖。
| 能力 | 本期范围 | 最低完成标准 |
|---|---|---|
| 登录与鉴权 | 支持教师、学生登录和退出；基于身份限制页面与接口访问 | 两类用户能够进入各自功能入口，未授权访问会被拦截 |
| 课程管理 | 教师创建、编辑、查看课程；学生加入课程并查看课程内容 | 能完成“建课/加入课程/查看课程内容”完整流程 |
| 作业与实验发布 | 教师发布作业或实验，填写任务说明和提交要求 | 学生能在课程内看到已发布任务并理解提交要求 |
| 学生提交 | 学生提交作业或实验结果，系统保存提交记录 | 每次提交都有可查询记录，教师能看到提交详情 |
| 自动评测 | 系统对提交结果进行自动处理并给出反馈 | 学生提交后能得到明确结果，教师能查看评测结论 |
| 教师批改 | 教师查看提交结果并补充批改意见或调整评分 | 教师能够形成最终批改结果并反馈给学生 |
| 成绩统计 | 汇总课程内作业或实验结果，支持教师查看成绩结果 | 教师能查看课程成绩汇总，学生能查看自己的结果 |
4.2 增强与加分候选
下列内容不是基础交付承诺，只能在教学主链路稳定、演示流程完整、正式文档已形成闭环的前提下纳入：
| 候选项 | 可纳入的前提 | 纳入后的定位 |
|---|---|---|
| 通知中心 | 主链路全部可用，且通知不会引入新的关键阻塞 | 作为任务发布、评测完成、成绩发布的辅助提醒 |
| 课程资源管理增强 | 课程、作业、提交流程已稳定 | 提升课程材料组织能力，不改变主链路 |
| 管理员仪表盘 | 基础数据已稳定可展示 | 作为加分项中的可观测性展示 |
| AI 助教或智能答疑 | 基础业务正确可演示，且新增能力不影响答辩主流程 | 作为基于 Agent 的扩展功能 |
| Skills 沉淀 | 已实际使用大模型参与文档或开发工作 | 作为大模型辅助开发的补充材料 |
| UI/UX 优化 | 不改变业务流程和数据规则 | 作为界面一致性和展示效果提升项 |
增强项一旦决定纳入，必须同步补齐对应需求说明、设计说明、测试证据和演示路径；如果无法补齐，仍按“未纳入正式范围”处理。
4.3 明确排除范围
以下内容不纳入本期正式交付范围：
- 真实支付、真实计费或商业化结算能力
- 面向大规模用户的高并发容量设计与压测结论
- 完整的多端同步上线能力
- 复杂运营后台、开放平台和第三方生态集成
- 与课程答辩主链路无直接关系的功能堆叠
5. 开发原则与推进策略
5.1 开发原则
- 主链路优先：任何新增内容只有在不影响“课程管理到成绩统计”闭环的前提下才可进入实现范围。
- 文档同步：范围、流程、接口或关键规则发生变化时，相关文档必须同步更新，禁止长期保留与实现不一致的描述。
- 需求可追溯：每个核心能力都必须同时落实到页面入口、接口支撑、数据落点、测试证据和答辩演示路径。
- 最小可行实现：复杂能力先完成能够支撑教学场景和演示的最小方案，不预先扩展超出当前需求边界的能力。
- 稳定性优先：加分项、展示项和优化项不得挤占基础能力的修复、联调和验收准备时间。
- 演示可复现：交付结果必须能够通过固定环境、固定数据和固定操作路径重复演示，不能依赖临场解释补足缺失能力。
5.2 推进策略
项目推进采用“先收口范围，再冻结需求，再形成设计，再打通实现，最后准备验收”的顺序。各阶段输出必须能够直接成为下一阶段输入，避免出现计划书无法支撑需求、需求无法支撑设计、设计无法支撑实现的问题。
在实现阶段，优先保证以下链路完整：
- 教师登录并进入课程管理入口。
- 教师创建课程并发布作业或实验。
- 学生加入课程并查看任务要求。
- 学生完成提交并收到自动处理结果。
- 教师查看提交结果并补充批改。
- 教师查看成绩汇总，学生查看个人结果。
只要上述链路中任一关键节点尚不稳定，增强项均不进入正式实现范围。
6. 工作分解与阶段出口
6.1 核心工作包
| 工作包 | 主要内容 | 完成判定 |
|---|---|---|
| W1 计划基线 | 明确范围、边界、原则、风险和阶段出口 | 计划书能够独立约束后续文档和实现 |
| W2 需求规格 | 明确核心需求、用户场景、验收标准 | 每项核心需求都有可验证描述 |
| W3 设计说明 | 明确模块关系、接口总览、关键流程和数据对象 | 设计内容足以指导实现，不依赖口头补充 |
| W4 主链路实现 | 完成登录、课程、任务、提交、评测、批改、成绩能力 | 教学主链路可运行并可重复演示 |
| W5 联调与验证 | 对主链路进行联调、回归、演示验证 | 关键流程稳定，无阻塞性问题 |
| W6 验收材料 | 形成测试报告、部署文档、用户手册和演示材料 | 验收材料与实际交付系统一致 |
| W7 增强候选 | 对增强项进行条件评估、实现和补充说明 | 仅在不影响基础交付时进入正式范围 |
6.2 阶段目标与出口条件
| 阶段 | 阶段目标 | 主要输出 | 进入下一阶段条件 |
|---|---|---|---|
| 计划阶段 | 收口本期范围，明确边界、原则和风险 | 软件开发计划书 | 基础范围、排除范围、阶段出口和风险应对均已明确，后续文档可据此展开 |
| 需求阶段 | 固定核心需求、用户场景和验收口径 | 软件需求规格说明书 | 每项核心需求均有场景说明、边界说明和验收标准，且未超出计划范围 |
| 设计阶段 | 把需求转换为可实现的模块、接口和流程方案 | 软件概要设计说明书、软件详细设计说明书 | 关键流程、模块边界、接口规则、状态变化和异常处理已能指导编码 |
| 实现与联调阶段 | 打通教学主链路并验证可演示性 | 可运行系统版本、联调记录 | 主链路全部可操作，核心页面、接口和数据结果一致，演示脚本可复现 |
| 验收准备阶段 | 形成最终交付材料并完成展示准备 | 测试报告、部署文档、用户手册、演示材料 | 文档、系统和演示内容一致，部署流程可重复，用户操作路径清晰 |
7. 质量保证与配置管理
7.1 质量保证要求
项目质量控制以“能否证明核心需求已落地”为判断标准。至少执行以下检查规则：
- 需求追踪检查：每项核心需求都必须能对应到用户场景、页面入口、接口、数据记录、测试项和演示步骤。
- 变更一致性检查：范围、接口、流程、数据结构发生变化时，相关文档必须同步修订，不能只改其一。
- 主链路回归检查：涉及登录、课程、任务、提交、评测、批改、成绩的变更，合入前必须重新检查主链路是否被破坏。
- 演示准备检查：演示账号、演示数据、演示环境和演示步骤必须提前验证，避免展示时依赖人工补解释。
- 验收材料检查：测试报告、部署文档和用户手册中的描述必须能在实际系统中找到对应依据。
7.2 配置管理要求
- 分支规范：稳定版本保留在
main，集成开发保留在dev，新增内容使用feature/*，缺陷修复使用fix/*。 - 提交规范：提交信息采用
type: summary格式，要求能直接说明本次修改内容。 - 版本标记：能够形成稳定演示或正式交付的版本应打标签保存，以便回溯。
- 文档管理：正式文档在仓库 Markdown 与 VitePress 站点中保持一致；文档结构变更时需同步更新
SUMMARY.md并验证构建结果。 - 变更记录：影响范围、接口、流程或验收口径的修改，应在对应文档中留下可追踪的版本更新信息。
8. 风险管理
| 风险 | 触发情形 | 应对策略 |
|---|---|---|
| 核心需求边界不清导致返工 | 需求阶段同时讨论过多扩展功能，或不同文档对基础范围理解不一致 | 以本计划书的基础交付范围为准收口需求；新增内容先判断是否属于增强候选，再决定是否进入正式范围 |
| 自动评测和实验能力复杂度过高 | 评测流程、运行环境或结果展示无法在当前范围内稳定落地 | 先实现可支撑教学演示的最小评测闭环，把复杂扩展能力后置，不把未验证方案写入正式承诺 |
| 文档与实现脱节 | 接口、流程或对象已经变化，但需求、设计、测试文档未同步更新 | 将文档同步作为变更的必要动作；凡是影响主链路的修改，都要同步检查相关文档 |
| 演示环境不稳定 | 演示环境与开发环境差异过大，部署步骤不完整，演示数据不可复现 | 提前固化演示环境、演示数据和操作路径，并通过部署文档验证从零启动流程 |
| 过早投入加分项影响基本项 | 在主链路尚未稳定时开始实现仪表盘、AI 助教或界面大改 | 以“主链路稳定、文档闭环、演示可复现”作为增强项准入条件，不满足条件时不启动 |
| 大模型生成内容未经核查 | 直接采用生成的文档或实现内容，未与项目范围和真实系统核对 | 对大模型产出执行人工复核，只保留经检查且能解释其依据的内容，并单独维护使用说明材料 |
9. 验收与交付要求
9.1 核心需求验收要求
核心需求的验收以“是否形成可证明的闭环”为标准。每项核心需求至少应具备以下证据：
- 一个明确的用户场景
- 一个可进入的页面或操作入口
- 一组支撑该能力的接口或处理流程
- 一份可追踪的数据结果或状态变化
- 一项对应测试或回归结论
- 一段可用于答辩展示的演示路径
9.2 系统交付要求
- 系统必须支撑教师和学生完成教学主链路操作，不能只展示静态页面或孤立功能。
- 交付结果必须能够在演示环境中稳定运行，关键流程与演示材料保持一致。
- 系统应支持小规模演示场景下的连续操作，不出现明显阻塞性错误。
9.3 文档交付要求
- 计划书、需求、设计、测试、部署和用户手册之间必须保持连续关系，前一阶段文档能为后一阶段文档提供直接依据。
- 文档内容必须与实际交付系统一致，不能保留无法落地或未实现的正式承诺。
- 每份正式文档都应围绕本计划书定义的范围、边界和验收口径展开，不单独扩展新的基础交付范围。
9.4 大模型使用说明要求
如项目在文档编写、设计分析、编码或测试过程中使用大模型相关工具，应单独维护使用说明文件，说明使用场景、人工复核方式以及保留下来的 Session、Skill 等材料。本计划书只规定该材料需要独立存在，不在正文中展开具体过程。