整理 | 华卫

 

“世界上不会再出现第二个我这样的 CEO 了。”近日,英伟达联合创始人兼首席执行官黄仁勋(Jensen Huang)在一场私人访谈中这样说道。

 

据称,这场深度对话已经酝酿了三十年,将黄仁勋鲜为人知的一面展现在大众眼前。主持人 Jodi Shelton 与黄仁勋的职业交集始于三十余年前,彼时,图形处理器(GPU)尚未掀起席卷全球的 AI 革命。从加速计算的源头到生成式 AI 的前景,这场对话堪比一堂远见大师课。

 

在访谈中,黄仁勋表示,从某种意义上说,英伟达其实有 61 位 “CEO”。过去这些年,包括他在内,很多人都犯过严重的错误,但在英伟达,从来没有人因为犯错而被解雇。“我们打造了一个足够安全的环境。”他还透露,CEO 这个职位,远比人们想象的要脆弱得多。“实际上,我们可能是公司里最脆弱的一群人。不过对我来说,承认这种脆弱,并不是什么难事。”

 

有意思的是,他提到,在很多方面,自己都算是一个 “不情愿的 CEO”。“公开演讲简直让我怕得要死。比起待在公司外面抛头露面,我更喜欢扎根在公司内部;比起发表演讲,我更喜欢安静做事;我甚至一点都不喜欢做主题演讲,但为了公司,我必须去做这些事。”

 

此外,黄仁勋称,英伟达的成功,绝不是靠产量取胜。“虽然是英伟达发明了 GPU,但从产量来看,我们其实是全球最小的 GPU 制造商。很多不知名的厂商,GPU 产量都比我们高。”而“没有终极目标” 这一点,对英伟达的发展真的起到了至关重要的作用。

 

对于五年后的世界,黄仁勋断言,英伟达和整个行业在 AI 领域的投入,必将彻底改变计算机的运作模式,未来的计算机,将从 “由人类编程” 进化为 “在人类引导下自主学习编程”。并且,100% 的工作岗位都会发生变化,但不会有 50% 的岗位消失。未来的趋势不会是就业岗位减少,反而是大家会变得比现在更忙碌。并且,那些现在没有工作的人,很可能会因为 AI 获得谋生的手段。

 

网友们纷纷就此次访谈对黄仁勋评价道,“我从未见过他如此坦诚直率,真是不可思议。”

 

以下是详细对话内容,我们在不改变原意的基础上进行了翻译和删减,以飨读者。

“走了整整 33 年才看到成果”

Jodi Shelton:大众其实特别好奇像你这样的人,毕竟你们正在定义科技的未来,而科技的未来就是整个世界的未来。所以我们想做的,是挖掘你成功光环背后的个人经历以及支撑你走到今天的价值观。你对这个定位怎么看?

 

黄仁勋:说实话,不太喜欢。

 

Jodi Shelton:真的不喜欢吗?可你现在是名人啊,大家都想了解名人的故事。

 

黄仁勋:我从不觉得自己是名人,也根本不是什么名人。我只是恰好执掌着一家举足轻重的企业,是这家堪称史上最成功的科技公司之一的 CEO。很早以前,我们就做了一些正确的决策。回溯到 1993 年,我们就立志要重塑计算行业,而且对于计算机的架构,我们有着自己独到的见解。在很长一段时间里,这个观点都不被看好,甚至颇具争议。要知道,当时整个行业的焦点都在微处理器和 CPU 上。说起来,我和你就是在那个时期认识的。我们早在 1993 年底或者 1994 年就相识了,对吧?从那时起,英伟达就在做我们现在依然在做的事:重塑计算。

 

Jodi Shelton:没错,我记得很清楚。那时候的硅谷,正处在 CPU 为王、摩尔定律大行其道、个人电脑革命如火如荼的年代。

 

黄仁勋:是啊。而且我们早期的客户,全都是 PC 芯片组领域的初创公司。这些企业可以说是半导体行业辉煌版图的奠基者,像 Cirrus Logic、S3 Graphics、Western Digital、Trident Microsystems,你还记得这些名字吗?

 

Jodi Shelton:当然记得。

 

黄仁勋:这些公司,称得上是英伟达的 “前辈”。而现在,我们依然在这条路上前行,致力于打造一种全新的计算模式。这条路,我们走了整整 33 年才看到成果。我只是恰好成为了这家公司的 CEO,仅此而已。

 

Jodi Shelton:可能对你来说,这一切是水到渠成,但对整个世界而言,英伟达的崛起堪称横空出世。大概从 2023 年 11 月起,整个世界的科技格局都因你们而改变。你是怎么看待这次转型的?

 

黄仁勋:要知道,想要创造未来,就必须在未来到来之前,先置身于未来之中。坦诚地说,从我们发明 CUDA 技术、推出相关产品的那一刻起,就已经踏上了通往未来的道路。英伟达最让我骄傲的一点是:我们不仅擅长技术发明,更擅长把技术转化为产品推向市场。世界上有太多的公司、科研人员和发明家,他们确实创造出了先进的技术,但最后往往只能感慨 “这个技术我早就做出来了”、“这个想法我早就有了”。每次听到这种话,我都觉得很惋惜。这些优秀的发明家,遗憾的是没能遇上同样优秀的产品创新者。

 

所谓产品创新者,就是能把一项技术发明转化为一款能推向市场的成熟产品的人。而这还不够,你还得为产品制定精准的市场策略,甚至需要亲手培育出一个全新的市场,让市场能够接纳你研发的产品和制定的策略。英伟达就是这样一家公司,我们具备技术发明、产品创新、策略制定、生态构建乃至市场培育的全链条能力,而且我们已经多次成功做到了这一点。所以对我来说,这种 “身处未来” 的状态,已经持续了很长时间。

 

Jodi Shelton:确实如此。

 

黄仁勋:很久以前,我们有一个战略,现在已经不怎么提了,叫 “CUDA 无处不在”。很多人都听过我当年四处推广 CUDA 的故事,跑遍各大高校、初创企业和成熟企业。有时候,台下听众加起来也就三个人,但我还是会掏出笔记本电脑,为他们演示 CUDA,告诉他们这项技术将如何改变世界。我走访了无数科研机构和实验室,参加了数不清的行业会议,推广 CUDA 的次数,估计比世界上任何人都多。长久以来,我一直沉浸在这样的 “未来图景” 里,讲的故事多了,甚至会产生一种 “未来已经到来” 的错觉。

 

Jodi Shelton:确实有这种感觉。

 

黄仁勋:所以现在看到这一切成为现实,我依然满心欢喜。而且在我看来,这一切其实并不意外,因为支撑英伟达发展的是计算机科学领域最根本的底层逻辑,不是靠一时的直觉,也不是凭主观的喜好。从很多方面来说,如今的成果是一种必然。但我想说的是,当你把一件事物的速度提升一千倍,或者规模扩大一千倍、体积缩小一千倍时,无论这件事物原本是什么,都会发生质的飞跃。而这种质变最终带来的结果,往往是超乎想象的。

 

我们早就预见到深度学习技术有着巨大的扩展潜力,这也是我们举全公司之力押注这一领域的原因。我们知道,AlexNet(深度卷积神经网络)绝不会是深度学习的终点,这种技术架构天生具备极强的可扩展性,再加上全球海量的数据资源,深度学习的爆发是水到渠成的事。不过我当时也清楚,有一项技术会成为我们前进路上的障碍,那就是无监督学习,或者说自监督学习,也就是让计算机摆脱人工标注数据的束缚,实现自主学习。因为人工标注数据的效率,迟早会成为技术发展的瓶颈。而当无监督学习技术取得突破的那一刻,我就知道,我们的时代来了。

 

就在不久前的投资者路演上,还有人跟我说,我当时就明确跟他们提过这场 “质变”。如果你去回看当时的财报电话会议,就会发现每当谈到对世界至关重要的技术话题时,我都会把这一点讲得非常透彻。在每一场投资者路演,在每一个我演讲的场合,我都会强调这个观点。如今,无监督学习技术确实取得了重大突破,深度学习的规模效应也彻底释放出来,我们才算真正驶入了发展的快车道。但即便如此,这项技术如今能解决的问题,依然让我感到惊喜。我们早就预料到技术会发生质变、计算平台会迎来变革,但我们没想到,变革的成果如此丰硕。

 

我们现在能够解读蛋白质的 “语言”、细胞的 “语言”、量子的 “语言”,能够读懂世间万物的各种表征形式。过去我们用来描述信息的方式,如今正在被彻底重塑。从几何图形、纹理材质到如今的 3D 高斯和 3D 点云,信息的呈现形式日新月异。这种感觉就好像人类突然变得无比聪慧,连英语这种语言体系都随之改变了。我们不再沿用过去的词汇、语法和句式,因为我们的智慧已经进化到了一个全新维度,能够用一种全新的方式进行交流。或许未来人类的交流方式会变成简单的 “嘀嘀嗒嗒” 的信号声。这让我想起了电影《降临》里的场景,人类突然开始用抽象的图形进行沟通,仅仅通过图形就能传递海量的信息,实现更深层次、更高效率的交流。

 

最不可思议的是,我们现在解决的很多问题在过去是完全无法想象的,而且解决问题的速度也远超以往。过去我们常说摩尔定律,而现在英伟达的发展速度完全可以用 “英伟达定律” 来形容,比过去快了整整一千倍。未来十年必将是波澜壮阔的十年,光是想想就让人无比兴奋。

 

Jodi Shelton:要做到你所做的这些事,要能够预见未来,并且坚信未来一定会到来,需要何等强大的自信啊。就像你之前说的,我们 1994 年就认识了,这么多年来,你一直都是这个样子。

 

黄仁勋:是啊,我记得很清楚。

 

Jodi Shelton:那时候我才二十几岁。你应该比我大一点吧?

 

黄仁勋:当时我差不多 29 岁,快 30 岁了。

英伟达有 61 位“CEO”,从没有人因犯错而被解雇

Jodi Shelton:我还记得我们第一次见面的场景,当时我是为了给杂志写稿采访你。我问你:“黄仁勋,硅谷人才流动频繁,很多人来了又走,你会担心这个问题吗?” 毕竟当时很多 CEO 都在抱怨这件事。而那时你才 29 岁或 30 岁,你是这么回答我的:“英伟达既不是教堂,也不是监狱。想来的人可以来,想走的人也可以走。” 我当时听完特别震撼,心里想着:“这个人到底是谁啊?” 年纪轻轻,却有着如此的自信和智慧。我还听过一个类似的故事,张忠谋( Morris Chang)第一次见到你的时候,你当场就说:“我会成为你最大的客户,至少也是最大的客户之一。” 他当时的反应是:“哇,这小伙子可真有魄力。” 所以我很好奇,你这么年轻的时候,这份自信是从哪里来的?

 

黄仁勋:哈哈,你要知道,什么都懂其实也挺痛苦的,我开玩笑的。对了,张忠谋要是知道英伟达现在是台积电最大的客户,一定会很开心的。

 

Jodi Shelton:那是肯定的,他肯定会为你感到骄傲。

 

黄仁勋:我也为他感到骄傲。要知道,在个人电脑革命时期,英伟达就曾是台积电最大的客户。如今,我们再次成为了他们最大的客户,对此我感到非常欣慰。言归正传,我觉得一个人必须坚信自己所相信的东西。而且这份信念,不能建立在道听途说之上,不能因为别人说了什么,你就去相信什么。你必须认真思考,梳理出自己相信这件事的逻辑,并且把这些逻辑拆解成可靠的底层原则。之后,你还需要定期检验这些原则,确保你所秉持的信念、所付诸的行动,都是建立在坚实的基础之上的。

 

如果这个基础不够稳固,或者因为某些原因发生了变化,那就说明它可能并非真正的底层原则 ,也许它并没有锚定在物理规律或客观事实之上。一旦出现这种情况,你就要重新评估,然后及时调整方向。我一直都是这样做的。而且,如果你真心相信一件事,就应该付诸行动去实现它。我从 1993 年起就坚信我们正在做的事情,直到今天,这份信念依然没有改变。正因为坚信不疑,所以我才会不断地推演,不断地在脑海里进行逻辑梳理。我会持续复盘过去的决策,也会不断预判未来的趋势。

 

就像昨天我们开了那么多场会议,每场会议上,我都会重新梳理我们一路走来的逻辑。你会发现,过去的那些假设,有些是正确的,但也有些是错误的。正是因为我们足够灵活,能够根据实际情况及时调整方向,才最终走到了今天。所以,时常回头复盘、重新推演过往的决策,是一件很有意义的事,它能帮你更好地锻炼向前推演的能力。正因为我一直坚持这样做,所以我始终活在自己认定的真相里。直到现在,我依然觉得自己只是英伟达的一名员工。我非常在乎这家公司,但公司里有很多人都和我一样,对这家公司倾注了深厚的感情。

 

在一家治理完善的公司里,CEO 的角色定位是很明确的。CEO 需要向董事会汇报工作,而董事会则要对股东负责。如果 CEO 的工作表现没有达到董事会的预期,不管董事会有 12 位、13 位还是 15 位成员,他就会被解雇。所以说,CEO 其实也是公司这个组织里的一名员工。这就是为什么我说,英伟达既不是教堂,不是想来就能来;也不是监狱,不是想走都走不了。这种心态能让你始终保持脚踏实地,保持谦逊,保持锐意进取的状态,因为你必须每天都努力,才能对得起自己的这份工作。

 

有时候会有人问我:“黄仁勋,你热爱自己的工作吗?” 我会告诉他们,我并非每天都热爱这份工作,但我每天都会全力以赴去做好它。我觉得,这种态度源于两个方面:第一,我坚信自己是这份工作的最佳人选;第二,我必须每天都努力,才能配得上 “最佳人选” 这个身份。

 

Jodi Shelton:在大家眼里,你就是英伟达的代名词,英伟达就是你。这么多年下来,你已经和这家公司深度绑定了。

 

黄仁勋:我应该是英伟达内部被拍照最多的人吧。

 

Jodi Shelton:没错。不过,要是将来换了新的 CEO,这个人真的能接好你的班吗?

 

黄仁勋:世界上不会再出现第二个我这样的 CEO 了。原因很简单,我是被这家公司一步步培养起来的。刚创立英伟达的时候,我对怎么当 CEO、怎么做战略规划、怎么打造产品、怎么开创一个全新的行业,一窍不通。我只知道怎么融资,却不懂怎么和股东沟通,不了解股东、政策制定者、各国领导人以及企业管理者的想法,也不知道该如何把握员工的心态、如何打造企业文化,甚至连 “企业文化” 这个词到底意味着什么,我都无法准确界定,让我制定公司战略那更是天方夜谭。这就是我第一天接手工作时的真实状态。而在过去的 33 年里,我在这些领域都一步步做到了得心应手。

 

如果说这个世界上有谁能称得上是 “企业战略宗师” 或者 “行业开创者”,那这个人大概就是我这样一个小个子。我把自己的整个职业生涯都投入到学习这些能力上,而且我本身就是个好学生。除此之外,我对这份工作的投入程度和深厚感情,是很难通过招聘来复制的。在我心里,英伟达就像我的孩子一样,我对它倾注了全部的心血。我的家人也陪着我一起,为这家公司的成长付出努力。这种对公司的特殊情感,是很难被替代的。毕竟 33 年来,我见证了英伟达的每一次成功、每一次失败、每一次挫折,亲历了它做过的所有明智决策,也目睹了它犯下的各种错误。这种对公司的深刻理解和情感联结,不是随便招一个能力出众的人就能替代的。

 

不过从另一方面来说,英伟达的管理团队架构其实早就做好了准备。我现在有将近 60 位直接下属,他们中的每一个人,放到其他公司都能胜任世界级 CEO 的职位。我总是当着他们的面推演各种决策逻辑,我的每一个决定,都是在他们的注视下做出的,我会把背后的思考过程原原本本地讲给他们听。公司的每一次成功、每一次挫折、每一个挑战、每一场困境,我都会和他们一起复盘。所以从某种意义上说,英伟达其实有 61 位 “CEO”。他们每个人都对这家公司饱含深情,很多人已经在这里奋斗了 33 年。我认为,英伟达的成长模式是独一无二的,这也造就了它无可比拟的韧性。

 

Jodi Shelton:显然,你搭建的这套管理架构在行业内已经成了一段传奇,所有人都在谈论你这近 60 位直接下属。要让这样的架构顺畅运转,这些人肯定都得是万里挑一的顶尖人才。

 

黄仁勋:没错。

 

Jodi Shelton:他们不光要头脑聪明,毕竟硅谷从来不缺聪明人,更得是适配英伟达的顶尖人才。

 

黄仁勋:确实如此。

 

Jodi Shelton:那你能不能跟我说说,你是怎么筛选和培养这些人才的?另外,我记得你有个原则,找不到合适的人,就宁可让职位空着。我想到了 Colette Kress 的例子,你当时面试了 22 位首席财务官候选人,最终才选定了她。现在她在华尔街已经是一位传奇人物了。你当初是怎么选中她的?你选拔这类核心人才的标准是什么?

 

黄仁勋:在我看来,宁让职位空着,也不能让不合适的人占着位置,所以我从来不会急于招人。就算 CEO 的位置暂时空缺,或者某个副总裁职位没人接任,公司的运转也不会停滞。只要你坚信这一点,坚信 “空位胜于错配”,你就有足够的时间去寻找那个真正合适的人。这个合适的人选,需要满足很多条件,其中很重要的一点,就是你得发自内心地欣赏他、认可他。

 

我记得 Colette Kress 入职第一周的时候,就问过我:“黄仁勋,你希望我在首席财务官这个岗位上干多久?” 我告诉她:“只要我们还活着,只要死亡不将我们分开,你就一直干下去。” 因为任何其他答案都是没有意义的。这份工作没有所谓的 “截止日期”,唯一的终点,就是当她觉得英伟达不再适合自己的时候。这个原则不仅适用于 Colette,也适用于我那 60 位直接下属。我愿意为了等待合适的人,让职位空很久。而在这个过程中,公司依然会稳步向前。无论这个空缺的职位对应着什么使命、什么工作,大家都会主动顶上。退一步说,就算没人接手,我也会尽全力扛起这份责任,保证公司正常运转。

 

这就是我的用人哲学,永远不要让不合适的人占据岗位,耐心等待那个对的人出现。经常有人问我,什么样的员工才算优秀员工,什么样的管理者才算卓越管理者。说来奇怪,我其实没有标准答案。因为能走到我面前的人,都足够聪明、足够能干。你随便找一个首席财务官,我敢保证他绝对胜任本职工作。其他岗位的候选人也是如此。在我看来,英伟达之所以能创造奇迹,关键不在于单个人的能力有多强,而在于团队成员之间的 “化学反应”。更重要的是,这源于我们的企业品格。这种品格,才是一家伟大公司的核心竞争力。市面上有很多公司都在做芯片,虽然是英伟达发明了 GPU,但从产量来看,我们其实是全球最小的 GPU 制造商。

 

这话听起来可能有点不可思议,但事实就是如此,很多不知名的厂商,GPU 产量都比我们高。很明显,英伟达的成功,绝不是靠产量取胜。我认为,真正的秘诀在于我们独特的企业文化和企业品格、团队在逆境中凝聚在一起的力量。在外人看来,我们似乎总是一帆风顺,但其实研发 Grace Blackwell 芯片的过程,差点拖垮了整个公司。但我们硬是咬牙扛了过来。这个项目的复杂度和规模都是前所未有的,外界对我们的期望也高得离谱。我们最终不仅达标,甚至超出了所有人的预期,而支撑我们做到这一点的,100% 是企业品格。这不是靠智商,也不是靠勤奋就能实现的,毕竟这个世界上,聪明又努力的人太多了。

 

