AI 带来的组织变化，不只是让每个岗位做得更快。
更深的一层是：工程、产品、设计和数据科学之间原本清晰的执行边界，正在逐渐变薄。产品经理可以直接做出可交互原型，工程师可以更早参与产品判断，设计师和数据科学家也能跨过过去需要多人交接的环节。
但这不意味着未来团队只需要一种“全能岗位”。当专业头衔开始交叉，团队仍然需要不同的人，解决产品生命周期里不同的问题。
2026 年 6 月，Claude Code 负责人 Boris Cherny 分享了一个来自自己团队的观察：他在这支跨职能团队里，看到了五种反复出现的角色。
Boris Cherny 的原帖给出了五种角色、角色可以重叠，以及团队会随产品阶段调整组合这几个边界。下面把它们排进产品生命周期，是我对这套框架的进一步拆解，不是 Anthropic 的岗位制度。
我更愿意把它理解成一张“动态团队地图”。先看产品处于哪个阶段，再看团队需要哪几种角色、以什么比例一起工作。五个名称只是为了描述贡献方式，不是新的岗位编制。
五种角色，覆盖一条完整的产品生命周期
**原型者（Prototyper）**把还说不清的想法变成可以看、可以试、可以讨论的东西。他们需要快速探索，也接受大多数点子最后不会上线。
**建造者（Builder）**接过已经露出价值的原型，把“能演示”推进到“别人真的可以依赖”。需求边界、质量、数据、流程和基础设施，都要在这一段补齐。
**清扫者（Sweeper）**处理系统不断产生的冗余：重复功能、越来越绕的流程、难以维护的代码、持续消耗注意力的界面。他们不仅优化，也会判断什么应该下线。
**增长者（Grower）**面对的是产品已经做出来、但市场答案还不清楚的阶段。他们沿着真实反馈继续迭代，判断用户为什么留下、在哪一步流失、什么需求值得继续投入。
**维护者（Maintainer）**守住成熟系统的安全、可靠、速度和效率。真实用户和业务开始依赖系统以后，维护就不再是收尾，而是一项持续责任。
这五种原型连起来，正好覆盖一条产品路径：探索想法、完成建造、清理冗余、寻找增长、守住规模。
Boris Cherny 还强调了两个边界：一个人可能同时覆盖两三种原型，而且会随任务和产品阶段移动；这些原型也不和具体头衔绑定，设计师、工程师、产品经理或数据科学家都可能出现在不同位置。
这也不是给 0—1、增长、技术债和 SRE 换一套名字。真正有用的地方，是把角色和岗位头衔拆开，再根据产品阶段重新组合。
所以，别急着把它做成新的人格测试。把“我是产品经理”换成“我是原型者”，并没有解决标签过早固化的问题。
AI 让执行边界变薄，判断位置变得更显眼
过去，组织按照专业技能分工，有很现实的原因。代码、设计、产品和运营都需要长期训练，一个人很难越过多个执行门槛。
现在，AI 正在帮助更多人跨过其中一部分。产品可以更快做出交互原型，运营可以处理数据和搭建自动化，开发也能更直接地参与界面与内容。
专业能力并没有因此失去价值。变化在于，“会不会使用某个工具”越来越难完整解释一个人的贡献。面对不确定性时，你擅长发现机会、完成交付、删除噪音、验证增长，还是守住风险？这个问题更接近实际工作。
把团队地图用回个人：看过去 30 天承担了哪些角色
不要先看岗位职责，也不要凭感觉选一种原型。把过去一个月真正完成的任务列出来，只写具体动词。
例如：提出、试做、上线、补齐、删除、简化、复盘、转化、修复、监控、降本。
然后建立一张表：
| 真实任务 | 主要动词 | 产品阶段 | 承担的角色 | 你做出的关键判断 | 可验证结果 | | --- | --- | --- | --- | --- | --- | | 做出活动页首版 | 试做 | 探索期 | 原型者（少量建造者） | 先验证哪一个核心需求 | 获得首轮反馈 | | 下线低使用功能 | 删除 | 规模期 | 清扫者＋维护者 | 哪部分成本已经高于价值 | 流程缩短、维护量下降 | | 优化新用户路径 | 转化 | 增长期 | 增长者＋建造者 | 流失主要发生在哪一步 | 完成率变化 |
填完以后，只看三个问题：
- 哪一类任务最容易让你进入状态？
- 哪一类判断最常被团队依赖？
- 哪一段工作长期没人负责，正在拖慢结果？
前两个答案描述你的当前优势，第三个答案提示下一步最值得补的能力。
对管理者来说，五种角色需要随产品阶段重新配比
探索期需要更强的原型能力；验证期要把有效原型补到可靠，同时及时清理无效试验；进入增长期后，用户反馈、市场匹配和稳定交付的权重会上升；到了规模期，维护、效率和风险控制会占据更多精力，但团队仍要保留试验和继续建造的能力。
五种角色不是五个固定编制。一个人可以覆盖两三种，同一个人也会随着产品阶段改变自己的主要角色。招聘和组队时只问“还缺一个产品还是一个开发”，可能已经不够，还应该再问两个问题：
- 我们现在卡在产品生命周期的哪一段？
- 团队缺的是把想法变成东西的人，还是把东西变得可靠、变简单、变得有人持续使用的人？
这套框架来自一支前沿软件团队的观察，不是 Anthropic 的官方岗位制度，也不能直接平移到所有行业。它适合帮助个人复盘工作偏好、帮助团队发现角色缺口，不适合拿来把人锁进另一套标签或直接改成绩效分类。
下一次介绍自己时，可以在职位后面补上一句：
“我最擅长把什么状态，推进成什么结果。”
你所在的团队现在处于哪个产品阶段，最缺的又是哪一种角色？
来源与说明
- Boris Cherny 原帖
- Anthropic 官方身份页
- 五种角色来自 Boris Cherny 的公开分享；角色与产品生命周期的对应关系、个人复盘表与管理建议为本文分析。