Signal
一句话信号：
AI Coding 正在把产品团队从“职能分工”推向“生命周期分工”：未来更重要的不是你叫什么岗位，而是你能在产品哪个阶段创造关键价值。
Claude Code 负责人 Boris Cherny 最近在 X 上提出一个很有代表性的观察：
当工程、产品、设计、数据科学等职能逐渐被 AI 工具重新连接在一起，未来团队里的角色可能不再按传统岗位划分，而会按一种新的“贡献模式”划分。
他在 Claude Code 团队里看到了五种典型原型：
Prototyper，原型者
负责提出大量新想法，快速试错，做出很多原型。大多数不会真正上线，但它负责打开可能性。
Builder，搭建者
负责把一个原型、想法或实验，快速变成可运行、可交付、可上线的生产级产品或基础设施。
Sweeper，清道夫
负责清理 UI、简化代码和系统、下线冗余功能、优化性能，让产品和系统重新变轻。
Grower，增长者
负责在已经被验证的产品上持续迭代，提升 Product-Market Fit，推动留存、转化、使用频率和用户价值。
Maintainer，维护者
负责成熟系统的安全、稳定、可靠、性能和规模化，让产品在增长之后不崩掉。
判断
这不是简单的岗位命名变化，而是 AI Native 团队组织方式的变化。
过去，一个产品团队通常按职能拆分：
产品 / 设计 / 工程 / 数据 / 运营但在 Claude Code、Codex、Cursor 这类工具普及后，一个人可以更快完成原型、代码、测试、分析、迭代和发布。AI 正在压缩传统职能之间的边界。
于是，团队真正需要区分的，不再只是“谁负责产品、谁负责设计、谁负责工程”，而是：
谁负责探索？
谁负责构建？
谁负责清理？
谁负责增长？
谁负责维护？也就是说，AI 把“执行能力”放大之后，真正稀缺的能力会变成判断力、系统感、取舍能力和产品生命周期意识。
方法
这个框架对创业团队尤其有价值。
在产品早期，最重要的组合是：
Prototyper + Builder + Sweeper先大量试方向，再快速做出来，同时不断清理复杂度。
否则团队很容易陷入两个极端：要么只停留在想法层，要么原型越堆越多，系统越来越乱。
当产品开始接近 PMF 后，团队需要引入：
Grower这时重点不再是继续堆新功能，而是围绕真实用户行为做打磨：谁留下来了，谁转化了，谁愿意持续使用，哪些功能真正创造价值。
当产品进入规模化阶段后，团队必须补上：
Maintainer否则系统会被历史包袱、复杂度、成本、性能和稳定性问题拖垮。
行动
每个 AI 产品团队都可以用这五个角色做一次自检：
我们现在缺的是新想法，还是缺把想法变成生产级系统的人？
我们是不是一直在加功能，却没有人负责下线、清理和简化？
我们是否已经到了需要增长和维护的阶段，但团队还停留在原型冲刺状态？
这五种角色不一定对应五个人，更不是新的固定岗位。它们更像五种工作模式。
一个优秀的 AI Native Builder，未来可能需要在不同阶段切换身份：早期是原型者，验证后是搭建者，复杂度上升后成为清道夫，进入市场后承担增长者角色，规模化之后再进入维护者状态。
最终判断
AI 时代的团队分工，不会简单变成“人人都是工程师”，而会变成“人人都要理解产品生命周期”。岗位会变轻，贡献模式会变重。