这种企业品格,是没法通过面试来筛选的。但我始终相信一件事:几乎任何人进入英伟达之后,都会被这种品格所感染、所塑造。这就是我们公司最神奇的地方:我们能够承受挫折,能够直面各种艰巨的挑战,并且一次次从困境中突围。很少有公司的团队能做到这一点。通常来说,当公司遭遇重大挑战后,总会有人因为心存不满离开,或者因为被当成 “背锅侠” 而被解雇。在团队合作中,出了问题总要有人承担责任,这是毋庸置疑的,就像一场球赛输了,我们必须清楚是谁失误丢了球。

 

在英伟达,我们打造了一个足够安全的环境。过去这些年,包括我在内,很多人都犯过严重的错误,这些失误大家都看在眼里,但从来没有人因为犯错而被解雇。久而久之,英伟达就形成了自己独有的文化和特质。这种文化的核心,就是包容、宽恕,以及从错误中学习。对我来说,有两件事至关重要:只要团队里的每一个人,都为了共同的目标拼尽了全力,这就足够了。

敢叫板 20 岁新锐的黄仁勋,也有至暗时刻?

Jodi Shelton:刚才聊到 “痛苦与磨砺” 的理念,你可以再深入谈谈吗?我最近听 Andy Karp 在播客里说,“人生的二十几岁,要么用来享乐,要么用来打拼事业”。你认同这个观点吗?当然,不是每个人都能成为帕兰提尔或者英伟达的 CEO,但对年轻人来说,想要在事业上有所成就,到底需要付出什么?你想给年轻人传递怎样的职业与成功之道?

 

黄仁勋:Andy 很睿智,总能说出一些深刻的人生哲理。不过我对这类说法,倒没那么执念。我一直很佩服张忠谋先生,他一直工作到 80 多岁,思维依然敏锐得像一把刀。如果要在维基百科里查 “大器晚成” 这个词,配图说不定就是他。能在人生最具创造力的阶段,持续奋斗 50 年,这难道不是一件幸事吗?我自己也倾向于这种人生轨迹。对我而言,投身于有价值的事业,远比用后 20 年的时间环游世界更有意义,当然,环游世界本身也没什么不好,只是我现在就已经在满世界奔波了。

 

不得不承认,二十几岁的我,确实更聪明、专注力更强、思维速度也更快。但那个年纪的人,往往缺少一样至关重要的东西,阅历沉淀出的智慧、处理复杂问题的分寸感、制定长远战略的眼光,以及长线思维的能力。这些能力,光靠读书是学不来的。现在的年轻人可以刷短视频,通过共情去感受别人的经历,算是一种间接的经验积累,这种模仿式学习确实有价值。但还有一样东西,是无法通过旁观习得的,那就是坚韧的意志,是直面痛苦与挫折时,懂得如何应对的底气;是熬过精神内耗、挺过煎熬时刻、战胜内心恐惧的勇气。

 

经营公司的过程中,恐惧是真实存在的。我们的决策,关乎数万人的生计。当公司发展不顺时,一个感受不到恐惧、焦虑和脆弱的领导者,反而是不合格的。如果对结果毫不在意,那未免也太冷漠了。而这些真切的感受和应对的能力,只有亲身经历过,才能真正掌握。所以我觉得,两种人生选择没有绝对的对错。年轻时打拼,确实精力充沛,可以熬夜加班,可以付出十倍的努力,更容易早早取得成功。但我现在身上拥有的东西,是三十岁时的我完全不具备的。

 

如今的我,思维速度虽然慢了,但依靠智慧和经验积累的思维模型,能更快地找到正确答案。就算和二十岁的年轻人同台竞争,我也有信心不输给他。他们未必能胜过现在的我。

 

Jodi Shelton:那我们来聊点更私人的话题吧。能不能说说你的童年?哪些高光或至暗的经历,对你如今的性格特质产生了直接影响?

 

黄仁勋:我从来不觉得自己是天赋异禀的人,智商也算不上出众。小时候入学需要参加考试,我当时的成绩确实很不错,那会儿的考试还是全国性的。我记得母亲总是逢人就说,我是个非常聪明的孩子。不管这话是不是真的,她反复的肯定,无形中给了我一种压力,我必须变得足够聪明。这件事让我意识到,无论是为人父母还是做管理,给身边的人或者整个公司设定一个超出常理的高目标,往往能激发他们的潜能,让他们迎难而上。当然,也有人会被这样的目标吓退,但对我而言,这种激励起到了积极的作用。这是我第一个想到的童年片段。

 

另一件事,是关于我母亲的。当年我们学习英语的时候,她其实根本不懂英文,而且我觉得她可能连高中都没毕业。但这丝毫没有妨碍她每天教我们学英语。你可能会觉得不可思议,一个完全不懂英语的人,怎么教孩子学英语?她的方法很简单:买一本韦伯斯特词典,照着单词的拼写规律,写下英文单词,再标注上中文释义,把纸对折做成单词卡,然后逼着我们背下来。我们的发音准不准确,她其实也无从判断。但这件事,让我学到了一个道理:一个人只要有足够坚定的意志,就算暂时不知道该怎么做,也不该停下脚步。很多事情,其实并没有想象中那么难。小时候的这段记忆,我一直记到现在。

 

还有一段经历,是我们搬到肯塔基州之后。我当时是学校里年纪最小的孩子,就读的奥尼塔浸会学院坐落在山顶。每天上学,我都得走下山坡,穿过一条河,再走过一片广阔的田野,才能到达那所小小的学校。那是 1973 年,我是整个镇上第一个出现的中国孩子。镇上的那些孩子都很野,每次我过吊桥的时候,他们都会找我的麻烦。那座吊桥的桥面是木板铺的,有些木板已经缺失了,桥下的河水很深。而那些孩子,就守在桥的另一头等我。那时候我才 9 岁。

 

Jodi Shelton:天哪,才 9 岁。眼前是一条河,一座破吊桥,桥对面还有等着找麻烦的孩子,这简直太糟糕了。

 

黄仁勋:是啊,但我每天都得走这条路去上学。这大概就是童年时期的 “痛苦与磨砺” 吧。每天早上都是这样。下午放学回家后,我还有任务:打扫卫生间。那时候家里的每个孩子都有分工,我哥哥当时 11 岁,他的活儿是去烟草农场干活,而我的工作就是打扫卫生间,每天都要做。

 

Jodi Shelton:你觉得当年那些找你麻烦的孩子,知道你现在的成就吗?

 

黄仁勋:奥尼塔浸会学院的校长最近还发邮件给我呢。他们每年都会给我寄圣诞礼物,知道我喜欢吃肯塔基风味的香肠肉汁配饼干。

 

Jodi Shelton:这个爱好是在肯塔基养成的吧?

 

黄仁勋:没错。我记得我 45 岁生日的时候,家人带我回了一趟母校。当年食堂里做饭的阿姨们居然还健在,特意回来给我做了一顿饭。

 

Jodi Shelton:天哪,这也太暖心了。

 

黄仁勋:真的特别感动。她们给我做了正宗的肯塔基香肠肉汁配饼干,味道还是小时候的样子。

 

Jodi Shelton:你的父母见证了你的成功吗?

 

黄仁勋:当然,他们现在身体还很好,特别为我骄傲。他们对我的事情了如指掌,我父亲会读所有和我相关的报道。要是看到有人说我的坏话,他还会生气。我总劝他别什么都看,不然天天都得生气,别理会那些负面新闻。

 

Jodi Shelton:挺有意思的。现在功成名就了,你会怀念那些还没这么受关注的日子吗?会想念那些平凡的小事吗?比如你很爱车,现在却没什么机会开车了吧?我记得你是我认识的人里,第一个也是唯一一个拥有柯尼赛格跑车的人。

 

黄仁勋:克里斯蒂安・冯・柯尼赛格真是个天才设计师,那辆车太棒了。启动的时候,引擎声和蝙蝠侠的座驾一模一样。而且启动它得按七个步骤,因为动力实在太强劲了,不能随便让别人碰。不过我现在已经没有那辆车了,也确实很少开车了。

 

Jodi Shelton:会想念开车的感觉吗?

 

黄仁勋:有一点吧。我现在还是会关注新车,比如新款的法拉利,每次看到都觉得很惊艳,这些车真的是工程学的杰作。

 

Jodi Shelton:确实很厉害。我去过法拉利的工厂,亲眼看到一辆车从工业器械一步步变成顶级消费品,现在甚至成了艺术品,这个过程太震撼了。

黄仁勋眼中五年后的世界

Jodi Shelton:如果五年后我们再坐在这里,你觉得到那时的世界会是什么样子?哪些变化会让我们最惊讶?

 

黄仁勋:如果我们回归底层逻辑,再结合现实的实用性和技术落地的规律来判断,有几件事是可以预见的。首先,英伟达和整个行业在 AI 领域的投入,必将彻底改变计算机的运作模式 ,未来的计算机,将从 “由人类编程” 进化为 “在人类引导下自主学习编程”。过去我们是手把手教计算机学日语,未来我们只需要告诉它 “去学日语” 就够了。未来的计算机,将能够处理比现在大十亿倍的问题规模。这个变化的影响之大,我们现在甚至无法完全想象,因为提出解决方案是一回事,而能否构想出需要解决的问题,就是另一回事了。很多问题之所以无法被解决,往往是因为我们连如何定义和描述它们都做不到。

 

未来,无论是数字生物学、物理科学、量子物理还是材料科学的复杂难题,都会变得容易攻克。就算是交通拥堵这种日常问题,也能得到极大改善。就拿智能电网来说,现在的电网存在大量能源浪费,AI 会精准计算出所需的能源量,实现按需分配,从根本上避免过度供应造成的损耗。AI 解决这些日常难题的能力,会让人惊叹不已。到那时,每一个科学领域都会被重塑,当下所有的难题都会被技术赋能、迎刃而解。工具的速度提升了,难题自然就显得 “渺小” 了。举个例子,如果飞机的速度能达到 10 马赫,整个世界就会变得 “小” 很多, 喷气式飞机的出现,其实已经让世界变小了。

 

英伟达制造的计算机也是如此,极致的运算速度让所有问题都变得更容易被解决。就像 OpenAI 的研究人员曾经说的:“为什么不把整个互联网的数据都喂给计算机呢?” 因为在算力爆发之后,全球互联网的数据量,突然就显得微不足道了。现在我们看互联网数据,也会觉得体量很小,原因就在这里。这种心态,未来会渗透到几乎所有的科学领域。过去人们会说 “这是个无解的难题”,未来大家只会觉得 “这事儿很简单”。五年后,每一位科学家、工程师、企业家和创新者,都会抱着这样的心态。曾经的难题变得简单,我们就能解决更多的问题。这是第一个必然结果。

 

第二个结果,就是企业的生产效率会实现质的飞跃。今天的难题变成明天的小事,供应链管理会变得无比顺畅,浪费现象基本消失;计算机的设计流程也会简化,我们可以尝试更多的方案。这并不是说我们会每年推出更多的产品,我们还是保持一年一款的节奏,但每一款产品都会经过更多次的迭代优化,最终呈现的成品会比现在好得多。这样一来,公司的效率会更高,利润会更丰厚,所有企业都会变得更赚钱,整个社会的财富也会随之增长。但还有一个值得深思的点:当所有我们能想到的问题都变得可以解决时,我们就会去探索更多新的问题。

 

所以,未来的趋势不会是就业岗位减少,反而是大家会变得比现在更忙碌。因为以前那些被认为 “不可能完成” 的任务,现在都摆上了台面;那些因为成本太高而无法开展的实验,现在都可以去尝试,AI 还会帮我们推进这些实验。只要我们有足够的想象力,所有搁置的难题,都会找到解决的路径。我可以做一个思想实验。现在我工作时,身边围绕着 60 位顶尖人才,而他们每个人又带着数千名精英。这些人在各自的领域里,能力都远超于我,对我来说,他们就像是 “领域内的人工超级智能”。但和他们合作,我完全没有障碍。现在我使用的 OpenAI、Gemini、Grok、Perplexity、Anthropic 这些 AI 工具,在很多方面也已经比我聪明了,但我每天都在和它们高效协作。

 

不过有一个很有意思的变化:以前我给团队布置一个问题,需要等两三天才能得到反馈和答案,这段时间里我可以思考下一步的计划 ,因为我的决策需要基于这些中间结果。但如果这些答案能在一秒钟内就反馈给我,会发生什么?我的工作节奏会变得无比紧凑,因为我会成为所有事情的关键节点。刚得到一个答案,立刻就要推导下一步,马上启动新的实验。你不觉得吗?现在信息技术的提速,已经让我们变得更忙碌了。信息、知识和答案的获取速度越来越快,我们作为决策节点,自然会比以往更忙。我觉得未来很多人都会有这种感受。

 

最后一点,对于那些没能赶上之前科技浪潮的人来说,AI 会填平技术鸿沟。我特别喜欢 “氛围编程” 这个概念,现在任何人都可以成为软件程序员,借助 AI 写出的代码,甚至比很多专业程序员的作品还要好。我很欣赏 Cursor 这家公司的成果,前几天还见到了 Lovable 的 CEO,他是个很厉害的人,他们的公司在瑞典。AI 会帮助那些在自己的领域很有天赋,但不懂如何用技术放大自身能力的人实现能力的跃迁。Lovable 的 CEO 就跟我说过,很多人用他们开发的软件创办了小公司,现在每年能赚 2300 万美元。这太不可思议了。这些人终于能融入全球经济体系,不再被技术门槛挡住去路,这一切都是 AI 的功劳。

 

五年后的世界,大家会拥有更有价值的工作,经济效率会大幅提升,GDP 有望实现增长,劳动力短缺的问题会得到缓解,通货膨胀也会回落。更多的科学领域会被开拓,更多的难题会被解决。当然,也有一些悲观的论调,认为 AI 会让一半的人失去工作。但我觉得,更可能发生的情况是:100% 的工作岗位都会发生变化,但不会有 50% 的岗位消失。而且,那些现在没有工作的人,很可能会因为 AI 获得谋生的手段。

 

当然,我们的技术会发生翻天覆地的变化,但这些技术层面的革新,反而不是最有意思的。五年后,计算机还是计算机,只是应用变得更智能了,本质上还是软件。我们依然会做电商,只是可能不用自己逛网站了,会有智能代理帮我们购物,但商品还是来自亚马逊这些平台。很多事情,其实都会保持原样。最后我还有一个小小的愿望或者说期待:希望我们在机器人和人形机器人领域的研究能结出硕果,希望未来每个人都能拥有属于自己的 R2-D2 和 C-3PO,它们可爱又贴心。就像在 GTC 大会上,我每次都会邀请迪士尼的机器人上台,那些机器人真的太萌了。

 

为什么不让每个人都拥有一个呢?我还希望迪士尼能把这些机器人做成周边商品,它们真的值得。我的宠物猫莫莫和库玛,也需要这样的 “宠物玩伴” 不是吗?我真心希望这个愿望能实现。现在有很多孤独的人,已经有不少人联系过我,希望能拥有可以在家陪伴自己的机器人,尤其是那些独居的老人。机器人能给他们带来陪伴和帮助,而且它们本身又那么可爱,这绝对是我们技术发展带来的意外之喜。

 

Jodi Shelton:如果以后有机器人帮我们做饭、打扫卫生,你还会像现在这样,饶有兴致地看着别人做饭吗?

 

黄仁勋:当然会。原因很简单,我现在完全有能力不用自己做饭,但我还是会选择下厨。我们完全可以雇很多佣人,但我们没有这么做。我和洛里一直都是两个人自己过日子。昨晚她做了墨西哥辣椒肉酱,味道棒极了,全程都是她一个人忙活的。以后我们大概率还会保持这样的生活。对我来说,最幸福的时刻,就是孩子们回家来,我们一起下厨做饭,喝喝小酒,这就是最完美的时光。

 

Jodi Shelton:一家人在厨房里忙活,这种亲密感真的太美好了。

 

黄仁勋:是啊,人生的幸福莫过于此。我们打拼奋斗,不就是为了这样的时刻吗?

“不爱演讲的黄仁勋”:CEO 是公司里最脆弱的一群人

Jodi Shelton:当一切尘埃落定,你希望后人如何记住你?

 

黄仁勋:首先,能被人记住,本身就是一件很幸运的事。我很庆幸,凭借英伟达的成就,凭借我们打造的事业,凭借我们在全球最重要的科技产业:人类最核心的工具 “计算机” 领域留下的印记,英伟达很可能会在我离开这个世界很久之后,依然对这个世界有着重要的意义。我很庆幸自己能和克里斯、柯蒂斯一起创立这家公司,很庆幸自己能一路学习成长,没有成为拖垮公司的那个短板,反而常常是推动公司走下去的一份力量。我们打造的这家企业,对整个世界都有着深远的影响,而不只是局限于某个行业或某个群体。

 

能做到这一点的人,在这个世界上并不多。我很庆幸自己作为创始人,能亲身参与并见证这一切,见证英伟达成长为如今的模样,见证它对全球各行各业产生实实在在的影响。公司里有很多已经工作了 33 年的老员工,他们的人生因为英伟达变得更加丰盈;现在甚至已经有第二代、第三代员工加入我们。我们在全球各地建立了自己的团队,我很荣幸能和这些员工并肩作战,分享他们一路走来的绝望与喜悦、希望与悲伤。这样的经历,并不是每个人都能拥有的。我为我们在中国的团队感到骄傲,为我们在印度的员工们由衷赞叹,也为欧洲、加拿大的团队感到欣慰。我们在加拿大的团队正在不断壮大。

 

我还希望有朝一日,英伟达能把业务拓展到南半球,让更多地区的人们,也能享受到我们今天所拥有的技术成果。昨天我还和人聊起我们在非洲开展的工作,聊到我们应该在拉美和东南亚投入更多精力。我真的为我们公司带来的这些影响感到自豪。所以,人们会怎么记住我?或许,他们会记得我是英伟达的创始人之一,是这家公司的缔造者之一。或许,还会记得我是个好人。

 

Jodi Shelton:这是毋庸置疑的。

 

黄仁勋:他们或许还会觉得,我是个风趣幽默的人,不喜欢端着架子。其实在很多方面,我都算是一个 “不情愿的 CEO”。比起待在公司外面抛头露面,我更喜欢扎根在公司内部;比起发表演讲,我更喜欢安静做事;我甚至一点都不喜欢做主题演讲,但为了公司,我必须去做这些事。我确实是个不太情愿的 CEO,但我绝对是个满腔热忱的英伟达建设者。只要是为了公司发展必须做的事,我都会全力以赴。说了这么多,其实我也不知道,人们最终会如何记住我。

 

Jodi Shelton:我觉得,看到好人获得成功,总是一件令人开心的事。这么多年来,看着你一路打拼,经历起起落落,最终收获成功,我真的由衷地为你高兴。你这一路走来,见过了形形色色的人。

 

黄仁勋:是啊,真的见过了太多人。我想提醒所有的 CEO,没有人能单枪匹马地成功。

 

Jodi Shelton:确实如此。

 

黄仁勋:我们虽然是 CEO,但这个位置总需要有人来坐。如果不是早年大家对我的提携与帮助,比如你一直不遗余力地宣传英伟达还有张忠谋奖带来的认可,这些都对我意义重大。张忠谋奖大概是我人生中获得的第一个真正有分量的奖项,直到今天,它对我来说依然意义非凡。这个奖项以他的名字命名,而且他还亲自参与了评选,这份认可真的让我铭记于心。还有那些和我们合作的企业,他们的慷慨相助,我也一直记在心里。

 

其实 CEO 这个角色,很多时候都需要寻求帮助。我已经记不清有多少次,我是这样开启一段对话的:“我需要你的帮助。” 很多时候,我是真的需要帮助,而且对方往往是唯一能帮到我的人。一路走来,很多人都慷慨地伸出援手,分享他们的知识,教我做事的方法,帮我解决棘手的难题。这或许才是 CEO 这个角色带给我的真正启示,这个职位远比人们想象的要脆弱得多。

 

