如果你现在打开我的博客，可能会觉得它有点奇怪。
顶部只有两个入口：
Articles
About
没有复杂的导航。
没有标签云。
没有十几个分类。
没有很花哨的动画。
文章页也没有塞很多东西进去。
如果这是一个设计案例，我大概可以很认真地告诉你：
“这是我对数字极简主义的理解。”
但如果说得更诚实一点，其实事情没那么复杂。
一开始，是因为我不会做。
后来用了几个月，我发现：
好像也没有必要什么都做。
01我先得让它跑起来
2026 年 4 月之前，我基本没认真做过前端。
过去这些年，我主要做的是汽车空气动力学和 CFD。
HTML、CSS、JavaScript 对我来说，都不是日常工作的一部分。
所以刚开始做博客的时候，我根本没有能力去讨论什么设计哲学。
我面对的是一些更实际的问题：
页面怎么出来？
文章怎么放进去？
链接怎么跳？
手机上会不会乱？
代码怎么组织？
后来才慢慢碰到 Astro、TypeScript、Tailwind 这些东西。
那时候如果有人问我：
“你的博客想做成什么样？”
我其实回答不上来。
我只有几个非常简单的要求：
文章能够正常发布。
别人能够正常阅读。
我以后能够继续维护。
我自己愿意一直用。
就这样。
第一版博客基本就是从这里开始的。
02真正用起来以后，问题才开始出现
刚开始看到自己的页面，我其实有点嫌弃。
别人做的个人博客看起来都很完整。
有漂亮的首页。
有各种卡片。
有动画。
有搜索。
有标签。
有分类。
有各种我当时甚至不知道怎么实现的交互。
再看看自己的页面：
两个导航链接。
文章。
关于。
结束。
看起来确实有点像一个还没做完的网站。
但后来我开始真的拿它写东西。
这个时候我发现了一件很现实的事情：
个人网站和产品网站不太一样。
一个产品可能有设计师、前端、后端、测试、运营。
个人博客没有。
这个网站以后加一个功能，维护的人还是我。
出了 bug，还是我。
移动端炸了，还是我。
依赖升级出问题，还是我。
某个组件半年没用过但一直要维护，还是我。
于是我开始重新看待“功能”。
以前我的想法比较简单：
能加的东西为什么不加？
现在会多问一句：
这个东西真的值得我以后一直维护吗？
这个问题改变了很多东西。
03我后来越来越喜欢删东西
我以前做软件的时候，很容易进入一种状态：
既然已经做了，那再加一点也没关系。
于是功能越来越多。
一个面板不够，再加一个。
一个统计不够，再加一个。
觉得用户可能需要某个功能，那就先做。
最后整个东西看起来越来越“完整”。
但真正开始使用以后，情况经常相反。
有些东西看起来很厉害，用起来却没有帮助。
甚至会打断原本的工作。
我自己写东西的时候就是这样。
我真正需要的通常很简单：
打开编辑器。
写东西。
遇到问题，查一下。
必要的时候问 AI。
然后继续写。
如果旁边一直有很多统计、提示、状态、面板，我并不会因此写得更好。
有时候只是多了一些东西可以看。
所以后来我开始删。
不是因为我突然理解了什么高级的设计理论。
只是因为我自己用着觉得烦。
不好用，就删。
没用，就不放。
这个标准其实比很多设计原则都简单。
但对我来说挺有效。
04所以最后只剩两个导航
博客的导航其实也经历过几次变化。
以前有过：
Articles · Research · About
更早的时候甚至放过 Reading。
后来发现 Reading 暂时没有必要占一个一级入口，就拿掉了。
Research 也是后来重新加进来的。
因为我开始做一些视频和研究简报，需要一个地方把背后的数据、资料和分析留下来。
它确实有价值。
但后来我又把 Research 从一级导航里拿掉了。
这里可能有一点容易误解：
不是 Research 不重要。
而是我觉得它没有必要一定出现在最顶层。
现在它仍然是一个独立的内容区域，只是从信息架构上，它属于 Articles 的一部分。
这两件事情其实不矛盾。
一个东西可以重要。
但不一定需要占据导航栏。
所以现在顶部只留下：
Articles
About
够用了。
如果以后真的需要第三个入口，我会再加。
但我希望原因是：
我真的开始需要它了。
而不是：
一个博客好像应该有三个导航。
05至于那些留白
这一点我其实也想诚实一点。
现在网上有很多关于留白的设计理论。
呼吸感。
视觉节奏。
信息密度。
空间层次。
阅读路径。
这些东西当然都有意义。
但如果你问我：
为什么你博客这里留这么大一块空白？
有些时候我的真实答案其实就是：
因为我不知道那里应该放什么。
所以我没放。
就这么简单。
但后来我发现，这个结果其实也没有那么糟。
如果一个位置没有真正需要的信息，我宁愿先让它空着。
以后真的发现需要一个东西，再加。
而不是为了让页面看起来“完整”，硬塞一个组件进去。
这也是我现在越来越喜欢的一种开发方式：
先留下空间。
而不是先填满空间。
06这其实不是什么「极简主义案例」
如果现在让我重新给这篇文章起名字，我甚至不太确定还要不要叫它：
Minimalism in Digital Design
因为严格来说，我并没有研究过什么完整的极简主义设计方法。
这个博客也不是经过专业设计团队打磨出来的极简作品。
它更像是一个工程师自己做东西时留下来的痕迹。
我不会前端。
所以最开始做得很简单。
开始使用以后，发现有些东西不需要。
于是删掉。
发现某些东西确实有用。
于是留下。
发现新的问题。
再改。
整个过程其实非常普通。
甚至有点笨。
但它让我慢慢形成了一个现在比较认同的判断：
一个东西不应该因为“可以做”就被做出来。
它应该有一个真正的理由。
07我现在更相信这个循环
以前我做东西的时候，很容易想：
我要先把它设计完整。
现在我越来越倾向于另一种方式：
Build it.
先做出来。
Use it.
自己真正用一段时间。
Find the problems.
看看哪里真的不好用。
Change it.
然后再改。
这其实和我做工程时的思路很像。
很多东西在纸面上看起来都合理。
真正进入实际工况以后，才会发现问题。
软件也是一样。
设计稿里看起来很漂亮的东西，真正写文章的时候可能很烦。
一个理论上很合理的导航结构，真正使用以后可能根本没人需要。
一个看起来很“完整”的功能，最后可能只是增加维护成本。
所以现在我不太追求一开始就把所有东西想清楚。
先让它跑起来。
然后让使用告诉我，下一步应该怎么改。
08现在这个博客，其实挺像我现在的状态
它不是一个完成度特别高的设计作品。
也不是一个经过完整用户研究、信息架构分析之后做出来的“极简主义案例”。
它就是一个还在不断修改的网站。
有些地方我现在已经比较满意。
有些地方我还是觉得别扭。
有些页面以后可能还会重做。
甚至现在这套结构，过几个月也可能发生变化。
但我并不觉得这有什么问题。
因为这个网站的意义，本来就不是证明：
我已经把网站做好了。
而是留下一个过程。
从不会做前端，到开始自己搭网站。
从觉得功能越多越完整，到开始主动删东西。
从一开始不知道设计应该是什么样，到慢慢知道什么东西自己不需要。
这个过程本身，比最后那个页面长什么样更有意思。
09最后
所以现在，如果你打开我的博客，你看到的可能还是：
Articles
About
然后是一篇篇文章。
看起来没什么特别的。
但对我来说，它已经不是“东西太少”了。
而是我终于开始知道：
哪些东西我暂时不需要。
这可能是我目前对设计最朴素的理解。
不是尽可能少。
也不是为了极简而极简。
而是：
需要的时候再加。
不需要的时候，就让它空着。
以后这个博客可能会越来越复杂。
也可能一直这么简单。
我现在还不知道。
等真的需要的时候，再决定。
Build it. Use it. Find the problems. Then change it.先做出来，用起来，发现问题，再改。