031 | 编译日志, AI对我们的影响

conversations with builders and thinkers

① 编译日志的来由

过去的一年之间, 我的工作的氛围有了极大的变化. 从team role转到org role; 从带组员转到带TL; 从跟IC协作到跟EM协作. 在这个过程里面, 我发现自己难回到曾经那个up主的节奏里: 我的表达欲受到了一些冲击, 似乎因为看到了更多的人和事, 导致过往的’经验总结’显得过于肤浅, 无法入目. 基于这个认知, 我把小红书, YouTube, B站上面的视频全部下架了.

我姑且把这样的心理变化归类为个人成长, 但本质也是一种被打磨后的怯懦. 回想年少的自己, 未曾有顾及别人利益的情商, 看到不顺的事情还会写写文章; 而今, 每每有想法却无处表达, 瞻前顾后, 只能在网上给认同的观点加个赞.

2019年是我表达欲的巅峰, 那时候做了很多coding interview, 也做了很多人生低谷的自我检讨. 当时的我认为我是有信息差的. 而今, 我已经不具备明显的信息差, 尤其是跟硅谷大厂的同事们相比, 我能给到的信息, 远不及身边人.

这几年我都很喜欢听podcast. 从Mordern Wisdom听来的一个想法我非常赞同. 其实我并不需要是整个房间里面最聪明的那个人 - 做最愚蠢的那个人, 做提问的那个人, 没什么掉面子或者不好的. 这句话在我心里来回折腾了好几年. 现在的我认为, 我的能力从来不是有超宇常人的眼界, 但是我具备一定深度的同理心和好奇心. 这可能是一个新的方向.

2025年初的时候我在西雅图出差, 那时候已经有了重整podcast的想法. 当时我去跟课代表立正聊天, 受到了鼓励, 次日就录了编译日志的第一期: #1 课代表立正: 打开第四面墙, 走进课代表的世界. 就录视频而言, 我已经有了5年多的经验, 但查资料做采访, 那算是头一回.

在给播客取名字的时候, 我给它的定位, 是要找寻builders and thinkers. Builder字面意思, 就是那些创造者/构建者, 同时也包括了自我提高的人, 尤其是那些运动, 训练, 比赛的人. 其次, thinkers顾名思义, 就是乐于思考的人.

在过去的几个月, 我断断续续做了这些采访.

• 硅谷

  • #8 Heng: 在科技大厂从Staff Engineer转职Engineering Manager

• 美国

  • #2 Wilson: 接纳洛杉矶这座城市, 她也会接纳你

  • #3 GeekPlux: 打开美国的“战争迷雾”, AI时代的自我补全

  • #4 QIN: AI时代, 中式拼搏还是美式松弛?

• 跑步

  • #5 Wade: 越野入坑? 先把钱花了 | UTMB

  • #6 MuJing: 马拉松赛道上的人生刻度

• 人物

  • #1 课代表立正: 打开第四面墙, 走进课代表的世界

  • #7 Dr. Peter Jamieson: AI Dynamics, Empathy, Be Great Educators Through Games

做采访很有意思. 每个人, 都是他自己世界的main character. 哪怕有一些问题我是知道答案的, 但是他们每个人都有自己的故事和全新的见解. 同时, 我能够感知到每个人性格中独特的质地; 也许是特定沟通环境的协助, 几乎每一次, 我都有那么些个瞬间, 发现 ”原来你还有这样一面!” 或者 “原来我们的观点如此相同!”, 这一点让我非常惊讶和惊喜. 也许这是人与人, 面对面直接沟通的力量.

The Build Log, 我觉得编译日志是个好译名, 你怎么看?

---

② Vibe Coding | 人脑的认知负荷?

vibe coding 的中文叫啥来着? 氛围编程? 沉浸式编程? 怎么说都好, 大势所趋. 最早认真尝试, 应该是从课代表的superlinear.academy community里面开始的, 大约是2025年初. 中间断断续续的, 其实我上手非常的慢. 今年Q2的时候, 我的工作工作项目逐渐地跟internal tools, AI agent有了那么些关系, 我就不得不看了. vibe coding 已经席卷了科技公司的工作模式. 如果还没有拥抱vibe coding, 我觉的就有一种拿着石器时代的工具在工作的感觉, 什么事情都比别人慢好几倍.