Jodi Shelton:而且还是一个很孤独的职位,对吧?

 

黄仁勋:确实可能会感到孤独。但我想说,这种孤独更多是存在于我们的内心世界。当你试图解决一些棘手的难题时,往往需要长时间独自思考,自己跟自己对话。公司发展的每一次转型、每一次跨越,每一次我推动公司自我革新的时刻,我都不知道自己独自思考了多少个小时。在那些时刻,你会真切地感受到孤独。但我们也要明白,其实有很多人都希望我们能成功。就像你之前说的,你很乐意看到我成功,我知道你是真心希望我好,而我也同样希望你能越来越好。从这个角度来说,我们其实并不孤单。

 

所以说,CEO 这个职业,是一份充满脆弱感的工作。你无法单打独斗完成任何事,很多时候都需要依赖别人的帮助与善意。或许在外界看来,我们是强大的领导者,但实际上,我们可能是公司里最脆弱的一群人。我经常说,我是公司里唯一一个离开别人的帮助就寸步难行的人。我想,大多数 CEO 应该都是如此。这或许就是这份职业带给我们的感悟:CEO 们,远比他们愿意承认的要更加脆弱。不过对我来说,承认这种脆弱,并不是什么难事。

“没有终极目标” ,才成就了英伟达?

Jodi Shelton:接下来我们用快问快答收尾。你见过的最聪明的人是谁?

 

黄仁勋:这个问题我没法回答。我知道大家心里对 “聪明” 的定义,就是智商高、会解决问题、技术能力强。但在我看来,这种能力早已经成了一种 “通用品”。而且我们很快就能证明,AI 处理这类问题是最轻松的,不是吗?举个例子,以前大家都觉得软件编程是最考验智商的工作,结果呢?AI 最先攻克的领域之一就是编程。所以说,“聪明” 的定义,其实和大多数人想的完全不一样。

 

在我看来,从长远来讲,真正的 “聪明”,是那种兼具技术洞察力与人文同理心的能力,是能够洞察弦外之音、预判未知风险、看透表象背后本质的能力。那些能 “见人所未见” 的人,才是真正的聪明人,他们的价值是无可估量的。这种人能凭借数据、分析、底层逻辑、人生阅历、智慧经验,再加上对他人的感知,敏锐地捕捉到潜在的风险,在问题发生之前就提前规避。我觉得这才是 “聪明”,而且拥有这种能力的人,说不定在学术能力评估测试(SAT)里的分数惨不忍睹。

 

Jodi Shelton:外界对你有什么误解?

 

黄仁勋:这些问题都好犀利啊。首先,我都不知道外界对我有什么印象。

 

Jodi Shelton:比如,大家觉得你喜欢抛头露面,觉得你是个很棒的演讲者,所以肯定很享受做演讲的过程。但你之前已经说了,事实并非如此。

 

黄仁勋:对,完全相反。公开演讲简直让我怕得要死。不是说站在台上的那一刻害怕,而是现在,想到两周后在华盛顿举办的 GTC 大会,我就焦虑得不行。不,应该说,我已经焦虑一个月了。这种事总是让我心神不宁,脑子里时时刻刻都想着,压力特别大。公司内部的会议演讲也让我紧张到极致。因为台下坐的都是对我而言最重要的人,从某种程度上说,这是我做过的最重要的演讲。但这种演讲根本没法准备,我要讲的所有内容,其实都能在网上的某个视频里找到,他们完全可以自己去看。

 

我很讨厌把那些内容重复一遍讲给他们听,因为你绝不会回家对着家人做一场 GTC 主题演讲,对吧?我也不想那样做。演讲内容必须是真诚的、独一无二的、对听众有价值的、有意义的,能给他们带来改变。毕竟我还在领导这家公司,我希望通过演讲达成一定的目标。所以我必须拿出全新的内容,但不到演讲结束的那一刻,我永远不知道最终效果会怎么样。大家都觉得财报发布周我会很紧张,但说实话,我一点感觉都没有。真正让我紧张的,是公司的内部会议演讲。所以外界的这个印象,真的大错特错。

 

Jodi Shelton:你最受不了的事是什么?

 

黄仁勋:在关键时刻,有人不认真听我说话、不理解我的问题,还胡乱回答。尤其是在我们处理非常棘手、非常困难的问题时,我们需要的是事实,是真相。这个时候我提出问题,如果有人答非所问,我会立刻火冒三丈。我实在无法理解,为什么有人意识不到这场会议的重要性?我们正在为一件至关重要的事努力,我们需要尽快找到真相、解决问题。我到现在都想不通这一点,这种情况每次都会激怒我。谁要是想惹我生气,这招百试百灵。

 

Jodi Shelton:这下我们知道怎么让黄仁勋发火了。

 

Jodi Shelton:最后一个问题,是最近有人问我的,我特别喜欢这个问题。如果让你回到 20 岁,你是想回到自己当年的那个年代,还是活在当下的 20 岁?

 

黄仁勋:我会毫不犹豫地回到自己的那个年代。因为我觉得,我们那一代人的 20 岁,比现在年轻人的 20 岁更快乐。我总觉得,每个人都应该拥有一段 “懵懂无知” 的时光,不必从第一天起就背负着全世界的重担。我坚信这一点,没人能说服我。有时候,“无知” 也是一种快乐,甚至是一种超能力。如果当初我知道创立英伟达是一件 “不可能完成的任务”,那今天的英伟达根本就不会存在。事实就是,创立英伟达这件事,本来就是天方夜谭。但当时的我什么都不懂,所以没人能说服我放弃。

 

我觉得,乐观的人都这样,你永远没法说服他们 “这件事做不成”。他们就是这么 “无知”,对现实的艰难视而不见,所以才会充满乐观。这难道是坏事吗?现在的年轻人,过早地接触到了太多信息,变得越来越愤世嫉俗。他们并不是天生就这么消极,而是因为看到的东西太多太杂了。其实大可不必如此。人需要培养内心的乐观精神,需要在心里留存一份善意,学会只看到世界美好的一面。我们得锻炼这种能力。我们那一代人,有更多这样的机会。我们 20 岁的时候,就是这样的,乐观得像超人一样,觉得凡事皆有可能。所以,我肯定会选择回到自己的 20 岁。

 

Jodi Shelton:真是个完美的收尾。无知是福啊。

 

黄仁勋:没错,无知是福,无知也是一种超能力。任何一个想要开启新征程的人,如果不是因为这份 “无知”,他们一早就会因为觉得事情太难而放弃了。我真的很庆幸,自己当年虽然也算勤奋、也算有一些能力,但那份 “无知” 帮了我大忙。我那时候做任何事都抱着一种心态:“这能有多难?” 结果后来才发现,简直难到超乎想象。你根本没法想象。你看看我今天建立的这一切,如果当初我就知道前路会有这么多艰辛、这么多挫折、这么多失望,把这些困难全都摆在我面前,我绝对不会去做的,绝对不会。所以说,“无知” 真的是一种超能力。

 

还有一种超能力,就是“没有终极目标”。英伟达就没有什么终极目标。总有人问我:“黄仁勋,你的计划是什么?” 我们没有计划,“活下去” 就是我们的计划。我们对未来的世界有憧憬,我们会畅想技术会如何改变世界,但我们 100% 的计划,就是让公司一直运营下去。以前也有人问我,现在也经常有人问:“黄仁勋,你的人生目标是什么?” 我没有什么人生目标,就是想一直工作,一直有事可做,能和一群优秀的人一起做有意义的事。这就是我的目标。

 

所以说,从很多方面来讲,“没有终极目标” 这一点,对英伟达的发展真的起到了至关重要的作用。

 

参考链接:

https://www.youtube.com/watch?v=8FOdAc_i_tM

整理 | 华卫、Tina

过去一年,编码 Agent 的变化速度,已经快到让人很难用“功能升级”来形容。

如果把时间拨回到一年前,Agent 还主要停留在代码补全、对话式改几行代码的阶段;而今天,在 Cursor 内部,工程师已经开始同时运行多个 Agent 并行“甩活儿”,让它们在代码库中自主修改、调试、复盘,再由人类在最后阶段集中审核结果。开发者不再盯着 Agent 的每一步操作,而是开始习惯“等它跑完再看答案”。

在最近一次访谈中,Cursor 工程负责人 Jason Ginsberg 给出了一个明确判断:这不是渐进式优化,而是一场正在发生的“换代”。更重要的是,他把这场变化的时间窗口,压缩到了未来三到六个月——在他看来,Agent 将不只是“更聪明”,而是会真正接管更长周期、更复杂的工程任务,整个行业的工作方式也将随之重塑。

下面是详细对话内容,我们在不改变原意的基础上进行了翻译和删减,以飨读者。

一年多时间,编码 Agent“翻天覆地”

Harrison Chase:Jason,你能跟大家简单介绍一下自己吗?也给大家讲讲 Cursor 是什么吧。

 

Jason Ginsberg:好的。我目前在做一款 AI 编程工具,已经在 Cursor 工作了六个月,担任该产品的工程负责人。不过说实话,我日常的大部分时间还是在写代码和做设计工作。在加入 Cursor 之前,我在 Notion 负责 Notion Mail 相关工作。几年前,我创办了一家名为 Skiff 的公司,后来这家公司被 Notion 收购了。所以,我一直都在从事产品开发相关的工作,而且主要聚焦在生产力工具领域。

 

Harrison Chase:非常棒。我有很多话题想和你探讨。要不我先抛砖引玉,问问你对编码 Agent 的发展历程,以及这些年来人机交互模式演变的看法吧。你们可以说是这个领域的先行者之一,我认为编码 Agent 的发展经历了几个阶段的转变:从最初的代码自动补全,到集成在集成开发环境(IDE)中的对话式交互,再到如今出现的各类终端工具,以及基于云端的异步 Agent。我很想听听你的看法,你觉得这样概括其用户体验的演变历程是否准确?或者你们团队是如何看待这一发展过程的?

 

Jason Ginsberg:我认为编码 Agent 的发展确实可以用 “翻天覆地” 来形容,而且这些变革基本上都是在一年多一点的时间里发生的。正如你所说,Cursor 最早开启了代码自动补全的先河,这种模式主要是在逐行的层面上提供辅助,适用范围也基本局限在单个文件内。而此后,几乎每隔几个月,我们就不得不提升产品的抽象层级,这其实是一个极具挑战性的产品设计难题。显然,Agent 的出现让开发者能够在多个文件之间灵活切换,并且可以放心地让 Agent 自主完成代码修改工作。

 

在过去两个月左右的时间里,我发现行业又出现了新的转变:开发者现在已经能够做到从项目启动到结束全程信任 Agent,并且会对整个代码库中多个文件的内容进行批量审核。因此,我们不得不对产品的整体布局进行大幅重新设计,将核心从逐行的代码差异对比,转向更偏向代码审查的模式。

 

展望未来的产品开发方向,我们的工作重心其实会更多地放在多 Agent 协同运行上。我们需要实现的是,能够快速验证这些 Agent 是否在正常运行,并且可以让它们并行工作,同时避免受到当前单一对话模式下各种选项和选择的束缚。

 

Harrison Chase:推动这些变革的核心因素是什么?仅仅是因为大模型的性能变得越来越好,还是有其他更多的影响因素?

 

Jason Ginsberg:我认为大模型性能的提升是一个很关键的因素,这让开发者能够更加信任 Agent 编写的代码质量。要知道,以前大家必须对 Agent 生成的代码进行非常全面细致的审查。

同时,现在也有了更完善的代码审查工具。比如我们有 BugBot,市场上其实还有很多类似的工具,它们都能够自动检查代码中存在的问题。

 

此外,我觉得从行业文化层面来看,开发者们对 Agent 工具的接受度和使用信心也在不断增强,甚至可以说已经 “上瘾” 于这类工具带来的便捷。而且,一旦习惯了完全依赖 Agent 进行编码的工作模式,再切换回传统的编码方式其实是很困难的。所以现在,我们能看到越来越多的开发者已经将 Agent 辅助编程作为默认的工作方式。

最顶尖工程师的干活秘诀:全靠 Agent?

Harrison Chase:你观察到大家使用 Cursor 的方式都有哪些不同?或者你自己平时是怎么使用 Cursor 的?

 

Jason Ginsberg:其实在我们公司内部,工程师们使用 Cursor 的方式就五花八门。甚至团队里有几位工程师,他们完全不使用 Cursor 的 Agent 功能,比如负责安全和基础设施的同事。所以,确实有一部分用户非常依赖代码自动补全功能,日常使用中大部分操作都是基于补全功能完成的。但令人意外的是,我发现团队里一些最顶尖的工程师,我们称他们为 “核心用户”,他们做任何工作都会完全依赖 Agent,甚至会同时运行多个 Agent 并行处理任务。

 

至于我个人的使用习惯,我并不会去设计那些复杂繁琐的提示词,也没有什么所谓的 “Agent 使用秘籍”。我写的提示词往往都很简短,甚至还会带有拼写错误。我会针对手头不同的工作任务,或者同一个问题的不同模块,同时启动多个 Agent,然后等待它们返回结果。

 

目前我用得最多的是我们今天刚刚发布的一个新功能:调试模式。这个模式下,Agent 能够通过生成日志来进行自我评估,之后开发者复现相关操作步骤,Agent 就会通过查看日志判断问题是否得到解决。这个功能非常实用,因为它相当于通过投入算力去不断尝试解决问题,最终攻克那些手动排查起来极为棘手的难题。

 

Harrison Chase:调试模式具体是什么样的?为什么需要专门设置这样一个模式?难道不能自动完成调试吗?直接给 Agent 下达调试指令不也可以吗?

 

Jason Ginsberg:其实我也认同你的这个想法。所以在开发调试模式的时候,我们内部确实有过不少争论。主要原因在于,Cursor 目前已经有很多功能模式了,如规划模式、询问模式等等,这些模式其实不太容易被用户发现。我们一直认为,这些模式都很实用,理想的状态应该是,Agent 能够根据用户的操作场景,自动匹配并启用最合适的模式,无需用户手动切换。

 

而现阶段调试模式之所以需要手动开启,是因为它的交互方式比较特殊。在运行过程中,Agent 会暂停当前的工作,向用户提问以获取反馈。如果用户不熟悉这种交互逻辑,可能会觉得比较困扰。

 

Harrison Chase:Agent 具体会询问哪些问题,又需要用户提供什么样的反馈呢?

 

Jason Ginsberg:我举个例子吧。假设我正在开发一个前端应用,遇到了一个很让人头疼的问题:菜单总是在左上角弹出。这时候我会对Agent说:“这个菜单需要锚定到按钮的位置。” 随后,Agent 会启动服务器,并在整个代码库中添加大量日志,同时提出一系列可能导致该问题的假设,如 “可能是某个定位参数设置错误”、“可能是事件绑定逻辑有问题” 等。之后,Agent 会提示我:“麻烦你点击这个按钮,打开菜单,看看问题是否解决。” 如果我反馈问题依然存在,Agent 就会查看生成的日志,然后分析判断:“这个假设成立,那两个假设不成立”。通常这样反复两三次之后,Agent 往往就能找出并解决问题。

 

Harrison Chase:你觉得人类还需要手动操作多久?就不能让 Agent 自主完成点击、测试这类操作吗?

 

Jason Ginsberg:一两个月内,毕竟这个行业的发展速度实在太快了。

 

Harrison Chase:刚才你提到了 Agent 的多种不同模式,比如规划模式、解释模式、调试模式等等。这些模式在实际应用中到底意味着什么?难道只是为 Agent 设置不同的提示词这么简单吗?还是说背后有更复杂的逻辑?

 

Jason Ginsberg:很多时候,确实就是修改一下系统层面的提示词。不过在某些情况下,我们也需要对用户界面进行相应的调整。比如规划模式现在也加入了交互提问功能,运行过程中会主动打断用户操作,寻求反馈。用户有时也可以自行设置参数,如调整 Agent 打断的频率等。再比如询问模式,它不只是依赖特定的系统提示词,还会限制 Agent 调用某些与文件编辑相关的工具,以此来保证功能的稳定性和可靠性。

 

Harrison Chase:回到之前的话题,关于大家使用 Cursor 的不同方式,你觉得未来使用编码 Agent 或者说 Cursor,存在所谓的 “最佳方式” 吗?

 

Jason Ginsberg:我觉得并没有什么 “最佳方式”,具体的使用方法很大程度上取决于工程师的个人工作习惯以及他们所处理的具体工作内容。目前行业里,既有异步运行Agent的应用场景,也有开发者深度参与、实时交互的模式,就像一边编程、一边像画画一样实时调整代码或者进行可视化的编辑操作。不过我经常在推特上看到一些所谓的 “Agent 使用技巧”,其实对此我是有点持保留态度的。很多人会说 “这才是使用 Agent 的最佳方式”,但在我看来,这些技巧往往是凭空杜撰的。

 

我们团队内部其实并不会使用那些冗长复杂的提示词,也不会采用多阶段规划的策略。大多数时候,我们都是快速迭代,如果 Agent 运行的结果不理想,就直接终止进程,重新启动 Agent。通常这种方式的效率是最高的。

自然 “唠嗑”是 Cursor 最终交互模式?

Harrison Chase:如果让你预测一下一年后的情况,你认为开发者在 IDE、终端以及其他形态的载体上使用 Cursor 的时间占比会是怎样的?

 

Jason Ginsberg:当然,我肯定会带有一定的主观偏向性。但我认为,终端工具并不会成为用户的首选。我觉得,真正驱动行业发展的是用户对Agent的信任度不断提升,他们更希望等到Agent完成所有工作后再查看最终的修改结果,然后决定是否采纳,同时也愿意让 Agent 运行更长的时间,以实现更智能的处理。

 

而 IDE 之所以至关重要,是因为它是为整个软件开发周期量身打造的工具。从项目的构思规划,到运行代码修改、查看代码内容、清晰对比代码差异、提交代码合并请求,再到在浏览器中预览效果所有这些环节,都可以无缝集成在 IDE 的模块化功能之中。这一点其实很容易被忽视,毕竟 IDE 的这些功能是经过了数十年的发展才逐步完善起来的。

 

我认为,当前行业的一个明显趋势是,产品层面的设计变得越来越重要。现在 Cursor 用户使用频率最高的功能,如规划模式,其实都需要可视化编辑器的支持,用户需要能够在编辑器中添加注释,并进行实时交互。一旦脱离了按钮、弹窗和菜单这些可视化交互元素,用户与工具的交互难度会大大增加。

 

不过,我觉得未来并非所有操作都必须局限在笔记本电脑的 IDE 中完成。这种模式并不会被完全取代,具体的使用场景会根据实际需求灵活变化,适用的场景也会更加广泛。用户在更多场景下,都能够使用到 Cursor 这样的工具。

 

Harrison Chase:未来会有更多场景都能用上像 Cursor 这样的工具。你们应该有对应的官网吧?用户可以直接在网页上进行交互操作,是这个思路吗?

 

Jason Ginsberg:对,我们确实有官网。这么做的原因是用户可以通过手机等设备随时随地访问。我觉得在不远的将来,用户完全可以戴着 AirPods,开启语音模式,和Agent实时沟通、碰撞想法,让Agent不断优化方案。等用户到了办公室,打开笔记本电脑,就已经有一堆代码修改记录或者演示视频等着审核了,到时候只需要简单确认通过或者驳回就行。如果某些细节还需要微调,再把项目下载到本地修改就好。

 

Harrison Chase:我认为 Cursor 真正的优势,在于围绕 Agent 交互打造的整套设计和用户体验体系。你之前在 Notion 工作过,我记得即便是在生成式 AI 普及之前,Notion 的设计和用户体验就已经广受认可了。当然,他们在生成式 AI 时代也很好地完成了转型。从一家在生成式 AI 普及前就拥有出色设计积淀且顺利完成转型的公司,再到如今专注 Agent 相关工作,你觉得 Agent 的出现给产品设计和用户体验带来了哪些变化?现在的工作模式和之前有相似之处吗?

 

