https://yunpan.plus/t/27089-1-1

最近，Claude Code 的创始人 Boris Cherny 发了一条热度很高的推文，核心观点是：工程、产品、设计、数据科学这些传统岗位的边界正在模糊，并逐渐融合成一种全新的角色。

他提到，自己一直在思考未来的岗位会是什么样子。就拿 Claude Code 团队来说，他从中观察到了五种典型角色：

1. Prototyper（原型构建者）：负责提出全新的想法，快速产出大量创意，而且坦然接受其中大部分都不会最终落地。
2. Builder（落地构建者）：能够迅速将原型或想法，转化为可以投入生产环境的产品或基础设施。
3. Sweeper（精打磨者）：专注于打磨用户界面，精简代码与系统，果断下架无用功能，持续优化性能表现。
4. Grower（增长驱动者）：接手已经完成初步搭建的产品，通过持续的迭代来优化产品与市场的契合度。
5. Maintainer（系统维护者）：看护成熟的系统，确保其在业务规模不断扩大的过程中，依然保持安全、可靠、快速且高效。

很多人并不会只扮演单一角色，而是会同时承担两种，有时甚至是三种。更重要的是，这些角色和具体职能岗位（比如你是工程师还是设计师）没有必然联系。在 Anthropic，有些设计师是第一种类型，有些是第二种，还有的是第三种——工程师、产品经理、数据科学家也一样。

一个健康的团队，需要根据产品所处的发展阶段来搭配不同类型的人才，而且每个人的角色也会随着时间和项目的变化而动态调整。

• 处于早期、尚未达成产品市场契合度（PMF）的产品，急需擅长 1+2+3 类能力的人。
• 处于成长期、已达成 PMF 的产品，则需要 2+3+4 类角色，再搭配少量 5 类角色。
• 对于 PMF 很高的成熟产品， 3+4+5 类角色成为主体，并补入少量 2 类角色。

这条推文能引发这么多共鸣，核心原因在于：大公司里，工程师、产品经理、数据分析师这些在上一代工业逻辑下形成的固定分工，在 AI 的冲击下，身处其中的人多少都有些迷茫。

一个直观的感受是，每个人能做的事情确实变多了。很多产品经理开始动手写代码、跑自动化脚本；工程师会直接调整 UI、做交互实验；设计师则能借助 AI 快速产出可交互的 Demo。

与此同时，团队里某些传统的“传话”或“中转”角色，正在被悄然折叠。最近不少大厂进行人员优化，我觉得某种程度上也和这种效率结构的变化有关。在 人工智能 的驱动下，个体的能力边界被大大拓宽了。

Boris 的思路很明确：或许我们可以先放下前端、后端、产品这类按专业技能切分的传统分工方式。这让我想起华为早年的一些实践，他们常常会围绕产品流程，重新定义和调整岗位职责，以适应业务需要。

可能有人会撇嘴：这不就是新瓶装旧酒吗？Prototyper 对应客户需求加产品经理，Builder 对应架构师，Sweeper 对应软件工程师……这么说有点道理，毕竟这些工作内容过去也都存在。

但问题的关键在于， AI 已经把横亘在这些事情之间的边界给打破了。以前，一个想法从产生到最终上线，中间要像流水线一样经过许多专业工种。现在，AI 折叠了一些角色，流水线上需要的工种更少，每个人的职责范围（Range）会变得更大。甚至在我们这样的创业公司，前三类角色的活儿都可能会整合到一个 Builder 身上。

就像我上周跟大家分享的例子，我们团队以前的产品开发流程是：

调研 → 写一堆 PRD/文档 → 评审 → 设计 → 再评审 → 开发 → 测试 → 上线

过去产品经理启动一个需求，起点就是码字写文档。调研、写文档、评审、设计……光是这条前期链路走下来，就要耗费大量时间。更别提产品文档这种东西，写的人痛苦，看的人也未必有耐心逐字读完——动辄几千字，真正认真看的人没几个。

现在我们换了个做法：产品经理不必先写文档，直接用 AI 把原型做出来。跟用户沟通用这个原型，跟程序员沟通也用这个原型。一下子省掉了一大段冗余环节，沟通效率反而更高了。

文档当然还是有的，只不过变成了后置。评审完，把其中的关键逻辑梳理清楚、写明白就行，无需啰嗦，严格控制在 1000 字以内。毫无疑问，流程在变，对人才角色的定义也真的在变了。