夜雨聆风
Vibe Coding 的下一站不是 App，而是公司内部原型工厂
最近看到一条关于 Stripe 内部 Protodash（可以理解成“原型工作台”）的讨论，我第一反应是：Vibe Coding（氛围编程）这个词，可能又要换一层意思了。
过去我们聊 Vibe Coding，基本围绕两种故事打转。
一种是个人爽文：不会写代码的人，靠 Claude Code、Cursor、Lovable 之类的工具，几天做出一个 App，上线、收钱、截图发 X。
另一种是反面教材：AI 搓出一堆“看起来能跑”的代码，真上线以后权限、数据、支付、性能全是坑。然后大家得出一个结论：Vibe Coding 适合做玩具，不适合进生产。
这个判断没错，但有点不够用了。
因为更大的变化，可能不是“个人能不能靠 AI 做 App”，而是公司开始把 Vibe Coding 放进内部流程，变成一个组织级的原型工厂。
按 Twitter/X 上的说法，Stripe 内部的 Protodash 是一个 AI 原型工具，可以让设计师和 PM（产品经理）快速生成真实、可点击、接近产品形态的原型。这里我不想把它当成某个新工具来写，毕竟公开信息有限，更值得看的其实是它背后的方向：原型生成正在从个人外挂，变成产品组织的基础设施。
个人乱写代码，最多是一个人的项目烂掉。
但公司开始规模化生成原型，影响的就不是某个 App，而是 PM、设计师、工程师之间怎么协作。
个人 Vibe Coding，解决的是“我能不能做出来”
最早的 Vibe Coding 很像一个人的外挂。
你有一个想法，不想花几周学前端、后端、部署、数据库，就把需求丢给 AI：帮我做一个记账 App，帮我做一个 landing page，帮我写一个 Chrome 插件。
AI 很快给你一堆代码。你再复制报错、继续追问、让它修 bug，把东西一点点推到能跑。
这件事让人兴奋，是因为它把“从想法到界面”的距离压得很短。以前你得先找程序员、搭环境、选框架、写样板代码。现在你可以先看到一个东西，再决定它值不值得继续做。
但这里有个坑：个人 Vibe Coding 的默认产物，通常不是产品，而是“能跑的样子”。
它可能没有清晰的数据模型，没有权限边界，没有异常处理，也没有长期可维护的架构。它最擅长的是把想法变成一个看得见、点得动、能录屏的视频。
所以 Reddit 上那条 “Vibe Coding vs. Production reality” 会有那么高的热度。大家不是否认 AI 能写代码，而是在提醒：能生成代码，和能交付一个长期可维护的软件，是两件事。
这个批评成立。
但如果只停在这里，就会错过下一步。
公司内部用 Vibe Coding，解决的是“我们能不能更快理解一个想法”
个人使用 Vibe Coding，目标通常是“我想做个东西”。
公司内部使用 Vibe Coding，目标更像是：“我们怎样更快判断这个想法到底长什么样。”
这两句话差很多。
传统产品流程里，一个新功能从想法到原型，要经过很多层翻译：PM 写需求文档，设计师画线框图，设计评审，工程师评估可行性，再做 demo 或技术验证。
这个过程慢，不只是因为人多，而是每个角色手里的表达工具不同。
PM 用文字，设计师用 Figma，工程师用代码。大家看似在讨论同一个东西，其实经常是在不同抽象层里互相猜。
内部 AI 原型工具的价值，就在于让团队更早拥有一个共同对象。
不是一段需求描述，也不是几张静态设计稿，而是一个能点、能跳转、能模拟流程的产品雏形。
以前大家争论“这个流程会不会太复杂”，现在可以直接点一遍。
以前设计师说“这里需要一个更轻量的引导”，现在可以马上生成几个版本。
以前工程师到很后面才发现某个交互背后藏着复杂状态，现在原型阶段就可能暴露一部分问题。
这就是原型工厂的意义。它不是为了替代工程团队直接交付生产代码，而是让组织更快地把模糊想法变成可讨论对象。
Vibe Coding 到了这里，就不再只是“让非程序员写 App”。它变成了文档、设计稿和正式代码之间的中间层。
原型工厂的好处，是让想法变得可触摸
公司里很浪费时间的一件事，是讨论一个没人真正见过的东西。
PM 脑子里有一个流程，设计师脑子里有一个界面，工程师脑子里有一个系统拆法。等真的做出来，才发现三个人想的根本不是同一个东西。
AI 原型工具最直接的作用，就是降低这种想象误差。
比如一个新 onboarding 流程。过去你可能先写文档，再画十几张 Figma。评审会上大家讨论按钮明显不明显、步骤是不是太长、用户会不会迷路。
但静态稿有个问题：它永远比真实使用更顺。
真实产品的问题，往往出现在点击之间：等待、返回、空状态、错误提示、输入中断、用户不按预期操作。
如果 AI 能快速生成一个可点击原型，团队就可以提前感受到这些问题。产品讨论也会从“我觉得”变成“我们试一下”。
这对大公司尤其有价值。大公司不是没有想法，而是想法太多，验证太慢。每一个想法都排进正式开发队列，工程团队会被拖死；只靠文档和评审过滤，很多问题又暴露得太晚。
AI 原型平台如果用得好，可以变成一个低成本试错层：想法先在这里跑一遍。能跑通，再进入设计和工程流程；跑不通，就早点丢掉。
麻烦也在这里：原型会伪装成产品
问题是，原型一旦变得太像产品，就很容易被误认为产品。
手绘稿不会骗过任何人，大家都知道它只是草图。Figma 再漂亮，也还是设计稿。
但 AI 生成的可交互原型不一样。它有页面，有按钮，有跳转，甚至有假数据、动画和局部状态。对于非技术角色来说，它看起来已经“差不多能用了”。
于是新的组织摩擦就来了。
既然它都能点了，为什么不能直接上线？
既然 AI 已经写了代码，工程师是不是只要整理一下？
既然 PM 和设计师已经把流程跑通了，工程团队为什么还说要重做？
工程师看到的是另一套东西：状态管理是不是合理，权限边界在哪里，异常流程怎么处理，数据模型能不能支撑后续扩展，接口失败怎么办，日志和监控有没有，安全风险在哪里。
这些东西不会出现在漂亮的原型里。
更麻烦的是，AI 为了“先跑起来”，通常会选择最短路径。硬编码、临时状态、假数据、重复逻辑、脆弱组件结构，都可能被包装在一个看似流畅的界面下面。
如果组织没有明确边界，这些原型代码就可能被一路带进生产。原型债变成技术债，技术债再变成维护债。最后工程团队既没参与早期决策，又要为后期稳定性负责。
这才是 Vibe Coding 平台化真正危险的地方。
不是个人写烂代码，而是组织开始批量制造“看起来已经完成”的半成品。
角色边界会被重新画一遍
公司内部有了 AI 原型工厂以后，PM、设计师、工程师的边界都会被挪动。
PM 会更像产品导演。过去 PM 的主要产物是需求文档、流程图、优先级和协调。以后 PM 可能需要直接拿出可交互原型，用它表达需求、争取资源、做用户测试。
这会提高好 PM 的上限，也会暴露差 PM 的问题。文字可以模糊，原型很难模糊。一个流程到底顺不顺，一个页面有没有考虑空状态，一个需求是不是自洽，点一遍就能看出来。
设计师也会被推到新的位置。
如果 AI 能快速生成界面，设计师的价值就不只是“画页面”，而是定义体验标准、判断交互质量、控制视觉一致性，以及决定哪些原型值得进入更严肃的设计系统。
工程师的变化可能最大。
工程师不再只是“把设计稿实现出来”的人，而要更早介入原型评估：哪些部分可以参考，哪些必须重写；哪些交互背后有隐藏复杂度；哪些需求看起来简单，但会破坏系统边界。
所以我觉得，工程师最好不要站在原型工厂的最后背锅，而要站在出口处。
也就是说，组织需要一个明确转换流程：原型可以验证想法，但不能默认进入生产；原型代码可以作为参考，但不能默认成为正式代码；原型评审不只看体验，也要看实现风险；进入工程排期之前，必须完成一次“原型到产品”的边界确认。
这不是为了增加流程感，而是在保护团队。
没有这个边界，AI 原型越强，组织越容易误判交付成本。
公司缺的不是更多原型，而是原型治理
很多团队看到这类工具，第一反应会是：我们也要做一个内部 AI 原型平台。
可以做，但别急着兴奋。
原型生成能力很快会变成标配。真正拉开差距的，不是你能不能生成原型，而是你有没有能力管理这些原型。
一个公司内部如果开始规模化使用 AI 原型，至少要想清楚几件事。
它到底用来干什么？是用户访谈、内部评审、方向探索，还是需求表达？不同用途对质量要求完全不同。
它什么时候归档、什么时候废弃、什么时候进入正式项目？如果没有生命周期管理，内部很快会堆满一堆没人敢删、没人维护、但又被反复引用的半成品。
谁有权把原型推进到工程阶段？如果任何 PM 或设计师都能拿着一个 AI 原型说“这个已经差不多了”，工程团队会非常被动。
原型代码能不能复用？我的直觉是默认不允许。除非经过工程审查，否则 AI 生成的原型代码应该被视为一次性材料，不是生产资产。
原型能不能接真实数据？这点尤其关键。内部工具一旦接入真实用户数据、真实业务接口、真实权限系统，风险就不再是“原型不好看”，而是安全、隐私和合规问题。
所以公司内部原型工厂最重要的不是生成能力，而是边界设计。
没有边界，它就是一个技术债制造机。有边界，它才可能成为组织试错机器。
别把“AI 做原型”当成省工程人力
国内团队很容易误读这件事。
看到 Stripe 用内部 AI 原型工具，就立刻想到：那我们是不是可以少配几个前端？是不是 PM 自己就能把需求做出来？是不是设计师可以直接交付代码？
这个方向大概率会出问题。
AI 原型平台的价值，不是用非工程角色替代工程师，而是减少正式工程投入之前的无效沟通和错误方向。
它省掉的不是工程质量，而是早期探索成本。
如果把它当成省人力工具，结果通常是前期看起来更快，后期修起来更贵。因为原型阶段越随意，进入生产时补的账越多。
更健康的做法，是把 AI 原型平台放在“需求发现”和“正式开发”之间。
它可以回答：这个想法有没有感觉？用户路径是不是顺？核心交互能不能成立？几个方案里哪个更值得继续？
但它不应该直接回答：系统架构是否合理？代码能不能长期维护？功能能不能安全上线？
这些仍然是工程问题。
换句话说，Vibe Coding 进入公司以后，最好的定位不是“让所有人都变成程序员”，而是“让所有人更早看见自己的想法到底长什么样”。
前者会制造混乱，后者会提高组织学习速度。
Vibe Coding 的下一站，是组织学习速度的竞争
如果只看个人创作者，Vibe Coding 的故事很容易变成爽文：一个人，一个 AI，一个 App，一夜上线。
但放到公司内部，它会复杂得多，也更有价值。
公司不缺一个能写代码的人。公司缺的是让想法快速暴露问题的机制。
很多产品失败，不是因为代码写得慢，而是因为团队太晚才发现需求不成立、流程不顺、用户不懂、实现成本过高。AI 原型工厂真正可能改变的，是这些问题暴露的时间点。
它让想法更早变成可触摸的东西，也让团队更早面对一个不舒服的问题：这个东西看起来很酷，但真的值得工程化吗？
所以我不觉得 Vibe Coding 的下一站是更多独立开发者做 App。那当然还会发生，但不是最重要的部分。
更重要的是，它会进入公司内部，变成 PM、设计师、工程师之间的新协作层。
这个协作层会带来速度，也会带来债务；会减少误解，也会制造新的边界冲突；会让原型更容易出现，也会让“什么才算产品”这个问题变得更难回答。
未来真正成熟的团队，可能不是最会用 AI 生成代码的团队，而是最会管理 AI 原型边界的团队。
因为在 AI 时代，生成一个东西会越来越便宜。
但决定什么东西值得被认真做，仍然很贵。
参考来源
- —
Twitter/X: Stripe Protodash vibe coding platform（https://x.com/clairevo/status/2051342163188011323） - —
Reddit: Vibe Coding vs. Production reality（https://reddit.com/r/ClaudeAI/comments/1t3bk3x/vibe_coding_vs_production_reality/） - —
SD Times: AI updates from the past week（https://sdtimes.com/ai/may-8-2026-ai-updates-from-the-past-week-coder-agents-launch-snyk-claude-partnership-opsera-cursor-partnership-and-more/） - —
The Futurum Group: Atlassian Teamwork Graph and Rovo MCP Server（https://futurumgroup.com/insights/atlassian-teamwork-graph-the-secret-weapon-thats-no-longer-a-secret/） - —
YouTube: AI Driven Development | Write Code with AI（https://www.youtube.com/watch?v=5g67pNRCIZk）
