为什么不"先做表再做页面"
内容管理有九个子功能，最大的一次性做法是：先花两天把所有表建好，再花三天写全部接口，最后两天写所有页面。
这种"分层推进"有两个问题：
- 前四天没有任何可验证的东西，需求理解错了要到最后才发现；
- 风险集中到最后，页面写完才发现接口字段不够、权限码漏了，返工成本最高。
我们用的是相反的顺序：垂直切片——每个切片只覆盖一小块业务，但从表一直做到页面，当天可点、可测。
第一片：协议 / 帮助中心 / 单页
这三者结构最简单：一张主表 + 状态 + 排序 + SEO。放在第一片的作用是把整条链路打通：
建表 → 模型 → 服务（校验与状态流转）→ 控制器 + 路由 → 后台页面 → 菜单与权限种子 → 接口文档 → 冒烟。
这一片跑通后，后面两片的"模板"就固定了。实际耗时集中在链路搭建上，业务逻辑反而少。
第二片：SEO / 模板 / 栏目 / 文章
这一片是内容管理的主干，也是最需要设计判断的部分：
- 栏目是树形（物化路径），支持频道首页、列表频道、单页频道三种类型；
- 模板是可在线编辑的 HTML 文件，绑定到栏目；
- 文章挂在栏目下，支持富文本、封面、标签、置顶与推荐；
- SEO 早期是独立表，后来改为内联到内容表（见另一篇）。
一片做完的标志是：能在后台建栏目、选模板、发文章，并且前台接口能取到数据。
第三片：Banner / 装修区块 / 首页装修 / 静态化
这一片是"让站点看起来像个网站"：
- Banner 管理广告位与投放时间窗；
- 装修区块（图文、列表、富文本）组合成首页；
- 静态化把栏目页与文章页生成 HTML 文件。
静态化放在最后，因为它依赖前面所有数据的结构定型——先做静态化再做内容，等于给一个会变的模型写渲染器。
每片结束必须做的事
切片的纪律比切片本身更重要。每片结束时固定做四件：
- 冒烟：打开页面、增删改查、无权限账号被拒；
- 权限种子：菜单记录 + 权限码，缺这步客户登录后看不到入口；
- 接口文档：请求/响应字段与错误码，前端与二次开发都靠它；
- 审计：确认没有遗留的临时调试代码、没有把测试数据留在库里。
效果
三片在同一天内完成，新增文件 60 余个。更重要的是每一片结束时系统都是可用的：即使当天只完成两片，交付出去的也不是"半个内容管理"，而是"能管协议与文章的内容管理"。
这套切法后来沿用到多租户、授权、账期等模块：先把一条最薄的链路打通，再横向铺功能。相比"分层大推进"，它牺牲了一点"整体优雅"，换来的是每天都能对着真实页面判断方向对不对。