写点什么

一个月重写三次代码库、三个月就换套写法!吴恩达:AI 创业拼的是速度,代码不重要

  • 2025-07-13
    北京
  • 本文字数:9090 字

    阅读完需:约 30 分钟

大小:4.41M时长:25:42
一个月重写三次代码库、三个月就换套写法!吴恩达:AI创业拼的是速度,代码不重要

近期,吴恩达 (Andrew Ng) 在 Y Combinator 发表了最新演讲,分享了自己的创业心得。他提出为创业公司成败的关键在于执行速度,执行速度比以往任何时候都更加重要,此外,他还详细阐述了创业公司应该如何提速。

 

期间,吴恩达提出,创业者最大机会是在应用层,因为只有应用才能创造更多收入,反哺云、模型和芯片公司。创业中,不要有类似“我要用 AI 优化医疗资源”这样的想法,因为不够具体、难以落地。系统性地做 20 个原型产品去试错,很多最后不会投入生产,但没关系,因为试错成本足够低。

 

实践中,要善用 AI 编程工具提速,吴恩达指出,和最新工具比起来,即便只是落后半代、一代,差距就会非常明显。“现在我团队里的工程师,和三个月、六个月前比,写软件的方法已经很不一样了。”他还表示,鉴于当前研发速度已经远超产品设计速度,产品经理与研发人员的人数比已经出现反转趋势。

 

在问答环节,他表示 AGI 被过度炒作:过去两年,有些公司为了营销、融资、影响力,故意把某些说法炒得很大,就是为了让这些公司看起来更厉害。另外,很多开发者太担心 token 成本,他表示,大多数创业公司根本还没到那个量级,真正因为 token 开销太高而受影响的只是极少数团队。

 

我们对吴恩达的本次演讲内容进行了翻译,并在不改变愿意基础上进行了删减和整理,以飨读者。

 

执行速度决定创业成败

 

很高兴见到大家。既然今天是创业学校的活动,我想分享一些我在 AI Fund 和 AI Fund Venture Studio 参与创业时积累的经验教训。我们平均每个月孵化一家初创公司,因为是联合创始模式,所以我们不仅仅是看别人创业,还会亲自下场写代码、接触客户、设计功能、确定定价等。可以说,我们在实际操作里做了很多。

 

今天想重点跟大家分享的是围绕 AI 技术变化带来的创业新机会,尤其是和“速度”相关的经验体会。对于想创业的人来说,我认为衡量一家初创公司未来成败的一个关键因素,就是执行速度。我非常敬佩那些能够高效推进事情的创业者和管理者。

 

新一代 AI 技术正在让创业速度大幅提升。我想分享过去几个月中不断演变的一些最佳实践,帮助大家提升速度,提高创业成功的概率。

 

很多人问我:Andrew,现在还有哪些 AI 创业机会?我个人的看法是,可以把 AI 行业分成一层一层的“技术堆栈”:最底层是半导体公司,往上是云服务商,再往上是基础大模型公司。虽然大家的注意力、媒体的报道大多集中在这些底层技术上,但实际上,最大机会几乎必然是在应用层,因为只有应用才能创造更多收入,反哺云、模型和芯片公司。

 


媒体和社交网络可能不太爱谈应用层,但如果你打算创业,几乎可以肯定的是,最大的机会就在这里。当然每一层都有机会,但应用层是最直接的。

 

过去一年,AI 领域最大的新趋势是 Agentic AI。大约一年半前,我就开始到处演讲,想让大家相信智能体可能会成为主流产品。没想到去年夏天,很多市场营销团队开始疯狂用这个词,贴标签,什么产品都往上套,导致这个词本身有点被滥用了。

 

但我想从技术角度解释一下,为什么我认为 Agentic AI 既重要又充满创业机会。过去,我们用大模型的方式通常是一问一答,比如让大模型写一篇文章,它从第一句话写到最后一句,中间不复查、不修改。但人类不会这么写,强制线性写文章不是最高效的方法,AI 其实也一样。即便如此,今天的大模型在这种“线性”模式下已经做得很不错了。

 

