AI 时代还按"前端/后端/PM"招人吗？Claude Code 之父甩出 5 类原型，社区吵成两半

🚩 2026 年「术哥无界」系列实战文档 X 篇原创计划 第 155 篇，AI 星探「2026」系列第 18 篇

大家好，欢迎来到 术哥无界 | ShugeX ｜ 运维有术。

我是术哥，一名专注于 AI 编程、AI 智能体、Agent Skills、MCP、云原生、AIOps、Milvus 向量数据库的技术实践者与开源布道者！

Talk is cheap, let's explore。无界探索，有术而行。

AI 时代人才分类坐标轴翻转信息图封面

240 万浏览量。

一条推文，把工程师 / PM / 设计师这套用了三十年的职能分工，随手撕开了一个口子。发布者是 Anthropic 的 Boris Cherny，Claude Code 项目的负责人。他贴出了自己团队里看到的五种人（Prototyper、Builder、Sweeper、Grower、Maintainer），然后甩出一句判断：未来的产品岗，可能长这样，而不再长今天这样。

这条推文的评论区很快就吵了起来。有人把它捧成 AI 时代的人才圣经，有人骂它主角综合症，有人冷嘲：既然 coding 已经 solved，那 Sweeper 在清扫什么。

我自己看完原推和围绕它的全部讨论后，有一个判断要先放出来：

Boris 真正贡献的，不是这五个名字。五个格子谁都能画。他干的一件更狠的事，被大多数人（包括大部分中文解读）忽略了。

说明：本文内容基于 Boris Cherny 2026-06-28 的 X 原推、Acquired Unplugged / Platformer / developing.dev 等多源访谈、以及 paddo.dev 的系统性分析整理而成，理论框架来自 Boris 本人，独立视角与批判性解读为作者个人观点。文中引用的数据（240 万浏览、+200% 生产力、2 天 ramp-up、65.7%/34.3% 情感比例等）均来自公开访谈和社区统计，实际适用性请以你的团队和业务场景验证为准。如果你在实际组织中尝试过类似的人才结构调整，欢迎在评论区分享经验。

先把 5 类原型摆上桌

原推发布于 2026 年 6 月 28 日，X 账号 @bcherny。原文已经被 Digg、Threads、Business Insider、科技新报等多源交叉验证过，浏览量 240 万，情感数据正向 65.7%、负向 34.3%。下面这张表是 Boris 自己给的定义，我做了一版中文画像：

Boris 自己补了一句很关键的话：很多人同时跨 2 个角色，有时跨 3 个。而且这些角色并不绑定岗位。在 Anthropic，有设计师是 1 号，也有设计师是 2 号、3 号；工程师、PM、数据科学家同样如此。

他在拆的不是岗位，是岗位背后的能力倾向。

5 类原型能力雷达图叠加，展示一人可跨多个原型

图 1：5 类原型不是 5 个格子，而是一张可叠加的能力图谱——很多人同时跨 2-3 个原型，清扫者贯穿三个产品阶段

Boris 的真创新：翻转了坐标轴

这是整件事最被低估的一层。

科技博客 paddo.dev 在 Boris 推文发出后不久，写了一段我认为是这次讨论里最锋利的分析。原话大意是：

Cherny flips the axes.（Cherny 翻转了坐标轴。）

要理解这句话，得先把时间线拉长。把人按产品生命周期分类，这件事不是 Boris 发明的。它有一条 30 年的脉络：

看出区别了吗。

前三家里，生命周期阶段始终是次要轴。Cringely 的主轴是性格（突击队人格和警察人格就是两种人）；Wardley 的主轴是市场策略（你在 Wardley Map 的哪个位置决定了你该用哪类人）；Thiel 更干脆，二分法只看你是在创造还是在复制。

Boris 干的事是：把生命周期阶段从次要轴，直接提到主轴位置。

为什么他能这么干？因为 AI。

