掌中生活——凡事预则立（β冲刺计划）

目录

零、β 要做什么

α 结束时，我们的应用已经能注册登录、建记录、看详情、改状态，也能在模拟器上走完一条完整路径。但离"给别人用"还有距离：加密没做，二次验证没做，附件没有入口，提醒不会弹通知，搜索还是占位页，备份也没有。界面是能用的控件堆在一起，离"像个产品"还差一轮打磨。

所以 β 的目标定得比较具体：SRS 里的 FR-01~FR-21 全部能演示，四条交付验收场景都能走通，AC-38 逐条有记录，最后出一个 Release 签名 APK。

α 答辩我们拿了 5 份评分，平均 90.5。其中"安排计划与实现"14.1/15 最高，"测试与质量"16.8/20、"文档一致性"13.4/15 最低。这个结果和我们的自评基本一致：计划执行得不错，测试和文档还有欠账。β 的功能安排和工具流程，主要就是补这两块。

另外，α 答辩 Q&A 里我们公开说过三件事：AI 自主测试进流水线、CI 迁移自定义执行机、附件/提醒/检索/加密按契约推进。β 要接得住这三句话。接不住的部分，比如全自动的 AI 测试流水线，我们会说明放到作业 7，不装作没说过。

有不做的：OCR、邮件和账单导入、重复扣费识别、云同步、多设备、家庭共享、通用密码管理器、深色模式、PDF 批注、桌面小组件。这些都列在 P2，答辩时主动说明，不留给评委问。

一、下一阶段要改进和新增的功能

1.1 已有但不够的功能

1.2 需要新增的功能

1.3 优先级和降级方案

砍需求只砍 P1/P2，每次砍都要站会决议、记 CR、当天随笔留痕，并且同步改 PPT 和演示脚本。不能博客里说做了、演示时没有。

二、分工怎么改

α 的分工有三个问题，β 要调。

第一，PM 身上的事太多。站会、博客、CI、契约、答辩、作业提交都在一个人身上，Day1 和作业 5 答辩撞在一起时，站会只能压到 25 分钟，很多细节靠会后补。β 把构建交给胡昊，把 PPT 交给李天赐，把答辩主讲交给杨俊鑫，PM 只留计划、契约、博客、对外和调查报告。

第二，测试只有陈瀚楷一个人，而且他本机没有 Android SDK，只能做"源码拷贝 + ViewModel 桩"的等价测试。UI、通知、附件这些新交互基本没有覆盖。β 由林铭宏接手测试，他从七匹狼换过来，做过数据库和后端数据，SQL 和数据一致性比较熟，但 Android UI 和端到端测试要补，所以安排了 2 天影子跟测。

第三，UI 没有明确的负责人。吴军峰同时做列表、分类、状态 UI 和设计令牌，视觉打磨自然排到最后。β 让他专注 UI/UX、搜索和页面走查，不再接新的业务模块。

2.1 角色调整

2.2 四条新规则

1. 文件级 owner。同一个文件只能一个人负责，接口文件单独指定 owner，契约 13.5 写归属表。α 的 DateRepo 因为两个人同时实现，返工约 1100 行，这个教训不能再犯。
2. 结对。安全（李天赐 + 胡昊）、附件（杨俊鑫 + 吴军峰）、提醒（陈志 + 胡昊）。结对不是两个人一起写，是设计对一遍、review 对一遍。
3. 测试左移。林铭宏从 Day1 参加契约评审，用例跟接口一起冻结；每天 22:00 前出测试日报，写清跑了什么、发现什么、卡在哪。
4. 新成员融入。11-14 交接会，11-15 环境和资产验收，11-16 影子跟测，Day1 独立执行；陈瀚楷 11-15~17 每天留 30 分钟答疑。

2.3 个人负载

林铭宏和 PM 的任务点看起来少，是因为每日测试、缺陷跟踪、博客和统筹没有计点，贡献度里会单列。

三、工具和流程怎么改

3.1 版本控制

