分毫不差——团队展示

分毫不差 2026-10-08 17:09:49

分毫不差——团队展示

分毫不差

八个人，一个学期，做一件事，把谁欠谁这笔糊涂账，变成一张能对得上的表。
产品叫同账。一起花的钱，用一本账算清。

这个作业属于哪个课程	2601_CS_SE_FZU
这个作业要求在哪里	软件工程实践团队作业——种子队选拔、团队展示及选题
这个作业的目标	组队，定队长、队名和分工；用 NABCD 讲选题，8 分钟内汇报；按《构建之法》第 17 章写出能执行的考核办法；做 10 分制评审表
其他参考文献	邹欣《构建之法》第 17 章人、绩效和职业道德；贡献度看工作量 × 影响力 × 不可替代性

一、队名

分毫不差

我们做的是同账，给一起花钱的人记账、结算。

队名是从自己的烦心事里长出来的。几个人一起吃饭、一起采购、一起出去玩，总有一个人先掏钱，回到群里发张截图，接着就开始拉扯。谁点的饮料要不要单算，提前走的那位算不算，三块五的零头又该谁担。多数时候这笔账最后就糊过去了，垫钱的人不好意思再提。

分毫说的是金额要算到最小单位，不差是我们对这件事的承诺。账算错一次，用户就不会再点开第二次。口号是账要算得清，代码要写得明。

这个名字好用，有三个原因。「分」是双关，既是分账这个动作，也是金额的最小单位，看一眼就知道我们在做什么。分毫不差本来就是常用成语，几乎没改，听一遍就能记住。后面做 Logo、仓库名、CSDN 账号都可以接着用，中途不用改名。

二、团队描述

我们是分毫不差，8 个人，这个学期一起做同账。要处理的就是集体消费之后那笔算不清、对不上、也不好意思再催的账。

分工是全队讨论后定的。饶恩哲做全栈，系统设计和前后端怎么接由他负责。前端两个人，叶银珍管视觉规范，circlexx 管页面结构和交互。服务端是风车和 whisper，风车同时当组长。李润君做测试，G_bamboopole 做运维，陈林祺做需求分析和文档。

技术栈我们开过一次会就定了，后面按这次走。客户端用 React Native 加 Expo，服务端用 Fastify，数据库用 PostgreSQL，前后端都写 TypeScript。八个人同时维护两套语言顾不过来，接口类型还可以直接复用。whisper 原来更熟 Java，这学期转到 TypeScript 写服务端，饶恩哲带着他过一遍。

项目体量不大，八个人的时间都放在需求、开发、测试和部署上。数据分析、产品运营这类岗位我们没有单列，岗位一多，容易变成每个人都有头衔、事情却没人扛。

组长是风车。他一边写服务端，一边管过程，周会由他主持，排期和风险台账由他维护，绩效数据也是他汇总后公示。技术上怎么定、过程上怎么推，放在同一个人手里，少转一道话。

合作上我们约了三条，公开承诺、证据说话、互相兜底。任务先写到看板上，验收标准在认领之前写清楚，每周复盘一次。谁掉队了，24 小时内就会被看见，也有人去补。到期末，每个人都应该能指着能装上的作品，说清哪一块是自己做的。我们想做成敢删自己代码的队伍。

三、队员风采

3.1 成员总览

学号	姓名 / 昵称	性格	擅长技术	兴趣爱好	期望角色	最终角色	CSDN
072403123	饶恩哲	随和、认真，喜欢独立思考，也愿意与团队交流	Kotlin、Kotlin Multiplatform、TypeScript 全栈、Rust、C++	探索新技术、体验数码产品、研究系统架构与游戏引擎原理	全栈开发、系统设计	全栈开发	饶恩哲
052406103	叶银珍	内敛慢热，执行利落	C / C++	羽毛球、音游	UI、测试	前端 UI	叶银珍
102400307	风车	务实、肯动手，遇变化愿意补位，也希望需求讲清楚	Python、FastAPI	绘画	后端	组长兼服务端开发	风车
072403324	whisper	随和、认真负责，遇到不会的会主动查资料，也愿意一起讨论	Java、Spring Boot、JavaScript、TypeScript	听音乐、看电影、旅游，研究新软件和 AI 工具	后端开发、AI 应用、前后端联调	服务端开发	whisper
102400103	李润君	认真踏实，细心耐心，报错会耐心排查，沟通主动	Python、MySQL、Git，数据处理与接口开发	游戏、运动	后端	测试与质量保障	李润君
102400201	陈林祺	细心稳重，做事有规划，善于梳理文档，耐心沟通	Java、Git、MySQL、需求分析、项目文档撰写	唱歌、跑步	文档撰写	需求分析与文档	陈林祺
102400202	G_bamboopole	安静内向，细心有耐心，执行力强，善于倾听，遇到 Bug 不急躁	C、C++、Java，Git，华为云 CodeArts，Linux 基础命令	听音乐，画画，散步	运维	运维与工程化	G_bamboopole
102400109	circlexx	淡	各项技术均有基础，仍在积累中	躺着	PM	前端开发	circlexx

