从博客到产品目录：一次站点信息架构重建

最开始我以为这是一次常见的博客改版：改导航、调首页、补 about、把产品页做得更像目录一些。但做着做着我发现，真正要处理的并不是页面样式，而是站点到底在对外说明什么。如果一个站点里只有文章，博客式归档天然就成立；按时间排序、按分类浏览，再加一页 about，已经足够让读者理解它的用途。可当站点里同时存在文章、产品、工作台、部署链路、内容系统和持续迭代的记录时，原来的博客结构就开始说不完整了。

它会把一切都压成“文章更新”这件事。这样做短期很省事，因为所有东西都能被塞进一条流里；但长期会出现一个问题：读者第一次进来时，很难知道你现在真实在做什么。产品像文章的附件，工程像零散技术笔记，关于页像事后补写的说明书。站点并没有失效，它只是越来越不诚实。对外看到的是博客，对内发生的却已经是一套公开工作现场。

这次最关键的变化，是我不再把首页理解成“最新文章列表”。一旦内容和产品同时增长，首页就会开始承担多种互相冲突的职责：它既像内容入口，又像作者介绍，又想把工作台和产品挂出来，还想顺手解释整个站点在做什么。问题不是这些目标不重要，而是它们如果没有明确分工，就会在同一层抢位置。结果就是每一块都存在，但没有任何一块真的说清楚。

我后来把问题重新改写成一句更实在的话：第一次来的读者，需要用最少的路径明白什么？答案并不是“看完所有内容”，也不是“立刻进入产品”，而是先知道这座站点的主线，再进入自己最关心的那条线。于是首页不该只是时间流，它应该先给出主线，再给出继续深入的入口；产品页不该像营销页，它应该像作品目录；about 页也不该再替布局辩护，而要直接解释这个人正在如何工作。

如果首页只保留文章流，它当然仍然可用，甚至实现成本最低。但它会天然强化一种误解：这里主要是个博客，产品和工作流只是附属。可现实并不是这样。录制视频工作台、公共内容层、搜索、RSS、发布门禁、Cloudflare 兼容、workspace 拆层，这些都不是写作之外的边角料，而是同一套工作的一部分。如果首页不承认这件事，站点就会不断把最重要的上下文藏起来。

所以我后来把首页拆成更明确的几层：先给出当前最能代表主线的 featured story，再用 highlights 展开几条次级入口，让读者知道这不是一条单一内容线；随后保留完整的热门文章流，继续承担浏览职责；再往下才是产品目录和关于说明。这种排列不是为了做得更“丰富”，而是为了让顺序更诚实。文章仍然重要，但它们不再独占整个入口。

真正稳定下来的一步，是把“导航到底服务谁”拆清楚。左栏导航负责告诉读者这座站里有哪些稳定阅读路径，因此它必须围绕更可信的五类主线展开：产品现场、工程与系统、产品判断、AI 协作、独立开发者。它不是作者给自己贴标签的地方，而是第一次来的读者用来判断“我该从哪条线进入”的地图。

产品目录则承担另一种职责。它不再是一个忽然跳出来的促销区，也不是首页主角，而是工作主线里的另一种索引。录制视频工作台排在第一位，是因为它真的是当前最成形、最能运行的产品，而不是因为它适合做 banner。这样一来，博客、产品和运行页之间的关系才会变得更自然：文章解释判断，产品页整理能力，真正运行则留在 /workspace。三者不是竞争关系，而是同一工作流的不同层。

如果只有首页改了，其他页面还沿用旧语气，读者仍然会感觉像进入了几个不同站点。about 页以前很容易滑向一种站点自解释：为什么这样分栏、为什么保留产品导航、为什么要这么分类。可这些都不是读者第一次来最关心的问题。读者真正关心的是：你是谁，你在做什么，你如何工作，我应该从哪里开始理解你。

所以 about 页后来被改成线性的作者说明页，先讲人，再讲工作，再讲方法，最后给出五条继续阅读路径。产品页和产品详情页也一样，被压回到更安静的编辑式语气里，不再像仪表盘或营销海报。只有当首页、产品页、about 页都说同一种语言，这座站点才不会像一堆各自完成的页面，而会像一个统一的公开索引。

我现在回头看，这次信息架构重建最重要的并不是页面变好看了，也不是层级更完整了，而是站点终于更准确地表达了现实工作。它不再把产品藏在博客后面，也不再把写作降格成产品的附属说明。它承认这里本来就是一个复合型工作现场：内容、产品、工程系统、AI 协作和独立开发者的长期取舍，本来就来自同一条主线。

对我来说，这种变化比“从旧首页换成新首页”更关键。因为一旦结构开始对外说真话，后续无论是补新文章、继续重写代表作、完善产品目录，还是处理发布链路和部署问题，读者都会更容易理解这些动作为什么出现在同一座站里。站点于是第一次不只是一个还能用的博客，而是一张可以持续增长的公开工作地图。