我为什么开始做这个网站

我一直想要一个地方，记录自己最近到底在折腾什么。

这里面可能有正在学习的技术、做过的项目、遇到的问题，也可能只是一个还没有完全想清楚的实验。它们未必都足够完整，未必都能马上变成一篇标准的技术文章，但如果没有一个地方把这些过程留下来，过一段时间之后，我很容易忘记自己曾经走过哪些弯路。

所以，我想做一个“自己技术生活的记录工具”。

这件事有两个很直接的目的。第一是记录自己的技术生活，第二是把自己学习到的东西更快、更直接地传递给其他人。博客当然可以完成其中一部分工作，它可以用来分享自己的技术经历，也可以把一些问题整理成文章。但我后来发现，如果网站只停留在博客这个形态，仍然有一些东西很难自然地放进去。

一个博客为什么还不够

文章适合解释问题、记录思路和总结经验，但不是所有内容都适合用文章表达。

有些东西更像是一个实用的小工具。它可能很小，也可能只是为了某个具体场景服务，但它不一定需要被写成一篇长文章。有些东西更像实验，重点不在于得出一个漂亮的结论，而在于把过程跑一遍，看看结果是什么。还有一些想法可能只需要一个小组件，或者一个可以继续修改的页面。

这些内容如果都硬塞进博客里，结构会变得不自然。文章、工具和实验有不同的使用方式，也有不同的展示重点。博客可以保留，但它不应该成为唯一的容器。

这也是我开始重新考虑网站形态的原因。

所以，我更想做一个门户

我更希望它逐渐变成一个个人技术空间：文章、工具、实验流程、小组件，以及以后可能出现的其他 Web 功能，都可以在这里找到自己的位置。

这里的“门户”并不是一个已经规划完整的大系统。我现在也不知道它最后具体会长成什么样，只是觉得，这个方向比单纯做一个博客更接近我真正想做的事情。

如果以后有实用的小工具，可以把它们放进来，慢慢形成一个工具箱。如果某些内容需要更强的互动，也许可以继续扩展成讨论问题的地方。至于社区会不会真的出现、会以什么形式出现，现在没有必要提前下结论。

对我来说，重要的是先把基础空间搭起来，让文章、工具、实验和小组件能够共存，而不是一开始就把所有未来功能都设计完。

为什么最后选择 SvelteKit

在选择实现方案的时候，我比较过 Astro、Next.js 和 SvelteKit。

我比较看重的不是某个框架的排名，也不是谁能在所有场景里胜出，而是它和这个个人项目的方向是否匹配。我希望用相对轻量的方式，逐步实现一个完整的个人门户系统，同时保留继续扩展的空间。这也是我一直比较在意 KISS 的原因：能简单解决的问题，就不要先引入不必要的复杂度。

Astro

Astro 很适合博客，尤其适合以内容为中心的网站。它的 Content-first 思路很清晰，做文章、文档和内容展示时非常自然。

但我的目标逐渐不只是“做一个博客”。如果以后要加入工具、实验、小组件，甚至其他 Web 功能，我会更希望基础方案本身就偏向通用的 Web App / Portal。对我来说，这意味着 Astro 和我的目标之间存在一定差距。

这不是说 Astro 不适合大型网站，也不是否定它在内容网站上的价值。只是我希望这个项目不要停留在文章本身，所以最后没有把它作为主要方案。

Next.js

Next.js 的生态很丰富，这是一个明显的优点。它可以覆盖很多场景，也有大量成熟的工具和实践可以参考。

不过，对一个由个人维护的项目来说，生态更丰富不一定就意味着最终方案更适合自己。我更在意的是能不能在满足当前需求的同时，把系统保持在自己能够理解和维护的范围内。

如果只是为了一个个人门户，就承担过多不必要的复杂度，那会偏离我最初想做这个网站的原因。我的目标不是追求功能数量，而是用一个自己愿意长期维护的方式，把想法慢慢实现出来。

SvelteKit

SvelteKit 刚好符合我现在的判断。

它可以用来做博客，也可以继续扩展成更完整的 Web App。边缘部署、性能优化和 Serverless 方向给了我足够的空间，同时整体仍然相对轻量、直接。

我选择它，不是因为它在所有方面都一定优于其他框架，也不是因为想证明某个技术选择是唯一正确的答案。更准确地说，是因为我希望用轻量级的方式实现一个完整的个人门户，而 SvelteKit 目前和这个方向比较接近。

Markdown：让内容和页面分开

我希望文章内容和页面展示能够保持解耦。

Markdown 本身就是被设计来描述内容的工具。“一篇文章，一个 Markdown 文件”这件事对我来说简单、直接，也容易长期维护。文件只负责文章内容，页面负责把内容展示出来。

理想情况下，article.md 不应该反过来关心 Blog Card、首页、搜索、RSS、Sitemap 或 SEO 是怎么实现的。这些都属于展示层和内容系统的其他部分，不应该把文章本身变成某个页面结构的附属物。

我喜欢这种分工：

• Markdown 是内容源。
• UI 是展示层。
• Blog Card、Homepage、Search、RSS、Sitemap 和 SEO 都是内容的不同使用方式。

这样做的好处不是让系统看起来更复杂，而是让每一部分的职责更清楚。以后调整页面，不需要为了一个卡片布局去改文章；以后整理内容，也不需要让每个展示入口都跟着变化。

Agent：我负责方向，它负责实现

这个项目还有一个比较重要的特点：我并不是让 Agent 自己决定网站应该是什么。

我负责设计最初的思路、定义方向、提出需求、监督 Agent、审计它的工作，并且验收最终结果。通常我会先产生一份文稿、一个设计初版，或者至少先说明自己希望解决什么问题，然后再让 Agent 去完成具体实现和优化。

Agent 更适合负责实现、放大、重构和具体工程工作。它可以帮助我把一个模糊的想法拆开，把重复的工作做完，也可以在发现问题之后协助调整结构。

但方向仍然需要由我来决定。更准确地说：

我负责决定这个东西应该是什么，Agent 负责把这个想法尽可能完整地实现出来。

这和“让 Agent 替我开发整个网站”不是一回事。网站的取舍、语气、边界和验收标准，仍然需要由我自己负责。

为什么选择 Serverless

我使用 Serverless / Edge，一个重要原因是降低成本，同时减少个人网站的维护工作。

我并不是为了追求服务器性能极限，也没有兴趣把时间都花在管理服务器、考虑扩容或者维护一套复杂的基础设施上。能够少管理一些东西，利用 CDN / Edge 完成更多请求处理，对个人项目来说已经很有吸引力。

我更在意的是：网站能不能在较少维护的情况下稳定运行。

互联网里有很多所谓的“邪修”优化方式。很多时候，思路不一定是把服务器堆得更强，而是让请求尽可能少到达服务器。这句话在这里更像是我的个人表达，不是一个需要证明的技术结论，但它确实描述了我比较喜欢的方向：减少不必要的维护，让系统保持简单。

我希望它最后长成什么

我希望它最后不是一个单纯的博客，而是文章、工具、实验流程、小组件和社区可能组成的一个集合。

但我并不知道它最终具体会长成什么样。现在能确定的，只是我想给这些内容预留位置，并且用一种自己能够持续理解和维护的方式慢慢往前走。

也许最后它会更像一个工具箱，也许会有更多实验，也许会出现可以和其他人讨论问题的地方。也可能它会停在某个阶段，变成一个记录过很多过程的个人技术空间。

这些都可以以后再决定。

对现在的我来说，先把这个地方做出来，让它能够容纳我正在学习、正在实现和还没有想清楚的东西，就已经足够了。