表里的期望角色是报名时填的意向，最终角色是全队讨论之后的实际分工。

3.2 队员名片

饶恩哲｜学号 072403123｜全栈开发

饶恩哲的 CSDN

随和，做事认真，自己想清楚了也愿意拿出来一起改。主力是 Kotlin 和 Kotlin Multiplatform，TypeScript、Rust、C++ 也会用，数码产品、系统架构和游戏引擎他都爱钻。报名时就想做 TypeScript 全栈。现在负责系统设计，把前后端关键模块接起来，并带 whisper 过 TypeScript 服务端。

保持好奇，踏实做好每一步。

叶银珍｜学号 052406103｜前端 UI

叶银珍的 CSDN

内敛，慢热，动手快。技术底子是 C 和 C++，平时打羽毛球、玩音游。报名时想做 UI 和测试，现在负责 Figma 视觉规范、设计稿还原和组件外观，界面走查也一起看。

没有未来的未来，不是我想要的未来。

风车｜学号 102400307｜组长、服务端开发

风车的 CSDN

务实，肯动手，计划变了愿意补位，也希望需求先讲清楚。平时写 Python 和 FastAPI，爱好是画画。报名时想做后端。

现在是组长，同时写服务端。需求评审、方案和代码合并由他把关，Fastify 的接口、业务逻辑和数据也由他写，再和前端、测试对齐。周会他主持，分歧他拍板，对外找老师和助教也是他，交付的第一责任在他身上。

对象是风和海，我就有办法航行。

whisper｜学号 072403324｜服务端开发

whisper 的 CSDN

随和，遇到不会的会自己查，也愿意拉人一起看。写过 Java、Spring Boot、JavaScript 和 TypeScript，平时听音乐、看电影，新软件和 AI 工具会自己折腾。报名时想做后端，也想碰 AI 和联调。现在负责核心服务、数据库和结算算法，这学期从 Java 转到 TypeScript。

Always in beta.

李润君｜学号 102400103｜测试与质量保障

李润君的 CSDN

踏实，报错会顺着排下去，进度也会主动说。会 Python、MySQL 和 Git，喜欢游戏和运动。报名时想做后端，现在做测试，负责用例、自动化脚本和回归，重点盯金额有没有守恒、并发会不会错。

踏实做好每一段代码，认真完成每一次开发任务。

陈林祺｜学号 102400201｜需求分析与文档

陈林祺的 CSDN

细心，做事有规划，文档理得清楚。会 Java、Git 和 MySQL，平时唱歌、跑步。报名时就想写文档，现在负责用户调研、需求规格、验收标准，以及项目文档和版本记录。

日日精进，久久为功。

G_bamboopole｜学号 102400202｜运维与工程化

G_bamboopole 的 CSDN

话不多，做事细。写过 C、C++ 和 Java，用过 Git 和华为云 CodeArts，Linux 基础命令能操作，平时听音乐、画画、散步。报名时想做运维，现在负责 PostgreSQL 部署和备份、仓库与分支规范、持续集成和安装包构建。

稳步完成任务，自在从容前行。

circlexx｜学号 102400109｜前端开发

circlexx 的 CSDN

性格自评是淡，各项技术都碰过一点，爱好写的是躺着。报名时想做 PM，现在做前端，负责页面结构、交互、通用组件和接口联调，和叶银珍一起把设计稿变成能用的界面。

加油～

3.3 最终分工

