NULL —— 代码规范、冲刺任务与计划

2026-10-24 16:14:21 86 阅读 AI 写同款 · GEO 优化AI 选题数据监测一键分发 ›
NULL101010 NULL101010 墨衍会员 · AI 创作全网分发 墨衍智能分发 通过墨衍一键同步至各平台 可同步平台 CSDN微信公众号微博知乎掘金百家号博客园抖音小红书 你的文章也可以这样分发 墨衍会员 ¥399起/年，写一次发全网 我也要 + 加入社区
美团研发笔试题深度拆解：核心考点与复习方法论 在软件工程领域，数据结构与算法、操作系统、计算机网络和数据库是支撑技术面试的基石。理解这些基础概念的本质原理，不仅有助于解决复杂工程问题，更是技术价值的重要体现。无论是并发编程中的进程线程模型，还是索引结构中的B+树设计，都源于这些底层知识。在实际场景中，大厂笔试面试往往围绕这些高频考点展开，考察候选人的逻辑思维与代码能力。本文以美团2016年研发工程师笔试题为样本，系统梳理笔试背后的出题逻辑，分析数据结构、算法、操作系统、网络等核心模块的复习重点，并给出编程题的解题流程与时间管理策略，帮助读者构建完整的备 阅读详情

NULL 团队——Alpha 冲刺代码规范、任务分工与七天计划（原型对齐版）

软件工程实践 · 团队作业：站立式会议 + Alpha 冲刺
项目：数据结构可视化学习平台（NULL Visual Lab） | 团队：NULL | 2026 年 10 月 23—29 日

一、基本信息

项目内容
课程名称软件工程实践
作业名称团队作业——站立式会议 + Alpha 冲刺
团队名称NULL 团队
项目名称数据结构可视化学习平台（NULL Visual Lab）
团队人数8 人
冲刺阶段Alpha Sprint
冲刺时间2026 年 10 月 23 日—10 月 29 日
作业截止时间2026 年 10 月 29 日 23:59
参考资料《构建之法》《阿里巴巴 Java 开发手册》终极版 v1.3.0、华为云公开代码检查规范相关资料

相关项目与设计基线（未公布的仓库 / Issue 链接发布前填写）：

NULL 团队原型设计 / 需求分析（9页原型）：https://bbs.csdn.net/topics/620552906

本文依据 NULL Visual Lab 原型 v1.0 的 9 个页面、P2 学习主界面三联动、L1–L4 功能边界和既有 8 人职责制定七天 Alpha 冲刺规范与计划。内容与能力分别管理：先稳定 L1 学习闭环；账号/进度（L2）单独排期；闯关积分（L3）保留 Beta 时间盒，避免在 Alpha 冲刺阶段挤占核心开发。

二、项目背景与 Alpha 冲刺目标

2.1 项目背景

NULL 团队正在开发一个面向数据结构学习者的 Web 平台——NULL Visual Lab（数据结构可视化学习平台）。用户通过浏览器即可学习数据结构与算法，不需要安装客户端。

原型设计强调的学习障碍包括“抽象、动态、脱节”三方面：节点、指针、下标不易理解，插入/删除/遍历的动态过程难以脑内模拟，代码行与结构变化经常脱节。NULL Visual Lab 以“代码执行 → 状态变化 → 原因解释”为核心，将三联动学习过程可视化；逐步引入账号进度与闯关积分，形成“学 → 练 → 测”的能力闭环。

平台的主要功能包括：

  1. 数据结构选择（P1）： 首页以数组、链表、栈、队列等结构卡片进入学习；树/图可显示后续内容入口。
  2. 数据输入（P3）： 支持手动输入、随机生成、批量粘贴；数据集导入视实现进度分级交付。
  3. 操作与算法（P4）： 选择插入/删除/查找/遍历等操作并填写参数，由算法引擎生成步骤快照。
  4. 可视化（P2）： 中央画布显示节点、边、指针、下标等，随 StepSnapshot 改变。
  5. 代码同步（P2 左栏）： 当前代码行高亮与中间画布严格同拍。
  6. 步骤解释（P2 右栏 / P7）： 中文解释可对应到帮助和术语表。
  7. 播放控制（P2 底栏）： 播放/暂停、前进、回退、调速、步骤进度条及任意步骤跳转。
  8. 账号与练习（P6/P8/P9）： Alpha 单独推进登录/访客/进度，Beta 推进关卡、积分与排行榜；测试与部署贯穿全程。

2.2 前期工作完成情况

在进入 Alpha 冲刺之前，团队已完成需求分析、系统设计、数据库设计及原型设计（原型 v1.0，2026-10-15），并确定 8 人“主责+副责”分工。本次直接复用已有成果，不重复完整设计。

  • 需求分析： 梳理用户学习需求、系统主要功能及应用场景。
  • 系统设计： 完成系统整体设计及主要模块的职责划分。
  • 数据库设计： 完成项目数据库的前期设计工作。
  • 团队分工： 明确 8 名成员的主要职责、协作接口及验收依据。
  • 协作原则： 确定使用统一的 Step 步骤模型连接算法、动画和教学内容。

这些成果将作为 Alpha 阶段开发的基础。本次冲刺不重新开展完整的需求分析和系统设计，而是将已有设计转化为实际代码，重点完成核心功能开发、模块联调、自动化测试和部署。

对于数据库部分，沿用前期数据库设计。原型明确账号、学习记录与积分记录属于不同能力层：本轮只有 L2 账号与进度需要有限持久化能力（成员8的独立时间盒），L3 积分落在 Beta；不为了复刻 9 个页面而强行开发整个后端系统。

2.3 Alpha 阶段总体目标

本次七天 Alpha 冲刺核心目标：完成原型 P1→P3/P4→P2 的 L1 学习闭环，保证链表插入黄金样例能以 StepSnapshot 驱动“代码高亮—画布变化—中文解释”三联动、可暂停/回退/调速/进度跳转；逐步扩展数组、栈、队列基础操作。并行设立 M4a/L2 账号进度时间盒，优先保证访客模式可完整使用 L1；P9 闯关积分由 Beta（M6a/L3）承担。

项目核心工作链路如下（与原型中的 VisualizationSession、StepSnapshot 术语对应）：

P1 结构选择 → P3 数据输入 + P4 选择操作
    ↓
数据结构模型 / Algorithm Engine（成员5）
    ↓
StepSnapshot 序列（成员1统一字段；成员5生成）
    ↓
VisualizationSession / Step Controller（唯一 stepIndex）
    ↓
P2：代码高亮（左） | 动画画布（中） | 中文解释（右）
    ↓
底部播放、暂停、单步、回退、调速、进度条
    ↓
成员7测试 → 成员8集成部署
    └─ L2：访客可用；登录后保存进度（独立时间盒）

范围采用原型的“内容维度 + 能力维度”双重控制。项目整体 MVP 内容范围为数组/链表/栈/队列，本七天冲刺以链表插入作为最先验收的垂直切片，随后推进其他三种线性结构基础操作；L1 核心能力不可裁剪，L2 与 L3 不得阻塞访客使用。

优先级功能范围完成要求
P0 / L1P1 首页、P2 三栏三联动、P3 基础数据输入、P4 操作面板；链表插入黄金样例七天 Alpha 必须稳定跑通、可回放且可测试
P0 / 工程统一 StepSnapshot/Controller、代码规范、单测/E2E、CI、部署和博客证据不可裁剪；每日形成运行或测试证明
P1 / 内容数组、栈、队列基础算法及可视化（整体 MVP 四种线性结构）黄金样例稳定后按能力扩展；未达标如实列 Backlog
P1 / 页面P5 结构知识卡、P7 帮助/术语表及 P3 随机/批量输入优先实现可见可用的基础版本
L2 / M4aP8 注册/登录/访客模式、P6“我的实验台”学习记录与进度保存独立时间盒；不登录也必须完整使用 L1
L3 / M6aP9 关卡、题目判定、积分记录、徽章、排行榜保留页面原型与接口规划；核心实现留至 Beta
V1 / V2树/BST（V1）；图/哈希表（V2）非本次七天交付门槛，进入后续里程碑

2.4 黄金样例

团队选定链表插入作为首个完整端到端验收样例，以确保原型 P2 三联动与 P3/P4 自定义输入真正可用。

初始链表：

10 → 20 → 40

