最近我把 Boris Cherny 那场关于工程师成长的访谈翻来覆去看了好几遍越想越觉得它被低估了。网上铺天盖地都是“Claude Code 怎么安装”“怎么接入 DeepSeek”“Windows 上怎么配”真正值得反复琢磨的反而是 Boris 作为 Claude Code 的核心缔造者对中级工程师到 Principal 这条路的理解。Claude Code 只是他的作品他脑子里的那套关于“人如何成长”的方法论才是这场访谈里最值钱的东西。如果你正处在一个“代码写得还算顺手但说不清下一步该往哪走”的阶段或者你已经带了小团队、开始操心跨团队协作这篇内容应该能帮你把成长路径重新捋一遍。我会把访谈里的关键观点拆开结合我自己做技术带团队踩过的坑讲清楚中级工程师和 Principal 之间到底差在哪以及 AI 编程工具在其中扮演了什么角色。1. 这场访谈到底讲了什么Claude Code 之父的背景与核心主张1.1 Boris Cherny 是谁从编译器到 AI 编程助手很多人知道 Boris Cherny是因为他主导了 Claude Code 这个项目。但如果你往前翻他的经历会发现他根本不是那种“只会调 API 的工程师”。他做过编程语言、编译器、类型系统相关的工作写过关于 TypeScript 的书对“工具如何改变程序员思维”这件事有非常深的体感。这也解释了为什么 Claude Code 不是简单套壳的 AI 插件——它对代码库的理解、对多文件修改的组织方式明显带着做编译器的人才有的那种“系统感”。访谈里 Boris 聊到过一个细节他在做 Claude Code 之前反复观察工程师每天的工作流发现大量时间其实消耗在“上下文切换”上——从一个文件跳到另一个文件从 IDE 切到终端从读代码切到查文档。传统工具只是在帮你更快地完成切换而 AI 编程助手的价值应该是让你尽量少切换。这个观察不是产品经理式的“用户痛点”而是工程师视角的“系统瓶颈”。理解这个背景很重要。因为后面他聊到的所有关于成长的观点都建立在他自己就是从底层一步步做到 Principal 的亲身体验上。他不是在讲理论他是在讲自己怎么想问题、怎么做决策。1.2 访谈里最能打的一个观点工具升级不是让你变快而是让你变大访谈中有个观点我印象特别深很多人以为用了好的工具自己的价值就变大了因为输出变多了。但 Boris 的视角恰恰相反——工具升级带来的不是单纯的“速度提升”而是你处理问题“粒度”的变化。普通工程师用 AI 写代码可能只是把需求拆成小函数让 AI 帮忙补完。但 Principal 级别的工程师用 AI思考的是“这个系统里哪些部分可以被抽象掉”“哪些重复劳动可以从根本上消除”“整个团队的工作流应该怎么设计”。同一个工具不同职级的人使用方式完全不同。你从“让 AI 帮我写代码”切换到“让 AI 帮我重构整个模块的边界”本身就意味着你的思维层级上移了。这个观点我特别认同。我最近用 Claude Code 帮团队做一次服务拆分一开始我只是让它帮我写迁移脚本后来我试着让它先读完整目录结构、理解模块耦合关系再生成一份拆分建议。它给我的不是一个脚本而是一整套带风险点和回滚方案的行动计划。那一刻我突然意识到AI 工具不是替我做执行而是逼我把问题定义得更清楚。这种“定义问题的能力”才是从中级往上走的真正分水岭。2. 中级工程师和 Principal 之间差的不是代码量而是“问题选择权”2.1 中级工程师的典型能力边界执行好、范围小、反馈快先别急着对标 Principal我们先把“中级工程师”这个阶段看清楚。一个标准的中级工程师通常具备这样几个特征你给一个明确的需求他能拆成任务并按时交付代码质量基本稳定会写单测会做 code review遇到问题能自己查资料解决不需要事事问人。这些都是非常好的基本功但它们的共同点是——工作范围被预先划定问题已经被别人定义好了。中级工程师的困境也在这里你越擅长执行别人就越会把“已经定义好的问题”交给你你反而没机会接触那些模糊的、需要你自己去定义的问题。久而久之你会变成团队里的“高效执行器”而不是“问题解决者”。这不是能力问题是选择权问题。你手里没有选择“做什么”的权利你只有“怎么做”的权利。我见过太多在这个阶段卡住的人。他们以为往上升需要学更多框架、看更多源码、刷更多 LeetCode但真正让他们停在原地的是——他们从来没有主动去接过一个“没人知道该怎么定义”的活。2.2 Principal 的核心能力定义问题、消除不确定性、跨团队放大Principal 级别的工作状态和中级工程师几乎是反过来的。它不再以“代码量”或“交付速度”为衡量标准而是看你能否在模糊地带里把问题定义清楚让一群人围绕同一个目标有序推进。具体拆开Principal 的核心能力大概有三块定义问题面对一个业务诉求你能分辨出哪些是表面需求哪些是根本问题你能把一个模糊的“我们要提高系统稳定性”转化成“我们要把 P99 延迟控制在 200ms 以内并且给出可观测的监控指标”。消除不确定性当一个技术方案存在多个未知因素时你设计实验、验证假设、快速获取信息把团队从“可能不行”带到“确定能行”。跨团队放大你不再只对自己负责的模块负责而是理解上下游团队的约束建立一个大家都能接受的协作方式让团队整体效能提升而不是局部最优。这三件事每一件都不直接“写代码”但它们对组织的价值远超过任何一段代码。访谈里 Boris 有句话说得很好Principal 不是团队里最会写代码的人而是最会“让代码变得不必要”的人。这句话乍一听反直觉仔细想非常有道理——真正的高级工程师会把精力放在消除重复劳动、简化系统复杂度上让后续的代码变得简单甚至多余。2.3 一张表看懂三个职级的能力权重变化为了让大家更直观地理解我列了一张能力权重表。这张表不是绝对标准但在多数技术组织里都适用。能力维度中级工程师高级工程师Principal 工程师代码实现核心产出重要产出偶尔产出主要用于验证方向问题定义依赖别人定义能定义模块内问题能定义系统性问题不确定性管理尽量避免能在局部分解能主导探索并收敛跨团队影响力几乎没有有一定协作能力核心杠杆技术视野当前技术栈相邻技术栈行业级技术趋势人才培养自己成长指导初级培养整个梯队这张表最扎眼的变化就是“代码实现”从核心产出降为“偶尔验证方向”。很多人接受不了觉得 Principal 不写代码凭什么服众。但 Boris 在访谈里点了一个关键Principal 不是不写代码而是写代码的目的变了。他写的代码通常是用来验证一个架构假设、搭建一个脚手架、或者做一个能让大家共同讨论的 demo。他的产出是决策、方向、标准和人才而不是功能点。3. 从访谈中拆出来的成长路径五个可以落地的转变3.1 从“完成需求”到“质疑需求”这是中级工程师往上走的第一步也是最难的一步。因为“质疑需求”容易变成“抬杠”关键不是否定需求而是挖掘需求背后的真实目标。我自己的做法是接到需求后先问三个问题这个需求解决的是谁的什么问题衡量成功的指标是什么如果什么都不做会怎样这三个问题一问很多需求会自动原形毕露——有的根本不需要做有的只需要做 20% 就能达到 80% 效果有的其实是另一个问题的错误解法。Boris 在访谈里也提过类似观点Principal 最常做的事是“消除需求”而不是“实现需求”。这不是偷懒而是把团队精力从低价值工作里解放出来。你敢不敢在周会上说“这个需求我们不应该做”比你能不能把这个需求做出来更能决定你的天花板。3.2 从“写代码”到“设计系统”中级工程师写代码时默认系统框架已经存在他是在框架里填内容。到了更高一层你需要开始思考框架本身是否合理模块该不该拆分数据流该不该重新设计。这里我推荐一个实操方法每次写完一个功能后退后一步看整个系统的调用链问自己“如果我现在重新设计这个模块我会怎么设计”不需要真的重写只需要在文档里画出新方案对比差异。这个习惯能慢慢训练你从局部思维切换到系统思维。Boris 做 Claude Code 的时候其实也在做大量的系统设计。他聊到过Claude Code 之所以能处理复杂任务不是靠模型单点能力强而是靠整个 agent 的循环设计读文件、改文件、运行命令、观察结果、再调整。这个循环本身就是一套系统设计而不是一个提示词技巧。你可以从这个比喻里理解“写代码”和“设计系统”的差别。3.3 从“个人贡献”到“杠杆化他人”中级工程师的成就感往往来自“我搞定了这个难题”。但一个人能解决的问题数量是有限的想要影响更大的范围你必须学会让别人也能搞定。“杠杆化他人”不是叫你去做管理而是指你写的代码、你写的文档、你设计的流程能不能让团队里最不熟悉的人也能高效工作。比如我自己会刻意给重构写迁移指南给复杂模块画架构图给新人设计 onboarding 任务。这些工作在短期看会拖慢我的交付进度但长期看是在给团队装增长引擎。Boris 在访谈里也提到一个词叫“让阅读你代码的人变强”。如果你只是写出来自己能看懂、别人只能膜拜的代码那是炫技如果你写出来别人能接手并能继续演进的代码那是领导力。Principal 的影响力不来自职位来自别人因为你的存在而变得更有效率。3.4 从“技术选型”到“技术布道”中级工程师做技术选型通常只关心“这个框架好不好用”。到了 Principal 级别你需要关心“这个框架对整个团队未来三年的影响是什么”以及“怎么说服团队接受这个选择”。技术选型本质上是风险决策。你选一个冷门但优雅的方案可能让团队难招人选一个热门但笨重的方案可能让系统日后难演进。Boris 做 Claude Code 时也面临过类似的抉择他选择了非常克制地暴露接口优先保证安全性和可操控性而不是一味追求“全自动”。这种取舍背后是对用户能力和风险边界的深刻判断。想培养这种能力我建议你每个月做一个“技术雷达”练习列出当前团队在用的主要技术给每一项打分标出“值得坚持”“值得关注”“需要替换”然后尝试写一份简短的推荐报告。不用发给别人先给自己看逼自己形成观点。3.5 从“面对现状”到“创造未来”中级工程师的工作对象是“现状”这个 bug 怎么修这个需求怎么实现这个性能怎么优化。Principal 的工作对象是“未来”我们六个月后要支撑什么样的业务现在应该做什么铺垫行业里出现的新技术哪些值得我们提前研究。这不是让你去搞那种两三年都落不了地的“前沿研究”而是让你养成“向前看”的决策习惯。每次做方案时多问一句这个方案是否给未来留下了演进空间如果业务量增长十倍它还能不能扛住如果团队扩张一倍它会不会变成瓶颈Boris 做编程语言的经历对他做 Claude Code 帮助很大因为他见过太多系统由于早期设计缺陷在后期付出惨痛代价。他反复强调“第一版就要考虑可演进性”不是要求你把所有事都做成通用平台而是要求你在做关键决策时把时间维度拉长。这一点恰恰是中级工程师最欠缺的视野。4. AI 编程工具Claude Code对成长曲线的影响4.1 为什么 Boris 会去做 Claude Code他看到了什么痛点很多人以为 Claude Code 是顺着大模型热度做出来的产品但 Boris 在访谈里给出了一个更真实的原因他发现 AI 聊天界面根本不适合写代码。聊天里你可以问答案但你没法让 AI 持续跟一个代码库协作没法让它自己跑测试、自己看报错、自己改下一个文件。代码开发是“长任务循环”而不是“一问一答”。这个痛点的本质是工具形态和工程师工作流不匹配。Boris 想做的是一个能真正嵌入开发流程的 agent而不是另一个 AI 对话框。他观察到的现象是工程师真正的高价值时间应该花在定义问题、设计方案、审视结果上而不是花在让 AI 理解上下文上。说实话我第一次接触 Claude Code 时的感受很复杂。一方面确实惊艳它能自己改文件、跑命令、根据报错迭代另一方面我也会警惕怕自己依赖太久失去底层能力。但 Boris 给出了一个很好的角度工具会替你做执行层的事但判断层永远是你的责任。这就把“AI 会不会取代程序员”的问题变成了“你愿不愿意承担判断责任”的问题。4.2 AI 辅助编程如何改变中级工程师的工作方式如果你现在是一个中级工程师AI 工具给你带来的最直接变化是你完成“实现需求”的时间大幅缩短。过去要写两天的样板代码现在可能一个小时就搞定了。省下来的时间去哪了很多人会去接更多需求但这恰恰是陷阱。正确的做法是把省下来的时间投入到“高级工作”上——做重构、做设计、做技术方案评审、做知识沉淀。Boris 认为 AI 真正改变的不是工程师的产出速度而是工程师可投入思考的时间比例。过去你 80% 时间在写代码20% 时间在想为什么现在可以反过来80% 时间想清楚20% 时间让 AI 把想法变成代码。我自己是这么用的上手一个新模块之前先用 Claude Code 把代码结构、数据流、关键逻辑梳理成一份摘要然后我自己读这份摘要花时间想“如果我来设计我会改动哪些边界”。这个流程让我从“实现者”逐渐变成了“设计者”。工具本身没有变变的是你愿意把精力放在哪个层级。4.3 使用 AI 工具时的判断力训练这是 Principal 的必修课AI 工具越强大对使用者的判断力要求越高。因为 AI 会一本正经地生成错误方案而且错误往往藏得很深。中级工程师看到 AI 给出的代码能跑就放心了但 Principal 级别的人会先问这个方案是不是最合理的它有没有忽略边界情况它是否符合我们现有的架构约束这其实是一种极好的训练机会。你每天面对 AI 的输出都可以问自己“如果这是我同事写的代码我会怎么 review”把你 mental review 的结论和 AI 的最终代码对比时间长了你的代码评审能力会飞速提升。Boris 在访谈里也有类似观点你越依赖 AI越需要有清晰的“接受或拒绝”的标准。这个标准不是来自 AI而是来自你对系统、对业务、对工程质量的理解。换句话说AI 是放大器放大的是你自己已有的判断力。如果你本身判断力一般AI 只会让你更快地产出平庸结果如果你的判断力够强AI 会让你更快地产出高质量决策。5. 访谈背后没有明说的事踩过的坑与常见认知误区5.1 误区一以为 Principal 只是更高一级的高级工程师很多技术团队把职级做成了一条线性阶梯初级、中级、高级、资深、Principal好像每往上走一步只是“工作量更大、技术更难”。但 Boris 访谈里隐含了一个非线性转变从高级到 Principal不只是难度提升而是工作性质发生了变化——从“解决已知问题”到“定义未知问题”。线性思维会害了你。如果你在高工阶段依然只盯着“谁的技术难我就去攻克谁”你会成为团队里最强的“攻坚手”但不会成为 Principal。因为攻坚手解决的是别人定义好的难题而 Principal 要决定“这个难题是否值得解”。这两者的价值差一个数量级。5.2 误区二以为影响力等于管理别人有人觉得想往上走就得带团队、管人。这是个更大的误解。Principal 可以是一个纯技术角色也可以带少量人但它的核心影响力不是来自“管”而是来自“让人愿意跟随你的技术判断”。我见过最厉害的 Principal手里一个 direct report 都没有但整个架构组、后端组甚至产品经理都愿意听他的意见。因为大家在面对复杂决策时知道找他聊一次比自己看一周文档有效。这种影响力比任何管理职位都稳固。Boris 自己也没有强调“管理”这件事他更多在讲设计决策、工具哲学、如何让 agent 和工程师协作——这些东西天然有跨团队属性。5.3 误区三以为 AI 会取代工程师所以不用学底层这是我在评论区经常看到的一种极端论调AI 都能写代码了我干嘛还要学编译原理、学操作系统、学网络协议Boris 的经历恰恰是对这种论调最好的反驳——他能做出 Claude Code正是因为他懂底层。他对代码库结构、对工具链、对工程师心智模型的理解决定了他能把 AI 能力封装成真正好用的产品。对你个人来说比“学不学底层”更重要的问题是“你愿不愿意理解系统”。AI 能帮你写代码但帮不了你理解一个分布式系统的数据一致性边界AI 能帮你写测试但帮不了你判断一个产品功能到底该不该上线。这些理解和判断来自长期的底层积累而不是临时问 AI。5.4 实操体会用 Claude Code 辅助做设计文档和代码评审我从访谈里学到最有价值的一个技巧是用 AI 工具做“设计文档的对抗性评审”。以前我写完技术方案都会找关系好的同事帮忙看但说实话很多人碍于面子不会往死里挑毛病。现在我会把设计文档丢给 Claude Code让它扮演一个“对现状一无所知但非常挑剔的架构师”专门找逻辑漏洞、假设缺失、风险和备选方案。这个做法帮我提前发现了很多问题。比如有一次我设计的服务降级方案Claude Code 指出我没有考虑“降级本身可能导致雪崩”的情况我一看才发现确实漏了。这种 feedback loop 的价值不在于是不是 AI而在于它让你在低摩擦的环境里不断修正自己的思考盲区。时间长了你脑子里会自动带着一个审查者视角写方案时就会更严密。这比多看几篇架构文章管用得多。6. 把访谈建议变成个人行动计划6.1 给中级工程师的三个月自检清单光听道理没用得能落地。我把访谈里的核心观点整理成了一份三个月自检清单建议你每两周对照一次看看自己有没有跑偏。第一个月练习“质疑需求”。这周有没有一次需求沟通中你主动追问了“为什么要做”如果没有下周找一个需求开始问。第二个月开始写技术决策记录。每个重要方案至少写一页 ADR包含背景、决策、替代方案和理由。写不出来说明你还没想清楚。第三个月主动做一次跨团队分享。不需要大型宣讲哪怕只是给隔壁团队讲你们模块的架构演进也能逼你站在更高维度看问题。持续每次用 AI 工具时记录一个“AI 给出的方案我拒绝了”的案例并写清拒绝理由。这是训练判断力最快的办法。这份清单不是职场鸡汤它背后对应的都是 Principal 的核心能力定义问题、系统思维、技术影响力、判断力。你不需要一次性全做到但每两周复盘一次你会发现自己处理问题的粒度在悄悄变大。6.2 如何开始积累“跨团队影响力”很多人觉得跨团队影响力得等做到高工才开始其实不然。我见过一个工作三年的后端工程师因为把团队部署文档整理成了自己动手的视频教程被前端和测试团队当成“部署专家”后来很多跨团队项目都点名拉他参与。这就是影响力不需要头衔。更系统一点的做法是找到一个“大家都觉得痛但没人愿意收拾”的公共问题比如测试环境不稳定、接口文档常过期、告警太多没人响应。你花业余时间做一个让至少两个团队都能受益的小工具或流程规范然后把使用方式写清楚主动去相关团队讲一次。做完这一件事你积累的可信度胜过写十个功能。访谈里 Boris 说得很实在Principal 不是靠 title 获得影响力的是靠“别人用你的产出时感到爽”。你先想想你能做出什么让别人感到“爽”的东西而不是想想自己还缺什么知识。6.3 和 manager 对齐成长预期要资源而不是要评价从我带团队的经验看很多中级工程师在晋升这件事上吃了大亏原因是他们只会在绩效季问“我今年能升吗”而不是平时主动说“我需要什么样的机会来证明自己能升”。最有效的做法是找 manager 单独聊一次主题不是“我能升吗”而是“如果我打算两年内到 Principal我需要在这两年里积累哪些可展示的成果有哪些跨团队项目我可以参与”你要的是机会和资源而不是一句“继续努力”。把这个对话变成一个季度一次的固定动作你就能持续把 manager 变成你的资源而不是评审者。Boris 的访谈虽然没直接聊职场政治但他说过一个相通的观点人的成长不是靠被动完成任务而是靠主动构建自己的反馈系统。和 manager 对齐其实就是构建一个关于“方向和期望”的反馈系统。6.4 最后聊点个人经验别急着跳槽先在当前环境里试一次我知道很多人看到这里会觉得我现在的团队根本没有 Principal 的空间学习这些有什么用我的建议是别急着跳槽先试着在当前环境里做一次最小规模的事。挑一个你已经熟到不能再熟的模块把它重新做一次技术复盘找出三个可以优化的点然后主动在周会上提出你的方案并愿意牵头推进。哪怕只是把一段三年前没人敢碰的烂代码清理掉这件事带给你的东西比你刷十个面试题都大。因为你需要在这个过程中练习定义问题、说服别人、管理不确定性——这些能力在任何一家公司都通用。如果试了一次发现环境实在不给机会那再考虑换环境也不迟。最怕的是你从来没在当前环境里尝试过就默认“这里不行”。Boris 做 Claude Code 也不是一夜之间的事他是先在已有工具里看清了痛点积累起足够的判断力才敢去创造一个新东西。你的成长路径也一样不是靠一次晋升而是靠一个个“主动定义问题并解决它”的瞬间。我自己回看这几年的经历真正让我和同龄人拉开差距的不是某次绩效考核拿了高分而是几个“没人逼我做但我决定去做”的项目。Claude Code 这样的工具现在恰好把执行层的事压缩到了极致留给我们的时间窗口正好用来训练更上层的思考和判断。这条路任何时候开始都不算晚。