α 的远端有 40 多个分支，包含 mr/*/head、test、中文"测试"和几个重复的 feature/date-*，合并后大多没删。还有一次 filter-branch 差点把提交信息清空，靠 reset 回滚。

β 的规则：

• 只保留 dev（日常集成）、master（发布）和短期的 feature/{模块}-{Issue号}；
• 功能分支活不过 3 天，MR 合并后当天删；
• 文档、博客、脚本直接提交 dev，不建分支；
• 提交信息用 feat/fix/docs/test/refactor/chore(scope): 描述 (#Issue)；
• 每天 22:00 前合并到 dev，合并前本地编译、跑相关单测、git diff --check、一人 review；
• 发布打 tag（v0.8.0-beta），APK 放 release/，不覆盖历史。

3.2 构建和 CI

α 有相当一部分成员本机没有 Android SDK，三个人各自搭了一套 kotlinc/JUnit 的等价环境，脚本还不完全一样。CI 又遇到体验版构建机 30 分钟限制、gradlew 权限、JDK 缺失，三轮才跑通，完整 Android 构建没落地。

β 的做法：

• 指定一台构建机（胡昊）负责 assembleDebug 和 testDebugUnitTest，其他人不重复搭环境；
• 每天 22:00 跑一次，结果截图进随笔；构建挂了当天修；
• CI 保留"静态检查 → 单测 → 构建 → verify_db"四段；体验版构建机的限制写进 README，完整构建走本地或自建执行机；
• 版本矩阵锁定：JDK 21、AGP 8.7.3、Gradle 8.9、Kotlin 2.0.21、compileSdk 35、minSdk 26，写进 docs/环境说明.md。

3.3 测试

缺陷管理也改：全局 ID 从 B-01 起，不再按天编号（α 的 D-01 在 Day2 和 Day4 指的不是同一个问题）；单一来源 docs/测试/缺陷清单-beta.md；状态只有打开、修复中、待验证、关闭；"修了没合"不算关闭。

3.4 文档和契约

α 的 D-02 口令长度裁决后，契约改了、CR 写了，SRS 和测试期望没改，代码常量也没改，三处口径并存了五天。β 的规则是：

• 契约 v1.1 增补 D/H/I/Z/K 的接口、错误码、事件，接口先冻结再写码；
• 任何字段、错误码、页面变更，当天同步四处：契约、SRS 增量、测试期望、演示脚本；
• CR 单加"影响面 checklist"和"关闭验证"两栏，没关闭不算完；
• 设计说明书 v1.1 只写增量章节（加密、附件、提醒、搜索、备份、迁移），不重写全文；
• 文档以仓库 docs/ 为准，群里发的结论当天入库。

3.5 AI 技术员

• 提示词包 v1.1，补三条：安全红线（不输出明文/密钥/真实数据）、生成代码必须附规范自查表、禁止改契约外接口；
• 每个任务卡记三个数：AI 生成条数、人工采纳条数、发现缺陷数；
• AI 代码和人工代码同一套规范、同一个 review；
• 喂料脱敏，真实手机号、证件号、凭据一律替换；
• 每日随笔单列 AI 技术员工作，答辩时至少能拿出 3 个具体例子。

α 答辩 Q&A 说过"AI 自主测试进流水线"。β 先做三块地基：①断言基线表（口令 820、节点上限 5、提前天数 0365、掩码真值表），AI 生成断言只准引用基线；②缺陷探针资产化，D-01D-06 的探针转成 B-01B-06，每次回归先跑；③CI 第 4 阶段接口（基线表、探针、报告格式）。真正的自动拉起 diff、生成、执行、建单，放到作业 7。

四、博客计划

发布纪律：每天 22:30 前发布；CSDN 审核有延迟，重要博客提前半天；发布后把链接回填置顶集合；作业页面最晚 11-26 23:59 提交全部链接。

每篇冲刺随笔按同一个结构写：今日站会（时间、地点、主持、议题、决议、真实照片）、燃尽图、成员进展（表格，开发岗附 Issue 和签入记录，测试岗附结果截图）、AI 技术员工作、代码签入与 Issue、运行截图或录屏、明日计划与风险。站会照片每天真实拍、角度不同、可以挡脸，7 天不复用。

五、七天怎么排

5.1 日期

Day1 定在 11-14，Day7 是 11-20。后面三天收尾，11-26 提交，11-27 答辩。

如果某天临时没空，后面整体顺延一天，DayN 编号不变；但收尾不要晚于 11-22，否则答辩材料会赶。

5.2 每天做什么

5.3 燃尽

燃尽图每天由 PM 更新，实际线按"完成且验收物齐"算，不按"代码写了"算；同时标可演示场景数（0→4），两条线互相校验。

5.4 每日节奏和灵活规则

任务可以提前做，不按日锁死。谁提前完成，就补测试、补文档，或者去帮附件和验收，不新增范围。某天没空就整体顺延，DayN 编号不变，随笔按实际发布日写。唯一不能动的是 11-14 三篇博客、Day7 只回归/打包、11-26 提交、11-27 答辩。

六、完成标准

七、风险

八、最后

α 让我们明白，计划、环境、接口、测试、缺陷，任何一项偷懒，最后一天都会一起找你。β 的计划比 α 少了一点乐观，多了一点缓冲：176 个任务点、Day7 硬缓冲、每天构建、每条 AC 留痕。

我们不追求功能最多。答辩时能随便点开一个页面都不露馅，随便查一条数据都不见明文，随便问一个缺陷都能说出它什么时候被谁怎么关掉，就可以了。

附：代码仓库

https://codehub.devcloud.cn-north-4.huaweicloud.com/10668555b4754395b09a3ce886e8a3d8/software-schoolwork-lifemap