当工程师、PM、设计师、数据科学家这些职能，都在指挥同一批 AI agent 写同一种语言（Karpathy 管这叫 Software 3.0，自然语言成为新的编程语言），职能就不再是区分人的有效维度了。大家都变成了指挥 agent 的人。那剩下能区分人的维度是什么？

只剩一个：你在产品生命周期的哪个阶段最擅长。

paddo.dev 那篇文章的原文判断我直接引在这里：

新颖之处不是那五个格子，而是格子从次要透镜晋升为主要透镜。

这才是 240 万浏览背后的真问题。如果你只把 5 类原型当成又一份 MBTI，你抓到的只是表皮。

配比表：不同阶段需要什么人

Boris 在原推里直接给了三阶段配比，我整理成一目了然的版本：

这张表有个隐藏信息：Sweeper 是唯一在三个阶段都不可或缺的角色。它夹在中间，既不是开疆拓土的英雄，也不是守城的老臣，却贯穿始终。这个位置很微妙，后面讲批判的时候会再回来。

配比表回答的是团队该长什么样。但 Boris 的理论要落地，还得回答另一个问题：怎么招人。

招人那套：社区总结的偏好

这里我要插一句诚实声明。

调研报告里查证过一件事：Boris 在公开访谈和原推里，明确说过自己招人看重通才、跨域好奇心、副业项目（他原话用的是 side quest，举的例子是：哪怕是酿康普茶的人）。这部分有据可查。

但业界流传的另外两个标签（低 ego 和 接受失败作为数据）我在原推、Acquired 访谈、Platformer 访谈里都没有找到 Boris 直接使用这两个词。Platformer 那篇里 Daniela Amodei 说过 Anthropic 招人优先看 EQ、沟通、善良、好奇心，可以作为间接佐证。所以下面这些，我会标注清楚哪些是 Boris 亲口说的，哪些是社区根据他的风格总结的合理推断：

Boris 在 2026 年 6 月 2 日的 Acquired Unplugged 访谈里有一句很出圈的判断（比 X 推文早了整整 26 天）：

Right now, this is just the golden age of the generalist. People that want to do more than one thing — it's never been more fun.

这句话是 5 类原型理论的先导。他在这次访谈里已经完整描述过那张图景：工程师做 scoping、和用户对话、拉数据、做仪表盘、做设计；设计师写代码；chief of staff 写代码；财务也写代码。这就是 6 月 28 日推文的雏形。

还有一组数据值得放在这里，全都来自这次访谈（由 WorkOS 整理）：Anthropic 工程团队规模翻倍的同时，人均生产力（merges/engineer/day）提升 200%，新工程师 ramp-up 时间从几周降到约 2 天，Claude Code 团队超过 90% 的代码由 Claude Code 自己写成。

另据 Platformer（Casey Newton）2026 年 5 月 26 日的访谈，Boris 自己说他已经 6 个多月没亲手写过一行代码了。

这些数字是 5 类原型理论生长的土壤。没有这个土壤，PM 也写代码就是一句空话。

Anthropic 团队规模翻倍下的人均生产力、ramp-up 时间、AI 写代码占比对比

图 2：Anthropic 内部数据——团队翻倍的同时，人均生产力反而 +200%，新人 ramp-up 从几周压到 2 天，这正是 5 类原型生长的土壤

不能只夸：paddo.dev 的四连批判

到这里如果你觉得这套理论很完美，那说明我只讲了一半。Boris 的推文评论区不是一边倒的叫好，34.3% 的负面不是凭空来的。paddo.dev 那篇分析里，系统性地挑出了四个我觉得最有分量的批评。不讲这些，这篇文章就只是一篇传声筒。

批判一：Sweeper 和 Maintainer 是换名字的晋升陷阱。

Tanya Reilly 有本讲 glue work（粘合工作）的书，一句话：维系团队存活的那种工作（协调、清理、文档、救火）恰恰是悄悄毁掉你晋升案例的工作。因为它不产生可以写进 promotion doc 的我的项目。