用户执行操作：在节点 20 后插入节点 30。

预期最终结构：

10 → 20 → 30 → 40

执行过程需要完成：

  1. 查找插入位置。
  2. 创建新节点 30。
  3. 将新节点 30 指向原后继节点 40。
  4. 将节点 20 指向新节点 30。
  5. 更新并展示最终链表状态。

在每一个步骤中，由相同 stepIndex 对应的 StepSnapshot 同时驱动画布结构状态、代码高亮行、中文解释和底部播放进度；前进、回退、拖拽进度条与重新执行均须得到一致结果，且访客无需登录即可操作。

验收标准：不仅最终链表正确，而且 P2 左栏代码、中栏画布、右栏解释及底栏进度必须同步；P3/P4 输入合法、出错有明确中文提示；访客模式无登录墙。

2.5 九个页面的原型基线与本轮交付边界

原型 v1.0 在 2026-10-15 的需求/原型博客中定义 P1–P9 共 9 个页面。页面在原型中存在，并不表示 Alpha 七天必须实现全部后端能力；本轮按“L1 必须 / L2 独立时间盒 / L3 Beta”逐项跟踪。

编号页面原型设计内容七天冲刺目标 / 阶段边界
P1首页 / 结构选择结构卡片、品牌标语、帮助/进度及登录/访客入口Alpha：结构入口与访客入口可用；树/图为后续内容标识
P2学习主界面左代码／中画布／右解释＋底部播放器和进度条Alpha：必须实现链表黄金样例三联动与回退/调速/跳转
P3数据输入面板手动输入、随机生成、批量粘贴、导入数据集Alpha：手动与校验优先；随机/批量按进度；导入分级
P4操作面板插入/删除/查找/遍历；参数、预演提示、错误反馈Alpha：链表插入完整；其他操作随算法扩展
P5结构详情 / 知识卡定义、复杂度、核心要点、常见错误、课程关联Alpha：链表/数组基础知识卡与学习跳转
P6我的实验台历史、回放、收藏、分享；积分与成就汇总Alpha/M4a：记录与进度基础能力；积分区保留占位
P7帮助与术语表使用说明、快捷键、节点/指针等术语解释Alpha：说明、关键术语及返回学习页入口
P8登录 / 注册登录、注册、访客入口、错误反馈及隐私说明Alpha/M4a：与 P1 访客联动，账号能力独立交付
P9闯关模式 / 积分榜关卡地图、答题、解析、得分、徽章、排行榜Beta/M6a：保持原型与接口设计，不作为 Alpha 核心功能

2.6 P2 学习主界面与关键交互契约

P2 严格采用“代码区（左）—可视化画布（中）—步骤解释（右）”的布局，底部设置播放/暂停、前后单步、重播、速度滑块及步骤进度条。P3 输入和 P4 操作可随时重新生成 StepSnapshot 序列。

左栏：代码中栏：画布右栏：解释
CodeSnippet / 当前行高亮；由 codeLineNo 驱动Node / Edge / Pointer / 下标；由 structureState、highlightedNodes 渲染中文 explanation / 术语链接；与当前 stepIndex 一致

交互验收规则：① 三栏使用同一 stepIndex，不允许各自维护独立播放游标；② 控制条可暂停、单步、回退、调速、拖拽跳转；③ P3/P4 修改数据或操作时重新生成序列；④ 错误需中文提示、不静默失败；⑤ 访客可以无障碍完成完整 L1；⑥ 进度与积分功能仅在对应能力阶段启用。

三、团队代码规范

为了提高多人协作效率、降低代码集成成本，并保证项目的可读性、可测试性与可维护性，NULL 团队参考《阿里巴巴 Java 开发手册》终极版 v1.3.0 的相关原则，并借鉴华为云公开代码检查资料中有关编码风格、规则集、静态检查的工程化思路，制定以下团队代码规范。

本项目以 Web 原型为统一目标，实际语言和框架以仓库已确定方案为准，不直接套用其他团队的 Spring Boot / Vue / MyBatis 组合。前端遵循统一格式与分层，若后端采用 Java，则进一步按阿里 Java 规约落实分层、Javadoc、异常与持久化规则。

3.1 规范等级

等级含义处理方式
强制所有成员必须遵守不符合要求的代码原则上不允许合并
推荐原则上应遵守如有特殊原因，需要在 Code Review 中说明
参考根据具体场景选择由模块负责人决定，并保持团队一致性

代码审查重点包括命名是否清晰、结构是否合理、功能是否正确、异常是否处理、是否存在重复逻辑、是否符合公共接口、是否提供测试，以及是否破坏其他模块。

3.2 命名规范

（1）强制使用具有明确语义的名称。 变量、函数、类和文件名应清楚表达其用途，不使用意义不明的缩写。

正确示例：

const currentStepIndex = 0;
const animationSpeed = 1;

function insertLinkedListNode() {
  // ...
}

错误示例：

const a = 0;
const sp = 1;

function func1() {
  // ...
}

（2）统一使用英文命名。 不在变量名中混合拼音与英文，不直接使用中文作为程序标识符。

（3）采用一致的命名风格。

对象推荐命名形式示例
普通变量camelCasecurrentStep
函数/方法camelCasegenerateSteps()
类PascalCaseLinkedListEngine
前端组件PascalCaseNodeRenderer
常量UPPER_SNAKE_CASEMAX_NODE_COUNT
普通文件kebab-casestep-controller.ts
Java 包名（如使用）全小写com.nullteam.algorithm
数据库表名遵循已确定的数据库设计规范learning_record

数据库命名以已经完成的数据库设计文档为准，不在 Alpha 开发时随意修改。

3.3 代码格式规范

  1. 强制： 同一模块采用统一的代码格式和自动格式化配置。
  2. 强制： 不允许出现无意义的空格、重复空行和错误缩进。
  3. 推荐： 前端 JavaScript/TypeScript、JSON 等文件采用 2 空格缩进；若使用 Java 后端，则采用 4 空格缩进。
  4. 推荐： 单行代码尽量不超过 100～120 个字符，较长表达式合理换行。
  5. 强制： 条件判断和循环控制应保持清晰，避免过深嵌套。
  6. 强制： 提交前删除不再使用的变量、调试输出和死代码。
  7. 推荐： 使用 ESLint、Prettier 或所选技术栈对应的格式检查工具。

对于公共配置，应将格式规则保存到仓库，避免不同成员使用不同的格式化方式。

3.4 注释规范

注释应解释代码的业务意图、算法思路、边界条件和重要设计决策，而不是简单重复代码本身。对于公共算法接口，建议包含功能描述、参数含义、返回值、异常条件及使用限制。

/**
 * 在链表的指定位置执行插入操作。
 *
 * @param values 初始链表数据
 * @param position 插入位置
 * @param value 待插入节点的值
 * @returns 按顺序生成的算法 Step 列表
 * @throws RangeError 当插入位置非法时抛出
 */
function generateInsertSteps(
  values: number[],
  position: number,
  value: number
): Step[] {
  // 具体实现由算法模块负责
}

若实际使用 Java，则公共类、公共接口和方法采用 Javadoc 注释形式。注意：不保留过时注释；不大面积注释掉旧代码；不为显而易见的语句编写冗余注释；复杂算法步骤应解释设计原因。

3.5 模块划分规范

项目按照原型 P1–P9、领域模型和 8 人职责划分模块。建议逻辑结构如下；实际目录以仓库已选技术栈与建库方案为准：

project/
├── src/
│   ├── pages/           # P1-P9 页面和路由；按阶段启用
│   ├── algorithms/      # DataStructure / Operation / StepSnapshot
│   ├── visualization/   # P2 节点、指针、边与画布
│   ├── player/          # VisualizationSession / 步骤控制
│   ├── code-sync/       # P2 代码高亮、步骤解释
│   ├── input-panel/     # P3 输入、P4 操作与校验
│   ├── knowledge/       # P5 知识卡、P7 术语和帮助
│   ├── account/         # P8 访客/登录与会话（L2）
│   ├── progress/        # P6 学习记录（L2）
│   ├── challenge/       # P9 闯关积分（Beta/L3）
│   └── shared/          # 统一类型、状态、API 契约
├── tests/               # 单元 / 接口 / E2E / 回归
├── docs/                # 原型映射、接口、使用说明
└── README.md

