未来产品团队的五种角色：从职能分工到价值分工

最近看到一条很有意思的推文：当工程、产品、设计、数据科学等职能逐渐融化成一种新的复合型角色时，未来团队里的「角色」会不会不再按岗位划分，而是按创造价值的方式划分？

这条推文以 Claude Code 团队为例，把一个产品团队里的贡献者抽象成五种原型：

1. Prototyper，原型者：提出新想法，快速做出大量原型，其中大多数不会真正上线。
2. Builder，建设者：把原型或想法快速变成生产级产品和基础设施。
3. Sweeper，清扫者：打磨 UI，简化代码和系统，下线不必要的功能，优化性能。
4. Grower，增长者：在产品已经被做出来之后，持续迭代，推动产品市场匹配。
5. Maintainer，维护者：负责成熟系统的安全、可靠、速度和成本效率，让它能规模化运转。

这个分类的关键不在于名字，而在于它提出了一种更贴近 AI 时代的组织视角：未来的产品团队，可能会越来越少用「你是工程师、设计师、PM、数据科学家」来定义人，而是更多用「你主要在产品生命周期里解决哪类问题」来定义人。

职能边界正在变薄

过去，产品团队的协作方式很像一条分工明确的流水线。

PM 写需求，设计师出稿，工程师实现，数据分析师看指标，测试和运维保障质量。每个人都有清晰的岗位边界，也有相对固定的交付物。

但 AI 工具正在把这些边界变薄。

一个工程师可以借助模型快速画出可用的交互原型；一个设计师可以直接用自然语言生成前端代码；一个 PM 可以让 Agent 拉数据、写 SQL、做用户反馈归类；一个数据科学家也可以直接把分析结果包装成可交互的产品实验。

这并不意味着所有人都会变成同一种「全能人」。更准确地说，是岗位边界弱化之后，团队真正需要的能力结构暴露出来了。

你会发现，团队里真正稀缺的不是某个职能头衔，而是某种阶段性价值：

• 有人能不断打开可能性。
• 有人能把可能性变成可上线系统。
• 有人能把复杂系统重新收拾干净。
• 有人能把产品推向更强的市场匹配。
• 有人能让一个已经成功的系统长期稳定运转。

这就是五种角色划分真正有价值的地方。

一、原型者：负责把可能性打开

原型者的工作不是证明自己每个点子都对，而是用足够低的成本扩大探索空间。

在早期产品里，最危险的事情往往不是做错，而是过早收敛。团队很容易因为第一个看起来合理的方案就停下来，然后把大量工程资源砸进一个其实还没有被验证的方向。

原型者的价值，是持续制造可被讨论、可被试用、可被否定的东西。

他们可能一天做出三四个 demo，可能拉出一堆看起来不成熟的交互，可能写出不适合长期维护的实验代码。很多产物最终都不会上线，但这不是浪费。因为在不确定性很高的时候，快速排除错误方向本身就是进展。

AI 会显著放大这种角色。过去做一个原型可能要等设计、前端、后端一起排期，现在一个熟练使用 AI 工具的人，可以在更短时间里把想法变成可感知的东西。

但原型者也有天然风险：容易迷恋新想法，忽视收敛；容易不断开坑，却不负责把坑填完。所以一个团队如果只有原型者，会很热闹，但很难沉淀出真正的产品。

二、建设者：负责把原型变成产品

建设者关心的是另一件事：这个东西能不能真的交付给用户使用？

从 demo 到 production，中间隔着一条很深的沟。原型阶段可以手动补数据，可以绕过异常路径，可以只服务一个理想用户。但生产级产品必须处理权限、错误、性能、监控、部署、兼容性、数据一致性和一堆边界情况。

建设者的价值，是把「看起来能用」变成「真的能用」。

这类人通常很擅长在速度和质量之间做权衡。他们不会为了完美架构拖慢全部进度，也不会把一次性脚本伪装成长期系统。他们知道哪些地方可以先简化，哪些地方从第一天就不能含糊。

AI 时代的建设者会更重要。因为原型生产速度变快之后，团队会更容易产生大量半成品。真正稀缺的能力，不是再多做几个 demo，而是判断哪个 demo 值得产品化，并把它稳稳落到现实系统里。

三、清扫者：负责把复杂度降下来

清扫者是很多团队最容易低估的角色。

他们不一定总是在做最显眼的新功能，却经常决定一个产品能不能继续变快。因为任何产品只要持续迭代，就会积累复杂度：没人用的功能、重复的组件、绕来绕去的状态、历史包袱、性能债、文案债、交互债。

复杂度不会自己消失。它只会在每次新增需求时收税。

清扫者做的事包括：

• 简化一个被过度设计的流程。
• 删除一个长期没人使用的功能。
• 合并重复的代码路径。
• 把混乱的 UI 状态重新整理清楚。
• 优化性能，让系统重新变得轻快。
• 重新划清模块边界，降低后续开发成本。

这类工作有时不容易被指标立刻捕捉，但它会改变团队的速度曲线。没有清扫者，产品早期积累的速度优势会慢慢被复杂度吃掉。

尤其在 AI 编程越来越普及之后，清扫者的重要性会进一步上升。因为 AI 可以快速生成代码，也会快速放大代码量。生成不是终点，整理才是系统长期可用的前提。

四、增长者：负责让产品更接近市场

当一个产品已经能用之后，问题就变了。

早期团队最关心「能不能做出来」，进入增长阶段后，真正的问题变成「为什么用户没有更频繁地用？为什么转化没有发生？为什么留存不够好？为什么明明有价值，用户却感受不到？」

增长者的核心能力，是把产品、用户、渠道和数据连在一起。