Jason Ginsberg:我觉得总体来说,我们产品的大部分设计其实并不是 AI 专属的。要知道,产品可用的交互组件和用户体验模式就那么多,市面上的应用本质上也都是基于一些传统的模式搭建的,如收件箱、仪表盘、聊天界面,这些都是很成熟的设计。所以我们的工作核心,更多是把这些现有的设计模式进行合理组合,然后在产品中恰当地呈现出来。这一点和 Notion 的产品理念是相通的,同时也是 Cursor 和集成开发环境(IDE)的核心特质:极高的模块化程度。

 

作为用户,你会发现每个人的 IDE 界面布局都可以千差万别。你可以自定义面板布局,把任意组件拖放到任意位置,和坐在你旁边的同事设置出完全不同的界面。我认为这种模块化设计对产品的适应性至关重要,毕竟如我之前所说,Agent 的能力发展日新月异,用户对产品的需求和期待几乎每隔几周就会发生变化。几个月前我们推出 Cursor 2.0 的时候,并没有把原来的产品推倒重来,只是把各个功能模块重新组合,调整为侧边栏收件箱式的管理布局,同时优化了聊天界面的信息密度而已。

 

Harrison Chase:听你这么说,很多组件的底层逻辑其实是相通的。那有没有出现新的组件?或者某些组件的优先级发生了变化?毕竟这些组件最初都是为 “人类与软件交互”“人类通过软件协作” 的场景设计的,现在加入了 Agent 这个新角色。这其中有没有产生什么新的变化?还是说其实本质上没有太大不同?

 

Jason Ginsberg:我认为底层的设计逻辑和核心要素其实没有变,关键变化在于谁在主导界面交互。而在这个核心框架下,其实可以演变出无数种交互形式。就拿交互的抽象层级来说,一年前大家使用Agent的时候,都恨不得盯着它的每一步操作,全程 “盯梢”。但现在 Agent 的操作步骤变得无比繁杂,用户根本看不过来。所以我们需要优化信息呈现方式:如何对操作步骤进行分组?如何提炼关键信息?

 

当用户足够信任 Agent 的操作后,我们就需要把重点放在文件的实际修改内容上,并且为这些修改添加更详细的注释说明。当然,我们也可以进一步提升交互的灵活度,比如聊天对象不再局限于单个 Agent,而是可以同时和多个 Agent 对话。这就需要一套更智能的后台交互逻辑来支撑 ,系统要能识别用户在和哪个子 Agent 对话,并且协调这些 Agent 完成对应的修改。未来这种交互的抽象层级还会不断提升。

 

Harrison Chase:你觉得交互的抽象层级最高能达到什么程度?我知道预测未来很难,但还是想听听你的看法。

 

Jason Ginsberg:我觉得未来,我们现在看到的各种操作选项,如选择模型、选择功能模式、选择运行环境这些都会逐渐消失。最终的交互模式会变得像和真人对话一样自然。但这并不意味着任何人都能随便写代码,在那个阶段,这个工具依然是为专业工程师服务的。因为你还是需要具备专业的行业术语知识,清楚自己想要修改的内容是什么。做产品的人,要明确自己想要的工作流程和功能需求;做基础设施的人,要足够了解代码库,知道什么样的架构和系统设计最适合当前要开发的项目。

 

而且我想强调的是,随着抽象层级的提升,我们并不会摒弃现有的功能。用户依然可以随时深入底层,查看细节、调整参数。只是产品的默认交互方式会不断优化升级。

Cursor 内部工作揭秘:少审代码、高频反馈

Harrison Chase:你之前提到了人类在 Agent 工作流程中的角色,比如查看代码差异、进行代码审查。你觉得 AI 会给代码审查工作带来哪些改变?

 

Jason Ginsberg:首先,就我们产品团队的工作模式来说,现在人工审查的比重已经大幅降低了。我们有一个叫 BugBot 的工具,它会自动检测代码问题,并且自主完成修复,还会在持续集成(CI)流程中不断迭代优化。这个工具的表现非常出色,也让我们对 AI 审查的代码质量更有信心。

 

其次是信息的语义化分组。用户查看代码差异时,可以清晰地看到 Agent 做了哪些修改。我们甚至可以展示 Agent 的原始指令,更理想的状态是,Agent 能够像人类一样,在处理大型代码合并请求时,为每一处修改附上注释,说明这么做的原因。我觉得这虽然算不上颠覆性的变革,但确实能给代码审查工作带来显著的优化。

 

Harrison Chase:出于好奇,我想问一下,Cursor 的工程师用 Cursor 写代码,用 BugBot 审查代码,那他们还需要和其他工程师沟通协作吗?

 

Jason Ginsberg:哈哈,这个问题很有意思。如果你以工程师的身份加入 Cursor,会立刻发现一个现象:所有人都在深度使用自家产品。我记得我入职第一周的时候,修改了一个快捷键设置。那个快捷键是 Alt+Shift+Command+J,非常冷门,我当时觉得选这个键肯定没人会注意到。结果刚改完不到半分钟,就有三个同事在 Slack 上发来消息:“你改的这个快捷键直接打乱了我的工作流程!到底怎么回事?”几乎任何产品改动,都会立刻收到同事们的强烈反馈。我觉得这其实是一件好事,大家就是在这种高频的反馈和交流中,快速推进产品迭代的。

 

Harrison Chase:从组织管理的角度,你们有没有采取什么措施来鼓励或者引导这种高频反馈的协作模式?毕竟大量的反馈涌进来,有时候也会让人应接不暇。

 

Jason Ginsberg:在我创办自己的公司之前,工程师们也会用邮件沟通,但用得并不多。大家甚至会说:“邮件只用来收垃圾邮件和购物通知,可别用它来发长篇大论的工作内容。”而在Agent这个赛道工作,其实完全不需要依赖邮件这种低效的沟通方式。我们团队的所有人都全身心投入工作,毕竟这是一个竞争非常激烈的领域,大家都对产品开发充满热情,会自然而然地用各种即时沟通工具协作。

 

另外,我在规划产品功能时,会遵循一个核心原则:我能开发什么功能,让自己的日常工作更轻松? 具体来说,就是思考 “做什么能帮我明天更高效地完成工作,不用再处理那些烦人的报错和问题”。这个原则指导着我们的大部分工作。毕竟这种功能开发出来之后,我们自己能立刻受益,比如修复了一个烦人的漏洞,以后上班就不用再被这个问题困扰了。

迭代狂飙背后,核心功能竟来自员工 “自嗨”?

Harrison Chase:你觉得你们的产品路线图,有多大比例是由 “让自己工作更轻松” 这个需求驱动的?又有多大比例是来自外部用户的需求?这个比例随着公司发展有变化吗?

 

Jason Ginsberg:这个比例确实随着公司规模的扩大在变化。现在我们也会制定月度的产品路线图和目标,但说实话,我们很多核心功能都来自自下而上的创新。比如 Cursor 的Agent功能,这可以说是大家提到 Cursor 时最先想到的核心功能。这个功能是我们团队的一个人开发的,最开始所有人都不看好这个想法,但他很快做出了原型。大家试用之后都惊叹:“哇,这东西居然真的能用!”

 

我之前提到的调试模式也是如此。感恩节假期的时候我闲着没事,就开发了这个自己很需要的功能,现在这个功能也即将上线。这些功能的开发初衷,都是为了解决团队内部的需求。我们判断一个功能是否具备发布条件,一个重要的衡量标准就是内部的使用率和认可度。

 

Harrison Chase:你们的产品迭代速度快得惊人,是怎么保持这种高效的开发节奏的?

 

Jason Ginsberg:说实话,我们的工作流程其实非常精简,没有太多繁琐的制度。公司里虽然有几间会议室,也有一两位产品经理,但我们很少通过撰写文档或者开对齐会议来推进工作,大部分的讨论和决策都是在代码层面完成的。而这一切能够实现的核心原因,是我们对人才的极高要求。今年年初的时候,公司总共也就 20 人左右。之所以团队规模增长缓慢,就是因为我们的招聘门槛高到近乎苛刻。我们会反复评估:这个人很优秀,但他能成为团队里最顶尖的那批人吗?

 

正因为团队里的每个人都足够出色,所以我们可以放心地把任务交给任何一个人。团队成员的主观能动性都极强,从提出想法、设计用户体验,到在推特上回复用户的支持请求、和企业客户沟通需求,再到最终将功能落地,整个流程都能独立完成。所以说,我们能保持这样的速度,归根结底还是人的因素。

 

Harrison Chase:你们是如何规划产品路线图的?你刚才提到了以月为单位的规划周期,这是目前的常规规划时长吗?有没有更长期的规划?另外,行业技术迭代的速度实在太快了,你们是如何平衡 “跟进现有技术浪潮” 和 “实现技术跨越式发展” 这两者的?会不会主动预判技术趋势,提前布局未来方向?

 

Jason Ginsberg:我们确实会投入不少精力去思考未来,比如预判未来三个月可能实现的技术突破,然后主动押注相关方向,团队里有相当一部分人都在做这类前瞻性的工作。我们制定的月度路线图更多是围绕核心产品功能展开,聚焦于用户的实际需求以及那些能优化日常使用体验的功能。而那些需要投入两个月时间重构底层逻辑的重大项目,则会纳入更长期的规划范畴。

此外,我们的应变能力其实非常强。

 

有时候我们会提前拿到新模型的测试版本,试用之后如果发现它在某些方面表现特别出色,团队成员往往会主动利用周末时间加班,争取在新模型正式发布前就完成相关功能的开发。很多重要功能其实几天之内就能搭建完成。

 

Harrison Chase:说到模型,你们发布了自研的 Composer 模型。开发这个模型的初衷是什么?目前用户的使用情况如何?这个模型有没有改变大家使用 Cursor 的习惯?

 

Jason Ginsberg:我们发现,工程师使用我们产品时的编码场景,需要有专门适配的模型来支撑。Composer 模型就是针对这类场景打造的,它定位非常明确,具备速度快、质量高、逻辑智能三大特点,尤其适合 “人机实时协作” 场景。我自己做前端开发时就经常用它,因为我需要频繁做出细微的交互设计决策,这就要求 Agent 能在几秒内给出反馈。Composer 就像一个高效的协作伙伴,能快速响应需求、碰撞想法,和那些适用于长周期异步任务的模型形成了很好的互补。

 

Harrison Chase:Cursor 的 Agent 相关研发工作是全员参与,还是有专门的团队负责?

 

Jason Ginsberg:我们确实有专门的团队负责 Agent 的性能优化,他们主要聚焦于工具链、调度框架的搭建以及效果评估。但正如我之前所说,我们的团队架构并不僵化,没有严格限制大家的工作范围。比如核心产品团队的工程师在开发规划模式时,如果需要对Agent进行调整,就会和Agent团队密切协作。而且在开发过程中,我们依然会深度使用自家产品进行测试,团队成员会分享使用感受,以此来评估功能的实际效果。

 

Harrison Chase:无论是 Agent 团队的成员,还是其他团队中擅长 Agent 研发的工程师,他们身上有没有什么共同特质?他们的专业背景或者个人能力有没有什么特别之处?

 

Jason Ginsberg:我觉得他们大多是偏产品方向的人才,而不是传统意义上的机器学习或算法研究专家。这些人经常在不同团队之间轮岗,因为Agent研发需要对用户的最终使用体验有很强的直觉,同时还要能准确解读团队的反馈意见。

 

Harrison Chase:上周你们和 OpenAI 合作发布了一篇博客,内容是针对 OpenAI 的新模型优化 Cursor 的 Agent 调度框架。我在推特上经常看到大家讨论 “Agent 调度框架” 这个概念。你们是如何看待模型的底层支撑架构的?这类架构是否需要和特定模型深度绑定?比如 Composer 模型和 CodeLlama 模型,对应的架构会不会有很大差异?

 

Jason Ginsberg:我其实没有深度参与这方面的工作,但据我了解,我们的核心目标是打造高度灵活的架构。毕竟我们需要不断尝试新技术、新功能模式,所以架构必须能够随着模型能力的升级快速适配。

 

Harrison Chase:很有道理。毕竟整个行业都在飞速变化。

开放问答

提问者 1:刚才提到了新增的可视化浏览器功能,我发现有些工具比如 Lovable 也有类似的功能。请问这个功能是朝着 “沉浸式可视化编码” 的方向发展吗?

 

Jason Ginsberg:我觉得它并不是为沉浸式可视化编码设计的。就像我之前说的,这个功能最初是我为自己开发的,我本身就是一名做产品的工程师,它的核心用户群体其实是专业工程师和设计师。大家在开发应用时,肯定都遇到过这种情况:精心设计的界面,最后却变成了大家都看腻了的紫黄渐变配色。这个功能就是为了让大家能够精准把控细节,比如把内边距调整到精确的像素值。它为用户提供了一套更直观的 “视觉化操作语言”,比纯文本指令的精度更高。

 

而且就算不使用侧边栏,你也可以直接点击页面元素,随时输入提示词下达指令。借助这个功能,你可以在几秒内同时启动六个 Agent。如果开启热重载功能,你的网站会实时呈现修改效果,用起来其实还挺有意思的。

 

提问者 2:我特别喜欢你们的浏览器 Agent,一直在用。但我发现一个小瑕疵:我想持续迭代优化设计方案,可 Agent 总是会中断我的工作,直接提交代码合并请求。未来有没有可能实现不间断的持续迭代?

 

Jason Ginsberg:当然可以。未来的发展方向就是让 Agent 具备自主评估能力,根据需求长时间持续运行、循环迭代。现在的调试模式还需要人工点击按钮来确认日志信息,但这只是过渡方案。理想的状态是,Agent能够自主完成评估、迭代,直到彻底解决问题。

 

提问者 3:我不知道你是否深度参与 Agent 相关的研发工作,但我注意到 Cursor 的内存管理功能做得很好。它可以根据工程师个人、部门乃至整个公司的偏好、规则和流程,自主管理相关信息。我们都知道,信息和上下文对 Agent 来说至关重要。请问你们有没有计划进一步拓展和升级这个功能?尤其是在长上下文处理方面,你们有什么思路?

 

Jason Ginsberg:我们正在进行大量的实验和探索。目前已经落地了规则管理、内存记忆、技能库等多个功能模块。现阶段,我们主要在研究高效的信息摘要技术。另外,借助我们的自研模型,我们也在探索让模型自主识别对话或代码中反复出现的关键信息。当然,跨组织的信息共享功能也很值得探索。不过这里有个需要注意的点,相关规则和信息可能会随着模型的迭代而过时。所以我们必须确保用户能够轻松更新这些内容,避免被过时的规则束缚。

 

提问者 4:关于你们发布的 Composer 模型,我认识一些开发者,他们基于 Gemini 模型微调了一个医疗领域的专用模型。但他们发现,这个微调后的模型效果还不如直接用原生 Gemini 模型做单次提示词调用。他们分析的原因是,微调模型需要持续维护,要跟上 Gemini 等基础模型的更新节奏。请问你们是如何制定策略,确保 Composer 模型不会落伍的?

 

Jason Ginsberg:你说的是 Composer 模型,对吧?我们会持续对它进行迭代优化,它并不是一个静态的模型。我们的核心关注点,是在速度和智能之间找到最佳平衡点,满足 Cursor 用户在大部分场景下的需求。不过在长上下文处理这类特定领域,我们确实还有提升空间。

 

提问者 5:我自己是产品经理,一直在用 Cursor 做原型开发,甚至在团队里还客串设计师,用它替代 Figma。我很好奇,有没有用户是在使用 Cursor 之前,从未安装过任何集成开发环境(IDE)的?这类用户会不会成为你们未来重点关注的群体?毕竟现在的编码 Agent 已经足够强大,很多工作都能在上面完成。

 

Jason Ginsberg:坦白说,我们目前并没有把这类用户作为核心关注点。当然,我们认同工具的使用门槛确实需要不断降低,而且 Cursor 的易用性也在持续提升,比如新增的浏览器工具对设计师就很友好。但我们的核心目标,其实是赋能顶尖工程师。我们一直在思考:如何让世界上最优秀的工程师变得更加强大?在这个过程中,我们开发的工具自然会惠及更多人群。不过在产品优化方面,我们确实还有很多工作要做,如优化新手引导和环境配置流程。毕竟设计师和产品经理在配置 GitHub 等工具时,经常会遇到困难。我们希望通过优化这些环节,吸引更多用户尝试 Cursor。

 

提问者 6:我一直在尝试用 Cursor 做智能合约的验证矩阵构建和试运行逻辑测试。请问在深度质量检测和安全加固方面,有没有什么不太为人知的实用工作流可以推荐?或者刚才提到的调试工具能不能派上用场?我对智能合约的质量检测特别感兴趣。

 

Jason Ginsberg:说实话,我们正在尝试让 Agent 自主完成测试工作,不过这项功能目前还没有完全发布。对于从事质量检测工作的人员来说,我强烈推荐试试我们刚发布的调试模式。这个功能定位问题的逻辑非常清晰,几乎可以说是确定性的,用起来会很有帮助。

 

提问者 7:您认为未来两到四个月,Cursor 面临的最大机遇是什么?会不会是语音 Agent?

 

Jason Ginsberg:我觉得机遇不在于语音 Agent。用户现阶段最核心的需求,其实是让 Agent 变得更智能、运行时间更长、能处理的任务更多。现在的很多 Agent,本质上只是在 “读取代码”,并不能真正判断修改后的代码是否有效。未来的发展空间非常大,我们可以投入更多算力,让 Agent 承担更多人类目前负责的校验工作。我觉得未来三到六个月,整个行业都会迎来巨大的变革,非常值得期待。

 

参考链接:

https://www.youtube.com/watch?v=dKSGK-fPFyU

从 Meta 离职、加入 Anthropic,这个决定在今天看来并不意外,但在当时却并非顺水推舟。

 

对 Claude Code 创建者 Boris Cherny 来说,这并不是一次普通的职业跳槽,而是一种价值判断:当大模型从“工具”逐步演化为具备自主生成与推理能力的系统,工程师究竟应该站在什么位置?是把它当作效率插件,还是把它视为一种需要被认真约束、引导和共同演化的新型技术力量?

 

近日,Boris Cherny 做客一档名为《The Peterman Pod》的访谈栏目,主持人 Ryan Peterman 与 Boris 围绕这一系列问题展开了长达一个半小时的深度对话。

 

访谈的前半部分,Boris 回溯了自己从 Meta 转向 Anthropic 的动机。他并未从公司前景或个人发展谈起,而是从第一次使用 ChatGPT 的震撼说起。在他看来,大语言模型并不只是“更聪明的软件”,而更像一种尚处在早期阶段的“新生命形态”——它的能力增长呈指数级,影响范围远超工程本身,最终会重塑社会运行方式。正因为如此,他选择加入一个将安全、对齐与长期风险置于核心位置的研究机构,而不是继续在以产品速度和规模为优先目标的大厂体系内工作。

 

这种价值取向,也直接塑造了 Anthropic 内部截然不同的工程文化。在鲍里斯的描述中,Anthropic 依然保留着创业公司式的“常识感”:工程决策不需要层层说服,安全不被视为拖慢产品的负担,而是与模型能力同步演进的前提条件。随着模型能力提升,风险不再只是内容失误或选举操纵,而是逐步逼近生物安全、社会系统性破坏等更高等级的问题。这并非科幻设想,而是工程师当下必须正视的现实边界。

 

在此背景下,Claude Code 的诞生与演进,成为这次访谈的另一条主线。Boris 坦言,Claude Code 在相当长时间里并不是一款“好用的产品”。它之所以最终跑出来,并非因为早期体验领先,而是因为团队在一开始就选择“为未来六个月后的模型能力而设计”,而不是围绕当下模型的短板打补丁。

 