模块职责要求：

  • 算法模块只负责算法过程、数据模型和 Step 生成，不直接操作页面 DOM。
  • 可视化模块只根据 Step 渲染图形，不重新实现算法逻辑。
  • 播放器只负责步骤调度和交互状态，不直接修改数据结构内部状态。
  • 代码同步模块根据当前 Step 更新代码高亮和文字解释。
  • 页面模块按 P1–P9 路由与页面状态组织：P3 管数据输入、P4 管算法操作；P5/P7 管教学帮助；P8 与 P6 提供有限的账号进度能力，P9 只在 Beta 激活。
  • 测试模块验证各层接口与完整业务流程。
  • 工程化模块统一构建、检查、部署和运行环境。

所有模块应通过约定的公共接口交互，禁止为了临时联调随意访问其他模块的内部实现。

3.6 Step 接口规范

本项目核心接口与原型领域类图保持一致：StepSnapshot 是不可变的步骤快照，VisualizationSession 持有唯一 currentStepIndex（前端对应 stepIndex）；成员5生成序列，成员1统一 Schema/Controller，成员3/6消费快照，成员4向控制器发送操作。

下面的 TypeScript 为与原型字段相符的接口示意（真实类型以第1天确定的 Step Schema v1 为准；不添加自定义的另一套强制字段）：

type DataStructureState = { type: string; values?: number[]; nodes?: unknown[] };

interface StepSnapshot {
  stepIndex: number;
  codeLineNo: number | null;
  structureState: DataStructureState;
  highlightedNodes: string[];
  explanation: string;
}

interface VisualizationSession {
  sessionId: string;
  currentStepIndex: number;
  steps: ReadonlyArray<StepSnapshot>;
}

// 本例为公共字段示意；实际结构状态遵循团队最终 Schema。

{
  "stepIndex": 2,
  "codeLineNo": 5,
  "structureState": { "type": "linkedList", "values": [10, 20, 30, 40] },
  "highlightedNodes": ["node-30"],
  "explanation": "将新节点30接入链表"
}

对 Step 接口提出以下要求：

  1. 每个 Step 必须明确表示一次算法状态变化或教学步骤。
  2. 相同输入应生成语义一致、顺序确定的 Step。
  3. Step 中涉及的节点应具有稳定且可识别的标识。
  4. codeLineNo 与 explanation 必须对应当前步骤；highlightedNodes、structureState 必须能重建该步骤的完整视觉状态。
  5. 涉及回退或重播的操作应保证状态可以正确恢复。
  6. 公共字段修改必须经过成员1确认，并通知全部接口使用方。
  7. 禁止各成员为自己模块另行建立不兼容的 Step 结构。

对于链表插入，渲染可将快照差异解释为 Create / Connect / Highlight 等动作；但不得将动画回调作为真实状态源，必须以 StepSnapshot 为唯一可信输入。

3.7 异常处理规范

强制要求：

  • 用户输入必须经过合法性验证。
  • 数组或链表索引不能超出合法范围。
  • 空结构操作必须有明确处理规则。
  • 不允许通过忽略异常来掩盖程序错误。
  • 不允许将调试异常堆栈直接展示给普通用户。
  • 异常信息应能帮助开发人员定位问题。

例如，界面应显示清晰的提示：

插入失败：位置超出链表的有效范围。

开发日志应记录必要的错误类别、所属模块和复现信息，但不能泄露密码、令牌等敏感数据。

3.8 数据库与安全规范

数据库设计已完成；结合原型的 UserAccount / LearningRecord / Challenge / ScoreRecord 领域模型，Alpha 对 L2 作最小化落实，Beta 再推进关卡和积分数据。

  • 按照既有数据库设计维护表结构和字段。
  • 若需要修改数据库结构，应先提交变更说明并经评审。
  • SQL 查询使用参数化方式，避免直接拼接用户输入。
  • 禁止在源代码中硬编码真实密码、密钥和数据库凭据。
  • 环境配置与业务代码分离。
  • 不将真实敏感数据放入测试用例或公开仓库。
  • 对用户输入进行必要的长度、类型和范围校验。

账号与积分安全底线：注册密码只保存强哈希（带独立随机盐）；会话支持登出失效及超时；学习记录读写必须检查用户权限；访客只使用 L1，不强制登录。Beta 期 P9 的分数必须由服务端判定并幂等结算，ScoreRecord.isFirstClear 不允许重复通关重复加分，禁止信任前端提交的积分。

3.9 Git 分支与代码提交规范

采用统一分支管理策略：

分支用途
main稳定版本
develop日常集成开发
feature/xxx新功能开发
fix/xxxBug 修复
release/alphaAlpha 发布候选版本

开发流程：

创建 Issue → 领取任务 → 创建个人功能分支 → 编写代码和自测
       ↓
推送代码 → 创建 Pull Request → Code Review
       ↓
通过 CI 和集成测试 → 合并到 develop → 阶段回归 → 发布稳定版本

Commit 提交规范： 推荐采用 type(scope): description。

类型含义
feat新增功能
fix修复问题
docs文档修改
style不影响功能的格式调整
refactor代码重构
test测试代码
chore配置及工程维护

示例：

git commit -m "feat(algorithm): 支持链表中间插入"
git commit -m "feat(player): 实现单步前进与回退"
git commit -m "fix(animation): 修复节点连线残留"
git commit -m "test(linked-list): 补充非法索引测试"

每次开发提交应对应实际任务 Issue，PR 中说明关联 Issue。

代码合并要求：

  1. 不直接向稳定分支提交日常功能代码。
  2. 每个开发任务需要明确 Issue。
  3. PR 必须描述功能变化、测试方法和影响范围。
  4. 至少由1名相关成员进行 Code Review。
  5. 公共接口和关键集成代码需要成员1参与审核。
  6. 必须完成必要的自测及集成检查后才能合并。
  7. 功能冻结后原则上只接受缺陷修复。

3.10 测试与代码质量规范

团队不将测试集中到最后一天，而是从开发开始就并行推进。

单元测试 → 接口测试 → 模块集成测试 → 端到端测试（E2E）
                                  ↓
                           回归测试 → 发布验收

测试内容至少覆盖正常输入、空结构、非法输入、链表头/中/尾插入、算法 Step 正确性、动画与数据状态一致性、代码高亮与解释同步、暂停/回退/重播、快速连续点击、多次执行及模块切换。

根据实际技术栈，可选择合适的自动化测试工具，例如 JavaScript/TypeScript 项目中的 Vitest、Jest、Playwright，或 Java 项目中的 JUnit。工具选择以实际技术栈为准，不为了使用工具而增加无必要的技术依赖。

开发成员负责模块自测；成员7负责测试方案、综合测试、缺陷跟踪和最终质量验收；成员8负责将必要的自动化检查接入 CI。

3.11 任务完成标准（Definition of Done）

一个任务只有满足以下条件，才允许标记为完成：

  • 对应 Issue 已明确功能及验收条件。
  • 代码符合命名、格式及模块职责规范。
  • 相关功能实际运行正常。
  • 开发者已完成自测。
  • 公共接口符合约定。
  • 与直接上下游模块完成必要联调。
  • PR 已通过相关成员评审。
  • 集成测试或 CI 检查通过。
  • 关键回归测试没有新增严重问题。
  • 代码、截图、测试报告等证据可追溯。

代码提交成功不等于功能完成，功能合并成功也不等于集成验收完成。

四、团队成员分工

本次 Alpha 冲刺沿用团队前期确定的“主责 + 副责”分工方式。每名成员既负责自己的核心模块，也需要配合相关成员进行联调，最终交付同一个可运行的系统。

成员核心角色主要职责副责与协作任务
成员1组长 / PM / 技术负责人任务管理、公共 Step、架构、集成、版本控制公共状态、技术补位、代码审查
成员2产品 / UX / 前端负责人网站页面、用户流程、输入表单、交互体验可用性测试、文案和演示流程
成员3可视化引擎负责人节点、边、指针、动画及布局动画优化、可视化组件复用
成员4播放控制负责人播放、暂停、单步、回退、重播、调速交互组件、状态管理和动画联调
成员5数据结构算法负责人算法数据模型、算法操作、Step 生成单元测试、基础数据结构扩展
成员6代码同步与教学负责人代码高亮、步骤解释、教学案例树/图等进阶算法的后续扩展
成员7QA / 测试负责人测试计划、自动化测试、Bug 管理、回归验收可用性测试、质量报告
成员8工程化 / 部署负责人环境、CI、构建、部署、README全栈支援、跨模块问题处理

