| name | xiaomi-ai-bootcamp |
| description | 用于小米 AI Native 训练营中的课程练习、个人项目、团队项目、Bug 修复、工程约束文件、docs 过程文档、Spec Coding、AI 协作日志、测试记录、提交审计和答辩准备。凡是在本项目中规划、开发、审查或提交训练营产物时使用。 |
小米 AI 训练营开发范式
核心原则
把“可复核交付”置于功能数量之上。让不了解项目的人只读提交文件、执行明确命令，就能判断范围、取舍、实现、验证和个人贡献。
遵守以下铁律：
- 先定义问题和验收，再写实现。
- 先记录方案取舍，再采用 AI 建议。
- 只把实际执行结果写成 PASS；计划、假设和推测不得伪装成证据。
- 代码、文档、测试和 AI 日志必须互相引用，形成证据链。
- 任务要求高于通用模板；发生冲突时记录冲突、人工判断和验证方法。
- 所有面向训练营的说明和产物使用简体中文。
- 所有开发过程文件使用 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，可按项目结构放置。
- 老师提供的题目原文、课程材料、模板、输入数据和项目工具属于只读输入，可保留原目录；不要把它们误判为项目自产过程文档，也不要为满足目录规则擅自移动或改写。
先读取权威资料
从当前工作目录向上确定项目根目录，然后按任务需要读取：
- 当前题目、评分标准、提交清单和现有工程约束文件。
day1-demo-students/templates/、day1-demo-students/check-submission.sh。day1-demo-students/day1材料/6份文件的定义.txt。- 个人项目：读取目标目录的作业要求、数据说明和现有
AGENTS.md/CLAUDE.md。
- 团队项目：读取
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：先写工程约束文件
- 在对应项目根目录执行
mkdir -p docs；后续过程文档全部使用 .md 格式写入该目录。
- 复制并按项目事实填写
assets/docs-engineering-constraints-template.md，输出为 docs/engineering-constraints.md。
- 使用
assets/AGENTS-template.md 生成根目录 AGENTS.md，只保留读取 docs/engineering-constraints.md 的入口规则。
- 课程明确要求
CLAUDE.md 时，再使用 assets/CLAUDE-template.md 生成根目录兼容入口。
- 删除全部
【填写…】 占位符。
- 写入真实安装、运行、测试、审计命令；未验证命令标记为“待验证”，不得宣称可用。
- 把工程约束正文写成执行合同和证据索引，不复制整份 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。
团队项目还要写负责人、采纳内容、拒绝内容和实际影响，并满足团队模板中的类型覆盖要求。
输出交付结果
结束时按以下顺序报告：
- 总体状态：PASS / WARNING / BLOCKED。
- 已完成产物及路径。
- 每条关键结论对应的证据路径或验证命令。
- 尚未验证、残留风险和下一步。
- 明确说明没有执行的测试，不用模糊措辞暗示已通过。
常见错误
| 错误 | 修正 |
|---|
| 拿到题目直接写代码 | 先完成工程约束、范围和验收门禁 |
| 把 tasks、spec、design、ai-log 等过程文件放在项目根目录 | 创建 docs/，全部改为其中的 Markdown 正文 |
| 把完整工程约束同时复制到 AGENTS.md、CLAUDE.md 和 docs | 以 docs/engineering-constraints.md 为唯一正文，根目录文件只做路由 |
| 把模板占位符当成交付内容 | 用项目事实替换，审计后再提交 |
| 用复杂功能争取高分 | 优先补齐可复核证据和人工取舍 |
| 写完代码才补 Design、测试记录和 AI 日志 | 在每个门禁结束时同步证据 |
| 所有 AI 建议都写“采纳” | 记录筛选、修改、拒绝及理由 |
| README 命令无法复制执行 | 在干净环境实际运行并记录结果 |
| 工程约束文件堆积项目介绍 | 保留执行顺序、边界、命令、证据路由和完成定义 |
