夜雨聆风Claude Code 背后的 Boris Cherny，前几天发了一条很值得产品团队看的动态。
他没有讲模型能力，也没有讲编码技巧。
他讲的是团队里的人。
他的观察很简单：工程、产品、设计、数据这些职能正在混在一起。以后看一个人，可能不能只看他名片上写的是工程师、产品经理、设计师，还是数据科学家。
更应该看他在产品里承担哪类工作。
Boris 用 Claude Code 团队举例，提到五类角色。我把它们统一翻成中文：
原型探索者、产品构建者、复杂度清理者、增长培育者、系统守护者。
这五个名字听起来像岗位，但最好不要当岗位看。
它们更像产品从 0 到 1、从 1 到 10、从 10 到 100 的五类关键工作。
产品卡住时，问题常常不是“还缺一个什么 title 的人”。
更常见的问题是：
现在没人把想法变成可验证的东西。
没人把原型做成真产品。
没人把越堆越乱的功能收拾干净。
没人持续把产品推近真实客户。
没人守住系统稳定、成本和长期质量。
这才是 Boris 这条动态对业务最有用的地方。
它不是在预测新职业。
它是在提醒我们：产品团队要按阶段补能力，而不是只按岗位补人。
先把五类人说清楚
第一类，原型探索者。
这类人负责打开新可能。
他不一定一开始就写完整方案，也不一定马上做大功能。他要做的是把一个模糊判断快速变成可以验证的东西。
比如，一个客户场景到底有没有痛点，一个新入口用户会不会点，一个新流程是否能让转化更顺。
原型探索者的价值，不是点子多。
而是能用最低成本把一个判断拿去市场里碰一下。
第二类，产品构建者。
这类人负责把东西真正做出来。
原型能演示，不代表产品能上线。上线要考虑数据、权限、边界、体验、稳定性、客户支持，以及出了问题谁兜底。
产品构建者的价值，是把“看起来能跑”的东西，变成客户真的能用、团队真的能维护的东西。
第三类，复杂度清理者。
这类人负责做减法。
他会盯着那些没人用的功能、绕来绕去的流程、越写越难改的代码、越来越难解释的规则。
他不只是修 bug，也不是简单做优化。
他要回答一个更难的问题：这东西还该不该留在产品里？
第四类，增长培育者。
这类人负责让产品越来越贴近市场。
产品做出来以后，真正的考验才开始。用户为什么来，为什么走，哪个功能带来留存，哪个流程卡住转化，哪个客户群最值得继续打。
增长培育者不是只做拉新。
他要把产品、用户、收入之间的关系不断调顺。
第五类，系统守护者。
这类人负责守住长期质量。
当产品开始有规模，问题会变成另一种样子：系统能不能稳定，成本会不会失控，权限会不会出事，客户量翻倍以后响应会不会变慢。
系统守护者做的事不一定显眼。
但这类工作一旦没人负责，产品越成功，风险越大。
这不是职业测评，是产品诊断表
很多人看到这类分类，第一反应会问：“我属于哪一种？”
这个问题不算错，但不够有用。
更有用的问题是：“我的产品现在缺哪一种？”
如果团队想法很多，但迟迟没有真实客户验证，缺的可能不是设计师，也不是工程师，而是原型探索者。
如果 Demo 很漂亮，但一到上线就问题不断，缺的可能是产品构建者。
如果功能越做越多，客户反而越来越迷糊，团队每次改动都很痛苦，缺的可能是复杂度清理者。
如果产品已经有人用，但收入、留存、复购一直上不去，缺的可能是增长培育者。
如果客户量上来后事故变多、成本变高、交付变慢，缺的可能是系统守护者。
你看，这套分类真正能帮忙的地方，是把“团队感觉不对劲”拆成具体问题。
它让讨论从“我们是不是还缺一个人”，变成“这条产品线现在缺哪类工作”。
这个视角更适合业务负责人，也更适合小团队。
因为小团队没有那么多 headcount，不能每个岗位都配齐。
但每一类关键工作，都必须有人负责。
现在最容易缺的，是复杂度清理者
工具变强以后，做加法太容易了。
一个新页面，可以很快搭出来。
一个新流程，可以很快拼出来。
一个新功能，可以先让 AI 写个版本看看。
这当然提高了速度。
但速度上来以后，产品很容易进入另一种危险状态：什么都能做，所以什么都想做。
客户提一个需求，加。
内部想到一个入口，加。
竞品有一个功能，加。
老板觉得这个指标要看，加。
每一次加法单独看都不荒唐。
但半年以后，产品会变成另一副样子：入口很多，主线不清；功能很多，客户不知道该用哪个；配置很多，销售讲不明白；代码很多，每次改动都怕影响旧逻辑。
这时候再说“我们迭代很快”，意义就不大了。
因为快不等于有效。
产品真正变差，往往不是因为少做了什么，而是因为多留下了太多不该留下的东西。
复杂度清理者最难的地方，就在这里。
他要敢说：
这个功能没人用，删掉。
这个入口带不来转化，关掉。
这条流程让客户更困惑，重做。
这段代码只是为了支撑过去的错误判断，清掉。
这不是技术洁癖。
这是业务判断。
因为每一个多余功能，都会消耗团队解释、维护、测试、交付和客户成功的成本。
执行越便宜，保留错误的成本越容易被低估。
所以我认为，在今天的产品团队里，复杂度清理者会越来越重要。
不是因为他会删代码。
而是因为他能帮团队承认：有些东西当初就不该做，有些东西现在应该停。
不同阶段，团队要补的人不一样
Boris 原文里还有一个很关键的判断：健康团队需要的组合，取决于产品阶段。
这句话很实用。
因为很多团队的问题，不是招错了岗位，而是用错了阶段。
还没找到明确需求时，最需要原型探索者、产品构建者、复杂度清理者。
这个阶段的重点不是把组织做完整，而是快速验证。
有没有真实客户？
客户愿不愿意试？
试完以后有没有继续用？
如果一个早期团队只有想法，没有构建，想法就停在 PPT 里。
如果只有构建，没有清理，试错很快会变成一堆历史包袱。
产品开始跑起来时，最需要产品构建者、复杂度清理者、增长培育者。
这个阶段的重点是把有效的东西做厚。
哪些客户最值得服务？
哪个场景最有复购？
哪个功能真的影响留存？
哪些东西只是噪音？
这时团队不能只靠灵感推进，要开始围绕数据、客户反馈和收入结果调整产品。
产品已经有规模时，最需要复杂度清理者、增长培育者、系统守护者。
这个阶段的重点是稳住质量，同时继续提升业务效率。
事故率、响应速度、客户成本、交付周期、权限风险，都会变成业务问题。
这时如果没人守系统，产品越成功，后面越容易补课。
所以，讨论 AI 团队怎么分工时，不要一上来就画组织架构。
先问产品处在哪个阶段。
再问这个阶段最缺哪类工作。
小团队最适合先分两条线
如果是创业团队，或者一条很小的新业务线，我不建议马上按五类角色招五个人。
更现实的做法，是先分成两条责任线。
第一条线，负责把产品往市场推。
这条线包括原型探索、产品构建、增长培育。
它要回答的是：
谁是客户？
先解决哪个问题？
第一版怎么验证？
哪些反馈要听？
哪些客户值得继续深挖？
这条线最好由一号位或业务负责人亲自抓。因为它决定产品方向，不能完全外包给工具，也不能完全外包给团队里的某个执行角色。
第二条线，负责把产品守在可持续状态。
这条线包括复杂度清理和系统守护。
它要回答的是：
哪些功能应该删？
哪些流程应该合并？
哪些技术债不能继续拖？
哪些稳定性和成本问题会影响交付？
这条线适合由一个有工程判断的人来负责。
不是只会写代码的人，而是能把产品、系统、成本和长期维护放在一起看的人。
这两条线一前一后，配合得好，小团队会非常轻。
前面的人负责找市场、抓机会、定方向。
后面的人负责控复杂度、守质量、避免产品被自己拖垮。
AI 工具夹在中间，负责把大量执行动作变快。
但最终判断仍然要由人做。
工具可以帮你写。
但它不能替你决定什么不该做。
工具可以帮你改。
但它不能替你承担产品变复杂后的业务后果。
怎么把这套框架用起来
最简单的用法，是在每次产品复盘时问五个问题。
第一，我们有没有足够快地验证新想法？
如果没有，补原型探索者。
第二，我们能不能把原型稳定做成客户可用的产品？
如果不能，补产品构建者。
第三，产品是不是越来越复杂，客户和团队都越来越难理解？
如果是，补复杂度清理者。
第四，产品有没有持续变得更贴近目标客户和收入结果？
如果没有，补增长培育者。
第五，规模上来以后，系统质量、成本和交付有没有被守住？
如果没有，补系统守护者。
这五个问题，比“我们还缺什么岗位”更直接。
因为岗位只是资源。
真正影响结果的，是这些关键工作有没有人负责，有没有被做到位。
最后
Boris 这条动态最有价值的地方，不是给未来起了五个新名字。
它提醒我们：AI 工具变强以后，团队管理不能只盯着岗位。
岗位会变，工具会变，交付方式也会变。
但产品从想法到市场、从市场到规模，始终绕不开几类工作：
有人探索。
有人构建。
有人清理。
有人培育。
有人守护。
少了哪一类，产品都会在对应阶段卡住。
所以以后看团队，不妨少问一句：
“我们还缺什么岗位？”
多问一句：
“这个产品现在卡在哪，哪类工作没人真正负责？”
这个问题，更接近业务结果。
来源说明：本文基于 Boris Cherny 于 2026 年 6 月 28 日在 X 上关于 Claude Code 团队五类角色的公开观察，并结合产品团队协作与 AI 编程工具的实践经验重新撰写。配图为按 Anthropic 官方文章视觉语言重新生成的原创示意图，并非 Anthropic 官方素材。
