团队里一个刚升到高级的同事最近问了我一个问题他说自己每天都写了不少代码、Review 了不少 MR、也带过一两个小项目但心里总觉得离 Principal 很远不知道差在哪。我拿 Claude Code 这个话题反问了他一句你现在能用 Claude Code 在终端里读代码库、改代码、跑测试这确实已经超过很多人了但 Boris Cherny 在那次关于 Claude Code 的访谈里字里行间谈的其实是另一个问题——你为什么要用它以及你用什么标准来度量自己的成长。这个问题值得展开说。Claude Code 火了之后网上最多的搜索词是“安装”“配置”“接模型”“VSCode 里怎么用”这些都属于工具使用层面我当然会聊一些但真正想聊的还是那条从中级工程师到 Principal 的成长路径。Boris Cherny 本人就是这条路径上一个很有意思的样本写编程语言出身做过 TypeScript 生态里的事最后跑去做一个终端里的编码 Agent。这篇不是访谈逐字稿也不是工具营销文而是我把访谈连同自己多年在大型代码库里的实操经验揉在一起整理出来的一些判断。你把它当成一份“从会用工具到会造工具”的职业复盘来看就行。1. 访谈背后那条职业连线编译器老兵为什么会去做终端编码 Agent1.1 我理解的 Boris 技术底色很多人第一次听到 Boris Cherny 这个名字是因为《Programming TypeScript》那本书或者是因为他在 TypeScript 社区里留下的各种 talks。换句话说他本质上是一个有编程语言背景的人类型系统、编译器、AST、作用域分析这些东西对他来说是家常便饭。这样的人跑去做 Claude Code表面上看是从“语言工具”跳到了“AI 工具”但从设计理念上讲这两者其实离得非常近。程序员理解别人的代码靠的是读代码、跟踪调用关系、猜测意图编译器理解代码靠的是语法树、符号表、类型推导、作用域链。Boris 在做编译器相关的工作时练出了一套非常结构化的代码理解方式不靠感觉靠结构。这套方式放到 Claude Code 身上就是让模型在动手改代码之前先弄清楚代码库的结构、依赖关系、上下文边界而不是让模型像一个什么都不懂的新人那样直接往里冲。1.2 编译器思维恰好是 Agent 的底层思维我在实操里发现一个很有意思的现象Claude Code 处理一个陌生仓库时的习惯和编译器处理一个源文件的步骤几乎是同构的。编译器拿到源码后先做词法分析、语法分析再建符号表然后才做类型检查和代码生成Claude Code 在大型代码库里通常也是先读目录结构再搜索关键符号找到相关文件之后打开上下文最后才生成修改提议。整个过程不是“一次生成一大段代码”而是“一步步逼近正确答案”。这个设计取向非常值得中级工程师学习。很多人拿到一个没见过的代码库第一反应是全局搜索关键词东看一个文件西看一个文件最后改了 A 又弄坏了 B。而 Boris 那类编译器老手会先想这个代码库的入口在哪模块边界是什么哪些符号是被多方依赖的哪些地方是真正需要动的。这种思维一旦养成你就算不用任何 AI 工具单靠自己的阅读路径也能把代码库捋得明明白白。1.3 访谈里最值得抄的一个判断访谈里我印象最深的一句话大意是编码 Agent 不是更聪明的代码补全而是更严谨的编译器工具。这句话翻译成日常经验就是Claude Code 的价值不在于它“能写代码”而在于它有足够多的机制去限制自己、验证自己、纠正自己。这和工程师成长的逻辑是一样的一个中级工程师和一个 Principal 的最大区别往往不是谁代码写得快而是谁更清楚自己的工作边界、验证方式和影响范围。我把这条逻辑记下来之后回头再看网上铺天盖地的“Claude Code 使用教程”就有了一个判断绝大多数教程讲的是“怎么让它输出代码”而不是“怎么把它纳入你的工程判断体系”。后者才是这次访谈真正有价值的地方。2. 中级工程师和 Principal 的分水岭藏在访谈里的能力象限2.1 解决问题与定义问题是两种完全不同的工作访谈中反复出现的一个主题是 Boris 在描述自己的工作时很少说自己“写了多少功能”更多是在说“我构建了某个让其他人更高效的系统”。这个区别恰恰就是中级工程师和 Principal 之间最实际的分水岭。我把这个观察整理成了一个表格方便你对照自己的日常状态维度中级工程师的典型状态Principal 的典型状态关注问题被交付的具体任务什么是值得被解决的问题时间跨度本周、本迭代这个季度、这个技术方向交付物代码、MR、修复工具、框架、流程、团队能力影响范围自己负责的模块跨团队、跨项目的杠杆点重复性同类问题反复处理把同类问题抽象成一次投入别急着反驳说“这不是岗位描述区别这是职级带来的资源区别”。我见过很多中级工程师手里并没有多高的权限但照样能在团队里做出杠杆级的东西关键不在资源在于你有没有主动从“解决问题”切换到“定义并解决重复问题”。2.2 最高级的抽象是别人几乎感觉不到抽象Boris 在做 TypeScript 相关工作时接触到的是语言层面的抽象你写下的类型注解编译器帮你检查你定义的一个 interface在无数个文件里约束着行为。语言工具的魅力在于使用者不需要理解底层机制只要遵守表面规则就能获得安全保障。这个思路被完整地带进了 Claude Code 的产品设计里。我实际用下来发现Claude Code 最值钱的地方不是“它能写”而是“它在动手之前先和你确认边界”。比如它支持把项目约定写进仓库说明文件启动时自动读取比如它在改代码前会先展现出它将要修改哪些文件、出于什么理由。这些都是从“编译器对代码的约束”延伸出来的产品逻辑。映射到个人成长上这就是一个很硬的指标如果你做的事情能让团队里其他人“不用知道原理也能变安全、变快”那你就是在做 Principal 层面的事。反之如果你做的事情只有你自己能解释、能维护那不管代码写得多么漂亮影响半径都极其有限。2.3 别把“工具用得熟”误当成“职业等级高”我必须提醒一个容易被热词裹挟的误区。最近 Claude Code 相关搜索里有很多是“如何配置”“如何接入”“如何让它在 VSCode 里跑起来”这当然是有用的但只停留在这一层对你的职级成长帮助不大。工具用得好只能证明你有执行力和学习速度这两个特质在中级工程师阶段就很关键但 Principal 需要的是判断力知道什么时候用工具、什么时候不用、什么时候要自己造工具、什么时候要把工具做得让整个团队都能用。这不是靠多跑几个 prompt 能练出来的而是靠一次次解决真实问题、一次次复盘抽象出来的。我在访谈里读到 Boris 的成长路径时最大的感受是他不是从“天天用工具”变成 Principal 的而是从“被重复问题烦到忍无可忍决定造一个别人也能用的解决方案”开始的。这个起点非常重要。3. Claude Code 的几个产品切片每个背后都是一种工程判断3.1 为什么先做 CLI而不是先做 IDE 插件访谈里聊到 Claude Code 的产品形态选择时思路其实非常工程化终端是所有开发者环境里最稳定的公共层。你可能用 VSCode他可能用 JetBrains 全家桶还有人用 Neovim、Emacs但几乎所有开发者都愿意在终端里待着。CLI 的好处不只是跨编辑器更是可组合、可脚本化、可审计。比如你可以在终端里把 Claude Code 套进自己的 worktree 流程让它和 git 命令、测试命令、CI 脚本串起来你甚至可以写一个小脚本批量处理一个目录下的多个拆解任务。IDE 插件固然体验好但可编程性远不如 CLI。这个判断放在任何工具选型场景里都通用如果你做的工具要被别人集成进复杂流程优先选一个协议简单、输入输出明确的形态而不是一个图形界面。3.2 工具调用循环而不是一次性生成结果我用 Claude Code 处理一个大仓库的时候最在意的不是它生成的代码质量而是它有没有经过一个“可验证的循环”。典型过程是这样的它先读取项目结构和说明文档确认自己理解了仓库意图然后定位到相关文件打开上下文分析当前实现生成修改方案通常是一个明确的 diff 级别描述它在改动之后跑测试或语法检查最后把人工确认的时机留给你。这种“做一步、验一步、确认一步”的循环本质上和工程师写代码的习惯完全一致。很多人以为 AI 编程就是“给一个需求吐一坨代码”Boris 在访谈里想表达的恰恰相反真正的 Agent 产品是要把工程上的谨慎、验证、节制感做到产品机制里。你在自己的编码习惯里也应该强制加入这个循环而不是拿到代码就提交。3.3 上下文是第一等公民1M 上下文不等于全塞进去现在到处能看到“1M 上下文”的说法很多人的直觉是上下文越长越能把整个仓库丢给模型。这个直觉在实际工程里是危险的。我在访谈里感受到的技术判断是上下文不是用来“无脑装”的而是用来“有选择地构建”的。就像编译器不会把整个项目的源码一次性装进内存做分析它只加载当前编译单元需要的符号和定义。实操上我在大仓库里会让 Claude Code 分阶段工作先让它给我一份代码地图再明确告诉它“这个功能只涉及支付模块的这几个文件”最后才让它动手。这个习惯值得你手动维护不要指望任何工具能自动替你判断哪些代码是核心路径哪些只是边缘逻辑。4. 把访谈里的成长路径落到地上三个可以立刻执行的动作4.1 动作一先定义验收标准再开始写代码访谈里关于工程师成长的讨论落到执行层面其实就是一个反直觉的顺序先写验收标准再写实现。Boris 做编译器时验证方式是很明确的——输入什么、期望输出什么、类型是否满足约束做 Agent 时同样先把任务拆成“改完之后的代码应该长什么样、测试应该过哪几条、影响范围应该控制在哪些文件里”。我现在给团队的建议就是哪怕是给 Claude Code 下一个改代码的任务也要在前面写清楚“可验收的结果”比如这个函数必须兼容现有的三种调用方式新加的错误处理不能吞掉原有日志改动不许影响订单查询接口的响应结构。写完这些再让工具动手输出质量会高很多你作为工程师的评审工作也会轻松很多。这个习惯反过来也会推着你往更高层级走因为定义验收标准本质就是在定义“做什么”和“做到什么程度算好”这正是 Principal 的核心职责之一。4.2 动作二为团队内部造一个真正的小工具我在访谈里得到的另一个强烈启示是不要只做一个 AI 工具的用户要做那个把团队重复劳动吃掉的人。Boris 从语言工具走向 AI 工具背后是一条“自己先烦透了重复劳动然后开始动手自动化”的路径。这条路径不挑技术栈大厂小厂都走得通。你可以从很小的范围开始。比如我认识的一个前端组同事发现自己每周都要手工核对一批依赖库的版本和废弃 API他就写了一个小 CLI把“扫描代码库、匹配废弃 API、生成报告”这三步串起来再配合 Claude Code 的 Agent 流程让它在每个迭代末自动跑一遍。这个工具技术上没有任何高深的地方但它一次性把十几个人的重复劳动全吃掉了。这件事的直接收益是团队效率间接收益才是关键的你从“写代码的人”变成了“定义工作方式的人”。下次晋升讨论时别人说“我完成了多少个需求”你可以说“我让整个团队完成需求的速度提升了多少”这两种表述的分量完全不同。4.3 动作三把“接到任务就动手”改成“先构建心智地图”有经验的工程师和新手在处理陌生代码库时的差别不在打字速度而在阅读顺序。新手往往是先找关键词再点进若干文件然后在一个非常局部的地方开始改有经验的人会先花时间搞清楚全局结构入口在哪、数据怎么流动、异常在哪里汇聚、边界在哪里。Claude Code 处理大型项目时我推荐的工作流也是这样让它先画出仓库的结构和模块关系让它标出哪些文件是高危区域也就是被大量依赖的核心文件再让它深入到你要改的那个局部路径最后才进入修改和验证。这个流程不仅能让 Claude Code 的上下文更准确也能让你在每一次协作中真正理解代码库。长期坚持下来你对系统的整体认知会远远超过那些只会在自己一亩三分地里打转的人。5. 顺着热词说几句实操话配置、模型接入和大代码库的注意点5.1 把项目说明文件当成你的“类型系统”Claude Code 非常依赖项目说明文件也就是放在仓库根目录的说明文档。启动时它会自动读取用来理解项目约定、编码风格、禁忌事项。我强烈建议不管是不是在用 Claude Code你都把这类文件维护起来。它是团队的“类型系统”把隐性的约定变成显性的规则。我的项目说明文件里通常包括这几块项目结构说明哪个目录是核心逻辑哪个目录是配置哪个目录绝对不能动代码风格约束缩进、命名、错误处理偏好常用命令测试、构建、局部运行踩坑记录哪些模块改动容易出事需要额外警惕。把这些写清楚Claude Code 犯错概率会明显下降更重要的是新成员接手时也不会一脸茫然团队的知识不再只存在老员工的脑子里。5.2 接入第三方模型这件事我建议你怎么看最近很多搜索词都在问能不能把 Claude Code 接到 DeepSeek、Qwen、GLM 这类模型上。社区确实已经有各种工具和脚本做到这件事思路大体上是走“模型配置切换”或“网关代理”把不同厂商的 API 统一成 Claude Code 能识别的接口格式。我的建议是如果你想玩可以试这能帮你直观感受到“底层模型能力”和“上层 Agent 工程能力”的区别但如果在严肃生产环境里还是优先考虑官方默认模型。原因很简单Agent 工具的核心不是模型多聪明而是模型能不能稳定地返回工具调用格式、能不能在长上下文里保持一致的行为。第三方接入经常会遇到工具调用格式不兼容、上下文窗口策略差异、模型行为漂移这些问题。你要记住你在生产环境里要的是确定性而不是新奇感。5.3 大型代码库里的几个操作习惯最后分享几个我在大型代码库里用 Claude Code 真实踩出来的习惯。第一任务一定要拆。不要让它同时改五个模块宁可拆成五轮每轮验证一次。拆小了之后就算哪一步它理解错了你也能精准回滚不至于牵连一片。第二让它先用搜索和结构工具不要直接跳到“读取整个文件”。大型仓库里最耗 token 也最容易干扰判断的是无关文件的上下文。精确指定路径、限定搜索范围哪怕多花你一分钟敲命令也比它被噪音带偏之后重新来一遍划算。第三改动后的输出必须经过你的眼睛。我看过太多人让工具改完代码直接提交结果留下了隐蔽的逻辑错误和风格不一致。工具可以帮你完成“执行”的那部分但“判断是否合格”的责任永远是你的。这个责任意识也是从中级往更高层级走必须守住的东西。访谈里 Boris 反复传递的那种“把工程约束内化到自动流程里”的态度放到个人成长上其实是一个更朴素的原则你可以用工具替你做很多事但替你做不了的是你对自己工作边界的定义、对重复劳动的反感、以及把个人经验变成团队杠杆的冲动。完成这一层转变Principal 就不只是一个头衔了而是你做事的默认姿势。