“何器斋”个人博客建站报告

背景与结果

我从 2024 年开始进行个人内容创作，主要发布于两个不同平台的同名账号：微信公众号“何器斋”的 3 篇文史小考证，以及小红书“何器斋”的 13 篇 Vibe Coding 手记、IT 学习与生活记录，内容分散、维护不便、“个人品牌”联动性较差。

由于近期参加实习面试，了解到了腾讯云 EdgeOne Makers 这款产品，于是打算借着在免费额度内试用本产品的机会，正式把自己的个人内容聚合站建设起来，以满足轻松部署、快速访问、稳定维护的需要。

整体架构

• 实线：日常使用路径
• 虚线：试飞试验，或只在访客浏览器里发生的请求

flowchart TB
  A["本地写 Markdown"] -->|"git push master"| B["GitHub 私有仓库"]
  B -->|"自动触发"| C["Makers 云构建<br/>pnpm build · Node 22"]
  C -->|"部署"| S
  U["访客浏览器"] -->|"haoyong.org"| D["Cloudflare DNS<br/>仅解析，CNAME 接入"]
  D --> S
  subgraph P1["Makers 项目一：博客（全球可用区，不含中国大陆）"]
    S["静态站点<br/>边缘节点分发"]
  end
  S -.->|"页面脚本跨域请求"| T
  subgraph P2["Makers 项目二：留言板（函数地域 ap-singapore）"]
    T["Twikoo 云函数 2.0.15<br/>comment.haoyong.org"]
  end
  W["WorkBuddy<br/>直接上传"] -.->|"试飞"| X["试飞项目<br/>只做试验"]

主要时间线

网站建站（10/18–10/19）：10/18 10:30 内容素材整理、框架选型 → 13:00 项目总文档制定 → 18:31 试飞站上线 → 19:18 GitHub 云构建通过 → 10/19 凌晨 内容素材上线，00:28 在腾讯云注册 haoyong.space → 01:27 域名与强制 HTTPS 生效 → 13:04 前端设计与用户体验精修、留言板上线。

域名抢修（10/20–10/21）：10/20 07:32 注册局 Radix 把 haoyong.space 置为 serverHold，博客和留言板同时打不开 → 排查并确认：是被注册局暂停，起因是 Spamhaus 以钓鱼类别收录 → 三条线同时申诉（Spamhaus 工单、腾讯云工单、Radix 解封申请） → 10/21 06:54 在 Cloudflare 注册新域名 haoyong.org → 当天上午 EdgeOne 绑定新域名，修改网站网址与留言板地址的配置并推送，更新留言板跨域白名单 → 浏览器、留言板、中国大陆出口网络逐项验证正常 → 18:50 Spamhaus 移除黑名单、Radix serverHold 解除，haoyong.space 恢复正常访问。

关键问题和决策

1. 框架选型：Retypeset 原版仓库 vs. Retypeset + Contentful 模板

关于框架选型，我的原则是：① 满足个人博客的实际需求；② 界面设计符合个人审美；③ 与 EdgeOne Makers 足够适配。基于上述三个原则，我注意到 Retypeset，并且发现 Makers 模板库里就有 Retypeset + Contentful 模板。但要使用这个模板，就需要先注册 Contentful、导入内容模型，并且文章会存在它的后台。我期待的是“写好 Markdown 就发布”，多接一个第三方后台就多一个依赖和失败点，所以我决定从该主题的原版仓库复刻。

2. 部署方法：WorkBuddy 直接构建 vs. GitHub 云端构建

关于部署方法，已知有两条路线：① 让 WorkBuddy 连接 EdgeOne Makers 的技能和连接器，本地构建后直接上传部署；② GitHub 私有仓库连接 Makers，云端构建部署。这两条路线经过以 Retypeset 框架模板为素材的试飞试验，发现都可以跑通。但基于本次建站是希望可以达成稳定维护的目标，而直接上传的项目不适合长期更新，于是决定选择第二条路线。

在采用该方法并付诸实施的过程中，意外发现它的长处不仅仅在于 GitHub 端的版本管理与长期维护，还在于 EdgeOne Makers 端可以实现 GitHub 推送后自动构建部署，非常简便易行。与此同时，工作中途因故对 GitHub 仓库改了一次名，发现仓库与 EdgeOne Makers 的连接也没有中断，其稳定性也得到验证。

3. 域名设置与故障抢修

① 个人域名设置

关于域名，由于 EdgeOne Makers 自动生成的默认域名不太好记且无法从中国大陆访问，以及后续希望接入的留言板功能也要求绑定自己的域名，于是我在腾讯云注册了 haoyong.space。它的 DNS 留在 DNSPod、不交给 EdgeOne，采用 CNAME 接入：一条 TXT 向 EdgeOne 证明该域名的归属，一条 @ 上的 CNAME 指向 EdgeOne 的调度域名，由它按访客位置给出就近节点。随后，针对此域名设置了自动申请免费 DV 证书，并打开了强制 HTTPS 和 OCSP 装订。

