过去一年，B 端团队的协作方式在慢慢的变化。产品经理开始用 AI 直接生成高保真原型，拿着能点击的页面去和开发对需求。一个订单管理的列表页，从想法到可交互原型，可能只要一个下午。在一些团队里，标准需求的设计环节开始被跳过，设计岗位也随之收缩。

变化不只发生在一个方向。有设计师往上游走，自己拆需求、理流程，再反向整理出 PRD；也有设计团队往下游走，借助组件库和 AI Skill 直接生成前端代码，减少标注、切图和反复走查。开发这边同样如此。AI 能帮他们更快读懂需求、理解交互，直接做出可运行的功能。中间不一定需要完整的设计稿，甚至不一定需要一份非常详细的 PRD。

把这几件事放在一起看，会发现：产品可以跳过设计；设计可以覆盖产品和前端；开发也可以绕开前面的部分环节。链路上的每个环节都有被跳过的可能。

真正值得关注的，已经不是哪个岗位更安全，而是：当链路越来越短，什么样的价值不会被轻易跳过？

01 被压缩的，是传递，不是专业

回头看传统的研发链路：产品把业务需求整理成 PRD；设计把 PRD 转化成界面和交互；前端再把设计稿实现成代码。从业务需求到最终产品，中间要经过好几次"转换"。问题也往往出在这些转换里。产品理解的，设计不一定完全理解；设计表达出来的，开发也不一定能完全还原。

AI 正在明显降低这部分成本。一段需求描述，可以快速生成原型；一个原型，也可以进一步生成代码。过去需要不同角色接力完成的很多中间步骤，现在可以更快完成，甚至直接跨过去。这意味着，最先被压缩的，不一定是某个岗位，而是岗位里那些重复、标准化、以转换和交接为主的工作。比如把已有信息整理成格式完整的 PRD；把明确的需求画成标准列表页、表单页；把成熟设计稿按照既定规范实现成页面。这些工作过去需要大量人工执行，现在越来越容易被 AI 加速，甚至部分自动完成。

但这并不意味着产品、设计、开发的专业价值也会一起消失。

02 专业为锚，AI 为杠杆

当翻译环节越来越轻，每个岗位都需要留下专业的判断。产品要判断：这件事该不该做？先做什么？做到什么程度才值得？设计要判断：这个流程顺不顺？用户能不能理解？复杂场景下体验是否一致？开发要判断：这个方案稳不稳？成本是否可控？未来能不能持续维护和扩展？

AI 可以提供方案，却替代不了真正的取舍。所以，在 AI 时代放大个人价值，可以分成两步：第一步，找准专业内核。这是你在链路上的锚点，决定了你最重要的判断力在哪里。第二步，用 AI 向两端延伸。过去需要跨岗位协作才能完成的执行工作，现在一个人可以覆盖得更长。

这里有一个很重要的区分：延伸的是执行能力，内核承载的是判断和责任。所以更准确的说法不是"每个人都变成全栈"，而是：每个人都可以做得更宽，但必须有一个足够深的专业支点。专业是锚，AI 是杠杆。锚越稳，杠杆能撬动的就越多。

03 产品：让业务判断走得更远

产品最核心的价值，是回答两个问题：为什么做？做成什么样才算成功？比如一个采购系统，要不要做审批分级？哪些金额走快速通道？上线之后，是看审批时长，还是看成本下降？这些都不是"写完一份 PRD"就能回答的问题，背后是对业务目标、用户场景和资源成本的综合判断。

AI 带给产品最大的变化，不只是"写得更快"，而是把信息搜集和初步整理的成本降了下来。于是，产品可以把更多时间留给真正重要的事情：这些信息到底说明了什么？与此同时，验证也变得更快。一个想法可以直接变成能点击、能演示的页面，拿去和业务方对齐，也可以提前和开发讨论可行性。从"想到一个方案"到"看到真实效果"的周期缩短，试错成本也随之降低。

04 设计：让体验判断落得更实

B 端设计真正难的，从来不是标准页面，而是复杂场景：多角色协作、多状态流转、各种异常和边界，以及几十个模块之间的一致性。这些需要对业务流程和用户操作有足够深入的理解，也是设计专业价值最集中的地方。

借助 AI，设计师可以更早进入需求阶段：梳理业务流程、拆解功能模块、补充异常状态，甚至直接整理成结构化需求文档，与产品共同讨论。设计也因此从"接需求"，变成"一起定义需求"。很多体验问题，不必等到设计阶段才发现，在需求源头就能被考虑进去。

