Tag: 设计

第三个网站 Read PDF Aloud 上线了。

12 月 14 日开工，1 月 1 日凌晨上线第一版，到今天把已知的 bug 和不完善的地方全部修改完，一共花了大半个月的时间，是我工期最长的一个站。

Read PDF Aloud 核心的功能和交互相比之前的网站都要复杂，所以踩了不少坑，都是经验不足导致的。

程序设计上，这次核心的交互逻辑是用面向对象的方式完成。

svelte 的状态管理方式天然适配面向对象范式，官网文档上也专门就 runes 在 class 内的使用做了介绍。这次真正使用面向对象，我也感受到了面向对象的优势，心智负担低，越写越顺手。

但这一切建立在对象设计合理的基础上。如果一开始规划有问题，后面少不了返工。我这次就经历了推到重来的过程。

第二个坑是 CloudFlare Workers。这次的涉及到 PDF 的文字提取和 TTS Api 的调用，所以需要一些简单的后端功能。我最初为 PDF 解析和 TTS Api 调用编写了相应的后端接口，都非常简单。

但是，在我第一次部署到 Worker 后，我就遇到了后端报错。一开始我还以为是我部署方式不对，后来我又怀疑是不是我用的库不适配 Worker 环境。

看完 Worker 的后台日志以后，我才发现，错误原因是 Error 1102: Worker exceeded resource limits。

简单来说，就是 Worker 对单次请求消耗的 cpu 时间有限制。免费版是 10ms，付费版是 30s。一些计算量比较大的任务，难免会占用更多 cpu 时间。当时我心都凉了，一度考虑要不要租个服务器。我还上网查了一下，发现踩到这个坑的，不止我一个。

后来理智说服了我，在没有赚钱的情况下，不能乱花钱。那就只能让用户体谅一下我的难处了，把 PDF 解析放在了用户的浏览器里。

剩下的坑就是一些交互设计上的问题了。

我一直觉得写 ui 最浪费时间，因为很容易陷入细节调试的地狱，我就看这个设计不顺眼，但是又不知道怎么改好，想太久，时间就白白浪费了。

之前做的网站交互都比较简单，这个问题不明显。这次的交互方式更复杂，尤其是阅读器的界面，我边想边写边改，来来回回拉扯了两天。昨天上线，发现交互有问题，又改了一天。现在这版算是没有大毛病了。

编程好难啊。

为什么 Ai 生成的东西，会有一股廉价感呢？

我觉得这种廉价感源于「特征太明显」。

比如说，文本内容比较空泛，缺乏细节。图片看起来非常油腻。视频的话，人物动作不自然、连贯，人物的声音也缺乏语气。这些都是人类能比较明显感知到的特征。

人类总是喜欢在显而易见的事情上追求完美。

我每次写 UI 的时候，都十分折磨，因为我总觉得不好看。写一点，改一点，再写，再改。一天下来什么进展都没有，一直在原地打转。

但我写后端代码时基本没遇见过这样的问题。

所谓金玉其外，败絮其中，就是这么来的。

第二个工具站Glitch Text Generator。

这次算是做了一个有用的东西，能帮你把文字变成特殊的风格样式，比如说：

Glitch Text，可以变成：

₲łıꮏȼħ Ꮏєӿꮏ

ǤɫɨŁčꚕ ₸€ҳŁ

Ԍłıŧϲħ Ŧєӿŧ

𝓖𝓵𝓲𝓽𝓬𝓱 𝓣𝓮𝔁𝓽

还可以变成：

