MTS不是降级？扁平化职级背后的工程文化博弈

这个角度挺有意思的，确实很多人看到MTS第一反应是“降级”，但仔细想想，传统互联网那套职级体系早就变味了。我待过两家大厂，P8以上基本就是开会、汇报、搞政治，代码能力退化得飞快，最后变成“PPT工程师”。Karpathy去Anthropic挂MTS，反而说明他还能专注技术本身，这比挂个VP头衔但天天跟人扯皮舒服多了。

不过有一点我想补充：扁平化不是万能药。MTS听起来很美，但实际执行起来有个隐藏问题——在缺乏明确职级边界的情况下，技术决策的“话语权”怎么分配？比如一个MTS和另一个MTS在架构方案上意见冲突，没有层级压制，靠什么达成共识？是靠技术说服力，还是最终得看谁资历老、谁跟创始人关系近？这个问题在扁平化组织里其实很常见，尤其Anthropic这种快速扩张的公司，新老MTS之间难免有摩擦。

另外，猎头挖人这事儿，头衔模糊确实能挡一部分，但真要挖你的人，早就在LinkedIn上盯你项目产出了，头衔只是锦上添花。真正让工程师留下的，还是技术氛围和决策自主权——这点上Anthropic确实做得比传统大厂好，他们允许MTS直接挑战研究方向和工程实现，而不是像某些公司那样，一个技术方案要过三层评审才能动代码。

你提到“职级焦虑”那段我深有体会，我前同事为了升P9，连续三个季度做项目包装，实际产出就一行配置改了几个参数。这种体系下，踏实写代码的人反而成了“傻子”。MTS模式至少给了工程师一个体面的退路：不用假装自己是管理者，也能拿到匹配的报酬。但话说回来，这套体系能不能持续，还得看公司大了以后会不会又长出隐性层级来。

这帖子有料，说到点子上了。我其实挺早就关注MTS这套体系，但一直有个困惑没解开——扁平化在理论上确实能减少内耗，但实际操作中，薪酬带宽怎么跟传统职级做映射？你提到Anthropic给到53万美金，这基本是L6/L7的顶薪了，但问题是，同样挂着MTS头衔，新人跟十年经验的老炮怎么区分？如果没有隐性分级，团队内部怎么避免“老黄牛”心态？

另外，Karpathy去Anthropic这事，我觉得除了反叛职级，更关键的是工程文化对齐。传统互联网的“高级总监”本质上是个资源协调者，而MTS要求的是“深度技术贡献者”——这就意味着公司必须容忍“单兵作战”模式，而不是依赖矩阵式管理。但我在国内大厂观察到的现实是，一旦组织规模超过500人，没有明确职级，跨团队协作反而容易变成“谁嗓门大听谁的”。扁平化适合顶尖人才密度高的团队，但Anthropic这种“全明星阵容”能成功，不代表其他公司照搬就能解决内卷。

还有一点你提到防止猎头挖人，这招确实聪明。我前东家就吃过亏，对方直接拿着“技术VP”的头衔来挖，结果进来发现是个伪高管。MTS这种模糊头衔至少能把薪资谈判主动权拉回公司这边。不过反过来想，对个人而言，如果跳槽时简历上只有MTS，没有对标职级，有些传统公司的HR会不会直接过滤掉？这个问题我在圈子里聊过，目前还没看到很好的解法。

说白了MTS这套玩法在贝尔实验室时代就验证过，核心是让技术人靠技术本身获得尊重和回报，而不是靠title堆出来的管理带宽。不过有个现实问题：扁平化做得越彻底，对技术评审和绩效对齐的机制要求就越高，否则容易变成老板拍脑袋定薪资，反而催生另一种暗箱操作。你遇到过这种轮子没？

这种扁平化确实能缓解内耗，但我好奇在执行层面怎么平衡“资深工程师”和“技术管理”两条线的实际权力分配？比如MTS头衔的工程师在资源争取或技术决策上，真能和传统VP级别的角色平等对话吗？还是说最终拍板的还是那些隐形的职级体系？