Sweeper 和 Maintainer 干的事，和 glue work 高度重叠。Boris 给它们起了好听的名字，但名字不等于赋权。一旦你的 manager 在你名字旁边写下 Maintainer，你在系统里的位置就定了，而你参与早期高学习价值项目的机会也会随之减少。

这是整个理论最痛的一刀。它不是说 Boris 错了，而是说：在一个仍然按职能和可见产出论英雄的职场里，把清扫和维护写成正式角色，可能反而固化了做这些事的人的处境。

批判二：原型是镜子，不是笼子 - 但镜子很容易硬化成笼子。

Boris 自己在评论区同意过这条：有人批评原型分类会让人选一个就不再质疑自己，Boris 回复说完全同意，角色会随时间/项目变化。但同意归同意，机制没解决。paddo.dev 的原话大意是：原型本来是帮你认识自己的镜子，可一旦它进入绩效系统，镜子就硬化成标签，而标签决定资源分配。

批判三：收敛是局部的，不是普世的。

5 类原型对中等复杂度的产品工作成立。但对安全、分布式系统、ML 研究、编译器这类硬边缘领域，它不成立。这些领域的认知需求在上升，专家招聘在增加，而不是在消融。把它们硬塞进全员 product builder的框里，会掩盖真实的认知门槛。

Threads 上 @carnage4life（Dare Obasanjo）的批评指向同一个方向：Claude Code 是开发者工具，它需要的角色不能很好地 generalize到全行业，因为它的本质是开发者给开发者做工具。

批判四：初级人没资格自选原型。

这条最容易被忽略，但我觉得最犀利。5 类原型框架假设你已经有足够职业经历，知道自己属于哪个格子。但刚入职场的人呢？他们的标签会在自我认知形成之前，就被别人贴上。Boris 的框架是给成熟个体的自省工具，不是给组织的分配系统。一旦组织拿它当分配系统用，先被分类、被定型的，永远是资历最浅的那批人。

这四条批判加在一起，构成一个清醒的提醒：Boris 的理论是一面好镜子，但它能不能变成一个好制度，取决于用它的组织愿不愿意解决标签固化、晋升公平、领域差异这些老问题。理论本身不解决这些问题。

把 Boris 放回 30 年坐标里

讲完批判，我想退一步，把 Boris 放回那条 30 年的脉络里看。

Cringely 1992 年的 Commandos/Infantry/Police，是写给 PC 革命那一波公司的。Wardley 的 Pioneers/Settlers/Town Planners，是写给云时代的。Thiel 的 0→1/1→n，是写给移动互联网和独角兽时代的。每一个分类法都精准对应了一个技术周期里人怎么组织的核心矛盾。

Boris 的 5 类原型，对应的是 AI agent 开始商品化职能层这个新周期。他的贡献不在多画了两个格子（Cringely 是 3 个，他是 5 个），而在响应了一个新问题：当职能不再是区分人的维度，我们该按什么维度重新组队。

这个问题的答案他给得很果断：按生命周期阶段。

这个答案对不对，现在没法盖棺定论。但它至少是一个对的新问题。在一个大家都还在争论 AI 会不会取代程序员的时点，Boris 跳过了数量问题（Sam Altman 和 Dario Amodei 在谈的：多少岗位会消失），直接去回答结构问题（剩下的岗位怎么重新分类组织）。两个层次的问题互补，但后者更稀缺。

落地：三个真实在做的公司

理论再漂亮，没人照着做就是纸上谈兵。好在已经有公司在动了。

Anthropic 自己是关键证据。全公司统一头衔 Member of Technical Staff，不分工程师/PM/设计师。Claude Code 团队里，PM 写代码、设计师写代码、数据科学家写代码，连 15 年没写过代码的 manager Fiona 都开始写代码。Boris 说他爱极了这套——它逼着你走出自己的泳道。

LinkedIn 做了组织层面的改动。据 paddo.dev 引述，LinkedIn 取消了 Associate Product Manager 项目，改成轮岗制的 Product Builder track。这几乎是把 5 类原型的逻辑直接写进了晋升路径。