角色	成员	主要职责
组长兼服务端	风车	Fastify 服务端主线；技术决策与终审拍板、排期与进度跟踪、风险台账、会议主持、分歧裁决、绩效数据汇总与公示、对外代表团队、交付第一责任
全栈开发	饶恩哲	系统设计与技术选型，前后端关键模块贯通，带服务端同学上手 TypeScript
前端 UI	叶银珍	Figma 视觉规范、设计稿还原、样式与组件外观
前端开发	circlexx	页面结构、交互逻辑、组件封装、接口联调
服务端开发	whisper	核心服务、数据库设计与结算算法实现
测试与质量保障	李润君	测试用例、自动化脚本、回归验证
需求分析与文档	陈林祺	用户调研、需求规格、验收标准、项目文档
运维与工程化	G_bamboopole	数据库部署与备份、仓库与分支规范、CI、安装包构建

四、选题描述

4.1 一句话选题

中文：给经常一起消费的在校生做一个多人共享记账和结算应用，一次活动里互相垫付的几笔账，合成最少几笔转账，谁转给谁、转多少，打开就能看见。

English: A shared-ledger app for students that merges multiple group expenses into the fewest possible transfers, so everyone sees exactly who pays whom.

4.2 选题说明书

选题说明书-同账.pdf 564.29K

五、NABCD 分析

聚餐之后的三个人

5.1 N 需求

一次活动里往往不止一笔账。好几个人轮流垫钱，有的人没参与其中某一笔，结束时却要看清谁转给谁、转多少。现在大家靠群收款、截图和计算器凑合，数字对不齐，垫钱的人也不好意思再开口催。

用户主要是和同学、室友、社团一起花钱、事后再还的在校生。一次活动至少 3 个人，场合包括聚餐、班费、社团采购、短途和宿舍公共开支。当场各自付清、没有事后对账的，以及要经手真实资金的收银和收款码，这次先不做。

算我们的用户	典型场合	这次先不做的用户
和同学、室友、社团一起花钱、事后再还的在校生	聚餐、班费、社团采购、短途、宿舍公共开支	当场各自付清，没有事后对账
一次活动 3 人及以上	有人先付，其他人后转	要经手真实资金的收银、收款码

这些办法现在都能用一点，卡点各不一样。

现在的办法	能做的	做不到的
微信群收款	对单独一笔收款。可以人均，也可以按人填金额，约 12 小时后能提醒还没付的人。人要在同一个微信群里	不管前面已经垫过的其他笔，不能把多笔抵成最少几笔转账。见爱范儿对群收款的说明 https://www.ifanr.com/app/1419506
支付宝 AA	等额人均收款	产品分析里写的是等额人均。见 https://www.woshipm.com/evaluating/1100934.html
群里发截图，再用计算器	零门槛	后面的消息把账单冲掉。有人没吃还按人头除，结果是错的
表格或备忘录	规则可以自己定	几个人同时改、在手机上对着看，都不方便

公开调查能说明大学生聚餐多、AA 常见。算错了多少、没还钱的有多少，下面两篇报道里都没有写。

来源	样本	写了什么	报道里没出现的
中国青年网转中国高校传媒联盟调查，http://news.youth.cn/sh/201603/t20160304_7702700.htm	460 名大学生	29.31% 的受访者聚会达到每周两次以上。结账方式包括发起者结账、AA、轮流买单。文中举例聚餐常为 AA，人均约 50 元	AA 占比，算错率
河北都市网，http://www.hbdsw.com/2019/1114/091614680.html	在连高校 236 人	52.54% 每月聚餐两次以上。报道称聚餐消费基本采用 AA，社团聚餐占 62.71%	没还钱的比例

下面这组数是我们自己造的验收例子，不是调查结果。三个人 A、B、C，谁都可以记一笔。

谁记	内容	谁付	怎么分	每人应付
A	餐饮 120	A	三人人均	各 40
B	交通 90	B	三人人均	各 30
C	住宿 300	C	排除没住的 B，A 和 C 人均	A、C 各 150

三笔加在一起，净额是 A −100，B +20，C +80。转账可以收成两笔，A 转给 C 80 元，A 再转给 B 20 元，同一个人要转给两个人。这时候再在群里发一次收款，盖不住前面三笔互相垫付。

5.2 A 做法

同账在做什么

从打开到结清，就这一条路。

注册登录 → 创建账本 → 邀请成员 → 各自记账 → 看流水与余额
→ 结算预览 → 正式结算并冻结账单 → 复制方案 → 逐笔登记已还
→ 整本结清只读 → 归档

账本三种状态，进行中、结算中、已结清。结清后可以归档，记录留着。一个账本最多 12 人，创建者算在里面。