4.1 四条协作主线

  • 产品与整体：成员1 + 成员2。 负责范围管理、用户流程、页面设计和整体架构，确保产品需求能够实际落地。
  • 可视化与交互：成员3 + 成员4。 负责动画展示和播放器控制，确保动画状态和用户操作保持一致。
  • 算法与教学：成员5 + 成员6。 负责算法 Step、代码高亮与解释，使用户不仅能够看到变化，还能理解变化原因。
  • 质量与工程化：成员7 + 成员8。 负责从开发初期开始测试和部署，确保项目不只是某个成员本地能够运行。

五、Alpha 七天冲刺任务与计划

5.1 总体日程安排

日期冲刺阶段当天核心目标
10月23日Day 1：原型映射与接口统一 P1–P9 范围、StepSnapshot、P2 布局、访客原则
10月24日Day 2：核心组件并行P1/P2/P3/P4 可独立运行；算法/动画/高亮并行
10月25日Day 3：三联动集成P1→P3/P4→P2 链表插入黄金样例端到端通过
10月26日Day 4：稳定与账号时间盒修复三联动/回退/进度条；P5/P7；P8 访客和账号基础
10月27日Day 5：线性结构扩展数组、栈、队列基础操作 + P6 进度保存（按条件）
10月28日Day 6：全路径验收回归 L1、访客模式、已实现的 L2；冻结功能
10月29日Day 7：交付答辩版本发布、P1–P9 实现矩阵、11篇博客、测试/AI总结

5.2 Day 1：项目初始化与接口统一

日期：2026年10月23日

当天目标：将原型 P1–P9 分为可执行 Issue，统一 StepSnapshot / P2 三联动接口，建立访客优先规则和开发环境。

成员具体任务当天计划交付物
成员1按九页面原型拆 Issue、明确 L1/L2/L3 时间盒；冻结 StepSnapshot + VisualizationSession v1 与 P2 三联动协议。页面—Issue 对照表、Schema v1、Controller 初版、PR 规范
成员2依据 P1 首页和 P2 三栏绘制实际前端框架；给 P3/P4 输入与操作面板留入口，P8 设置访客入口。P1/P2 页面骨架、路由、P3/P4 入口截图
成员3实现 P2 的 Node/Edge/Pointer/下标组件，使用 Mock StepSnapshot 显示链表节点和连接。P2 画布组件、链表静态运行图
成员4P2 底部播放控制、步骤进度条和初版 stepIndex 状态；完成 Mock 前进/回退。播放器初版、控制条截图、状态约定
成员5实现 DataStructure/Operation 的链表基础模型与插入 StepSnapshot；准备数组/栈/队列的基础接口。链表算法初版、示例快照、单元测试
成员6实现 P2 左代码、右中文解释的数据绑定骨架；为 P5 知识卡、P7 术语列内容清单。代码同步组件、解释映射、知识卡/术语目录
成员7按 P1–P9 建立覆盖矩阵；首先编写 L1 黄金用例、访客模式、输入非法值及三联动用例。测试计划、原型功能用例表、Bug 模板
成员8创建可重现构建与 CI；核对 P8/P6 涉及的账号、进度数据表和 API 范围。启动脚本、README/CI、账号/进度接口草案

团队验收：P1 首页和 P2 三栏骨架可以运行；P3/P4 入口、P8 访客入口明确；模拟 StepSnapshot 可以驱动节点展示，接口、构建和测试环境可用。

当天博客材料： 代码规范、冲刺任务与计划博客；Day 1 冲刺日志；当天真实站会照片；首次燃尽图；程序运行截图；相关 Issue、Commit 和测试记录。

5.3 Day 2：核心模块并行开发

日期：2026年10月24日

当天目标：围绕 P2 三栏和 P3/P4 的核心任务并行开发，模块各自可用且遵守统一 StepSnapshot。

成员具体任务当天计划交付物
成员1校验快照字段与唯一 stepIndex；审查 P3/P4→算法→P2 端到端接口与 PR。接口测试、Schema Review、Controller 更新
成员2完成 P3 手动输入、随机/批量数据入口和输入校验；实现 P4 插入参数与中文错误提示。P3/P4 组件、输入测试截图
成员3完成 P2 创建节点、修改连线、高亮操作的可视化，使用快照模拟完整插入。动画动作、P2 演示 GIF
成员4将播放、暂停、前进、回退与 Controller 联接；制作进度条及调速交互。播放器代码、步骤索引测试记录
成员5补齐链表头/中/尾插入与空链表非法位置；输出字段一致的不可变快照。链表快照序列、边界单测报告
成员6根据真实 StepSnapshot.codeLineNo/explanation 驱动左、右栏；完成链表知识卡初版。P2 代码同步 GIF、P5 链表知识卡
成员7验证算法→快照、播放器→索引、快照→三栏对齐；梳理访客流程异常。接口测试报告、Bug 清单
成员8部署联调预览环境；按独立时间盒建立 P8 账号 API 骨架（不得阻塞 L1）。CI 记录、预览链接、账号 API 草案

团队验收：链表算法可以独立生成 StepSnapshot；P2 三栏以模拟快照显示同一状态；播放器按唯一 stepIndex 调度；P3/P4 输入和操作面板具备基本交互。

当天发布 Day 2 冲刺日志，并提供对应的运行截图、真实站会照片和燃尽图。

5.4 Day 3：链表插入黄金样例联调

日期：2026年10月25日

当天目标：访客从 P1 首页进入 P3/P4，最终在 P2 完成链表插入的三栏端到端演示。

成员具体任务当天计划交付物
成员1组织 P1→P3/P4→StepSnapshot→P2 全链路联调；合并过审 PR，核对三栏同一状态。黄金样例集成版、联调记录、PR Review
成员2打通 P1 结构选择、P3 输入、P4 操作与 P2 学习页；保证访客无需先登录。访问路径运行截图、操作演示 GIF
成员3消费真实快照驱动节点和指针变化；保证修改前后连接关系与高亮准确。链表插入完整动画 GIF、联调代码
成员4驱动真实 stepIndex；让单步、回退、暂停和进度跳转保持三栏同步。P2 完整播放器视频/测试记录
成员5与画布联调链表 10→20→40 插入 30；确认结构变化与快照顺序。真实算法快照、黄金算法单测
成员6与成员3校验同一快照下的代码行、中文解释和术语准确性。P2 三联动录像、映射测试
成员7执行链表 E2E、访客路径、非法输入和拖拽进度条测试，追踪 Bug。黄金样例 E2E、缺陷 Issue、截图
成员8部署集成版并验证外部设备访问；记录 L2 API 骨架进度。集成环境地址、构建/运行日志

团队验收：访客从 P1 进入 P3/P4，输入 10→20→40 并在 20 后插入 30，P2 最终显示 10→20→30→40；代码高亮、画布、中文解释与控制条、进度条保持同步。

当天发布 Day 3 冲刺日志，重点展示完整运行过程及联调中发现的问题。

5.5 Day 4：核心功能完善与异常修复

日期：2026年10月26日

当天目标：修复三栏不同步、回退/进度跳转等关键问题，并按 M4a 独立时间盒落实 P8 访客与账号最小功能。

成员具体任务当天计划交付物
成员1分级处理三联动与交互 Bug；审查 P8 登录/访客和 P6 进度的最小 API 契约。P0 Bug 关闭记录、L2 范围确认
成员2完善 P5 结构详情/知识卡及 P7 帮助/术语；开发 P8 登录/注册/访客页面与错误态。P5/P7 内容、P8 页面与访客跳转演示
成员3修复快速回退、重新输入后节点漂移、连线残留等 P2 动画问题。动画修复 PR、连续操作 GIF
成员4完善拖拽进度条、调速、快速点击防重；区分“访客可学”和“登录可保存”的 UI 状态。状态机修复、控制异常测试
成员5补齐链表边界 Step；若核心稳定则开展数组创建/插入，规划栈/队列快照。链表回归、数组算法初版/Backlog
成员6检查 P2 所有中文解释并与 P7 术语表关联；补充数组伪代码和知识卡。解释修订、术语表、数组映射初版
成员7重点验证 P2 索引/三栏一致、P3/P4 输入错误、P8 访客不被强制登录。跨页面与异常回归报告
成员8在 M4a 时间盒内实现最小注册/登录/登出接口与加盐哈希；若拖慢 L1 则保留 Mock/接口草稿。账号 API 代码与安全测试，或明确降级记录