随着 Sonnet 和 Opus 4 等模型上线,Claude Code 从辅助工具迅速跃迁为主力生产方式,在 Anthropic 内部,大量代码已经由模型生成,工程师的角色也随之发生变化。

 

但这并不意味着“氛围编码”可以无条件替代人类判断。Boris 反复强调,模型生成的代码与人写的代码必须接受同一套质量标准:不合格就不合并。不同任务对应不同协作方式——原型、临时代码可以交给模型快速推进,而核心逻辑仍需要工程师逐行审视。这不是“人被 AI 取代”,而是人类工程师与模型之间形成一种新的协同分工。

 

更重要的是,Claude Code 的使用场景正在溢出传统的软件工程边界。数据科学家、分析师、甚至销售团队,都在把它当作通用的工作执行工具,连接数据库、业务系统和数据源完成实际任务。这种扩散并非最初的产品设计目标,却揭示了一个趋势:当“写代码”本身变得门槛更低,软件能力正在被重新分配到更多角色手中。

 

贯穿整场对话的,是一个清晰却并不轻松的判断:软件工程正在经历一次结构性重写。工程师不再只是代码的直接生产者,而正在成为“智能体系统”的设计者、管理者和最后的责任人。Claude Code 只是一个具体案例,但它所揭示的,是一个更大的变化——当模型能力以指数级提升,工程文化、工作方式乃至风险边界,都必须随之重构。

 

以下为访谈实录,经由 InfoQ 翻译及整理:

 

Claude Code 创建者,职业生涯起步于 Facebook

 

Ryan:我想从你晋升为 Meta 高级工程师开始讲起你的故事。你晋升的那些项目背后有什么故事?当时你在哪里?

 

Boris:如果我没记错的话,这个项目叫做“群组聊天”,目的是为了让 Messenger 和 Facebook 之间的联系更加紧密。

 

我在 Meta 参与的最初几个项目都与 Messenger 和 Facebook 有关。第一个项目是扎克伯格提出的将 Messenger 聊天记录和 Facebook 群组同步的想法。当时有几个项目旨在拉近 Messenger 和 Facebook 之间的距离。

 

最初的动机是,我们感觉公共空间社交产品正在消失,而人们的注意力更多地转移到聊天和更随意的实时空间。我们尝试了几个产品版本,最终“聊天和群组”版本取得了成功。

 

我记得当时应该是第三个或第四个项目。那时我在 Facebook Groups 部门,主要负责 Messenger 的相关工作,但 Messenger 的组织架构和我们离得很远。这个想法是当时的 PM Steve 提出的。我听了之后觉得,好啊,太棒了!就这么办!我就开始着手开发。很快有了进展,于是我申请了更多工程师,有三位工程师加入了。

 

我们获得了一些数据科学和设计方面的支持。项目最初在网页端启动,后来也稍微拓展到了移动端。我们验证了在 Facebook 群组内进行聊天的想法,并证明了这类产品是可行的。当然,也有很多方面最终都失败了。

 

以现在的产品标准来看,当时的体验简直糟透了。那时候,大家都在用 Web 开发,各种各样的 bug 都完全可以接受。但现在,视觉效果和质量标准要高得多。产品不断发展壮大,而我们团队很小,所以每个人都得包揽所有工作。

 

我记得当时我们没有用户研究员,所以我会在午餐时间去食堂。我们会推出一个新功能,然后向食堂工作人员展示,问他们能不能找到打开聊天窗口的方法。有时候他们能找到,有时候找不到。

 

这是一项观察性用户研究。你可以观察人们在特定情况下如何完成任务,而无需过多提示,从而了解他们在哪些方面遇到困难,以及最终取得了哪些成果。我教会了团队如何进行这项研究,很快我们就会利用午餐时间去食堂,询问食堂工作人员(作为用户的代表)这种方法是否合理。

 

Ryan:有趣的是,你当时所处的早期 Facebook 文化允许工程师们在代码之外做很多事情。例如,你当时在做用户体验研究。我记得在你的经历中,你也做过一些设计工作,并且指导过其他人进行设计。我认为这在 Facebook 的企业文化中是一个非常有趣且独特的事情。对吗?

 

Boris:我觉得这一点非常重要。直到今天,在我所在的 Claude 团队中,我们仍然非常重视通才型人才

 

我喜欢和通才共事。如果你是一位既会写代码又能做产品开发、设计,并且具备产品意识的工程师,那么你肯定想和用户交流。我非常喜欢和这样的工程师一起工作。现在我们所有职位都是这样招聘的:我们的产品经理会写代码,我们的数据科学家会写代码,我们的用户研究员也会写一点代码。

 

我非常喜欢这些通才。我的成长经历也是如此。从 18 岁创办第一家公司开始,我就得事事亲力亲为。在加入 Facebook 之前,我也一直在一些规模较小的公司工作,那里也一样,什么都得做。在大公司里,你可能会被安排在某个特定领域,但这其实只是个形式。工程技能的范围很广,除了编写代码,完成整个流程还有很多其他方面需要考虑。当时能在一家真正重视这种能力的公司工作,感觉真的很棒。

 

我觉得在那半年结束时,我得到了晋升,然后我觉得在那半年结束后,所有的工程师也都得到了晋升。

 

Ryan:在那些早期产品中,存在着你多次提到的“潜在需求”概念,这正是许多产品方向的推动力。你能解释一下“潜在需求”吗?

 

Boris:潜在需求是产品设计中最重要的原则。纵观 Facebook 的成功产品,每一款都蕴含着潜在需求的元素。

 

例如,Marketplace 的诞生源于一项观察:当时 Facebook 群组中 40% 的帖子都是关于买卖物品的。Facebook 群组最初并非为商业用途而设计,但人们却用它来做这件事。你设计的产品要具有一定的可扩展性和易用性(即使被“滥用”)。然后,你分析数据,看看用户是如何“滥用”的,并以此为基础开发新的产品功能。

 

先是出现了 Facebook 群组,然后是买卖群组。买卖群组之所以发展迅速,是因为人们本来就想在 Facebook 群组里进行商业活动。接下来是 Marketplace,它只是人们这种意图的自然延伸。Facebook Dating 的发展也与之类似。观察发现,大约 60% 的个人资料浏览量来自互不相识的异性用户。这种传统的互相“窥探”行为证明了这种方法的有效性。

 

产品设计的核心原则是:你永远无法强迫人们去做他们原本不会做的事情。但你可以找到他们的潜在意图,并引导他们更好地利用这种意图,从而更轻松地实现目标。

 

“跨部门工作简直是一场噩梦”

 

Ryan:在你的叙述中,你提到你曾跨部门工作,因为你负责弥合 Messenger 和 Groups 工程团队之间的鸿沟。你说存在一些明显的文化差异,这很困难。对于在文化差异很大的组织之间工作,你有什么建议吗?

 

Boris:我的天哪,说困难都太轻描淡写了。简直是一场噩梦。当时 Facebook 的目标是尽快推出优秀的产品。而 Messenger 则完全专注于可靠性和性能,他们只关心这些。这完全是截然相反的价值观。

 

这不仅仅是文化差异或工程师之间的问题。那个团队的工程师对我们抱有戒心,因为我们的工作可能会影响他们的绩效指标。他们的组织目标是稳扎稳打,在不影响核心指标的前提下稳步推进产品发布;而我们的组织目标是快速发布。

 

目标完全不同。他们关注的是服务级别协议规定的正常运行时间,而我们只关注日活跃用户数和用户参与度。这些文化价值观根深蒂固,不仅体现在人们的言谈中,更体现在组织架构、目标设定等各个环节。

 

那个项目最终能部分成功,克服了价值观差异,关键在于:如果你想让价值观截然不同的团队成功合作,就必须找到某种共同的目标、共同的兴趣或共同的信念。让他们能够一起验证某个假设,并且如果验证成功,对双方都有益处。

 

Facebook 的“聊天和群组”功能很酷,但很多功能在 Messenger 上实现时却不太理想,原因就在于此。

 

Ryan:既然你现在知道了这些,你会如何改变现状?

 

Boris:我可能会去找高层(比如扎克伯格),然后说,如果你真的对这件事很认真,我们应该把 Messenger 并入 Facebook 的组织架构下。我觉得这件事后来确实以某种形式发生了。Messenger 最初在公司里,后来搬了出去,然后又搬了进来,之后又搬了出去。公司这么大,这种情况难免发生。

 

但我认为,从根本上来说,这类事情要想成功,不能只靠普通经理去协调。可能需要更高层的介入,调整组织架构,让它们更具合作性。

 

Ryan:在你职业生涯的这个阶段,我看到你做了很多非常有趣的副业项目,我很好奇这些项目会产生怎样的蝴蝶效应。例如,在你加入 Meta 之前,你曾参与过 Undux 的开发,这是一个 React 的状态管理框架。我很好奇这段经历对你的职业生涯产生了怎样的影响?

 

Boris:对我来说,支线任务非常重要。我招聘工程师时,这绝对是我会考虑的因素之一。我想要那些有副业项目的人,比如周末可以做一些有趣的事情。甚至包括那些对制作康普茶充满热情的人。你需要的是那些对工作以外的事物充满好奇心和兴趣的人。这些人全面发展,我喜欢和他们一起工作。我的很多成长都来自于参与这些副业项目。

 

说实话,像 Undux 这样的工具,源于我觉得当时用 React 管理状态太复杂了。当时最先进的技术是 Flux,后来又出现了 Redux,但我完全搞不懂 Redux。我自认为只是个水平一般的产品开发工程师,不是那种技术高超的系统工程师。Redux 的概念,比如 reducer,更新一个小小的状态都需要非常复杂的流程,我理解不了。

 

所以我做了一个更简单的版本,效果不错。当时我在一家非营利组织做志愿者,他们开始使用这个版本,他们的工程师也很喜欢。加入 Facebook 后,我发现很多人在使用 Redux 时遇到困难,公司内部有一个 Redux 用户群,里面有很多问题,和我当初问的都一样。

 

当你作为工程师遇到问题时,有时可能只有你一个人遇到;但很多时候,其他人也会遇到同样的问题。培养一种“直觉”,能够预判其他人可能也遇到的类似问题,这非常重要。我遇到的这个问题显然是其他人也遇到的,我在用户支持帖子里也看到了。

 

我在公司内部推出了 Undux。它还不错;虽然算不上很棒的产品,但比 Redux 简单。在 Facebook 的时候,我不知道该如何推广它,所以我就发帖宣传了一下。结果有几个人开始用了。我记得通知团队的 Jeff Case 是这项功能的早期积极使用者,我们因此熬了好几个通宵,调试一些棘手的通知相关 bug。

 

为了推广这项功能,我写了个小脚本,抓取了提交问题的用户群体,并按团队进行了统计。我通过聊天工具联系了每个团队的技术负责人和经理,并为每个团队安排了一场技术讲座。在几周的时间里,我大概做了二三十场,甚至四五十场技术讲座。我记得当时骑着自行车在 Meta 园区里四处演讲,感觉特别棒,因为大家都很投入,也很兴奋有人关心这个问题并想解决它。

 

曾经,Undux 是 Facebook 最流行的状态管理框架之一。但很快它就被 Recoil 和其他更现代的方案取代了。如今,Relay 之类的框架又开始流行。

 

Ryan:这种副业项目会出现在你的绩效考核中吗?或者对你有什么帮助?

 

Boris:我觉得它应该写在我的绩效考核里了。按 Meta 的标准来说,这算是锦上添花。它本身并不能让你直接晋升到下一个级别。那段时间我还有很多其他的支线任务。

 

后来,我突然对 TypeScript 非常着迷。这是我之前在一家公司用过的。当时相关的资源不多,所以我开始写一本关于它的书,因为总得有人做这件事。这门语言太棒了,设计非常出色,包含了很多当时其他语言不具备的理念,像条件类型、字面量类型、映射类型之类的,简直太疯狂了。即使是最资深的 Haskell 程序员也会惊叹,但之前却没有人系统性地写过这些内容。

 

我当时完全沉迷其中,写了这本书,几乎耗尽了我整整一年的业余时间。我不推荐别人也这样做,但深入研究的过程真的很有趣。当时我还在旧金山创办了世界上最大的 TypeScript 聚会。能见到 Node.js 的创始人 Ryan Dahl 以及其他这些著名的 JavaScript 大咖,真是太棒了。这让我意识到,他们也只是普通人;每个人都能创造出很酷的东西。

 

Ryan:后来你在 Meta 工作期间,或者甚至在 Anthropic 工作期间,最终有没有大量使用 TypeScript 或达到那种技术深度?

 

Boris:是啊,说起来挺有意思的;我以前其实对编程语言本身一点兴趣都没有。大概十年前,我骑摩托车的时候出了一场很严重的车祸,双臂都骨折了,身上绑着两个吊带。

 

Ryan:我的天哪。你是怎么写出代码的?

 

Boris:那才是最难的部分。我整整一个月都不能写代码,而且我的手现在还有点疼。我写不了 JavaScript(按键多),所以我不得不学习其他按键次数更少的语言。我一开始学的是 CoffeeScript,因为它的括号比较少。这门语言现在应该已经没什么人用了。我也是通过 CoffeeScript 接触到 Haskell 和函数式编程的。你可以用更少的击键次数完成同样的事情,这正是我当时的动力。

 

在加入 Facebook 之前,我在一家对冲基金工作,我的同事 Rick 对 Scala 非常着迷。他带我入门,也让我接触到了函数式编程。如果让我推荐一本对我的工程师生涯影响最大的技术书籍,我会毫不犹豫地推荐《Scala 函数式编程》。你可能永远不会每天都用 Scala,但它教你思考编程问题的方式,与大多数人在学校或实践中接触的方式截然不同,这彻底改变了我的编码方式。

 

对我来说,Scala 和 Haskell、CoffeeScript 一样,是少数几种改变我思维的语言。第一步是 CoffeeScript,然后是 Scala,再然后是 TypeScript。这改变了我的思维方式,因为现在我编码时会用类型来思考。代码中最重要的就是类型签名,这比代码本身更重要。做好这一点能写出非常简洁、健壮的代码。

 

即使在 Facebook,我主要用 Flow 和 Hack,后来在 Instagram 用 Python,这种思维方式也很有帮助。在 Anthropic,我主要用 TypeScript 和 Python,所以这一点仍然非常重要。更重要的教训就是要学会用类型来思考。

 

Ryan:在你职业生涯的这个阶段,你提到你刚入职时级别偏低,只是个中级工程师,尽管你经验丰富。你说现在回想起来,当时级别低反而是件好事。我很好奇你当时是怎么想的。

 

Boris:在大公司里,对于项目影响和人员影响方面都有很多期望,具体标准因公司而异。很多事情要么关乎项目的影响,要么就是为了完成一堆任务,而这一切都非常耗时。刚开始的时候等级不够,反而给了我探索的空间,让我可以纯粹为了创造而创造,没有太多绩效压力。

 

Ryan:没错。我很好奇这是否也有助于积累势头。如果你以中级级别加入,然后表现出色,所有人都会说“Boris 太棒了”。这很不可思议。而如果你以更高预期级别加入,表现平平,情况就完全不同了。当你一加入就让所有人眼前一亮时,会产生一种奇妙的效果,你会给人留下非常深刻的第一印象。我认为这有助于建立良好的声誉,从而在未来获得更多的信任、更多的项目等等。

 

Boris:是的,我觉得完全正确。这对于任何公司来说都是很好的建议。很多时候,工程师跳槽的时候会非常积极地争取更高级别,比如“我想去另一家公司,我想升一级”之类的。这样做有很多弊端。

 

Ryan:接下来我想问一下是什么让你在 Meta 晋升为资深工程师(E6)。我很好奇你当时的职位,以及是什么推动你晋升到这个更高层级的领导岗位。

 

Boris:当时的情况是,Facebook 推出了群组聊天功能,并且有一个团队负责开发。在加入 Facebook 之前,我写过很多 JavaScript,但在 Facebook 内部,我之前从未真正写过 JavaScript,因为当时主要用 PHP。我真的很想写 JavaScript

 

我们当时专门为 Facebook 群组开发了一个网页界面。很多人使用网页版而不是手机版,因为群组管理员在电脑上用键盘操作起来更方便。但当时这个网站真的很糟糕,它是一个静态网站,完全用 PHP 编写,只是在不同的地方零散地注入了一些 JavaScript 代码,结果导致了各种不一致的状态和问题,用户体验很差。

 

我当时想用 JavaScript 重写整个界面,但遭到了公司内部的强烈反对,主要原因是我们已有的基础设施还没准备好。幸运的是,与此同时,Comet 项目启动了,该项目旨在重写 facebook.com 的桌面版。

 

当时有很多核心成员在做这个项目,我真的很想参与。我主动联系他们,询问我能如何帮忙,并提议先在 Facebook 群组里进行测试和探索。我几乎是没问任何人就直接开始做了。

 

后来,我跟 Facebook 群组部门的领导们说:“嘿,Comet 项目马上就要全面推行了。这会是一项艰巨的工作。但我们可以提前做好准备,为所有其他团队树立一个迁移标准,并与其他团队建立联系。”我仍然遇到了阻力,比如他们说“你不能安排 20 个工程师来做这件事”。经过多次讨论和讨价还价,我们最终组建了大约 12 名工程师的团队,因为这是一个相当大的迁移项目,大约需要一年时间。

 

“群组”是 Facebook 所有产品中规模最大的一个,这有点出乎意料。这次迁移很成功。除了与这个基础架构团队建立联系和友谊之外,有趣的是,我们因此有机会影响 Comet 项目的发展方向。对于基础设施项目而言,产品团队通常无法左右项目方向,他们更像是客户。但在这个项目中,由于我们早期深度参与,我们创建了许多抽象概念,后来被其他基于 Comet 进行开发的团队所使用。

 

举一个具体的例子,比如“中继变更”。你需要发送 API 请求,并且需要某种状态一致性。之前存在一个 bug:假设有一个按钮,每次按下它都会发送一个 POST 请求。为了良好的用户体验,你希望在按下按钮后,按钮的状态立刻切换,这需要使用乐观更新。当网络请求返回时,你还需要更新本地缓存以确保一致性。但如果你连续快速点击按钮,响应可能会乱序到达,最终得到的状态可能与用户界面上显示的状态不同。

 

我写了一个系统来排队处理这些变更,这样虽然保证了一致性,但牺牲了一点即时性。在当时这是一个合理的权衡,这个方案最终被广泛采用。我就是在这个过程中认识了 Joseph 和 Relay 团队里负责数据存储的其他人。这段经历真的很有趣。每当我看到工程师深入钻研,努力弄明白复杂系统到底发生了什么时,我都很欣赏。产品工程师并不意味着你不能构建基础设施,基础设施工程师也不意味着你不能和用户交流。对技术栈的其他部分保持好奇心就好。

 

成功搞定大项目后,才有更多话语权

 

Ryan:当然。你抢先一步进行 Comet 迁移和大规模的 JavaScript 重写,正如你提到的,这实际上让你拥有了更大的影响力和话语权。你所说的机会,是指构建这些对所有使用新平台的人都至关重要的基础产品架构吗?

 

Boris:是的,这就是一个例子。另一个例子是,Comet 的质量比之前的版本高得多,因为它是一个单页 Web 应用,所以感觉更加流畅和完善。但我们当时还没有完全弄清楚“产品层面的质量”究竟意味着什么。我写了很多笔记试图定义它,也做了很多演讲,向其他团队的成员讲解我们对质量的理解,并就此展开讨论,共同塑造标准。

 

Ryan:您提到迁移到 Comet 需要大量人手。我很想知道,如果现在有了 Claude Code、Codex 等新的 AI 编码工具,情况会是怎样的。以您现在对 Claude Code 的了解,如果您负责评估这项工作,您认为现在需要多少工程师才能完成原本需要 12 名工程师花费一年才能完成的工作?

 

