第18章　学生项目冲刺六：发布、展示与复盘

本周从v1.0.0-rc.1或后续候选出发，完成发布前审查。审查包括公开边界、许可证、依赖和安全。项目还要通过干净环境复现与最终实机验证。随后发布v1.0，并依据仓库证据开展展示和复盘。

最终候选
→ 公开与权利检查
→ 干净环境复现
→ v1.0发布
→ 实机展示
→ 外部反馈
→ 工程与AI协同复盘
→ 下一版本议题

展示不是脱离项目的宣传材料。产品行为、版本、指标和限制都应与仓库中的v1.0一致。

一次演示只能说明特定条件下出现了结果。正式发布还要使他人能够取得同一版本、复现过程并了解限制。可复现发布增加了整理成本，却使成果能够被审阅、维护和继续开发。

完成本章后，应当能够：

• 决定内部材料、公开源代码和发布构建物的边界；
• 核对许可证、第三方声明、模型和数据权利；
• 生成并检查依赖和软件物料清单；
• 从干净目录复现v1.0候选；
• 创建v1.0.0标签和带散列值的发布记录；
• 设计可重复、包含失败恢复的产品演示；
• 用议题、合并请求、测试和版本证据说明个人贡献；
• 记录AI参与、人工判断和返工原因；
• 把用户反馈转为后续议题；
• 形成个人工程作品集和项目后续路线。

18.1 固定最终候选

周初选择一个候选提交：

候选标签：
Git提交：
硬件修订：
固件版本：
服务器/用户端版本：
数据集：
模型：
策略：
JSON模式：

从此只接受：

• Blocker和High缺陷修复；
• 发布复现所需修复；
• 开源权利、安全和文档阻塞修复。

新功能进入v1.1里程碑。

18.2 建立公开范围

18.2.1 三类项目对象

内部开发仓库
├─ 完整开发历史
├─ 受控调研、数据和配置
└─ 公开候选内容
        ↓
公开源仓库
├─ 允许公开的源代码与文档
└─ 发布定义
        ↓
v1.0发布构建物
├─ 固件/服务包
├─ 模型或取得说明
├─ SBOM与散列值
└─ 发布说明

三者不能默认完全相同。受控数据和内部服务信息可以保留在内部仓库，但不能进入公开源仓库与构建物。

18.2.2 逐项盘点

| 路径/对象 | 来源 | 权利/授权 | 敏感性 | 公开决定 | 处理证据 |
|---|---|---|---|---|---|

覆盖：

• 自有代码；
• 第三方库和复制代码；
• 文档、图、图标和字体；
• 原理图、物料清单和结构文件；
• 测试数据和样例；
• 模型文件、模型卡和训练来源；
• 服务器地址和配置；
• 用户与调研材料；
• AI生成但由团队纳入的内容。

AI生成内容仍需团队检查来源、质量和许可证风险，不能因生成方式而自动视为可公开。

18.3 完成许可证和第三方声明

18.3.1 选择适合项目对象的许可证

根据学校和课程要求决定：

• 软件许可证；
• 文档许可证；
• 硬件资料许可证；
• 数据使用条款；
• 模型发布条件。

LICENSE说明软件或项目主体，README.md明确其他目录是否采用不同许可。无法确认权利的对象从公开版本移除或只提供取得方法。

18.3.2 第三方声明

THIRD_PARTY_NOTICES.md：

| 组件/文件 | 版本/提交 | 来源 | 许可证 | 在项目中的用途 | 声明位置 |
|---|---|---|---|---|---|

保留第三方要求的版权和许可证文本。评审实际发布构建中是否包含该组件，不能只检查依赖配置文件。

18.3.3 标准许可证标识

对项目自有且适用统一许可证的源文件，按批准结果添加标准SPDX标识。第三方文件保留自身标识，不批量覆盖。

18.4 执行安全和隐私清理

18.4.1 自动检查

python tools/secret_check.py
python tools/project.py dependency-check
python tools/project.py sbom
python tools/project.py release-check

按项目环境选择实际命令。任何检查器都不能替代人工检查。

18.4.2 人工检查

[ ] .env和本地秘密文件未跟踪
[ ] Git历史无未处理秘密
[ ] 内部地址和测试账户已替换
[ ] 设备ID和用户数据已脱敏
[ ] 默认配置遵守最小数据采集
[ ] 调试日志不输出令牌和原始敏感数据
[ ] 模型和数据公开范围与授权一致
[ ] SECURITY.md提供批准的报告入口
[ ] 发布包没有临时日志和调试构建

发现已提交令牌时，先吊销并向教师报告。是否清理历史、重新建立公开仓库或改变发布方式由维护者决定，不能只删除当前行。

18.5 完善外部使用入口

18.5.1 README.md

外部读者应能找到：