一笔记账要分开三个人。记录人把这笔输进 App，付款人是先掏钱的那个，首版每笔只有一个。分摊人是该出这份钱的人，可以是全体，也可以去掉没参与的。付款人可以不是记录人，也可以不摊这一笔。最后该收钱的人按整本净额算，不一定是最初垫钱的那位。钱在微信、支付宝或线下转，同账只负责算，再登记已还。

技术栈开过一次会就定了。

层次	方案	理由
原型设计	Figma	先把页面流程、组件、异常状态定下来再写代码
移动端	React Native + Expo + TypeScript	一套代码出真机安装包。队里 TypeScript 能力集中在饶恩哲，前端两人能接上
导航	Expo Router	组织登录、账本、记账、结算等页面
服务端	Fastify + TypeScript	和客户端同语言，接口类型可以直接复用。八个人只维护一套服务
数据库	PostgreSQL	事务和约束够用，图片也能直接存
图片	独立图片表，bytea 字段	收据图片存在库里，课程项目少接一个对象存储
结算算法	净额汇总 + 状态压缩动态规划	精确求最少转账笔数

金额按「分」存，不用小数。100 元三人均分，记成 3334、3333、3333 分，加起来仍是 10000 分。多出来的分用最大余数法，余数相同就按固定的成员顺序，同一笔每次结果一样。

最少转账用动态规划求，不用贪心。先把净额加总，总和必须是 0，再把不为 0 的人拆成尽可能多、组内也能结清的小组。人数是 n，这样的组有 k 个，最少笔数就是 n − k。做完再模拟一遍，确认每个人归零、金额为正、没有自己转给自己。复杂度是 O(3^n)，所以一个账本限 12 人。12 人的最坏情况要实测，算不动就如实写。

库里要有用户、账本、成员、邀请、支出、分摊、图片、结算和操作记录。支出和分摊放在同一个事务里写。邀请码由服务端生成，重置后旧码失效。能不能看这本账，在服务端查。图片单张压到 1 MB 以内，列表里只给引用。

5.3 B 好处

省掉的是来回问和心里算。快了多少、催账有没有更容易开口，测过再写。

步骤	现在	用同账之后
记账	谁垫了谁在群里发截图，别人翻记录	每个人各自记自己垫的那一笔，付款人可以不是记录人
有人没参与	口头说这顿不算他，容易忘	记这一笔时就把他排除，应付为 0
结束	群里重算，或再发一次收款	打开结算，看到谁转给谁、多少，可以是多笔
已经转过	对不上微信记录	在对应那一行标记已转，全部标完后这笔账不能再改金额

收益方	具体好处	怎么核对	测过再写
一起消费的同学	多笔、规则不统一的账，结束时有一张转账列表	鼓山一日四个账号，系统结果和手算一致	快了多少
垫钱的人	催的是列表里的一笔	演示里能指出哪一行还没标记已转	催账成功率

5.4 C 竞争

对手	它解决什么	优势	短板	依据
微信群收款	在群里对一笔消费收款，可提醒未付	人人有微信，能真的收到钱	只管这一笔。不管之前互相垫过的账，也不能排除后再和别的笔一起抵消	https://www.ifanr.com/app/1419506 ；模式说明亦见 https://cloud.tencent.com/developer/news/918758
支付宝 AA 收款	等额把一笔钱收齐	能直接付款	分析文章写的是等额人均	https://www.woshipm.com/evaluating/1100934.html
表格、备忘录	规则自己定	灵活	多人同时改困难，手机上不好对着看	使用场景对比，没有单独产品文献
百事 AA 记账	多人账本。均分、百分比、具体金额、份额。结算可以一对一，也可以汇总抵扣，减少转账笔数	功能已经完整，还有小程序	同时做 AI 记账、多币种、预算、会员。校园一次活动用起来偏重	帮助中心 https://www.bestrie.com/help.html ；官网 https://www.bestrie.com/cn/
Splitwise	群组记账。Simplify Debts 在每人净额不变的前提下，减少要付的笔数	算法和产品都成熟	英文环境为主，国内付款习惯和网络都不贴	https://kb.splitwise.com/balances-and-expenses/what-is-simplify-debts
先放着不管	零成本	不用学	差额留在垫钱的人身上	无

下面只标同账要做的范围。