Boris:为了迁移 Facebook 群组,最初是 12 位工程师,但最后可能动用了 20 到 30 位工程师,持续了大约两年时间,最终变成了一个相当大的项目。现在来看,可能只需要 5 位工程师,耗时六个月左右就够了

 

Ryan:也就是说,只需要四分之一的时间,以及不到一半的工程师?

 

Boris:是的,因为现在你可以让 AI 并行工作。你让它运行几个小时,它就能生成一个可用的 PR。你甚至可以给它装上 Puppeteer 之类的工具,让它能看到 UI 并进行视觉调整。大概就是这样。现在,从编码的角度来看,环境已经截然不同了,因为模型更新迭代太快了。如果你三个月或六个月后再问我这个问题,我的答案肯定会完全不同。六个月后,答案可能就变成了:这实际上只需要一个工程师就能完成。现在的变化实在太快了,很难做出准确的估算,也很难预测它们未来会如何演变。

 

Ryan:在你职业生涯的这个阶段,你曾提到过一件事,也许是半开玩笑地说,那时你学会了在向副总裁评审提案时,总是提出三个选项。因为 80%的情况下他们只会选择中间的那个。你这么做的想法是什么?

 

Boris:这话虽然有点讽刺,但或许当时在 Meta 公司那种特定环境下有点道理。那些远离一线具体工作的决策者,他们想知道你是否认真研究过各种方案和权衡利弊,是否真的做了充分的工作。但同时,他们也想以某种方式参与决策。提供一个“折中”选项,对他们来说比较容易理解和接受。我这么说确实带有讽刺意味,因为并非所有领导者都这样。很多领导者会亲自深入参与决策,他们或多或少信任自己的团队。管理风格有很多种。我记得当时我们有一位技术水平可能不那么深入细节的领导,而这种方法算是帮助她进行决策的一种沟通方式。

 

Ryan:在你职业生涯的这个阶段,你与高层管理人员的接触最为密切。你提到你曾向一位高级总监汇报工作,并且参与了很多重要的项目规划讨论。我很好奇,向这样一位资深人士汇报工作,对你后续的成长产生了哪些影响?

 

Boris:是的,我觉得这很大程度上取决于工程师个人和公司文化。比如,我现在在 Anthropic,我觉得在 Anthropic,你向哪个层级汇报并不重要。公司里一些最资深的员工也是向部门经理汇报的。很多部门经理本身就是前首席技术官或非常资深的人士,所以实际上这并不构成障碍。

 

我认为向高级别汇报带来的压力,在某种程度上是 Meta 公司特有的文化现象。我觉得这里存在两种情况。一是,在 Meta,你需要非常主动地找到自己的发展方向和上升路径。有些机会你可以自己发现,有些则需要你的经理或技术领导帮你识别和引荐。

 

Meta 的 PSC(绩效评估)流程出了名的严苛,你必须不断地强调和证明你的影响力。而“职责范围”是造成这种严苛体验的最大因素。如果你有足够大的职责范围,并且执行得当,就能产生显著的影响力。这就是秘诀。

 

我觉得在 Meta,另一个特点是大家都没有很花哨的头衔。即使是最资深的工程师,头衔也只是“软件工程师”,我非常喜欢这一点。贝尔实验室的技术人员也是如此,Anthropic 也是如此,但我们在这里更进一步:所有人的头衔都是“技术人员”。不管你是工程师、项目经理还是设计师,头衔都一样。我其实很喜欢这样,因为这样一来,你就可以跳出自己被默认设定的职责范围,去做那些你认为正确和必要的事情,而不用过分在意别人期望你做什么。我认为这种文化正是促成这种灵活性的原因。

 

Ryan:我看到了不设复杂头衔的很多好处。但我也能想到一种情况,也许这只适用于大公司:当你联系公司里的某个人,说“嘿,我想参与这个合作”,如果你的头衔是“总监”之类的,这就能让他们更容易理解你的层级、影响力和协作方式。如果你是设计师或其他职位,在 Anthropic 规模扩大了一些的现在,你感受到这一点了吗?也许因为大家现在都认识你,所以你没怎么感受到。

 

Boris:是的,这绝对是一个潜在的缺点。但我认为优点大于缺点。那就是你必须努力争取,用实力和贡献赢得尊重。我觉得这条原则无论在哪家公司都适用。仅仅因为你以前做过一件很棒的事,并不意味着你在新的环境里就理应自动获得权力和尊重。当然,每个人都应该得到基本尊重;但这不意味着你在一家新公司、一个新项目中就理应拥有决策权。即使是那些一开始就拥有“经理”头衔的人,也需要努力争取团队的信任。在某种程度上,拥有经理头衔反而可能让赢得这种信任变得更难。作为独立贡献者,无论如何你都必须用行动证明自己。我认为,正是因为没有那些预设的、等级森严的头衔,才使得这一切变得稍微容易一些,更注重实际贡献。

 

如何从技术人转型为高管

 

Ryan:在你职业生涯的这个阶段,你逐渐转型为技术主管或高级技术主管,我记得你讲过一些为数百名工程师制定工作计划的故事。你是怎么做到的?如果工作量如此庞大,而你又只有一个人,你是如何向领导层提出如此大规模的工作计划请求的?

 

Boris:是的,那段时间真是太疯狂了。我当时和蒂娜·萨奇曼共事很多,她现在在微软,但当时是我的经理。然后是我的上级伊芙。当时公司决定对 Facebook 群组投入更多资源。我刚加入的时候,群组部门大概只有 150 到 200 人,等我离开去 Instagram 的时候,好像已经有 600 到 800 人了。扎克伯格一直觉得 Facebook 应用的核心应该是社群,他希望我们加快速度,把这个想法变成现实。

 

作为高管,最重要的就是让合适的人负责决策,然后给他们提供资源。在 Meta,资源主要就是工程师。我们向扎克伯格推介了这个名为“社区即新组织”的内部项目。他为此投入了一大批人手,我们只需要弄清楚这些人具体要做什么。对他来说,如果事情很重要,就得投入大量人力。事后看来,我会采取不同的做法,大幅减少初期投入的人员,因为真正重要的是解决用户的问题,打造出色的产品,这必须自下而上地进行,需要随着新产品线找到市场契合点而逐步推进,不能一口气做完所有事情。

 

但当时,我们必须先把所有事情都规划好。有好几个星期,我都要写一份庞大的规划文档,内容大致是:“好,我们要安排 30 个工程师负责 A 项目。这里有三个技术方案,我们选方案二。下一个 B 项目,我们要安排 20 个工程师。这里有三个方案,我们选方案一。”就这样一遍又一遍地重复,才能确保这个庞大的项目计划不是完全异想天开。我们进行了一些基础的技术范围界定,大致估算了每个子项目需要的工程师人数。

 

其中有些事情很有意思。我记得我们曾经尝试合并 Facebook 群组和主页的数据模型。那真是一次非常棘手的迁移。要彻底实现这一点,需要很多年时间,可能还需要数百名工程师,因为必须跨数据模型、产品层、完整性系统和广告系统进行操作。当时,Yosef Carver 刚刚加入;我记得他之前在 Profile 或 Events 部门工作,这两个部门与 Groups 部门合作推进这项工作。他当时正在研究这个问题,但还在犹豫不决,无法就数据模型做出最终决定。

 

于是我召集了一群人,说:“好了,公司所有相关的技术主管都来了,我们今天花三个小时,像玩游戏一样,来讨论一下架构设计。”我把大家分成两队,好像是蓝队和绿队(记不清了)。我们给每个人布置了同一个问题:如何合并这些数据模型,并给出了具体的要求。每个人都有三个小时的时间在白板上设计方案。

 

最酷的是,一开始我们都觉得这个问题棘手,不知道该怎么做。但最后,我们两队得到的两个方案竟然有 80%的相似度!我们可以采取的行动变得非常明确,而那 20%的差异也清楚地揭示了风险所在。我们可以通过一些技术性操作来预先承担一部分风险,但我们也清楚地知道可以立即开始执行哪些部分。

 

Ryan:是啊,我觉得这个形式很有意思:就像一个技术设计竞赛,所有资深工程师都参与其中,分成几个小组,在不同房间里同步进行设计。我以前从没听说过这种形式。你当初在公司内部提出这个设计竞赛的想法时,大家是觉得很兴奋,还是觉得这有点异想天开?

 

Boris:是有点非常规。这种事,你只能硬着头皮去做,靠行动推动。我直接跟所有相关的人说:“嘿,我们要这么做了”,然后就把会议日期记在了每个人的日历上。感觉挺有意思的;作为工程师,你肯定也想参与这种创造性的解决问题的过程。但有时候你需要漫长的过程来达成共识,有时候你则需要快速行动来打破僵局

 

在这种情况下,由于技术方向不明朗,采取行动至关重要。但同时,我自己也不知道确切的最佳路径,所以我们必须召集所有关键人员,通过这种高强度、高协作的方式快速达成共识。作为技术领导者,你总是需要在“推动共识”和“果断行动”这两件事之间寻求平衡。

 

Ryan:有了那次为数百名工程师规划项目的经历,你对那些需要快速进行项目范围界定的技术主管有什么建议吗?有什么对你来说行之有效的方法或原则?

 

Boris:我觉得我看到的最大问题是人们花费的时间太长,而且过于纠结细节。细节总是无穷无尽的。最好从宏观层面入手。大多数技术范围界定都可以在 30 分钟内完成一个非常粗略的版本。

 

如果你不了解所涉及的系统,现在你甚至可以让 AI 来帮忙。你只需要在代码库中运行一个查询,或者直接问 AI:“要实现 X 功能,会涉及代码库中的哪些系统和模块?”它实际上可以帮你快速梳理出依赖关系。这真是个不可思议的改变。我以前做这些事情的时候,绝对想不到人工智能现在能帮我做到这些。

 

但回到一般性原则,我过去的建议是:设定严格的时间限制。用于初步范围界定的会议最多花 30 分钟。如果需要深入研究代码,最多几个小时。一定要联系专家,并列出所有需要咨询的专家名单。和他们所有人交流。但不要只是泛泛地征求他们的意见。给他们一个具体的假设或初步设计方案,这样他们才能真正给你有建设性的反馈,你才能以此为依据进行迭代和完善。

 

Ryan:继续你的职业经历。你晋升到高级职位的关键,似乎和 Facebook 的“公共群组”项目有关。我很想了解这背后的故事,以及其中发生了什么有趣的事?

 

Boris:是的。“公共群组”项目源于我们想让 Facebook 群组更开放。我们当时想做一个看似简单、但实际非常复杂的改动:让用户无需加入,就能查看和评论公开群组的内容。

 

这听起来像改一行代码,但实现起来异常困难。因为它触及了核心的数据模型问题:在数据库里,一个发表评论但未“加入”的用户,到底算不算“群组成员”?这引发了我们内部激烈的技术讨论。

 

过去的“加入”需要管理员批准,是一种信任投票。现在对于公开群组,行为变成了“关注”。那么,“关注”和“加入”在数据层面应该是同一回事吗?当时公司里一位资深的元老级工程师鲍勃,强烈认为这必须是两件不同的事,并要求进行大规模的数据迁移来区分它们。

 

这还引发了连锁反应:如果任何人都能评论,垃圾信息怎么办?我通过一个简单的蒙特卡罗模拟,展示了潜在的垃圾信息风险,最终成功说服了公司的诚信团队介入,帮助调整评论排名算法来应对。

 

为了完成数据迁移等所有工作,我们组建了一个大团队。当时我和其他几位资深工程师同级,都需要我来协调指导,这让我一度感到有些“冒名顶替”。但最终,正是因为我推翻了之前鲍勃关于数据迁移的决定,才促成了我后来的晋升。

 

我经过审核发现,最初的“成员”字段其实完全可以同时表示“关注者”和“群组成员”,强制区分只会让后续所有开发变得复杂。我敦促负责的工程师撤销了那次迁移。这个正确的技术判断,反而让鲍勃更认可我作为技术领导的能力,因为我能基于事实对资深人士的决定提出异议。

 

Ryan:你和高级技术主管之间存在严重技术分歧,但结果反而加强了关系。对于如何处理这类分歧而不损害关系,你有什么建议?

 

要敢于挑战权威

 

Boris:我认为核心是赢得信任。在你拥有足够的技术信任之前,很难去挑战权威。一开始,可以更多地倾听、执行,表现出尊重和合作意愿。同时,你必须通过实际行动积累扎实的技术判断力。在赢得信任后,你基于事实和专业提出的异议,才更容易被接受。

 

Ryan:关于“冒名顶替综合症”,以及领导那些和你同样优秀的工程师,你有什么建议?

 

Boris:别想太多。其实没人真正知道自己在每个新层面上具体该做什么,大家都在摸索。这种感觉会随着时间慢慢消失。某种程度上,始终保持一点点“冒名顶替”感是健康的,那说明你还在努力突破舒适区。

 

Ryan:在你职业生涯的这个阶段,你更像技术主管,编码减少。你曾提到,在 Meta,有时其他职能(如产品经理)支持不足,你认为这是让工程师更多关注产品、甚至参与产品管理的机会。你如何决定何时该自己顶上,而不是反复要求更多支持?

 

Boris:关键在于理解利弊和背景。你需要从决策者的角度思考:他们关心什么?手头有哪些项目?做这件事的代价是什么?是否能帮他们成功?有些组织可能确实资源紧张,或认为你的项目优先级不够。有些组织则可能资源充沛。了解你所在的环境和决策者的处境,才能判断是应该自己主动补位,还是能够争取到资源。

 

Ryan:你将自己的成功很大程度上归功于“副业项目”。你对工程师如何寻找这样的机会有什么建议?

 

Boris:我的很多想法来源于日常工作中那些重复、繁琐的部分。工程师的超能力就是自动化。我养成了一个习惯:在代码审查中,如果我多次评论同一类问题,我就会写一条规则来自动化检查它。很快,我几乎自动化了所有代码审查。

 

这些“副业”往往就是去改进那些拖慢日常开发速度的基础设施或工具。这不仅能解放自己,也能惠及整个团队。一个核心原则是:如果你遇到了某个问题,很可能其他人也遇到了。为自己打造解决方案,往往就是为很多人打造解决方案

 

为何从 Meta 转向 Anthropic

 

Ryan:你从 Meta 离职加入 Anthropic,当时是怎么做出这个决定的?

 

Boris:我第一次用到 ChatGPT,是它刚推出不久的时候。当时我在日本,一个小地方,几乎没有人能和我讨论技术。我每天刷 Hacker News,用到 ChatGPT 后的第一反应是:这东西太不可思议了。

 

现在回头看我们已经习以为常,但当时的大模型给我的感觉,更像是一种“新生命”。它不仅是一项技术,而是一种可以被培育、被引导的存在。我本人很喜欢科幻小说,尤其是硬科幻,所以当我意识到这类模型意味着什么时,心里只有一个想法:我一定要参与其中。

 

后来我去了解哪些实验室在做这件事,也和一些在不同研究机构工作的朋友聊过。第一次和 Anthropic 的创始团队吃饭时,我随口提到了一本科幻小说,结果发现桌上几乎所有人都读过,还能继续讨论别的作品。那一刻我意识到,这是一个真正认真思考“这些技术会把世界带向哪里”的地方。

 

人工智能正在改变社会,而且是从工程领域开始,逐步扩散到各个层面。我也很清楚,这项技术存在很多潜在风险,甚至可能走向非常危险的方向。对我来说,加入 Anthropic 几乎是顺理成章的选择——如果我能做点什么,那就是站在一个真正把“安全”和“长期影响”当回事的地方。

在 Meta,安全往往被当成一种负担,是和产品对立的事情。但在 Anthropic 完全不同。我们在安全和对齐研究上投入了大量算力和人力,甚至因为不确定模型是否足够安全而推迟发布。随着模型能力提升,风险也在快速上升,这已经不是科幻,而是现实问题。我很庆幸自己能参与其中。

 

Ryan:加入 Anthropic 之后,你感受到的工程文化和以前最大的不同是什么?

 

Boris:有两点特别明显。第一,公司虽然已经不小了,但仍然保留着创业公司的“常识感”。很多事情不需要复杂的流程去推动,大家天然会做正确的决定。这是大公司最容易丢失的东西。

 

第二,对我个人来说,最重要的是使命感。它让我每天都愿意来上班,甚至周末也愿意写代码,不是因为 deadline,而是因为我想这么做。我在 Facebook 群组项目里感受过类似的氛围,但在 Anthropic,这种感觉更强烈,也更一致。

 

Claude Code 为什么能跑出来

Ryan:你是 Claude Code 的核心推动者之一。当初市面上也有不少类似工具,Claude Code 真正不同的地方在哪里?

 

Boris:一开始,大家对“AI 编程”的理解非常狭窄,基本等同于自动补全。即便有一些智能体的概念,也更多是问答工具,而不是能真正参与编程。

 

坦白说,在很长一段时间里,Claude Code 本身也并不好用。即便在内部,我可能只用它写了不到 10% 的代码。关键在于,我的主管一直提醒我:不要按“现在的模型能力”来设计产品,而要按“六个月后的模型能力”来设计。

 

后来 Sonnet 和 Opus 4 发布后,一切发生了变化。短短几个月,我自己有一半以上的代码都交给 Claude Code 来写。现在在 Anthropic,很多团队 80% 到 90% 的代码都是用 Claude Code 生成的。公司规模虽然扩大了,但工程师的整体生产力反而显著提升。

 

Ryan:有人担心模型生成大量代码,但质量不稳定、问题隐蔽,你怎么看?

 

Boris:AI 编程和任何工具一样,是需要学习如何使用的。我们内部的原则很简单:不管代码是人写的还是模型生成的,标准完全一致。代码不好,就不合并。

 

不同场景需要不同方式。原型、临时代码,可以更“感觉驱动”;核心代码,就必须逐行推敲。大多数时候,我是和模型一起写代码:先制定计划,再让模型生成,再不断修改、清理。某些关键部分,我仍然坚持手写。

 

现在的模型编码能力当然还不完美,但已经是“史上最差的一代”了。一年前还只是自动补全,现在已经是完全不同的世界。

 

Ryan:除了写代码,你觉得 Claude Code 还能用在哪些地方?

 

Boris:我们公司里的数据科学家、分析师,甚至销售团队都在用它。有人用它写 SQL、跑分析、搭数据管道;销售团队把它接入 Salesforce,直接干活。这完全超出了我们最初的设计预期。

 

Ryan:你怎么看 Claude Code 和 Codex、OpenAI 之间的竞争?

 

Boris:说实话,我几乎不看其他产品。过度关注竞争对手,很容易让团队迷失方向。我们只专注一件事:解决我们自己、Anthropic 研究人员以及用户真正遇到的问题。

 

Ryan:你不是计算机科班出身,这对你有影响吗?

 

Boris:几乎没有。我学的是经济学,后来辍学创业。编程是一项高度实践性的技能,最重要的是动手做、做出产品。理论当然有价值,但对我个人来说,从来不是关键。

 

Ryan:你效率很高,有什么秘诀?

 

Boris:现在我的答案只有一个:学会用 Claude Code,而且是同时用多个。你不再是亲自写每一行代码,而是在做统筹、调度和判断。这就是工程的未来。

 

Ryan:你觉得工程师会不会越来越像管理者?

 

Boris:某种程度上是的。但我依然很享受安静地写代码。现在我每天早上都会启动几个 Claude Code 代理,让它们先跑起来,等我到电脑前再检查、合并或修改。

 

这听起来很疯狂,但它确实有效。甚至一些多年不写代码的管理者,现在也能重新参与进来。我们熟悉的“写代码”这件事,正在发生根本性的变化,而且正在变得对更多人开放。

 

参考链接:

https://www.youtube.com/watch?v=AmdLVWMdjOk