#7 Dr. Peter Jamieson: AI Dynamics, Empathy, Be Great Educators Through Games

这这一期节目里面 (英文), 我跟Dr. Jamieson聊到一个观点, 为什么有时候年轻的同事, 反而比我们这些老员工更不愿意接受vibe coding? 照理说, 不应该反过来么? 难道是我们更加有紧迫感怕被替代? 我们得出的一个观点: 软件工程师的学习和训练过程, 不是教这个人’怎么写代码’, 而是教他该如何’思考/设计代码’. 写代码, 只是一个最终的结果, 而做系统, 架构设计, 才是一个工程师从菜鸡到senior的主要成长标志. 那么, vibe coding从0到1的效率那么高, 就会让一些年轻程序员担忧失去了学习的机会; 再或者, AI现在已经能取代的, 恰恰是入门级程序员的工作, 这样也会让他们有一定的反感.

我觉得这是个值得深思的问题. 在AI帮我们完成很多事情的时候, 它做到的到底是”1/ 重复性的工作”或者是”2/ 我原本就会放弃的思考”, 还是”3/ 我原本必须该有的思考”.

• #3是比较危险的: 它会导致我们思维的简化, 对AI的重度依赖, 对自己能力的质疑.

• #1, #2 会提高我们处理事情的效率和准确度, 甚至帮我们开阔一些原本会放弃的路.

有一个词叫做cognitive load, 就是我们人脑的认知负荷. 我们一定会有这样的感受, 如果学习的时候看了很多东西做了很多题, 人是会非常疲倦的; 工作时, 如果不断的开会, context swtiching, 一天下来, 也会感觉超负荷超级累.

认知负荷的理论, 有三个方面:

• 内在负荷: 学习材料本身固有的复杂性所带来的负荷。例如，一个复杂的问题本身就比一个简单问题产生更高的内在负荷。

• 外在负荷: 信息呈现方式不良或任务设计复杂所带来的不必要负荷。例如，不清晰的指令或不相关的信息会分散注意力，增加处理难度。

• 有益负荷: 与信息加工、知识构建和长期记忆的建立（形成图式）相关的认知努力。这种负荷是积极的，促进了真正的学习。

显然, 内在负荷是我们不太能改变的; 而外在负荷是我们可以控制的. 乐观地去向, 有AI帮助的时候, 就会直接改变我们cognitive load, 我希望他能够帮我减少外在负荷, 在维持我们所需要的有益负荷.

就比如说, 我们家的马桶按键坏了, 我需要找到更换它的教程然后自己动手学会如何更换:

• 内在负荷: 换零件本身的难度和它的基本原理

• 外在负荷: 零件叫什么名字, 英文怎么说, 在哪个地方可以买到, 是不是很贵, 是不是必须要专业人士来检修

过去, 我可能要在外在负荷上面寻找很久, Google搜索, YouTube去找相关的视频. 因为我没有办法把损坏的零件在网上直接找到, 同时因为我缺乏这方面的知识, 我的搜索是非常没有效率的. ChatGPT帮我瞬间解决了这些外在负荷, 并且负责地告诉我这是几块钱就能解决的小问题, 完全可以自己搞定. 这就是一个完美的高效帮助.

最终, 我仍然学会了该如何换零件(有益负荷), 但是外在负荷减少到几乎为零.

回到vibe coding, 我就在想, 有没有什么好的方式, 让我尽量减少外在负荷, 而维持有益负荷?

1/ 我觉得我们在开始写一段代码的时候, 应该自己去掌控的是对整个项目的设计, 安排. 在给coding tool下任务的时候, 还是把它当做一个intern来对待, 尽量在不废话的前提下, 把系统e2e要做的事情, 先自己想明白, 再写下来安排好.

2/ 当vibe coding报错的时候, 我们应该去积极的看报错分析, 理解报错的缘故, 做调整跟安排. 在这个时候, 做出积极的改变, 把这个错误记录下来, 写在coding agent的代码规则之中, 避免下次不犯错. 这一步就是有益负荷, 我们自己做出了努力去思考, 并且积极做出了选择, 而不是把选择交给AI.

关于AI对我们的影响, 你怎么看? 欢迎在任意地方留言!