# M9：主题边界到共享 UI —— 从可用到可继续设计（教程大纲）

## 一、这篇内容写给谁

- 已经完成 `M1 ~ M8`，项目进入“能跑、能联调、能展示”阶段的开发者
- 想继续把项目从“功能闭环”推进到“体验基线更稳定、后续更容易设计”的开发者
- 想学习如何在不做大重构的前提下，小步收住主题、展示和共享 UI 边界的读者

## 二、M9 要解决什么问题

M8 结束后，项目已经具备：

- `admin / web / server` 三端最小闭环
- 草稿 / 发布流持久化
- 双语内容可真实读取
- 导出链路可用

但体验层仍然存在明显断层：

- `web / admin` 的主题基线还不统一
- 后台首页虽然能用，但信息架构仍偏联调壳
- 公开简历页能展示真实内容，但视觉层次和阅读节奏还不够像“成品页面”
- 两端开始出现重复展示结构，继续复制会加大后续维护成本

所以 M9 的本质，不是扩业务，而是把项目从“能工作”推进到“有稳定体验基线、可以继续设计”。

## 三、M9 的阶段边界

### 本里程碑做什么

- 建立统一主题 tokens 与 `light / dark` 最小闭环
- 整理后台首页信息架构，形成更像控制台入口的页面壳
- 升级公开简历页视觉基线与阅读节奏
- 沉淀最小共享展示原语，为后续设计演进做准备

### 本里程碑不做什么

- 不做多模板系统
- 不接入 Figma 精修稿
- 不做商业版主题体系
- 不做完整组件库
- 不扩展新的核心业务模块

## 四、M9 的 issue 拆解思路

### issue-42 共享主题 tokens 与 light/dark 最小闭环

- 为什么体验层升级要先收主题基线
- 为什么把主题状态和持久化先收到 `packages/ui`
- 为什么当前只做 `light / dark`，不抢跑到 `system` 或多模板

### issue-43 admin 后台信息架构与仪表盘壳整理

- 为什么后台首页要先解决“信息区 / 工作区 / 动作区 / 状态区”的边界
- 为什么当前不直接引入现成 admin 模板
- 如何让 `admin / viewer` 差异在页面层更容易被理解

### issue-44 web 公开简历页视觉基线升级

- 为什么先升级公开页阅读节奏，而不是直接进入模板化
- 如何在不增加业务字段的前提下，让页面更像公开成品
- 为什么视觉升级不能只停在 CSS，而要补信息层次

### issue-45 packages/ui 最小共享展示组件沉淀

- 什么时候值得开始抽共享展示原语
- 为什么当前抽 `Surface / Intro / Stat / Pill`，而不是一口气做完整组件库
- 如何让共享层保持轻量，又能减少 `web / admin` 的重复结构

### issue-46 教程大纲与里程碑收束

- 为什么里程碑结束时必须及时写教程大纲
- 如何把开发日志整理成后续可继续展开的系列文章
- 怎样把“已完成边界”和“后续规划”讲清楚，避免文档结构漂移

## 五、M9 的关键设计取舍

### 1. 先收主题边界，再做体验升级

- 如果主题变量、切换逻辑和持久化入口还在各自散落，后续每次改 UI 都会重复判断“主题到底归谁管”
- 所以 M9 第一件事不是改页面，而是先让 `web / admin` 站在统一主题基线上

### 2. 先做“可解释的页面壳”，再追求“更漂亮的页面”

- 后台首页先解决信息架构问题
- 公开页先解决阅读节奏和页面主次问题
- 这样后续无论是继续做视觉升级，还是接设计稿，都不会回到“边做边找结构”的状态

### 3. 先抽展示原语，不急着抽成品组件

- 当前 `web / admin` 共享的主要是底层展示骨架
- 路由语义、权限语义、简历业务语义仍然明显不同
- 所以 M9 选择先抽基础原语，而不是把业务组件整体塞进 `packages/ui`

### 4. 体验层升级不等于模板系统起步

- 当前阶段已经开始考虑后续模板化与多主题扩展
- 但 M9 刻意只做“边界与基线”，不把模板系统提前做成“半成品”
- 这能避免教程节奏被大需求拖散

## 六、M9 完成后的项目状态

- `packages/ui`：已有共享主题入口与最小展示原语
- `apps/admin`：后台首页拥有更清晰的信息架构与角色边界提示
- `apps/web`：公开简历页具备更完整的题头、信号区和阅读节奏
- `apps/server`：继续维持唯一业务后端，不被前端体验升级反向污染

## 七、建议展开成系列文章的章节

### 文章 1：为什么体验层升级要先收“主题边界”

- 重点讲主题 tokens、状态逻辑和应用接入的职责划分

### 文章 2：后台首页为什么应该先整理信息架构，而不是先换模板

- 重点讲教学型后台的组织方式与角色边界表达

### 文章 3：公开简历页如何从“验证态页面”升级到“可展示页面”

- 重点讲题头、信号区、阅读节奏和视觉主次

### 文章 4：什么时候该抽共享展示原语，什么时候不该直接做组件库

- 重点讲共享层抽象时机与边界控制

### 文章 5：如何在不做大重构的前提下，逐步把项目拉到“可继续设计”的状态

- 重点讲里程碑节奏、小 issue 推进和教程型仓库的过程感

## 八、推荐引用的开发日志

- `docs/30-开发日志/M9-issue-42-共享主题-tokens-与-light-dark-最小闭环.md`
- `docs/30-开发日志/M9-issue-43-admin-后台信息架构与仪表盘壳整理.md`
- `docs/30-开发日志/M9-issue-44-web-公开简历页视觉基线升级.md`
- `docs/30-开发日志/M9-issue-45-packages-ui-最小共享展示组件沉淀.md`

## 九、M9 刻意没做什么

- 没做多模板切换
- 没做完整设计系统
- 没做 Figma 精修落地
- 没做新的后台业务模块
- 没把共享层抽到难以解释的程度

## 十、后续衔接建议

- `M10` 可以继续评估模板化、视觉精修或更完整后台体验
- 但无论进入哪条线，都建议继续守住当前节奏：
  - 先定义边界
  - 再拆小 issue
  - 先做基线
  - 再做增强

- 同时保持一个原则：
  - 后续扩展要建立在 M9 已收住的主题边界、展示边界和共享边界之上，而不是重新打散
