小盖 (@xiaogaifun)

字节对大厂 AI Coding 的反思，好真实。 字节技术副总裁洪定坤的分享，我来回看了好几遍，很有启发。 字节在 AI Coding 方面的实践还是很有代表性的，推荐所有做研发的同学都可以看看。应该会感同身受。 我看完记了一整页笔记，分享给大家。 我甚至觉得可以把这个分享理解为字节在 AI Coding 上的一些真实反思。 根据自己的理解，我把这个分享里对我有启发的几个判断展开来聊一聊。 其中会夹杂很多我自己的感触，想看原文的可以直接去找演讲全文。 反思一：AI 代码贡献率不该是 KPI AI Coding 基本上都已经逐步进入了各个公司的生产流程。 很多人都在说自己的业务有 90% 的代码是 AI 生成的，乍一听，感觉很恐怖。 但其实，AI 对研发的提效没有外界想象的那么高。 洪定坤举了 TRAE 团队的例子。TRAE 本身就是做 AI 工具的，所以这个团队对 AI Coding 的采用非常积极。 过去半年里，他们有 94% 的代码都是 AI 贡献的。但人均需求吞吐率只提升了 60%，也就是之前的 1.6 倍。 这就有疑惑了，AI 写代码的速度至少是人的 10 倍以上，如果 90% 以上的代码都是 AI 产出的，效率至少应该提升 5 倍或者 10 倍吧？为什么只提高了 1.6 倍？ 字节得出来的结论是，单一的指标，比如 AI 代码占比，根本没有办法代表真实的生产力。 如果把 AI 代码贡献率当成 KPI，结果就是大家都去优化 AI 的生成量，而不是优化交付能力。 看起来 AI 用了很多，但系统的效率并没有真正变好。 那为什么 90% 的代码都是 AI 写的，人效才提了 1.6 倍？一个很重要的原因是，写代码只是整个研发流程的一个环节。 写之前要理解需求、写 Spec，写完之后要验证功能、提交发布，这些环节如果还是传统方式，光把写代码加速了，整体效率提不上去。 洪定坤把字节在这方面的尝试叫做系统化的 AI Development，核心意思就是 AI 不能只管写代码，得让它进入更多的研发环节，整条链路都跑通，效率才能真正上来。 前两天出去的时候还跟别人争论这件事。现在还有不少公司在追踪员工到底用了多少 Token，说白了，这是在追踪过程。 更应该关注的是，用了这个工具之后，从结果层面去看，交付到底有没有变得更快、更可靠。 一个团队天天说自己 AI 工具用得贼溜，消耗了多少 Token，但没有什么有效的产出，那这到底是好事还是坏事。我觉得这是一个值得每个管理者思考的新问题。 反思二：功能正确≠工程可用 Vibe Coding 的理想状态是就像聊天一样，用自然语言表达自己的需求，最后做出来想要的产品。 如果哪里不对，再用自然语言和 AI 沟通，让它修改。这是过去一年 Vibe Coding 风靡的思路。 对于不太复杂的应用，这种方式完全没问题。我自己做的一些项目基本上就是这个流程跑下来的。 但只要是做生产级的软件，无论公司大小，流程肯定不是这样。 因为公司里必然有老代码，有一套约束。怎么复用已有的组件，安全和权限怎么处理，性能怎么保证，还有兼容性、可维护性。 正经写过工程代码的人都清楚，Vibe Coding 描述的那个状态是比较理想化的，更适合做小项目和验证想法。 真正的程序员虽然也在 Vibe Coding，但流程跟理想状态不一样。 字节内部做了一个实验来验证这个判断：三个模型，三个 Agent 框架，两两组合成 9 种方案，针对同一个需求，每组跑 100 次，总共 900 次。 结果发现，AI 在功能正确率上表现还不错，所有组合都超过了 80%，也就是说，AI 把功能写对的能力已经过了及格线。 但无论哪个组合，生成代码的工程质量都不太好。比如 UI 不对，没有复用组件，性能有问题，结构不符合规范。 这些问题大家在用 AI 写代码的时候应该都碰到过。 现在所有上了牌桌的 Coding 模型，都已经过了 Opus 4.6 这个级别的临界点，模型可以自主写代码了。 这个时候影响 AI Coding 成败的绝对不是裸模型，而是裸模型加上 Harness 的能力。 这个判断本身不算新鲜。 但我最受触动的是字节对 Harness 的理解。 他们的反思是，整个行业好像还是把 Harness 等同于 Agent 框架，诸如用 single agent 还是 multi agent，包含哪些角色，角色之间怎么配合。 这些当然重要，但字节在实践中发现，真正决定 AI Coding 能不能落地的，反而是更基础、更工程化的东西。 洪定坤把它叫做基建。 比如上下文工程有没有做好，架构的约束够不够清晰，团队的知识能不能有效沉淀下来，过去的技术债有没有梳理清楚。 这些看起来不那么性感的工作，反而直接影响 AI Coding 的效果。 实验数据也验证了这一点。同样的模型和框架组合，把这些基建结合进去之后，功能正确率直接从 80% 提升到了接近 90%，工程质量得分，也从之前 40 到 60 分的不及格水平，普遍提升到了 80 分左右。 基建做不好的话，可能的后果是，Vibe Coding 感觉快了，但实际整体可能更慢。工程的债，迟早得还。 反思三：代码门槛下降之后，团队怎么协同 洪定坤分享里有一个例子让我印象很深刻。 产品经理有个需求，发现还得等研发排期，就说那我自己来吧，用 AI 三下五除二就把功能给实现了。 确实这个功能不复杂。做完之后产品经理把代码给到研发，说我已经把代码写完了，现在你只需要帮忙把功能上线就行。 研发一看，不行。你这代码能跑，但不符合上线的规范，有权限问题、安全问题。 产品经理就很委屈，你们没时间做这个需求，现在我都做完了又不让上线。可研发看到的其实是代码质量的问题。 所以这里面就有一个需要所有人正视的事情，虽然代码的生成门槛虽然下降了，这并不代表系统的复杂度也下降了。 真实的业务系统里，代码要放到已有的架构里，要跟已有的模块配合，还要考虑各种各样的问题。 绝对不是谁写出来就能直接上线的。不然肯定会出问题。 怎么让不同角色的人用同一套工具和规范做出符合要求的代码，这是接下来大家需要去解决的。 字节的思路是在内部尝试工具化。比如把内部实践直接产品化，沉淀到 TRAE 里面，开放给所有人。 其实说白了就是工具化。 我看朋友圈有好多大佬也都在转这篇文章，应该还是有挺多共鸣的。 我感觉这一次分享多少也是一些拨乱反正吧。因为过去一段时间确实有很多听起来很离谱的言论，有些人会疯狂地炫耀自己使用了多少 Token，会认为这就代表着 AI Native...... 强烈推荐大家看看原文。字节跳动的公众号就有。