欢迎收看本期《派评》。你可以通过文章目录快速跳转到你感兴趣的内容。如果发现了其它感兴趣的 App 或者关注的话题,也欢迎在评论区和我们讨论。


Focast:高保真环境音专注应用

  • 平台:macOS
  • 关键词:白噪声、专注计时

@ElijahLee:Focast 是专为 Mac 平台开发的专注应用,提供了丰富的高保真自然环境音,并结合专注计时功能, 帮助你在学习、工作或阅读时进入专注状态。

Focast 的亮点是提供了 90 多款高质量的环境音,包括雨声、海浪、森林、火堆、鸟鸣等自然音效。除了常见的声音外,应用竟然还有很多独特的日常氛围音,比如鸭嘎嘎子叫、搅拌鸡蛋液的声音、在厚厚的雪地步行的声音。所有声音都由声音艺术家现场录制,并可以无断点持续循环,让你在聆听环境音时快速沉浸并持续专注。

与一般的白噪音应用不同,Focast 的另一个特色是混音(Mix)功能。对于自带的环境音,应用提供了两种模式。Solo Mode 只能选取一中环境音播放;而 Mix Mode 可以叠加多个音轨同时播放环境音,比如同时选择雨林(雨滴打落在树叶的声音)、鸟鸣(远处鸟的鸣叫)和后院(夜晚虫鸣鸟叫)。基于环境音的组合,我们可以搭配出丰富的现实音效,还原真实世界中的场景。Mix Mode 下, 对于中意的搭配组合,我们还可以保存混音,便于以后一键播放。

除了内置环境音的混音之外,Focast 还支持与 Apple Music、 Spotify、或 YouTube 一起播放,应用会将环境音叠加在背后播放,并可以独立控制环境音的音量。

在 Focast 我们可以自由地创建专注与休息时间段,应用默认提供 10、25、40、60 分钟的计时器,并且支持自定义设定,使用快捷键也可以快速启动。启动专注计时后, 应用在菜单栏的图标会显示可视化倒计时,帮助你更好地查看专注时段。在专注计时结束时,Focast 会发出一声温柔的提示音作为结束,应用也支持我们修改这个音效,非常贴心。

专注日历视图功能,可以让你回顾专注天数与连胜记录,如果你非常需要养成专注习惯,使用这个记录来保持连胜会非常有用。应用还支持 iCloud 同步,对于声音设置、计时器、统计数据等,都可以通过 iCloud 在设备间同步。

你可以可以在 App Store 免费下载 Focast,免费版提供了非常有限的基础功能。付费订阅后可以全部环境音、自定义混音、自定义计时器等。价格为每年 38 元或买断 88 元。对于按年订阅,应用提供了长达 14 天的有效期,如果你感兴趣可以在两周时间内充分体验后再决定。

 


三星浏览器 Windows Beta 更新:现已解除区域限制

  • 平台:Windows
  • 关键词:三星、浏览器

@大大大K:三星浏览器在此之前已经上线过 Windows 平台,但后来因多种原因不再提供安装。不过前段时间,三星突然又重新推出了 Windows Beta 版,而且现在任何区域的用户都可以通过指定链接下载安装(虽然页面中还是显示仅限韩国和美国)。如果你正在使用国际版的三星浏览器 Android 版,也会在浏览器首页看到链接推送。

在 UI 方面。新版客户端和两年前的版本差别不大,依然保留了极具特色的侧边栏功能。其中的「已同步设备」功能可以同步手机端浏览器的快速启动页,并以移动设备模式浏览网页内容;日历功能则直接与三星账户中的日历事项同步,并支持添加 Google 账号显示 Google 日历。如果有需要,可以在侧边栏下方添加新的网址。

快速启动页做了小幅升级,支持更换背景以及添加设备同步、隐私报告、天气时钟等小组建。值得一提的是,设备同步功能可以将手机版浏览器的标签页在这里显示,实际测试下来,手机端新开标签页同步速度非常快,但关闭标签页之后的同步会比较滞后。

Windows Beta 版中的「浏览助手」功能包含了摘要提取和翻译功能,其中摘要提取来自于 Galaxy AI。该功能的使用效果与手机版相同,可以由 AI 总结网页内容供你参考,不过可能是由于网络或其他限制,连接云端 AI 时会报错,有条件的用户可以自行测试。

翻译功能应该是来自于 Google 翻译,同时浏览器支持原文和译文分屏对照,学术用户群体使用起来会更加方便。

除此之外,三星浏览器手机版支持将登录信息保存在 Samsung Pass 中(包括国行用户),Windows Beta 版也支持该功能,但要求电脑中安装有 Samsung Pass 客户。但 Samsung Pass 客户端有机型限制,所以目前处于不可用状态。不过考虑到 Windows Beta 采用了 Chromium 136 内核,支持 Chrome 插件,还是建议大家使用专业的密码管理器和浏览器插件使用。

如果你是三星用户,想要拥有更完整的 Galaxy Ecosystem 体验,可以前往官方网站体验该 Beta 版。浏览器强制安装于系统盘,并且过程中会同步安装三星账户和三星智能服务组件并创建开始菜单项目,大家记得留出足够的空间。


Quiche Browser:自定义布局浏览器

  • 平台:iOS
  • 关键词:浏览器

@Snow:Quiche Browser 是 iOS 平台上一款第三方浏览器应用,在这个全员「卷 AI」的时代,它并没有引入先进的对话式引擎,也没有借助算法智能排列标签优先级,而是将交互自主权交还给用户,让用户可以从丰富的功能按键中自由排列组合,打造自己理想中的浏览器。

浏览器底部的 Toolbar 是 Quiche Browser 自由度最高的一个区域,但应用并没有丢给你「一张白纸」任意发挥,而是在设置中提供了 16 种布局预设,你可以根据自己的使用习惯选择其一,再在预设之上进行微调。

应用提供了超 40 个交互按键,从高频使用的前进、后退、刷新、新建标签页等,到一般配合快捷键使用的缩放、查找、快速定位等均有覆盖,你可以自由选择按键,并在预设的框架里布局使用。以常规的双行布局为例,第一行除地址栏外最多设置 4 个按键,第二行最多设置 7 个按键,如果你还有高频使用的功能,则可以将其安置在更多菜单中。

Quiche Browser 就是借助这种「有限的自由」,让应用可以在满足用户个性化需求的同时依旧保持美观。

Quiche Browser 还可以对地址栏的展现进行微调,例如在地址栏中选择性展现域名、完整地址、页面标题以及网站图标,调整文本左对齐或居中对齐,展现阅读时长等。在交互上,你则可以为短按和长按地址栏设置触发不同动作,进一步提升交互效率。

除了页面交互外,Quiche Browser 还提供了一些功能性补充,来弥补其不支持第三方扩展的缺憾。应用默认开启广告拦截功能,并内置了三套拦截规则,你可以按需进行开关,不过目前暂不支持添加自定义规则。

应用还支持为所有网页强制开启深色模式,如果你订阅了 Quiche Plus 服务,则还支持自选主题配色。应用还支持对默认搜索引擎、隐私模式、后台刷新、用户 UA 等多个功能项按需调整,更详细的应用介绍你可以点击此处了解。

应用包含一项订阅式内购,你可以按 22 元 / 月 或 198 元 / 年价格订阅,付费后可以解锁多主题深色模式、单手操作模式,以及更多的按键样式和应用图标,鉴于以上功能并不会严重影响浏览器主要功能,建议使用一段时间再按需付费。

你可以在 App Store 上免费下载 Quiche Browser。

 


Activas:本地 AI 健康分析助手

  • 平台:iOS / iPadOS
  • 关键词:健康追踪、数据分析

前段时间,OpenAI 推出了 ChatGPT Health 功能,在 iOS 客户端上甚至可以直接导入健康 App 中的数据进行分析和建议。不知道此举会不会让 Apple 觉得「后背一凉」,毕竟 Apple 自己画的增强版健康助手的大饼迟迟没有实现。

如果你已经等不及那一天的到来,也不想把自己的数据泄漏给 OpenAI,那么不妨试试 Activas 这款应用,它采用了 Apple 的 on device ML 接口来进行数据分析,可以基于我们的健康数据给出对应的建议。

打开 Activas 后,应用会申请获得 Apple Health 的数据权限,进行简单的配置后就可以进入 Dashboard 了。在这里,我们可以看到应用对我们的身体情况进行一个综合打分,点击进入详情页还可以看到评分变化的具体原因。

在 Insight 模块,AI 可以当前的健康数据给出一个总结。再往下,可以看到 Activity、Nutrition、Sleep、Vitals、Body Measurements 等不同领域的数据展示。点击任意一个模块,就可以进入 Activas AI 标签页,在这里 AI 会根据入口的不同给出相应的分析和建议。

不过,这个健康 Chatbot 只能基于预设的问题进行问答,并不能自由地输入自己想问的问题,这方面显得有点局限。

总的来说,这款应用的功能非常简单,更多的是基于 Apple 设备端 AI 能力的一次技术展示。这款应用可以在 App Store (外区) 免费下载使用,没有内购选项;其中 Insights 以及对话功能需要启用 Apple Intelligence,数据展示、趋势图表等基础功能则无限制。

 


什么时辰:结合日历、万年历和黄历的趣味时间应用

  • 平台:iOS / iPadOS / macOS / watchOS
  • 关键词:日历、万年历

@化学心情下2:作为一个相当传统的中国人,日历的作用不仅仅是知道今天是周几、几月几日、需要安排哪些日程,还有看节气、翻老黄历等特有的功能,虽然看上去有些「迷信」但却也是中国传统民俗的一部分。但就从使用上,我见到的更多是独立的黄历、万年历等 app,而将日历、万年历、老黄历等结合在一款应用上的则比较少见,《什么时辰》就是近期我找到的一款设计优美的趣味时间类应用。

什么时辰,从应用名就不难看出,这款应用强调的是中国传统计时方式。打开应用首页,就可以看到时钟以及对应的时辰,还有农历上对应的月份和日期,并且应用还进行的标注的每一个时辰的拼音注脚念法,比如当下是「未时」,就在「未」上加注了拼音 Wei。

以 Mac 版为例,通过顶部的 Tab 页,你可以切换到不同的日历类型中,比如万年历部分除了可以以月的形式查看日期之外,还可以看到对应的农历信息、黄历的今日宜忌以及近期的 24 节气和节假日信息,切换到日历事件则可以读取 macOS / iOS 的系统日历事件信息。

切换到老黄历则会显示今日宜忌、时辰宜忌、今日胎神、吉神宜趋以及凶神宜忌等信息,对于不是很了解里面内容的朋友,还可以点击右上角的帮助按钮来获得解析信息。

什么时辰还提供了两项我认为相当实用的小功能:一个是节日推送提醒功能,除了可以定时收到当日的节日提醒,还可以选择开启指定类型的节日,目前可以选择的节日类型包括法定节假日、传统节日、节气、国内节日、国际节日、道教节日、佛教节日、七十二侯、三伏日、数九日。

另外一个就是小组件部分,现在 macOS 支持将小组件添加到桌面,而恰好什么时辰提供了种类繁多的小组件,比如我个人喜欢就非常喜欢时钟加上时辰的这种小组件,这样可以看一眼桌面就知晓当下的时间,比起是不是瞄向右上角看时间要更方便一些。

总的来说,无论是功能还是设计上,什么时辰将多种形式的日历形式进行巧妙融合,让我们通过一款应用就可以查询日历、万年历、老黄历的信息。如果你希望找一个设计优雅功能全面的传统时间类的应用,不妨体验下这款 app,你可以在 App Store 下载该应用,应用价格为 8 元。

 


App 速报

  • Apple 宣布将于 1 月 29 日推出 Apple Creator Studio 订阅服务,包含 Apple 旗下 Mac 和 iPad 平台的各个专业创作 app,其中 Pixelmator Pro 也将推出适配 iPad 的版本,并会为 iWork 办公套件及无边记 app (稍晚) 推出高级模版和订阅内容。该服务订阅价格为 38 元 / 月、380 元 / 年。
  • Apple 与 Google 宣布将由 Gemini 为新版 Siri 提供 AI 技术支持。


> 下载 少数派 2.0 客户端、关注 少数派公众号,解锁全新阅读体验 📰

