下午在手机上测博客，随手点了首页底部的聊天胶囊。
那个胶囊会自动把最新博文标题填进去。我没多想，就顺手点发送：
我愣了一下，又笑出声。
明明是我自己昨天刚发的博文，这家伙居然问"说说你身上发生了什么"——他把"我的小破站"里的"我"理解成了我（访客），以为是我的博客被 AI 公司围观了。合着标题里的"我"和"跟我聊聊"里的"我"撞车，他彻底分不清谁是谁。
我忍不住吐槽回去：
我当时正坐在咖啡店，wifi 还不稳，页面加载得慢吞吞。顺手又敲了一句：
不是聊天慢，是整个站都慢——这点他没 get 到。我又澄清了一句：
"我会转达给本人。"
我盯着这句话看了几秒。心想：好，等下次我翻聊天记录，这条就是工单了。
然后把手机一扣，先回家。
那些被我自己吐进数据库的槽
这就是我博客的真相：我自己也用聊天入口当工单系统。
按理说我是博主、工程师、repo 的 owner，要反馈问题，我应该开个 GitHub issue、写个 TODO、记到 notes 里。但那天下午，我正点着咖啡，没有打开终端的欲望；开 GitHub 要登录、选仓库、写 title，实在太重。
最顺手的事情，反而是跟博客里的数字分身抱怨两句，像跟朋友发微信那样。
三小时后回到家，打开终端，翻出今天的聊天记录，自己下午的吐槽原原本本躺在里面——"跟我聊聊……"、"这不是你的博文么"、"感觉访问你变慢了"、"不是聊天，是整个博客变慢了"。
数字 Polly 确实做到了"转达"。他把吐槽原封不动喂给了我自己。
两个 Bug，两种修法
第一个问题是代词歧义。前端把博文标题直接拼进聊天预设语——"跟我聊聊 我的小破站……"——两个"我"撞在一起，数字分身无从分辨哪个是访客、哪个是博主。
修法只有一个思路：给标题加边界。把"跟我聊聊"改成"聊聊你最新的博文《……》"，书名号把标题框起来，"你最新的"把归属锁死。一行改动，但这种 bug 只有在真实对话里才会露馅——测试覆盖不到"代词指代歧义"这种语境问题。
第二个问题更实在——整站变慢。回家后 curl 了一下响应头，真相一目了然：Cloudflare 压根没在边缘缓存 HTML。每次请求都穿透 CF，跨太平洋回源到美西的 GitHub Pages，TTFB 实测 2.7 秒。刚好那篇热门博文在社区传播，访问量涨了，每一次跨洋回源都在放大延迟。
修了三件事：让 CF 在边缘缓存 HTML（1 小时 TTL）；改写响应头把浏览器缓存从 10 分钟压到 4 分钟（微信内置浏览器咬缓存特别死）；在 GitHub Actions 里加一步——push 博文时自动 purge CF 全站缓存，等 30 秒 GitHub Pages 传播完再清。
推上去，跑完 CI，再 curl 一下：第一次 MISS，第二次 HIT，age: 4。边缘缓存立刻建立。闭环合上了。
顺手再砍三刀
修完缓存那晚意犹未尽，顺手跑了一遍 Lighthouse。Mobile 性能分 79，LCP 5 秒——罪魁祸首不是缓存，是聊天系统自己：每个页面加载时偷偷下载 816KB 的博文索引，只为在聊天气泡上显示一行最新博文标题。99% 的访客根本不会打开聊天框，却人人付这笔流量税。
砍了三刀：把 816KB 的索引换成一个 120 字节的轻量版（只放最新一篇的标题和链接）；264KB 的 favicon 重新生成，压到 3KB；213KB 的头像换了格式，压到 40KB。
再跑一遍 Lighthouse：92 分，LCP 3 秒，每页省了 434KB。
从下午咖啡店的一句"感觉变慢了"，到晚上的 92 分——中间隔了一个 purge_everything、三刀瘦身、和一个说"我会转达给本人"的数字分身。
留言板的黄昏，聊天入口的新生
整件事修完，我才意识到这个回路有多怪。
上一个时代博客的反馈回路是这样的：
我写博文 → 读者留言 / 发邮件 → 我看到 → 改
周期以周计，而且大多数时候留言区无人问津。
更尴尬的是——博主自己也用不上留言板。 你不会在自己博客底下给自己留言说"这个页面加载慢"。你要么开 issue，要么记 TODO，要么当场 commit。
今天的回路多了一条岔路：
我写博文 → 自己测 → 用聊天跟数字分身吐槽两句 → 躺在 D1 里 → 晚上翻到 → 修
关键在"跟数字分身吐槽两句"这一步。它比 GitHub issue 顺手太多——不用登录、不用选仓库、不用写 title、不用 reproduce steps，就是像跟朋友发微信那样说一句"为什么感觉访问你变慢了"。然后这句话就默默存进了数据库，等我哪天想起来翻。
这不是留言板的进化版。留言板是给访客的口子；聊天入口变成了给任何人的低摩擦工单系统——访客可以抱怨、我自己也能抱怨，甚至抱怨的还可能是"未来的我"留给"今天的我"的提醒。
我当初做这个聊天入口时想的完全不是这个。我以为它是给访客用的，是为了让博客有一点点"活着"的感觉。没想到我自己也开始用——把自己的吐槽扔进数据库，让另一个自己在晚上修掉。
数字分身不是客服，是传感器
数字 Polly 的价值不是"解决问题"——他不懂 Cache-Control、看不到服务器监控、连书名号歧义的 bug 都是他自己踩进去的。
他的价值是成为一个低摩擦的承接点：
- 我下午在咖啡店懒得开终端，对他抱怨了一句。
- 访客打开博客觉得慢，对他抱怨了一句。
- 微信里刷到旧内容的人，会对他抱怨"怎么还是昨天的"。
他把这些抱怨——不管来自访客还是来自我——稳稳地接住，塞进 D1。等到那个能修的人（我）回到终端前，他就成了传感器网络的最后一节。
这让我重新想起为什么当初要做这个聊天入口。不是为了展示"看我会做数字分身"，而是——博客作为一个作品，它的缺陷、它的慢、它的 bug，需要一个承接口子。这个口子不一定非得是"留言板"的形状；它可以是"和一个知道博主所有项目的小助手闲聊"的形状。
而一旦这个口子足够顺手，连博主自己都开始用它给自己留工单。
小尾声：那句"转达"
修完所有东西已经是晚上了。我顺手又打开那个对话看了一眼。下午那个懒得开终端、只想吐槽两句的我，和今晚这个打完 CF Cache Rule + 推了 deploy.yml + 验证了 cf-cache-status HIT 的我，其实是同一个人。
中间那个把两端连起来的，是一个说"我会转达给本人"的数字分身。他真的转达了。
我忽然有点期待下次自己在什么地方再踩到博客的哪个坑——那会是我下一次 git commit 的起点。
写博客的人能被读者听见，是上一个时代的幸运；
而能听见我自己，是这个时代悄悄递给我的礼物。