• 请不要在回答技术问题时复制粘贴 AI 生成的内容
duanshiwen
V2EX  ›  程序员

AI 编程时代, MVP 思维已经失效了?

  •  
  •   duanshiwen · 11h 36m ago · 1695 views

    最近在用 Rust 写一个 AI Agent 操作系统内核,叫 Agent OS 。37 个 crate ,1232 个测试,用 craft agent 都写了十几天。

    不止一个朋友问过我:你为什么不先用 Python 快速搭个原型?先验证需求,等跑通了再用 Rust 重写。

    以前我会觉得这是个好建议。但这次我拒绝了。

    原因很简单:我在用 AI 编程的过程中,逐渐意识到一件事——在 AI 时代,MVP 那套"先简后优"的逻辑,前提已经不存在了。

    传统 MVP 的核心假设是:简易实现和高质量实现之间有显著的成本差,先用低成本验证,验证通过再投入。这个在人写代码的时代是成立的——用 Python 写个原型 2 天,用 Rust 写生产级实现 2 周,差 10 倍,所以先做简易版合理。而且代码是你自己写的,你理解每一行,以后重构只是时间问题。

    但现在你对 Cursor 说"用 localStorage 存数据"和说"用 PostgreSQL 加连接池和事务管理",生成时间差不了几分钟。既然成本一样,为什么要做简易版?

    更要命的是第二点:AI 生成的代码是黑箱,你大概率没法有效重构。

    去年帮一个朋友用 Cursor 做了个小工具的 MVP ,需求很简单,AI 几分钟就生成了能跑的代码。两周后他想加个功能,打开代码,完全看不懂。不是因为代码乱,而是他不知道 AI 为什么这样写。最后他选择让 Cursor 重写一遍,而不是在原有代码上改。

    这就是问题所在。你以为"以后再优化",但你连哪里需要优化都不知道,因为你从未理解过这段代码。

    所以我做 Agent OS 的时候,做了一个在很多人看来反直觉的决定:每一个架构决策都自己做,AI 只负责执行。

    选语言的时候,用 Python 或 TypeScript 写个 Agent 框架,AI 几小时就能生成一个看起来很完整的 MVP 。但我选了 Rust ,理由很具体:Agent 系统需要长期运行、需要内存安全、需要跨平台——这些需求第一天就是确定的,不会因为用户量上来了才变成需求。

    设计原则也是。我定了"事件溯源"——每一次操作都记录,可以回溯和重放。这在 MVP 阶段看起来是多余的,但当你的 Agent 在凌晨 2 点做了个错误决策,你需要知道它为什么做了这个决策。这不是"以后再加"的事,因为你以后根本不知道要加在哪里。

    测试也一样。1232 个测试,每个模块合并前必须通过。AI 帮我写了很多测试,但测什么、怎么测、边界条件是什么——这些是我决定的。AI 很擅长为自己的代码生成"能通过"的测试,这就像自己出题自己答,当然满分。

    Andrej Karpathy 自己也承认过:"代码超出了我的理解范围。当 AI 修不了一个 bug 时,我就让它随机改,直到错误消失。"这是 OpenAI 联合创始人说的,不是什么新手的窘境。

    我的选择是不让代码超出我的理解范围。哪怕前期慢一点。

    有人会说这样不是更慢了吗?前期确实更慢。但到现在,每个模块都可以独立修改而不影响其他模块。我知道这个系统的每一块是怎么工作的。

    而那些用 AI 快速搭 MVP 的项目呢? 63% 的开发者说调试 AI 生成代码花的时间比自己写还多。470 个 GitHub PR 的分析显示,AI 生成代码出现重大逻辑错误的概率是人写的 1.7 倍,安全漏洞概率是 2.74 倍。

    AI 编程还带来了一种新的技术债,和传统的不一样。传统技术债你知道它在哪——那个 hack 、那个 TODO 、那个硬编码。AI 编程的技术债是隐形的。

    一种叫理解债:代码能跑,测试全过,但没人能解释它为什么这样工作。调试一段你不理解的代码比调试自己写的慢 3 到 5 倍,而 AI 大幅增加了你代码库里"不是你写的"代码的比例。

    一种叫同质债:不同公司、不同产品、不同需求的团队,用 AI 解决同一个问题会得到几乎一样的代码。AI 给你的是互联网上最受欢迎的解法,不是最适合你系统的解法。农业里叫单一栽培——高产但脆弱,一场病全军覆没。

    还有一种叫归属债:开发者从代码的作者变成了策展人。出问题时第一反应不是理解原因,而是让 AI 重新生成。一位资深工程师说得很直接:"AI 为当下而建,不为将来而建。它对自己生成的东西没有维护的利害关系。"

    这几种债有个共同特点:你的仪表盘全是绿色的。Sprint 速度在涨,PR 合并更快,测试覆盖率 94%。一切看起来很好。直到有一天你需要改一个功能,发现没有任何人知道该从哪里改起。

    所以我的想法是:在 AI 编程时代,别再用 MVP 思维了。直接一步到位。

    不是说花三个月做完美产品再上线。AI 已经把构建高质量实现的时间成本压到和简易版差不多了。关键是你的思维方式要从"先简后优"变成"一步到位"——对 AI 描述你要的终态而不是最简态,架构决策由人来做而不是交给 AI ,关键路径必须是人类彻底理解的。

    真正的快不是写得快,是改得快、修得快、迭代得快。如果你连自己的代码都不理解,你根本快不起来。

    AI 编程的本质是黑箱。你可以让黑箱帮你写代码,但你不能让黑箱帮你做决策。你没法重构一个你不理解的东西。

    19 replies    2026-05-31 05:32:33 +08:00
    mindddd
        1
    mindddd  
       11h 29m ago
    为啥不看代码,是自己懒还是被 ai 控制了
    passive
        2
    passive  
       11h 28m ago via Android
    所以老大已经不再用小岗村模式了。
    lscho
        3
    lscho  
       11h 27m ago
    从个人体感来说是这样的,以前是开发成本太高,才需要做 MVP 之后慢慢迭代。

    但是现在 ai 时代,开发成本压缩到极致,反而是不可控的工程后续迭代成本在升高。

    所以不如一步到位。
    VeteranCat
        4
    VeteranCat  
       11h 25m ago   ❤️ 1
    最佳工程实践是人摸索出来的,不是 ai 摸索出来的。AI 只能模仿最佳实践,他懂个毛线最佳实践。

    所有最佳实践和设计模式,都是人总结出来的,ai 是总结不出来的。 把 AI 神话对于开发者这个群体来说,是最不应该出现的一种情况,你是个工程师唉。
    sinstar
        5
    sinstar  
       11h 14m ago
    工程角度可能确实有范式转移,但是大家还不是很清晰。

    但是商业角度,快速去市场试错,这一点应该没错。
    ndxxx
        6
    ndxxx  
       10h 52m ago via Android
    部分同意。不过还是看开发者水平,连 MVP 都玩不明白的,直接一步到位更是痴人说梦。

    LLM 时代的一般 MVP 现状 be like:纯一次性的/过度工程化且依然没有扩展性/屎山代码量爆炸难以维护哪怕用 LLM 都会轻易上下文爆炸的那种(尽管仅是 MVP )。

    LLM 时代当然也能做出优质的 MVP ,只不过我目前看到过的基本都是上面那种😁
    Parva
        7
    Parva  
       10h 16m ago
    前半部分不赞同。感觉很多程序员对 mvp 的理解都太狭隘了,以为 mvp 是“先糊一坨代码”,然后再用技术债、重构成本去反驳它。

    mvp 的本质是“先用最低成本验证关键假设”。跟代码无关,跟 ai 不 ai 也无关,你能连 Python 都不写,用 gpt-images2 做效果图、seedance2.0 做个演示视频给用户看,就能完成那最关键的假设的验证,这就是 mvp 的操作。

    后半部分对 AI Coding 管控操作分析得挺好。
    WngShhng
        8
    WngShhng  
       10h 5m ago
    为什么你就一口咬定“AI 编程的本质是黑箱”,然后否定 MVP ,而不是“AI 编程就不应该是黑箱”呢?难道你开发了一个版本之后,后续就一定不需要任何改动吗?
    zbinlin
        9
    zbinlin  
       9h 59m ago
    现在的 AI 最合适我这种一开始想太多的人
    kneo
        10
    kneo  
       9h 26m ago via Android
    你以为:我用 rust 直接一步到位,不用原型。

    实际:你让 ai 用 rust 搞了个原型。然后不停推翻重来,每次重来不忘让 ai 帮你写篇长篇大论当干货。
    shoaly
        11
    shoaly  
       9h 14m ago
    @kneo #10 总结的很好, 我有个朋友也在做一样的事情, 我称之为炼蛊
    oopc
        12
    oopc  
       9h 8m ago
    说了这么多, 我更感觉是把 Python/TS 换成了 Rust, 但不是说换了语言, 就没了 MVP... 你自己都说了 "真正的快不是写得快,是改得快、修得快、迭代得快。"
    shyrock2026
        13
    shyrock2026  
       8h 50m ago
    恰恰相反啊,有了 AI 迭代可以飞快,成本极低。无论你堆了多少功能,第一次上线的版本,他就是一个传统意义上的 MVP 。
    billccn
        14
    billccn  
       8h 46m ago
    等等。。。国内两周现在要工作 20 天?
    xing7673
        15
    xing7673  
       8h 9m ago
    你这套逻辑只能做你自己的个人产品
    涉及到企业级的 infra 这种工作,如果你打不出可解释性是不可能被采纳的

    你这套方法论无法 cover 太多场景
    drealism
        16
    drealism  
       7h 49m ago
    其实我关心现在 AI coding 时代, 测试驱动还适用不. 自己的项目暂时还没试过, 有没试过的兄弟聊聊?
    GeruzoniAnsasu
        17
    GeruzoniAnsasu  
       7h 34m ago   ❤️ 1
    我怀疑 OP 理解错了 MVP 的含义——字里行间总感觉 OP 认为的「 MVP 」是那种「随便糊一个 demo 拿去骗投资人」的东西,然而这个词完全不是这个意思啊

    一个有单一亮点的、自洽的、能最小化验证 idea 的产品才是 MVP ,「 MVP 思维失效」是指? 这个验证产品是不需要最小化了还是不需要自洽了? 并不影响啊



    任何产品都不可能一步到位的原因并不出在生产侧,而是在需求侧。不管 AI 或任何生产工具/开发力再怎么提升,你永远没办法一次性了解你潜在用户的所有需求,不可能一次性完全满足。
    msg7086
        18
    msg7086  
       3h 26m ago
    不对,完全不对。
    我之前做一个项目就是先用 python 或者 ruby 糊一个 mvp 出来验证可行性,通过以后再切到 java 上重新设计架构实现。
    至于代码不能超出理解范围,那对于简单项目可行,复杂的就别想了,大部分人都没到那个水平。
    Asimov01
        19
    Asimov01  
       1h 29m ago
    我反而认为 MVP 更重要了。AI 让低成本堆功能变得更容易更快,但是人的时间/注意力始终是有限的,能够控制住自己用 AI 一直堆功能的欲望反而更重要了,一个产品无法一步到位从来不仅仅是技术实现成本的问题,还有市场,场景,真实的用户反馈,产品边界等等的考虑。POC -> MVP -> Product iteration loop 的路线反而更重要了。
    About   ·   Help   ·   Advertise   ·   Blog   ·   API   ·   FAQ   ·   Solana   ·   952 Online   Highest 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 68ms · UTC 23:02 · PVG 07:02 · LAX 16:02 · JFK 19:02
    ♥ Do have faith in what you're doing.