能力	微信群收款	支付宝 AA	百事 AA	Splitwise	同账要做
一次活动里多笔记账	否	否	是	是	是
每个人都能记，记录人可以不是付款人	否	否	是	是	是
某一笔排除没参与的人	可勾选这一笔的参与人	弱	是	是	是
人均、按份、按金额	人均或按人填金额	人均	均分、份额、金额、百分比	均分、金额、百分比等	人均、按份、按金额
多笔抵成谁转给谁，允许一人转给多人	否	否	有汇总抵扣	有 Simplify Debts	是
经手真实付款	是	是	以记账为主	以记账为主	否
老师装上就能自己走一遍	否，得在微信里	否，得在支付宝里	以 App 和小程序为主	有网页，不过偏英文	是，交安装包加演示机

人数一过三个，分摊又不均匀，账还不止一笔，再发一次群收款就盖不住以前互相垫过的那些。这一段我们用账本把多笔抵掉，结算页用头像、箭头和金额告诉大家谁转给谁。百事 AA 和 Splitwise 已经能算这类账，我们只做校园里一次活动，从建账本到标记结清。学期结束时，老师装上安装包，就能把同一条路径自己走完。

5.5 D 交付与验证

交出去的是移动端安装包。现场再备一台已经登录好的演示机，避免老师当场注册失败。小程序和应用商店上架，这次不写成必达。

演示按鼓山一日来走，四个账号对应四个人。

顺序	谁操作	评委应看到
1	A 创建鼓山一日，邀请 B、C、D 加入	四人都在成员列表里
2	A 记食堂 120，A 付，四人人均	每人应付 30
3	B 记门票 120，B 付，四人人均	这笔不是只有 A 能记
4	C 记车费 60，C 付，只选 A 和 C	B、D 这一笔应付 0
5	打开结算	C 转 A 30，D 转 B 60。净额 A +30、B +60、C −30、D −60
6	登记 C 已还，再登记 D 已还，结清	结清后不能再改这三笔的金额，只读并归档

净额必须和手算一致。这一天总支出 300 元，最少两笔转账。如果最少笔数暂时做不出来，可以多几笔，金额不能错。算错了的方案，笔数再少也不交付。

阶段和课程节奏对齐，不按 16 周去排推广。

阶段	选题上要能被看到的结果	这一阶段还缺的
本次	用户、功能范围、竞品、考核、技术路径	能点的账本
原型与需求	Figma 主路径原型。建账本、记一笔、结算	原型上多出来的按钮
设计与数据	能存账本、成员、账单、分摊和转账方案	只有页面、没有记录
Alpha	四个账号走完上表，结果与手算一致	只有一个人能记账
Beta	老师用安装包走同一条路径	只有截图、没有能装的包

六、团队愿景

算账本来是数学问题，到了群里常常变成人情问题。有人先垫钱，再发截图、等转账，不好意思催。这个学期把建账本、人人可记、按规则分摊、生成转账、标记结清这条路做完，金额算准。先给本校宿舍、班级和社团用。期末每个人能指出自己做的那一块，交出去的是老师装得上、数字能对上的作品。

七、团队绩效考核方案

读完《构建之法》第 17 章之后按这一套执行。代码行数、提交次数、在线时长不进分数。第一次作业全组同分，从第二次作业起用下面的办法。汇报时只讲 7.11 那三句，表留在这里。

7.1 三条基本原则

看任务有没有做完、交出去能不能用、别人离不离开这次交付。删掉冗余代码算完成。把一次改动拆成很多次提交不加分。
贡献看三件事叠在一起。做完的规模、对里程碑和别人的影响、当时换人会损失多少。
看承诺和结果对得上。只在关键模块上交付的人，可以高于一直在线、没有合并记录的人。

7.2 分数分四层，组内只定 R 和 W

层级	含义	谁定
团队项目分 P	作品整体	老师、助教
个人绩效分 R（0–100）	本阶段过程	记录加互评
贡献系数 W	组内比例，合计 100%	由 R 归一
作业折算分	课程如何把团队分落到个人	按课程规则，不在组内另造

7.3 考核维度和权重

维度	权重	看什么	不看什么
交付与质量	35%	按事先写的标准能否用、测试有没有退回	只数做了几个功能
任务规模与进度	25%	完成的点数、有没有堵住别人	只记开始或完成两种状态
协作与响应	20%	规定的会到了没有、阻塞当天有没有写明、评审有没有指出具体一步	在线时长
工程规范	12%	提交能否对上任务、构建是否通过	提交次数、代码行数
文档与展示	8%	本阶段该有的规格或复盘、演示是否按清单走通	页数

