古法手搓文字的自留地

#14

之前也大大小小做了20多次分享，感觉在非AI时代分享这个事情还是比较因人而异的。以我自己为例，通常我对某一个主题进行分享的前提是，我已经有了一定的时间和理解，然后在短时间内做一个系统的梳理。分享的过程，也是我自己查漏补缺，审视自己的过程。但是没有什么章法可言。

AI时代下，我重新思考了一下这个过程。并设计了一个可以重复的SOP流程。

核心是将这个抽象的过程做成一个流水线，具体步骤如下：

  1. 构建想法与分享大纲（人工）；
  2. 针对想法和大纲中的举例实证进行实际的调研；（AI辅助，人负责验收和判断）
  3. 生成文字描述版的分享笔记（类似于用于渲染的 DOM tree）；（人工主导）
  4. 最终基于这个分享笔记，使用 slidev 等工具生成最终渲染的 PPT。（AI主导）

这个流水线不是单向的。调研可能修正原来的想法，写笔记可能暴露新的调研问题，试讲也可能推动内容和表达的调整。发生变化后，再让 AI 辅助更新受影响的环节。

我觉得最核心的原则是，把资料查找、验证中的执行工作，以及最终幻灯片的制作交给 AI；人把精力放在观点形成、证据判断和表达取舍上。

我不太认可丢出一个想法，让 AI 全盘接手并生成 PPT 的做法。因为我觉得 PPT 是讲者理解与判断的外显。如果跳过理解和审核，直接接受 AI 生成的整套 PPT，讲者就容易停留在复述页面内容，难以解释观点的依据，也难以回答追问。。

人可以委托很多执行工作，但要观点和其表达过程本身要由人把控。

#13

谈谈REA

最近有一个非常火的项目 ：morluto/rea。因为自己平时也经常做一些逆向的工作，有的是工作需要，有的是个人需要。由于这个领域比较特殊，我之前都没有公开分享成果，但确实也是自己颇有心得的一个领域，所以想分享一下自己的感受。

首先是 rea 干了什么？

我对于 AI 在工程领域的各种爆火项目的感觉是：没有什么革命性的创新或“0 到 1”的工作，更多的是对工程经验的一种整合和萃取——将优秀的工程经验整合为标准化的 SOP 流程，提供给 AI Agent。

在没有 REA 之前，优秀的逆向工程师也是这么去分析的。但是 REA 做的是什么事情呢？它把各种技术产物（比如二进制的产物、Electron 的产物、安卓的产物等）的逆向流程做了标准化。有的产物的逆向流程有非常权威的工具，rea就直接复用了，有的没有标准化的工具，它就自己写了分析引擎。

这些东西在没有 REA 的时代，是需要大量学习才能掌握的和完成的。REA 把这些东西全都做成了标准化的流程，带来的结果就是：

  1. 对于会提问的普通开发者：做逆向的下限大大提高了。可能加固水平比较一般的软件，很容易就被普通人破解了。
  2. 对于懂逆向的人：他的上限也被大大提高了。因为很多机械性的工作 REA 都帮他先做好了，他可以在一个很高的起点上开始自己定制化的工作。另外AI的理解带宽比人大，人能够更加专注在自己的核心目标上了。

因为AI的到来，导致一些半开放性的经验的复用变成了可能（没有AI的时代，我把我的经验萃取出来，其他人也无法复用用，因为他没有这个背景知识，但是AI是有这些背景知识的，就让此类经验的沉淀有了意义：隐性知识第一次有了可执行的读者），软件工程领域来到了大蒸馏时代。

#12

做ToB类、办公类、效率类、工具类的软件，其本质就是要对抗某一个场景下的熵增(Systeom 2)，因为趋于无序是自然的规律。 典型的：笔记、Todo、备忘录。

做toC类、生活、娱乐类的软件，通常不需要关心熵增，核心是爽就行了， 解决了当下的、具体的问题（System 1）就行了。

典型的：购物、音视频、游戏。购物记录、浏览记录、游戏对局记录，这些数据用户可能有一定的查看诉求，但是并没有很强烈的诉求需要将它们整理并持久化。

像PS / IDE / CAD这种工业软件，感觉兼而有之。

#11

国庆节前赶了一个产品demo的需求，时间紧，任务重，特别是中间遇到了几个 bug，花了不少时间才解决。

节后趁着脑子清空得差不多了，做了一下复盘，感觉最大的问题是：

  1. AI 对于一些模糊的描述也会进行错误的执行，而不是像正常人那样刨根问底，AI 经常自以为知道。
  2. AI 无法全面地评估自己的实现结果。至少在客户端这种 UI 需要通过编译运行并且会动态变化的场景，是很难完成从开发到验证的闭环的。

针对我的具体问题，比较特殊的是必须要掌握充分的背景信息，包括：Mac 的机制 、 Chromium 的机制、 我们项目的实现细节 。 加上这个项目有很多复杂的UI交互状态，一开始如果没有约定一套术语的话，会导致AI经常犯一些小错误。 这里有一个比较重要的经验是：要定义好术语，并将术语对应的代码位置做一个大致的绑定，这样能大大减少歧义。

另外，这个项目也有很多的背景知识，不能让 AI 每次新起一个对话去探索。这就涉及到外置的记忆，或者说这些文档如何去维护、如何去处理冲突、如何去防止腐烂、如何迭代进化。

AI维护的文档最核心的问题，是要保证人在时时刻刻也能够看懂并使用。一味地让AI去更新文档也没有用，最终只会膨胀到让人无法使用。

#10

最近在开发一个项目，我自己思考了一下，还是挺复杂的。具体复杂体现在几个层面：

1 UI就挺复杂的，要和各种的系统窗口打交道，并不是一个纯粹的Web UI 2 功能也挺复杂的，需要获取各种系统能力。另外还要去理解腾讯云、阿里云的各种语音SDK。 3 内部状态的维护也挺复杂的，语音输入各种交互状态之间的切换非常复杂，还要和UI保持一致 4 另外就是它本身是一个Agent的项目，导致调试起来也有很多不确定性

之前用Codex，因为上下文太短，导致经常触发上下文压缩。最近切换到了Claude Code, 这个问题好了很多。

但是今天上午，我随便问了个问题，CC+Sonet-1m 给我查了快1个小时，我烧了100多块，我还是有点无法接受

因为我觉得我这些需求虽然复杂，但如果向AI表述清楚了，DeepSeek V4是完全能够胜任的。

最近AI Coding有点发毛了，感觉非常复杂的场景还是要人为的强力介入和引导

特别是当前这个项目，AI无法闭环完成验证，而且自身的各种交互和行为细节又非常的多。

#9

最近一直在 Codex 里面使用支持 response api 的 DeepSeek v4，但有一个问题是 Codex 默认写死了 300K 不到的上下文窗口，导致开发大型项目时需要频繁地压缩上下文，体验实在太差。

配置起来还有点麻烦，最近考虑引入其他工具了（Claude Code近期更新不少）~

#8

以后不会有产品和开发了，只有【发现&提出问题的人】和【解决问题的人】。

#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 点，它会自动把内容排版成对应的列表格式。

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

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

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

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