AI 时代的软件团队应该是怎么样的?Claude Code 的新型组织结构

Claude Code 的创建者 Boris Cherny 昨天天发了一条挺有意思的推文。

他说，当工程、产品、设计、数据这些传统职能开始融合，未来的产品团队也许会长成另一种样子。比如在 Claude Code 团队里，他看到的不是简单的「工程师」「产品经理」「设计师」职位，而是五种角色。

有人负责不断冒出新想法，把很多原型扔出来。有人负责把一个粗糙想法快速变成可以上线的产品。有人负责清理 UI、删除功能、简化代码、优化性能。有人负责在产品找到市场后继续打磨增长。还有人负责成熟系统的安全、可靠、性能和成本。

他给这五类人起了名字：Prototyper、Builder、Sweeper、Grower、Maintainer。

我觉得这条推文真正有意思的地方，不在于它给未来岗位发明了几个新名词，而在于它换了一个看团队的方式。

过去我们习惯问，一个团队里有几个工程、几个产品、几个设计、几个数据。Boris 的问题更像是：这个产品现在处在哪个阶段？它缺的是探索、建造、清理、增长，还是维护？

这一下，分工的单位变了。

它不再稳定地长在岗位上，而是长在产品阶段里。

一个人在项目早期可能是 Prototyper，负责试方向。方向一旦成立，他又要变成 Builder，把东西做成真正可用的系统。系统开始变乱，他就得切到 Sweeper，去删功能、改体验、清理复杂度。产品有了用户，他又要关心增长和留存。再往后，他还要面对稳定性、安全、成本和维护。

如果一个人死死认领某个身份，说「我就是做原型的」「我只负责写代码」「我不碰增长」「维护不是我的事」，那他很可能只能陪项目走一小段路。

但一个真正想把事情做成的人，迟早会发现，项目不按你的岗位说明书发展。项目只会不断暴露新的瓶颈。哪里卡住，你就得去哪里。

这就是 AI 时代软件分工里最微妙的变化：团队还需要分工，但人不能太早被分工困住。

要理解这件事，得往回看。

生产组织的历史，其实就是人类不断重新安排人、工具、知识和协调成本的历史。哪个东西贵，组织就围着它设计；哪个东西便宜，组织就开始重组。

分工也是这样。它不是管理学家坐在会议室里发明出来的，而是每个时代对当时稀缺资源的回答。

工匠时代，一个木匠、鞋匠、铁匠往往理解完整作品。他选材料，做设计，动手加工，修修补补，最后交到客户手里。那时候工具弱，流程不标准，知识主要长在人的身体和经验里。

所以那个时代需要完整的人。

到了工业革命，机器变强了。纺织机、蒸汽机、机床、电力系统出现以后，生产过程开始被拆成一个个稳定动作。只要产品能标准化，动作能重复，训练一个人只做一小段，就比培养一个完整工匠便宜得多。

福特汽车流水线把这件事推到极致。

产品移动，人固定。节奏固定，动作固定。工人不需要理解整辆车，他只需要在规定时间里拧好眼前那颗螺丝。

这当然压抑人，但它在当时非常有效。

因为那个时代最重要的事，是用最低成本、最高一致性，生产出大量标准化产品。为了规模，系统把人的完整判断拿走，把复杂性放进机器、流程和管理里。

所谓「螺丝钉」，就是这么来的。

软件行业看起来离工厂很远，但早期软件公司其实也长出了一套知识流水线。

产品经理写需求，设计师画稿，工程师实现，测试工程师验证，运维负责上线，数据团队再回头分析指标。这里拆掉的不是体力动作，而是知识职能。

这套结构不是凭空来的。它曾经很合理。

因为写代码门槛高，部署门槛高，查数据门槛高，设计工具也有门槛。一个人很难同时理解用户、产品、前端、后端、数据、安全和运维。专业分工能够降低训练成本，也能让复杂系统维持基本秩序。

但它也有副作用。

用户的痛感到了产品经理那里，变成需求文档。需求到了设计师那里，变成流程图。流程图到了工程师那里，变成 ticket。上线后的真实反馈，又要经过数据报表和会议再传回来。

每个人都完成了自己那一段，可整体经常没人真正负责。

软件里的「螺丝钉」不是站在流水线旁边重复动作，而是在一个职能格子里反复交付局部结果。

AI 让这套结构开始松动。

因为很多原本需要专业职能承担的动作，正在被工具降低门槛。

写代码变快了。做原型变快了。生成测试变快了。读文档、查日志、写 SQL、总结用户反馈、画一个基础界面，也都比过去容易了。

这不代表专业消失。

安全、架构、数据库、性能、合规这些东西，仍然需要深专家。AI 没有让所有人突然全能。它真正改变的是另一件事：过去必须交给另一个岗位的很多动作，现在一个人可以先跑起来。

于是组织要重新算一笔账。