Notion 创始人这期分享确实很精彩。 大家千万别错过 Notion CEO Ivan Zhao 在红杉聊的这期播客，观点特别有见地。 甚至我觉得，这是近半年来所有创业者都应该认真精读的一期内容。 相当解惑。Ivan 把 AI 时代里一个组织正在发生的变化，用一种特别形象的方式串了起来。 1、Ivan 提到一个非常有意思的概念，叫 Jazz Mode。传统公司像 marching band（行进乐队），队形整齐，节奏固定，指挥说什么大家做什么。 Notion 想做的是 jazz band，有基本结构，但更强调即兴、互相接住、每个人都能主动发挥。 Ivan 觉得 AI 时代变化太快，太像 marching band 的组织会跟不上，所以 Notion 这几年在刻意招那种高主动性、高好奇心、能自己找路的人。 2、公司并不存在完美的扁平结构，人和人之间的层级关系始终存在，在这一点上他选择承认现实。 真正能设计的是一起工作的方式，把公司组织得更像一支可以即兴合奏的爵士乐队，而不是一支只会整齐队列表演的军乐队。 3、但爵士模式的前提是主旋律要清楚，相当于愿景、产品方向和少数几条铁律，类似底层和声结构。 团队在这个主旋律之上拥有较大的即兴空间，可以根据用户反馈和技术变化自己处理段落，而不是在每一个决策点都往上递审批。 4、Notion 现在大约有六十个曾经做过创始人的员工，这是他刻意营造的人才结构。 他更愿意招对 0 到 1 负过全责的人，这类人习惯自己发现问题、搭框架、推进落地，也更愿意在模糊地带主动出手。 公司需要的是能自己写歌、也能听懂别人演奏的人，而不是只会照谱子执行任务的演奏员。 5、在工程组织上，他把 Notion 重构成一个杠铃结构。 一端是非常 junior 的工程师，刚毕业或者职业早期；另一端是少数非常 senior 的架构师和技术带头人。 中间那类常规中高级工程师反而被刻意压缩，整个分布像一根两头重、中间瘦的杠铃。 6、杠铃结构背后的逻辑很简单。年轻工程师可塑性强，不会被旧时代的大规模工程实践和工具链束缚思路，在大模型快速变化的环境里能更容易接受全新的开发范式。 资深架构师负责定义系统级的分工和抽象，比如哪些部分交给模型，哪些部分坚持规则，如何组织数据和服务，确保整个产品作为一个系统是连贯的，而不是东一块西一块的功能拼盘。 7、当一个工程团队里大多数人都停在经验不浅、但也谈不上顶尖的这个档位时，整个组织很容易陷入一种温水状态：事情都有人做，但缺少敢颠覆旧方案的人，也少了愿意疯狂尝试新东西的人。 年轻人缺少全局视角，只能局部优化，老一辈如果人数太少，声音又容易被流程淹没，这种结构在 AI 时代会变得非常迟钝。 8、他用一个很有画面感的比喻来解释大模型产品开发。传统软件工程更像修桥，强调确定性的结构分析和数学推演，只要按照规范搭建，结果会高度可预测。 基于大语言模型做产品更接近酿啤酒，需要在原有配方和工艺上不断试验，调整温度、时间和原料比例，最后的标准来自人的口感而不是单一技术指标，用户体验是第一参照系。 9、他把 Notion 的 AI 能力视作对产品的再创作，而不是简单给旧界面贴一个智能按钮。 在拿到 GPT4 的早期访问时，他的直觉是，工具本身的工作方式需要重想，如果从公司一开始就可以假设存在这样的模型，那么 Notion 的交互结构、功能边界和价值主张应该是完全不一样的一套设计，这需要以重启思维来对待，而不是做一个插件。 10、他的职业生涯里出现过两次真正意义上的重启。 第一次发生在公司最困难的时候，团队被压缩到只剩几个核心成员，几个人躲在京都的小公寓里，用近乎白纸的心态重新问自己。 Notion 还要不要继续存在，如果要继续，哪些东西必须放弃，哪些能力哪怕再难也要保留。这一轮更偏向拿掉包袱、守住本质。 11、第二次重启发生在他拿到 GPT4 早期权限之后。 当模型能力跃迁时，他意识到自己这家公司可能会失去原本的位置，也可能借此进化成下一代生产力工具，关键在于有没有勇气承认旧的产品假设正在过期。 这一次的重启更偏向向前跳，是把 Notion 推向 AI 原生路线的转折点，从「文档+数据库」升级成「有理解能力的工作空间」的起点。 12、关于什么时候该重启，他给的判断标准非常实际。 并不是等到财务报表撑不住，更多是看组织与时代之间的错位：技术和市场环境已经明显往前走了，内部流程、产品形态和人才结构还停在旧逻辑里。 同时创始人对当下这家公司明显提不起兴趣，每天更像在维护一台运转正常但没有灵魂的机器，这种状态持续存在，基本就到了需要重启的阶段。 13、他谈创始人角色时，把重心放在创始人能量上。 创始人在公司里最关键的价值不只是最后拍板，更是持续发射出一套稳定的频率，这套频率包括对产品审美的标准，对什么算好体验的直觉，对哪些细节不能妥协的执念，以及面对不确定性时愿不愿意亲自下场试。 只要这股能量还在线，团队就知道自己在跟随一位有风格的乐手，不是在为一个抽象的 KPI 系统打工。 14、在人才选拔上，他逐步弱化简历本身的重要性。 Notion 的第一轮面试已经不再以简历为核心材料，更关注候选人在开放问题前的思考方式，对产品的直觉，对工具和工作方式的理解。 名校和大厂的履历在他眼里容易变成噪音，他更在意一个人能不能提出自己的看法，能不能在真实的情境下把事情推进，而不仅是在纸面上合格。 15、在销售文化上，他没有把销售放在产品的对立面。 他希望 Notion 的销售像懂音乐的乐手，先听清楚客户现在那首歌的节奏，再思考 Notion 这件乐器应该在什么位置加入，是主旋律，是伴奏，还是间奏，而不是一上来就把音量拉到最大只追逐签约数字。 真正重要的是建立长期合作关系，帮助对方把 Notion 用深、用广，而不是满足一次性收入目标。 16、他反复把组织、产品和 AI 放在同一个坐标系里思考。 组织设计要适配新的技术范式，人才结构要为试错和即兴留出空间，产品要在模型能力和用户体验之间找到新的平衡点，销售和商业化则负责把这套东西带到更大的市场里。 整套思路的底层前提很简单：这家公司永远是一支在不断改编曲目的爵士乐队，而不是一台固定工序的流水线。

