文章目录前言一、马斯克懂的技术根本不是写代码二、帕金森定律每个 5 年以上的研发组织都会得的熵增病三、研发团队官僚化的 6 个早期信号自检清单1. 会议里讨论框架选型的人比写框架的人还多2. 制度化的流程开始替代工程师的判断力3. 人均 PR 数量持续下降超过 2 个迭代4. 技术 leader 的大部分时间花在协调而非决策5. 一个简单需求的改动牵涉 3 个以上的评审群6. 新人的产出贡献周期从2 周拉长到3 个月四、为什么控制技术精英是最贵的内耗五、高密度人才组织的几个真实案例Valve、DeepSeek、巴菲特1. Valve几百名工程师没有经理2. DeepSeek150 人做出能和 OpenAI 对标的大模型3. 巴菲特投资团队20 多人管几千亿美元资产4. 反观国内不少互联网公司的研发部门六、技术 leader 怎么把团队往高密度方向带1. 招人的时候宁缺毋滥2. 评估方式从工时切到产出3. 给核心工程师反官僚特权4. 定期反熵增审查5. 自己以身作则——少开会多写东西七、现实里的草台班子管理学的另一半真相1. 你需要先判断自己团队的真实水平2. 高密度是目标不是起点3. 警惕假高密度4. 钱学森之问本质是组织生态问题总结前言最近做技术招聘和带团队评审有一个反复出现的画面10 人的小研发团队把一个项目从 0 做到 1干得又快又稳。等公司开始扩张团队涨到 30 人、50 人、80 人结果同样的迭代速度反而慢了 3 倍——会议从一天 2 个涨到一天 8 个PR 评审从 1 天合掉变成卡 3 天需求从想法到上线的周期从 2 周拉到了 8 周。这不是工程师的问题也不是管理工具的问题。这是一个组织从高密度人才结构滑向草台班子结构的典型过程。最近翻到一篇知乎高赞回答《马斯克到底懂多少技术》作者把这个现象归到了反帕金森定律和高密度人才组织上——一句话戳穿了这两年大家对马斯克懂不懂代码的误解。读完这篇文章结合我自己十几年带技术团队的观察我想从一个研发管理者的角度把这套逻辑往程序员和技术 leader 视角展开聊聊为什么马斯克懂的技术不是写代码而是识别哪些程序员是真正有水平的帕金森定律为什么会摧毁绝大多数 5 年以上的研发组织一份研发团队官僚化的 6 个早期信号自检清单高密度人才组织的真实案例Valve、DeepSeek、巴菲特团队技术 leader 在自己 30 人以下的团队里具体怎么操作能避免组织熵增不管你是 1-3 年的工程师、5 年以上的技术骨干、还是带 10-50 人团队的技术 leader这套思考都用得上。开整。一、马斯克懂的技术根本不是写代码去年 DeepSeek 最火的时候梁文锋说过一句话“我们缺乏一种高密度人才的组织方式。”我当时反复在想什么叫高密度人才的组织方式后来想明白了——就是马斯克搞的几个公司的运作逻辑第一性原理简单直接没有任何为了管理而管理的人员。真正的科技精英是非常反感外行为了管理而管理的。一个技术团队只要混入了一两个纯行政导向的管理者就会不可避免地走向臃肿。很多人问马斯克一个 CEO又不写代码他到底懂多少技术我的看法和知乎那篇回答一致他懂的根本不是写代码而是识别哪些程序员是真正有水平的那种洞察力。他把推特买下来之后直接裁掉 80% 的人只保留 20% 必须的程序员后来又根据情况增聘了 5% 的程序员。这个操作的关键不是裁员本身而是他能判断出哪些人是必须的、哪些人是充数的。这就是我理解中马斯克懂的技术。他不一定比工程师更懂某段代码怎么写但他在几百个技术人员的组织里能快速过滤出谁是创造价值的核心节点、谁在拖后腿。这种能力比多写几万行代码对组织更有价值。二、帕金森定律每个 5 年以上的研发组织都会得的熵增病帕金森定律Parkinson’s Law是 20 世纪西方文化三大发现之一。它的核心描述很简单一个不称职的官员管理者有三条出路——退位让贤、找一个能干的人当助手、找两个更无能的人当助手。前两条都走不通退位丢权力找能干的人会变成自己的对手。于是所有人都选了第三条找两个更无能的人当助手。助手们又上行下效再给自己招两个更无能的副手。结果就是机构每层都在膨胀效率每层都在下降。这个定律在研发组织里比在传统企业管理里发作得更隐蔽但也更致命。原因是技术团队里能力差异的跨度极大。一个优秀的工程师可能顶 10 个甚至 50 个普通的。如果组织机制允许管理者持续选看起来听话但技术平庸的人进入团队3 年内就会形成一条平庸堆积链第 1 年核心骨干发现周围新招的人跟不上节奏第 2 年骨干开始承担越来越多帮别人改 Bug的额外工作第 3 年骨干要么被累垮、要么主动离开第 4 年团队里全是听话但不解决实际问题的人这个链条在互联网行业比传统行业更快——因为技术迭代速度快人才流动性大。 你不需要故意搞官僚主义只需要在招人时选安全但不优秀的人帕金森定律就会自动运转。反过来说马斯克裁掉推特 80% 的人之后系统没崩溃、业务没停摆——说明那 80% 的人大概率就是帕金森定律制造出来的冗余。裁掉冗余不是目的让剩下的人有空间真正做事才是。三、研发团队官僚化的 6 个早期信号自检清单原文分析了帕金森定律的发作逻辑但我想从一线技术管理者的角度给出更具体的东西——当你的组织正在变胖时早期有哪些信号我见过不少技术团队从 10 人扩张到 30 人后效率不但没提高反而下降了。复盘下来以下 6 个信号出现 3 个以上说明你的团队已经进入低密度化的通道1. 会议里讨论框架选型的人比写框架的人还多一个 10 人团队讨论技术选型30 分钟搞定。一个 30 人团队讨论技术选型可能开 3 场会还定不下来——因为参会者里有大量虽然不写代码但需要发表意见的人。2. 制度化的流程开始替代工程师的判断力“这个需求按要求排期就行不用问为什么这么做。”——当工程师开始不质疑需求的合理性只是机械执行时团队就从高密度组织变成了执行队列。3. 人均 PR 数量持续下降超过 2 个迭代这是个可以量化的指标。如果你发现团队过去 6 周的人均 PR 合入量剔除休假/新人入职环比下降超过 20%说明有人在无效忙碌——开会、写文档、走审批流程这些都不产出代码。4. 技术 leader 的大部分时间花在协调而非决策技术 leader 一周的工作场景80% 在协调不同小组之间的依赖关系15% 在写周报/汇报5% 在思考架构方向。这就是典型的帕金森症状——管理层在制造工作而不是解决问题。5. 一个简单需求的改动牵涉 3 个以上的评审群正常的研发组织中一个前端样式改动的 PR 应该只需要 1-2 个人 Review。如果你发现一个按钮换个颜色需要拉 5 个人进群、对齐 3 个小组、审批 2 轮——说明组织的复杂度已经超越了业务复杂度本身。6. 新人的产出贡献周期从2 周拉长到3 个月这是最隐蔽但最致命的一个信号。高密度的 10 人团队一个中等水平的应届生入职 2 周就能开始贡献有效代码。而一个开始官僚化的 30 人团队同样的新人可能 3 个月后还在熟悉业务——因为他的代码需要经过太多人的评审每层评审的人都会出于自保心态挑一堆无关紧要的问题。如果你发现团队出现了 3 个以上信号不要急着买新的项目管理工具也不要组织更大规模的团建。回到最底层的问题你的团队里有多少人在创造价值多少人只是被帕金森定律制造出来的四、为什么控制技术精英是最贵的内耗原文里有个观点很犀利“我们为什么要控制科技工作者我们为啥要向一个高密度的人才组织里掺沙子去降低效率”这句话戳到了不少国内技术团队的隐痛。很多公司在管理上有一种潜意识——“必须有人盯着工程师”。于是给一个 5 人的小组配 1 个项目经理、1 个产品经理、1 个 QA leader、1 个技术总监4 个管理岗位监督 5 个开发。结果不是管得更好而是每个开发的有效编码时间从一天 6 小时缩到 3 小时。这种控制的代价其实远比不控制高——真正有水平的工程师最反感被外行管理他们会用脚投票要么离开要么消极怠工留下来的工程师会演给管理者看写华丽的周报、做形式主义的复盘但代码本身的质量在下降组织对外部市场的反应速度变慢——因为每一个决策都要走 4 层审批更关键的是技术精英的稀缺性远高于管理者的稀缺性。知乎那篇回答里举了一些例子美国某公司给一个中国 AI 专家开年薪 1 亿美金马斯克的董事会给他 1 万亿美金的薪酬包虽然主要是期权很多人会批判美国是个人英雄主义。但在科技领域这种个人英雄主义是有数据支撑的——一个数学天才解决一个数学难题可能比 10 亿普通人加起来花几十年都管用。例子可回收火箭技术为什么直到最近几年才搞成因为里面最关键的数学问题之一直到 2013 年才被解决。在数学问题没解决之前你堆再多的工程师都没用。这套逻辑放到日常的研发团队同样适用一个真正能搞定核心算法的工程师比 10 个写 CRUD 的工程师对项目价值更大一个能在架构层面提前避坑的架构师比 5 个事后救火的中级工程师对系统稳定性更关键一个能识别并保留这种核心人才的技术 leader比一个忙着开会汇报的管理者对组织未来更有意义承认精英价值给精英相称的回报不是个人英雄主义是对组织效率的诚实。五、高密度人才组织的几个真实案例Valve、DeepSeek、巴菲特原文最后举了几个高密度人才组织的真实例子我把它们和我自己的观察对照展开。1. Valve几百名工程师没有经理Valve 公司是个非常特别的样本——代表作品包括《半条命》《反恐精英》《Dota 2》《求生之路》以及 Steam 平台。2025 年 Steam 日均新增付费用户达 10.9 万同时在线峰值突破 4000 万。而支撑这一切的内部组织是几百名顶尖工程师没有经理、没有主管、甚至没有汇报线这种东西。它的核心机制无层级结构所有人平等员工自己选择项目自我驱动文化你认为某个东西重要就直接去做内部人才市场项目缺人时自己去说服别人加入信息极致透明内部所有项目数据全员可见同行评价体系年度考核由同事互评不是上级打分失败容忍生态尝试失败的项目不会成为黑历史这种组织看起来乱但实际上对真正高水平的人才最友好——你不用花时间证明自己忙只需要证明自己有产出。2. DeepSeek150 人做出能和 OpenAI 对标的大模型梁文锋的 DeepSeek 团队只有 150 人搞出来 DeepSeek-V3、DeepSeek-R1 这一系列在国际上有竞争力的模型。同时还运营着幻方量化的核心策略。对比一下很多互联网大厂的 AI 部门动辄 500 人、1000 人但产出却跟不上。这不是 DeepSeek 的人比大厂的人更聪明而是150 人的组织里每个人都得真的产出没有冗余位置可以躺。3. 巴菲特投资团队20 多人管几千亿美元资产伯克希尔·哈撒韦的核心投资团队大概只有 20 多人但管理着几千亿美元的资产。这里的关键不是人少而是这 20 多个人都是能独立做出投资决策的人。每个人都不是螺丝钉每个人都是发动机。4. 反观国内不少互联网公司的研发部门我观察过国内一些大厂的中层架构一个普通业务线配 3-5 个项目经理、2-3 个产品经理、1-2 个技术总监实际写代码的工程师可能只有 15-20 人但部门总人数能达到 40-50 人这种结构在业务高速增长期还能掩盖问题一旦业务进入平稳期冗余结构就会成为首先被砍掉的对象。我说这些不是要鼓吹裁员是对的。我想说的是——与其等到业务出问题再被动裁员不如从一开始就把组织维持在高密度状态。六、技术 leader 怎么把团队往高密度方向带前面讲了帕金森定律是怎么发作的、高密度组织长什么样。但很多人会说道理我都懂可我自己只是个 10-30 人团队的技术 leader不是 CEO怎么操作我把自己的方法论总结成 5 条可执行原则。1. 招人的时候宁缺毋滥帕金森定律的起点是招了一个不合适的人。一旦招进来再想清出去成本极高HR 流程、人际关系、团队心理。具体准则招人时至少 3 个面试官达成共识任何一个明确反对就不要拒绝业务紧急、先招进来再说的妥协——紧急招进来的人2 年后大概率成为团队的负担候选人的上限比下限重要——一个有上升潜力的初级工程师比一个稳定但无潜力的中级工程师更值得招2. 评估方式从工时切到产出很多团队的评估方式还停留在谁加班多“谁会议多”这就在系统性鼓励冗余。具体操作周会从每个人讲讲做了什么改为每个人讲讲解决了什么问题KPI 中至少 50% 是可量化的产出PR 合入数、Bug 修复数、需求交付周期明确告诉团队会议、文档、汇报本身不产生价值只有真正交付的东西才算数3. 给核心工程师反官僚特权如果你的团队里有 1-2 个真正的技术骨干给他们拒绝无意义会议的权利——他们可以选择不参加大部分会议跨部门直接沟通的权利——不用什么事都走 leader 转交挑战决策的权利——他们说这个方向不对时你必须认真听这看起来像是给特殊人物特权但实际上是让组织里最有价值的人有空间继续创造价值。4. 定期反熵增审查每 6 个月做一次组织审查问自己几个问题上半年新增的会议有几个是真正必要的团队里有没有位置在但产出说不清的人决策链路有没有变长过去 1 周决定的事情是不是 3 个月前用 1 天就能定发现问题就果断处理取消会议、调整人员、压缩流程。不要等组织自己变好——熵增是单向的必须主动反熵增才能维持高效。5. 自己以身作则——少开会多写东西技术 leader 最容易掉进的陷阱是成天开会、不再写代码也不再深度思考。然后下属的工作方式会自动模仿你。具体做法每周至少留出 1-2 天无会议日自己也写代码或者深度复盘技术问题把我在思考 XX 架构作为日常对外输出而不是我在协调 XX 项目写技术博客、做内部分享——让团队看到你还在保持技术敏感度leader 自己保持高产出状态团队才会保持高密度状态。这是最隐蔽但最有效的反熵增手段。七、现实里的草台班子管理学的另一半真相前面讲了那么多高密度组织好但要承认一个事实现实里 90% 的组织根本不是高密度的——它们是草台班子。原文作者讲过一句话很到位“100% 的工地99% 的工厂和大多数企事业单位都是草台班子。”圈子里能看到的不少传统行业 IT 项目确实是这种状态——人员水平参差不齐岗位职责模糊质量标准不清晰。对草台班子来说管理是必须的。海尔创始人张瑞敏当年定的第一条管理制度是不准随地大小便。我看了之后没觉得是笑话反而觉得很真实——管理这件事得看你管的是什么人。对一个真正的高密度技术团队过度管理是诅咒对一个草台班子缺少管理是灾难。所以这套反帕金森的逻辑不能粗暴套用——1. 你需要先判断自己团队的真实水平团队里 80% 以上是技术骨干水平 → 适合高密度模式少管多放团队里 50% 左右是技术骨干剩下是中等及以下 → 混合模式给骨干自由给一般水平的人明确流程团队里大部分是初级、外包、跨行人员 →必须靠管理体系兜底否则交付质量不可控2. 高密度是目标不是起点如果你接手一个新团队发现现状是后两种正确的做法不是立刻搞无层级 Valve 模式那会立刻乱套。正确的做法是先用流程稳住质量基本盘通过淘汰 招聘逐步替换人员结构团队骨干浓度上来后再逐步取消多余的管理层级这个过程一般需要 1-2 年。3. 警惕假高密度有些团队对外宣称扁平化、无管理但实际上老板大权独揽所有决策都要拍板没有人敢挑战决策表面上自由实际上是恐惧文化下的伪自由这种比传统层级组织更糟糕——既没有层级带来的清晰责任也没有真正高密度团队的创新空间。4. 钱学森之问本质是组织生态问题著名的钱学森之问“为什么中国教育培养不出世界顶尖人才”我个人的看法人才本身一直都有但社会整体的组织生态没能给真正的人才提供宽松、自由、不被外行压制的环境。这是一个超出技术 leader 能影响的范围但作为技术管理者我们至少能在自己 30 人以下的团队里尽量做到这一点。这也算是对反帕金森理念最实际的实践。总结回到最开始那个问题——马斯克到底懂多少技术我的答案他可能不写代码甚至读代码都未必比一个高级工程师快。但他懂的是比写代码更稀缺的东西在几百个技术人员的组织里能识别真正有价值的那 20%并且敢于把剩下的 80% 砍掉。总结全文 5 个核心观点马斯克懂的技术本质是识别真正有水平的工程师并把他们放到合适位置上的洞察力——这种能力比写代码更稀缺。帕金森定律是研发组织最隐蔽的杀手——不需要任何人故意搞官僚主义只要在招人时持续选安全但平庸的人3-5 年内组织就会自动臃肿。研发团队官僚化有 6 个早期信号——会议堆叠、流程替代判断、人均 PR 下降、leader 时间被协调耗光、决策链路变长、新人产出周期拉长。出现 3 个以上就要警惕。承认精英价值不是个人英雄主义是对组织效率的诚实——一个核心工程师顶 10 个普通工程师是真实的给他们相称的回报和环境是高密度组织的基础。技术 leader 在 10-30 人团队层面至少能做 5 件事反熵增——招人宁缺毋滥、评估改成产出导向、给骨干反官僚特权、定期反熵增审查、leader 自己保持高产出状态。最后一句留给读者不是每个团队都能成为下一个 Valve、DeepSeek但每个技术 leader 都能让自己手里的 10-30 人团队比 5 年前的同等规模团队更密度、更有产出。如果这篇文章让你想起了自己团队里的某个画面欢迎评论区聊聊你觉得自己团队现在是高密度状态还是已经在向草台班子滑了