conanxin-homepage：从域名迁移到个人知识工作台的完整复盘

Why this project exists

conanxin.com 最初不是个人主页，而是 Cloud Mail 的入口。当我决定把邮件服务迁移到 mail.conanxin.com 后，主域名空了出来。问题是：放一个什么样的主页？

我不想做一个普通的个人介绍页。过去几年我积累了大量项目、翻译、阅读笔记和实验原型，但它们散落在不同地方：GitHub 仓库、Obsidian 笔记、本地 Markdown 文件、各种实验页面。没有一个统一的入口能把这些内容串起来，也没有一个地方能让别人快速了解我在做什么。

所以这个项目的目标很明确：建立一个可持续维护的个人公开档案系统，既能展示当前状态，又能长期归档和检索。

Starting point

2026 年初，conanxin.com 还只是一个简单的 Cloud Mail 登录页。迁移邮件服务到 mail.conanxin.com 后，我需要：

• 保留 Email Routing、MX/TXT/DKIM/SPF 记录不变
• 在 Cloudflare Pages 上创建新的主页
• 解决"内容从哪里来"的问题

最初的想法很简单：一个静态 HTML 页面，列出我的项目和文章。但很快发现，静态页面在内容增多后会变得难以维护。每次更新都要手动编辑 HTML，没有搜索、没有标签、没有内容之间的关系。

First principles

我从几个基本原则出发：

本地优先：内容先在本地维护，通过 Git 版本控制，再自动部署到线上。不依赖任何 CMS 或第三方内容平台。 静态生成：用 Node.js 脚本把 Markdown 和 JSON 数据转换成静态 HTML。不引入 React/Vite/Astro 等构建工具，保持简单。 增量演进：不追求一次性完美，而是通过 HP（Homepage Phase）系列逐步迭代。每个阶段有明确边界和验证标准。 可验证：每个阶段结束后必须验证线上状态，确保部署成功、页面可访问、功能正常。 agent 执行：整个 HP 系列由 Hermes agent 分阶段执行，每个阶段包含审计、计划、执行、验证、报告五个步骤。

Key decisions

域名迁移策略：把 Cloud Mail 从 conanxin.com 迁移到 mail.conanxin.com，保留所有邮件路由和 DNS 记录。这一步需要谨慎操作，因为一旦 MX 记录出错，邮件就会中断。 部署方式选择：最初用 Cloudflare Pages 的 Direct Upload，后来升级为 GitHub Actions 自动部署。这样每次 push 到 main 分支就会自动构建和部署。 内容格式选择：项目信息用 JSON 数据文件，长文内容用 Markdown，实验记录用 Markdown + frontmatter。统一用 Node.js 脚本转换成 HTML。 导航结构设计：采用"档案馆"而非"博客"的导航逻辑。顶层分为 Projects、Writing、Lab、Map、Search、Tags 六个入口，而不是按时间线排列。 视觉风格："安静档案馆"风格。温暖纸色背景、深色文字、低饱和强调色。不追求视觉冲击力，让内容本身成为焦点。

System architecture

当前系统由几个层次组成：

内容层：content/ 目录下的 Markdown 文件，包含 writing、case studies 等内容。 数据层：data/ 目录下的 JSON 文件，包含 projects、labs、relations、tags、media 等结构化数据。 构建层：scripts/ 目录下的 Node.js 脚本，负责把内容和数据转换成静态 HTML。 展示层：根目录和子目录下的 index.html 文件，由构建脚本生成。 资产层：assets/ 目录下的 SVG 封面、截图、OG 图片等媒体文件。 部署层：GitHub Actions 自动部署到 Cloudflare Pages。

Phase timeline

这个项目经历了十个主要阶段：

HP-1：基础多页面结构。首页、项目页、文章页、实验室页、关于页。 HP-2：项目详情页。为每个项目创建独立详情页，包含 Why、What、Current status、Design notes、Impact、Links、Next 等区块。 HP-3：Writing 档案。把分散的 Markdown 笔记整合成结构化的写作档案。 HP-4：Markdown 写作系统。建立 content/writing/ 目录，用 frontmatter 管理元数据，自动生成详情页。 HP-5：Discovery 系统。增加搜索、标签、RSS、站点地图，让内容可被检索。 HP-6：关系图。建立项目、写作、实验之间的关系网络，生成知识地图。 HP-7：Lab 档案。为实验原型建立结构化档案，支持类型筛选。 HP-8：媒体资产系统。统一生成 SVG 封面，管理项目、写作、实验的媒体资源，覆盖全站 OG/Twitter Card。 HP-9：结构化首页。把首页从简单入口升级为"个人知识工作台"，展示精选内容、站点状态、当前关注方向。 HP-10：真实截图。用 Playwright 自动捕获核心页面截图，在项目页和 lab 页展示真实界面。

What changed

最大的变化不是技术，而是工作方式的改变。

以前，我的项目、笔记、实验是分散的。现在它们都在一个系统里，有统一的数据结构、统一的导航、统一的搜索和标签系统。更重要的是，这个系统是由 agent 分阶段构建的，每个阶段都有明确的验收标准和报告。

具体的技术变化包括：

• 从 Direct Upload 升级为 GitHub Actions 自动部署
• 从手写 HTML 升级为 Markdown + 脚本生成
• 从孤立页面升级为有关联的知识网络
• 从静态展示升级为可搜索、可筛选的档案系统
• 从 SVG placeholder 升级为真实截图

Current status

当前版本 v0.9 / HP-10。系统包含：

• 8 个项目，其中 6 个有详细复盘
• 6 篇写作，全部 Markdown 化
• 7 个实验，全部结构化
• 12 个项目-写作-实验关系
• 46 个标签
• 25 个媒体资产（SVG + 截图）
• 9 张真实页面截图
• 完整的搜索、标签、RSS、站点地图

部署状态：GitHub Actions → Cloudflare Pages，每次 push 自动部署。

Impact

对个人工作流的影响是深远的。现在我有一个统一的入口来整理和展示所有工作。更重要的是，这个系统本身是"可对话的"——我可以告诉 agent"为这个项目生成一个详情页"，agent 就能基于现有数据结构自动完成。

复用价值方面，这个模式（静态站点 + GitHub Actions + Cloudflare Pages + Markdown 内容 + JSON 数据 + Node.js 构建脚本）可以应用于任何需要结构化内容展示的场景。

What I learned

关于个人主页：个人主页不应该是"自我介绍"，而应该是"工作档案"。它应该回答"这个人在做什么"和"这个人已经做了什么"，而不是"这个人是谁"。 关于静态站点：静态 HTML 的能力被低估了。配合 JSON 数据和构建脚本，静态站点可以完成大部分内容展示需求，而不需要引入复杂的构建工具。 关于阶段化执行：大项目必须拆成小阶段。每个阶段有明确边界、验收标准和报告，这样即使中断也能知道从哪里继续。 关于 agent 协作：agent 不只是写代码的工具，而是可以执行完整工作流的协作者。从审计到计划到执行到验证，agent 可以完成整个闭环。

Next

• 继续补充其他项目的真实复盘
• 为 About 页面增加个人叙事
• 考虑引入 Astro 内容系统以支持更复杂的内容关系
• 增加项目演示链接和外部引用
• 探索自动化的内容更新工作流