菜单
规范小米 AI Native 训练营 Day5-Day6 团队大作业的开发、接续开发、已有代码逆向审计与重构、过程证据恢复、官方目录补齐、AI 协作记录、验证、GitLab 提交和答辩准备。用户提到 Day5、最后大作业、团队项目、完整代码补文档、半成品继续开发、按课程流程重构、project-template、提交自查或 6 分钟答辩时使用。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | day5-team-project |
| description | 规范小米 AI Native 训练营 Day5-Day6 团队大作业的开发、接续开发、已有代码逆向审计与重构、过程证据恢复、官方目录补齐、AI 协作记录、验证、GitLab 提交和答辩准备。用户提到 Day5、最后大作业、团队项目、完整代码补文档、半成品继续开发、按课程流程重构、project-template、提交自查或 6 分钟答辩时使用。 |
把项目整理为可复核的判断链，而不是页面或文档数量竞赛：
真实问题
→ 关键澄清
→ 本质不同的方案与反证
→ 人工取舍和非目标
→ 端到端设计
→ 最小可运行原型
→ 正常/边界/失败/回归/端到端验证
→ AI、协作和个人贡献证据
→ 可抗追问的提交与答辩
所有课程交付和说明使用简体中文。只把实际发生、可由文件或命令支持的内容写成事实。
从目标项目向上寻找训练营仓库根目录，按顺序读取：
课件/day5.pptx。day5/day5材料/学生材料/01-任务书.md。day5/day5材料/学生材料/02-提交自查清单.md。day5/day5材料/project-template-master/ 中当前阶段涉及的模板。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 |
| 正在开发，核心链路尚未完成 | 正向开发 | 从当前最近且真实的门禁继续 |
| 代码与文档都部分存在 | 混合模式 | 已完成部分按逆向审计，未完成部分按正向推进 |
| 仅要求审计或提交检查 | 只读审计 | 不改代码，输出缺口、风险和修复顺序 |
不要仅根据用户说“差不多完成”就判定完成。必须实际运行或检查。
在改代码或补文档前完成：
禁止把模板字段、计划、代码存在或用户回忆直接写成“已验证”。
以 deliverable-contract.md 的路径为准。
day5/day5材料/project-template-master/ 复制缺失文件。src/ 只放源码、运行脚本和模拟数据。prototype/ 只放原型说明和截图/录屏证据。docs/ 放诊断、方案、设计、决策、验证、AI、协作、复盘和答辩过程文档。允许保留项目工具需要的 AGENTS.md、.env.template、配置和测试目录，但不能用它们替代官方交付物。
补齐并互相引用：
docs/diagnosis/problem-diagnosis.mddocs/diagnosis/clarifying-questions.mddocs/diagnosis/assumptions-and-non-goals.md必须写清用户、利益相关方、核心冲突、约束、信息缺口、假设、非目标和可验证成功标准。
至少提出 10 个澄清问题，其中至少 3 个 P0。每个 P0 必须说明不同答案会如何改变方案、规则、范围、优先级或验证方法。无法向讲师或业务方确认时，保留为假设并说明风险，不能伪造答案。
补齐：
docs/options/solution-options.mddocs/options/tradeoff-matrix.mddocs/options/rejected-options.mddocs/decision/decision-memo.md至少比较 3 条本质不同的路线，不能只是同一方案的低、中、高配。为每条路线记录适用条件、价值、实现成本、风险、可解释性和两天可交付性。
让 AI 主动反驳当前偏好，寻找错误假设、漏判和失败场景。最终选择可以不是矩阵最高分，但必须留下人工判断、放弃理由、代价、风险和验证责任。
在 docs/design/end-to-end-system-design.md 中明确：
可使用模拟数据、伪接口或静态数据收窄外围功能，但必须在 README 和原型说明中声明。题面要求说明系统边界，不等于实现所有外围功能。
把工作映射到 docs/collaboration/role-division.md、会议行动项和 Issue。每项任务写负责人、备份人、产出、验收标准和证据位置。
原型至少真实演示：
实现时优先修复断链和证据不一致，不为增加页面数量扩张范围。修改行为前同步更新诊断、取舍或设计；修改行为后补对应验证。
AI 协作覆盖“澄清、对比、反证、实现、验证、Review”六类中的至少五类，反证或风险审查必须存在。每条高价值记录写：
时间与负责人
+ 目标
+ 输入材料和约束
+ Prompt 摘要
+ AI 输出摘要
+ 采纳内容
+ 拒绝或修改内容
+ 人工判断原因
+ 实际影响
+ 验证证据
至少留下 2 条被真实拒绝或明显修改的 AI 建议，以及至少 1 次 AI Review 后的人工修正。不得为了凑数量虚构拒绝。
团队至少保留四个真实节点：Day5 启动、方案取舍、Day6 同步、提交前复盘。会议必须有结论、分歧、行动项、负责人、验收和证据位置。逆向重构时若历史会议没有记录，不得补写伪造纪要；按 reconstruction-mode.md 标注缺口或记录当前真实复盘。
先写计划，再运行并记录实际结果。最低覆盖：
docs/validation/cases-and-results.md 必须包含环境、时间、命令或操作、输入、预期、实际、结果和修复。失败记录不得删除；至少一条失败应推动代码、设计或风险更新。
在 docs/validation/review-record.md 同时保留人工 Review 和 AI Review。只把实际通过的命令标为 PASS。
完成：
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、证据明显失真、成员无法解释贡献或存在伪造。结束时依次报告：总体状态、改动文件、运行结果、评分项证据映射、未验证项、残留风险和下一步。不得因文档数量齐全就宣称完成。