关于加速区域，我选的是“全球可用区（不含中国大陆）”。主要的考虑是：选含中国大陆的区域，自定义域名要完成工信部备案，不含中国大陆则不需要。我用自己的手机，经 VPN 走国内出口试了一次，可见当前加速区域设置下，默认域名会返回 401、无法访问，个人域名则可以正常打开。于是感受到 CDN 产品服务等不仅仅要考虑技术问题，还需要考虑用户所在国家地区的合规要求。

② 发现个人域名故障并确定原因

10/20，我发现 haoyong.space 打不开了，留言板也一起失灵。EdgeOne 控制台提示“请添加 CNAME”，DNSPod 提示“DNS 地址待修改”，看上去像是配置丢了；可实际上这些配置并没有变，EdgeOne 自动生成的两个默认域名也一直正常。

要说清楚是哪一层出了问题，得先分清一个域名背后的两条线（见图一）。登记线负责“这个名字归谁、交给哪组 DNS 服务器”：我是注册人，经转售商（腾讯云）找到注册商（Aceville Pte. Ltd.），再由注册商代我向注册局（.space 后缀的注册局是 Radix）登记。访问线负责“浏览器怎么走到内容”：浏览器问递归解析器，再依次问根服务器、顶级域服务器，得知这个域名归哪组权威 DNS 管（DNSPod），最后连上 EdgeOne 的边缘节点。两条线的接点是顶级域服务器。

图一：一个域名背后的两条线（红框是这次出事的接点）

---
config:
  flowchart:
    nodeSpacing: 20
    rankSpacing: 26
    padding: 8
---
flowchart LR
  subgraph L1["登记线（我是注册人）"]
    direction TB
    RS["转售商<br/>旧：腾讯云｜新：无"] --> RG["注册商<br/>旧：Aceville<br/>新：Cloudflare"]
    RG -->|"EPP"| RY["注册局<br/>.space：Radix<br/>.org：PIR"]
    RY --> ZF["顶级域区文件<br/>名字归哪组 DNS"]
  end
  subgraph L2["访问线（每次访问）"]
    direction TB
    BR["浏览器"] --> RC["递归解析器<br/>（先问根服务器）"]
    RC --> TS["顶级域服务器<br/>注册局运营"]
    TS --> AD["权威 DNS<br/>旧：DNSPod<br/>新：Cloudflare"]
    AD --> EN["EdgeOne 节点<br/>证书、缓存、回源"]
  end
  L1 ==>|"接点"| L2
  style ZF stroke:#c0392b,stroke-width:3px
  style TS stroke:#c0392b,stroke-width:3px

这次，注册局正是在这个接点上动了手：Radix 因为 Spamhaus（一家维护垃圾邮件和钓鱼域名黑名单的国际非营利组织）把 haoyong.space 报告为“钓鱼”（phish）类别、“荣登” Domain Blocklist，于是就把它设置为 serverHold，在区文件里不再发布这个域名，导致全世界的解析器都找不到它的 DNS，一律回答“域名不存在”（NXDOMAIN）；DNSPod 和 EdgeOne 里的配置完好无损，只是再也没有访客走到它们面前。这也解释了两个控制台为什么都像是“配置丢了”。申诉除名后，Spamhaus 对拉黑我的原因的解释是：这个域名似乎处在信誉很差的互联网“邻域”，原因可能是 DNS 服务器、托管服务、注册商、所用 IP、所在网络的信誉，或是它们的组合；只要这种关联还在，就不具备除名资格，建议迁移到信誉更好的托管网络。Spamhaus 得出这一结论的具体原因尚不明确，但可见的一条旁证是：Spamhaus 的页面上有一份按检出数量排名的恶意域名注册商 Top 10，该域名背后的 Aceville 排在第一（10/20 查看时数据）。整条因果链见图二。

图二：这次故障的因果链

---
config:
  flowchart:
    nodeSpacing: 20
    rankSpacing: 30
    padding: 8
---
flowchart TB
  SP["Spamhaus 域名黑名单<br/>haoyong.space 记为 phish<br/>理由：邻域信誉差"] -->|"以钓鱼类别报告"| RX["注册局 Radix<br/>设 serverHold"]
  RX -->|"不再发布这个域名"| TS["顶级域服务器<br/>答 NXDOMAIN"]
  RX -.->|"转交的改 DNS 请求被拒"| S4["腾讯云<br/>域名状态错误<br/>不能修改 DNS"]
  TS --> S1["浏览器<br/>打不开"]
  TS --> S2["EdgeOne 控制台<br/>请添加 CNAME"]
  TS --> S3["DNSPod<br/>DNS 地址待修改"]
  style RX stroke:#c0392b,stroke-width:3px

③ 抢修环节：三条同时申诉 & 申请绑定新域名