但效果更好的是“迭代式”工作流:先写个大纲、再上网查资料、补充上下文、写第一稿、自己审稿、自己修改,如此反复循环。这样虽然慢一点,但结果好得多。AI Fund 做过的项目,包括合规文件提取、医疗诊断、法律文件处理,几乎都是靠这种智能体工作流才能跑通。很多有价值的业务,未来还需要把传统工作流,变成适合 Agentic AI 的迭代式流程。

 


回到 AI 技术堆栈,过去一年又新增加了一层——Agentic 编排层。它帮助应用更容易调度和协调底层 AI 服务,也让做应用变得更容易。但归根结底,应用层仍然是最有价值的地方。

 

如何更“快”

 

接下来,我想分享一些关于如何让创业公司更快推进的实践经验。

 

想法要具体

 

在 AI Fund,我们只落地“具体”的想法。所谓具体,是指工程师听完之后,马上可以开工写代码的那种。比如“用 AI 优化医疗资源配置”,这太模糊了,不同工程师理解完全不同,没法快速落地。反过来,如果你说“做一个软件,让医院的患者可以在线预约核磁共振时间,提高设备利用率”,我不管这个想法本身好坏,它至少是具体的,工程师马上可以开工,而且你很快就能知道这事值不值得做。

 


“具体”,带来速度。

 

很多时候,创业者会被“模糊的宏观想法”误导。比如你跟朋友聊天说“要用 AI 优化医疗资源”,大家都会夸你想法好。但这其实并不是好想法,至少不是一个可以执行的好想法。想法模糊的时候,你永远是对的;当想法变得具体时,你可能对,也可能错。

 

但创业最需要的是快速验证,所以我一直要求团队只讨论具体想法,因为只要具体,就有明确方向,团队才能快速推进。要么做成,要么发现做不成,都没关系,重要的是快。

 


找到好的具体想法,通常需要有一个人——可能是你,也可能是行业专家——长期深入思考那个问题。比如我在创办 Coursera 之前,花了好几年时间琢磨在线教育,跟用户聊,自己也反复琢磨。YC 把这叫做“走迷宫”。当你真的想明白了,后面再做决策时,直觉可以是一个出乎意料的、不错的决策机制。

 

很多人以为做 AI 创业一定要靠数据,但其实数据反馈很慢。很多时候,有长期积累的人直觉更准,决策更快。

 

另外,很多成功的创业公司在某个时刻只专注于一个非常清晰的假设。初创公司没资源同时试 10 条路,因此必须选一条,全力以赴。如果发现做不通,也无所谓,立刻转向,再专注于新的具体想法。

 

这是 AI Fund 的日常:一旦世界告诉我们错了,马上换方向,但保持同样的决心和投入。如果每次跟用户聊完都完全推翻原来的想法,那说明对这个领域了解还不够。真正好的具体想法,通常需要反复思考和验证。

 

还有一个重要的事情,就是“构建-反馈”循环。尤其是现在有 AI 编码助手之后,这个循环正在变得前所未有的快。

 

很多初创公司失败,并不是因为技术做不到,而是做出来没人用。所以做应用型创业时,我通常是先写软件,这是工程工作;然后拿去给用户反馈,这是产品管理工作;再根据反馈调整,再写软件;不断循环,直到找到 PMF(产品市场匹配)。

 

现在 AI 编码助手让写代码的速度和成本大幅降低。以前做一个小功能可能要好几天,现在半天就能写好。这个变化特别大。

 

我自己写软件时,大致分两种情况:一种是快速构建产品原型来验证想法,比如做一个新的客服机器人、处理法律文档等;另一种是编写或维护生产环境里的正式软件。写生产级代码时,用 AI 助手可能能提升 30%到 50%的效率,不同报告说法不一,但在写原型验证代码时,效率提升完全不是 50%,而是至少 10 倍,甚至更多!

 


为什么?因为快速原型不需要和遗留系统集成,不需要高可靠性,不需要安全性。虽然这话可能不太对,但我经常跟团队说:“你就写个不安全的代码没关系。”如果这个软件只在你自己电脑上跑,你又不会黑自己电脑,那就先不考虑安全。

 

