ELEC5620 Stage 2 要求总结：评分、Jira、源码提交与现场部署
ELEC5620 Stage 2 要求总结
Stage 2 要交付一个基于 Stage 1 需求与架构的可运行原型，并向扮演投资者的 tutor 演示 AI-native company。这一阶段共 20 分，核心是实现、Agent 能力、敏捷过程和先进技术的有效应用。现场还要用 Canvas 中提交的源码重新部署。
本文于 2026 年 10 月 22 日核对悉尼大学 Canvas 课程 ELEC5620（课程 ID 74323）。以下区分官方要求、评分细则和准备建议；后续调整以 Canvas 最新通知为准。所有时间均为 Australia/Sydney（AEDT，UTC+11）。
1. 先确认提交时间和交付形式
| 项目 | 当前 Canvas / 官方文件信息 |
|---|---|
| 提交入口 | Stage 2 Code Submission |
| 总分 | 20 分 |
| 形式 | 小组作业，线上上传，允许的文件扩展名为 zip |
| 开放提交 | 2026 年 10 月 26 日 00:00 |
| 正式截止 | 2026 年 11 月 1 日（星期日）23:59:59；评分 PDF 表述为当日 11:59 PM |
| 入口关闭 | 2026 年 11 月 6 日 23:59:59 |
| 演示 | Week 13 / final week；本次查到的文件未给出各组具体时段 |
| 现场运行依据 | 从 Canvas 下载已提交源码，现场部署 |
| 贡献声明 | 附 Stage 2 Group Contribution Statement；未附则按全组等贡献处理 |
入口关闭时间不等于提交截止时间。 11 月 6 日仍可访问或上传，不能据此认定延期或免除迟交处理；本次材料未说明具体迟交扣分规则。
当前 Stage 2 作业描述为空，但有完整的在线 rubric。已核实的交付要求是源码 ZIP、贡献声明和现场演示；本次材料没有另行规定 Stage 2 报告、视频、幻灯片的页数或时长，不能沿用 Stage 1 的「8 分钟视频」要求。
2. 20 分如何分配
官方 Stage 2 评分 PDF 与 Canvas 在线 rubric 的四项总分一致：
| 评分项 | 分数 | 需要证明什么 |
|---|---|---|
| Stage 1 需求与设计的实现 | 7 | 原型实现的完整性、覆盖范围、测试和用户体验 |
| AI Agent 能力 | 4 | 感知、决策和交互确实融入系统，并产生可说明的改进 |
| Agile 开发经验 | 4 | 迭代、反馈、协作及相应过程证据 |
| 先进技术应用 | 5 | 技术选择合理、真正集成，并能说明效果 |
| 合计 | 20 |
2.1 功能与实现：7 分
PDF 要求以 Stage 1 的需求与设计为基础开发原型；项目总说明还要求实现大部分模型。Canvas rubric 将这部分具体化为功能与特性的完整性：
| 档位 | 分数 | 要点 |
|---|---|---|
| Excellent | 7 | 全部功能完整实现，充分测试，包括边界情况；用户体验流畅，无明显问题 |
| Good | 5 | 几乎全部功能实现并测试，仅少量问题，主要用户场景运行良好 |
| Satisfactory | 3 | 大部分关键功能实现，做过基本测试，但仍有缺口 |
| Basic | 2 | 仅实现部分基础功能，关键功能缺失，可能有明显缺陷，测试较少 |
| No Marks | 0 | 多项关键功能缺失或有严重缺陷；该档描述还提及缺少自动化测试 |
准备建议： 建一张「Stage 1 需求 / 用例 → 实现模块 → 验证证据 → 演示步骤」对应表。对尚未实现或发生调整的设计如实说明，并准备正常流程与关键失败场景的验证结果。这里的对应表是整理证据的方法，不是官方新增的提交模板。
2.2 Agent 能力：4 分
需要演示的是 Agent 如何感知输入、做出决策，以及与内部组件和外部系统交互。项目总说明特别强调 LLM 对这些能力的增强。
Canvas 的满分描述要求 Agent 充分融入系统，明显提升这些能力，并以详细反馈或数据支持改进。3 分档强调有效集成和使用反馈优化；2 分档是基本支持、效果有限且有部分改进；1 分档的作用有限或不稳定；0 分档则是能力差或未体现。
准备建议： 选择一条真实业务链路，展示输入信息、角色分工、决策依据、工具调用、执行结果及反馈如何影响下一步。演示时能把各个 Agent 的工作和 Stage 1 模型对应起来，并说明失败时系统怎样处理。
2.3 Agile 过程：4 分，明确要求 Jira
Stage 2 PDF 明确要求每组使用 Jira 管理协作并实践 Agile。Canvas rubric 的满分档进一步要求详细记录迭代、burn-down charts（燃尽图）、user stories 和 feedback loops，体现团队协作及持续改进。低一档的差别主要在于实践、文档和反馈闭环是否充分。
Lab 8 给出的实践内容包括：
- Sprint Planning：排序、拆分任务、分配责任。
- Daily Stand-up：说明已完成事项、当前工作和阻碍。
- Sprint Review：回顾交付结果，向 tutor 等利益相关者收集反馈。
- Sprint Retrospective：总结有效做法和下一轮改进。
- 用 Jira 管理 user stories；采用
As a [user], I want [goal], so that [reason]格式。 - 为每个故事定义 Definition of Done，考虑自动或手工验证方式，按 MoSCoW 分类。Lab 8 原文列的是 Must-have、Should-have、Could-have、Would-like-to-have。
Lab 9 要求继续做 Review 和 Retrospective，并根据反馈细化 Jira stories。
准备建议： 保存真实的 sprint、故事、任务状态变化、燃尽图、review / retro 记录，以及「收到什么反馈 → 如何改任务 → 原型发生什么变化」的证据。只展示一个最终全是 Done 的看板，难以体现完整的迭代过程。材料应反映实际发生过的工作，不要事后虚构会议或任务历史。
2.4 先进技术：5 分，注意 rubric 的数量歧义
评分 PDF 列举了应用框架（React、Flutter 等）、移动或 IoT 等新设备、云服务、CI/CD 或 Kubernetes 等部署系统，以及新的 AI 模型、工具或技术。列表并非封闭清单；能论证技术使用有效，未在课上讲过的技术也可以考虑。
但 Canvas 在线 rubric 还有数量条件，且存在明显的不一致：
| 档位 | 分数 | 在线 rubric 写出的最低数量 | 同时强调的效果 |
|---|---|---|---|
| Excellent | 5 | 至少 6 项 | 充分集成，明显改善性能、扩展性和可维护性，数据支持效果 |
| Good | 4 | 至少 5 项 | 有效集成，改善性能、响应时间或扩展性，有数据支持 |
| Satisfactory | 3 | 至少 3 项 | 有应用，但潜力未充分发挥、性能影响有限 |
| Basic | 2 | 至少 4 项 | 使用适当，有性能或扩展性改善，但总体影响有限 |
| No Marks | 0 | 未列数量 | 使用有限或无关，未能说明可测量的性能改善 |
3 分档的最低数量是 3，2 分档却是 4；PDF 也没有规定怎样计数。因此，不能自行把它修正成一套递增规则，也不能假设装了六个库就能拿满分。应向 tutor 确认：哪些算独立技术、同类框架或模型能否分别计数，以及 3 分和 2 分档数量是否有笔误。
准备建议： 为实际使用的每项技术记录「用在何处 → 解决什么问题 → 为什么选择它 → 有什么效果数据」。数据应来自实际测量；没有测量的部分如实注明。先确保业务原型可靠，再评估技术选择是否有足够的创新性和效果证据。
3. Week 13 现场部署：以 10 月 13 日澄清公告为准
官方 部署澄清公告 对评分 PDF 的现场部署要求作了补充：
| 问题 | 官方澄清 |
|---|---|
| 能否用自己的电脑？ | 可以 |
| 能否提前准备环境？ | 可以提前安装必要工具和依赖、准备开发环境 |
| 代码从哪里来？ | 现场从 Canvas 下载已提交的源代码，并据此部署 |
| 有手机应用怎么办？ | 必须现场由提交的源码构建并安装应用，不能只展示预装版本 |
| 手机应用的后端呢？ | 关联后端也必须由提交的源码现场部署 |
| 网络能否自备？ | 可以使用自己的网络，包括个人热点；要保证应用、后端和外部 API 互通 |
| 是否计入部署准备时间？ | 演示前会额外分配部署时间；公告未给出具体分钟数 |
这意味着可以提前装好运行时、编译器、SDK 和依赖；现场仍需证明提交的那份代码可以构建和运行。对于含移动端的项目，单独展示商店包或已安装应用不满足公告要求。
建议做一次完整演练： 上传最终 ZIP 后，从 Canvas 下载到一个新的工作目录，按文档配置环境并启动所有服务，再跑完准备演示的业务场景。这样能发现漏文件、硬编码本机路径、未提交代码以及前后端版本不一致等问题。
4. 贡献声明怎么填
Stage 2 评分 PDF 的第二页就是 Stage 2 Group Contribution Statement。要求包括：
- 填写 Group Number。
- 每名成员的姓名和 Student ID 放在同一列。
- 按四个评分项分别填写各成员贡献百分比；每一个评分项的一行都必须合计 100%。
- 未使用的成员列留空。
- 在下方逐人说明具体任务与交付物，可按需要增加文字。
这不是只写一行全项目贡献比例。四个维度对应的分工可能不同，应分别填写并由小组核对。PDF 明确说明：不附贡献声明时，默认全组成员贡献相同。
当前线上入口只接受 ZIP。把完成的贡献声明随源码一并放进 ZIP，是与这些要求兼容的准备方式；本次查到的材料没有规定声明必须使用的文件名、额外独立入口或签名格式。
5. AI 辅助开发是否允许
2026 年 9 月 21 日悉尼时间发布的 Stage 2 coding agent 邀请公告 鼓励各组用 vibe-coding 实现项目，但明确说明不是强制要求。可以使用个人 AI 订阅，也可以自愿申请课程提供的 coding agent 资源；参与相关项目是自愿的。
Lab 9 还介绍了 Campus Qwen / ELEC5620 AI Proxy，并鼓励用 OpenCode 辅助生成、审查和调试项目代码。这些是开发支持资源。无论代码通过何种方式编写，提交的原型仍需满足功能、Agent 能力、敏捷过程和现场部署要求。
6. 提交前检查清单
以下是依据上述要求整理的操作建议，不是额外评分项：
来源与相关笔记
以下 Canvas 链接通常需要课程访问权限，本文不转载个人提交记录、组员身份或课程访问凭据。
- Stage 2 Code Submission 与在线 rubric：时间、ZIP 格式、分组设置及评分档位。
- ELEC5620 Project Stage 2 Marking Criteria.pdf：两页，包含四项评分、现场部署要求及贡献声明模板。
- Clarifications on Stage 1 Interviews and Stage 2 On-site Deployment：2026 年 10 月 13 日，本文使用其中 Stage 2 部署部分。
- Project Description.pdf：项目背景与 Stage 2 总体目标；其中概括性截止说明，应结合当前作业和专门评分文件中的明确日期阅读。
- Lab 8 与 Lab 9：敏捷实践、Jira、user stories 及 AI 开发支持资源。
- Invitation to using our in-house deployed coding agent for project stage 2：AI 辅助开发鼓励与自愿参与说明。
相关：[[26-S2-Course/ELEC5620/ELEC5620-Stage1-Marking-Criteria-and-Lab3|Stage 1 评分标准与需求建模]]、[[26-S2-Course/ELEC5620/ELEC5620-Project-Guide-Tutorial01-Lab01|项目指南]]。