写产品文章时，我更在意句子能不能形成判断

写产品文章时，最容易得到的一种“安全感”就是信息完整。你可以把功能点列清楚，把版本变化写出来，把页面结构讲一遍，把背景补足，读完之后读者也许不会说你漏了什么。但这并不等于文章已经成立。很多产品文章的问题从来不是信息不够，而是句子没有形成判断。它们像一份比较礼貌的说明书，什么都交代到了，唯独没有告诉读者：作者到底认为什么重要，为什么这一步应该这样做，而不是那样做。

对 MakePlans 这种公开迭代中的项目来说，这个问题尤其明显。因为站点里的很多变化，本来就不是“增加了一个功能”那么简单，而是带着明确取舍的调整。比如录制视频工作台不再默认占据首页，而是回到产品导航第一位；比如公共博客的分类从过去偏弱、偏自我命名的栏目，重构成“项目实战、产品方法、AI 工作流、工程拆解、内容与表达、工具评测”这样的六个主分类；再比如部署链路里，原来放在 src/proxy.ts 里的行为后来迁进 next.config.mjs，是为了避免 Cloudflare / OpenNext 场景下的代理层阻塞。这些都不是纯信息，它们本身就是判断。文章如果不把这层判断写出来，只写“改了什么”，读者永远只会看到结果，不会理解方法。

很多人一听“有判断”，会以为是要把口气写得更强硬、更像宣言。但真正有用的判断，不在语气，而在取舍是否清楚。一个句子有没有判断，最简单的标准不是它听起来多有气势，而是它有没有回答“为什么选这个，不选那个”。

比如把录制工作区从默认首页移开，这件事如果只写成“现在产品被放进产品导航第一位”，当然也能传达事实。但这样的句子太平了，它没有说出这个决定解决了什么。真正有判断的写法，应该进一步说明：首页首先是语境层，而不是操作层；一个同时承载博客、产品、作者身份的公共站点，不应该把第一次进入的读者直接扔进工具内部；把工作区当成产品目录里的第一项，不是弱化产品，而是让它获得更清楚的位置。这样一句话才承担了选择的后果，读者也才能顺着你的思路理解为什么这个调整是必要的。

同样的情况也出现在分类改造上。如果文章只是说“栏目更新为六个新分类”，那还是描述事实。真正的判断是：旧分类像作者内部文件夹，不够主流，也不够可信；新的分类要先服务读者的识别效率，再服务作者的自我命名欲望。读者即使不同意这个结论，也至少能看见你把哪种标准放在了前面。产品文章一旦能这样写，文字就不再只是更新播报，而会开始承担产品方法的功能。

判断最有价值的地方，是它能让读者看到你的优先级

我越来越相信，产品文章最值得公开的，其实不是“我们做了很多”，而是“我们现在先做什么、后做什么，为什么”。因为优先级本身就是产品最核心的信息之一。一个功能之所以被放在第一位，说明它比别的东西更接近当前问题；一个入口之所以被删除，说明它制造了比价值更大的噪音；一个技术实现之所以被迁移，说明原先的结构已经开始干扰稳定性。

像这次把安全头和旧路由跳转逻辑从代理层转移到 next.config.mjs，如果只是写成技术细节，读者很容易把它看成“文件搬家”。但真正值得写出来的是背后的判断：不要让代理层承担太多默认正确的职责，更不要让它在 Cloudflare / OpenNext 的部署链路里变成新的上线门槛。这样表述以后，文章的力度就完全不同了。它不再只是告诉人代码放在哪里，而是在说明你如何界定风险边界、如何判断什么才是更稳的工程表达。

第一种空话是假装成熟。它喜欢借用大公司博客和 SaaS 营销页的写法，把一切都写得像经过大量用户验证，好像每个决定背后都有成套数据、访谈和转化结论。但像 MakePlans 这种仍在公开生长的个人产品项目，很多阶段性的选择并没有那么宏大的证据链。这个时候如果硬写成“用户强烈需要”“验证显示效果显著”，就会立刻失真。读者也会感受到一种不自然：项目明明还在打磨，你却在用像成熟组织季度汇报一样的口气说话。

第二种空话则是中性过头。为了避免夸张，它把所有句子都写成不承担风险的说明。结果就是全文什么都没说错，但也什么都没真正说到点上。读者读完以后，只知道页面结构和功能顺序，不知道作者最在意什么，不知道为什么这个项目看起来会是现在这个样子，更不知道这个产品下一步大概会往哪里去。

我现在宁愿文章承认边界，也不愿它假装周全。没有成规模用户数据，就写从真实项目过程里得出的判断；没有漂亮增长故事，就写为什么某个入口、某个结构、某个部署方案在当前阶段更值得优先做。只要句子能回到真实决策现场，它就比那些听起来更“完整”的空话有价值得多。

所谓可验证，不一定是有外部数据，而是读者能够从项目本身看见这句话落在哪里。你说公共博客该用更可信的主流分类，读者能在站点里看到分类真的改了。你说录制工作区应该被当成产品而不是默认首页，读者能在产品区和 /workspace 的关系里看到这个结构。你说代理层不该变成发布门槛，读者能从 next.config.mjs 的调整和那篇发布阻塞复盘里理解这个结论。这样一来，文章里的判断就不是飘着的立场，而是能被项目现状支撑的立场。

这也是我为什么越来越不把产品文章当成包装层。它不是在产品做完以后再补一层更好看的解释，而是产品本身的一部分。你怎么写，决定了你怎么理解自己的取舍；你写不写得出清楚判断，也会反过来暴露产品到底有没有清楚的方向。对一个 serious personal product blog 来说，文字不应该只是附带说明，而应该像结构、导航、部署选择一样，都是产品方法的一种公开形式。

这一步看起来很小，实际非常管用。因为很多产品文章写散，不是作者没有内容，而是他同时想让读者理解太多事情：想解释背景，想说明功能，想顺便交代路线图，还想给整个项目建立气质。结果每段都“有点重要”，整篇文章却没有真正的落点。我现在更愿意先逼自己写一句 verdict：这篇文章读完以后，读者最该记住的到底是什么。是“首页应该先卖判断而不是卖功能”，还是“产品导航首先是目录不是营销按钮”，又或者“工作区被移出首页不是弱化产品，而是让它回到更清楚的位置”。结论一旦先被钉住，段落就会开始自动收紧。

这也会反过来改善句子质量。因为当你知道读者最后必须带走哪一个判断时，那些只是补背景、补礼貌、补完整感的句子会变得很显眼。它们不是错误，只是没有在推动文章向结论前进。产品文章往往就是这样写虚的：信息越来越多，方向越来越弱。

交稿前，我会专门删掉那些“正确但没有立场”的句子

我现在把这一步当成最后一道真正的编辑工序。凡是那种读起来没有问题、也不算空洞、但拿掉以后全文并不会失去什么的句子，我都会重点检查。它们通常最危险，因为它们给了作者一种“已经写得很完整”的安全感，却没有让读者更理解任何一个关键判断。产品文章真正需要的，不是无穷尽的正确，而是有限但可感知的立场。能把这些中性句删掉，文章的力量通常会立刻出来。