当然,如果打算上线给别人用,那一定要加上安全性和可扩展性。但前期快速测试阶段,是可以临时放一放这些的。

 

现在越来越多的初创公司会用“并行原型法”——同时做 20 个原型来找出哪个能走通。很多人担心“AI 做的 POC(概念验证)项目上线不了”,但如果做 POC 的成本足够低,这根本不是问题。我们完全可以承受一堆无疾而终的 POC,只要其中一个成了,那就是成功。

 

“快速迭代,打破常规”(move fast and break things)这句口号因为“break things”出了名声问题,导致有些团队误以为不该“move fast”,这是错误的。我告诉团队要“快速且负责任地行动”。这是可以做到的。

 

用好 AI 辅助编码工具

 

关于 AI 辅助编码工具这块,我觉得大概三、四年前,GitHub Copilot 普及了“代码自动补全”这个概念,后来又有了像 Cursor、Windsurf 这种新一代内置 AI 功能的 IDE 工具,我们团队也经常用 Windsurf 和 Cursor。

 

大概从六、七个月前开始,又冒出了一批更新一代的 Agentic 编码助手,包括我们也在大量使用的 Claude Code。自 Claude 4 发布之后,Claude Code 效果非常好。它上线三个月左右,我们团队有些人就开始换工具了。

 


总的来说,演进非常快。Claude Code、Codex 代表的新一代 Agentic 编码助手确实在不断提升开发者的生产力。

 

而且这里有个挺有意思的现象:和最新工具比起来,即便你只是落后半代、一代,差距就会非常明显。现在我团队里的工程师,和三个月、六个月前比,写软件的方法已经很不一样了。

 

还有个挺反直觉的变化:我们以前总觉得代码本身是很宝贵的资产,因为写起来太费劲了。但现在,随着软件工程成本越来越低,代码本身变得没那么重要了。比如我在一些团队里,一个月内把整个代码库推翻重写三遍已经不是什么新鲜事了,因为完全重写、换数据库架构、重新选技术栈的成本已经低了很多。

 

有些人可能听过贝索斯的“两扇门”理论:有的决策像单向门,进去了就很难回头,比如早期决定技术架构就是;而有的决策像双向门,做了发现不对还能轻松回撤。而现在,我觉得选技术栈这件事越来越像双向门了。我不想过度吹捧,完全推翻重做还是有代价的,但在我团队里,大家越来越习惯在一周后就说,“不如把整个代码库扔了重写一遍”。以前这几乎不可想象,现在变成了常态。

 

工程成本变低之外,我还想个说一个稍微超出工程范畴的话题:过去一年里,网上很多人劝大家别学编程,说 AI 都能自动写了。我觉得这可能会成为历史上最糟糕的职业建议之一。技术工具越好,学写程序的人应该越多,而不是越少。

 

历史上也是这样:从打孔卡到键盘、从汇编到高级语言,比如 COBOL 出来时候很多人说,“有 COBOL 了,程序员要失业了”,结果根本不是那样,语言越高级,学的人反而越多。现在的 IDE、AI 编码助手、自然语言写代码,都是一样的道理:软件开发变简单了,应该更多人去学。

 

我个人甚至有个可能不太主流的看法:任何岗位的人都应该学会写点代码。我团队里,包括 CFO、HR 负责人、招聘经理、前台,他们都会写程序,我确实能明显地感觉到他们在各自的岗位上表现更好。虽然现在大多数企业还没做到,但未来趋势应该是:让更多人具备基础编程能力,整体效率会更高。

 

我还想补充一个小故事,说明为什么“让大家都学”这件事很有意义。

 

我们在 Coursera 教大家做生成式 AI 项目,比如用 Midjourney 生成背景图。有个同事学过美术史,他在给 Midjourney 下指令时,能明确写出流派、色调、风格参考等要求,生成效果特别好。相比之下,我不懂美术史,只能写“请帮我画一张好看的机器人”,效果就差很多。

 

这让我深刻意识到:未来跟计算机打交道,最重要的能力就是要清楚表达你想要什么,让计算机帮你实现。无论是自己写代码,还是指导 AI 帮你写,掌握这种能力都非常关键。

 

