工作流复盘：用 AI 助手长期维护 johnbuilds.xyz

个人网站最难的不是上线，而是之后还能持续被照看：HTTPS、SEO、404、新文章，每一项都不大，但很容易拖到「下次再说」。

这次我想换个角度写：不是某一次改了哪几个开关，而是我怎样把 johnbuilds.xyz 的日常维护交给一个专职的 AI 助手，并把它收成一套能重复用的工作流。站点本身很简单——静态 HTML 加一份 styles.css，仓库是 Berlinjon/johnbuilds-site，经 Cloudflare Pages 的 git 连接部署。复杂的地方不在技术栈，而在边界：什么能自动做、什么必须我点头、卡在授权时该怎么走。

目标不是「让助手替我做完所有事」，而是「让维护变得可审计、可回滚、可重复」。

为什么需要专职助手，而不是随手问问

我这边还有别的项目和别的助手。若把网站维护混在通用对话里，上下文会散，权限边界也会糊。所以我给这个站单独留了一个角色：只负责 johnbuilds.xyz。别的仓库、翻墙 VPS、临时想法，不进这个助手的范围。

这样做有两个直接好处。一是它记得站上的约定：中文站点、现有排版、配图风格、记录页的日期写法。二是危险操作有固定闸门——推 main、合并 PR、删文件、改域名或部署设置，都必须我明确同意。代码改动一律走 Cursor 云端代理开 PR，不直接推主分支。

一条实际跑通的维护循环

最近这一轮维护，大致是同一条路径反复走了几遍：

1. 先审计线上
   打开真实站点，看 HTTPS、响应头、打错地址时返回什么、/robots.txt 和 /sitemap.xml 是不是真文件。结论写清楚：哪些是 Cloudflare 后台就能改的，哪些必须动仓库。
2. 我批准方案，再动手
   助手给出改法后，我确认范围。例如 HTTPS 三项（Always Use HTTPS、HSTS、最低 TLS）可以立刻改；robots、sitemap、404、分享卡片要动仓库，另开一轮。
3. 后台改动走 Cloudflare 连接器
   安全类设置在 zone 里完成。HSTS 先用短有效期（300 秒），不带子域、不上 preload，方便观察几天再拉长。改完用响应头和 TLS 协商做验证，而不是「改完就算」。
4. 代码改动走云端代理 → PR → 我审 → 合并
   新文章、缺文件、链接统一这类改动，由云端代理在仓库里改，开 PR，我看过再说合并。Pages 跟着 main 部署，线上很快能验。
5. 内容也可以委托，但风格要对齐
   第一篇八月复盘就是按现有文章的版式和语气起草的：短导语、分段讲问题和做法、偶尔一句引用、实用收尾。展示日期可以有意设成 2026.08；封面用深色海军蓝、青色强调的 16:9 信息图，和站上前几篇一致。我可以让助手把关文案，自己只做最终确认。

卡住过的地方，比顺利的更有用

真正拖进度的，往往不是「会不会写 HTML」，而是权限和观测环境。

Cursor 的 GitHub App 必须能看到这个私有仓库。

账号连上 GitHub 不等于 App 已安装，也不等于装了就能访问 johnbuilds-site。安装时若选了 Only select repositories，漏勾这个仓，云端代理就开不出 PR。补上仓库访问之后，文章 PR 才能正常走完：开草稿、我确认、合并、Pages 上线。

测试环境会制造假阳性。

助手所在的执行环境无法对任意站点做明文 HTTP（80 端口）探测。一度误以为「HTTP 超时、跳转有问题」，后来对照真实浏览器和 Cloudflare 配置才纠正过来。教训很简单：工具说不通时，先怀疑观测条件，再怀疑线上配置。

仓库类缺口和后台类缺口要拆开。

HTTPS 可以立刻改完并验证；robots、sitemap、真正的 404.html、OG/分享卡片仍要进仓库。同一轮维护里，后者作为独立 PR 推进，避免和内容改动缠在一起，也避免文中把「进行中」写成「已完成」。

这套工作流真正固定下来的规则

• 范围写死：这个助手只维护 johnbuilds.xyz；旁支任务转给别的助手。
• 同意写死：合并、推 main、删文件、动域名/部署，必须我点头。
• 路径写死：能后台改的用连接器；要动代码的开 PR；上线后看 Pages 部署和真实 URL。
• 验证写死：改安全项就查响应头和协议；发文章就打开记录页和文章页；不确定的环境限制先记下来，不硬猜。
• 内容可委托：复盘文可以按站上风格起草和配图，日期与列表摘要一并定好，我审过再进仓库。

下一步

同一条循环还在继续：SEO 与 404 相关改动（真实 robots.txt、sitemap.xml、404.html、分享描述与专用图、链接统一和图片压缩）按独立 PR 推进；HSTS 在观察几天稳定后，再考虑把 max-age 拉长。之后若再补文章或改版式，仍走「审计 → 方案 → 改动 → PR → 合并 → 验证」。

结语

把个人网站交给 AI 助手长期维护，关键不是助手有多聪明，而是把同意、范围和验证变成默认动作。johnbuilds.xyz 仍然是静态站，没有复杂构建；真正变复杂的是人机分工——助手负责查、写、开 PR，我负责拍板和合并。

当这条工作流稳定之后，维护就不再依赖我「哪天突然想起要检查一下」，而变成可以按清单重复执行的日常。内容可以继续往前写；底下那些看不见的基础项，也有人按同一标准接着盯。