执行清单：里程碑任务开发与交付规范

这份清单用于固化后续里程碑的标准推进方式。以后无论继续做 M5-9、M5-10，还是回头补某个场景，都默认按这份清单执行。

这份文档要解决的不是“下一篇写什么”，而是“每一轮应该按什么顺序稳定推进，保证交付物完整、可复用、可追踪”。

一、默认执行顺序

后续每一轮都严格按下面顺序推进，不跳步骤，不把自测和沉淀留到最后补：

1. 先确认本轮里程碑主题与素材来源
2. 先写任务拆解文档
3. 再写详细设计文档
4. 再进入案例文档开发
5. 再同步入口、导航和统一框架
6. 再补开发记录 / 技术博客
7. 再执行自测
8. 自测通过后再 git add、git commit、git push

如果本轮不满足这个顺序，就不算真正完成。

二、每一轮必须产出的文档

以后每个新的里程碑子阶段，至少要产出下面四类文件：

1. 案例文档

放在 11Vue学习/组件化思维/ 根目录。

作用：

• 说明本轮选题来源
• 提炼复杂度中心
• 给出推荐的重构边界
• 沉淀可复用的方法与结构

2. 任务拆解文档

放在 11Vue学习/组件化思维/docs/ 目录。

作用：

• 说明本轮目标
• 列出素材来源
• 明确拆解顺序
• 明确完成标准

3. 详细设计文档

放在 11Vue学习/组件化思维/docs/ 目录。

作用：

• 说明为什么选择这个主题
• 明确复杂度中心
• 说明与统一框架的映射关系
• 明确交付物与设计约束

4. 开发记录 / 技术博客

放在 11Vue学习/组件化思维/docs/ 目录。

作用：

• 复盘本轮背景与目标
• 记录关键决策
• 说明本轮自测方式
• 作为后续可复用的技术博客沉淀

三、每一轮的标准任务清单

步骤 1：确认主题与素材

开始前先回答四个问题：

• 本轮要扩展哪一条横向主线
• 主要素材来自哪些本地文件
• 这次是否涉及独立子项目
• 这轮最核心的复杂度中心是什么

这里继续遵循当前项目约束：

• 不直接修改带 package.json / node_modules 的独立子项目
• 只提炼核心文件、核心逻辑和方法进入文档
• 文档优先，源码子项目不动

步骤 2：先写任务拆解文档

任务拆解文档必须先于开发落地。

建议固定包含这些部分：

• 本轮目标
• 本轮对象
• 拆解顺序
• 本轮完成标准

只有任务拆解先写清楚，后面开发才不会边做边改方向。

步骤 3：再写详细设计文档

详细设计文档必须在正式开发前写完。

建议固定包含这些部分：

• 设计目标
• 为什么选择本轮主题
• 本轮案例的复杂度中心
• 与现有框架的映射关系
• 本轮交付物
• 设计约束
• 完成后的预期效果

这一步的目的，是先把边界讲清楚，再进入案例写作。

步骤 4：进入案例开发

这里的“开发”在本项目里，主要指文档化重构开发，而不是去改独立 demo 源码。

这一步至少要完成：

• 新案例文档
• 方法抽象与代码片段
• 结构化小节
• 与已有方法库风格一致的表述

默认写作要求：

• 用主动语态
• 用完整句子
• 先解释再给代码
• 代码片段只作为方法表达，不作为对子项目的直接修改

步骤 5：同步入口与导航

每次新增案例后，必须同步更新这些入口：

• 11Vue学习/组件化思维/README.md
• 11Vue学习/组件化思维/笔记.md
• 11Vue学习/组件化思维/Vue练习项目重构统一框架.md
• 11Vue学习/组件化思维/Vue重构案例导航图.md
• 11Vue学习/组件化思维/docs/00-里程碑规划.md

如果新增案例没有进入这些入口，就说明这一轮还没有真正接入方法库。

步骤 6：补开发记录 / 技术博客

开发完成后，不直接跳到提交。

必须先补一篇开发记录，至少回答这些问题：

• 为什么这轮要做这个主题
• 这轮完成了什么
• 这轮最重要的决策是什么
• 本轮自测怎么做
• 本轮结果和后续扩展位是什么

这一步既是复盘，也是后续沉淀为技术博客的正式入口。

步骤 7：执行自测

自测通过前，不进行提交。

每轮至少执行下面几类自测：

• Markdown 本地链接检查
• git diff --check
• 入口页是否已接入新案例
• docs/ 中任务拆解、详细设计、开发记录是否齐全
• 里程碑状态是否已同步到最新阶段

建议默认检查范围：

• 11Vue学习/组件化思维/*.md
• 11Vue学习/组件化思维/docs/*.md

步骤 8：提交并推送

只有在自测通过后，才进入 Git 提交流程。

默认顺序：

# 1. 暂存本轮文档
# 2. 提交本轮成果
# 3. 推送到远端

git add ...
git commit -m "docs(vue): ..."
git push origin master

这里的原则是：

• 先通过自测，再提交
• 提交信息与里程碑主题一致
• 每一轮都形成独立提交，方便后续追踪

四、文件命名规则

为了让后续扩展继续保持一致，默认沿用当前编号方式：

• 任务拆解：NN-MX-Y任务拆解-主题名.md
• 详细设计：NN-MX-Y详细设计-主题名.md
• 开发记录：NN-开发记录-主题名.md

其中：

• NN 表示 docs/ 内的顺序编号
• MX-Y 表示当前里程碑与子阶段，例如 M5-8
• 案例文档不放在 docs/，直接放在根目录

五、每一轮完成判定清单

以后每一轮结束时，都按下面清单逐项确认：

• [ ] 本轮主题和素材来源已明确
• [ ] 任务拆解文档已完成
• [ ] 详细设计文档已完成
• [ ] 案例文档已完成
• [ ] 入口页与导航已更新
• [ ] 开发记录 / 技术博客已完成
• [ ] Markdown 链接检查已通过
• [ ] git diff --check 已通过
• [ ] 已完成 git commit
• [ ] 已完成 git push

如果有任意一项未完成，就不标记该轮完成。

六、后续默认工作方式

从现在开始，后续里程碑默认遵循下面这条固定模式：

• 按 docs/00-里程碑规划.md 选下一个子阶段
• 先补任务拆解，再补详细设计
• 再写案例文档与入口接入
• 再补开发记录 / 技术博客
• 最后自测、提交、推送

也就是说，后面的推进不再是“想到什么写什么”，而是统一进入“规划 -> 拆解 -> 设计 -> 开发 -> 自测 -> Git -> 沉淀”的标准交付流。

七、这份清单的作用

这份清单真正沉淀的，不只是一个操作顺序，而是一套后续可以不断复用的交付规范。

它保证后面的每一轮扩展都具备下面这些特征：

• 有规划来源
• 有任务拆解
• 有详细设计
• 有开发结果
• 有技术复盘
• 有可追踪的 Git 节点

这样这套 Vue / Nuxt 重构方法库，才会持续长成一个结构稳定、过程可追踪、内容可扩展的长期项目。