快速反馈

 

回到软件工程效率变快这件事,另一个明显变化就是:通过产品管理获得用户反馈、再决定做哪些功能,反而越来越成为瓶颈。

 


过去四、五年,硅谷有些不成文的“人效比”规定:比如一个产品经理对应 4 个工程师,或者是 1:7。虽然只是参考,但现在工程师研发速度变快太多,产品设计的速度完全跟不上。甚至昨天有个团队来找我说,干脆一个产品经理配 0.5 个工程师,也就是说,产品经理数量比工程师还多一倍。这是我第一次听到这样的建议,我还没完全想好这是不是个好主意,但至少说明了现在已经有了这种变化趋势。现在很多时候,具备产品思维的工程师、能写代码的产品经理,反而更有优势。

 


工程速度快了之后,另一个关键就是怎样快速获得产品反馈。我这边总结了一套组合拳,包括最快、但可能不太准的,到慢一点、但更准的各种方式。

 

最快的办法就是自己看产品、凭直觉判断。如果你是个内行,这其实很有用。再慢一点的方式是找朋友、同事试用获得反馈。再慢一点的方式就是找 10 个陌生人,这个我自己特别有体会,我很早就学会去咖啡厅或者酒店大堂,找人帮忙试用产品,问他们意见,当然要非常礼貌和尊重别人,实际效果特别好。尤其是旅行的时候,坐在酒店大堂高人流区域,拉陌生人帮忙看一看,我很多产品决策就是这么做出来的。这有时候反而还是个社交机会,很多人愿意被这样“打扰”一下。

 

再往后就是发原型产品给 100 个用户测试,或者做 A/B 测试。A/B 测试当然重要,我自己也做很多,但说实话,现在它已经是相对最慢的一种反馈手段了。尤其是产品还没大规模放量时,收集数据比较慢。

 

而且,我想提醒大家,A/B 测试的意义不只是“选 A 还是选 B”。我团队做 A/B 测试时,会花时间坐下来分析数据,校准自己的判断力。比如我原本以为产品 A 的名字会比 B 好,但数据告诉我完全相反,那说明我对用户的认知有偏差。这时候就要认真反思,总结规律,让下一次靠直觉决策时能更准。

 

综上所述,整体来说,就是如何让想法更具体、让工程更快、让产品反馈更快。这些环节做好了,整个创业速度就能大幅提升。

 

始终保持 AI 技术敏感性

 

最后我想讲一件事:真正理解 AI 能让你做事情更快。为什么这么说?可能我自己是做 AI 的,会有点偏向 AI,但我想把这个道理跟大家解释清楚。

 


大家用智能手机很多年了,基本都知道手机 App 能做什么,即使是不懂技术的人,对 App 能力也有比较准的直觉。再比如销售、市场、HR、法务这些岗位,当然都很重要也不简单,但因为行业成熟了,从事的人很多,大家总结的方法在一、两年内其实不会有太大变化,所以行业里懂的人很多,知识也比较普及。

 

但 AI 不一样。AI 是新技术,真正懂怎么用 AI 的人不多。团队如果真的理解 AI,就会比不懂的团队更有优势。如果你有个 HR 问题,身边随便找个人可能就能搞定,但 AI 相关的问题,可能真的是做对一个决策,几天就能搞定;但做错一个决策,可能三个月白忙活。

 

比如你要做客服机器人,准确率应该做到多少?是直接 prompt 还是微调?语音识别怎么做到低延迟?这些技术决策如果做对了,几天就能搞定,一旦做错了,可能就会卡在死胡同里一直打转。

 

我自己也有点意外:表面上看,两种架构方案二选一,好像只是慢一倍而已,但实际上可能是慢十倍。选错了方向,光试错就耗掉大半年。所以说,有没有正确的技术判断,直接影响到整体速度。

 

还有一个原因,让我觉得持续关注 AI 进展特别关键:过去两年,各种新的 AI 工具、新的基础能力层出不穷。像 prompting、Agentic 工作流、Evals 评估工具、Guardrails、RAG、语音、异步 API、ETL、embedding、微调、图数据库、DP 隐私保护、视觉多模态集成……这些基础能力,现在能快速组合起来,做出一两年前根本做不出来的产品。

 

