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

5 月 30 日
 duanshiwen

最近在用 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 编程的本质是黑箱。你可以让黑箱帮你写代码,但你不能让黑箱帮你做决策。你没法重构一个你不理解的东西。

5571 次点击
所在节点    程序员
31 条回复
mindddd
5 月 30 日
为啥不看代码,是自己懒还是被 ai 控制了
passive
5 月 30 日
所以老大已经不再用小岗村模式了。
lscho
5 月 30 日
从个人体感来说是这样的,以前是开发成本太高,才需要做 MVP 之后慢慢迭代。

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

所以不如一步到位。
VeteranCat
5 月 30 日
最佳工程实践是人摸索出来的,不是 ai 摸索出来的。AI 只能模仿最佳实践,他懂个毛线最佳实践。

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

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

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

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

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

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

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

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

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



任何产品都不可能一步到位的原因并不出在生产侧,而是在需求侧。不管 AI 或任何生产工具/开发力再怎么提升,你永远没办法一次性了解你潜在用户的所有需求,不可能一次性完全满足。
msg7086
5 月 31 日
不对,完全不对。
我之前做一个项目就是先用 python 或者 ruby 糊一个 mvp 出来验证可行性,通过以后再切到 java 上重新设计架构实现。
至于代码不能超出理解范围,那对于简单项目可行,复杂的就别想了,大部分人都没到那个水平。
Asimov01
5 月 31 日
我反而认为 MVP 更重要了。AI 让低成本堆功能变得更容易更快,但是人的时间/注意力始终是有限的,能够控制住自己用 AI 一直堆功能的欲望反而更重要了,一个产品无法一步到位从来不仅仅是技术实现成本的问题,还有市场,场景,真实的用户反馈,产品边界等等的考虑。POC -> MVP -> Product iteration loop 的路线反而更重要了。
junksheng
5 月 31 日
MVP 更重要了, 自从有了 Agent, 我就有了产品 MVP, 架构 MVP...先给领导和产品经理 demo, 讨论效果和改进点. 然后有架构 MVP, 和 mde 讨论哪种架构更好, 选择架构. 这样有了一套清晰的功能/架构规划, 开始写测试用例, 最后才是生成

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/1216691

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX