代码、产品与长期项目的个人记录https://laterya.github.io/Firefly6.8.11https://github.com/CuteLeaf/Firefly2026年4月8日 09:09:28https://laterya.github.io/posts/from-zero-to-pages/https://laterya.github.io/posts/from-zero-to-pages/为什么我最后选了 Astro，而不是继续往一个更重的全栈栈里叠需求。Wed, 08 Apr 2026 00:00:00 GMT<p>我重新搭博客时，先把问题收窄成了一个很朴素的目标：让我愿意持续写，而不是让我继续维护一套过度设计的系统。</p> <p>对个人博客来说，最关键的并不是“功能是不是足够全”，而是“打开仓库之后，我能不能在几分钟内进入写作状态”。如果每次写文章之前都要先处理一轮数据库、鉴权、部署环境和依赖链，博客就很容易从写作工具变成另一项基础设施负担。</p> <p>Astro 吸引我的地方，在于它把默认重心放回了内容本身。页面是静态生成的，性能稳定，SEO 友好，内容集合又让文章管理保持足够整洁。对个人站点来说，这种取向非常合适：站点结构清楚，部署简单，后续如果真要加交互能力，也还有足够空间。</p> <p>GitHub Pages 则解决了另一个问题：托管路径足够直接。仓库、版本、部署记录和页面内容都在一个地方，不需要再为一套小站额外找复杂平台。对长期写作而言，可预期比花哨更重要。</p> <p>这篇文章本身就是这个博客的第一条记录。它不是在总结“最优解”，而是在给未来的自己留下一个起点：一个足够轻、足够稳、足够能持续积累的起点。</p>https://laterya.github.io/posts/the-shape-of-a-good-note/https://laterya.github.io/posts/the-shape-of-a-good-note/我越来越在意文章是否能在几个月之后仍然对自己有用。Mon, 06 Apr 2026 00:00:00 GMT<p>过去我写过很多“即时记录”，它们在写下来的那一刻很有价值，但几周之后再回头看，往往只剩下一堆缺少背景的结论和不完整的片段。</p> <p>现在我更偏向另一种标准：一篇笔记应该至少回答三个问题。</p> <p>第一，它要交代问题从哪里来。没有上下文的结论几乎无法复用，因为下一次遇到类似情况时，你根本无法判断这条经验是否适用。</p> <p>第二，它要说明你为什么做了某个选择。真正有价值的不是“我用了什么”，而是“我为什么在当时排除了其他方案”。这部分会逼着写作者把模糊直觉整理成清晰判断。</p> <p>第三，它要留下足够具体的下一步。不是所有文章都必须导向一个待办事项，但至少应该让未来的自己知道接下来可以继续往哪里推进。</p> <p>对我来说，博客不是内容仓库，而是一个长期工作的外部记忆系统。每篇文章都应该让下次启动项目时少一点重建背景的成本。</p>https://laterya.github.io/posts/mdx-as-a-workbench/https://laterya.github.io/posts/mdx-as-a-workbench/MDX 真正有用的地方，不是“能嵌组件”，而是能让文档和界面结构更自然地靠近。Sat, 04 Apr 2026 00:00:00 GMT<p>很多人第一次接触 MDX，都会先想到“可以在文章里塞组件”。这当然没错，但如果只停在这里，MDX 的价值会显得很像一个语法层面的花活。</p> <p>我更愿意把它理解成一张工作台。</p> <p>当你在写技术方案、设计复盘或者项目日志时，经常会遇到一个问题：纯 Markdown 足够轻，但表达复杂结构时有时会显得吃力；而完整页面开发又太重，不适合承载思考过程本身。</p> <p>MDX 处在两者之间。它保留了 Markdown 的写作流畅度，同时允许你在确实有必要的时候，把某些结构化内容嵌进去。</p> <blockquote><p>对个人博客来说，MDX 最好的使用方式不是“每篇文章都加交互”，而是“在需要的时候，允许文章拥有更准确的表达能力”。</p></blockquote> <p>例如一篇项目复盘里，时间线、状态块、提示卡片或一个小型对比组件，都可能比大段解释更清楚。重点不是为了炫耀技术，而是为了降低读者理解成本，也降低作者自己回看时的认知成本。</p> <p>所以我会保留 MDX 支持，但不会把它变成默认炫技路径。大多数内容仍然应该是朴素、稳定、可维护的文字。</p>