项目解决的问题
系统结构
支持硬件和版本
快速构建与运行
数据和模型取得方式
最小端到端验证
当前限制与非适用用途
贡献、安全和支持入口
许可证范围

所有命令在干净环境实际执行。README.md不写“高准确率”“低功耗”等没有版本、测量和条件的描述。

18.5.2 贡献与支持

CONTRIBUTING.md说明：

• 议题和分支流程；
• 本地检查；
• AI协同边界；
• 合并请求模板和评审；
• 模型、数据和硬件变化的额外证据；
• 个人数据和秘密处理；
• 许可证要求。

SUPPORT.md说明支持版本和范围。课程结束后无法持续响应的事项如实说明。

18.5.3 部署和回退

部署说明包含：

• 构建物版本和散列；
• 适用硬件；
• 配置与秘密；
• 安装或烧录；
• 初次验证；
• 升级；
• 回退；
• 数据迁移或兼容性；
• 故障状态。

回退必须实际执行一次，不能只写理论命令。

18.6 从干净环境复现

在新目录克隆公开候选：

git clone <公开候选地址>
cd <project>
git switch --detach <最终候选标签>
git status --short

按照README.md：

python tools/project.py doctor
python tools/project.py fetch-model <实际模型版本>
python tools/project.py verify-model <实际模型版本>
python tools/project.py release-check
python tools/project.py build

完成真实设备最小闭环，记录：

# v1.0复现记录
- 候选标签和提交：
- 环境：
- 硬件：
- 数据/模型/策略：
- 构建命令：
- 构建物SHA-256：
- 自动检查：
- 实机输入：
- 事件ID或序号：
- 用户结果：
- 回退验证：
- 未解决差异：

任何未记录的手工步骤都补入文档并形成新候选。

18.7 编写最终发布说明

AI可以从已合并合并请求整理初稿：

请根据v0.1.0到最终候选之间已经合并的合并请求和CHANGELOG.md，
按以下栏目生成发布说明初稿：
- 用户可见功能
- 硬件与固件
- 数据与模型
- 服务器和用户端
- 测试和质量
- 已知限制
- 安装、升级和回退
- 许可证和第三方材料

每一项必须引用MR或Issue编号。
不得补充未测量指标、未验证兼容性和未完成安全结论。

人工核对：

• 每个功能确实在最终候选；
• 指标与测试记录一致；
• 硬件、模型和模式版本准确；
• 已知限制未被删除；
• 散列值来自最终构建物；
• 公开链接没有权限错误。

18.8 发布v1.0.0

最终门禁：

[ ] 候选完成试用和缺陷复测
[ ] 公开范围和权利清单通过
[ ] LICENSE与第三方声明通过
[ ] SBOM与实际构建一致
[ ] 安全和隐私检查通过
[ ] 干净环境构建与实机验证通过
[ ] README.md、部署和回退准确
[ ] 最终构建物与SHA-256固定
[ ] 发布说明与候选一致
[ ] v1.0阻塞Issue为0

创建：

git switch main
git pull --ff-only
git status --short
git tag -a v1.0.0 -m "v1.0.0 first stable student release"
git show v1.0.0
git push origin v1.0.0

由标签流水线生成发布包，核对后发布到学校批准的平台。正式发布后不移动标签、不覆盖构建物；修复使用v1.0.1。

18.9 设计真实产品演示

18.9.1 演示结构

建议8—10 min：

1 min：用户问题、证据和v1.0边界
1 min：系统结构和三课程分工
3 min：真实设备成功路径
1 min：一个失败与恢复路径
1 min：模型、版本和限制
1 min：Git工作流与AI协同证据
1 min：后续议题

演示时显示：

• 真实物理输入；
• 设备版本日志；
• 同一事件在反馈链路中的身份；
• 失败状态；
• v1.0标签和流水线；
• 模型卡或限制；
• 发布入口。

18.9.2 演示必须可重复

准备：

• 固定硬件和供电；
• 已验证网络；
• 脱敏测试账户；
• 明确正例、反例和干扰；
• 设备与服务器重置步骤；
• 备用构建物及散列；
• 无网络或设备异常时的受控说明。

可以准备真实操作录制作为故障备用，但不能用录制结果冒充当场成功。现场失败时展示日志、版本和恢复过程，也属于工程能力证据。

18.9.3 不夸大模型和产品

准确表述：

“在model-x、hardware-y和测试场景z下，
本组记录到以下实际结果……”

避免：

“系统能够适应任何环境。”
“模型已经完全解决误报。”
“产品可以直接量产。”

课程v1.0是稳定的教学项目基线，不自动等于经过法规、可靠性和量产验证的商业产品。

18.10 用仓库证据说明工程过程

展示选择3—4个关键节点：