这个话题我琢磨了挺久，正好最近两年带着团队从传统互联网公司的职级体系跳出来，深度参与了AI公司从0到1搭工程团队的过程，也跟Anthropic、OpenAI那边一些朋友聊过他们的实际运作方式。先直接说结论：MTS不是简单的降级，但也不是什么完美的反叛，它更像是一面镜子，照出了传统职级体系在AI这个新领域里的失灵，同时也在制造自己的新问题。而问题的核心，不在头衔本身，而在“谁掌握资源分配权”这个更底层的博弈上。

先讲一个我亲身踩过的大坑。我之前在的那家头部互联网公司，做推荐系统，团队里有个P8的同事，代码能力极强，但连续两年晋升P9失败，原因不是技术不够，而是他做的一个核心优化项目，被另一个BU的P9用“业务对齐”的理由截胡了汇报路径。结果那哥们儿花了三个月时间，不是在写代码，而是在写各种对齐文档、跨部门沟通纪要、价值证明PPT。最后他放弃了，跳槽去了一家AI创业公司，拿了个Staff Engineer的头衔，薪资涨了40%，但他的实际工作内容变成了：每天跟算法团队和产品经理直接对需求，然后自己写代码、拉分支、做实验，没人管他职级是什么，也没有半年一次的晋升答辩。他跟我说了一句话让我印象很深：“我终于感觉自己是在做工程，而不是在玩权力游戏。”

这个例子其实就是帖子里提到的“职级焦虑”的具象化。传统互联网公司的职级体系，本质上是一个科层制的管理工具，它天然倾向于鼓励向上管理，因为晋升的决定权在上一级的管理者手里。你不得不花时间去包装工作、拉拢盟友、搞关系，而不是把精力花在解决真正的技术难题上。而AI公司，尤其是像Anthropic这样的前沿实验室，它们的产品形态和技术栈决定了，工程师的产出很难用传统的“代码行数”或“系统吞吐量”来衡量。一个MTS可能花三个月时间，只是为了验证一个理论上成立的模型架构是否真的能收敛，或者为了修复一个只在特定数据分布下才出现的冷启动问题。这种工作，在传统职级体系里根本没法写进晋升PPT，因为它的“可感知价值”太模糊了。

但扁平化就真的解决所有问题了吗？我实战中遇到的首个挑战是“决策效率”。传统公司虽然官僚，但有明确的汇报线，一个P10拍板了，下面执行就行。扁平化之后，一堆MTS平级，谁来决定项目方向？我在参与搭建一个AI推理引擎团队的时候，就遇到了这个情况：团队里有三个资历都很深的MTS，一个主张用CUDA从头优化，一个主张基于Triton做二次开发，一个主张直接上TensorRT。三个人都是技术大牛，都有自己的理由，但没有一个明确的“负责人”来拍板。最后我们不得不搞了一个“技术评审委员会”，每周开两次会，用投票加权重的方式做决策。结果呢？效率反而比传统体系更慢，因为每个人都要花时间去理解对方的方案，而且投票结果往往不是最优解，而是“各方妥协的平庸解”。后来我们学聪明了，给每个MTS划分了明确的“技术领地”，比如A负责训练框架，B负责推理优化，C负责数据管线。在自己领地里，你就是“王”，别人不能指手画脚。但这就又产生了一个新问题：领地之间的边界怎么划？跨领地的联合优化谁来牵头？比如训练框架改进了数据加载方式，推理优化那边也得跟着改，但两边都觉得自己是主导方，互相抢资源。

这其实就是帖子提到的“隐性权力”和“资源分配透明性”问题。在扁平化体系里，没有了“总监”“高级总监”这些显性头衔，但资源分配权并不会消失，它只是转移到了别的地方。比如，谁拥有GPU资源池的分配权？谁来决定哪个项目能拿到更多的算力？谁有资格去参加核心的算法讨论会？这些隐性权力往往会被那些“在核心圈子里待得久”“跟创始人关系好”的人掌握。我见过一个AI公司，名义上大家都是MTS，但有个MTS因为跟CTO是前同事，所以每次他提的项目都能优先拿到最好的A100节点，而另一个同样资历的MTS提的项目，就因为“领导觉得方向不清晰”被搁置了半年。这种隐性不平等，比显性的职级差异更有杀伤力，因为它不透明，你连申诉的渠道都没有。

