#7

学海无涯，何以为舟？

最近在研究 Chromium 的源码，由此产生一点感想：现实世界的工程其实都是非常庞大的。即使像 Chromium 这样一个非常高质量的项目，哪怕它的每一个模块、每一行代码都有学习的价值，我们也是很难去完全学习清楚的。

我觉得一个比较有效的方法是结合自己遇到的问题，再去深入地分析研究。总的来说，带着问题，带着目的，带着实践的反馈去研究一个模块，效果是最好的。

当然这里还要注意三个问题。

第一个问题是，很多东西是超越代码的。比如说，这个地方为什么要这么设计？它是为了什么样的场景、解决什么样的现实问题？这些东西不一定在代码里面有完整的体现。

第二个问题是时效性。你对一个模块今时今日研究懂了，但是这个模块是会不断更新迭代的，可能你以后不做这个方向了，你的知识又过期了。所以，更重要的是你要从这里面沉淀出一些更有价值的东西，补充到你的知识体系里面，而不是跟着这个项目走。

第三个问题是：研究透一个模块固然重要，但是实际上很多模块和问题都是交叉关联的。绝对不能把自己拘囿在一个具体的问题上，要时刻用联系的眼光去看待整个模块。即使我们没有精力去把其他的模块搞清楚，还是要有意识地去建立一张知识的网络图谱，而不是孤立、局部地看待问题。

当然，这里涉及到一个问题：我们选择自己工作方向的时候，一定要选择一个有足够上限，或者说生命力足够持久的领域，比如浏览器。我觉得像操作系统、安全还有编译器，这些可能都是比较底层，不可能被完全替代的领域。但是像安卓的一些框架或技术栈反而很容易被替代，所以选择方向也很重要：选择一个能做 20 年的方向，或者选择一个能够让自己投入毕生精力的方向。

最近我就在研究chromium的渲染管线和窗口抽象设计。首先，可以以这个为切入点来研究 Chromium 的某些模块。

其次，可以与之前自己对于 WebKit 和 Flutter 的一些研究关联起来，形成对比。

#6

最近尝试了一下使用 AI + tldraw 绘制 UML 架构草图，感觉它目前还没有想象中那么顺手。

由于当前还是处在探索讨论阶段，所以还是需要通过这种手绘图的形式(类似草稿)。 之前这种情况都是通过纸笔绘制完成的。但是纸笔绘制有很多约束：

  • 一是调整不方便。
  • 二是确认之后没办法让AI理解，并且转换成PUML。

tldraw的优势是，AI可以完成初步的草稿，直接从讨论沉淀出草图，我可以基于可视化的编辑去直接调整。

这样效率是最高的，但目前还是有一些不智能的地方。

  • 图1是我之前写书时充分理解之后设计的架构图，在完整表述源代码架构的基础上，视觉上也非常的合理和有层次。
  • 图2是内容变多之后，AI甚至用了将近1个小时才完成架构图的调整。
  • 图3是最终生成的架构图，我之前也有一些调整。但看得出来，AI在没有引导的情况下，是不会输出特别有层次感和设计感的UML类图的。

#5

最近这半年多，一个很明显的感受是，AI 语音输入的能力变强了很多。

之前我还是用单句话输入，而且经常需要校验。

现在的话，我可以一段一段地输入，AI 会把整段内容进行排版。比如，我说话的要点里有 1、2、3、4 点，它会自动把内容排版成对应的列表格式。

我觉得打字本身就是人类为了适应和机器交互而采用的一种折中形态。人类从诞生以来，其实一开始是用语音交流的。

当然，我觉得文字输入也不会消失。比如编写代码，还有一些比较精细化的校正，这些还是需要文字来的。

就像人类在有了简单的交流能力之后，也发明了文字一样，我觉得后面一些精确性的场景还是要用文字，但是很多日常场景都会被语音所取代。

顺便整理一下几个月前关于语音输入的一些讨论。

#4

之前在Windows Server 2025上，手动安装 Codex/ChatGPT 桌面版一直失败，在 ChatGPT 里通过对话反复询问原因再手动去尝试，效率很低。

后来让 Agent 直接负责安装，让它根据安装过程中的错误自己去排查解决，全程不用我动手，效率反而高得多。

(原因是Agent会在失败是自己收集必要的信息，自己尝试新的方向，比我手动操作效率高很多)

#3

最近半年大量使用语音输入后，我越来越觉得它比打字更高效：

  • 语音和打字都是以将符号输入电脑为目的的。
  • 语音其实是通过亿万年的进化才获得的技能，人类将思想转换成语能力是写在基因里的。
  • 人类将思维转换成打字，其实是有一个后天的肌肉记忆的训练过程。
  • 语音的带宽，也就是输入的速度，其实天然是比打字快的。
  • 我觉得最终极的形态就是脑机接口，即直接将思想转变成电脑的输入，但这个目前来看还太遥远。
  • 语音输入和打字输入来比，可能唯一的劣势是同一个读音有多个含义，可能会存在重码的情况。但我相信，随着AI对于整句输入理解能力的加强，一定能够结合上下文语境选出最正确的候选词。

除了这方面的比较之外，我觉得语音输入还有一些优势:

  • 语音输入的启动成本更低，特别是大篇幅的输入，其实80% 的内容可以用语音做输入，只有 20% 的亲切化的语言需要用打字来校正。
  • 另外，长期对着电脑屏幕其实对颈椎、腰椎也有一定的伤害，但是语音输入不会约束你的身体姿态。我觉得这也是一个巨大的优势，特别对于我这种已经有轻微职业病的人来说。
#2

最近用AI把自己之前在博客园和CSDN写的博客都迁移到了这个博客。

迁移过程中，CSDN还由于邮箱和手机号码都已经是之前废弃掉的，花了点时间才找回来。

CSDN对文章私自进行收费的做法实在是太恶心人了，搞得我必须找回账号才能完成这些文章的迁移。 迁移完成之后我把C间上的文章全都删除掉了。

那时候还涉猎过AI贪吃蛇、AI五子棋，只可惜由于自己当时的视野有限， 没有对AI这个领域，做真正学术上深刻的调研和理解，错过了真正的浪潮。

截图留个记忆

#1

如何正确、优雅地向AI提供完备的环境信息，是一个值得系统思考的问题。

最近就遇到一个典型的案例：目标是用 C++ 实现一个样式，要对齐前端的某个 UI。

一开始总有一些细节对不齐，这时候如果通过【截图+拷贝 DOM 结构和 CSS 信息给 AI】，AI 总是不能够全面地理解。

正好我们框架预留了一个CDP接口，用于从 chrome://inspect/#devices 进行devtools的调试。在codex下，可以无缝地通过这个CDP接口让AI去读取目标页面的全部样式信息。

这样比手工贴截图更优雅快捷，甚至更节省token。

另外，这周还有一个场景是: 线上报了一个 crash，如果直接把Crash Stack给 AI 分析，AI 会出现幻觉。

但是如果把 crash 前后的日志同时提供给 AI，AI 就能够从日志中分析当时的用户行为，进行更准确的分析。

另外还要注意一点：AI 在分析的时候，一定要把代码切到出现 crash 的分支，不然也有可能出现歧义。

归根结底就是我们要提供完备而正确的信息，实际上我们自己人为开发的时候也是遵循这样一个路径