过去一段时间，关于AI产品开发有一种很流行的说法：产品经理会被取代，一个人的公司会成为主流，软件产品会像搭积木一样被快速生产出来。
我个人相信后半句的“搭积木”，却不信前半句的“被取代”。这个论断听起来很契合当下的技术情绪，也太适合被做成各种AI开发教学视频了——屏幕上一开AI编程工具，敲几句提示词，页面出来了，按钮能点了，数据库也连上了。于是结论似乎顺理成章：你看，产品经理不需要了，研发团队也不需要了，未来一个人就能造出一堆产品。
但这个结论最大的问题，不是激进，而是它把产品设计和开发想得太小儿科。
人人都会做饭，并没有让厨师消失。
人人都能拍照，也没有让摄影师成为历史。
人人都能写字，更没哪个作家是因为打字快而成名的。
一个行业特定岗位的真正价值和能力，往往不在最容易被看到的那个动作里。把代码生成等同于产品开发，和把会做一道菜等同于会开一家餐馆，本质上是一回事。
眼下众多AI开发演示，表面上是秀技术进步，实际上是在展露一种对行业的误读。它把产品开发压缩成“我有一个想法，AI帮我实现”，把需求分析压缩成“我写一段提示词”，把团队协作压缩成“我让AI改一下”，把质量验证压缩成“它看起来能跑”。这种简化当然利于传播，因为复杂的事一旦被讲清楚，流量就不太好看了。大众更爱看“魔法”，而不是魔法师在后台做道具、修道具、苦练手速。
做得快，不等于做得对
AI对软件开发的提升是实打实的——它能更快生成代码，更快补测试，更快解释框架，更快定位常见错误，也能帮个人开发者把想法快速变成原型。但问题在于，效率提升的只是某些个人执行力中的部分动作，而不是团队的协作能力，更不是成果输出的品质。技术只是让一个原本不知道要做什么的人，现在可以更快地做出一个不知道为什么要做的东西。
这事儿的吊诡之处在于，越是不了解产品开发的人，越容易相信产品经理只是“画原型的”；越没管理过复杂软件的人，越容易相信工程就是“把功能写出来”。他们看到AI能写代码，就以为软件行业的核心被攻破了。这种判断很像看见别人切菜快，就觉得后厨管理、菜单设计、食材采购、成本控制、出餐节奏通通不重要了。说严重点，这不是技术乐观主义，这不过是去自助餐厅吃了一顿后产生的管理自信。
用户是谁？为什么要用？原来的流程哪里有问题？哪些需求是真需求，哪些只是用户随口一提？哪些功能必须做，哪些做了反而破坏体验？哪些限制来自历史系统，哪些又来自组织结构？这些问题，都不是AI写几段代码就能搞定的。它可以把答案写得更像答案，但如果问题本身就错了，答案越完整，结果越糟糕。自“软件工程”的概念诞生起，产品设计与开发里的诸多难题，从来都不是“代码实现不了”的问题。
需求说不清，AI只会更快地制造混乱
到目前为止，我还没看到一篇真正严肃的、用AI做软件设计与开发的完整案例。这里说的“严肃”，不是工具用得多，不是提示词写得长，也不是视频里终端滚动得很有压迫感，而是它能不能把一个真实的产品问题交代清楚：业务目标、用户场景、约束条件、验收标准分别是什么？为什么选这个方案而不是另一个？哪些事这次不做？后续出了岔子怎么追踪和回滚？
很遗憾，目前大量示例仍停留在工具教学层面。它们教观众如何打开Codex或Claude Code，怎么输提示词，怎么让AI生成登录页、看板页、聊天窗口或待办事项应用。就像一个人演示自动炒菜机，先把肉、青椒、调料都备好，倒进去，一按按钮，几分钟后菜就出来了。演示很精彩，可现实厨房里最难的部分，往往不是最后那几下翻炒。
真实的工程场景更像这样：有人洗，有人切，有人炒，有人摆盘；顾客要求不放青椒、不放葱，可菜单上写的是农家小炒肉；老板还要求成本不能涨；旁边一桌已经在催菜；后厨新来的把蒜苗和葱分不清楚。这时候，自动炒菜机依然有价值，但它解决的只是其中一段流程，它不会替你判断顾客为什么不吃青椒，也不会替你承担上错菜后的差评。
软件产品开发中的AI应用也是如此。它可以提高某些环节的效率，但不能自动生成对业务、用户、约束和责任的理解。更糟糕的是，如果需求本身一团模糊，AI的效率反而会放大混乱。过去一个模糊需求可能要经过好几轮会议才暴露问题，现在AI可以在几分钟内把它实现成一个看起来很完整的系统——界面有了，接口有了，表结构也有了，甚至说明文档都写好了。唯一的小问题是，它可能从一开始就不该这么做。这不能怪AI，就算怪了，AI也不会脸红。
Vibe Coding 不是工程化软件开发
现在所谓的Vibe Coding，主要还是从0到1，实现作者脑子里的一个想法。它更接近个人创作、快速原型和灵感验证，而不是工程化的软件产品管理。这个边界必须说清楚，否则就很容易把“我做出了一个东西”误解成“我掌握了产品开发”。前者是能力的一部分，后者是能力、经验、组织和责任的组合。
从0到1的个人项目，面对的是“我想要什么”；工程化产品开发，面对的是“在这些限制下，我们还能交付什么”。前者可以靠灵感驱动，后者必须靠约束驱动。前者失败了，大不了删掉重来；后者失败了，可能影响客户、收入、数据、流程和团队信任。个人项目可以不写迁移方案，不考虑权限继承，不处理灰度发布，不解释为什么这个功能这次不上线。企业项目不行，它有一个很朴素的特点：现实不会因为你 Vibe Coding 得不错就自动配合你。
多人协作也不是把任务拆给几个人那么简单。真刀真枪的软件协作，首先要求大家对同一个问题形成相对一致的理解。产品经理写需求文档，不是为了生产废纸，也不是为了给流程盖章，而是为了让研发理解边界，让测试理解验收，让设计理解取舍，让运营理解影响。
所以，Vibe Coding 的问题不在Coding，而在Vibe。它适合表达个人意图，却不天然适合管理组织复杂度。一个人脑子里的想法，可以凭感觉往前冲；但一个团队面对真实客户、历史系统和预算周期，就不能只靠感觉。感觉当然重要，可感觉不能报销，不能写进SLA，更不可能在客户投诉时代表公司出来道歉。
真正的产品经理价值，不在于把话写进PRD，而在于把模糊的问题变成可讨论、可取舍、可实现、可验证的方案。他需要判断用户表达背后的真实诉求，识别业务方没说出来的约束，拆掉看似合理但代价高昂的功能，阻止团队在错误方向上高效狂奔。高效狂奔当然也算一种进步，只不过如果目的地是悬崖，跑得快通常不是什么好事。
严肃的AI产品开发，应该展示难题而不是遮住难题
如果真要深入讨论AI如何改变软件产品开发，重点不应该是怎么写提示词生成页面，而应该是AI如何进入真实的生产流程。一个严肃的案例应该展示：需求如何澄清，方案如何比较，边界如何定义，任务如何拆分，风险如何识别，测试如何设计，上线如何控制，反馈如何进入下一轮迭代。代码生成当然是其中一环，但它不是全部，更不是最能证明产品能力的部分。
比如一个企业内部系统改造，真正的问题可能不是“生成一个后台管理页面”，而是旧系统的数据字段混乱，部门之间对流程理解不一致，权限模型多年无人维护，领导希望本季度上线但一线员工根本没时间解决技术债务，甚至没真正弄懂业务逻辑。
AI可以让产品原型更快出现，原型即需求，需求即原型，却不能让错误决策变成正确决策。所以，一个真正有价值的AI产品开发案例，不应该只展示“我如何让AI写出代码”，而应该展示“我如何让AI参与复杂产品问题的形成、拆解、验证和迭代”。前者是工具教程，后者才接近产品实践；前者解决的是观众的好奇心，后者才解决团队的真问题。
所以，别急着宣判产品经理的消失。AI可以帮你炒，帮你切，甚至根据菜谱建议火候，但它不知道为什么这桌客人不吃青椒，也不知道老板为什么既要降成本又不想挨差评，更不知道后厨今天少了两个人意味着什么。
软件产品也一样。 AI可以写代码，但它不知道这个功能为什么该做，为什么不该做，什么时候做，做到什么程度，以及做错了之后谁来承担代价。这才是产品经理没那么容易被取代的根本原因——尤其是真正的产品经理，而不仅仅是画原型图的那类。这也恰恰是很多AI开发演示最不愿意，或者说根本无法展示的部分。
工具越先进，我们越应该尊重复杂工作本身。否则，所谓未来的生产力，最后很可能只是把外行的自信，批量生成得更快了一点。
发表于 2 小时前
|
查看: 6|
回复: 0