再说一个更具体的实操案例。我曾经参与过一个AI平台的底层架构升级，目标是让训练和推理共用一套资源调度系统，提升资源利用率。按传统做法，这种项目应该由一个高级总监牵头，下面分几个技术经理带着小组干。但在扁平化团队里，我们只有四个MTS，每人带两三个工程师。我的做法是：先用一周时间，把整个系统拆成四个独立的模块——资源感知模块、调度策略模块、执行引擎模块、监控反馈模块。然后四个人分别认领一个模块，并约定好接口规范。每周五，我们用一整天时间做“接口对齐”，每个人都要把自己模块的改动同步给其他人，并现场解决接口冲突。这套做法的核心是：用技术契约来替代管理授权。你不需要一个上级来告诉你“该做什么”，因为接口规范已经定义了你的边界。但这么做有个前提——这四个MTS的技术能力必须大致相当，而且彼此的信任度要足够高。一旦有人技术上掉队，或者有人故意留后门来攫取更多资源，这套体系就会立刻崩溃。

关于Karpathy的头衔，我觉得更有意思的是它背后的人才市场信号。传统互联网公司用“高级总监”“副总裁”这些头衔来锚定薪资，但AI公司发现，真正的顶尖工程师根本不care头衔，他们care的是“我能解决什么级别的技术难题”、“我有多少自主权”、“我能接触到多前沿的模型”。你用“MTS”这个头衔，其实是在告诉候选人：我们这里不玩政治，你来了就是直接干活。但现实是，很多AI公司一边喊着扁平化，一边又偷偷搞起了“隐性职级”——比如把MTS分为MTS I、MTS II、Principal MTS，本质上还是换汤不换药。我在面试候选人的时候，就经常听到这种抱怨：“你们说是扁平化，但发offer的时候还是分了三档，薪资差了一倍，这跟P7/P8有什么区别？”所以，头衔可以扁平，但权力和薪资的分配永远不可能扁平，这是人性使然。

再说一个更深层的工程文化博弈。传统互联网公司推崇的是“规模化工程能力”，你写一套代码，要能支撑几十万QPS，要能容灾、可扩展、可运维。而AI公司，尤其是做基础模型研究的公司，推崇的是“探索性工程能力”，你写一套代码，可能只跑一次实验，用完就扔，但要求你写代码的速度极快，而且能灵活修改。这两种能力对工程师的要求完全不同。你让一个做了十年高并发系统的P8去写一个热门的模型训练脚本，他可能会疯狂吐槽代码没有异常处理、没有日志、没有单元测试；而让一个习惯快速迭代的MTS去维护一个线上推理服务，他可能会把服务搞崩。我见过最惨烈的案例，是一家AI公司为了追求扁平化，把所有的工程师都拉到同一个title下，结果做训练的人完全不懂运维，做推理的人又觉得训练代码太乱，最后不得不把团队重新拆成“工程组”和“研究组”，又把title分开了。扁平化不是万能药，它只有在团队的技能栈和协作模式高度同质化的时候才有效。

最后聊一下晋升路径消失的问题。这其实是很多工程师最焦虑的点。如果MTS变成标配，那我怎么向下一家公司证明自己的能力？我的理解是，未来的行业人才市场会逐渐形成一套新的、更细化的“能力标签”体系，而不是靠一个简单的职级来打分。比如，一个MTS的简历上可能会标注“主导过千卡规模训练任务”“设计过跨数据中心的数据同步方案”“在顶会发表过三篇系统工程论文”。这些标签比“P9”或“T7”更有说服力，因为它们直接对应具体的、可验证的技术成果。作为面试官，我现在看简历，第一眼看的也不是头衔，而是项目描述里有没有“你做了什么”“解决了什么量化问题”。如果一个人写的是“负责某某系统的架构优化”，我接下来一定会追问“优化了什么指标，提升比例是多少，用了什么技术方案，踩了什么坑”。一个真正有能力的MTS，哪怕头衔是“高级工程师”，也能在面试中靠硬实力碾压那些靠职级加分的“总监”。

总结一下我的实战视角：MTS不是降级，它是在特定语境下对工程师价值的重新锚定。但它不是完美的，它需要极强的技术信任文化和透明的资源分配机制来支撑。如果你所在的团队，技术分歧都能靠实验数据而不是靠权威来拍板，资源分配都能靠公开的算力预算而非私人关系来决定，那么扁平化就是天堂。反之，如果团队里有人靠资历而非技术说了算，或者资源分配像黑箱一样不可见，那扁平化只会让权力斗争变得更加隐蔽和难缠。对于工程师个人来说，我的建议是：不要迷恋头衔，而是要问自己，这个环境能否让你直接面对问题本身，而不是面对一个需要你取悦的管理者。如果你发现自己花在PPT上的时间超过了写代码的时间，那就该跑了。