团队验收：黄金样例与访客学习路径稳定；P5 知识卡和 P7 术语内容正确；P8 登录与 P6 进度按 M4a 独立时间盒验收，未达成则记录延期与原因。

5.6 Day 5：功能扩展与架构复用

日期：2026年10月27日

当天目标：在黄金样例稳定后，推进数组、栈和队列基础操作；同步尝试 P6 学习记录的轻量实现。

成员具体任务当天计划交付物
成员1验收 P1–P7 的最低实现，推动四种线性结构复用统一快照；核对 P6/P8 能力边界。L1 功能矩阵、联合联调记录
成员2完善 P6“我的实验台”的记录/回放布局和登录后保存提示；优化 P1 结构导航。P6 UI、访客/登录态提示、导航截图
成员3实现数组单元、栈/队列基础布局；复用 P2 的节点、高亮与动画能力。数组/栈/队列可视化演示（以实际完成为准）
成员4复用播放器于数组、栈、队列；处理重新输入、结构切换和清空进度。通用播放器集成、跨结构测试
成员5推进数组插入、栈 push/pop、队列 enqueue/dequeue 的基础 StepSnapshot 与单测。新增算法与测试；未完成列出 Issue
成员6为新增线性结构提供 P5 知识卡、代码高亮和中文步骤解释；核查术语。数组/栈/队列教学资源及映射
成员7回归链表黄金案例，验证新增结构 Step；测试 P8 鉴权/P6 保存权限（如已实现）。回归报告、L2 安全与接口结果
成员8完善 P6 LearningRecord 保存/查询接口及部署；未实现时提供清晰降级说明。进度 API、持久化测试或下阶段 Backlog

团队验收：链表黄金样例继续通过回归；数组、栈、队列按实际完成情况提供真实测试和截图；P6 只展示已实现的学习记录能力，不能以静态原型充当已完成功能。

5.7 Day 6：全面测试与功能冻结

日期：2026年10月28日

当天目标：覆盖 P1–P7 的实际学习路径、访客 L1、账号 L2 的已实现部分，形成可发布候选版本。

成员具体任务当天计划交付物
成员1核对 L1 Must 验收、L2 M4a 实现进度，冻结新功能；决定 Alpha Release 候选。冻结记录、原型/实现对照与风险表
成员2组织2–5名同学从 P1 首页进入 P2 学习、P3/P4 操作、P5/P7 查看说明并测访客路径。可用性报告、UI 修复及截图
成员3修复 P2 重叠/跳帧，保证每个 stepIndex 可重复渲染；录制稳定黄金样例。最终动画组件、黄金样例 GIF
成员4最终检查回退、重播、暂停、调速、拖拽、重新输入后的三栏同步。播放器回归报告、异常操作截图
成员5全面回归链表及已实现的数组/栈/队列算法；报告缺失操作或范围偏差。单测汇总、算法覆盖报告
成员6校对 P2 代码行与中文解释、P5 知识卡和 P7 术语；整理答辩教学案例。教学模块最终版、术语检查单
成员7执行 E2E/自动化回归；重点覆盖访客 L1、P8 登录错误、P6 未授权保存（按实现范围）。测试报告、缺陷闭环、独立测试博客
成员8构建可重复部署候选版；检查账号 API 安全、错误日志、会话退出（如实现）。Release Candidate、CI/部署与安全检查

建议在当天 18:00 前完成功能冻结。冻结后原则上不再增加新功能，只修复影响核心功能和答辩演示的问题。

当天团队交付： Day 6 冲刺日志、独立测试随笔、最新燃尽图、综合测试报告、Alpha 候选版本和答辩 PPT 初稿。

5.8 Day 7：最终交付与冲刺总结

日期：2026年10月29日

当天目标：交付 Alpha 实际实现的 P1–P9 功能矩阵、稳定版、测试结果、课程博客与答辩 PPT。

成员具体任务当天计划交付物
成员1整理 P1–P9“原型 / 已实现 / 待实现”矩阵、工作量、燃尽图、Release 和 Alpha 总结。冲刺总结、博客索引、PPT、版本验收
成员2整理 P1/P2/P3/P4/P5/P7 实机截图及 P6/P8 状态说明；提供用户体验演示脚本。原型对齐截图、用户操作说明、PPT
成员3录制核心 P2 三栏同步与插入指针变化；准备演示离线视频。真实运行 GIF/视频、动画技术页
成员4按原型演示“播放→暂停→单步→回退→拖动进度→重播”；检查访客入口。控制演示录像、回归结论
成员5整理链表/数组/栈/队列的实际算法完成情况、StepSnapshot 正确性及遗留项。算法交付清单、正确性测试、PPT
成员6演示 P2 代码/解释同步以及 P5/P7 教学内容；整理 P9 关卡题目 Beta 建议。教学素材、术语校验、后续关卡提案
成员7执行最终 L1 端到端和 L2 已完成路径回归，列清未做的 P9 Beta 测试项。最终测试结论、缺陷统计、评审表
成员8部署 Alpha Release、验证访问/回滚；归档 L2 API 状态、P9 不上线说明。部署地址、Release Tag、README、备用环境

当天团队交付： Day 7 冲刺日志、Alpha 冲刺总结随笔、最终项目运行截图/GIF、最终版本与部署说明、答辩 PPT、腾讯共享评审表和完整置顶博客集合。

团队内部计划在当天 21:00 前完成材料提交，为平台审核和突发问题留出时间。

六、站立式会议与每日进度管理

6.1 会议制度

团队在七天冲刺期间每天举行一次站立式会议，建议会议时长控制在 15～20 分钟。每位成员需要说明：

  1. 上次站会以来完成了什么？
  2. 当前遇到了哪些困难？
  3. 下一次站会之前准备完成什么？
  4. 是否需要其他成员协助？

第一次站会以冲刺前已完成的准备工作为基础，不虚构不存在的前一天开发内容。AI 技术员的工作情况单独记录。建议每日站会后更新 Issue 看板，并检查是否存在影响下游成员开发的阻塞问题。

6.2 每日进展记录

每天的冲刺博客中统一使用以下记录表：

成员今日进展遇到的问题下一步安排心得体会
成员1当日填写当日填写当日填写当日填写
成员2当日填写当日填写当日填写当日填写
成员3当日填写当日填写当日填写当日填写
成员4当日填写当日填写当日填写当日填写
成员5当日填写当日填写当日填写当日填写
成员6当日填写当日填写当日填写当日填写
成员7当日填写当日填写当日填写当日填写
成员8当日填写当日填写当日填写当日填写
AI 技术员记录 AI 实际工作记录不足与限制记录下步任务记录人工评价

以上仅是日志模板，实际进度、问题及结果均在当日填写。

6.3 燃尽图管理

本次采用任务点数管理 Sprint 工作量。项目开始前，成员1负责将需求拆分成可验收的 Issue，并估算相应任务点。每日根据已经通过验收的任务更新剩余工作量。

实际剩余任务点 = 当前冲刺范围内总任务点 - 已验收完成的任务点

为说明记录方式，假设初始任务总点数为 80 点，可以制定计划燃尽线：

日期示例计划剩余点数
冲刺开始80
Day 174
Day 262
Day 344
Day 429
Day 516
Day 64
Day 70

以上是示例计划值，不代表真实开发完成情况。 实际燃尽图以团队确定的任务总点数和每日验收结果绘制，并在每天的冲刺日志中更新。

6.4 每日成果证据

每日博客中需要提供：

  • 当天真实站立式会议照片；
  • 当日项目燃尽图；
  • 最新模块或程序运行截图/GIF；
  • 8 名成员的实际进展；
  • 开发任务对应的 Issue 与代码签入；
  • 测试、文档或设计任务的实际成果；
  • AI 技术员工作记录；
  • 当前问题及下一天安排。

站会照片必须来自当天的真实会议，不复用以前照片。对于尚未完成的功能，要如实标注开发状态，不使用设计图或 AI 生成图片冒充真实运行结果。

七、AI 技术员的引入与协作计划

