第17章　学生项目冲刺五：形成发布候选

v0.5已经具备智能能力。本周停止扩展产品范围，集中完成系统集成、故障测试、小规模试用、缺陷修复和持续集成，形成v1.0.0-rc.1。

v0.5
→ 冻结功能范围
→ 风险驱动测试
→ 故障注入
→ 小规模试用
→ 议题分级
→ 修复与回归
→ 持续集成门禁
→ v1.0-rc

发布候选表示团队认为当前版本已经满足v1.0范围，等待最后试用和开源审查；它不是“代码大致完成”的别名。

功能实现完毕不等于版本可以发布。真实设备可能仍有资源、故障和长期运行问题。发布候选通过冻结范围，把有限时间用于发现和修复阻塞缺陷，其代价是新的功能设想必须推迟。

完成本章后，应当能够：

17.1 冻结v1.0范围

从项目章程列出：

## v1.0必须
- <已经批准的核心闭环>
- <必要失败处理>
- <数据、模型和硬件追溯>
- <构建、测试和发布资料>

## v1.1候选
- <新功能和优化>

## 明确不做
- <高风险或超范围内容>

本周新建议默认进入v1.1。只有Blocker修复所必需的接口变化，才可调整v1.0范围，并由教师批准。

检查所有v1.0议题：

17.2 建立系统测试矩阵

围绕五类风险选择：

风险 测试对象 示例
功能 核心用户结果 正例产生一次反馈
误判 模型与策略 反例、主要干扰、连续事件
故障 设备和网络 传感器断开、断网、服务器拒绝
资源 设备与服务 长时运行、队列上限、存储
数据与隐私 上传、日志和访问 未授权、原始数据模式、秘密

test-matrix.md每项连接需求或风险、执行方式和证据。

17.2.1 最少测试组合

每组至少完成：

1个真实正例
1个真实反例
1个主要干扰
1个重复事件或时间边界
1个传感器/输入故障
1个网络或反馈故障
1次设备重启
1次持续运行
1项未授权访问
1次用户验收任务

实际次数和条件根据项目风险增加。

17.3 验证模型和事件效果

17.3.1 分层记录

输入层：信号和质量是否有效
模型层：模型输出和类别是什么
策略层：是否形成产品事件
系统层：事件是否送达并显示
用户层：用户是否理解并行动

错报可能来自信号干扰、模型、阈值或重复策略；漏报也可能由传感器、窗口、模型、网络或界面造成。议题标题不要在定位前写“模型错误”。

17.3.2 错报和漏报记录

| 记录ID | 场景 | 期望 | 模型结果 | 策略事件 | 用户结果 | 版本 | 证据 |
|---|---|---|---|---|---|---|---|

所有记录包含模型、策略、固件和硬件版本。数据科学课程负责进一步错误分析，项目团队负责判断产品影响和是否阻塞发布。

17.4 进行受控故障验证

故障验证前确认操作安全，不通过短路、过压或其他可能损坏设备的方法制造故障。

17.4.1 输入故障

检查系统是否停止产生有效事件、记录错误并允许恢复。

17.4.2 网络和服务故障

检查“已发送”“已确认”“待重试”和“永久失败”是否区分。

17.4.3 重启和恢复

在事件产生、上传排队和冷却期间分别重启。检查：

17.4.4 持续运行

在规定时间运行：

记录实际时长，不能用几分钟运行表述为“长期稳定”。

17.5 开展小规模用户验收

选择目标角色，在批准场景中完成2—3项任务：

## UAT-01
- 用户目标：
- 前置条件：
- 操作：
- 预期可见结果：
- 实际结果：
- 完成时间：
- 用户理解：
- 困难或误解：
- 版本：
- 是否通过：

用户反馈优先记录原话和行为，再由团队形成判断。AI可整理主题，不能把少量试用推断为普遍市场结论。

试用发现的新功能建议进入v1.1。只有核心结果无法理解或无法完成时，才阻塞v1.0。

17.6 把失败转为可修复议题

缺陷议题：

# <可观察的问题>

## 版本身份
- 产品：
- Git提交：
- 硬件：
- 固件/服务：
- 数据集：
- 模型：
- 策略：

## 环境与前置条件
-

## 复现步骤
1.

## 实际结果
-