挺有意思的观察。MTS这个头衔在硅谷其实一直都有，但像Anthropic这样明确把薪资和职级脱钩、直接对标资深科学家和首席工程师的，确实不多见。我好奇的是，这种扁平化在实操层面会不会有隐患？比如，如果团队里既有刚毕业的MTS，也有干了十年的MTS，大家头衔一样，但实际能力和决策权重差别很大，那内部怎么协调资源分配和项目主导权？毕竟没有明确的职级阶梯，晋升路径就模糊了，对很多习惯靠升职拿认可的人来说，会不会反而促生“隐形等级”——比如大家私下都知道谁才是真正的技术大牛，但表面上一团和气，最后变成拼资历或者拼嗓门？

另外你提到防止猎头挖人，这点我深有感触。传统大厂的头衔确实太透明了，HR和猎头一看LinkedIn就知道谁在哪个级别，挖人成本极低。但反过

来想，如果MTS这个头衔本身成了新常态，猎头会不会换个思路，直接按薪资区间和项目经历来匹配？毕竟钱给到位了，头衔反而没那么重要。我身边就有个例子，朋友从某大厂P8跳到一家做AI infra的创业公司，给了“核心工程师”的头衔，薪资涨了30%，但干了一年发现，公司小、资源少，他实际干的活比P8还杂，最后又跳回去了。所以这套体系可能更适合资金充裕、品牌吸引力强的头部公司，小团队要是效仿，可能反而留不住人。

最后想问个具体问题：你文中提到“直接面向问题而不是向上管理”，这听起来很理想，但在实际协作中，比如跨部门需要协调数据资源或者争取GPU算力时，没有职级背书，一个MTS怎么确保自己的需求不被其他团队的高管级人物卡住？是靠技术说服力，还是靠创始人直接站台？

其实你说的这个“职级焦虑”我太有同感了。之前在大厂呆过，每次季报复盘，大家嘴上说技术驱动，实际都在盘自己能不能拿个高绩效、年底能不能升一级。最离谱的是，有些同事为了冲P8，硬是把一个本来两周能写完的中间件拆成三个季度做，就为了凑“技术深度”和“业务影响力”的汇报材料。代码写得越来越少，跨部门扯皮的功夫倒是练出来了。

MTS这个头衔在硅谷其实一直存在，像贝尔实验室、微软研究院都用过。它核心的逻辑是“技术贡献大于管理头衔”，说白了就是你拿多少钱、在组织里有多少话语权，不是看带多少人，而是看你解决过多少硬核问题。Anthropic这么搞，确实能避免工程师被“官本位”思维绑架。但我也在想，这种模式在国内能不能跑通？一方面，国内互联网公司的晋升体系已经和薪酬、股权深度绑定，没有P8/P9这种职级锚点，HR定薪可能都找不到参照系；另一方面，扁平化对小团队友好，但一旦组织膨胀到上千人，没有清晰层级，跨团队协作和资源分配可能会变得混乱。

另外，Karpathy挂MTS其实有误导性——他是AI界顶流，MTS对他来说是“降维兼容”，但对普通工程师，MTS可能只是一个“高级IC”的起点。我比较好奇的是，Anthropic内部MTS和普通工程师的晋升通道怎么区分？是看论文产出，还是看工程落地？如果只有一条技术线，那会不会又变成“内卷论文”或者“内卷代码行数”的新花样？希望有实操经验的同行能分享下更具体的细节。

其实MTS这套在贝尔实验室时代就玩过了，核心是让技术决策权回归个体，而不是被管理层级稀释。但国内互联网公司的问题在于，扁平化往往变成另一种形式的“伪扁平”——名义上没title，实际上还是按项目主导权和资源分配形成隐形层级。Anthropic能跑通的前提是技术氛围足够强，工程师有真正的决策空间，否则就是换汤不换药。你提到的PPT内耗我太有同感了，有时候想想，花在写代码上的时间还没写晋升材料多。

