我把这个网站叫作 Trace of Me。
Trace 是程序执行留下的轨迹，也是一个人持续学习、判断和修正的痕迹。相比一份只在求职时更新的简历，我更希望这里记录问题如何被拆开、方案为什么改变，以及某段经验最终沉淀成了什么。
为什么还要拥有个人博客
信息发布从来不缺平台，真正稀缺的是可持续的上下文。
短内容适合分享一个结论，却很难容纳推导过程；代码仓库展示最终实现，也不一定解释背后的约束。个人博客可以把二者连接起来：文章解释方法，项目提供实践，时间顺序保留认知变化。
独立网站还带来一种朴素的控制感：内容使用通用 Markdown 保存，地址由自己决定，页面不依赖信息流排序。即使未来替换框架，文章本身仍然可以迁移。
从“文章列表”到知识系统
如果博客只是按发布日期堆叠内容，它很容易变成另一个归档文件夹。我希望这里至少具备三层关系。
主题之间的关系
我长期关注服务端工程、分布式系统、工作流编排和 AI 长期记忆。这些主题并不孤立：工作流需要可靠的状态管理，记忆系统需要数据生命周期，AI 应用最终也要面对传统工程中的一致性、容错和观测问题。
标签页不是为了制造分类，而是帮助读者沿着一个问题继续阅读。
文章与项目的关系
项目卡片只提供公开安全的高层说明，文章则拆解可复用的工程方法。二者互相验证，但不会把未公开的实现、内部数据或业务细节搬到网站上。
这条边界很重要。写作应该增加理解，而不是用敏感信息换取所谓“真实感”。
现在与过去的关系
技术判断会随经验改变。与其悄悄重写历史，不如在必要时标注更新时间，并在新文章中说明变化的原因。错误并不可怕，不可追溯的变化才会让知识失去价值。
一套刻意简单的发布流程
首版没有 CMS、数据库、登录、评论或统计服务。每篇文章就是仓库中的一个 Markdown 文件：
---
title: "文章标题"
description: "一句话摘要"
publishedAt: "2026-07-01"
tags:
- 系统设计
featured: false
---
构建过程会校验字段、生成阅读时间和目录，并把公开文章加入 RSS 与站点地图。发布流程保持为：新增 Markdown、完成构建、检查私有预览，再公开上线。
这套流程牺牲了一点在线编辑的便利，换来更少的运行依赖和更清晰的版本历史。对一个个人技术博客来说，这是合适的取舍。
设计为什么是一条时间轴
网站使用暖白纸张、墨黑文字和锈橙节点。页面上的细线不是装饰性的“科技感”，而是信息结构：日期、文章和项目都落在一条持续延伸的轨迹上。
标题使用接近中文刊物的宋体风格，正文使用系统无衬线字体，代码使用等宽字体。所有字体都来自本地系统，避免为了视觉效果依赖境外字体服务。
深色主题也遵循同一原则：不是把颜色简单反转，而是保留纸张、墨色与标记之间的层次。
如何选择要写的内容
我会优先记录三类内容：
- 解决过、并且能够抽象成通用方法的问题；
- 正在形成理解，但值得公开推演的主题；
- 对项目与工具的复盘，包括哪些选择没有奏效。
文章不追求固定频率，也不为搜索关键词扩写。比起“持续生产内容”，我更在意每篇文字是否为未来的自己保留了足够清晰的上下文。
这是一个起点
首发的三篇文章分别讨论 DAG 工作流、AI 长期记忆和这个网站本身。它们构成了第一段轨迹：从系统执行、数据生命周期，到个人知识如何被组织。
以后这里会继续增加新的节点，也会修正旧的判断。站名中的 “Me” 不是静态的个人介绍，而是这些变化共同形成的结果。
记录代码留下的轨迹，也记录持续变化的自己。