Natural Stupidity

Why DeepSeek's Prompt Cache Keeps Missing in Copilot Chat

Fri, 08 May 2026 18:24:00 +0800

If you've used DeepSeek V4 for Copilot Chat, you may have noticed something puzzling: the prompt cache hit rate sometimes drops from 99% to 37%, or even 13%, within a single conversation. The chat still works, but you're suddenly paying for tokens that should have been cached.

This post explains why this happens, which usage patterns trigger it, and what I've found digging through prompt dumps, API logs, and Copilot Chat's source code.

把代码部署到现场：All in House 组装小宇宙线下装置

Thu, 29 Jan 2026 16:00:00 +0800

从播客漫游日到大学路志趣探索之旅，再到刚刚结束的小宇宙播客大赏。
三年三场不同形态的线下聚会，活动装置的部分由小宇宙的技术团队 All-in-House 打造。
第一次认真考虑怎么把代码部署进物理世界的时候, 我还在盘算着把吃灰多年的开发板和焊台拿到公司开整。
但今天, 我们已经默契达成共识：不要炫技, 不要花里胡哨的声光电装置, 要传递真实的平台气质, 让社区氛围从 Online 流淌到 Onsite.
借着又一次播客圈的聚会, 聊聊我们怎么把代码“部署”到现场。

01. 最好的导航，是让你「迷路」

在技术选型阶段，我们脑暴过很多看起来很酷的 Idea： UWB 室内定位、基于摄像头的身份追踪，全场大屏实时同步...这些技术很酷，显得我们掌控能力很强，又能交出准确好看的报表。
最终我砍掉了所有“监控级”的方案，选择了让大家“迷路”（当然有些也是因为太贵太难）。

效率在线下聚会中是个伪命题。大家来这里不是为了最快找到某个点位，而是为了“相遇”。

在活动页做详尽的线上地图，只是为了帮用户在抵达前建立基本的空间概念。我们通过动线设计和点位安排，制造直觉上的“漫游”。一旦踏入会场，我们希望你脱离导航，被一段吵闹吸引、被一个装置打动，自然地去撞见那个点位，而不是被所谓的产品设计推着走。

技术在这里选择了隐身。“不确定性”的“相遇”此时开始变得迷人。

我不希望你盯着屏幕找路，而是看着身边的人。

02. Touch 主义

虽然在“导航”上选择了克制，但在核心体验上的设计原则是：将线上的意象，实体化为线下的触感。
小宇宙的用户和创作者都很熟悉“播放时长”和“里程碑”。在线上，他们代表着真实的收听习惯和回忆，在活动现场，我们希望它能被“触摸”。为了在线下呈现它，我们做了一个 3米×3米的巨型实体里程碑。
用手机触碰，巨大的屏幕瞬间响应，展示出属于他的独家数据。这是一个精心设计的“输入-输出不对称”：

你只是轻轻碰了一下手机，世界却给了你一个巨大的回响。

这里的技术实现非常有意思。经过好几轮与播控服务供应商们的搏斗，价格从几十万谈到几百万之后，我决定不搞这些高大上的东西了，直接把 Chrome 浏览器投屏，让工程师们把自己最熟悉的 Motion/Rive 搬上 LED 屏；没法像支付宝一样定制碰一碰支付的手机，那就写个 App 装进安卓手机让它把自己模拟成 IC 卡（不过现场证明这个“土法炼钢”确实很不稳定）。
这种 Homebrew 的方案，虽然听起来不那么“工业级”，但它让我们能以粗糙的手工活，在现场制造出令用户惊叹的 Wow Moment。对于主播而言，这是对他们创作生涯最隆重的实体加冕；对于听友，这是归属感的具象化。

03. 圈越热，周边（小垃圾）越多！

我们每次活动被搭建供应商吐槽最多的，就是零零散散的小物料多到用卡车拉。
引用老二次元们的话：

圈越热，周边（小垃圾）越多。

为了串联起路线与玩法，我们把小宇宙的贴纸，绑上淘宝商家们宣传了好多年的「屏幕印章」。碰碰装置打卡、在手机屏幕上盖章，收集活动专属的限定贴纸。
贴纸系统背后又联动着「收听时长货币」，听众们随时可以亮出 100 小时限定贴纸，彰显自己对主播与平台的喜爱；选择“贴纸”作为限制流通的数字资产，一定程度上是因为它不绑定真实的货币，它代表着独一份的现场体验与身份认同。

屏幕印章不是一个新鲜玩意了，但我依然选择了它。因为心理学角度看，物理动作能带来更强的“确权感”。
在手机屏幕上盖一个章，这种物理世界的仪式感，是单纯点击一个“领取”按钮无法比拟的。

只不过这背后，是调试阶段为了解决一个凹多边形相似度的问题，我在测试机上盖了几千次不同的章，盖到手都抬不起来。而 QA 工程师为了验证回归，在两天之后重新体验了一遍我的公务员生活，一度考虑去民政局工作。

我们更希望在活动结束后，用户带走的不仅是满手的周边物料，还有独属于这一刻的数字资产。让感动与回忆回归互联网空间，延续长尾效应。

Web 字体工程实践：DX、子集化与性能平衡

Sun, 12 Oct 2025 07:36:00 +0800