权重若要改，阶段开始前公布，浮动不超过 5 个百分点，中途不改。

7.4 个人分和贡献系数怎么算

先给五个维度打分，再合成个人分 R，最后换成贡献系数 W。抄袭、伪造记录、故意阻碍，提交老师复核，当次 R 可以记 0。

五个维度各打三档。 每维满分 100。

档	记分
达标	100
能用，但有缺陷	60，并写明理由
打不开，或对不上任务	0

交付、协作、规范、文档按验收记录打这三档。规模先算任务得分，再和本期人均比，也落进 100、60、0。

规模用点数。 认领前写验收标准。点数只用 1、2、3、5、8，超过 8 先拆开。1 点是改一处样式，3 点是一个带校验的表单或一个联表接口，8 点接近一周。意见不同只对验收边界和依赖，组长不压点。

没做完的那一笔记 0。已经合并的部分留在看板上，下周再领。当次认领的任务一笔都没有交，也没有按 7.10 提前换成其他任务，当次 R 记 0。

难度和时效分开，各只有两档，相乘，不组成四种情况。

难度	系数
普通	1.00
认领时写明要先验证技术方案	1.25

时效	系数
按时，或在原截止日期前 24 小时打过招呼	1.00
到期没说	0.60

任务得分 = 点数 × 难度 × 时效

本期人均 = 全组任务得分之和 / 8

一个人的任务得分之和达到本期人均，规模分记 100。达到人均的一半、还没到人均，记 60。不到一半，记 0。全组任务得分之和为 0 时，规模分都记 0。

普通 3 点、按时，任务得分是 3。要先验证的 5 点、按时，任务得分是 6.25。规模分不看单笔高低，看这些得分加起来够不够本期人均。

综合以上，最后这样算。 五项都按 0、60、100 记，再加权。全组只在最后把 R 归一得到 W。

R = 0.35 × 交付 + 0.25 × 规模 + 0.20 × 协作 + 0.12 × 规范 + 0.08 × 文档

解开别人的阻塞，或独立做完当时别人接不了的验证，可以在 R 上加减 2 分，理由和链接写在同一条公示里。加减后若超出 0 到 100，按 0 或 100 截住。然后再算 W。谁先提交不计分。

W = 这个人的 R / 全组 R 之和

八个人的 W 加起来是 100%，保留两位百分数。全组 R 之和为 0 时，W 都记 0，不除。

7.5 各角色看什么

同一类交付放在一起比。需求没写清时文档是关键路径，上线前测试是关键路径，环境打不开时运维是关键路径。

角色	看什么
组长兼服务端	模块能否用，会能否按期开，风险有没有记
全栈	关键路径有没有打通
前端 UI	同一套视觉有没有落到页面
前端	页面能否按原型走通
服务端	分摊和转账是否与手算一致
测试	主路径和手算例子有没有被拦住
需求文档	验收标准能否照着检查
运维	安装包能否打开，演示机能否走完鼓山一日

7.6 每周怎么跑

一次团队作业算一轮，一般不超过该次截止日期。

开始前把任务写进同一张表。编号、负责人、做完的标准、要交什么、截止日期。没写入的不加分。一条任务一个负责人。
改期要在原截止日期前 24 小时写明原因。
帮别人做的事，在帮忙的人名下新开一行，不把原负责人的完成分划走。
截止当天互评。次日公示 R 和 W。再留一天，指出任务编号，除本人外过半同意才改。
代码是否完成，以组长风车在群里确认为准。文稿和 PPT 以组长确认可以发出为准。

7.7 四个阶段更看什么

阶段	更看什么
刚组队	有没有认领，有没有把验收标准写清
需求与原型	原型和验收能否检查
实现	主路径和手算
测试与答辩	老师打开的路径，演示是否按清单

7.8 预警和贡献奖

级别	条件	处理
黄	到期未更新，也没有说明	24 小时内补计划，组长记录
橙	连续两次，或堵住别人	当周重排，全组看得到
红	伪造、抄袭、故意阻碍	按 7.4 的否决，可提交老师

课程若允许从个人满分里留出奖励，只奖三件事。解开发布阻塞、做完当时无人能替的验证、明显减少返工。获奖写明贡献和证据，人数不超过全组 20%。不按谁先提交来奖。