xiaomi-ai-bootcamp

name	xiaomi-ai-bootcamp
description	用于小米 AI Native 训练营中的课程练习、个人项目、团队项目、Bug 修复、工程约束文件、docs 过程文档、Spec Coding、AI 协作日志、测试记录、提交审计和答辩准备。凡是在本项目中规划、开发、审查或提交训练营产物时使用。

小米 AI 训练营开发范式

核心原则

把“可复核交付”置于功能数量之上。让不了解项目的人只读提交文件、执行明确命令，就能判断范围、取舍、实现、验证和个人贡献。

遵守以下铁律：

1. 先定义问题和验收，再写实现。
2. 先记录方案取舍，再采用 AI 建议。
3. 只把实际执行结果写成 PASS；计划、假设和推测不得伪装成证据。
4. 代码、文档、测试和 AI 日志必须互相引用，形成证据链。
5. 任务要求高于通用模板；发生冲突时记录冲突、人工判断和验证方法。
6. 所有面向训练营的说明和产物使用简体中文。
7. 所有开发过程文件使用 Markdown，并统一写入对应项目的 docs/；没有 docs/ 就先创建。

限定作用域

• 只在当前项目及其子目录中工作。
• 不把本 Skill 或项目规则写入 ~/.agents/skills、~/.codex/skills 或用户级配置。
• 把项目级 Skill 固定在 .agents/skills/xiaomi-ai-bootcamp/。
• 把 docs/ 作为每个项目开发过程 Markdown 的唯一正文目录。
• 根目录只保留项目总览 README.md、Codex 发现入口 AGENTS.md，以及课程明确要求时的 CLAUDE.md。
• 把完整工程约束正文写入 docs/engineering-constraints.md；根目录 AGENTS.md/CLAUDE.md 只负责路由到该正文，不复制完整过程内容。
• 源码、测试代码、数据、配置和可执行原型不属于过程 Markdown，可按项目结构放置。
• 老师提供的题目原文、课程材料、模板、输入数据和项目工具属于只读输入，可保留原目录；不要把它们误判为项目自产过程文档，也不要为满足目录规则擅自移动或改写。

先读取权威资料

从当前工作目录向上确定项目根目录，然后按任务需要读取：

1. 当前题目、评分标准、提交清单和现有工程约束文件。
2. day1-demo-students/templates/、day1-demo-students/check-submission.sh。
3. day1-demo-students/day1材料/6份文件的定义.txt。
4. 个人项目：读取目标目录的作业要求、数据说明和现有 AGENTS.md/CLAUDE.md。
5. 团队项目：读取 day5/day5材料/project-template-master/ 中与当前阶段相关的模板。

不要一次性加载无关材料。资料缺失时明确指出缺失项，不凭记忆补写课程规则。

选择项目模式

可观察条件	模式	必读参考
单人完成、个人答辩或个人评分	个人项目	references/personal-project.md
有成员分工、会议、共同决策或团队答辩	团队项目	references/team-project.md
只做课程练习或 Bug 修复	个人项目的最小闭环	references/personal-project.md
仅审查提交包	按实际类型审计	对应模式参考 + references/evidence-standard.md

每次都读取 references/evidence-standard.md。无法判断模式时，先从目录、题目和提交模板中寻找证据；仍无法判断再询问用户。

执行开发门禁

门禁 0：建立事实基线

• 列出任务原文、评分项、时间限制、必交文件和现有代码状态。
• 区分“已验证事实 / 待验证假设 / 用户选择 / AI 建议”。
• 保存原始要求，不擅自把示例要求解释为强制要求或把强制要求解释为示例。

门禁 1：先写工程约束文件

1. 在对应项目根目录执行 mkdir -p docs；后续过程文档全部使用 .md 格式写入该目录。
2. 复制并按项目事实填写 assets/docs-engineering-constraints-template.md，输出为 docs/engineering-constraints.md。
3. 使用 assets/AGENTS-template.md 生成根目录 AGENTS.md，只保留读取 docs/engineering-constraints.md 的入口规则。
4. 课程明确要求 CLAUDE.md 时，再使用 assets/CLAUDE-template.md 生成根目录兼容入口。
5. 删除全部 【填写…】 占位符。
6. 写入真实安装、运行、测试、审计命令；未验证命令标记为“待验证”，不得宣称可用。
7. 把工程约束正文写成执行合同和证据索引，不复制整份 PRD 或 Design。

