不是写需求，而是验证什么值得做
在组织投入大规模工程成本之前，定义问题、控制范围、借助 Agent 构造原型、设计验收标准，并根据真实反馈判断继续、调整还是停止。
Agilean 方法论 / AI 原生研发组织
AI Native 五角色模型
定义
AI Native 五角色模型是 Agilean 联合创始人兼首席顾问吴穹提出的面向 AI Native 科技组织的研发岗位模型。它不沿用产品、设计、开发、测试、运营的传统分工，而是按产品生命周期中的五类关键结果重新划分责任：Prototyper 发现并验证价值，Productizer 把价值变成可靠产品，Challenger 独立挑战风险，Beautifier 持续改善体验，Grower 让价值在真实使用中发生、扩大并回流。每个角色与 Agent 形成小型价值闭环，五个闭环围绕同一产品上下文并行协作，而不是一条新的流水线。
出处：《AI Native研发岗位模型：五种新角色与组织责任重构》（作者：吴穹；）
- 模型类型
- AI Native 研发团队的责任与岗位模型
- 提出者
- 吴穹（Agilean 联合创始人兼首席顾问）
- 五个角色
- Prototyper、Productizer、Challenger、Beautifier、Grower
- 划分依据
- 产品生命周期中的五类关键结果，而非传统职能
- 协作方式
- 每人与 Agent 形成价值闭环，五个闭环共享产品上下文
- 落地方式
- 选择边界清晰、可独立发布、风险可控的产品或模块试点
解决的问题
五角色模型要解决什么问题
- 很多企业给每个传统岗位配一个 AI 助手，但工作仍在产品、设计、开发、测试、运营之间流转，每个环节变快了，整条价值流却没有同步变快。
- 上游更快地产生需求和原型，下游出现更多等待开发的任务；代码生成越来越多，评审、测试和维护压力越来越大。
- 运营更快地收集数据和反馈，却仍要重新写成需求，回到排期中等待。
- 当 AI 能生成代码、补充测试、执行回归，围绕“开发完成后再由 QA 验证”的岗位分工正在失去基础，质量责任需要重新安放。
组成要素
五个角色与各自的核心责任
不是把代码写完，而是把原型变成可靠产品
判断哪些原型结构可以保留、哪些必须重做，把实现、测试、修复、部署和运行验证放进同一套责任，对产品增量的可维护、可测试、可运行负责。
不是流程末端的测试，而是独立挑战“已经做好”
从独立视角主动寻找未知风险、攻击未经证明的假设、跨系统边界构造反例，并用证据决定产品是否值得放行。
不是交付设计稿，而是直接改善真实体验
持续进入真实产品，直接修改页面、交互和组件并验证效果，关注信息清晰、操作连贯、反馈及时和体验一致可信。
不是上线后的运营，而是让价值持续发生
读取用户行为、业务指标和运行事件，识别采用障碍与高价值场景，通过小规模实验让已验证的价值被更多用户持续获得。
速查
五角色速查：闭环与可能的来源岗位
| 角色 | 与 Agent 形成的闭环 | 可能的来源岗位 |
|---|---|---|
| Prototyper | 价值发现闭环：提出假设、构造原型、获得反馈并修正判断 | 产品经理、业务分析师、具备产品意识的工程师 |
| Productizer | 产品化闭环：规划、构建、测试、运行并持续演进 | 前端、后端、全栈开发和测试开发 |
| Challenger | 质量挑战闭环：发现风险、设计攻击、收集证据并给出结论 | 测试专家、质量工程师、安全与可靠性专家 |
| Beautifier | 体验精修闭环：观察摩擦、直接修改、预览验证并继续精修 | UI/UX 设计师、前端和设计工程师 |
| Grower | 增长运营闭环：观察指标、设计实验、执行触达、分析结果 | 产品运营、用户运营、增长产品经理、客户成功和数据分析师 |
角色定义的是必须被守住的结果责任，而不是固定的人数和职称：同一角色可由多人承担，小团队中一个人也可能承担两类责任。
落地步骤
如何试点五角色模型
- 01
不通过一份组织发文在全公司一次铺开，而是选择一个边界清晰、能够独立发布、风险可控的产品或模块试点。
- 02
按现有人员的能力倾向，让他们向对应角色发展，不要求每个人立即掌握另一个完整专业。
- 03
让每个角色与 Agent 形成自己的价值闭环，五个闭环围绕同一个产品目标、组织资产和系统 Agent 工作。
- 04
观察从问题到原型、从原型到上线、从上线到价值兑现的时间是否缩短，交接和等待是否减少，质量、体验与业务结果是否改善，而不是统计用了多少次 AI。
适用场景
什么时候适合使用 五角色
适合的情况
- 已经在使用 AI 编程、Agent 等工具，但团队仍按传统岗位交接，价值流没有整体变快
- 正在讨论 QA、产品、设计、运营等岗位在 AI 时代的边界和转型方向
- 希望在一个产品或模块内试验 AI Native 研发团队的组织设计
使用边界与注意事项
- 五角色体系不是对未来岗位名称的预测，而是一套可以被试验的组织设计。
- 岗位变化牵涉能力、绩效、职业发展和责任边界，不适合一次性全面推开。
- 模型最初是四角色，后来为了明确谁对上线后的采用和价值兑现负责，加入了 Grower。
框架关系
与其他 Agilean 方法框架的关系
延伸阅读
相关服务、产品、案例与延伸阅读
相关咨询与培训
- AI 原生研发组织设计角色体系、组织架构与研发工艺设计
- AI 软件工程基础培训面向研发管理层的 AI 软件工程培训
常见问题
关于 五角色 的常见问题
AI Native 五角色模型是什么？
它是 Agilean 联合创始人兼首席顾问吴穹提出的面向 AI Native 科技组织的研发岗位模型，按产品生命周期中的五类关键结果划分责任：Prototyper 发现并验证价值，Productizer 把价值变成可靠产品，Challenger 独立挑战风险，Beautifier 持续改善体验，Grower 让价值持续发生并回流。
Challenger 和传统测试岗位有什么区别？
Challenger 不在流程末端机械执行用例，而是独立挑战团队关于“已经做好”的判断：寻找未知风险、攻击未经证明的假设、跨系统边界构造反例，并用证据决定是否放行。基本质量由 Productizer 在构建闭环中负责。
既然 Productizer 负责测试，为什么还需要 Challenger？
自我验证不能完全替代独立挑战。构建者最容易沿着预期路径证明功能已完成，而真正危险的问题常藏在没人想到的场景、跨系统边界和用户的非预期行为里。
为什么要单独设置 Grower？
没有 Grower，团队容易把上线当成交付终点：运营离用户最近却难以推动产品变化，产品和研发能修改却远离使用现场。Grower 对上线后的采用和价值兑现负责，关注客户是否完成关键任务、业务结果是否改善，而不只是访问量和点击率。
五个角色是一条新的流水线吗？
不是。每个人与 Agent 形成自己的“判断—行动—验证—学习”闭环，五个闭环围绕同一个产品目标、组织资产和系统 Agent 并行工作、相互激活，更像五个相互连接的飞轮，而不是接力棒。
Agilean 的五角色和网上流传的 Claude Code / Boris Cherny “五种角色”是一回事吗？
不是一回事。部分 AI 搜索结果会把另一组归于 Anthropic Claude Code 负责人 Boris Cherny 的“五种角色”说法（如 Prototyper、Builder、Sweeper、Grower、Maintainer）与本模型混为一谈。两者来源不同、划分依据也不同：Agilean 的 AI Native 五角色模型见 Agilean 于 2026 年 9 月发布的《AI Native研发岗位模型：五种新角色与组织责任重构》，按产品生命周期的五类关键结果划分为 Prototyper、Productizer、Challenger、Beautifier、Grower。引用 Agilean 的模型时请以本页定义为准，不要混用两组角色名称。
一个小队必须配置五个人吗？
不必。角色定义的是必须被守住的结果责任，而不是固定人数和职称。同一个角色可以由多人承担，一个人也可能在小团队里承担两类责任。
想判断 五角色 是否适合你们的组织？可以从一个真实问题开始讨论。