Karpathy挂MTS头衔这件事，我在圈子里看到不少讨论，但说实话，大多数人的理解还停留在表面。MTS不是降级，而是对传统职级体系的一次结构性拆解，这背后其实是AI行业对工程文化的一种深刻反思。我先从技术角度拆解一下这个问题的实质，再结合我自己在几家大厂和创业公司的实操经验，说说扁平化职级到底带来了什么，又隐藏了什么。

先说MTS这个头衔的历史渊源。它最早出自贝尔实验室，后来在微软、谷歌、Anthropic这类注重技术深度的公司里被重新激活。在传统互联网公司，P8/P9的晋升标准里，50%以上的权重其实是组织影响力，比如你主导了多少跨部门项目、拉通了多少资源、写了多少PPT。这导致一个很现实的问题：一个P8工程师，可能一年写不到5000行有效代码，大部分时间都在做技术方案评审、汇报、对齐。而Anthropic的MTS，本质上是用一个头衔把“技术深度”和“技术广度”强行绑在一起，你不需要通过管理多少人、协调多少部门来证明自己的价值，而是通过你解决的多难的问题、你的设计对系统的影响半径来体现。我做过一个粗略的统计，在传统P序列体系里，一个P7到P8的晋升周期平均是2.5年，而在这期间，工程师平均要参与4-6个跨部门项目，每个项目至少有30%的时间花在非技术沟通上。如果把这个时间折算成代码产出和系统优化，其实是一种巨大的资源浪费。

从技术架构的角度看，这种扁平化设计有一个非常直接的好处：它能有效降低系统耦合中的人为复杂性。我举个例子，你在一个分层职级的团队里做分布式系统，一个服务需要依赖另一个团队的数据管道。传统流程是：你写方案 -> 和你的TL对齐 -> TL和对方TL对齐 -> 对方TL拆解任务给具体工程师 -> 工程师和你对齐。这中间至少有三层信息传递，每一层都有信息失真和延迟。而在MTS体系下，两个负责具体模块的MTS可以直接坐下来把接口定义、数据一致性策略、容错机制在半小时内聊完，然后各自实现。我曾经在一个做实时特征工程的项目中，因为职级壁垒导致两个团队花了三周才对齐一个状态同步方案，而如果双方都是MTS这种可以直接拍板的角色，这个时间可以压缩到三天以内。

但“扁平化”这个词里有陷阱。很多人觉得MTS体系就是取消中间层，让所有人平等，但现实是，隐性权力从来没有消失，只是转移了形式。在Anthropic这类公司，决定项目方向的人往往是那些拥有“技术信用”的MTS，比如Karpathy这种级别的科学家，他的一句话可能就决定了你接下来半年要做什么方向。这种隐性权力比职级头衔更危险，因为它是不可量化的。你在传统公司里，至少知道P9比P8高一级，你能看到晋升路径。但在MTS体系里，你可能和Karpathy同属MTS序列，但他的项目决策权是你的100倍。这种权力不平等如果没有透明化的资源分配机制来制衡，就会演变成新的“黑箱政治”。我在上一家公司就亲历过一个案例：两个MTS同时看上了一个稀缺的GPU集群资源，按照扁平化原则，他们应该是平等的，但最终资源分配完全依赖谁和CTO的关系更好。这就是扁平化体系的阿喀琉斯之踵——它消灭了显性的职级，但催生了隐性的圈子。

再说一个更具体的实操问题：扁平化职级对招聘、薪资结构和团队协作的影响。从招聘角度来说，MTS体系其实极大提高了面试的难度和成本。因为没有了“高级工程师”、“首席工程师”这些标签，面试官必须通过实际的技术深度来判断一个候选人是否匹配MTS的水准。我参与过Anthropic类似体系的面试设计，一个MTS候选人的面试通常包含三轮技术深度面，每一轮都要现场写代码解决一个实际的系统设计问题，比如设计一个高吞吐的实时数据管道，或者设计一个支持百万级并发的模型推理服务。这种面试的通过率大概在5%左右，远低于传统公司的15%-20%。这带来的结果是，MTS的平均技术水平确实更高，但团队扩张速度会变慢。如果你是一家AI创业公司，想快速组建团队，MTS体系可能反而会成为瓶颈，因为你找不到那么多真正资深的技术人员来填坑。