7.1 引入 AI 技术员的目的

本次 Alpha 七天冲刺要对齐 P1–P9 原型和“学→练→测”产品路线，但不能把九个原型页面误当成九个全部开发完成的后端功能。AI 技术员将重点辅助 P2 StepSnapshot 三联动、P3/P4 输入校验、P8 访客/会话方案、P9 Beta 闯关判定与测试用例的设计，不代替成员执行真实代码验证。

AI 不作为独立承担最终责任的开发成员，而是作为辅助角色，为团队提供技术建议、代码草稿、测试设计、代码审查及文档支持。

AI 负责辅助，团队成员负责最终决策、代码验证和实际交付。

7.2 AI 技术员角色划分

根据不同任务，将 AI 的工作划分为四类。

AI 角色工作职责对接成员
AI-Designer核对 P1–P9 原型，优化 P2 三栏、P3/P4 表单、P8 访客入口和 P5/P7 教学可读性成员2
AI-Programmer辅助 StepSnapshot、VisualizationSession、数组/链表/栈/队列算法及 P8 最小接口成员1、3、4、5、6、8
AI-Tester产生 P2 三联动/跳转回退、访客无登录墙、账号权限/积分幂等 Beta 测试草稿成员7、8
AI-Documenter维护 P1–P9 原型/实现对照、Issue 证据、测试记录、AI 审核与答辩材料成员1、7

AI 技术员可以由实际使用的通用大语言模型或具有 AI 辅助功能的开发工具承担。具体工具名称和使用情况将在每日冲刺日志中如实登记。

7.3 AI 工作流程

为保证 AI 输出质量，团队采用以下协作流程：

成员发现问题或领取任务
          ↓
整理背景、要求和约束
          ↓
向 AI 提供明确任务
          ↓
AI 生成建议、方案或代码草稿
          ↓
成员人工审查和修改
          ↓
本地运行与自动化测试
          ↓
必要时进行 PR Review
          ↓
采纳有效成果
          ↓
记录 AI 贡献及验证证据

团队要求：

  1. AI 生成的代码必须经过人工阅读和理解。
  2. AI 不能擅自修改公共 Step Schema。
  3. AI 不能直接决定代码是否合并。
  4. AI 提供的算法必须经过正确性验证。
  5. AI 生成的测试用例必须实际执行。
  6. AI 生成的技术文档需要成员审核。
  7. 不向公共 AI 工具提交真实密码、令牌及其他敏感信息。
  8. 不将未经验证的 AI 产出作为已完成任务上报。

7.4 如何驱使 AI 辅助开发

为了避免模糊提问导致输出质量不稳定，团队将采用结构化 Prompt。每次向 AI 发出任务时，尽量说明项目背景、所属模块、预期功能、输入与输出、技术约束、边界情况、希望得到的结果以及验证标准。

示例一：驱使 AI 辅助链表算法开发

任务： 让 AI 辅助成员5设计链表插入的 Step 生成逻辑。

你现在是 NULL Visual Lab 的 AI-Programmer。
任务：为链表插入生成与原型一致的 StepSnapshot 序列。
输入示例：10→20→40，在20后插入30。
接口必须包含 stepIndex、codeLineNo、structureState、highlightedNodes、explanation。
要求：同一快照能驱动 P2 的左代码/中画布/右解释；不允许通过动画回调保存真实状态；支持暂停/回退/进度跳转。
请先分析指针更新顺序，再给出算法伪代码、快照序列、异常处理及单元测试。
不要编造尚未确定的公共字段，未知约定列为需要确认的问题。

人工验收方式： 成员5检查算法正确性，成员1检查接口兼容性，成员7执行相应测试。只有实际通过验证的内容才能进入项目代码。

示例二：驱使 AI 辅助播放器排错

任务： 让 AI 辅助成员4分析快速连续点击导致的状态问题。

你现在是 NULL Visual Lab 的 AI-Programmer（前端状态方向）。
P2 三栏由 VisualizationSession.currentStepIndex 唯一驱动。
已知问题：用户快速连续点击、拖拽步骤进度条或在回退后继续播放，代码高亮与画布可能不同步。
请给出状态机/调度模型、动画取消与恢复策略、禁用或排队规则、最小测试矩阵。
不能让组件各自维护独立游标；不能直接修改算法对象；必须支持 P3/P4 改参数重新生成 StepSnapshot。

成员4根据建议修改实现，成员3检查动画行为，成员7执行状态测试。

示例三：驱使 AI 生成自动化测试

任务： 辅助成员7设计链表插入测试用例。

你现在是 NULL Visual Lab 的 AI-Tester。
请按九页原型划分测试覆盖，不将尚未实施的 P9 Beta 功能标记为 Alpha 通过。
重点检查：P1→P3/P4→P2 的链表插入；同一 stepIndex 的三联动；暂停/回退/速度/拖拽进度；P3 非法输入中文提示；P8 访客无需登录使用 L1；登录后 P6 保存授权（若已实现）；P9 服务端积分幂等作为 Beta 待测。
输出：用例编号、前置条件、步骤、预期、优先级、适用阶段，并建议适配实际技术栈的自动化工具。

生成结果由成员7人工筛选和修改，再在真实项目环境中执行。测试用例是否有效，以实际运行结果为准。

示例四：驱使 AI 辅助 UI 设计

任务： 辅助成员2优化学习页面。

你现在是 NULL Visual Lab 的 AI-Designer。
页面原型已定义 P1 首页结构选择、P2 左代码/中画布/右解释、P3 数据输入、P4 操作、P5 知识卡、P6 我的实验台、P7 帮助术语、P8 登录/访客、P9 闯关积分（Beta）。
请优先评审 P1→P3/P4→P2 的学习路径、三栏可读性、步骤条与异常提示；确保访客不遇登录墙。
输出“原型要求—问题—建议—验收方式”表。不要增加无关页面、不要把 Beta 功能提前定义为 Alpha 必做。

由成员2选择可实施的建议，并与成员3、4核查动画区和控制区的实际兼容性。

7.5 AI 技术员七天任务计划

日期AI 计划承担的工作人工负责人预期成果
Day 1九页面 P1–P9 映射、StepSnapshot 字段审查、访客优先用例1、2、5、7原型对照、接口/用例建议
Day 2P2 三栏绑定与 P3/P4 输入校验草稿、链表快照单测3、4、5、7算法与界面测试建议
Day 3分析链表三联动日志、快照重建/回退冲突1、3、4、7Bug 原因与验证记录
Day 4P8 访客登录路径和 P5/P7 教学可读性检查2、4、7、8访客 E2E、文案与错误用例
Day 5数组/栈/队列复用测试；P6 学习记录/API 检查5、6、7、8覆盖用例与人工采纳记录
Day 6九页面实际实现对照、L1/L2 回归、P9 Beta 用例归档1、7、8回归脚本、缺陷分类
Day 7汇总 P1–P9 状态矩阵、AI 真实贡献和 Beta 闯关建议1、7可追溯 AI 贡献总结

7.6 AI 工作情况记录

在七篇每日冲刺日志中，单独增加“AI 技术员工作情况”，注明所用模型/工具、Prompt、人工修改和真实运行记录。P9 积分相关 AI 输出仅作为 Beta 设计与测试草稿，不计入本轮实际完成。

记录项目内容
日期当天实际日期
AI 角色AI-Designer / AI-Programmer / AI-Tester 等
实际使用工具填写当天真实使用的 AI 工具
工作任务AI 接收的具体需求
Prompt 摘要输入给 AI 的主要指令
AI 输出建议、代码、测试或文档
人工验证谁进行了检查、修改或测试
最终结果采纳、部分采纳或未采纳
贡献证据代码提交、测试报告、截图等
存在不足错误建议、理解偏差或其他限制

7.7 AI 贡献评价方法

冲刺结束时，我们计划从以下几个方面评价 AI 技术员：

  1. 辅助开发效果： 是否帮助成员解决实际开发问题。
  2. 代码质量： AI 生成代码经过人工修改后能否正确运行。
  3. 测试辅助效果： 是否帮助发现遗漏的边界场景。
  4. 问题定位能力： 是否对实际 Bug 提供有用的分析。
  5. 文档辅助效果： 是否改善接口说明和技术文档的清晰程度。
  6. 局限性： 是否出现不符合接口、错误假设或无法运行的代码。

