# M7 / issue-35 开发日志：教程大纲与里程碑收束

- Issue：#62
- 里程碑：M7 展示层与内容接入：从联调壳到真实页面
- 分支：`docs/m7-issue-35-outline`
- 日期：2026-03-25

## 背景

M7 的功能性改动已经全部完成，但如果里程碑到这里就停下，后续进入新阶段时会丢掉当前阶段最重要的两类信息：

- 为什么 M7 要按这样的 issue 顺序推进
- 哪些设计取舍是阶段性结论，哪些还只是临时实现

所以在里程碑收束时，先整理教程大纲并不是“额外文档工作”，而是防止后续内容断层的必要动作。

## 本次目标

- 产出一份 M7 教程大纲
- 把 M7 的问题、取舍、拆解过程和后续衔接记录下来
- 为关闭 M7 里程碑提供文档依据

## 非目标

- 不新增功能代码
- 不修改页面交互
- 不展开到 M8 具体实现

## TDD / 测试设计

本次为文档收束任务，不涉及代码测试。

验证方式为：

- 文档 review：是否能覆盖 M7 的核心 issue 和取舍
- 导航 review：是否已把 M7 大纲纳入文档体系
- 工作区 review：确认没有引入额外功能改动

## 实际改动

- 新增 `docs/40-教程与博客/M7-展示层与内容接入从联调壳到真实页面-教程大纲.md`
- 更新 `docs/00-文档导航.md`，把 M7 大纲纳入教程与博客目录计划

## Review 记录

### 是否符合当前 Issue 与里程碑目标

符合。

本次只做 M7 里程碑级文档收束，没有扩展到新的功能里程碑。

### 是否可抽离组件、公共函数、skills 或其他复用能力

本次没有代码抽离需求，重点是阶段性知识沉淀。

### 为什么里程碑结束时要先沉淀大纲

- 因为里程碑越往后，越容易忘记当前阶段真实发生过的取舍
- 先写大纲，可以把零散开发日志整理成未来可写成文的骨架
- 即使后续重构，也能保证教程结构不散掉

## 自测结果

- 文档内容已 review
- 导航已同步
- 未引入额外功能代码改动

## 可沉淀为教程/博客的点

- 为什么开源教程型项目必须做“里程碑收口文档”
- 如何从 issue 日志反向提炼一篇可继续扩写的教程大纲

## 后续待办

- 关闭 M7 里程碑
- 开始 M8 规划