很多新机会不是完全创造新的东西,而是把这些新的“积木”拼起来。每多掌握一种能力,组合的可能性就会指数级增长。

 

形象点的说法,如果你只懂一种 AI 能力,比如 prompt,那你只有一个白色积木块,能做一些事情;但如果你再学会搭建 chatbot,就相当于多了一个黑色积木块,可以拼的东西更多;如果再学会 RAG,就多了一个蓝色积木块;学会语音,又多一个红色积木块。随着你的“积木”越来越多,能拼出来的产品组合也会指数级增长。

 

我自己每次准备 DeepLearning.AI 的课程目录时,看到的就是一堆新的“积木块”。掌握它们,就是在给自己增加新的组合可能性,做出以前根本做不了的软件。我们团队也经常跟全球很多 AI 公司合作,这就是在不断补齐这些“积木块”。

 

最后,总结一下:创业当然不只有速度一个因素,但在 AI Fund,我们看到,团队执行速度和成功概率高度相关。为了变快,一是要做具体的想法,别太虚;二是利用 AI 编码助手加速工程;三是产品反馈要跟上,别只会写代码,不去验证市场。包括像我前面提的,学会去咖啡厅、酒店大堂找陌生人聊产品,这虽然听着不容易,但对创业者来说真的很有价值。另外,要始终保持对 AI 技术的敏感和学习。

 

现场问答

 

Q1:随着 AI 不断进步,你觉得是开发更多工具更重要,还是更好地学会使用这些工具更重要?人类怎样才能确保在智能逐渐普及的时代依然不可或缺?

 

吴恩达:我觉得 AGI 被过度炒作了。很长一段时间里,还是会有很多事情是人类可以做、但 AI 做不了的。我认为,未来最有能力的人,是那些能让计算机完全按自己意图去做事的人。我们当中有些人会去开发工具,但也有很多工具是别人做的、我们只要学会使用就行。真正厉害的,是懂得怎么用 AI 让计算机为自己工作的人,不必担心“人类无事可做”,但不懂用 AI 的人,会比懂得用 AI 的人弱很多。

 

Q2:现在很多人讨论 AI 算力趋势,有人说要将 GPU 送上太空(建造太空数据中心),也有人说只有核能数据中心才能满足 AI 需求,对此你怎么看?

 

吴恩达:这个问题其实和 AGI 炒作相关。我觉得可以有个简单框架,帮助大家判断什么是炒作、什么不是。

 

过去两年,有些公司为了营销、融资、影响力,故意把某些说法炒得很大。因为 AI 是新东西,外界搞不懂,很多时候根本没人去查证。有些炒作,就是为了让这些公司看起来更厉害。

 

比如“AI 强大到可能导致人类灭绝”这种说法,完全是无稽之谈,但却被大肆宣传,帮某些企业募资;“AI 太强了,以后大家都失业”——也不是真的,但又被放大了;还有“我们公司训练出新模型,一下子就能干掉上千家创业公司”,也不现实,确实有公司遇到困难,比如 Jasper,但没那么夸张;还有“AI 需要用电太多,只有核电撑得住,风能、太阳能不行”——这也不是真的。

 

我认为,关于什么 GPU 上太空这些说法,也差不多属于那类噱头。地球上的 GPU 还有很大的空间可以发挥。很多被放大的叙事,其实是对现实的扭曲。

 

Q3:哪些 AI 领域最危险的偏见或过度炒作,是大家容易被误导、但需要注意避免的?

 

吴恩达:我觉得最大的危险在于把 AI 过度神化。AI 确实是非常好的工具,就像电一样:有很多造福用途,也有可能被用在有害场景。

 

我自己不太常用“AI 安全”这个说法,不是因为不在意风险,而是我觉得“安全”不是技术本身的属性,而是使用方式决定的。就像电动机,其本身没法保证别人不会拿它去做坏事,又比如制造武器。安全不取决于电动机,而取决于怎么用。AI 也是一样,它本身既不安全,也不危险,是人类应用方式决定的。

 