## 预期结果
-

## 证据
-

## 初步分层
输入/模型/策略/通信/服务/用户端/未知

## 发布影响
Blocker/High/Medium/Low，理由：

先记录再修复。没有版本和复现的口头问题不能直接交给AI“优化”。

17.7 确定修复优先级

顺序：

安全和隐私
→ 数据损坏和不可恢复
→ 核心闭环失败
→ 高频错报/漏报
→ 设备恢复和网络故障
→ 使用困难
→ 体验优化

每次只修复一个有明确复现的议题。剩余时间不足时：

17.8 约束AI定位缺陷

规划请求：

请分析议题#<编号>，先不修改。

输入：
- 版本身份
- 最小复现步骤
- 第一条错误或异常日志
- 相关测试
- 对应接口和最近差异

回答：
1. 失败最可能位于哪一层；
2. 证据支持和不支持什么；
3. 还需一个什么最小实验；
4. 最小修复文件范围；
5. 必须回归哪些测试。

禁止：
- 更改验收条件
- 删除测试
- 调高资源预算
- 改变模型或阈值
- 大范围重构

完成最小实验后，再允许AI实施批准修复。检查：

git diff
python tools/project.py test

并重复缺陷复现、受影响回归和真实设备测试。

17.9 判断重构、回退和冲突

17.9.1 只做发布所需重构

重构只有在以下情况下进入本周：

重构前固定测试和资源，重构合并请求不改变产品范围、模型或策略。

17.9.2 使用已验证版本回退

若新模型、驱动或服务变化造成严重回归：

保留失败证据
→ 找到最近通过标签
→ 比较差异
→ 通过新提交恢复合格组件
→ 完整回归
→ 发布新候选

不移动旧标签，不覆盖旧模型。

17.9.3 冲突解决后重新验证双方目标

发布前分支集中合并，冲突风险上升。解决时同时阅读两个议题，保留当前批准接口，并运行双方测试。由AI提供候选合并方案时，人工核对资源、事件次数和失败路径。

17.10 建立最小持续集成门禁

本周至少自动运行：

文档和JSON语法
契约检查
秘密检查
单元和状态机测试
服务器/主机集成测试
模型包一致性
固件构建
资源预算检查

硬件在环和用户验收按条件人工执行，并在合并请求中链接记录。

配置main：

AI若通过修改持续集成规则让失败作业不再运行，该合并请求不能批准。

17.11 执行发布候选评审

候选合并请求检查：

[ ] v1.0范围冻结且全部可追踪
[ ] 自动检查全部通过
[ ] 实机成功和失败路径通过
[ ] 模型与事件效果有实际记录
[ ] 重启和持续运行结果明确
[ ] 用户验收完成
[ ] Blocker和High缺陷关闭或经教师批准处理
[ ] README.md准确说明支持和限制
[ ] 构建物能从干净提交产生
[ ] 回退到v0.5或更早版本的方法可执行

评审不通过时建立明确议题，修复后创建新候选，不在评审会上直接口头宣布“可以发布”。

17.12 发布v1.0.0-rc.1

git switch main
git pull --ff-only
python tools/project.py release-check
git tag -a v1.0.0-rc.1 -m "v1.0.0 release candidate 1"
git push origin v1.0.0-rc.1

发布候选记录：

17.13 本章小结

本章把学生项目从智能功能版本推进到发布候选。团队冻结范围，并按风险完成系统和用户验收。失败被转化为可复现议题，AI只参与受限定位与修复。

GitLab持续集成和主分支规则保证候选来自经过检查的提交。第18章将完成开源权利、安全、复现和展示准备，发布学生项目v1.0。

17.14 综合实践

  1. 冻结v1.0范围，把至少一项新增功能移入后续版本，并说明范围取舍依据。
  2. 根据项目风险设计一组故障实验，覆盖输入、设备、网络、服务或模型中的至少3类。记录状态变化和恢复结果。
  3. 组织一次小规模用户验收，把反馈转成带版本身份的缺陷议题，并确定修复优先级。
  4. 让AI协助定位一个可复现缺陷。合并请求不得删除测试或放宽验收，并须保留人工修正记录。
  5. 在干净目录复现候选，核对CI、实机记录和构建物散列，形成v1.0.0-rc.1。