如果你现在做产品，第一反应还是“先写一份PRD”，可能已经慢了一拍。
AI时代的产品开发，最先产出的东西不应该是一份几十页文档，而应该是一版能点、能改、能让团队一起讨论的可交互原型。
我不是说不用写PRD了。
而是说它应该换个位置。
页面布局、交互流程、功能模块，先让原型说话。
权限、数据、异常、跨模块规则，再写成系统行为Spec。
这是我最近做产品最明显的体感：流程要反过来。
以前是先写清楚，再做出来。
现在应该先做出来，再把看不见的规则写清楚。
先说我自己的真实体感
我现在开发一个功能，不画原型，也不写PRD了。
以前不是这样的。以前我会先用Axure画原型，调布局、调间距、拉连线、标注交互逻辑，折腾个两三天，画出来一份看起来挺专业的原型图。然后拿着这份原型去写PRD，把业务规则、交互说明、异常流程全写进去。
但现在回头看，这件事本身就挺荒谬的——你花了两三天画出来的原型，本质上是在用一种很笨拙的方式"描述"你脑子里的画面。而且画完之后你才发现：这里不对，那里要改。改原型又是一轮时间。
更麻烦的是，你画出来的Axure原型是线框文件，AI识别得很差。除非用 Figma—我用Figma跟AI编程工具的对接确实好一些，但Figma专业版一个月20刀（笔者整了俩月感觉性价比有点低)。
所以我现在的方式是：脑子里大概知道要什么功能，直接用自然语言描述给AI，让它生成一个可交互的前端页面。是真的能点、能跳转、能看到数据的HTML页面。
然后我就开始以最终用户的身份去点。
点着点着就发现问题了：这个筛选条件放在这里不对，用户第一眼看不到；这个列表应该默认展开而不是收起；这个操作需要二次确认但我没加；这个页面的信息密度太高了，要分两个Tab。
这些问题是你在操作一个真实页面的时候才会冒出来的。你坐在那里凭空想，想破脑袋也想不到。不是你能力不行，是人本来就干不了这件事——你不可能在还没有看到界面的时候，就把所有操作路径、所有边界情况全部想清楚。
所以我在vibe coding上花的大量时间，其实是在前端交互上反复改、反复调。改完交互，确认没问题了，才开始想后端的事。
这时候我反过来问自己一个问题：既然无论如何都要经历这轮前端迭代，为什么不把它提到最前面？
传统流程到底慢在哪
先回顾一下传统的产品开发流程：
产品经理画原型（Axure/Figma，几天）→ 写PRD（一两周）→ 评审（拉上开发、设计、测试，开一两次会）→ UI出设计稿、切图（几天）→ 后端设计数据库、写接口（后端先行，因为架构重、改动代价大）→ 前端根据设计稿和接口开发 → 联调 → 测试 → 看到最终效果 → 发现一堆问题 → 改。
整个流程走下来，从立项到第一次看到可交互的页面，少说一两个月。
这个流程的核心假设是：后端更重，所以要先做。数据库结构要先定好，接口规范要先设计好，因为后端改起来麻烦，前端相对灵活。
这个假设在传统开发模式下是对的。但vibe coding改变了一个关键变量：
前端的产出成本。
以前前端开发需要设计师切图、前端工程师写组件、对接Mock数据，光把一个可交互的原型做出来就要好几天。现在呢？你用自然语言描述你要什么界面，AI几秒钟就给你生成一个能跑的HTML页面。
「左侧树形导航，右侧详情面板，顶部有搜索框和筛选条件，点击树节点展开子树。」
丢给AI，十秒钟，页面出来了。你点两下，觉得不对，告诉它改，十秒钟又出来了。
这个成本变化是颠覆性的。它意味着产品经理可以自己直接输出可交互的原型，不需要等UI出设计稿，不需要等前端工程师开发，不需要等后端接口就绪。
那PRD还有用吗？
有用，但它不该叫PRD了，应该叫系统行为Spec。
为什么这么说？我们先想清楚一个事：传统PRD里到底写了什么？
传统PRD是按功能模块组织的——系统有几个大模块，每个模块下面有哪些子功能，每个功能写用户故事、业务规则、验收标准。偶尔附几张线框图，但主体不是UI描述。
那在前端优先的流程下，这些内容还需要用文字写吗？
功能模块拆分——页面上有几个Tab就是几个模块，原型上一目了然。每个模块里有什么列表、什么表单、什么操作——原型上都看得到。用户故事——"用户点击提交按钮后弹出确认框"——直接在原型上点就行了。这些都不需要再用文字写一遍。
但原型看不到的是什么呢？
举个例子。你的知识工程平台有一个"知识库管理"模块，原型上展示的是：左侧知识库列表、右侧文档树、顶部搜索和筛选、可以新建/编辑/删除知识库。这些都在页面上，一目了然。
但原型看不到的是：
删除一个知识库的时候，里面如果有100篇文档正在被另一个模块引用，怎么办？级联删除还是先清空？ 知识库的权限继承是怎样的？管理员给某人分配了知识库A的编辑权限，他能看到A下面所有文档，还是只能看到被单独授权的那几篇？ 两个用户同时编辑同一篇文档，后保存的覆盖先保存的，还是有冲突提示？ 知识库数据量上限是多少？超过之后系统怎么表现？
这些东西，你点原型的时候根本不会触发。你关注的是"布局对不对、流程顺不顺"，你不会去试"删一个知识库，底下的100篇文档会怎样"。
而且这些规则不是某一个页面的事，是跨模块的系统行为。删除知识库影响到文档模块，权限分配影响到多个模块的可见性，数据上限影响到存储和归档模块。原型是按页面组织的，天然看不到跨页面的系统逻辑。
所以PRD的定位变了：从"功能全书"变成"系统行为说明书"。原型搞定的东西不用写——页面布局、交互流程、功能模块划分，原型上都有，再写是浪费时间。原型搞不定的东西才需要写：
跨模块的业务规则——删除/归档/权限继承这些涉及多个模块联动的逻辑 数据约束——实体之间的关系、字段的限制、数据量的边界 异常和边界情况——并发冲突、网络中断、数据超限、权限越界 非功能需求——性能、安全、离线能力
这份东西可能就几页纸，比传统PRD薄得多。但它不能没有——尤其是做比较专业的领域，数据权限和业务规则都很复杂，省掉这一步后端会踩坑。
新的流程长什么样
以我的实际做法，从产品立项开始：
第一步（2-3天）：AI生成可交互原型。脑子里大概知道要做什么，直接用自然语言描述给AI，让它生成前端页面。然后你开始以最终用户的身份去点。布局对不对？流程顺不顺？信息密度合不合适？不对就改，改完再点，直到觉得"对了"。
这个过程中你会发现大量问题——不是你漏了，是你根本想不到。只有看到界面、点上去操作，你才能想到"这里还需要一个确认弹窗""这个状态需要一个空态页面""用户可能会在这里误操作"。
第二步（1天）：从原型反推功能模块。原型确认了，功能模块的划分自然就出来了——页面上有几个Tab就是几个模块，每个Tab里有什么操作、什么列表、什么表单，原型上都有。不需要再用文字重新描述一遍。
第三步（1天）：写系统行为Spec。这是唯一需要动笔写的东西。只写原型看不到的：跨模块的业务规则、数据约束、异常和边界情况、非功能需求。就几页纸。
第四步：团队一起定技术方案。产品把可交互原型和系统行为Spec拿出来，整个团队一起看、一起讨论。后端架构师根据业务情况判断技术选型和数据模型，前端根据原型确认交互细节，测试根据Spec设计用例。产品经理全程参与，不是甩手不管。
那后端现在到底干什么？
这是很多人会问的问题：你前端先做完了，后端怎么办？数据库不用先设计吗？
首先明确一点：我们是一个团队。产品经理、后端开发、前端开发、测试、UI，大家做的是同一个产品，不是各干各的然后互相甩手。
新流程改变的不是"谁管什么"，而是团队协作的起点。
以前的起点是：产品经理写完PRD，后端拿到PRD开始设计数据库和接口，前端等后端接口出来再开发。大家串行工作，后端是瓶颈。
现在的起点是：产品经理先输出一个可交互原型和一份系统行为Spec，整个团队一起看着这个原型来讨论技术方案。后端架构师看到原型，知道这个系统有哪些页面、哪些操作、哪些数据要展示，结合系统行为Spec里的业务规则和约束，他来判断应该用什么技术方案、怎么设计数据模型、怎么分层。
这不是产品甩给后端，是产品把"要做什么"具象化了，降低了整个团队的沟通成本。以前用PRD沟通，开发得在脑子里把文字"翻译"成画面，每个人翻译出来的还不一样。现在直接看原型，所有人对"做出来是什么样"的认知是一致的。
而且很多事情其实都可以交给AI来辅助。后端的技术选型、数据模型设计、接口规划——架构师可以把自己的判断喂给AI，让AI帮忙生成初稿，再人工调整。整个团队都在用AI提效，不只是产品经理。
一句话：产品经理先用原型把事情说清楚，然后整个团队一起把技术方案定下来。不是谁交给谁，是一起干。
这不是只凭感觉
这套做法当然不是拍脑袋。
2025年2月，OpenAI联合创始人Andrej Karpathy发了一条推文，提出了「vibe coding」这个概念：
“There's a new kind of coding I call "vibe coding", where you fully give in to the vibes, embrace exponentials, and forget that the code even exists.
我理解它的核心，不是说“代码不重要”，而是开发过程里可以先盯住结果：能不能跑，能不能点，交互是不是顺。
这和一个更早的软件开发理念有点像：Outside-In TDD。
Steve Freeman 和 Nat Pryce(这两位是测试驱动开发领域的老兵) 在《Growing Object-Oriented Software, Guided by Tests》里讲过一种从外到内的开发方式：先从系统外部可观察的行为开始，再逐层往内部实现业务逻辑和数据层。
不过我要解释一下：Outside-In TDD并不等于“前端先行”，更不是说所有项目都应该先做页面。
它真正有价值的地方，是提醒我们：软件不是从数据库表开始被用户感知的，而是从用户能看到、能点击、能触发的行为开始被理解的。
以前这个思路在产品早期很难彻底跑起来，因为把“外部行为”做成可交互原型的成本太高。你要等设计、等前端、等Mock数据。
现在这个成本被AI打下来了。
产品经理可以先把一个功能“点出来”，再让团队围着这个可见结果讨论后端、数据、权限和边界。
Y Combinator（全球最有名的创业孵化器之一，Airbnb、Stripe、Dropbox 都从这里起步） 的数据也能侧面说明这个变化。TechCrunch在2025年3月报道，YC管理合伙人 Jared Friedman 提到，W25批次里约25%的创业公司，代码库有95%由AI生成。
这不代表大家都可以随便乱写代码。
它说明的是另一件事：产品从想法到可运行原型的距离，正在被压短。
不过这套方法不适合所有项目
这套方法最适合：内部工具、管理后台、SaaS产品、数据看板、AI应用原型、轻量业务系统，以及不确定性很高、需要快速试错的功能。
这些场景的共同点是：交互体验很重要，需求还在变化，先做出一个能点的东西，比先写一份完整文档更有价值。
但有些项目不能这么粗暴地套。
比如强监管系统、核心账务系统、高并发交易系统、底层基础设施、硬件控制、医疗安全相关系统。这里面很多东西不是“先点点看”就能决定的，架构、合规、安全、数据一致性要更早进入讨论。
所以我说的不是“产品经理先把前端做完，后端再跟上”。
更准确地说，是：产品先把用户能感知到的结果具象化，然后团队一起决定系统怎么实现。
这套方法的几个坑
第一个坑：有些东西前端看着能做，后端做不出来。实时协同编辑、复杂计算、大数据量实时聚合——这些交互在原型里表现得很好，但后端实现成本极高。所以做原型的时候你心里要有个数：哪些是纯前端展示层的事，哪些涉及后端复杂逻辑。
第二个坑：Mock阶段的状态管理别太随意。如果原型里的数据全是硬编码、状态全是本地state，后面接真实API的时候可能要大改。建议即使在Mock阶段也用统一的数据层——哪怕是假的service层——别让组件直接操作假数据。
第三个坑：系统行为Spec不能省。原型再逼真，也表达不了跨模块的业务规则、数据约束、异常处理这些东西。不写Spec，后端开发的时候会缺上下文，很多业务逻辑要反复问你。尤其是做一些专业性比较强的领域，删除级联、权限继承、并发冲突这些规则，不提前写清楚后端一定会踩坑。
写在最后
人不是神，不可能在没看到界面之前就把所有需求想清楚。
传统流程的问题不在于PRD写得不好，而在于它试图用文字去描述一个视觉化的东西。
就像用文字描述一首歌的旋律——你可以写「4/4拍、C大调、BPM120」，但读的人脑子里浮现的旋律可能跟你完全不同。
现在我们有了更好的方式：先生成可交互的页面，直接看、直接点、直接改。
确认交互和流程以后，再把原型看不见的东西写成系统行为Spec：权限、数据、异常、边界、跨模块规则。
所以我不是说PRD死了。
我想说的是：PRD不该再站在产品开发的最前面。
第一步应该是原型，把界面和流程暴露出来。
第二步才是Spec，把系统行为补清楚。
原型补交互，Spec补规则。
不用再一上来就写50页PRD了。
以上就是这次的侦察。
如果对你有用，顺手点个赞 +「♥️」。
想第一时间收到前线情报，关注「硅基斥候S01」。我们，下次侦察见。
