这个博客正式上线的时候，我其实没有想象中那么兴奋。
没有一种“终于完成了”的感觉。
反而是在首页真正能够打开、文章能够正常展示、后台能够登录、Markdown 能够渲染、数据能够从数据库里读取出来之后，我突然冒出了另一个问题：
然后呢？
做一个博客并不难。
至少在今天，它已经没有以前那么难了。
你可以找到成熟的博客框架，可以买现成的主题，可以直接使用托管平台。甚至如果愿意，把需求告诉 AI，它可以帮你写 Vue，写 Rust，设计数据库，排查报错，生成 CSS，甚至顺手把 README 也写了。
从“我想拥有一个博客”，到“一个博客真的运行在互联网上”，中间的距离正在迅速缩短。
可就在这个时候，我反而开始思考：
既然越来越多东西都可以被自动生成，我们为什么还需要自己写？
1. 写作正在变得越来越容易，但思考没有
这是一个很有意思的变化。
以前写一篇技术文章，最困难的地方可能是整理语言。
你知道一个东西怎么实现，却不知道怎么把它讲清楚。
于是你不断修改：
- 这一段是不是太啰嗦？
- 这个概念是不是应该先解释？
- 示例是不是不够直观？
- 前后的逻辑是不是断了？
现在这些问题，很大程度上都可以交给 AI。
甚至你只需要说：
帮我写一篇 Rust Web 开发教程。
几秒钟以后，一篇结构完整、标题清晰、语句流畅的文章就出现了。
于是一个新的问题产生了。
当“写得像一篇文章”变得非常廉价以后，真正稀缺的东西是什么？
我现在越来越觉得，答案不是文字。
而是：
你到底有没有真正想过这件事情。
一篇文章可以有漂亮的标题，有标准的目录，有总结，有代码，有结论。
但这些东西并不能证明作者真的理解它。
真正的思考通常没有那么整齐。
它往往从一个问题开始。
比如：
为什么这里一定要这样设计？
如果换一种方式会怎样？
这个技术解决的究竟是什么问题？
我现在认为正确的方案，半年后还会这么认为吗？
这种东西没有办法简单通过“生成一篇文章”得到。
因为答案也许可以生成，
但问题必须先属于你自己。
2. 我越来越不想只收藏答案
这些年我有一个很明显的习惯：
遇到问题，搜索。
找到答案，解决。
然后关闭页面。
有时候我会收藏，有时候会复制到笔记里。
但过一段时间再回头看，会发现一个很尴尬的问题：
答案还在，但当时的思考已经不在了。
我只记得最后怎么做，却忘了为什么这么做。
比如开发这个博客的时候，我可以简单记录一句：
前端：Nuxt
后端：Rust + Salvo
数据库：MySQL这当然没有错。
但真正有价值的部分其实不是这三行。
真正值得留下来的，是：
为什么最后选了这样的结构？
为什么浏览器不直接请求 Rust，而是在中间加入 Nuxt Server API？
为什么认证 Token 最后放到了 HttpOnly Cookie？
为什么 Markdown 和 Shiki 后来从客户端移到了服务端？
为什么某个最开始看起来很合理的实现，最后证明存在问题？
这些内容才是真正属于这个项目的东西。
技术栈只是结果。
决策过程才是经验。
而经验如果不被记录，最后往往只会变成一句：
“以前好像踩过这个坑。”
至于坑是什么，已经想不起来了。
3. 所以我想把博客当成一个“思考的 Git”
程序员很习惯使用 Git。
因为代码是会变化的。
今天写的实现，明天可能重构。
今天认为正确的架构，半年之后也可能被推翻。
Git 最重要的地方，并不是保存“现在的代码”。
而是保存：
它是怎么一步一步变成现在这样的。
我开始觉得，人的认知其实也应该有类似的东西。
比如今天的我可能认为：
简单的系统应该优先选择简单的架构。
几年后的我也许会发现，所谓“简单”其实只是因为当时没有经历过更复杂的问题。
今天的我也许很喜欢某一种技术。
几年以后可能完全不再使用它。
但这并不意味着过去的判断没有意义。
相反，我很想知道：
当时的我为什么会这样想？
所以这个博客对我来说，不只是一个发布内容的网站。
我更希望它最终变成一个：
思考的版本控制系统。
这里保存的不一定都是正确答案。
甚至最好不要全部都是“正确答案”。
有些文章可能只是某个阶段的理解。
有些结论几年后可能会被自己推翻。
有些技术可能很快过时。
但没有关系。
因为真正值得保存的并不是：
我曾经正确过。
而是：
我是怎么走到今天这里的。
4. 技术文章最有价值的部分，可能恰恰不是技术
以前我看技术文章，经常会直接跳到代码。
安装命令。
配置。
完整示例。
复制。
运行。
问题解决。
这是最高效的阅读方式。
但现在越来越多代码都可以直接生成之后，我反而开始更关注另一种内容。
例如：
为什么选择这个方案？
作者试过哪些失败的方法？
哪个地方最容易踩坑？
如果重新做一次，他会改变什么？
因为“怎么写”越来越容易获得。
而：
为什么这样写
依然来自真实经历。
这也是我希望以后这个博客能够保留的东西。
如果我以后写 Rust，我不想只是写：
fn main() {
println!("Hello, world!");
}然后解释语法。
如果我写一次系统设计，我更想记录：
- 最开始是怎么想的；
- 哪一步开始发现原方案有问题；
- 为什么最后改变了设计；
- 哪些方案被放弃；
- 哪些问题到现在其实还没有答案。
因为真实的开发从来不是一条直线。
真实的过程更像：
想法
↓
实现
↓
发现问题
↓
怀疑人生
↓
查资料
↓
重构
↓
又发现问题
↓
终于能跑
↓
回头发现还能更好最后别人看到的，通常只是最后那个“能跑”的版本。
而我越来越觉得：
中间那些绕路，可能才是最值得写下来的。
5. AI 不会让我停止写作，反而让我更需要写作
我并不排斥 AI。
事实上，我越来越频繁地使用它。
写代码的时候用。
排查问题的时候用。
查资料的时候用。
整理思路的时候也会用。
它确实极大提高了效率。
但也正因为如此，我开始警惕另外一种状态：
答案得到得太快。
以前遇到一个问题，我可能会花一个下午研究。
现在十分钟就可以知道解决方案。
效率提高了。
但这十分钟到底有没有变成我的知识，是另一回事。
如果只是：
遇到问题
↓
询问 AI
↓
复制答案
↓
问题解决那么我拥有的可能只是一次成功的操作。
而不是理解。
所以我希望以后尽量多加一步：
遇到问题
↓
尝试理解
↓
询问 / 搜索 / 实验
↓
解决
↓
重新用自己的语言解释最后这一步，其实就是写作。
写作迫使一个人回答很多平时可以逃避的问题：
我真的理解了吗？
我能不能不用原文解释？
为什么这个方案成立？
它有没有边界？
有没有更好的方式？
当你无法把一件事情写清楚的时候，很多时候并不是表达能力有问题。
而是：
你以为自己懂了。
6. 我不希望这个博客变成一个“内容工厂”
互联网很容易让人掉进一个数字游戏。
浏览量。
点赞。
搜索排名。
更新频率。
日更。
周更。
选题。
热点。
这些东西当然都没有错。
如果以后有人愿意读这里的文章，我会很高兴。
但至少现在，我不希望为了“博客应该持续更新”而更新。
也不想为了搜索引擎去制造大量内容。
更不希望最后变成：
如何学习 Rust
Rust 入门指南
Rust 的 10 个技巧
程序员必须知道的 8 件事
提高效率的 12 个方法这种文章当然也可能有价值。
但如果只是为了让博客看起来“内容很多”，那并不是我最开始做这个网站的原因。
相比一百篇正确但没有自己的文章，
我更愿意这里最后只有几十篇真正经历过、思考过、愿意几年之后重新回来的东西。
更新慢一点，也没有关系。
7. 一个属于自己的互联网角落
还有一个很简单的原因。
我一直很喜欢“个人网站”这个东西。
它没有平台统一规定的卡片样式。
没有固定长度。
没有“推荐算法要求你怎么写”。
一篇文章可以只有几百字。
也可以写很长。
可以写 Rust。
可以写一次旅行。
可以写突然想到的一个问题。
也可以几年不更新以后突然再写一篇。
它不一定高效。
甚至从传播角度看，可能远不如直接去成熟的平台发布内容。
但它有一种我很喜欢的感觉：
这是互联网上真正属于自己的一个小地方。
代码是自己的。
数据库是自己的。
文章是自己的。
设计是自己的。
哪天看现在的 UI 不顺眼，可以全部重做。
哪天觉得某篇文章写错了，可以回来修改。
甚至哪天觉得过去的自己很幼稚，也可以把文章留在那里。
因为那本身就是记录的一部分。
8. 写给未来的自己
如果一定要给这个博客找一个最重要的读者，
我想可能不是陌生人。
而是：
几年后的我自己。
我希望有一天重新打开这里的时候，可以看到：
2026 年的时候，我正在研究什么。
当时喜欢哪些技术。
正在困惑什么。
对某些事情有什么判断。
做这个博客的时候遇到过哪些问题。
甚至当时为什么会突然想写这样一篇文章。
到那个时候，其中很多内容可能已经过时了。
Rust 生态可能变了。
前端框架可能变了。
AI 可能已经发展到今天很难想象的程度。
甚至这个网站的技术栈可能已经重构过几次。
但我希望有一样东西能够留下来：
当时那个正在认真理解世界的自己。
结语
这个博客的 v1 已经上线了。
从工程的角度来说，它只是一个很普通的网站。
前端、后端、数据库、API、Markdown、后台管理。
这些东西组合起来，让它能够运行。
但我希望从今天开始，真正让这个网站变得有意义的，不再是代码。
而是这里慢慢留下来的东西。
技术。
生活。
见闻。
思考。
以及那些现在还没有答案的问题。
所以，这篇文章就作为一个开始。
我不知道这个博客最终会变成什么样。
但至少我希望：
很多年以后重新点开它的时候，我仍然能够认出，
这些文字确实是我走过的路。
留下你的想法