「展示文字」，一个Web 1.0时代就已经成熟的功能。30年后，它还在让中日韩（CJK）开发者们左右为难：
如果追求美观使用网络字体，就会影响用户的加载体验；如果投降使用系统字体，就得忍受不同端的字体差异。

经历过太多这样的取舍之后，属实有点麻木了。麻木之余还有点绝望：

到底有没有一个「简单」方案，能让任何CJK字体无痛集成进任何Web页面？

别预加载：看20秒Loading动画，只为加载一个20M的ttf文件😅
别裁剪字体：遇到UGC文本直接露馅
别影响性能：浏览器缓存应用尽用，Reflow影响降到最低
别搞太复杂：Service Worker、客户端预缓存……最后全是兜底流程和维护成本

The Pain of CJK Fonts

CJK字符集太大了。

Noto Sans SC的可变字体文件大小超过17M，包含上万个字形。剔掉中文字符集之后，Noto Sans本身只有2M。网络文件的加载需要时间，粗暴引入这些巨型字体容易导致用户体验出问题。

在追求「体验一致」这个跨平台领域的桂冠之前，我们搞不好先会被「视觉一致」卡住。system-ui 在不同平台上的实现五花八门，让页面里占据最多视觉空间的文字本身在不同系统平台上长得各不相同。

过去5年，我们也尝试过五花八门的各种办法：

方案	优势	问题	参考
编译时按需裁剪中文字体	字体文件大小合理	不能应对动态内容	font-spider
固定3000常用字字体文件	能应对部分动态内容	如果动态内容中有常用字以外的内容，就只能fallback到备用字体显示	https://h5.ruguoapp.com/talent-market 即刻App-即刻镇-人才市场
让用户等待字体加载	完全避免FOUT 能应对动态内容	加载时间长需要设计Suspense界面	https://h5.xiaoyuzhoufm.com/wrapped-2023 需打开小宇宙查看
Google Fonts Subset	预切分、按需加载	Self-Hosting困难大陆地区不友好	Google Fonts launches Japanese support
文本转SVG	支持可变字体可以按需加载	不支持多行省略等CSS Layout 字体本身特性不兼容	font2svg 特殊字体渲染方案

其中Google的字体子集化思路非常吸引我：nam-files帮助字体设计师拆分字体集，把一个巨大的ttf文件按unicode区段拆成多个woff2文件，上传到Google Fonts交付使用。
浏览器这边借助CSS font-face 定义中的 unicode-range 属性来实现不同子集woff2的按需加载。这些CSS特性的覆盖率也已经相当不错：

播客漫游日 Homebrew 技术小揭秘

Sun, 20 Oct 2024 18:15:00 +0800

技术方案总体分成3块：

LED屏幕：接收数据，完成个性化效果的展示
NFC 接触式互动：接收用户的指令和数据，操作LED屏幕的展示
屏幕印章：读取实体印章信息，匹配印章数据与虚拟物品

LED 互动屏幕

先感谢热心即友拍的现场视频！点击链接可以看到效果里程碑：

即刻

即刻

航行日志：（虽然一整天都排着大长队，但是似乎所有人都忘了拍视频…）

现场的多个大屏由上百个 LED 屏幕模块拼接而成：

10 个分散的meetup 屏幕组合：每个点位由 3 块 1:1 的无缝 LED 屏环绕拼接为 U 型
1 个里程碑屏幕组合：由左、中、右分别是 1:3、3:3、1:3 的 LED 屏环绕拼接为 U 型
1 个航行日志屏幕组合：由 7 块比例 1:1/1:2/2:2 的 LED 屏幕平面拼接

所有的现场用户都能使用不同的方式与屏幕装置互动，且都有事件驱动的动画效果，屏幕展示的内容由用户的数据动态决定。现场的屏幕装置数量又多又分散，策划前期我们很天真的希望能汇集到一个总控制中心来渲染显示内容，分发给多个 LED 显示。咨询了多家 LED 技术支持企业，获得了以下一些回复：

贵司的需求真的很有趣
上千平米的场地布线，电线做过，HDMI 线真没做过
十几路的 4k 输出和显示调整，现场恐怕需要搭个 GPU 机房才能堪堪满足渲染性能

后来经过朋友推荐联系到一家海南的企业做整包的解决方案。他们的解决思路是用 GPU 集群实时渲染拼接视频流，现场不同的 LED 控制台通过互联网拉流进行画面输出。虽然我们对延迟并不敏感，但出于对场地 5G 网络的总带宽上限（漫游者们会占用基站资源）和预算不足（简直是天价）的考虑，最终还是放弃了。

怎么办呢，需求都接了，只能拿出 Homebrew 大法。

前端是我们老本行，这些动画效果全都仰仗 V8 帮我们搞定，浏览器去渲染各自的网页，LED 映射网页就行了。按道理来说，如果同一个装置的 7 块屏幕所要展示的画面内容各自独立，他就需要 7 个视频源用于渲染输出，7 个屏幕就要 7 个电脑……所幸供应商大哥给我搞到了一款LED控台，能手动矩形分割输出的一整块画面为多个，代价就是这个控台体积巨大，现场工程师1个像素1个像素的去手动调整画面分割。