所以,我更常讲“负责任的 AI”。关键是我们怎么负责任地使用它。比如前两天《华尔街日报》写了一篇关于 AI 失控的文章,我看了,觉得完全是把实验室里某个极端案例放大,弄得很耸动。AI 技术太新,很多人不了解,这些话题很容易被放大,甚至被用来打击开源,这是很可惜的。

 

Q4:在 AI 时代,产品随时可能被竞争对手用 vibes 编码几小时就复制,你觉得创业者该怎么思考这件事?

 

吴恩达:创业时要考虑的事情很多,但最重要的是:你有没有做出用户真正喜欢的产品?很多人会去想渠道、竞争对手、技术护城河,这些当然重要,但如果只能专注一件事,那一定是:用户是否真正需要你做的产品。

 

当你解决了这个问题,其他事情才开始重要,比如怎么获客?定价?护城河是什么?我个人觉得“护城河”这个概念有点被高估了。很多公司最开始是靠产品起家的,护城河是后期自然形成的。消费品靠品牌,企业服务靠渠道。但说到底,重点还是先做出用户爱用的东西。而且,现在这个阶段,机会远远多于具备能力的人。尤其应用层,空白太多了,很多新东西还没人做。所以我建议大家,专注做用户真正想要的产品,其他事情可以边做边解决。

 

Q5:你提到 AI 工具像积木一样可以组合,但目前感觉 AI 工具的功能叠加,和传统工程里的那种静态组合不太一样,存在 token 开销和时延问题。你怎么看 AI Agent 这种积木效果的积累?

 

吴恩达:我先说个简单建议:很多开发者太担心 token 成本,其实大多数创业公司根本还没到那个量级。真正因为 token 开销太高而受影响的,是极少数产品用户量真的特别大的团队。

 

我们也遇到过,确实有产品因为用户多,账单涨得很快,但多数团队压根还没到这个阶段。真到那一步,也有很多降低成本的办法,比如 prompt 优化、微调、系统架构优化等等。现在很多 Agentic 工作流,确实是在整合很多步骤,比如客服机器人往往要用 prompt、DSP 优化、RAG 检索、Guardrails 等,所以我确实看到这些东西在越来越复杂地组合到一起。

 

我自己经常做的一件事是,尽量让系统架构更灵活,方便随时切换不同的基础模型。我们有很多产品,背后用的是什么大模型,可能我自己都说不清楚,因为工程团队每周在跑 evals,新模型更好,就直接切过去了,甚至不用跟我报备。

 

基础模型的切换成本其实不高,平台层的切换稍微麻烦点,但总体来说,只要架构设计得灵活,越往上叠越多层,速度反而可以越快。

 

Q7:关于教育和 AI,有两种模式:一种是 AI 帮老师提高效率,比如自动批改;另一种是每个学生配一个 AI 私人导师。你怎么看未来 5 年的教育发展?

 

吴恩达:大家都觉得教育行业正在发生变化,但我觉得还没到真正大规模变革的时刻,现在更多是各种各样的探索。Coursera 有 Coursera Coach,效果不错;DeepLearning.AI 也在做 AI 教学相关的东西;语音学习领域,比如 Duolingo 已经有比较成熟的做法,但整个教育行业还没定型。

 

我确实相信未来教育会高度个性化,但这个到底是 ChatBot Avatar 还是别的什么,还没完全确定。几年前的 AGI 幻想太夸张了,实际上教育工作非常复杂,老师、学生各种流程交织,未来 10 年里,我们要做的就是不断探索,把这些工作流程和 Agentic 工作流结合起来。现在还在摸索阶段,但方向是明确的。

 

Q8:AI 有很多潜力,但也有潜在负面影响,比如加剧社会不平等。作为创业者,怎么在快速迭代和负责任之间取得平衡?

 

吴恩达:看你心里怎么想。如果你真觉得某个产品不会让人们变得更好,那就别做。听起来简单,其实很难。AI Fund 确实砍掉过一些项目,不是因为赚不赚钱,而是觉得这东西就不该存在。

 