立项MR：怎样收敛项目范围
技术决策：为什么选择当前硬件或推理位置
一次AI越界：怎样用diff发现并收敛
一次缺陷Issue：怎样复现、修复和回归
v1.0流水线：怎样形成发布证据

不需要展示完整聊天记录。关键是任务、AI建议、人工判断、Git差异和验证之间的关系。

18.11 建立后续反馈入口

演示与公开后，把反馈分为：

建立v1.1里程碑，只选择经过证据支持的后续项。课程结束不要求立即实施。

18.12 复盘AI协同过程

18.12.1 从任务记录而不是印象开始

docs/retrospective/ai-collaboration.md：

| 议题 | AI承担 | 人工承担 | 接受的建议 | 拒绝或修正 | 验证 | 结果 |
|---|---|---|---|---|---|---|

按任务类型总结：

• 需求材料整理；
• 技术方案比较；
• 代码实现；
• 测试生成；
• 构建错误分析；
• 文档和发布说明；
• 一致性检查。

18.12.2 分析有效条件

对成功任务回答：

• 目标是否单一；
• 上下文是否准确；
• 允许与禁止范围是否明确；
• 是否已有接口和测试；
• 学生能否读懂差异；
• 验证是否快速；
• AI建议是否减少了重复工作。

18.12.3 分析失控和返工

常见原因：

• 议题范围过大；
• 提供了不相关或过期文件；
• 未固定模型、硬件或契约版本；
• 让AI同时修改实现和验收；
• 没有查看差异；
• 把编译通过当成产品通过；
• AI猜测数据手册、指标或接口；
• 多个成员并行修改同一核心文件；
• 自动批准提交、推送或依赖安装。

每个原因都要对应下一次可执行的改进。例如，可以把任务拆成接口与实现两个合并请求，不写“以后更认真”。

18.12.4 比较人工与AI的责任

项目中AI适合：

• 读取限定上下文；
• 生成候选方案；
• 实施小范围代码；
• 补充测试候选；
• 搜索跨文件不一致；
• 整理已存在的发布记录。

人必须负责：

• 真实用户和产品范围；
• 数据、硬件和模型事实核查；
• 安全、隐私和许可证；
• 验收与风险接受；
• 差异、实机和用户验证；
• 合并与发布。

这不是固定工具分工，而是本课程v1.0实践中形成的责任边界。

18.13 形成个人工程作品集

每位学生选择：

• 一个负责的功能议题和合并请求；
• 一条高质量评审意见；
• 一次缺陷定位和修复；
• 一项实机或用户验证；
• 一次AI建议的接受或拒绝；
• 一项跨课程接口成果；
• v1.0中的具体贡献。

为每项写：

问题
→ 我的判断
→ Git证据
→ 验证结果
→ 对产品版本的影响

作品集链接到仓库固定提交或公开合并请求，不只放截图。涉及内部数据时使用脱敏摘要。

18.14 完成项目工程复盘

项目复盘回答：

# 工程复盘

## 项目结果
- v1.0范围：
- 实际用户结果：
- 未完成：

## 版本路线
- v0.1：
- v0.5：
- v1.0-rc：
- v1.0：

## 三项关键决定
-

## 三项主要缺陷及处理
-

## 数据、模型和硬件协同
-

## Git工作流
- 最有效：
- 最大等待：
- 冲突与回退：

## AI协同
- 有效任务：
- 失控任务：
- 人工控制方法：

## 质量和限制
-

## v1.1候选
-

复盘使用议题、合并请求、流水线、测试和版本记录，不凭记忆重写过程。

18.15 本章小结

本章完成学生项目v1.0发布。团队核对公开权利和安全边界，并从干净环境复现构建和设备闭环。版本标签和散列值固定发布身份。真实演示呈现产品结果、失败恢复和工程证据。

六周项目从一个项目原点开始，经过工程基线、v0.1、v0.5和发布候选逐步扩展。AI加速了限定任务，Git、测试、实机和同伴评审确保成果能够被理解、验证和维护。

课程结束时，最重要的成果不只是一个演示原型，而是一套学生能够迁移到后续课程的开发方法：

定义问题
→ 验证最大风险
→ 建立最小闭环
→ 用AI实施小任务
→ 用Git控制变更
→ 用证据验证
→ 按版本迭代
→ 公开并持续维护

18.16 综合实践

1. 完成公开范围、许可证、第三方材料和软件物料清单审查，形成可公开内容及排除内容清单。
2. 由另一组依据README.md从干净目录复现最终候选。双方通过合并请求消除隐含步骤。
3. 设计一段可重复的真实产品演示。演示包含正常路径、一个故障和恢复过程，结果与v1.0.0保持一致。
4. 统计AI建议在不同任务中的接受、修正和拒绝情况。用数据说明AI适合的任务、人工责任和下一轮改进。
5. 形成个人工程作品集和项目复盘，并从外部反馈建立一个有证据的v1.1议题。