产品线变糊的时候，表面症状经常是“信息不够清楚”，但真正的问题往往不是少了一段解释，而是太多入口同时想证明自己重要。MakePlans 之前也有这个倾向：公共博客、产品页、workspace、更新记录、实验入口都真实存在，每一项单独看都合理。可它们一旦同时站到前台，用户看到的就不是一个产品正在形成，而是一组彼此争夺身份的模块。
小产品发糊，常常是因为每个东西都想占一级入口
独立项目很容易掉进这个坑。只要某个能力真实存在，就想给它一个完整位置；只要某段工作花了时间，就想让它在导航里被看见。这样做很有人情味，因为你知道每一块背后都有投入。但用户不关心投入顺序，他只关心第一次进来时能不能看懂：这里到底在做什么，我该从哪里开始。
MakePlans 不是一个只有落地页的工具，也不是一个纯个人博客。它有公共写作，有产品说明，有实际运行的 /workspace，也有持续的工程迭代。这个结构的价值在于文章和产品可以互相解释；风险也在这里：每个真实存在的部分都可能被误升级成产品线。
如果不主动降层，站点就会变成“每一页都很重要”。而“每一页都很重要”在用户眼里，通常等于“没有一页真的定义产品”。
我先看谁在争夺同一种认知
给产品线做减法时，我不会先问哪个功能最少用。对早期个人产品来说，使用量常常还不足以成为唯一标准。我会先问：这些入口是不是在争夺同一种认知位置？
首页到底是在解释整个 studio，还是在把人直接送进 runtime？博客是在沉淀判断，还是承担产品说明？产品页是在建立目录，还是又做了一遍首页？更新记录是在帮助追踪变化，还是抢走产品叙事中心？
只要两个模块都想回答“这里是什么”，其中至少有一个就放错层级了。
语境层、运行层、判断层要分开
我后来更愿意把 MakePlans 拆成三层看。
公共首页是语境层。它解释我在做什么、写什么、当前真实产品在哪里。
/workspace 是运行层。它不用承担所有愿景表达，只需要把白板、提词、录制与导出这件事做好。
文章是判断层。它负责解释为什么这么设计、为什么这么命名、为什么某些东西被放到更低层级。
这三层一旦混在一起，页面就会互相抢戏。workspace 会变得像品牌页，首页会变得像功能入口，文章又会像产品说明书。
真正该前置的，是离开长篇解释仍然成立的主线
我现在有一个简单标准：一个模块如果离开长篇解释，仍然能让人理解它为什么存在，它才有资格留在最前面。
对当前项目来说，录制视频工作台比很多边缘实验更能承担主线，因为它不是概念，而是正在运行的产品能力。公共博客也应该保留，但它保留的理由不是内容多，而是它持续承接产品判断、工程复盘和公开表达。至于还在探索中的方向，如果需要大量背景才能说清楚，就更适合先待在文章、周报、实验或产品目录的次级位置。
有些东西不是删掉，而是降到正确层级
做减法不是把代码、文章或想法全部删掉。更多时候，它只是降低层级、改名、合并叙事。
一个实验可以继续存在，但不必拥有一级入口；一个能力可以继续维护，但先放进产品目录的次级说明；一段过程可以写成文章，而不是包装成新的产品线。这样处理更诚实，也更利于长期维护。
对个人项目来说，这种诚实很重要。你既不需要因为某个方向未成熟就假装它不存在，也不需要为了证明自己在持续推进，就把每个分支都推成主线。
入口减少以后，表达反而会变轻
当主线明确以后，很多后续工作会变简单。首页更容易写，因为第一句话知道该解释什么；产品页更容易收束，因为它不再像另一个首页；文章也更容易选题，因为它知道自己是在补判断，而不是重复说明导航。
工程维护也会受益。入口减少，命名、路由、测试边界和跳转关系都会更稳定。很多看起来是内容问题的混乱，其实背后是信息架构没有收束。
对小站最危险的，不是少一个入口
我现在越来越确定，小产品最危险的不是入口少，而是每个入口都像首页。每个页面都想自我介绍，每个模块都想占据中心，每个方向都想证明自己成熟，最后用户反而必须先理解一堆关系，才能知道真正能做什么。
所以我给产品线做减法时，会优先砍掉抢身份的入口。不是为了显得克制，而是为了让主线自己站出来。清晰不是包装层，它本身就是产品体验的一部分。