> 实用、好用的 正版软件,少数派为你呈现 🚀

    全程猛蹬 Gemini 3 pro,没额度了就继续蹬 Gemini 3 Flash。

    做了一些改动:

    • 移除了百度地图 SDK,改用开源的 OpenStreetMap 实现
    • 删减了功能,只保留了位置模拟
    • 增加暗黑模式支持
    • 按照 Material Design 3 设计风格,优化了整体界面



    📌 转载信息
    原作者:
    nekonene
    转载时间:
    2026/1/19 19:20:31

    稳定的 Claude Code 中转站上线了

    https://hongmacc.com

    上周发了个帖子,没想到热度这么高,考虑到还有些小伙伴没有看到,我们新开个帖子,活动继续。

    之前的帖子 https://www.v2ex.com/t/1185599?p=9#reply821

    我们不搞积分、不搞倍率,真 MAX20 号池

    我们是 Claude Code 的重度用户,起初一直购买官方账号。但高昂的费用、跑路的平台,频繁的封号实在让人头大。为了对抗风控,我们尝试了各种办法,结果账号还是活不长久…… 后来我们转向中转平台,买过很多家的会员,本想省钱省事,结果却事与愿违: 频繁报错,一天挂 3 次,次次不一样的理由,把用户当猴耍

    模型降级、后台偷偷加倍率、一天下来啥也没干直接耗完四五十刀… 不仅没省下钱,还浪费了大量时间。名为“中转”实为“骗局”!!

    终于,我们忍无可忍,决定自己下场做中转。 经过几个月的试运行,现在已经可以非常稳定地给大家提服务了。 希望大家都能 opus 自由

    为庆祝新站上线,我们决定给大家送福利了:

    福利一:新用户注册,留言就送$10;

    在评论区留下你在 hongmacc 账户的“身份 ID”; (控制台-账户设置-复制身份 ID )

    另外,还可在平台内以 9.9 元购买$30 体验额度卡一次

    福利二:评论区抽奖送月卡

    奖品:每天抽取价值¥288 的月卡一张

    结束时间:2026 年 01 月 15 日 - 2026 年 01 月 28 日

    抽奖规则:回复本主题即可。将使用 v2 网友开发的 “V2ex 等概率抽奖程序”,从回复楼层中随机抽取。(会做去重复处理,刷楼无效)

    上个帖子的小伙伴和本贴的小伙伴一起参与月卡抽奖

    月卡抽奖记录:

    #1 月 15 日抽奖
    恭喜上个帖子 379 楼小伙伴 autwind 中奖
    获得价值 288 月的月卡一份

    #1 月 16 日抽奖
    恭喜上个帖子 642 楼的兄弟 enchong 中奖了
    获得价值 288 月的月卡一份

    • 切换 Tab 感觉有闪动,而且有点延迟,很硬
    • 搜索不直观,没排序,添加标签页按钮奇怪
    • Group 没 Arc Tabs 直观,而且竟然不能移动!

    原生的竟然没我插件体验好,"草台班子" 🐶

    不信可以对比下: https://chromewebstore.google.com/detail/fmdcddgkjceilbjnendchimddgbmnjdo

    当然 Arc Tabs 目前没有 Compact 效果,可能有的人喜欢这种比较 "紧凑" 的效果,后面可以加个选项 🤧

    书接上回

    Starflow 基本可用后,我想到能否添加浏览器插件来嵌入 Github 页面来方便归类添加呢,并且项目没有使用 i18n,故有了后续的这些更新

    Starflow 是个开源可自托管的 Github Star 管理解决方案,具体可以参看我之前发的帖子:

    在线预览体验:Starflow

    Warning

    Starflow 默认会读取私库!介意请勿登录在线预览页面!自行部署即可!

    GitHub 仓库地址:

    页面预览:

    🌙 暗色模式


    ☀️ 亮色模式


    新 feature:

    插件支持

    可使用 chrome 插件通过注入在已 star 仓库页面便捷的添加到 list 进行分类,包括 AI 建议,便捷笔记等等功能,大大提升了操作便捷性,具体配置方式如下

    1. Starflow GitHub release 页面下载插件包
    1. 插件包提供了两种支持格式,包括 chrome 和 firefox,本人电脑上暂无 firefox,故未对 firefox 插件包可用性进行实践,chrome 插件包解压后在 chrome 插件管理处开启开发者模式选择 加载未打包的扩展程序即可
    1. 加载后在插件栏打开插件输入已部署服务的地址后进行同步即可
    1. 此后打开任意 GitHub 仓库,均可看到嵌入到页面内的 Starflow 插件按钮,如图:

    如此这般便可在仓库页面便捷的将已 Star 仓库添加到 Starflow 的数据库中

    中英文及中英文分类 list 支持

    目前 Starflow 支持了中英文 i18n,并且支持智能分类,默认在英文界面会使用英文版本 prompt 来对现有仓库进行分类,若使用的是中文界面那么分类出来的 list 也是中文

    写在最后

    项目大幅使用了 vibe coding,自认为调教的还可以,基本功能都运行无误,佬友也可以提提建议,喜欢的话点个 star,不胜感激


    📌 转载信息
    原作者:
    GEMILUXVII
    转载时间:
    2026/1/19 19:05:12

    全程猛蹬 Gemini 3 pro,没额度了就继续蹬 Gemini 3 Flash。

    做了一些改动:

    • 移除了百度地图 SDK,改用开源的 OpenStreetMap 实现
    • 删减了功能,只保留了位置模拟
    • 增加暗黑模式支持
    • 按照 Material Design 3 设计风格,优化了整体界面



    📌 转载信息
    原作者:
    nekonene
    转载时间:
    2026/1/19 19:00:05

    今天在看一个 pdf 文档,但是原文档没有目录,导致跳转比较麻烦。搜了下,好像没有比较方便快捷的工具可以加目录的,就动手写了个。

    核心特性

    • 智能目录提取:内置高精度算法,一键扫描文档前 50 页并自动识别潜在层级结构。
    • 自由拖拽排序:支持通过手柄直接拖拽调整目录顺序,所见即所得。
    • 多层级支持:支持三级目录结构(章、节、点),轻松应对复杂文档。
    • 页码偏置修正:自适应纸质页码与电子页码的偏差,确保跳转精准无误。
    • 本地化存储:尊重隐私,文件处理完成后自动清理服务器残留。

    Docker 部署

    1. 拉取镜像

    docker pull ghcr.io/jiangnan1224/pdf-toc-editor:latest

    1. 运行容器

    docker run -d -p 5000:5000 --name pdf-toc-editor ghcr.io/jiangnan1224/pdf-toc-editor:latest

    应用截图


    体验地址

    开源地址


    📌 转载信息
    转载时间:
    2026/1/19 18:35:52

    基于我的上一个帖子 ipv6+ddns+Termux+openssh+mosh—— 分享个人手机上 vibe coding 的尝试,含详细操作步骤 - 开发调优 - LINUX DO

    不需要任何多余的步骤,实现了手机连接 ccb 进行多模型协作 vibe coding
    在 vscode 的终端中

    tmux new -s ccb
    ccb up codex gemini
    

    随后手机上打开 termux,连接到 wsl 中后执行

    mosh wsl
    tmux a -t ccb
    

    即可达到图中效果

    为了方便使用,tmux 配置鼠标滚轮滚动
    只是屏幕比较小,如果换成平板岂不是在外随时随地当牛做马?(不是


    兼容 cli 和 ide 的新玩法 [ccb] 全新大升级!!!1.18 更新 - 开发调优 - LINUX DO


    📌 转载信息
    原作者:
    Mr_Seven
    转载时间:
    2026/1/19 18:33:45

    之前在 web 端使用对话的时候,发现很多时候不太知道如何编写 prompt。所以就弄了一款 chrome 的扩展程序,可以让大家保存在浏览时中保存的 prompt,后续在 web 端使用。
    预置了一些简单的 prompt 模版,支持 {{变量名}} 语法,注入时弹窗填写。通过快捷键 Ctrl+Shift+P (Mac: Cmd+Shift+P) 呼出面板,一键注入 prompt。
    项目链接: GitHub - iiinnovation/ai_prompt
    AI Prompt 模板助手

    一款轻量级 Chrome 扩展,帮助用户管理常用 Prompt 模板,并在主流 AI 平台上一键注入到输入框。专为不熟悉 Prompt 编写的用户设计,内置丰富模板,开箱即用。

    功能特性

    核心功能

    • 丰富模板库 - 预置 23 个精选模板,覆盖日常、工作、学习、生活、写作、翻译、代码 7 大场景
    • 模板变量 - 支持 {{变量名}} 语法,注入时弹窗填写,让模板真正可复用
    • 快速注入 - 快捷键 Ctrl+Shift+P (Mac: Cmd+Shift+P) 呼出面板,一键注入
    • 智能分隔线 - 长模板自动添加分隔线并定位光标,短模板和变量模板则直接注入

    模板管理

    • 增删改查、分类管理、置顶收藏
    • 批量添加模板
    • 导入导出 JSON/MD 文件
    • 使用统计,支持按最近使用 / 最常用排序

    交互体验

    • 智能搜索 - 模糊匹配模板名称和内容
    • 键盘导航 - ↑↓ 选择,Enter 确认,数字键 1-9 快速选择
    • 追加模式 - 可选择覆盖或追加到光标位置
    • 右键创建 - 选中任意文字,右键快速创建为模板
    • 智能降级 - 非 AI 平台自动复制到剪贴板

    支持平台

    预置模板

    分类模板
    日常简单解释概念、头脑风暴、优缺点分析、做决定帮手
    工作邮件撰写、周报生成、会议纪要、面试准备
    学习知识点总结、练习题生成、学习计划
    生活旅行规划、菜谱推荐、礼物建议
    写作文章润色、总结要点、文案撰写
    翻译中英互译、多语言翻译
    代码代码审查、SQL 优化、代码解释、Bug 排查

    安装

    从源码安装

    1. 克隆仓库
    git clone https://github.com/YOUR_USERNAME/prompt-template-extension.git
    
    1. 打开 Chrome,访问 chrome://extensions/

    2. 开启右上角「开发者模式」

    3. 点击「加载已解压的扩展程序」

    4. 选择 prompt-template-extension 文件夹

    使用方法

    快速注入

    1. 访问支持的 AI 平台
    2. Ctrl+Shift+P (Mac: Cmd+Shift+P) 或点击扩展图标
    3. 搜索或选择模板
    4. 如果模板包含变量 {{xxx}},会弹出填写框
    5. 模板内容自动填入输入框

    模板变量

    在模板中使用 {{变量名}} 定义可填写的变量:

    请帮我写一封{{邮件类型}}邮件:
    - 收件人:{{收件人}} - 主题:{{主题}} 

    选择模板后会弹出填写框,填完后一键注入。

    管理模板

    • 右键扩展图标 → 选项
    • 或在弹出面板底部点击「管理模板」

    批量添加

    格式:每行一个模板,用 | 分隔

    模板名称 | 分类 | 模板内容
    

    导入导出

    • 导出:生成 JSON 文件备份
    • 导入:支持 JSON 和 Markdown 文件
      • JSON:批量导入多个模板
      • MD:文件名作为模板名,内容作为模板内容
    • 冲突处理:覆盖 / 跳过 / 重命名

    快捷键

    快捷键功能
    Ctrl/Cmd + Shift + P打开模板面板
    / 上下选择模板
    Enter确认选择 / 下一个变量
    1-9快速选择前 9 个模板
    Esc关闭面板

    技术栈

    • Chrome Extension Manifest V3
    • Vanilla JavaScript
    • Chrome Storage API

    项目结构

    prompt-template-extension/
    ├── manifest.json        # 扩展配置
    ├── background/          # Service Worker
    ├── content/             # 内容脚本(平台适配、注入逻辑、变量弹窗)
    ├── popup/               # 弹出面板
    ├── options/             # 管理页面
    ├── utils/               # 工具函数
    └── icons/               # 扩展图标 

    📌 转载信息
    原作者:
    Sheldonluo
    转载时间:
    2026/1/19 18:32:55

    推荐一个完全免费的 PDF 神级翻译工具:BabelDOC,几乎不破坏排版,翻译论文 / 技术文档时,公式不乱、图表不飞,阅读体验非常好,平台覆盖:网页端使用为主;开源项目可本地部署
    GitHub:https://github.com/funstory-ai/BabelDOC
    核心亮点是 “保留原 PDF 版式”,不是简单抽文本再重排对公式、表格、页码、段落结构友好,翻完还能当原文看基于大模型做语义翻译,长句和专业内容更通顺,特别适合论文、技术文档、说明书这类 PDF


    📌 转载信息
    转载时间:
    2026/1/19 18:32:47

    最近因为 AI 封号潮,很多佬友不敢用来路不明的节点,甚至想开全局代理保平安。
    但是开全局又会导致访问国内网站变慢、B 站卡顿,最要命的是可能进不去公司内网。

    折腾了一圈,发现最稳的方案还是 Clash 负责无脑全局(防泄露),SwitchyOmega 负责白名单直连(保体验)

    分享一下我的配置作业,主打一个零信任,希望能帮到有同样需求的佬友。


    核心逻辑

    采用 “零信任 / 白名单模式” 。默认假设所有流量都需要走代理(以保护 AI 账号安全),只有明确被信任的国内域名和内网 IP 才允许直连。

    1. Clash 端设置(地基)

    • 运行模式Global(全局模式)。确保由 Clash 接管一切,不留死角。
    • 系统代理开启。(:如果开启后导致公司内网 VPN 客户端冲突或掉线,请改为关闭;关闭后浏览器依然有效,但 特定软件需手动设置代理)。
    • TUN 模式关闭
    • 节点选择:手动锁定一个稳定的美国节点(不要自动测速跳变)。

    2. SwitchyOmega 插件设置(核心)

    • 情景模式:选择 auto switch(自动切换)。
    • 默认情景模式(最后一行):设置为 proxy(即指向 Clash)。
    • 规则列表设置
      • 规则列表格式必须选择 Switchy(关键!为了更好支持通配符 *)。
      • 规则列表规则:设置为 [直接连接]

    3. 白名单配置代码(复制即用)

    后续大家可以根据自己的浏览习惯,遇到慢的国内网站就加进去。
    auto switch 的规则列表正文中,清空原内容,粘贴以下代码:

    ; --- 本机与内网 (规范化) ---
    127.0.0.1
    ::1
    localhost
    192.168.*.*
    10.*.*.*
    172.16.*.*
    172.17.*.*
    172.18.*.*
    172.19.*.*
    172.20.*.*
    172.21.*.*
    172.22.*.*
    172.23.*.*
    172.24.*.*
    172.25.*.*
    172.26.*.*
    172.27.*.*
    172.28.*.*
    172.29.*.*
    172.30.*.*
    172.31.*.*
    
    ; --- 安全与技术站 (微步/52/CSDN/博客园) ---
    *.threatbook.cn
    *.threatbook.com
    *.x.threatbook.com
    *.fofa.info
    *.52pojie.cn
    *.csdn.net
    *.oschina.net
    *.gitee.com
    *.cnblogs.com
    *.juejin.cn
    *.jianshu.com
    
    ; --- 核心大厂主站 ---
    *.cn
    *.baidu.com
    *.bdstatic.com
    *.qq.com
    *.weixin.qq.com
    *.aliyun.com
    *.taobao.com
    *.tmall.com
    *.jd.com
    *.163.com
    *.126.com
    *.zhubajie.com
    *.feishu.cn
    *.dingtalk.com
    *.zhihu.com
    *.zhimg.com
    
    ; --- 视频与娱乐 (B站/抖音) ---
    *.hdslb.com
    *.bilivideo.com
    *.bilivideo.cn
    *.douyin.com
    *.byteimg.com
    
    ; --- 常用公共 CDN (解决图片/样式不加载) ---
    *.alicdn.com
    *.gtimg.com
    *.gtimg.cn
    *.qpic.cn
    *.qlogo.cn
    *.qhimg.com
    *.qiniucdn.com
    *.upyun.com
    *.bootcss.com
    *.staticfile.org
    


    方案优势解析

    1. 极致的账号安全性(防封号)

    • 原理: 传统的 “黑名单模式”(GFWList)是 “知道被墙的才走代理”。这意味着如果有漏网之鱼(比如 OpenAI 新开了个域名),你的真实 IP 就会瞬间暴露,导致封号。
    • 本方案: 采用 “默认代理”。哪怕是你从未访问过的国外网站,或者 OpenAI 偷偷调用的后台 API,都会强制走美国节点。 这彻底杜绝了 IP 泄露的可能性。

    2. 彻底剥离 “机场依赖”

    • 痛点: 以前你不仅要挑机场,还要看机场的规则写得好不好。如果机场规则烂,访问微步就会变慢,访问 ChatGPT 就会断连。
    • 本方案: 你不再依赖机场的规则。Clash 只负责无脑转发,分流的智慧掌握在你自己的浏览器里。哪怕换个最烂的机场,分流依然精准。

    3. 极低的维护成本(符合成本论)

    • 操作: 以后如果发现某个国内网站(比如某政府网)变慢了,点击浏览器插件图标 → 添加条件直接连接
    • 对比: 不需要去改 Clash 的 YAML 代码,不需要重启软件,不需要找文档。1 秒钟解决问题。


    补充讨论:关于 Flclash 脚本与本方案的取舍

    评论区有人分享了这个大佬的方案,写得非常棒: [Flclash 覆写脚本分享 3 - 隐藏了部分策略组,并引入了节点过滤 - 开发调优 - LINUX DO](

    **Flclash 覆写脚本分享 3 - 隐藏了部分策略组,并引入了节点过滤 **

    )

    结合我自己的 网安工作场景AI 重度使用需求,分享一下为什么我倾向于坚持 「Clash Global (全局) + SwitchyOmega (白名单)」

    1. 安全哲学的根本区别:Fail-Safe vs Fail-Open

    • 脚本 / 规则分流(黑名单逻辑):依赖 GFWList 和 GeoIP。如果 OpenAI 突然启用了新域名,或者规则库更新不及时,流量可能会因为匹配不到规则而误走直连,导致 真实 IP 泄露。这对于 AI 保号 是致命的。
    • 浏览器白名单(零信任逻辑):我的方案是默认所有流量走代理(Global)。只有我显式信任的域名(如微步、百度、内网)才直连。未知 = 代理。这种 “宁可误杀,绝不漏放” 的机制,能给 AI 账号提供 100% 的安全环境。

    2. 业务稳定性 vs 节点速度

    • 脚本使用了 url-test 自动测速。这会导致出口 IP 在不同节点间跳变。看 YouTube 没问题,但对于风控严格的 ChatGPT/Claude,IP 频繁变动是封号大忌
    • 在全局模式下,我手动锁定一个稳定的美国节点,哪怕它延迟高一点,但它是静态的。生产力环境,稳定性 > 速度。

    3. 内网 / VPN 的兼容性

    • 在复杂的企业内网或挂着 VPN 办公时,系统级的 TUN 模式有时会和 VPN 客户端抢路由表。
    • 将分流控制在浏览器应用层(SwitchyOmega),可以完美绕过系统路由冲突,实现挂着梯子查资料的同时,丝滑访问 10.x / 172.x 的内网资产。


    特别说明:关于 “系统代理” 开不开?

    文中建议大家 “开启” 系统代理,但这里有个前提:

    • 如果你不开系统代理:浏览器由插件接管没问题,但 反重力 默认会直连(连不上),需要在软件内手动填 127.0.0.1:7890
    • 如果你开启系统代理:TG 等软件能直接用,很方便。但如果你电脑上还装了 EasyConnect、AnyConnect 等企业 VPN,开启系统代理可能会导致路由冲突(VPN 连不上或梯子断流)。

    结论: 没冲突就开着(省事);有冲突就关掉(保内网),然后手动给 反重力 填代理。

    白名单可以去 GitHub 上搜
    注意: 千万不要把这些列表全选复制进 SwitchyOmega!

    1. 太长了(几万行),会拖慢浏览器匹配速度。
    2. 没必要,我们是 “零信任”,只加自己常用的即可。

    进阶技巧:如何知道该加哪个域名? > > 如果你发现访问淘宝或 B 站时,排版乱了或者图片裂了,说明有 CDN 域名走了代理。 > 一招解决: > 1. 按 F12 打开开发者工具,切到 Network (网络) 标签。 > 2. 刷新网页(F5)。 > 3. 找红色的或者加载特别慢的请求,看它的 Domain (域名) 列。 > 4. 比如你看到 [img.alicdn.com](http://img.alicdn.com/) 很慢,就把 *.alicdn.com 加到 SwitchyOmega 的列表里。


    📌 转载信息
    原作者:
    techq
    转载时间:
    2026/1/19 18:32:42

    写了一个全自动创作小红书笔记、生成图片,并且发布的 Skills

    已开源,欢迎佬友们 Star & 贡献


    📌 转载信息
    原作者:
    comeonzhj
    转载时间:
    2026/1/19 18:31:20

    @Jimmy

    创建回复所需要的金币应该是跟回复内容的长度有相关的,我一些长回复会扣除 25 金币,短回复扣除 10 金币,但是先创建一个短回复,再改为长回复,所需的金币仍然是 10 金币,不会多退少补表情包

    OpenCode 竟然没有 “任务完成 / 请求权限 / 运行失败时发出通知” 这个功能。mohak34/opencode-notifier 这个插件倒是可以实现,但是最近的版本这个插件会导致 OpenCode 自带的 bun 发生 Segmentation fault,运行两步就崩溃。

    于是我原汤化原食自己 vibe 了一个,把压缩包里的文件放在 ~/.config/opencode/plugins 里即可。

    session-notify.zip

    可以在 47 行配置是否弹出通知以及是否发出声音,一般只推荐开其中一个。Windows 可用,Linux 和 MacOS 我没测试,大概也可用,Maybe。


    📌 转载信息
    原作者:
    MUTED64
    转载时间:
    2026/1/19 18:30:21

    使用 Cliproxy,Donehub, Antigravity Tools 反代出来的 api 生图是不能联网的。
    使用 gemini-business2api 的生图,Nano banana 可以联网检索。不过默认没有 4k,看哪位大佬搞下。

    设置如下,使用的是 url,cherry studio 里边给出的链接,就可以打开图片。联网是可以选择的。

    2api 的设置如下

    gemini-business2api 项目见链接

    使用的 linux docker 安装,opus 给的一个一键教程代码。


    📌 转载信息
    原作者:
    synbio
    转载时间:
    2026/1/19 18:30:11

    这是 ROG Xbox Ally 下的测试效果,可能有专门的硬件适配吧,普通台式机是不是也能有类似的性能加成呢?

    在 Bazzite 和 Windows 分别运行游戏《Kingdom Come: Deliverance 2》和《Hogwarts Legacy》的测试显示,Linux 下的游戏 FPS 比 Windows 下平均高 13.47%,而且帧率更平稳,FPS 最高多了 32%(17W 功率模式下的《KCD2》)

    版本新特性

    1. CLI 供应商设置页(Claude Code / Codex)
    1. `CollabChat` 视图与 `MessageList` 工具消息批量折叠,提升长对话可读性。

    2. 修复了资源占用的 bug

    项目地址:


    📌 转载信息
    转载时间:
    2026/1/19 18:29:51

    OpenStack 云基础设施项目中一个重大安全漏洞已被修复,该漏洞位于其身份认证中间件中。漏洞编号为 CVE-2026-22797,属于权限提升漏洞,允许已通过认证的普通用户欺骗系统,使其获得管理员权限或冒充其他用户。
    问题出在 keystonemiddleware 中,这是 OpenStack 服务中负责处理身份验证令牌的关键组件。
    该漏洞特别影响使用 external_oauth2_token 中间件 的部署。在安全的系统中,内部身份验证头(用于告诉后端用户是谁、能做什么)应该由系统本身严格管理。然而,该中间件在处理 OAuth 2.0 令牌之前没有清理传入的身份验证头
    这一疏忽为伪造身份创造了危险机会。由于系统没有清除这些输入,“通过发送伪造的身份头,例如 X-Is-Admin-Project、X-Roles 或 X-User-Id,已认证的攻击者可能提升权限或冒充其他用户。”
    本质上,攻击者只需通过注入 X-Is-Admin-Project 头就可以 “申请” 成为管理员,而系统会把它当成真实的。公告指出,这之所以可能,是因为中间件 “只在特定条件下设置某些头…… 当条件不满足时,伪造的值会保持不变”。
    该漏洞影响以下特定版本范围的 Keystonemiddleware:
    • 版本 >=10.0.0 且 <10.7.2
    • 版本 >=10.8.0 且 <10.9.1
    • 版本 >=10.10.0 且 <10.12.1
    公告警告:“所有使用 external_oauth2_token 中间件的部署都受到影响。”
    该漏洞由 Red Hat 的 Grzegorz Grasza 报告。作为回应,OpenStack 团队已在多个发布分支发布补丁,包括 Caracal(2024.1)、Dalmatian(2024.2)、Epoxy(2025.1)、Flamingo(2025.2)和 Gazpacho(2026.1)。
    云管理员被强烈建议立即应用这些补丁,以确保 OpenStack 环境正确验证用户身份,而不是盲目信任收到的请求头。

    也许有些佬不大明白这个软件是做什么的?

    简单讲,这是一款用于教学的 ERP 沙盘模拟系统,
    它可以让学生自己体验一把公司运营的感觉,
    倒也可以说是模拟经营游戏。
    这是一些软件截图,或许能唤起部分人的回忆:






    我是在学校中了解到这个系统,那时候上手了一下就有点上瘾了。
    后来我在各大搜索引擎中,在 CSDN 找到了原始安装包,
    不过由于需要加密狗,我就一直存放在我的网盘一直没有动过。

    后来在上周,我就开始了对他的破解研究,直到目前才正式完工。
    除了破解补丁,我在安装包内附赠了该软件的操作手册,
    还有一些我在学校机房发现的规划和订单文件。
    你可以利用这些文件让 AI 帮你写出你想要的规划和订单,
    或者你自己利用安装文件的工具手工制作一个,
    并导入到软件里面,自行体验公司运营的乐趣。

    你也许不知道这个软件的含金量,他在闲鱼价格通常以租聘账号为主。
    十几块钱一周,三十几一个月,主要租聘的是软件的规划订单数据,
    国内一些的比赛也在使用这个软件,而且不少学生都想要这个软件的安装包。
    软件本体本不应公开,但我希望我的贡献能给相同需要的学生一个帮助。

    !!!但请注意,请不要将该软件直接部署在公网的生产环境中!!!
    这不是我的问题,但这软件已经硬编码写死了数据库的密码和用户名,
    数据库本身有弱口令风险,会有被渗透的可能性。
    并且请勿将软件用于商业或盈利用途,转载请先告知我!!!
    除此之外,也还请各位佬友私下交流并游玩哇~~
    (同样如果你遇到了什么问题,也欢迎在底下留言呢,
    第一次做这种逆向,不是懂很多 xwx)

    软件启动后默认地址为:http://localhost:8081/
    管理员账户名:admin
    管理员密码:1

    123 盘:https://www.123865.com/s/ztqKVv-t3Hl3
    (去掉了蓝奏云下载,我刚知道蓝奏云已经没办法分卷上传了)

    因为是第一次,所以等级就暂时锁到 3 级佬可见,等风头好些了再尝试降到 2 级哇。
    希望不会给我带来什么乱子


    📌 转载信息
    转载时间:
    2026/1/19 18:29:38