工程约束文件至少回答：读什么、按什么顺序做、哪些不能做、如何验证、证据写到哪里、何时算完成。

门禁 2：定义范围和验收

• 在 docs/spec.md 或 docs/prd.md 中写可验证目标、主动收窄的非目标、验收标准和边界条件。
• Day1 最小规则：目标不超过 5 条、非目标不少于 3 条、可测试验收标准不少于 3 条。
• 把每条验收标准映射到测试或 Review 证据；无法验证的表述不是合格验收标准。

门禁 3：比较方案并做人工判断

• 在 docs/ 对应的方案、设计或决策 Markdown 中提出有实质差异的方案，说明适用条件、成本、风险和两天可交付性。
• 在 docs/ai-log.md 或团队项目的 docs/ai/ 中记录采用、修改或拒绝 AI 建议的具体理由。
• 避免“AI 说得对”“全部采纳”等无效人工判断。
• 选择 MVP 时优先完整证据链，不以功能数量替代取舍质量。

门禁 4：拆分可验证任务

• 在 docs/tasks.md 中把任务拆成可独立验证的小单元；课程微练习可按约 30 分钟一个任务控制。
• 每个任务写输入、产出、负责人（团队项目）、验证命令和证据位置。
• 未写验证方式的任务不得进入“已完成”。

门禁 5：最小实现并同步证据

• 只实现当前 Spec 和 Design 覆盖的行为。
• Bug 修复遵循“复现 → 定位 → 至少两个可验证假设 → 最小修复 → 回归验证”。
• 每完成一个可验证单元，同步 docs/ 内的测试记录和必要的 AI 决策记录，不在最后凭记忆补写。
• 发现需求或设计变化时，先更新决策与约束，再改代码。

门禁 6：执行验证

• 覆盖正常、边界、失败和回归场景；团队项目另加至少一个端到端场景。
• docs/test-record.md 或 docs/validation/ 中的执行记录必须包含输入、预期、实际和结果。
• 记录运行环境、命令、日期、失败原因和修复后的复测结果。
• 测试失败时保留失败证据；不得删除失败记录来制造全绿结果。

门禁 7：提交审计

运行：

bash .agents/skills/xiaomi-ai-bootcamp/scripts/audit-xiaomi-project.sh <项目目录> <personal|team>

如果当天材料提供专用检查器，再运行专用检查器。按证据输出：

• PASS：必需证据存在、内容可复核、命令实际通过。
• WARNING：主要证据存在，但内容、映射或复现性不足。
• BLOCKED：关键文件缺失、存在未替换占位符、无法复现或测试失败。

存在 BLOCKED 时不得宣布项目完成或可提交。

维护 AI 协作记录

每条关键记录写：目的、输入、AI 建议、人工判断、验证。只记录高价值决策，不复制全部聊天。优先记录：范围收窄、方案比较、反证、风险、实现取舍、失败修复、测试设计和 Review。

团队项目还要写负责人、采纳内容、拒绝内容和实际影响，并满足团队模板中的类型覆盖要求。

输出交付结果

结束时按以下顺序报告：

1. 总体状态：PASS / WARNING / BLOCKED。
2. 已完成产物及路径。
3. 每条关键结论对应的证据路径或验证命令。
4. 尚未验证、残留风险和下一步。
5. 明确说明没有执行的测试，不用模糊措辞暗示已通过。

常见错误

错误	修正
拿到题目直接写代码	先完成工程约束、范围和验收门禁
把 tasks、spec、design、ai-log 等过程文件放在项目根目录	创建 docs/，全部改为其中的 Markdown 正文
把完整工程约束同时复制到 AGENTS.md、CLAUDE.md 和 docs	以 docs/engineering-constraints.md 为唯一正文，根目录文件只做路由
把模板占位符当成交付内容	用项目事实替换，审计后再提交
用复杂功能争取高分	优先补齐可复核证据和人工取舍
写完代码才补 Design、测试记录和 AI 日志	在每个门禁结束时同步证据
所有 AI 建议都写“采纳”	记录筛选、修改、拒绝及理由
README 命令无法复制执行	在干净环境实际运行并记录结果
工程约束文件堆积项目介绍	保留执行顺序、边界、命令、证据路由和完成定义