他们不只是做增长黑客式的短期技巧，也不只是盯着仪表盘看数字。他们会从用户行为里发现摩擦点，从反馈里提炼真实需求，从漏斗里定位问题，然后推动产品迭代。

增长者往往横跨多个传统职能：懂产品判断，懂数据分析，懂用户沟通，也懂一定的实现成本。他们不一定亲自写所有代码，但必须能把模糊的增长问题拆成可验证的实验。

如果说原型者负责打开可能性，建设者负责交付可能性，那么增长者负责判断这件事是否真的进入了市场的循环。

五、维护者：负责让成功可以持续

维护者常常出现在产品已经比较成熟之后。

当系统承载了大量真实用户、真实收入、真实业务流程，团队的第一目标不再只是「更快推出新东西」，还包括「不要坏」「不要慢」「不要泄露」「不要失控」「不要贵到不可持续」。

维护者关心的是成熟系统的长期质量：

• 安全性：权限、数据、依赖、供应链风险。
• 可靠性：故障恢复、可观测性、容量规划。
• 性能：响应速度、资源利用率、关键路径优化。
• 效率：成本、自动化、内部工具、运维流程。
• 演进：在不破坏已有用户体验的情况下持续升级。

一个团队如果过早进入维护者模式，可能会变得保守；但一个已经有强 PMF 的产品如果缺少维护者，就会在规模化阶段把早期成功变成技术和组织负担。

维护不是停止创造，而是让创造出来的东西能继续存在。

不同阶段，需要不同配比

这套五角色模型最有用的地方，是它能帮助团队理解「当前阶段到底缺哪种能力」。

如果产品还很新，甚至还没有找到 PMF，团队最需要的是原型者、建设者和清扫者。此时重点是快速探索、快速交付、快速整理，不要让早期混乱拖垮后续速度。

如果产品已经开始增长，并初步找到 PMF，团队需要更多建设者、清扫者和增长者，同时引入一部分维护者。因为这时既要继续补齐产品，又要持续优化体验和转化，还要开始为规模化做准备。

如果产品已经有很强的 PMF，团队的重心会转向清扫者、增长者和维护者，同时保留一部分建设者。此时盲目增加原型和新功能，未必是最大收益；更大的价值可能来自提高系统质量、扩大市场覆盖、降低长期复杂度。

这也解释了为什么同一个人在不同阶段的价值会变化。

一个早期非常优秀的原型者，到了成熟期可能会觉得处处受限；一个强维护者如果被放在还没确定方向的早期产品里，也可能会把系统做得过重。问题不一定是人不行，而是角色和阶段不匹配。

角色不是岗位，而是贡献模式

这套模型还有一个很关键的观察：这些角色并不绑定传统职能。

有的设计师是典型原型者，能快速拿出一堆新交互；有的设计师更像清扫者，擅长把复杂流程变简单。有的工程师是建设者，能把系统快速做稳；有的工程师是维护者，擅长可靠性、安全和性能。有的 PM 是增长者，有的 PM 其实更偏原型者。

一个人也不一定只属于一种角色。很多人会横跨两类，有些人甚至能横跨三类。

但很少有人能在所有阶段都同样强。团队管理者真正要看的，不是组织架构图上的职能格子是否齐全，而是当前产品阶段需要的贡献模式是否齐全。

这对招聘、绩效和协作都会产生影响。

招聘时，不应该只问「我们还缺一个前端」或「我们还缺一个 PM」，还要问「我们缺的是能探索方向的人，还是能产品化的人，还是能清理复杂度的人？」

评价时，也不应该只用一种标准衡量所有人。原型者的价值可能体现在探索数量和洞察质量；建设者的价值体现在交付速度和生产质量；清扫者的价值体现在复杂度下降；增长者的价值体现在 PMF 逼近；维护者的价值体现在系统长期稳定和效率。

协作时，则要避免让所有人都挤在同一种角色里。一个全是原型者的团队会漂浮，一个全是维护者的团队会迟缓，一个缺少清扫者的团队会越来越重，一个缺少增长者的团队可能做出好东西却找不到市场。

对个人的启发：别只定义职位，要定义你的主要价值

对个体来说，这个模型也很有启发。

AI 正在降低很多具体技能的门槛。会写一点代码、会做一点设计、会分析一点数据，都会变得越来越常见。更重要的问题会变成：你最擅长在哪个阶段创造不可替代的价值？

你是擅长从 0 到 0.1，把模糊想法变成原型？

还是擅长从 0.1 到 1，把原型变成可上线产品？

还是擅长从混乱到清晰，把复杂系统重新整理顺？

还是擅长从 1 到 10，通过用户、数据和实验推动增长？

还是擅长从 10 到 100，让成熟系统稳定、高效、可靠地规模化？

这个问题比「我是工程师还是产品经理」更接近未来工作的本质。

因为当工具越来越强，职能边界越来越薄，真正能区分人的，不再只是掌握了哪门工具，而是你在不确定的产品生命周期里，能稳定承担哪类责任。

结尾

未来的产品团队不一定会取消工程、产品、设计、数据这些岗位名称，但这些名称的重要性可能会下降。

更重要的，是团队能否在不同阶段组合出正确的角色结构：有人探索，有人建设，有人清理，有人增长，有人维护。

这套五角色模型的价值，不是提供一套新的头衔，而是提醒我们：产品不是靠职能表格长出来的，而是靠不同类型的价值贡献接力长出来的。

在 AI 把工具能力不断拉平之后，真正值得重新思考的，是我们如何定义人、定义团队，以及定义一件事从想法走向成熟所需要的全部力量。