V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
欢迎通过 V2EX 的 创造者 节点寻找创业伙伴。
推荐书目
Founders at Work 简体中文译本
Founders at Work
zisen
V2EX  ›  创造者

关于快速迭代理论的思考

  •  1
     
  •   zisen · 2 天前 · 1136 次点击

    首先是在 b 站刷到了这个 OpenAI 员工翁家翌的访谈视频:
    翁家翌:OpenAI ,GPT ,强化学习,Infra ,后训练,天授,tuixue ,开源,CMU ,清华| WhynotTV Podcast #4

    访谈视频中翁家翌提到他是 OpenAI 的 infra ( LLM 基础设施)建设的,在他的观点看来,哪家 ai 公司更有能力看的并不是谁家的模型又上了 Benchmark 排行榜第一名,而是公司内部的 infra 的对于 llm 的迭代速度。

    视频中他提到,OpenAI 内部用于训练 ChatGPT 的 infra 已经是三年前搭建的了,而他们仍然还在准备新一代的 infra ,这是 OpenAI 面对 DeepSeek, Gemini, Claude 时较为乏力的原因,这些后来者的 infra 比 OpenAI 的更加先进,这意味着他们可以更快地对 LLM 进行迭代。

    随后又刷到了美国战争部长去 SpaceX 向 Elon Musk 取经的视频:
    美国防部长走访马斯克星舰基地!要把第一性原理搬到五角大楼!

    Musk 的 SpaceX 或者说 Tesla 的成功原因,一个是他的“第一性原理”,另一个就是他的“快速迭代理论”。

    快速迭代理论说的是:并不是从一开始就做一个完美的产品,而是先做一个差不多的产品,然后用最快速度去逼近完美。

    而 Musk 的星舰基地,就是一个快速迭代的平台,这个星舰基地有充足的资源让他可以不断试错不断发射失败,发射失败的速度越快,他距离成功的速度也就越快。

    同理,回到 LLM 的迭代中,各家 AI 公司其实真正需要的不是一个牛逼的算法或者架构,而是可以最短时间内验证一个 idea 的能力,任何人有 idea 或者算法都可以在最短时间内集成到产品中去,从而判断是否可以加强产品能力。

    这也是 DeepSeek 在 2025 年初能够释放重磅炸弹的原因,幻方量化有足够的 infra ,才能实现他们各种颠覆性的 ideas 。

    LLM 的 infra 是 AI 公司的算力基建和训练管道,而对于普通程序员或者独立开发者来说,其实 idea 并不重要,因为这个世界上有太多的 idea 了,在 idea 落地之前,没人知道这个 idea 能否成功,重要的是实现 idea 的 infra ,也就是现在的 coding agent 。

    因此,作为开发者,在 2026 年,一个 idea 落地的效率大大提高,因此没有必要再去问值不值得做,而是先 vibe coding 一个最简单的核心出来,然后看市场反馈,如果反馈好那么使用快速迭代理论来疯狂地接近成功。

    另外再举一些生活中的例子,比如你想开一家咖啡馆,而你本身并没有开咖啡馆的经验,你要做的不是花几十万重金盘下一个店面装修再购买数万元的设备,而是使用最低成本:买二手设备,租便宜店面,先简单装修等等压缩成本的方式开一家咖啡馆,然后看自己能不能开好这家咖啡馆,如果营业不下去了就倒闭,然后总结经验,继续开始下一次试错。

    到目前为止想的就这么多,本想用 AI 优化一下排版,但是不希望 AI 代理我的语言输出,大家将就看吧。

    14 条回复    2026-01-18 23:36:31 +08:00
    sillydaddy
        1
    sillydaddy  
       2 天前
    讨论一个实际问题:
    那比如说,我现在真的在做一个 youtube 频道,在做它的第一个视频,关于加密货币的 AMM 机制,也可以说 V 币的科普的。现在遇到的问题是,我科普这个东西,需要做 8 ~ 9 个动画,每个动画都比较耗费时间(甚至需要自己编写的软件去做),那这些动画是不是要做呢?还是直接讲解概念呢?
    zzlyzq
        2
    zzlyzq  
       2 天前
    可以先写一个 text ,需要有哪些东西。(当你写完后,可能注意力会下降,需要休息)
    过了一天,你发现,你可以再丰富些内容。(做完后,可能又需要休息一下)
    过了一周,你发现,还可以优化,那就再优化一下。
    zisen
        3
    zisen  
    OP
       2 天前
    @sillydaddy 快速迭代理论的第一步就是做一个不完美且低成本的产品(视频),然后依赖快速迭代来接近完美。

    你的第一条视频必须是低成本的,在做视频的角度上来看,就是时间成本,**你需要规划一定的时间,规定自己必须要在这个时间内产出第一条视频。**

    你的核心目标是做一个自媒体,而不是做一个动画软件,因此你首先要将动画的实现约束在现成的动画软件例如基础的 PowerPoint ,高级一点的可以直接做 flash 或者直接让 agent 生成前端动画页面,而你的重心应该放在如何让观众能更好地理解你要讲解的知识,也就是加密货币的原理讲解上面。

    另外也可以采用“第一性原理”的角度来看,就是这个动画效果是不是非得用专业软件制作才能让观众理解你要讲的内容,如果不是,那么没必要走学习成本或开发成本高的路径。

    在你上传完第一个加密货币的视频后,观察观众的反馈(大部分时候没有观众,可以拉身边的朋友或者直接在 v 站发帖推广,据我观察到的 v 站大部分朋友都会认真地提建议),然后基于反馈来进行迭代。

    另外说一下快速迭代中的迭代速度这一点,迭代速度确实基于 infra 的成熟程度,这里 infra 可以是你自制的动画软件,但前提是,你搭建的 infra 是逻辑清晰,稳定有效的可以用于快速迭代的一个基础设施,如果你只是想试试自媒体起一个号看看效果而不是想辞职全职做自媒体,那么这个动画软件是彻底没必要的。如果真的到了要开发动画软件的地步,也可以基于快速迭代理论来开发,这里就不细说了。

    Musk 曾经在 2017 年开发 Tesla Model 3 的时候,搞了一整套自动化机器人流程,结果这些流程差点让 Tesla 破产,因为这些机器人机械臂并没有像他预期的那样高效率的工作而是不断地出现小 bug ,而修复机器人产线 bug 远比人工来得慢,最后他把机器人产线拆除,重新使用人工来组装 Tesla 。这个例子换到你的例子里面,就是你的动画软件大概率不能助力你的视频产出,而你会消耗大量的精力在开发动画软件上面。你需要等到视频制作流程成熟稳定后,开始考虑使用软件来自动化迭代你的视频。
    sillydaddy
        4
    sillydaddy  
       2 天前
    @zisen
    感谢你的详细回复。最后的马斯克的例子让人印象深刻。

    低成本这块我确实做的很不好。你说的对,我的核心目标是自媒体,更准确的说是将自己的想法表达出来,确实如此。但正因为如此,所以我觉得第一个视频或者第一百个视频的受欢迎与否,不影响这个核心的目标。所以我才去做用于快速表达的工具的,也就是上面提到的软件。结果一做就是几个月,用玩笑话就是为了一碗醋包一顿饺子。但要是从核心目的来看,它并没有问题——为的是快速表达出想法。

    在尝试做的第一个视频中,这样的图画了有 9 个左右:


    然后为了构建这个动画,在自己制作的软件中,建了这么些节点图:


    这成本确实高的离谱,但我其实是寄希望在,这些高成本的东西,到后面能越来越流畅快速和低成本。其实我也不太肯定这一点。

    我刚才也跟 AI 讨论了一下,它确实提到了一点,可以尝试现有的,例如 Manim 这个开源的数学动画制作软件,而不是自己去建这样一个软件。一下子击中了我的要害:我确实没有尝试用 Manim 这个东西。

    我写到这里感觉自己确实有些在重蹈 Musk 的覆辙。当时想的仅仅是 Manim 是专为数学可视化而生的(其实这点我都不是很肯定),而自己的工具是较为通用的。。
    sillydaddy
        5
    sillydaddy  
       2 天前
    刚才说漏了一点,做自己的工具,核心目的是为了快速表达,例如使用 node-based 这样的工具,而 Manim 这样的编程工具,不符合自己的要求。当然,这是自己的一个假设( node-based 的工具可以更快表达)。总之这里的逻辑很乱,总感觉快速迭代,就卡在这个自己认定需要长期打磨的工具上面了。
    sillydaddy
        6
    sillydaddy  
       2 天前
    我发现这里的核心矛盾点了:自己认定这个工具需要长期打磨,但这个工具前期不好用,导致效率慢(比学其他软件,或者使用现成的 Manim 更慢)。这时候该怎么办?
    zisen
        7
    zisen  
    OP
       2 天前   ❤️ 1
    @sillydaddy 如果你的核心目标还是自媒体而不是开发动画软件,从低成本角度考虑,建议搁置现在这个自制的动画软件,用现成的工具(我经常看的一个讲 LLM 原理的博主[飞天闪客]( https://www.youtube.com/@%E9%A3%9E%E5%A4%A9%E9%97%AA%E5%AE%A2)就是用 PowerPoint 做动画的,你可以看看他的置顶视频,我觉得能把 LLM 原理讲明白的动画用来讲解加密货币应该没什么问题。

    如果你仍然不肯放弃自研动画软件,可以看看下面的话:

    依然从 Musk 的例子来套用你的现状,他在造车流程非常成熟之后,在上海超级工厂搭建初期,依然没有直接全套使用机器人自动化,而是采用人机协同来规避 bug ,等到人机协同成熟后,他再慢慢将人替换为机器,最终实现全套机械化产线。

    因此关于你的动画软件,你可以先实现一个 MVP 来制作 9 个图里都会出现的重复的动画,然后结合人工 PowerPoint 编排去实现一些现阶段只会使用一次的效果。而不是从一开始就寄希望于你的动画软件可以完美实现所有你期待的动画效果。等到后期你的视频内容越来越多,有大量的讲解开始需要重复的动画效果,这个时候你再去给你的软件加上这些动画效果。

    看得出来你是一个完美主义者,认为磨刀不误砍柴工,但如果你真的要做自媒体,那我建议你不要再去打磨这个动画软件了,除非你的目标变成开发一款动画软件。
    cxtrinityy
        8
    cxtrinityy  
       2 天前 via Android
    快速迭代并不意味着是低成本迭代,从你最后举的咖啡馆例子看,你可能有点混淆两个概念,看你如何看待“最低成本”和“低成本”。
    成本不论如何降低,都存在一个合理可接受的下限,这也就意味着很多人并没有迭代的资本,从资金成本到时间成本,始终存在一个可行性考量,很多人可能只有一次机会,第二次机会是在第一次并不是很失败的前提下获得的。最后又落回了原来的逻辑,在第一次就把事情尽可能做好。
    开发者现在“具有”快速迭代的能力是因为 ai 的爆发,也就是迭代降本的可能出现了。但同时很多人也反馈 ai 在迭代过程中随着项目复杂度提升存在问题,说明当前“具有”的未必是无限的快速迭代能力,而是有限的。
    同理,你不可能去山沟沟里都是老年人的地方租一个店面开咖啡馆,没有潜在客户意味着没有试错条件,潜在客户少意味着试错结果缺乏可信度,当前的构筑情况可能在能接触更多潜在客户的条件下达成稳定的投入与回报的平衡。
    cxtrinityy
        9
    cxtrinityy  
       2 天前 via Android
    马老板的快速迭代显然和他通过第一性原理来降本是密不可分,现在想想快速迭代不是什么新鲜事,以前还流行敏捷开发,公司接项目也是先跑起来一个 demo 把项目拿下,然后开发人员抱怨着难以维护的屎山一边又疲于奔命的继续拉屎。伊丽莎白•霍姆斯的血液检测诈骗甚至只是先把饼画出来,最后在”迭代”中玩不下去崩盘。
    sillydaddy
        10
    sillydaddy  
       1 天前
    @zisen #7
    这个工具的成本特性,其实不是根据不同的动画特效来划分的,它是一个通用型的机床,更多的成本在基础的构建上,而不是针对不同动画来分别开发。它对不同动画的边际成本是比较低的,通用功能需要 100 个单位时间的话,每个类型的动画开发只需要 1 个单位时间。

    原谅我下面的这些抽象,假如有一个工具,对其的开发时间投入与它的产出效率是:
    第 1 个单位时间的投入,让它的生产效率是 0 件/小时,
    第 2 个单位时间投入,生产效率是 1 件/小时,
    第 3 个单位时间投入,生产效率是 2 件/小时,
    第 4 个单位时间投入,生产效率是 6 件/小时,
    而其他的工具,生产效率是 3 件/小时。

    怎么看待这种工具的研发投入?如果使用其他工具,其实也需要一个从入门到能上手的时间投入,比如你说的 PowerPoint ,问题就更复杂了。

    对于你的建议,现在放弃这个工具的使用,考虑到这个工具已经初步成型了,后续的工具的学习时间成本,我觉得是比学习其他工具要快的。不考虑前面的沉默成本,后面的边际成本是比较低的,所以我还是决定继续使用它。

    但正如你所说的,前面的沉默成本,确实是一个教训,我本来可以做一个工具的 MVP 版本(其实我心里一直在绷着这根弦),但是有时候就是很难做到。比如这个工具中的「复合组件」功能,我统计了一下它的开发时间,耗费了很长时间,本来是可以后面再开发的。类似于你说的,这个工具可以使用螺旋上升的过程,先用起来,再根据使用需求叠加新的特性。不过当局者迷,有时候对开发时间的误判和一些其他心理,让人很难做到。

    总结一下就是这种通用型的基础设施,确实很难把握,如果它的各个迭代阶段比较容易划分,就比较容易处理。如果难以提取出那些核心的东西,大量的时间就容易被裹挟进去。比如当初的「复合组件」功能,我原本以为是可以比较容易开发完成,然后提高不小的制作速度的。
    momocraft
        11
    momocraft  
       1 天前
    迭代之路是有前提的
    1 迭代真的能前进,而且上限要足够高
    2 能活足够长
    zisen
        12
    zisen  
    OP
       1 天前
    @sillydaddy 既然你已经快完成了工具的制作,那在当下这个时间点来看,先做完工具再去做视频确实是更好的选择,不过仍然要谨慎安排你的时间成本,要说服自己接受当前的不完美,精雕细琢的代价就是工期无限拉长。就好比你的老板给你说要下周一做好新需求,你不可能随心所有地按照自己的规范去完善代码,而是在下周一之前给一个能用的版本,有问题后面再说。

    当然这是你自己的项目而不是老板的项目,你可以给自己划定超长工期,不过不断拉长的工期只会消耗人的耐心,因为没有反馈的去做一件事是需要极大的耐力的,很有可能到最后就烂尾了。
    sillydaddy
        13
    sillydaddy  
       1 天前   ❤️ 1
    @zisen 是这样的。所以我觉得,快速迭代的一个核心素质,就是能判断哪些是核心,精力集中在上面。否则耗时过长导致的无反馈,就进一步加剧了畏难情绪,加剧精力的分散,我现在基本就是这样,现在明明工具已经基本成型了,但很长时间都不愿再碰它。
    liminany1
        14
    liminany1  
       1 天前 via Android
    首先是 pdca 循环,然后是敏捷开发,这些都是比较基础的软件开发方法,在国外已经默认都敏捷化了,不谈了,谈更高层的应用场景了
    关于   ·   帮助文档   ·   自助推广系统   ·   博客   ·   API   ·   FAQ   ·   Solana   ·   3190 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 32ms · UTC 00:19 · PVG 08:19 · LAX 16:19 · JFK 19:19
    ♥ Do have faith in what you're doing.