为了尽快解决上述故障，我从三条线同时申诉：向 Spamhaus 和腾讯云分别提交工单，并且向 Radix 提交解封申请。但这三条线首尾相扣，成了死循环：Radix 要求先在 Spamhaus 除名才解封；Spamhaus 要求先改变关联才除名；能改变关联的办法，是把域名的 DNS 服务器换走，而腾讯云控制台在暂停期间拒绝修改（提示“域名状态错误，不能修改 DNS”）。

好消息是，这一困境并非牢不可破。一方面，腾讯云回复会向注册局核实情况；另一方面，我语重心长地在给 Spamhaus 的申诉中向对方申明利害，表明我已经陷入这个死循环，唯一的解法就是把我从黑名单里移除出去。经过24小时之内多轮的 battle，Spamhaus 终于被我“感化”、施舍给我可贵的信任，决定帮我恢复名誉。注册局Radix 一侧的响应速度也非常迅速，还不等我重新申请，就立即解除了 serverHold 状态。腾讯云也在我和他们同步 Spamhaus 的进展之后，告知了我 Radix 的变化，并决定结单。于是 haoyong.space 故障解除，目前是可以正常访问本网站的备份域名。

回到上述申诉结果还不明朗的时候，我决定不能干等，要行动起来：10/21 清晨，就在 Cloudflare 注册了新域名 haoyong.org，DNS 也由 Cloudflare 解析，托管仍然交给 EdgeOne。购买之前，我先查了 ICANN 有没有注册记录，以及 Spamhaus、VirusTotal、Google 安全浏览和 Wayback 的历史快照，似乎都没有负面记录。接着在 EdgeOne 绑定新域名并完成 HTTPS 设置，把配置里的网站网址和留言板地址改成新域名并推送。最后用浏览器、留言板和中国大陆出口的网络逐项验证，一切正常。于是新域名 haoyong.org 成为了本网站的正式域名。

截止目前，这次域名抢修给我最大的教训是：在购买域名之前，需要先查清楚相关各个方面的情况，至少包括：注册商和注册局的信誉，也就是它们名下的域名被用来做钓鱼、垃圾邮件的比例高不高，处理滥用的口碑如何；域名后缀本身的信誉，诸如 .space 这类便宜的新后缀可能更容易被安全机构盯上；这个域名之前有没有被注册、使用或列入黑名单的历史；以及万一出现问题，应该找谁解决、要走哪些步骤。

4. 附加功能：留言板和浏览数

除了博客文章的展示之外，我还希望为每一篇文章增加留言板和浏览数统计的功能。经过选型，我基于不增加第三方平台、便于与 EdgeOne Makers 适配、免费使用等原则，决定采用 Twikoo，并把它构建部署为第二个独立的 Makers 项目。

在部署过程中我学习到：它是 Node 后端，跑在云函数上，要落在某个具体地域；按照官方文档说明，云函数地域与项目的加速区域关联，这个项目的加速区域也是“全球可用区（不含中国大陆）”，只能在大陆以外选，默认值是新加坡，控制台里显示的就是 ap-singapore。并且由于它绑定了个人域名的子域名 comment.haoyong.org，页面脚本会对它发生跨域请求，所以域名、证书和跨域白名单都要配置一遍。另外，出于安全考虑，我还设置了屏蔽词、违禁词和限流规则，并隐藏了管理面板的入口。

我对 EdgeOne Makers 的理解

通过本次动手建站，我增进了对 EdgeOne Makers 的理解，特别是它“云边一体化”的特点：平台自动识别构建产物，完成云边分层，按应用形态把负载放在边缘或云端。我实际的体感与此一致：没有感觉到哪一步是“源站部署”，哪一步是“CDN 加速”，推送之后构建、部署、全球分发一次完成，不用自己架服务器，也不用另外配 CDN。但“静态”与“动态”、“源”与“边缘”分层也确实存在：博客是静态页面，由边缘节点分发；留言后端是新加坡地域的云函数，数据存在平台自带的存储里。

与 AI 的协作和分工

本次建站成功，仰赖于我和 AI 的通力协作，因此在广义上也属于我个人 Vibe Coding 的又一次实践。具体的分工如下表：

特别是关于 WorkBuddy 与 Claude 的选择：在试飞阶段，我让 WorkBuddy 使用 DeepSeek V4.1 Flash 执行，但它速度很慢，沙箱限制也让本地构建受阻，体感不佳。试飞站由 WorkBuddy 部署成功后，我决定让 Claude 协作完成主要工作。

与 AI 协作时，我会在前期首先制作总文档，控制项目进行的正确方向，并制定关键动作的执行方案；与此同时，要求 AI 在每完成阶段性任务时，都需要记录日志并更新项目文档，在记录时附带证据（命令输出、截图、提交号），并把结论分成 ✅ 已验证、⚠️ 推断、🔬 待测，以完整、准确地保留工作的全部上下文信息，供后续核验、交接与复盘等。

What's Next

本次建站局限于个人博客，没有使用到 EdgeOne Makers 更进阶的能力，比如边缘函数、Agent 构建等；后续可以寻找更合适的应用场景，进一步学习、尝试。（END）