往下游走也是一样。在组件库、Design Token 和工程规范足够成熟的前提下，设计师可以借助 AI Skill 生成符合规范的前端代码。设计与研发之间的讨论，也会逐渐从"还原得对不对？"，转向："这个方案本身好不好？"以采购审批为例。设想一个多级采购审批需求，设计师从需求阶段就参与梳理：申请人、部门主管、财务三个角色的操作路径是什么，驳回、撤回、超时、金额变更分别怎么处理。流程梳理完，直接沉淀成需求文档，与产品对齐。

到了设计阶段，精力集中在最有挑战的部分：不同角色在异常状态下看到什么、能做什么，整个流程是否清晰、一致。标准的列表页、详情页、表单页，则借助组件库和 Skill 快速生成，甚至直接输出代码。从需求梳理到页面交付，设计师覆盖的链路变长了。但真正投入最多心力的，始终还是体验判断本身。

05 开发：让工程判断发挥更大作用

开发的核心，也不是"把页面写出来"，而是工程判断：系统稳不稳，大数据量下性能如何，架构能不能扩展，组件能不能复用，技术债会不会越积越重。这些问题决定的，是一个产品能不能长期运行。

AI 同样会让开发向两端延伸。向上，开发可以更早进入需求和方案讨论，在需求阶段就判断：这个方案技术成本是否过高？有没有更简单的实现方式？越早介入，返工越少。向下，测试用例、部署流程、日志分析、线上监控等工作也可以借助 AI 提效，开发更容易把一个功能从实现一路负责到稳定上线。

更值得关注的是基建。为什么产品能快速生成接近真实的原型？为什么设计师能直接输出可用代码？一个重要前提，是团队已经有成熟的组件库、设计 Token 和工程规范。这些底层能力，需要开发持续建设和维护，并通过 Skill 等方式被产品、设计共同复用。一个好组件，可以被几十个页面反复使用；一条清晰的规范，可以让每一次 AI 生成天然符合团队标准。开发的成果，也就不再只体现在"自己写了多少页面"，而是：让整个团队生成出来的东西，都更加可靠。工程判断的作用，也因此覆盖到了整条链路。

06 能做得宽，不等于做得深

说到这里，需要补一个很重要的前提：延伸的前提，是专业内核足够稳。设计师借 AI 写出一份 PRD，如果缺少对业务的理解，只是把流程"写得像样"，反而可能把错误的假设固化下来。产品生成的原型看起来很完整，如果缺少体验判断，异常状态、权限差异、一致性这些问题，很可能在后期集中爆发。AI 生成的代码能跑起来，也不代表架构经得起长期迭代。

AI 让"做出来"变得容易，也让"做得浅"变得容易。所以，延伸出去的部分，最终还是要靠专业内核兜底。我们需要知道什么可以快速做，什么必须深入判断；也要知道什么时候该继续往前走，什么时候该把问题交回真正专业的人。AI 扩大的是我们能够到的范围，决定我们站得稳不稳的，仍然是内核。

07 协作的新样子：从传递产出物到对齐判断

当每个人都能覆盖更长的链路，团队的协作方式也会随之改变。过去，协作的核心是传递产出物。产品把 PRD 交给设计，设计把设计稿交给开发，大家花大量时间确认：需求有没有理解错？设计稿有没有还原错？现在，越来越多的讨论开始直接围绕可交互原型、真实页面，甚至代码展开。协作的重点，也从"你有没有准确理解我的产出物？"，变成："这个判断到底对不对？"比如：这个业务方向值得做吗？这个流程用户真的能理解吗？这个技术方案两年以后还能维护吗？边界变宽之后，责任反而需要更清楚：业务判断谁拍板？体验质量谁负责？工程风险谁兜底？交接环节虽然变少，但关键节点的评审不能少。

与此同时，组件库、规范、Design Token、Skill、知识库，也不再只是某一个岗位的资产，而会逐渐成为团队共同维护的基础设施。链路变短之后，协作并不会消失。它只是从"交接文件"，变成了"直接讨论问题本身"。

写在最后

未来，岗位名称可能会变化，职责边界也会越来越模糊。但真正有价值的，从来不是"我负责流程里的哪一段"。而是：面对复杂问题时，我能够做出什么高质量判断，并且为这个判断带来的结果负责。AI 放大的不是岗位，而是一个专业的人能够影响的范围。