AI 时代的产研团队重构

产研团队正在经历一次底层重构——翻译链正在消失。

翻译链正在成为最大的组织负债

传统产研分工的本质是一条翻译链。PM 把业务意图翻译成 PRD，设计师把 PRD 翻译成视觉稿，前端把视觉稿翻译成页面，后端把需求翻译成接口。每一次翻译都有信息损耗，每一次 handoff 都是等待和误解的温床。

这条链路在过去是必要的，因为”把想法变成可运行的实现”需要专业技能和大量时间。但 AI 正在让这个前提失效。

Jenny Wen 在 Anthropic 观察到的变化已经很具体：设计师花在设计稿上的时间从 60-70% 降到 30-40%，与工程师直接配合的时间从 20% 升到 30-40%，还多出了一块——自己写代码。Boris Cherny 每天发出 20-30 个 PR，没有手动写过一行。Anthropic 内部甚至取消了固定头衔，所有人都是 Member of Technical Staff，因为边界已经模糊到不值得区分。

这不是个别公司的激进实验。这是当翻译成本趋近于零时，组织结构必然发生的相变。

传统链路（4+ 环节，每步翻译 + 等待）：
业务意图 → PM(PRD) → 设计师(视觉稿) → 前端(页面) → 后端(接口) → 上线

重构后（2 环节，直接在最终介质上工作）：
业务意图 → spec owner(executable spec) →┬→ 简单改动：直接验收发布
                                         └→ 生产交付：product engineer → 上线

团队此刻的切入口

这里讨论的不是所有产研团队，而是一个非常具体的场景：负责企业核心领域服务，同时提供内部运营后台的团队。团队的主线是核心业务系统，前端工作主要集中在配套的运营后台上。

这个场景天然适合率先重构，原因很清楚：

• 运营后台的核心问题不是界面美不美，而是流程跑不跑得通。 运营配置、数据看板、审批流程——这些页面的价值在于尽快上线、用真实数据暴露问题、在最短路径里吸收反馈。
• 页面模式相对固定。 表格、表单、详情页、配置面板，80% 的场景可以用统一的组件和骨架覆盖。
• 离业务反馈近。 运营后台直接驱动业务动作，每一次配置变更都连着真实的业务结果。

换句话说，这是一块”翻译链成本高、但翻译难度低”的区域。正好是 AI 最先吃掉的地方。

新的分工：两个角色，一条更短的链路

重构后的分工只需要两个核心角色，取代原来至少三到四个环节的串行链路。

为什么是两个角色，而不是一个人全做？因为 AI 消除的是翻译成本，不是两类判断的差异：“该做成什么样”和”怎么在生产环境稳定跑起来”需要不同的能力和关注点。前者靠业务判断，后者靠系统能力。把它们混在一个角色里，结果要么是 spec 不够贴业务，要么是交付质量不够生产级。

离业务最近的人产出 executable spec

不再停留在 PRD 和原型图。借助 AI 工具，离业务意图最近的人直接产出一个可看、可点、可验证的可运行版本——这就是 executable spec（可执行规格）。需求不再是文档，而是直接以可运行的形态存在。

做这件事的人通常是 PM，但不限于 PM。很多技术项目本身就是有产品判断力的研发在主推，研发在早期天然承担了定义需求和验证方向的角色。谁离业务意图最近、谁对”这个功能该做成什么样”有判断，谁就应该是 executable spec 的 owner。

executable spec 不是生产代码，但它必须做到：

• 页面结构清晰，核心流程能跑通
• 字段和文案可直接体验
• 能在真实或接近真实的数据下暴露问题
• 产品侧看了就能指出”哪里不对”

这件事的意义远比”PM 学点前端”深刻得多。当需求可以直接在最终介质上被表达和验证时，所有围绕”你理解错了我的意思”的沟通成本瞬间归零。 团队不再需要在静态原型上反复对齐，而是在真实页面上收敛问题。

同时，spec owner 也自然承担一部分简单改动：文案调整、字段增删、布局微调、基于现有组件的小功能拼装。这些改动如果足够简单，可以直接验收发布，不需要再经过 product engineer。最理解业务意图的人获得了直接落地的能力，工程师则腾出精力专注更高杠杆的事。

product engineer 对线上结果负责

executable spec 解决了”意图表达”的问题，但生产级交付关心的是另一组问题：线上后果由谁负责？

这个角色接住 executable spec，判断哪些实现可以保留、哪些必须重构，打通前后端链路，补齐权限、异常处理、埋点、日志、测试，确保代码具备持续维护和演进的能力。

关键区分：这个角色的核心不是”会用 AI”，而是 能借助 AI 高效完成生产级交付，并对线上结果负责。AI 是杠杆，判断力和系统能力才是根基。

在这个场景下，这个角色更可能从后端成长出来。原因很直接：团队的核心复杂度来自领域模型，而不是视觉和交互。后端工程师天然离这些问题更近，运营后台只是他们交付能力的自然延伸。

前端能力从岗位沉淀为基础设施

这里要说的不是”不需要前端能力”——恰恰相反，前端能力变得更重要了，但它的载体变了。

组件库、页面骨架、鉴权壳、表单表格方案、错误处理规范、脚手架——这些不再由一个独立岗位单独承接，而是沉淀为团队共享的基础设施。spec owner 用它来做 executable spec，product engineer 用它来做生产交付。前端能力的价值不是减少了，而是从”由专人手工翻译”变成了”被所有人通过工具和规范直接使用”。

为什么这不是权宜之计，而是更好的形态

容易把这套分工理解成”AI 替代了前端，省了人”。这是最大的误读。

真正发生的事情是：团队里的每个人都离价值创造更近了。

Boris 的印刷机类比在这里同样成立：印刷机出现后，scribes（抄书吏）没有消失，他们变成了作家。整个文字市场扩张了 10,000 倍。软件也一样——当构建界面的成本趋近于零，需要被构建的东西会指数级增长，而决定”构建什么、为什么构建”的人会变得更重要。

这套模式的边界

适用场景：

• 运营后台
• 页面模式相对固定、可用统一骨架覆盖的场景
• 技术栈统一、愿意前期投入基础设施的团队
• 接受”先 80 分上线，再持续迭代”的组织文化

不适用场景：

• 直接面向外部用户的核心前台产品
• 复杂交互、重视觉、重性能的页面
• 安全、合规、审计要求极高且不容错的系统
• 需要大量自定义前端工程能力的产品形态

如果业务未来走向外部产品化，或前端交互复杂度明显上升，重新引入专门的前端负责人可能是必要的。这个判断不是永恒的，但在当前场景下，它是最值得押注的方向。

接下来的赋能节奏

1. 让离业务最近的人成为 spec owner。 目标是：产品侧能独立产出 executable spec，不再需要工程师翻译意图。基础设施和工具训练是手段，独立表达和验证需求的能力是结果。
2. 让后端工程师长成 product engineer。 目标是：对线上结果端到端负责。在接住 executable spec、补齐生产级交付的过程中，全栈能力自然生长。

相关阅读

• 设计流程已死：Anthropic 设计负责人谈 AI 时代的设计变革
• Claude Code 的架构、Claude Co-work 与工程师的未来