很长一段时间里，我都不确定这个网站是否真的需要一个博客。
我的大部分工作时间本来就在解决问题。有些只是普通的 frontend 或 backend 任务，有些却会迅速钻进很窄的领域：图像编码、浏览器行为、SEO 实验、基础设施故障、AI 辅助开发、媒体处理，或者某个从简单问题开始、最后变成连续几天调查的奇怪 production 问题。
做完这些之后，再写几千字似乎显得没有必要。
谁会读？
我能从中得到什么？
为什么不把问题解决掉，然后继续做下一件事？
后来我找到了一个对自己来说足够好的答案：有些工作付出的成本太高，不应该就这样被丢掉。
一个困难的问题，往往在我意识到之前就已经足够写成一整篇文章
我的文章通常不是从“这周我得写一篇博客”开始的。
它们从一个问题开始。
有时问题来自工作，有时来自自己的项目，有时只是因为我对某件自己不懂的事情产生了兴趣，然后不断往下挖，直到真正理解得更深入。
图像处理给我带来了很多这样的“兔子洞”。
一开始，一个任务甚至简单得有点可笑：
把这些图片变小一点。
你可以让一个 AI model 写脚本，几乎马上就能拿到一个版本。
但这并不意味着你已经拥有一个好的图像处理 pipeline。
第一个版本可能完全忽略 JPEG、PNG、WebP 和动画内容之间的差异；可能对所有图片使用同一个 quality 值；可能进行没有必要的 upscale；可能错误处理 transparency；可能保留你想删除的 metadata，或者删除你本来希望保留的 metadata；也可能只追求更小的文件，却完全不测量视觉损失。它可能在十个测试文件上表现完美，到了更大的规模却变成一个代价昂贵的错误。
一个能够成功运行的脚本，与一个我愿意信任的系统，并不是同一回事。
我的很多文章，正是从这个区别开始的。
我的 AI 工作流远比“问 ChatGPT，然后拿答案”慢得多
处理这类问题时，我会大量使用付费 ChatGPT 账户。
一个对话可能持续几天甚至几周。我提出问题，测试建议，把结果贴回去，质疑假设，检查代码，发现新的 edge case，修改 implementation，再次运行，比较结果，然后继续重复。
遇到特别深入的问题时，我围绕同一个大方向累计过超过 100 小时的工作。
这并不意味着我坐在那里等 100 小时，希望 AI model 神奇地自己找到答案。
这个过程是迭代式的。
典型流程更接近这样：
- 我描述问题。
- Model 给出初始方案。
- 我在真实数据上运行它。
- 某个地方表现很差、效率很低，或者干脆就是错的。
- 我把证据带回对话。
- 我们调整方案。
- 我再次测试。
- 又出现一个新的 edge case。
- 继续重复。
这个循环可能发生很多次。
真正有价值的结果通常不是第一个脚本，而是围绕它不断积累起来的失败、测量、修正和决策。
AI 让“生成起点”变便宜了，但并没有让验证变便宜
这也是为什么我觉得关于 AI 生成技术内容的常见讨论往往过于简单。
没错，一个 AI model 可以非常快地生成一篇看起来合理的教程。
它也可以生成一段看起来完全合理，却偏偏在最关键场景下出错的代码。
面对很窄、很难的技术问题，我几乎从来不满足于第一个看起来合理的答案。我想知道的是：真正运行之后会发生什么。
如果我在做 image pipeline，我会检查输出文件大小和视觉质量；我会看不同 source format 会发生什么；我会测试异常尺寸、alpha、动画和损坏输入；我还想知道 implementation 到底建立在什么假设之上。
如果这个脚本最终要处理一个巨大的数据集合，这些工作就更重要。
一千万张图片是我故意选择的极端例子，并不是说我的某个具体 dataset 就有一千万张图片。但它非常能说明问题：一个很小的系统性错误，如果被重复一千万次，就不再是小错误了。
生成代码的成本已经大幅下降。
判断这段代码是否值得在大规模环境里运行的成本，并没有。
Chat 是研究材料，不是最终文章
经历一次这样的长时间调查后，聊天记录里可能积累出夸张数量的信息。
其中可能包括：
- 失败过的方法；
- 后来被替换掉的代码；
- 有价值的 benchmark 结果；
- 日志；
- 误解；
- 修正；
- 对一些隐晦行为的解释；
- 不同方案之间的比较；
- 一开始没有想到的 edge case；
- 以及我最终开始信任的规则。
如果把这些东西全部留在一个私人对话里，我会觉得很浪费。
所以我会把有用的部分整理出来，写成文章。
文章并不是聊天记录的转录。实际上，大部分聊天内容根本不应该出现在文章里。
一篇真正有用的技术文章还需要再经过一层处理：删除那些什么都没教会我的死路，保留那些能解释关键问题的失败过程，验证 claim，重新还原 chronology，把 observation 和 explanation 分开，再把最终结果整理成其他开发者真正可以使用的东西。
这个编辑阶段非常重要。
AI 可以参与，但证据仍然来自真实的工作过程。
图像处理让我看到，一个“简单”问题到底能有多深
图像优化大概是我自己工作中最典型的例子。
我在这件事上投入了足够多的时间，以至于一开始看起来只是几个 encoder 参数的问题，最终逐渐变成了一个更大的系统问题。
问题会迅速变多。
当前处理的 source format 是什么？
它是不是动画？
尺寸该不该改变？
quality 应该怎么选？
应该用什么 metric 判断质量损失是否可以接受？
同一个 quality threshold 能否适用于差异非常大的图片？
如何避免 upscaling？
哪些 metadata 应该保留？
Transparency 怎么处理？
输出应该如何验证？
文件变小之后，真的值得付出额外的 encoding cost 吗？
当输入数据的分布发生变化时又会怎样？
这就是为什么我对那些只有五行的“终极图片优化”脚本保持怀疑。
它们当然可以处理一张图片。
但这和构建一个你真正理解其妥协与代价的 pipeline，是两件不同的事情。
对于我目前这些以图像为主的 workload，AVIF 通常是我最先考虑的格式。这是根据我所做项目类型形成的经验规则，并不是说全世界所有网站明天都应该删除旧格式。兼容性要求、source material、latency、encoder cost 和 delivery architecture 都可能改变答案。
真正有意思的地方，不是宣布某个格式“赢了”。
而是对 workload 理解得足够深，能够有意识地做出选择。
我也希望以后能在视频处理上钻到同样深度。现在还没有做到。这也是这些主题一直吸引我的原因之一：每当我以为自己已经挖到一个问题的底部，下面往往还有新的一层。
然后，一家日本网站找到了这个博客
我发布这些文章时，并没有期待什么明确回报。
这个博客并没有给我带来什么有意义的经济收益。我继续写，是因为我喜欢这个过程，也因为我宁愿把有用的工作保留下来，而不是让它消失在旧聊天和 terminal history 里。
然后发生了一件我真的没有预料到的事。
2026 年 9 月 17 日，日本的 Levtech Freelance 发布了一篇推荐文章，标题大致可以理解为“推荐给希望提升技能的工程师的博客”。
Levtech Freelance 的这篇文章把 JSVar 和另外几个工程技术博客放在了一起。
Levtech 属于日本一个很大的 IT 职业服务生态，Levtech Freelance 则主要面向 freelance IT engineer，提供支持和项目匹配。对我来说，有意思的地方并不仅仅是拿到一个 backlink，而是看到一个完全独立的编辑团队认为我的哪些工作值得介绍。
他们在介绍 JSVar 时特别提到了三篇文章。
其中一篇讨论了为什么我认为 Codex 和 TypeScript 在 production 开发中配合得很好，尤其是 TypeScript 的 type 和 compiler feedback 能够帮助更早发现 generated code 中的问题。
另一篇写的是我用 ChatGPT 把博客翻译成 20 种语言，并看到不同国家的搜索访问者开始直接落到本地化页面上的经历。
第三篇是我发布 10,000 个 AI-generated SEO 页面的一次实验，最后它并没有变成“轻松增长”的故事，反而成了一次失败经验。
这三个选择让我觉得很有意思，因为它们本身差异很大，却拥有同一种共同模式。
它们都建立在我真实做过的事情上。
我并不知道 Levtech 究竟是怎样发现我的
这里很容易讲出一个非常诱人的故事。
我不会说日语。
我的网站有日语版本。
一家日本工程媒体发现了这个网站。
所以，一定是把博客翻译成日语导致 Levtech 发现了我。
我无法证明这一点。
也许日语页面确实起到了帮助。
也许搜索把他们带到了一篇英语文章。
也许有人分享了链接。
也许他们完全通过另一个渠道找到了网站。
我没有这部分 attribution data，所以我不会为了故事漂亮，就把它包装成一个干净利落的 SEO case study。
我真正能确认的事情要简单得多：我把博客发布成了多种语言，后来一家日本媒体觉得它足够有意思，于是把它收录进了一篇编辑推荐文章。
这本身已经是一个不错的结果。
尤其让我满意的是，本地化本身原本也是一个投入不小、回报很不确定的实验。
这次收录之所以重要，是因为它是一种独立的外部认可
这里所说的“认可”，并不是说 Levtech 证明了我写的所有内容都是正确的。
他们没有审计我的 codebase，也没有复现我的每一个实验。
真正有意义的事情要朴素得多。
世界另一端，有人在为一个我无法用他们的语言直接沟通的读者群体写作，而他们认为我的工作足够有价值，值得整理后介绍给自己的读者。
我没有主动向他们投稿。
我写那些原始文章时，也不是为 Levtech 写的。
我完全没想到自己会出现在日本的推荐列表里。
正因为这样，这个结果对我才有意义。
它让我意识到，一篇非常窄的技术文章，并不一定需要巨大的受众才值得发布。
它只需要对正确的读者有用。
开发者在 2026 年还应该开始写博客吗？
对我来说，答案是肯定的——但有一个重要条件。
你必须真的有一些东西想写下来。
如果只是因为别人告诉你“每个开发者都应该打造个人品牌”，我不会建议你因此开始写技术博客。
如果只是期待 passive income，我也不会开始。
我更不会为了填充内容，去反复写那些已有更好官方文档的技术概述。
但如果你的工作会不断产生一些“如果我刚开始时能搜到这个就好了”的经验，那就完全不同。
把它们写下来。
写那个奇怪的 production 故障。
写那个比预计多花了三天的优化。
写那个推翻你原本假设的 benchmark。
写那个看起来很优雅、最后却失败的方案。
写最终 implementation，也写清楚为什么最显而易见的实现其实并不够。
这些内容，才是很难靠通用知识凭空制造出来的部分。
AI 给我的写作材料更多了，而不是更少
AI 并没有让我觉得技术博客已经过时。
对我来说，几乎正好相反。
因为获得一个初始 implementation 或 explanation 比以前快得多，所以我可以调查更多想法。
但更快的迭代也会制造更多 evidence：更多版本、更多日志、更多 benchmark、更多失败尝试，也有更多东西需要检查。
这些原始材料只有在有人真正去判断什么是对的、什么是重要的之后，才会产生价值。
一个包含 500 条消息的 AI 对话，并不会自动变成知识。
一个最终通过真实测试的脚本，再加上对之前 20 个失败版本为什么失败的解释，则可能会。
这正是我希望博客能够保存下来的区别。
发布文章，是我阻止有用工作消失的方式
大多数技术工作其实都比想象中更短暂。
一个困难的 bug 被修复。
Terminal 被关闭。
Deployment 成功。
Chat 在历史记录里逐渐沉下去。
六个月之后，甚至连我自己都可能已经忘了，最终 implementation 为什么会变成现在这个样子。
写作改变了这一点。
它迫使我在证据还存在的时候重新还原 reasoning。
它会产生一个可以被搜索到的东西。
它也会成为我自己未来工作的参考。
而且偶尔，它显然还会抵达一些我完全没想到的人那里——甚至包括一个使用我不会说的语言的工程媒体。
直到现在，我仍然没有什么特别复杂的理由来解释为什么要维护这个博客。
我喜欢学习。
我喜欢做东西。
我喜欢对那些一开始看起来很简单的问题挖得过深。
而当我为了得到一个有用答案已经花掉几十个小时，有时甚至超过一百个小时之后，我就不想再让那个答案死在一个聊天窗口里。
对我来说，这已经足够成为发布它的理由。
如果你的工作也会产生同样来之不易的知识，我想，这也可能已经足够成为你发布它的理由。