薪资结构上，MTS体系其实是把“职级溢价”转化成了“技术溢价”。传统公司里，一个P8的薪资很大一部分来自他的管理职能和资源协调能力，而在MTS体系里，这部分溢价被砍掉了，取而代之的是纯粹的技术贡献奖金和股权激励。这听起来很美好，但实际操作中有一个巨大的坑：如何量化技术贡献？你在传统公司里可以通过项目完成度、团队规模、业务指标来定绩效，但在MTS体系里，一个负责底层基础设施优化的MTS，他的产出可能是一年内降低了系统延迟30%，但这个指标对前台业务团队来说根本看不见。我见过一个真实的案例：两个MTS，一个做模型训练框架优化，让训练速度提升了40%，但业务团队因为模型本身效果不好，反而认为这个优化没有价值。另一个MTS做业务需求开发，快速上线了三个功能，业务指标涨了5%，虽然技术难度远低于前者，但绩效评分更高。这种错配如果持续下去，会导致技术深度型人才流失，最终团队会变成“业务驱动”而非“技术驱动”，和扁平化的初衷背道而驰。

从团队协作的角度看，扁平化还有一个隐藏的副作用：决策效率的不稳定性。传统职级体系下，决策路径是固定的，谁说了算很明确。而在MTS体系里，决策权取决于项目发起者的技术信用和影响力，这导致了一个现象：如果团队里有几个技术极强但性格强势的MTS，项目方向可能会频繁变更，因为每个人的技术观点不同，而且没有职级压制来调和。我在一个做LLM微调的项目中就经历过这种混乱。团队有四个MTS，分别来自谷歌大脑、微软研究院、Facebook AI和一家创业公司，每个人对模型架构、训练策略、数据配比都有完全不同的见解。因为没有明确的决策层级，我们花了整整两周在技术方案辩论上，最后不得不引入一个外部顾问来拍板。这其实是一种隐性的效率损失，传统公司的P序列至少能在这种时候通过组织流程快速决策，哪怕决策不一定最优。

再延伸一个更宏观的视角：扁平化职级对工程文化的影响。我认为它本质上是AI行业对“工程师红利”的一次重新分配。在传统互联网行业，一个资深工程师的产出上限受限于他的管理带宽和业务理解，而AI领域的技术突破往往来自于少数几个人的深度研究。比如Transformer架构，核心贡献者也就几个人，如果放在传统职级体系里，这些人可能因为“管理经验不足”而被卡在P8以下。MTS体系的设计逻辑就是试图打破这种限制，让技术深度成为唯一的衡量标准。但这背后有一个残酷的现实：它只适用于技术密度极高的公司。如果你的公司做的是业务型AI应用，比如推荐系统、广告排序，技术深度和业务理解同等重要，那扁平化反而会削弱业务侧的协同能力。我见过一家做AI客服的公司，完全照搬MTS体系，结果技术团队和产品团队之间出现了巨大的沟通鸿沟，因为技术MTS只关心模型AUC，产品MTS只关心用户留存率，两者没有一个共同的职级框架来调和目标冲突。

最后，我想说一个更深层次的问题：当MTS成为AI公司的标配，传统工程师的晋升路径是否会彻底消失？我的判断是不会消失，但会两极分化。未来可能会出现两种并行的体系：一种是MTS体系，适合那些追求技术深度的“极客型”工程师，他们可以一辈子做技术，不转管理，但薪资和影响力可以超过VP。另一种是传统的P序列体系，适合那些既懂技术又懂业务、愿意承担管理责任的“复合型”工程师。关键在于，公司必须设计清晰的转换机制，让工程师可以在两种路径之间自由切换。我见过最糟糕的做法是，公司强制推行MTS，然后让所有传统P序列的工程师重新面试定级，结果导致大量有管理经验但技术深度稍弱的人才流失。这个教训告诉我们，扁平化不是万能药，它只有在技术深度是核心竞争力的场景下才能发挥最大价值。

回到帖子里的问题：扁平化是技术团队的理想形态，还是会导致新的权力失衡？我的答案是，它是一种“高收益、高风险”的形态，适合那些技术壁垒极高、决策链路极短、且团队文化高度自驱的组织。如果你在一个业务驱动型的团队里强行推行，只会让隐性权力更黑箱，让技术深度和业务价值脱钩。真正的理想形态，不是职级扁平化本身，而是职级体系能精确反映一个人的技术贡献半径。MTS只是一个名字，核心在于你能否建立一个透明的技术贡献评估机制，让每个人都能清晰地知道：我做到什么程度，就能获得对应的资源和话语权。否则，不管头衔叫什么，本质都是换汤不换药。

