day5-team-project

name	day5-team-project
description	规范小米 AI Native 训练营 Day5-Day6 团队大作业的开发、接续开发、已有代码逆向审计与重构、过程证据恢复、官方目录补齐、AI 协作记录、验证、GitLab 提交和答辩准备。用户提到 Day5、最后大作业、团队项目、完整代码补文档、半成品继续开发、按课程流程重构、project-template、提交自查或 6 分钟答辩时使用。

Day5 团队项目全流程

目标

把项目整理为可复核的判断链，而不是页面或文档数量竞赛：

真实问题
→ 关键澄清
→ 本质不同的方案与反证
→ 人工取舍和非目标
→ 端到端设计
→ 最小可运行原型
→ 正常/边界/失败/回归/端到端验证
→ AI、协作和个人贡献证据
→ 可抗追问的提交与答辩

所有课程交付和说明使用简体中文。只把实际发生、可由文件或命令支持的内容写成事实。

先读取权威资料

从目标项目向上寻找训练营仓库根目录，按顺序读取：

1. 用户给出的题面、代码、项目说明和最新口头约束。
2. 课件/day5.pptx。
3. day5/day5材料/学生材料/01-任务书.md。
4. day5/day5材料/学生材料/02-提交自查清单.md。
5. day5/day5材料/project-template-master/ 中当前阶段涉及的模板。
6. 目标项目已有 README.md、AGENTS.md、约束、文档、测试和提交历史。

需要快速核对课程规则时读取 course-requirements.md。需要逐文件检查时读取 deliverable-contract.md。

采用以下优先级：

用户最新明确要求
> Day5 题面与任务书
> Day5 自查清单与官方模板
> 本 Skill
> 通用训练营流程
> 通用工程习惯

Day5 官方结构是特例：prototype/prototype-readme.md 和 prototype/screenshots-or-video.md 必须保留在 prototype/。不要因其他通用规则把它们移动到 docs/。

判断工作模式

先检查代码、文档、测试、版本历史和运行状态，再选择模式。

可观察状态	模式	首要动作
功能大体完成，过程文档缺失或失真	逆向重构	建立证据台账，读取 reconstruction-mode.md
正在开发，核心链路尚未完成	正向开发	从当前最近且真实的门禁继续
代码与文档都部分存在	混合模式	已完成部分按逆向审计，未完成部分按正向推进
仅要求审计或提交检查	只读审计	不改代码，输出缺口、风险和修复顺序

不要仅根据用户说“差不多完成”就判定完成。必须实际运行或检查。

门禁 0：建立事实基线

在改代码或补文档前完成：

1. 确认项目根目录、题目编号、题面技术端和角色要求。
2. 记录当前运行命令、测试命令、依赖、环境变量和外部服务。
3. 列出已有功能、代码入口、数据流、测试、截图、文档和提交证据。
4. 区分：
   • 已验证事实；
   • 有文件支持但未运行；
   • 用户陈述；
   • 当前推断；
   • 缺失或待确认。
5. 建立评分项到现有证据的缺口表。

禁止把模板字段、计划、代码存在或用户回忆直接写成“已验证”。

门禁 1：恢复官方骨架

以 deliverable-contract.md 的路径为准。

• 缺少结构时，从 day5/day5材料/project-template-master/ 复制缺失文件。
• 不覆盖已有内容，不移动老师材料，不改名核心路径。
• src/ 只放源码、运行脚本和模拟数据。
• prototype/ 只放原型说明和截图/录屏证据。
• docs/ 放诊断、方案、设计、决策、验证、AI、协作、复盘和答辩过程文档。
• 不适用项写明“不适用及原因”，不得保留空模板。

允许保留项目工具需要的 AGENTS.md、.env.template、配置和测试目录，但不能用它们替代官方交付物。

门禁 2：诊断真实问题

补齐并互相引用：

• docs/diagnosis/problem-diagnosis.md
• docs/diagnosis/clarifying-questions.md
• docs/diagnosis/assumptions-and-non-goals.md

必须写清用户、利益相关方、核心冲突、约束、信息缺口、假设、非目标和可验证成功标准。

至少提出 10 个澄清问题，其中至少 3 个 P0。每个 P0 必须说明不同答案会如何改变方案、规则、范围、优先级或验证方法。无法向讲师或业务方确认时，保留为假设并说明风险，不能伪造答案。

门禁 3：方案反证与人工取舍

补齐：

• docs/options/solution-options.md
• docs/options/tradeoff-matrix.md
• docs/options/rejected-options.md
• docs/decision/decision-memo.md

至少比较 3 条本质不同的路线，不能只是同一方案的低、中、高配。为每条路线记录适用条件、价值、实现成本、风险、可解释性和两天可交付性。