如需统计节约时间，将基于实际工作记录进行估算，不直接使用未经测量的数据。我们希望通过这一轮冲刺探索一种可持续的协作方式：开发者提出需求、AI 提供辅助、开发者验证结果、团队通过工程流程控制质量。

八、冲刺测试计划

8.1 测试目标

确保原型 P1–P9 的阶段目标被准确测试：Alpha 优先验证 P1→P3/P4→P2 的链表三联动与四种线性结构实际完成项；保证访客 L1 无强制登录；按 M4a 验证已实现的账号和进度；P9 积分判定与幂等安全测试列为 Beta 计划。

8.2 核心测试安排

阶段测试重点
Day 1P1–P9 原型测试矩阵、L1 链表黄金用例及访客场景
Day 2Algorithm→StepSnapshot、Controller→stepIndex、P3/P4 输入校验
Day 3P1→P3/P4→P2 三栏联动与全套播放器 E2E
Day 4回退/拖拽/快速点击、P5/P7 术语、P8 访客路径
Day 5数组/栈/队列扩展回归、P6 保存鉴权（仅已实现部分）
Day 6完整路径回归、P8 错误态/会话测试、CI 与 Release Candidate
Day 7最终版本回归；区分“Alpha 已实现”与“P9 Beta 待实现”

8.3 黄金样例测试用例

测试编号测试内容预期结果
TC-01创建链表 10→20→40初始节点与连线正确
TC-02在20后插入30最终结果为10→20→30→40
TC-03检查插入 Step 顺序创建节点和修改指针的顺序正确
TC-04检查代码高亮每一步对应正确代码行
TC-05检查步骤解释每一步描述与算法操作一致
TC-06播放中暂停视觉状态与步骤索引保持一致
TC-07上一步及重播能正确恢复此前状态
TC-08快速连续点击不发生节点错乱或错误推进
TC-09非法插入位置给出明确错误提示
TC-10重新执行黄金样例结果与首次执行保持一致
TC-11P1 结构选择→P3 输入→P4 插入→P2 动画访客可完整进入 L1，无错误跳转
TC-12P3 手动输入、随机与批量输入（按已实现项）合法输入正确生成数据集，非法输入中文提示
TC-13P2 进度条拖至任意 stepIndex左右中三栏同时重建正确快照
TC-14回退后改 P4 参数并重新执行旧快照与视觉残留清零，新序列正确
TC-15P5 知识卡、P7 术语回到 P2说明准确、术语可定位，学习路径不断裂
TC-16P8 访客跳过登录使用所有 L1 功能无强制登录墙，仅保存学习进度时提示登录
TC-17P8 注册/登录/注销、错误提示（L2 如已实现）密码强哈希；异常提示清晰；注销后会话失效
TC-18P6 未登录保存/登录后恢复（L2 如已实现）阻止未授权持久化，正确恢复本人进度
TC-19P9 首次通关/重复作答/服务端判分（Beta 计划）后续需满足服务端判分与积分幂等；本轮不计通过

8.4 Bug 管理

所有影响核心功能的 Bug 均应记录到 Issue 中。Bug 至少包含问题标题、发现日期、所属模块、复现步骤、预期结果、实际结果、严重程度、责任成员、修复提交和回归结果。

级别定义处理策略
P0 严重核心功能无法运行、数据结果错误或演示中断最高优先级处理
P1 较高重要交互或状态不正确当前冲刺内优先修复
P2 一般非核心表现或局部体验问题根据时间安排修复
P3 较低轻微样式或非关键优化允许记录到后续迭代

九、项目风险与应对措施

由于 Alpha 冲刺仅有七天，团队需要提前识别风险并准备应对方案。

风险可能影响应对措施
P2 三栏状态不同步代码/画布/解释不一致，黄金样例失效仅允许 StepSnapshot + 唯一 stepIndex 驱动；自动回归
原型9页被误当作7天全部开发完成引发范围蔓延和交付失真分 L1 Must、L2 M4a、L3 M6a；公布原型/实现矩阵
访客被 P8 登录墙阻挡用户无法完成核心 L1 学习闭环P1/P8 访客路径优先，E2E 强制验证
StepSnapshot 结构频繁修改算法/动画/播放器难以并行成员1冻结 Schema、审批变更，Mock 并行
进度保存与账号安全不足出现密码泄露、越权读写、失效会话密码强哈希、访问鉴权、脱敏日志与回归
P9 积分刷分/错误判定（Beta）重复结算导致积分不公平服务端判题、isFirstClear 幂等、Beta 专项测试
数组/栈/队列赶工影响黄金样例P0 核心质量下降第3天先验收链表，其他基础结构按点数推进
多人集成冲突/部署环境不一致本地可用但演示失败小 PR、Review、CI、固定 Release 和备份视频
AI 输出错误或误读原型生成不兼容接口和错误测试提供原型字段、人工验证、记录采纳证据
博客照片/燃尽图证据不足当日日志可能扣分当天实时收集照片、运行截图、Issue 与测试记录

9.1 关键进度检查点

  • Day 1： 所有成员能够基于统一接口和运行环境开展工作。
  • Day 3： 链表插入黄金案例首次完整跑通。
  • Day 4： 核心链路的主要严重问题已解决。
  • Day 5： 在 P0 稳定后扩展数组、栈、队列并开展 L2 独立时间盒验收。
  • Day 6： 完成全面测试及功能冻结。
  • Day 7： 交付稳定 Alpha 版本、P1–P9 原型/实现状态矩阵、博客与答辩材料。

如 Day 3 的黄金案例未能跑通，则调整 Day 4 任务，将人力集中到接口修复和核心联调，不盲目增加新功能。

十、博客与课程交付计划

本次作业需要完成 11 篇博客，并准备答辩 PPT 和腾讯共享评审表。

序号博客内容计划时间主要负责人
1Alpha 冲刺博客集合（置顶）10月23日建立，逐日更新成员1
2代码规范、冲刺任务与计划10月23日正式开发前成员1
3Alpha 冲刺 Day 110月23日成员2
4Alpha 冲刺 Day 210月24日成员3
5Alpha 冲刺 Day 310月25日成员4
6Alpha 冲刺 Day 410月26日成员5
7Alpha 冲刺 Day 510月27日成员6
8Alpha 冲刺 Day 610月28日成员8
9Alpha 阶段测试随笔10月28日成员7
10Alpha 冲刺 Day 710月29日成员1
11Alpha 冲刺总结10月29日成员1主笔，全体协作

各篇冲刺日志需包含当天真实照片、燃尽图、运行结果、成员进展、代码或测试证据及 AI 技术员贡献。独立测试随笔重点总结测试方案、工具选择、测试用例、自动化测试实践、实际结果与测试体会。

冲刺总结随笔重点回顾：预期计划与现实进展；各成员工作内容与心得体会；团队分工和协作情况；Alpha 阶段实际工作量比例；测试成果及遗留问题；AI 技术员的实际贡献与不足；下一阶段规划；答辩 PPT 链接。

10.1 答辩 PPT 任务分工

内容负责人
项目背景、P1–P9 原型页面与用户场景成员2
系统架构、冲刺管理和燃尽图成员1
P2 三栏与快照动画展示成员3
P2 播放器与 P8 访客模式演示成员4
链表黄金样例与四种线性结构实现范围成员5
P2 代码同步、P5 知识卡、P7 术语表成员6
原型/实现矩阵、E2E 测试、L2 安全边界成员7
Release 与登录进度 API（实际完成项）成员8
AI 技术员回顾与 Beta 规划成员1、7

所有成员配合完成最终答辩彩排。

十一、任务评价与工作量统计

本轮采用团队此前制定的成员绩效评价框架：

评价维度权重
任务完成度30%
工作质量25%
实际工作量20%
团队协作15%
参与度与纪律10%
合计100%

不同角色的实际证据形式有所不同：

  • 开发人员： Issue、Commit、PR、自测和运行结果。
  • 产品与设计人员： 页面代码、原型、交互说明及可用性反馈。
  • 测试人员： 测试脚本、报告、Bug 管理和回归记录。
  • 工程化人员： CI、构建、部署、README 及环境问题解决记录。
  • 组长： 公共接口代码、任务管理、代码审查、集成成果及版本记录。