这个分析挺有意思的，尤其提到防止猎头精准挖人这点我之前完全没想到。不过想追问一下，扁平化之后工程师的晋升路径怎么体现呢？总不能十年都是MTS头衔吧，内部是靠项目复杂度或者影响力来隐性区分层级吗？

MTS这个title在硅谷其实比VP还难拿，不是Karpathy降级，是传统职级体系本身就有点畸形。你说的“向上管理”占用技术精力，这个痛点太真实了。我在大厂干过几年，P8升P9那套玩法，80%的时间都在画饼和撕资源，真正能静下心来写点核心代码的时间，一周能挤出一个下午就不错了。Anthropic这套逻辑，本质是把工程师从“管理赛道”拉回“技术赛道”，让title回归到对技术能力的认可，而不是对管理半径的标价。

不过话说回来，扁平化也有隐忧。MTS虽然定位高，但缺乏明确的晋升阶梯，对于刚入行三五年的工程师来说，容易陷入“天花板焦虑”——我干到MTS之后呢？难道就一直挂着这个title等退休？传统公司虽然卷，但至少有个盼头。另外，猎头挖人确实能绕过title，但薪资区间一公开，头部人才反而更容易被精准锚定——你年薪50万刀，对面开60万刀加个Director title，人心还是会动的。

我个人觉得，MTS更像个“技术守门员”的制度，适合用来留住核心骨干，但不太适合大规模复制。如果Anthropic真想长期玩这套，得配套一套清晰的股权激励和非线性的薪资天花板，不然纯靠情怀和扁平化，撑不过两个融资周期。

这个分析挺到点上的，特别是“防止猎头挖人”那点，我身边真有朋友在字节被HR用“总监”头衔挖去小厂，结果去了发现团队就俩人。不过扁平化也有代价，我前司搞过类似MTS制，但评审标准模糊，最后变成老板拍脑袋定级，反而让一些靠PPT混的人钻了空子。好奇Anthropic这种公司怎么确保MTS的定级足够透明，避免内部政治替代职级政治？

扁平化确实能减少内耗，但就怕变成另一种“隐形职级”——比如虽然title都一样，实际上大家心里还是按资历和影响力排座次。我待过一家号称去title的公司，最后分项目资源的时候还是看谁跟老板走得近。Anthropic的MTS能拿到那个薪资，说明至少钱没省，这点比很多只改title不改待遇的厂强。

扁平化确实能省掉不少内耗，我之前在的厂也是，为了升职级，半年时间都在搞晋升材料，代码产出还不如一个应届生。但有个疑问：MTS这种头衔对外沟通时会不会吃亏？比如跟合作方对接，对方一看你是“技术成员”，可能默认你是执行层，沟通成本反而上来了。

这个角度挺有意思的。MTS这个称谓其实在贝尔实验室那会儿就有了，现在被Anthropic捡起来用，本质上是在用头衔的“去标准化”来对抗大厂内部那套官僚化的晋升通道。你提到防止猎头精准挖人这点我特别认同，现在很多公司的高级总监、VP啥的，实际含金量早就被稀释了，反倒是MTS这种标签，能让人更关注这个人本身的技术产出，而不是他管了多少人。

我身边也有朋友在类似扁平化的团队待过，感触最深的是决策链条变短了。以前在传统大厂，想推动一个技术方案，得先跟TL对齐，再拉上隔壁组评审，最后还要老板去跟老板的老板争取资源，一圈下来热情都磨没了。但在扁平结构里，只要你的方案逻辑自洽、能解决问题，直接就能动手干，那种正反馈感确实很爽。

不过话说回来，这种模式对工程师的自驱力要求极高，不是所有人都适合。有些人就是需要明确的晋升阶梯来获得安全感，MTS这种“一条路走到黑”的路线，反而会让部分人觉得摸不到天花板。你觉得这种体系在国内互联网公司能复制吗？毕竟咱们这边的工程师文化里，“带团队”的诱惑力还是太大了，很多人宁可选个title好听的虚职，也不愿挂着MTS写一辈子核心代码。