让 AI 主动反驳当前偏好，寻找错误假设、漏判和失败场景。最终选择可以不是矩阵最高分，但必须留下人工判断、放弃理由、代价、风险和验证责任。

门禁 4：确定 MVP 与端到端设计

在 docs/design/end-to-end-system-design.md 中明确：

• 至少两个技术端：通常为服务端加一个前端或客户端；
• 同一前端内各角色视图；
• 输入来源、关键字段、状态变化和输出；
• AI 的输入、输出、置信或不确定性表达；
• 哪些结果可直接采用，哪些必须人工确认；
• 空数据、冲突、误判、超时和重复提交处理；
• 操作、AI 建议与人工修改如何追溯。

可使用模拟数据、伪接口或静态数据收窄外围功能，但必须在 README 和原型说明中声明。题面要求说明系统边界，不等于实现所有外围功能。

门禁 5：拆分任务并实现最小链路

把工作映射到 docs/collaboration/role-division.md、会议行动项和 Issue。每项任务写负责人、备份人、产出、验收标准和证据位置。

原型至少真实演示：

1. 一条从输入到结果的主路径；
2. 一次核心判断或规则触发；
3. 一个边界、失败、误判或冲突场景；
4. 结果追溯到输入、AI 建议和人工判断。

实现时优先修复断链和证据不一致，不为增加页面数量扩张范围。修改行为前同步更新诊断、取舍或设计；修改行为后补对应验证。

门禁 6：记录 AI 与团队协作

AI 协作覆盖“澄清、对比、反证、实现、验证、Review”六类中的至少五类，反证或风险审查必须存在。每条高价值记录写：

时间与负责人
+ 目标
+ 输入材料和约束
+ Prompt 摘要
+ AI 输出摘要
+ 采纳内容
+ 拒绝或修改内容
+ 人工判断原因
+ 实际影响
+ 验证证据

至少留下 2 条被真实拒绝或明显修改的 AI 建议，以及至少 1 次 AI Review 后的人工修正。不得为了凑数量虚构拒绝。

团队至少保留四个真实节点：Day5 启动、方案取舍、Day6 同步、提交前复盘。会议必须有结论、分歧、行动项、负责人、验收和证据位置。逆向重构时若历史会议没有记录，不得补写伪造纪要；按 reconstruction-mode.md 标注缺口或记录当前真实复盘。

门禁 7：执行验证

先写计划，再运行并记录实际结果。最低覆盖：

• 正常场景至少 2 个；
• 边界场景至少 2 个；
• 失败或误判场景至少 2 个；
• 修改后的回归至少 1 个；
• 从输入到输出和复核环节的端到端至少 1 个；
• 题面起始线索之外，团队自行设计的边界或失败样例至少 3 个。

docs/validation/cases-and-results.md 必须包含环境、时间、命令或操作、输入、预期、实际、结果和修复。失败记录不得删除；至少一条失败应推动代码、设计或风险更新。

在 docs/validation/review-record.md 同时保留人工 Review 和 AI Review。只把实际通过的命令标为 PASS。

门禁 8：提交、贡献与答辩

完成：

• 根目录 README.md：真正问题、运行方式、Demo 主路径、验证命令、已知限制、设计摘要和 AI 概览；
• prototype/：能证明什么、不能证明什么、主路径和失败场景兜底证据；
• docs/reflection/：团队复盘、每人 150–300 字真实贡献说明和至少 3 类证据；
• docs/decision/final-recommendation.md：800 字以内的最终建议；
• docs/defense/defense-outline.md：6 分钟展示、6 分钟追问、Demo 失败兜底和个人追问卡。

答辩节奏：

问题诊断 60 秒
+ 方案取舍 90 秒
+ 端到端设计 90 秒
+ MVP 演示 120 秒
+ 验证与风险 60 秒
+ 个人贡献 60 秒

准备约束变化、AI 拒绝、当前不能证明什么和个人关键判断的证据化回答。不要让一人回答全部问题，不要临场新增无证据说法。

审计和完成判定

先运行静态审计：

python3 .agents/skills/day5-team-project/scripts/audit_day5_project.py <项目目录>

再运行 README 中的安装、启动、测试、端到端或专用检查命令。若命令需要密钥、网络或人工界面，明确记录未执行原因和替代证据。

状态定义：

• PASS：官方路径齐全、无空模板、核心链路可运行、验证实际通过、证据链一致、成员贡献可定位。
• WARNING：主要交付存在，但数量、内容、映射、复现性或历史证据仍不充分。
• BLOCKED：无可运行系统、违反题面端与角色要求、不能演示核心判断、只有最终 Demo、证据明显失真、成员无法解释贡献或存在伪造。

结束时依次报告：总体状态、改动文件、运行结果、评分项证据映射、未验证项、残留风险和下一步。不得因文档数量齐全就宣称完成。