Shopify 的数据更反直觉。据 paddo.dev 引述，Shopify 内部 AI 构建工具增长最快的用户群体，不是工程团队，而是 support（客服）和 revenue（营收）团队。职能壁垒在消融，而且是从最不像会写代码的部门开始消融。

加上 Figma 的 Dylan Field 在 2025 年 10 月公开说过每个人都在变成 product builder，以及 Anthropic 内部那份 40 万 Claude Code 会话研究的发现（据 paddo.dev 引述：管理类职业的使用成功率领先，编程背景和成效的相关性在下降），证据链是有的。虽然覆盖范围还有限，还谈不上全行业转向。

Anthropic、LinkedIn、Shopify 三家公司在 AI 时代的组织变化对比

图 3：三家公司已经动了——Anthropic 统一头衔、LinkedIn 改轮岗制、Shopify 客服团队反而最快拥抱 AI 构建，职能壁垒正在从最不可能的地方消融

给你一个能立刻用的东西

讲了这么多理论，落到个人头上，具体能干嘛。我给一个和自检三问不同的形式：一个原型 × 阶段自检矩阵，帮你看清两件事（你现在站在哪个格子里，以及你和你的团队/项目阶段匹不匹配）。

第一步：识别你过去 3 个月花时间最多的原型。

别按岗位想，按实际行为想。下面这些信号帮你定位：

第二步：看你的项目/公司处在哪个阶段，对照配比表，判断你是被需要的那个，还是多余的那个。

如果你是 Prototyper，但你的产品已经 PMF 稳固进入守城期，你要么主动迁移能力，要么准备好被边缘化。反过来，如果你是 Maintainer，但团队还在 0→1 乱撞，你大概率很痛苦，而且你的价值短期内没人看得见。

第三步：识别你最缺的那一类原型，然后用 AI 补位。

这是 Boris 理论在个人层面的用法。Boris 自己在评论区被问到 Claude 能不能替代 Builder 和 Sweeper，他的回答很克制：Claude 能在不同程度上帮助所有这些角色，并且会随时间改进。注意他用的是帮助，不是替代。

我个人会这样用这个矩阵：先用前两步认清自己和团队的缺口，然后让 AI agent 去补那个缺口里最机械、最可外包的部分。你是 Prototyper 但团队缺 Maintainer？让 AI 帮你做监控配置、写测试、生成运维文档。你是 Maintainer 但团队缺 Prototyper？让 AI 帮你快速出十个方向的 demo，你来判断哪些值得深入。

5 类原型的价值，不在于让你选一个格子待一辈子，而在于让你看清缺口在哪，然后用人和 AI 的组合去填它。

收尾的判断

如果让我用一句话总结 Boris 这次做的事：

他没有发明一种新的人才分类，他只是头一个敢在 AI 商品化职能层之后，把一个老问题提到 C 位的人：你在产品生命周期哪个阶段最擅长。

这个动作本身比那五个名字重要得多。五个名字会变，会被人忘，会被更好的框架取代。但当职能不再是区分维度，就得换一个维度看人——这个动作，至少现在还没人能反驳它。

至于 5 类原型会不会变成下一代公司的标准编制，我个人的判断是：不会原样照搬。格子大概率会被改写、被合并、被遗忘，但他翻转坐标轴的那只手——也就是"按生命周期阶段组队"这个底层动作——会比那五个英文单词活得久。

至于你该站在哪个格子里，这个答案，Boris 给不了你，我也给不了。矩阵能帮你看清现状，但往哪走，是你自己的事。

一个提醒收在这里：paddo.dev 那四条批判不是泼冷水，是告诉你这套理论的边界在哪。任何一套人才分类法，在被组织拿去当分配工具的那一刻，就开始背离设计者的初衷。Boris 自己都同意这一点。用好它的前提，是始终把它当镜子，而不是当笼子。

好啦，谢谢你观看我的文章，如果喜欢可以点赞转发给需要的朋友，我们下一期再见！敬请期待！