分工一直有两个面。专业化能提高效率，但交接会制造成本。当专业化收益大于协调成本，组织就会拆分；当协调成本大于专业化收益，组织就会重新合并。

任务稳定、重复、答案清楚的时候，拆得越细越划算。市场变化快、产品还不确定、反馈很重要的时候，拆得太细就会拖慢学习。

福特流水线适合生产确定的汽车。

但软件产品经常不知道答案。用户到底要什么，什么体验真的顺，什么功能能留存，什么方向该删掉，这些东西往往上线后才知道。

当 AI 把「做」的成本压低，「等别人、解释上下文、开会同步、跨部门排期」这些成本就变得更刺眼。

这也是动态角色出现的原因。

它不是为了让一个人干五个人的活，而是为了缩短从判断到行动，再到反馈的距离。

过去一个团队会问：这个需求谁写？这个页面谁画？这个接口谁做？这个指标谁看？

未来更重要的问题可能是：这个目标现在卡在哪里？是没有想法，还是想法太多？是没人把原型做成产品，还是产品已经太乱？是该继续加功能，还是该删东西？是该增长，还是该补可靠性？

这也是我觉得 Sweeper 这个角色特别值得单独拿出来说的原因。

AI 会让 Builder 变多。会写代码的人变多，会搭 demo 的人变多，会把一个想法快速堆出来的人变多。

但能把东西变少的人，可能会变得更稀缺。

删功能，删配置，删抽象，删没人用的入口，删掉一个看起来聪明但让系统变复杂的设计，这些事过去就难，AI 时代会更难。因为当生成变便宜，堆积就会更自然。每个人都能加一点，最后就变成没人说得清的产品和没人敢动的代码。

所以未来软件团队最缺的，可能不只是更多 Builder，而是足够强的 Sweeper。

他要能判断什么不该存在，什么复杂度不值得，什么体验看似完整其实多余，什么代码应该被删掉而不是继续包装。

这背后有一条很清楚的历史线。

工匠时代，人是完整的，但工具弱，规模小。

工业时代，机器变强，系统为了规模把人拆成动作。

软件公司时代，知识复杂，组织把人拆成职能。

AI 时代，工具开始承担一部分专业动作，人又有机会重新覆盖更完整的目标链条。

但这不是回到手工业，也不是浪漫的个体觉醒。

更准确地说，它像一种增强型工匠。

一个人借助 AI、云服务、开源生态、自动化测试和各种 API，重新有能力从想法走到原型，从原型走到上线，从上线走到反馈，再从反馈里决定继续做、改掉，还是删掉。

人重新变完整，不是因为组织突然更尊重人，而是因为在新的工具条件下，完整的人再次变得更有效率。

这句话听起来有点冷，但我觉得它更接近现实。

AI 时代的组织变化，不会只带来自由，也会带来更重的责任。过去你可以说「这不是我的职责」。以后这句话会越来越难说出口。因为工具已经让你有能力跨出去一部分，团队也会期待你至少理解目标，而不是只交付一个职能切片。

当然，这不意味着人人都要变成五边形战士。

复杂系统永远需要深度分工。成熟系统需要 Maintainer，安全问题需要安全专家，底层性能问题需要真正懂系统的人。动态角色如果被公司误读成「一个人干完所有事」，那就只是换了包装的压榨。

真正值得期待的变化，是分工从墙变成膜。

专业还在，但边界不再那么硬。你有自己的主轴，也能围绕目标临时跨出去。问题进入深水区，再让专家接管或审查。

未来的软件团队，可能不会先问「我们还缺几个岗位」，而会先问「这个产品现在处在哪个阶段」。

新产品缺探索和建造，就需要 Prototyper、Builder 和 Sweeper。找到 PMF 以后，就需要 Builder、Sweeper 和 Grower。产品成熟后，维护、可靠性、成本和安全开始变重，Maintainer 就必须站上来。

这比按岗位配人更接近产品本身。

因为产品不是靠岗位长出来的。产品靠一连串动作长出来：发现、建造、清理、增长、维护。

过去工业组织把人拆小，是为了提高生产效率。现在 AI 工具把很多执行动作压低成本，软件组织就开始把责任重新合并，去提高学习速度。

所以 Boris 那条推文让我想到的，不只是 Claude Code 团队怎么分工。

它更像一个信号：软件行业正在重新计算人的位置。

过去最贵的是执行，所以组织想办法把执行拆细、标准化、规模化。现在越来越多执行正在变便宜，真正贵的是判断、取舍、反馈速度和复杂度控制。

AI 没有消灭分工。

它只是让那种把人固定在一个职能格子里的分工，开始显得越来越笨重。

未来更强的软件团队，也许不是人最多、岗位最全的团队，而是能用最少交接，最快完成从判断到反馈闭环的小队。

人会从螺丝钉里出来一点。

但出来以后，他面对的不是轻松，而是一个更完整的问题：现在目标卡在哪里，我能不能把它往前推一步。