从这里开始：给想法一个生长的地方一份关于记录与行动的开篇。为什么写，写些什么，以及怎样让一个小小的博客持续生长。
为什么需要一个自己的博客 我们每天会遇到许多值得记住的事情：一个迟迟没有想通的问题，一次让人意外的反馈，或是终于跑通的小实验。 如果没有记录，它们很快就会被下一件事情覆盖。写作给这些片段一个停留的地方，也让我们有机会再次审视自己的判断。 记录不是为了证明自己已经想明白，而是给继续思考留下入口。 从一个具体的问题开始 第一篇文章不必很长。比起寻找一个宏大的主题，可以先选一个最近亲手处理过的问题。 - 当时遇到了什么？ - 尝试了哪些办法？ - 哪个选择起了作用？ - 如果再做一次，会调整什么？ 把这些问题回答清楚，就已经是一篇有价值的记录。 保留过程中的不确定 有些结论来自真实验证，有些只是当前的猜测。把两者分清楚，会让文章更可信，也方便以后回来修正。 不需要把每一次探索都包装成成功经验。失败的尝试、尚未解决的问题，同样值得留下。 让记录成为可持续的小事 可以给自己一个很小的起点：每周记录一个问题，每次只写清楚一件事。 时刻 可以记录的内容 --- --- 开始之前 问题、目标和最初的假设 尝试之中 做过的选择与遇到的阻碍 告一段落 结果、证据以及下一步 当记录足够轻，就更容易坚持。等到需要回顾时，那些看似细碎的笔记会慢慢连接起来。 下一页，从现在开始 这个博客的第一版已经有了文章、标签和订阅。接下来，最重要的事情就是换上你自己的内容。 你可以从 全部文章 看看其他排版示例，或者读一读 Markdown 写作指南，发布自己的第一篇文章。 一点思考，一点实践。每一页，都是新的开始。
从一篇 Markdown 开始，建立自己的写作节奏用简单的文本写文章，把注意力留给内容。这里是一份可直接参考的 Markdown 排版示例。
先写内容，再调整形式 Markdown 让你用纯文本完成大多数常见排版。文章跟代码放在同一个项目里，可以回顾修改，也方便迁移。 在这个博客中，文章保存在 src/content/blog/ 目录。新增一个 .md 文件，就能开始写作。 为文章填写基本信息 每篇文章的顶部都有一段用三个短横线包围的元信息： yaml --- title: "我的第一篇文章" description: "用一句话说明这篇文章在讨论什么。" pubDate: 2026-10-30 tags: ["日常实践"] draft: false sample: false --- 标题、摘要和发布日期必填。标签用于自动生成主题页面；draft: true 表示草稿，不会生成公开文章页面，也不会出现在列表、标签和 RSS 中。 选择一个稳定的文件名 比如 my-first-post.md，对应文章地址是 /blog/my-first-post/。发布以后尽量保持文件名不变，避免旧链接失效。 常用排版示例 正文从二级标题开始，文章标题由页面自动呈现。二级和三级标题会进入右侧的文章目录。 你可以使用 加粗 表达重点，也可以用 斜体 标注词语。行内代码像这样：npm run dev。 列表和引用 1. 写下一个具体的问题。 2. 补充过程和例子。 3. 检查结论是否有证据。 清楚的表达，通常来自对问题本身更清楚的理解。 代码块 在代码块开头注明语言，页面就会显示对应的代码高亮。 typescript const ideas = ['观察', '记录', '实践']; for (const idea of ideas) { console.log(idea); } 表格 字段 用途 是否必填 --- --- --- title 文章标题 是 description 文章摘要 是 pubDate 发布日期 是 tags 文章标签 否 draft 是否为草稿，默认 false 否 featured 是否首页精选，默认 false 否 写完以后怎么检查 运行 npm run dev 查看页面。提交之前，运行 npm run check 和 npm run build，检查类型、文章字段和静态页面生成是否正常。 写作最好的开始方式，往往就是先完成一个不太长的段落。
做产品之前，先把问题问清楚从用户想完成的事情出发，分清观察、假设与验证，让每一个功能都有明确的来处。
一个需求，可能有几种解释 “这里需要一个导出按钮。”这句话给出了一个方案，却还没有说明问题。 用户也许想把数据交给同事，也许需要定期归档，或者只是暂时无法在系统内完成分析。不同的目标，会导向不同的设计。 先理解用户想完成什么，才能判断这个按钮应该怎么做。 把观察和假设分开 记录需求时，可以用三句话整理： 1. 我们看到了什么：用户正在使用什么流程，在哪里遇到阻碍。 2. 我们认为原因是什么：当前的解释，以及还没有证实的部分。 3. 我们准备怎样验证：用什么方式观察变化，什么结果才算有帮助。 这样的记录能减少“大家都懂了”带来的误解。 让验证足够小 不一定要完整开发一个功能才能开始验证。一个可交互的页面、一份真实的操作记录，或者对现有流程的小幅调整，都可能提供有用的证据。 但要明确：原型被理解、代码构建通过、用户在真实环境完成任务，代表不同的阶段。 写下可判断的完成条件 “体验更好”很难验证。“用户能在文章列表中找到某个标签的全部文章”则具体得多。 完成条件可以包含： - 在什么前提下进行操作。 - 用户执行什么动作。 - 页面应该给出什么结果。 - 遇到空数据或失败时如何处理。 让下一次决策有据可查 记录最终选择，也记录做出这个选择的原因。将来情况变化时，团队就能判断原来的前提是否还成立。 一个清楚的问题，往往比一份很长的功能列表更能推动事情向前。
搭建一个小博客，也是在练习做减法先把写作、阅读和发布连起来，再决定下一步需要什么。一个静态博客的起步思路。
先确认最重要的那条路径 一个博客最基本的价值，是让作者发布内容，让读者顺利阅读。 因此，第一版可以围绕一条完整路径展开： 新增文章 → 本地预览 → 构建静态页面 → 发布 → 读者访问。 当这条路径可靠以后，再考虑搜索、评论和更多个性化功能。 静态内容如何变成网页 在这个项目中，Markdown 保存正文，Astro 组件负责页面结构，CSS 负责视觉样式。构建时，工具把它们组合成可以直接访问的 HTML 和静态资源。 读者打开页面时，首先得到的是文章本身。大多数阅读行为不需要额外的交互脚本。 内容结构保持简单 文章放在一个目录里；公共页头、页脚和元信息由布局统一提供；标签从文章数据自动汇总。 这样，发布一篇文章只需要添加一个文件，而不必同时修改多个导航或列表页面。 第一版要检查什么 bash npm run check npm run build npm run preview 构建成功之后，还需要检查实际页面： - 手机宽度下，标题、正文和代码块能否阅读。 - 文章链接、标签链接和目录锚点是否有效。 - 草稿是否确实从公开页面中排除。 - RSS 和 Sitemap 中的地址是否符合最终部署地址。 把后续变化留给真实需要 如果文章多到难以查找，再加入搜索。如果有了持续交流的需要，再选择评论服务。 保持一个小而完整的起点，让维护成本与实际需要一起增长。