同时,我觉得让更多人掌握 AI 也很重要,比如我们团队市场部的同事都会写代码,效率比不会写代码的人高很多。不是只有工程师才需要懂 AI,每个岗位都会因 AI 而更高效。所以,让更多人参与进来是我们应该做的事情。

 

Q9:现在大众对 AI 能力和现实之间存在很大认知差距。您觉得有必要普及 AI 基础知识,让更多非技术人理解 AI 吗?

 

吴恩达:我觉得这种知识会慢慢扩散开。我们在做这方面的工作,但我看到两个风险:第一个,如果普及速度不够快,可能形成类似手机行业 Android 和 iOS 两个超级平台的格局,创新被限制;第二个,有人故意夸大 AI 危险,借机打击开源,推行管制。这已经发生了,比如加州的 SP1047 法案,幸好被挡下来了。

 

有些公司和监管部门说的话,根本不是真实情况,只是为了掌握 AI 大模型的话语权。如果这种法案真被通过了,可能以后只有少数几家公司有资格发布大模型,其他创业公司根本没法做。

 

所以保护开源,依然很重要。我们过去取得了一些胜利,但这场仗还在继续。只有保护了开源,AI 知识和能力才会真正散播到每个人手里。

 

原文链接:

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

2025-07-13 07:008312

评论 2 条评论

发布
用户头像
代码不重要:结果就是最终都是火葬场
2025-07-15 13:56 · 北京
回复
赞同 只管杀不管埋
2025-07-15 21:00 · 四川
回复
没有更多了

Redis学习笔记(散列类型)

编程随想曲

redis

关于 DeepL 机器翻译能力

梁帅

产品 互联网 机器翻译 谷歌Google DeepL

系统的安全性设计

Janenesome

读书笔记 程序员 架构 安全

最好的汇报是不需要汇报

伯薇

团队管理 领导力 沟通 汇报 可视化

Java并发编程基础--Synchronized

Java收录阁

线程

测试驱动开发英制单位转换

escray

学习 CSD 认证实战营

JAVA小抄-001-Retrofit初级使用

NoNoGirl

retrofit okhttp

去中心化网络,不止区块链(一)

石君

区块链 去中心 去中心化网络 DHT

道德和正确的认知

沈传宁

信息安全 计算机道德

谨防常见的一些数据误区

Yanel 说敏捷产品

产品 产品经理 产品设计 产品开发 产品推荐

Panzoid:一款超好用的片头制作工具

千锤百炼锅

学习 产品 效率工具 工具 产品推荐

iTerm2使用小技巧-密码管理器

小菜与老鸟

iTerm

牛排等级之美国篇

地藏@易果18916037281

在 TypeScript 处理空值异常

寇云

typescript 大前端

人生需要做减法:少即是多

我心依然

程序员 人生 减法 少即是多 less is more

一个英语渣的自救手册

寇云

学习 程序员 效率工具 工作效率

不安全的“安全密码”

沈传宁

信息安全 口令安全

吾谈教育

ItsFitz

[MySQL-InnoDB] Buffer pool 并发控制

ba0tiao

MySQL 数据库 innodb

jenkins集成maven获取远程项目

kcnf

我为什么不买Mac

Winann

效率 效率工具 Mac apple

一杯茶的时间,上手 Docker

图雀社区

node.js react.js Docker

DIY 可用性测试

Yanel 说敏捷产品

产品 产品经理 产品设计 测试 产品推荐

性能优化第一课:性能指标

kimmking

性能优化

Ubuntu 20.04 装机手册

小柒

Linux #Ubuntu #geek

回"疫"录(9):守住我们自己的净土

小天同学

疫情 回忆录 现实纪录 纪实

深入理解Java中的Lambda表达式和函数式编程的关系

jerry

Lambda java8 函数编程

写文章的目的是什么?

小天同学

思考 写作 感悟 表达

权限系统设计的一种解法

kos

产品 总结 产品设计

《通往财富自由之路》——day1

轩呀

得到

创新真的可遇不可求么?

Yanel 说敏捷产品

产品经理 产品设计 产品开发 产品推荐

一个月重写三次代码库、三个月就换套写法!吴恩达:AI创业拼的是速度,代码不重要_AI&大模型_褚杏娟_InfoQ精选文章