团队不单纯按照代码行数或 Commit 数量评价个人贡献，而是结合任务难度、完成质量和跨模块协作综合判断。最终工作量比例将在冲刺结束后，根据实际完成记录计算，并在冲刺总结随笔中公布。

十二、预期成果与下阶段展望

12.1 Alpha 阶段预期成果

经过七天冲刺，团队计划形成以下成果：

  1. 与原型对齐的 Alpha 页面： P1 首页、P2 三栏主界面、P3/P4 输入与操作、P5/P7 教学辅助等，以真实运行截图为准。
  2. 完整的链表插入教学闭环： P2 同一 StepSnapshot 驱动代码高亮、画布与中文解释，支持回退、调速和进度条。
  3. 可复用的线性结构模块： 数据模型、StepSnapshot、Controller、播放器与动画组件用于数组/链表/栈/队列的逐步扩展。
  4. L2 账号/进度能力与质量成果： P8 访客模式必须可用；账号与 P6 学习记录在独立时间盒内实现并如实说明，保留单测、E2E、CI 与 Release 证据。
  5. 完整的软件工程过程记录。 包括每日站会、燃尽图、Issue、代码签入、联调记录、测试报告及冲刺总结。
  6. AI 辅助软件工程实践记录。 形成 AI 在需求理解、编码辅助、Bug 分析、测试生成和文档整理方面的真实使用记录。

以上均为计划目标，最终实现情况以冲刺总结中的实际验收结果为准。

12.2 下一阶段展望

Alpha 阶段结束后，团队计划根据实际完成情况和用户反馈，进一步开展 Beta 阶段工作。主要方向包括：

  1. 先补齐数组/链表/栈/队列基础功能，再开展 V1 树/BST 与 V2 图/哈希表。
  2. 增加更多典型算法与教学案例。
  3. 优化节点动画、布局和执行效率。
  4. 完善代码高亮和步骤解释。
  5. 完善 P6 我的实验台的学习记录、回放、收藏和进度跨设备同步，以及 P8 会话安全。
  6. 扩大自动化测试范围，提高回归效率。
  7. 继续探索 AI 辅助测试与代码审查。
  8. 根据真实用户反馈优化网站交互体验。

Beta（M6a/L3）将依据已完成的 P9 原型实现知识关卡、即时判定与解析、积分明细、成就徽章和排行榜；服务端负责判题和幂等结算，重复提交不得重复给分。

12.3 团队总结与期望

本次 Alpha 冲刺不仅是将需求转化为代码，更是一次对软件工程协作流程的完整实践。在有限时间内，我们将按照统一接口、明确分工、并行开发、及时联调、持续测试和阶段验收的原则推进工作。

团队希望通过这一过程提高软件需求落地能力、模块设计与接口协作能力、Git 协作和代码审查能力、自动化测试与质量保障能力、项目进度管理和风险应对能力，以及 AI 辅助软件开发的实际应用能力。

NULL 团队将坚持“先完成可运行的核心功能，再进行扩展；先保证正确性，再追求复杂度”的开发原则，以可验证的成果完成本次 Alpha 冲刺。

12.4 原型功能实现状态的汇报原则

最终展示与博客应使用 P1–P9 的“原型已设计 / Alpha 已实现 / 部分实现 / Beta 待实现”状态表，不得用静态原型截图冒充真实软件运行截图。所有“已实现”须附版本、Issue/PR、实际运行画面或测试日志；P9 闯关积分默认按 Beta（M6a）报告，除非有真实代码和验收证据。

十三、参考资料

  1. 邹欣：《构建之法——现代软件工程》。
  2. 阿里巴巴集团技术团队：《阿里巴巴 Java 开发手册》，终极版 v1.3.0（2017）。
  3. 阿里巴巴 Java 开发规约 P3C 开源项目：https://github.com/alibaba/p3c
  4. 阿里巴巴 Java 开发规约在线文档：https://alibaba.github.io/Alibaba-Java-Coding-Guidelines/
  5. 华为云 CodeArts Check 代码检查规则集公开文档：https://support.huaweicloud.com/usermanual-codecheck/devcloud_hlp_00116.html
  6. NULL 团队：《8 人职责分工与协作说明》。
  7. NULL 团队：《Alpha 冲刺七天执行计划》。
  8. NULL 团队前期需求分析、系统设计及数据库设计文档。

注：团队编码约定是在参考公开开发规范和工程实践原则的基础上，结合本项目实际情况自行制定；并非完整复刻上述企业规范。具体技术实现和最终执行情况以项目仓库及后续冲刺记录为准。

补充设计基线：NULL 团队《软件工程实践团队第二次作业——原型设计&需求分析》（原型 v1.0，2026-10-15）：https://bbs.csdn.net/topics/620552906

原型中 M4/M4a/M6a 的早期内部日期与本次作业七天截止时间不同；本文件执行 2026-10-23 至 2026-10-29 的课程冲刺窗口，保留原型定义的 L1/L2/L3 阶段边界。

...全文
Java面试宝典：微服务、分布式、高并发场景题实战解析 微服务架构作为现代分布式系统的核心技术，通过将单一应用拆分为多个松耦合的服务，实现了业务模块的独立部署和扩展。其核心原理包括服务注册发现、负载均衡和容错机制，基于Spring Cloud等框架可以快速构建高可用系统。在技术价值层面，微服务提升了开发效率、系统弹性和技术选型的灵活性。在实际应用场景中，结合分布式缓存、消息队列和数据库优化，能够有效应对高并发访问和数据一致性挑战。本文聚焦Java中高级面试，通过项目实战案例深入解析微服务、分布式系统和高并发编程等热点技术，帮助开发者掌握企业级场景的解题思路和最佳 阅读详情

相关推荐

介绍性部分的IO任务模板和开发人员算法的第一个冲刺_Java_C#_下载.zip

介绍性部分的IO任务模板和开发人员算法的第一个冲刺_Java_C#_下载.zip

快撑死的鱼

计算机二级C语言考试备考指南：考点解析与实战技巧

C语言作为结构化编程语言的代表，其核心原理在于通过函数模块化和指针操作实现高效内存管理。在编程教育领域，C语言的教学价值在于培养学员的计算思维和底层编程能力，广泛应用于嵌入式系统、操作系统开发等场景。数据结构与算法作为计算机科学基础，通过栈、队列、二叉树等结构体现程序设计的逻辑性。针对计算机二级考试这一标准化测评体系，本文结合历年真题分析，重点解析指针应用、函数模块化等高频考点，提供从基础语法到编程实践的完整学习路径，帮助考生建立系统的知识框架和解题策略。

weixin_30617695

网易系统开发岗笔试核心考点解析：从并发到分布式的高频技术栈

在互联网技术面试中，系统开发与后端工程师岗位的考核往往不止于算法题，更侧重对底层原理、并发编程、分布式架构以及数据库缓存等工程能力的综合考察。从操作系统到JVM，从线程池到消息队列，这些核心概念构成了高并发系统设计的基础，也是面试官判断候选人能否解决线上问题的关键。理解并发控制机制、网络通信原理以及数据一致性保障方案，不仅有助于应对校招笔试，更是日常开发中排查性能瓶颈、优化系统稳定性的必备技能。本文结合网易系统开发岗的真实考点，梳理了从基础理论到实战推演的学习路径，帮助准备进阶后端开发的工程师建立系统化的知

weixin_34417183

C++静态分析实战：Cppcheck与Clang-Tidy原理、配置与CI/CD集成指南

静态代码分析是提升软件质量、保障代码安全的关键技术。其核心原理是在不执行程序的情况下，通过解析源代码的语法结构、数据流和控制流，来识别潜在的错误模式、性能瓶颈和安全漏洞。这项技术的价值在于能将许多运行时难以复现的“幽灵”问题，如内存泄漏和未定义行为，在编码阶段提前暴露，从而显著降低后期调试成本并提高软件可靠性。在工程实践中，静态分析已成为现代CI/CD流水线中不可或缺的质量门禁，尤其适用于C++这类复杂且陷阱众多的系统级语言开发场景。本文聚焦于C++生态中两大主流工具Cppcheck和Clang-Tidy，

cuili5839

Java冲刺试题

Java冲刺试题

william毅
评论
收藏 已收藏
分享
返回顶部
NULL101010
NULL101010
202601福大-软件工程实践-W班 102 成员 231 内容
+ 加入社区