先想清楚站点要承载什么内容，而不是先写页面

Tutorial Path

从 0 搭建一个可持续写作的 Next.js 个人网站

当前位置：03 / 10

先决定网站里有什么，再决定页面长什么样。

如果你一开始就画首页、做导航、排模块，最后最常见的结果是：页面看起来已经成型，但每次真正要发内容时都发现放不进去。因为页面只是壳，内容模型才决定了这个网站能不能长期扩展。

为什么我不建议一上来只做“文章”一种类型

很多个人网站把所有输出都塞进博客里，短笔记、项目复盘、系列教程、近况更新全部混在一起。短期内这样最省事，但长期看问题很大：

• 读者不知道什么是完整文章，什么只是过程记录。
• 站内搜索结果会混杂不同粒度的内容。
• 分类和标签会被迫承担本不属于它们的职责。

所以我更推荐至少拆成三类：blog、projects、notes。

三类内容分别解决什么问题

blog 负责完整表达。它适合系列教程、深度复盘、系统化说明，读者预期是“我愿意花几分钟完整读完”。

projects 负责结果展示。它不是另一种博客，而是把一个阶段成果压缩成更清晰的“目标、方案、价值、现状”。别人想快速理解你做过什么时，项目页比文章更直接。

notes 负责低成本记录。它可以是清单、速查表、路线图、阶段结论。它的价值不在于精雕细琢，而在于帮助你把零散认知快速沉淀下来。

页面结构应该反过来服务内容模型

当内容模型清楚之后，页面设计反而容易了。因为你知道：

• 首页要做的是建立总览和入口，不是塞完全部内容。
• 列表页要按内容类型区分节奏，而不是做一个“万能列表”。
• 详情页的展示方式可以根据内容类型调整，比如项目页强调结果，笔记页强调速读。

这意味着我们不是“先有页面，再把内容塞进去”，而是“先有内容类型，再让页面去适配它们”。

这一篇决定了后面很多技术实现

一旦你接受 blog / projects / notes 三分法，后面的很多设计就自然展开了：

• 目录结构会拆成 content/blog、content/projects、content/notes。
• frontmatter schema 不再只有一套。
• 分类和标签要允许跨内容类型复用，但又不能失去规范。
• 首页、搜索、RSS、SEO 都会变成围绕“多类型内容集合”来设计。

小结

网站不是页面的集合，而是内容结构的可视化结果。先把要承载的内容想清楚，后面的路由、组件、SEO 和后台能力才不会失焦。下一篇我们就把这个内容模型落到 App Router 的实际目录和路由结构里。