强烈推荐大家看看DeepMind CEO Demis的最新判断。 真的，Google DeepMind 的 CEO Demis Hassabis 每一期访谈我觉得值得都花时间看看。这哥们讲东西很实在，而且通俗易懂。 早上边跑步边听完了他和 YC CEO Garry Tan 的最新一期播客。 刚刚把笔记写完，也给大家分享下。 多说一句，好多人问我这种笔记是不是 AI 写的。我说下自己的流程。 我会先完整听完播客，然后用语音输入法把感触尽量充分地讲出来，再让 AI 帮着整理初稿，最后自己逐字修改优化。 如果全部交给 AI 做总结，那等于把思考和理解的能力让渡给了 AI，对自己理解这件事其实没有任何价值。 OK，咱们进正题。 1 Demis 的态度非常明确，现在的大模型范式（大规模预训练 + RLHF + CoT）一定会是 AGI 最终架构的一部分，他不认为这会是条死路。 但要实现 AGI，还有几个关键问题要解决。这几个问题包括：持续学习、长程推理和记忆系统。 先从最容易看到的现象讲起，Context Window。 现在大模型处理长信息，最常用的招就是把 Context Window 一直撑大。一开始 8k，后来 32k，再后来 100 万 Token。听起来很厉害，但本质上是暴力堆砌。 Context Window 其实就相当于人脑里的 Working Memory，工作记忆。人的工作记忆能同时装多少东西？心理学里有个经典数字，7 个左右。背电话号码能记住 7 位上下，再多就溢出了。 大模型呢？已经做到 100 万 Token。 按理说，模型的工作记忆比人大几十万倍，应该比人聪明几十万倍才对。但显然不是。 问题也恰恰就出现在这。把所有东西都塞进 Context Window 里，里面包含了不重要的东西、错的东西、过时的东西。看起来信息很多，其实是一团乱麻。 那人为什么 7 个数字的工作记忆就够用？ 因为人脑背后还有另一套机制在工作。我们记得几年前的事，记得童年的事，记得几小时前发生的事。这些都不塞在工作记忆里，而是另一套系统。 具体来说这套系统是海马体，大脑里负责把新知识整合进已有知识库的那个部分。 研究发现，人睡觉的时候，特别是 REM 睡眠阶段，大脑会重放白天重要的片段，让大脑从中学习。新东西在睡觉的过程里，温柔地融进了旧的知识体系。 这个把新东西融进旧知识库的过程，就是持续学习。 模型现在没有这套机制。每一次对话结束，刚学到的东西就会忘记。下次重新打开，还是上次那个模型，没长进。 2 再聊聊长程推理的问题。英文表达是 Long-term Reasoning。我翻译为了长程。 长程推理这个词太抽象了。Demis 讲了一个特别具体的故事，听完会立刻明白他说的是什么。 他说自己喜欢跟 Gemini 下国际象棋。下棋的过程里能看到模型的 thinking trace，也就是它在那里到底想了什么。 然后他发现一件怪事。 模型考虑一步棋的时候，思考链里清清楚楚写着，这步是个昏招。但接下来，它没找到更好的走法，于是又走回这步昏招。 明明知道是错的，还是把错的那一步走出去了。 这个细节比任何 benchmark 数据都说明问题。因为它暴露的是模型缺少对自己思考过程的某种内省能力。 正常人下棋，意识到一步是昏招之后，脑子里会有一个反应，停一下，再想想。停一下、再想想这个能力，模型现在没有。它能在每一步局部判断对错，但没法基于整盘棋的局势去调整整体策略。 这就是长程推理还没搞定的样子。模型可以一步一步往前走，每一步看起来都合理，但走到后面整盘棋的方向其实是错的。它没有那种退回到当前思考的上一层、重新审视一下的能力。 说到底，模型缺的是一种内省。 3 学习、长程推理、记忆，这是 Demis 在播客里点出来的三个 AGI 鸿沟。 除此之外，他还反复提到了创造力。 2016 年 AlphaGo 跟李世石下棋，第二局走出了著名的 Move 37。那一步棋走出来的瞬间，全世界的围棋高手都看呆了。 所有人类几千年下围棋积累的经验都告诉它不该下那里，但 AlphaGo 下了。下完之后大家发现，是一步神来之笔。 很多人觉得，这就是 AI 的创造力来了。 但 Demis 说，对他自己来说，Move 37 只是起点。他真正想看到的是另一件事。AI 能不能发明围棋这件事本身。 这两件事的区别非常关键。 Move 37 是在围棋这个现成的规则里，找到了一步人类没想到的招。但围棋的规则、棋盘的形状、黑白子的对弈方式，是人类发明出来的。AI 在已有的框架里非常厉害，但能不能自己造一个框架，是另外一回事。 Demis 给了一个具体的设想。 如果给 AI 一个高层次的描述。造一个游戏，五分钟能学会规则，要好几辈子才能精通，棋局有审美，一下午能下完一局。AI 能不能根据这个描述，自己倒推出围棋？ 目前做不到。 为了把这件事讲得更清楚，Demis 还提了一个测试，他自己叫爱因斯坦测试。 用 1901 年人类已有的全部知识训练一个模型，看它能不能在 1905 年那个时间点，自己推出狭义相对论。 爱因斯坦在 1905 年那一年里，连写了几篇改变物理学的论文，后来叫爱因斯坦奇迹年。那些工作不是从已有的物理学论文里通过拼接得到的，是基于已有材料做了一次全新的概念跳跃。 爱因斯坦测试想问的就是这件事。AI 能不能做这种跳跃。 目前的大模型主要在做两件事，pattern matching 和 extrapolation。一个是从大量数据里找规律，一个是把规律往外延伸一点。但发现新东西需要的是类比推理的能力。从一个领域里抽出深层结构，搬到另一个全新的领域去用。 这个能力，模型现在还没有。也可能是有，但用法不对所以激发不出来。 4 除此之外，Demis 还分享了一个让我特别出乎意料的判断，他说未来 6 到 12 个月，真正的价值不在更大的模型，在更小的模型。 这一部分内容我反复听了好几次，确实突破我的已有认知。 不知道大家的想法，反正我自己，这一年来并没有怎么关注小模型的进展。毕竟行业的焦点就是把模型做大嘛。 那小模型的价值到底在哪？ 最直接的是成本。同样一个任务，小模型的推理价格可能只是前沿模型的十分之一甚至更少。 但 Demis 说，比成本更重要的其实是速度。 这里有一个前提得先说清楚。Demis 不是在说速度可以替代智能。 他的原话是，当小模型的能力已经达到前沿模型的 90% 到 95%，也就是已经相当不错的时候，剩下那 5% 到 10% 的能力差距，比不上速度带来的好处。 比如现在工程师用 AI 写代码，已经形成了一种新的工作节奏。一个想法冒出来，几秒之内就能看到结果，不行就改，再不行再改。 这个一改再改的循环跑得越快，做出来的东西就越好。如果每次调用都要等十秒，整个工作流就被打断了。 更关键的是，快到一定程度，工程师在这种节奏里能进入心流。一个想法、一次尝试、一个反馈、再来一个想法，思维不被打断。 这件事写过代码的人都懂，进入心流和频繁掉出心流，产出的差距是数量级的。 Agent 也是同样的逻辑。一个 Agent 跑完一个任务可能要调几十次模型，每次慢一秒，整个任务就慢一分钟。慢到一定程度，Agent 就从一个能用的东西变成鸡肋。 小模型不是大模型的廉价替代品。有些事只有小模型能做。 比如手机、眼镜、家用机器人，需要的就是一个能在本地跑起来的模型。本地跑除了反应快，还有一个特别重要的好处，隐私。 家里机器人看到的视频、听到的对话，全部在设备本地处理，根本不上云。这件事对很多用户来说不是加分项，是底线。 成本、速度、边缘部署，这是小模型的价值。 5 讲完小模型的价值，接下来一个更关键的问题是，能力被压到这么小的参数里，会不会有上限？ Demis 的判断是，目前没看到信息密度有任何理论上限。小模型的智能天花板还远没看到。 支撑这个判断的，是 DeepMind 在蒸馏这件事上的积累。蒸馏简单说就是先训练一个超大的模型，然后用这个超大模型去教一个小模型。教完之后，小模型用极少的参数，能复现原来 95% 以上的能力。 为什么 DeepMind 这么重视蒸馏？因为要把 AI 能力放进谷歌的头部产品中，前提是低延迟、低成本。前沿模型再强，每次推理花几秒钟、花几毛钱...这条路，恐怕很难走得通。 一个前沿模型发布之后，6 到 12 个月内，他们就能把这个模型的能力蒸馏到边缘设备能跑的小模型上去。这个时间表比很多人想的要快。 在很多场景中，小模型和大模型会相互配合。 举个例子，一个端到端的智能助手，绝大部分日常任务在本地的小模型上跑。智能眼镜看到的画面、家里机器人听到的对话、手机里的私人助理，模型直接在设备里读懂，不需要往云端传一遍。 只有遇到特别复杂、本地搞不定的问题，才向云端的前沿模型发起请求。 也就是说小模型在边缘做主力，前沿模型在云端做后援。 不过，这个构想对小模型的要求也比较高，它不能只会处理文字，还得能理解物理世界。 这就是为什么 Gemini 从一开始就坚持多模态，不光处理文字，也处理图像、视频、声音。 一开始这么做比只做文本要难得多，但眼镜也好，机器人也好，需要的是一个能看懂周围世界的模型，不是一个只会聊天的模型。 讲到这里，小模型这条路的轮廓就完全清楚了。它独立成立，不是前沿模型的廉价替代品，而是另一条同样重要的路。 嗯，很有启发。