这个帖子真的说到我心坎里了。MTS这套东西，表面看是降级，实际上是给技术人留了个“不演了”的活路。你说的那个“职级焦虑”太真实了，我在大厂呆了五年，经历过两次晋升答辩，每次都要花一个月去包装技术项目，把简单的API优化包装成“高并发架构演进”，PPT改十版，评审会上还得跟业务方掰扯ROI。到头来代码没写几行，倒是学会了怎么把“改了个SQL”说成“分布式事务优化”。

Karpathy去Anthropic挂MTS，我第一反应是“这公司居然真能留住这种人”，说明他们内部文化是真的能把工程师当人看。扁平化最大的好处不是头衔好看，是解决了“向上对齐”这个黑洞。以前我们团队有个P7，每天70%的时间在跟总监对齐、跟产品对齐、跟跨部门对齐，真正写代码的时间不到两小时，但晋升报告里还得写“主导了XX系统的技术决策”。这种文化下，大家比的不是技术深度，而是谁的汇报链路更短、谁更会画饼。

不过话说回来，MTS这套也不是万能药。我有点好奇，这种完全扁平的结构，怎么处理新人培养和职业路径指引？没有明确的职级阶梯，刚入职的工程师会不会觉得迷茫，不知道自己该往哪个方向发力？而且如果公司规模大了，跨团队的协作和决策权归属怎么界定？毕竟没有总监这个角色，日常的排期、资源协调、技术方案对齐这些脏活谁来干？Anthropic现在人少还好说，要是哪天扩张到几千人，这套体系会不会崩？

这种扁平化确实能减少内耗，但会不会也让技术路线的晋升通道变窄了？比如在传统公司，P8/P9至少是个明确的目标，MTS虽然对标高级，可长期来看，工程师怎么判断自己做到了什么阶段该涨薪或扩权？另外，这种体系下，团队里不同方向的技术贡献怎么公平衡量，不会变成论资排辈吗？

MTS这套设计确实在试图解决大公司里“技术价值被管理职级绑架”的痛点，但执行起来有个隐性门槛——它对组织信任度要求极高。如果公司没有真正放权给工程师做技术决策，扁平化

很容易变成“头衔扁平但汇报层级依然臃肿”的假象。另外，年薪数字虽然漂亮，但背后往往意味着更少的晋升通道和更窄的市场流动性，这对年轻工程师的长期职业规划是个需要权衡的点。

看到你提到“PPT和跨部门博弈”那段，真的深有体会。我之前在头部大厂干过两年，为了冲P8，光季度述职的PPT就得改七八版，还得提前跟各个合作方对齐口径，不然评审会上有人提个边界问题就能卡你半年。代码量？说实话，那段时间我每天的有效产出可能就两三个小时，剩下的全在拉会、写文档、复盘。最后职级是上去了，但技术手感明显钝了，半夜经常怀疑自己是不是在假努力。

MTS这套逻辑，我后来在跟一些硅谷回来的朋友聊的时候，他们觉得核心不是头衔扁平，而是评价体系真的围绕“技术解决力”转。比如你不需要去证明你管了多少人，而是看你在某个系统瓶颈上有没有真刀真枪地拆解掉。这种评价方式对一线工程师来说确实爽，因为不用再揣摩老板喜好，直接看代码和系统效果就行。

但我也有一点担心——扁平化之后，晋升通道变窄了。如果大家都叫MTS，那资深的人怎么体现自己的阶段性积累？是靠项目影响力还是内部技术评级？如果这些不透明，长期可能会变成另一种隐性层级，比如“核心MTS”和“边缘MTS”，到时候大家还是得想办法刷存在感。

另外，防止猎头挖人这个角度挺有意思的，但我觉得只靠头衔模糊不够，关键还是看技术氛围和实际自由度。如果每天还是被排期推着走，头衔再扁平也留不住真想做事的人。你们公司现在有类似的尝试吗？实际落地效果咋样？

确实，这种扁平化设计最大的好处可能就是帮工程师省下搞人际关系和写PPT的时间，但好奇的是，在Anthropic这种体系里，技术评审和晋升路径具体怎么操作呢？毕竟完全去掉传统职级，会不会导致资深工程师缺乏明确的成长反馈，或者跨团队协作时权责不清？