G̸̨̨̣̪͈͎̩͔̟̦͇̞̹͉̦̣͓͟͡l̞̰̭̘̯i̶̵̢̠͉̹͙̠͚̲̟̯̯͡͝t̷̛̛̜̲̫̝̱͚̳͇̠̮̬͖͎̭͙̤̯̝̠͍̘͖̤͎̘́̀̍͑͝҉̸̧̛͕̤͚͍͍̗̪̺̜̹̞̮̜͎ͦͨ͜͡͡ͅ͏̵̷̡̛̠̝̫̜̞̞͙̩̖̫̮̗͉̖͕̼̲̖̗̞̻̯͕̺̥̇̕͢c̵̢̡̦͚͈̻͕͕̭̭̤̘̣̙̺͙̬̟̖̭̥̻͗ͯͧͣ̀͢͝h̷̡̛̫̮͈̪̫̗̣̞̱̬̰͔̩͉̯͍̦̥̣̲̮̰̪͖̝̿̈́͊̀̀ͦ͘͟͜͜͞ ̡͇̫̳̞̳҉̨̹͉̟̳̹҉̨T̶̶̢̛͖̱͍̳̩̪̪̗̯͉͉̗̬̖͎̻͈̝͈̥̖̯̯̬̠̩͚̩͇͉͚͔͖̼̣̙̥̳̥̜̹̜̲̼̜̱͚̩͙̈͌͊͗̐̕͟͟͟͢͟͢͝͠͠͡ͅȩ̵͜͡͝x̮̻̱͎͕͜҉̶̷̷̷̷̶̢̢̧̯̘̣̣̝̙͓̬͈̰͙̜̤͎̮̜̪͇̼͇͙͈̖̻̠̟̝̥̘̫̥̟̮̠̮͉̝̪͖̬̬̺̤̙̞̯̤̯͍̪̟́̑ͣ͂̃̅͘͟͢ͅͅͅͅt̳̹̝͈͚҉̵̷̢̧̢̡̛̲̫͕̮̫̱͉͓̲̼̪̟̱̟̝͔̙̺̰̳̬͓̟̘͚̺͙͙̯͎̪̜̫̺̘̰͔̜̼͎̞̺͇̦͎͍̟̯̌ͫ̐ͯ̕͟͟͞͠ͅͅ҉̶̢̫̮͕͈̞̉̕͢͟͢

其原理是 Unicode 字符变体。

Unicode 字符集中有很多不同的字符，这些字符看起来很像，但实际上是不同的编码。

例如，字母 “A” 有多种变体，如 ”𝐀“（粗体 A）、”𝔄“（哥特体 A），还有”₳“（阿根廷比索符号）。

Unicode 字符集里有很多奇奇怪怪的字符，甚至还有古埃及象形文字 AKA 圣书体:

𓂀 𓆐 𓆡 𓆦

用来用去还是 VS Code 好用……

在写前端项目的时候，Zed 的内存开销相比 VS Code 没有太大优势，但是 VS Code 的插件比 Zed 更好用，即便是同款插件，VS Code 版本的似乎也更智能一点。譬如 Svelte 的组件导入，VS Code 版本的 Svelte LSP 插件的补全提示很快能显示出来，而 Zed 版本几乎只能靠 AI 的 inline hint，插件好像就不会显示组件的补全。

另外 VS Code 的动画会更顺滑一点，不知道是动画还是字体效果的缘故。

「低耦合，高内聚」是软件设计的法则，目的是让复杂的软件尽可能模块化。这样设计出来的软件，可以做到，一个模块出问题，另一个模块正常运转；或者改动一个模块，不影响另一个模块。

在我看来，搭建工作流、SOP，或者就是日常使用软件，也应该遵循这样的原则。毕竟你也不知道，未来你工作流里的某个软件，会不会出现更好的替代品。

所以，把自己完全封锁在某个生态里，无异于断绝新的可能性。

AI 生成产物的廉价感源于大量的重复。尤其是图片和视频，一个新的视觉样式，第一眼看过去很别致，但是看多了，就会迅速向平庸滑落。

所以创意的第一要义，就是要不一样。

但创新是最难的，[2025-10-12_13-38-01|创造，其实是一件很痛苦的事情……]。

毫无意外，macOS Tahoe 和 iOS 26 就是一次计划报废。新增加的毛玻璃特效在当下这个时点看不出交互上的必要性，反而会持续消耗计算机的算力。我观察了一下我 MacBook 的 GPU 用量，此前闲时用量很少超过 20%，升级到 Tahoe 后，闲时大概 30% 左右，CPU 闲时用量此前很少能超过 20%，现在也来到了 30%。苹果这边是真没活了，就想通过这种方式催促用户换新设备。

一旦你发现了这一简单的事实——你所谓的‘生活’，你身边的所有事物，都是由那些并不比你聪明多少的人虚构出来的，那么你的生活就会变得宽广许多。你可以改变它，影响它，创造属于自己的东西，让他人来使用。一旦你了解到了这一点，你将从此变得与众不同。

—— 乔布斯，出处

theme 献给深夜编码的人，murmurs 献给热衷于在深夜思考的人。