企业官网建设流程全解析

团队里一个刚升到高级的同事最近问了我一个问题：他说自己每天都写了不少代码、Review 了不少 MR、也带过一两个小项目，但心里总觉得离 Principal 很远，不知道差在哪。我拿 Claude Code 这个话题反问了他一句：你现在能用 Claude Code 在终端里读代码库、改代码、跑测试，这确实已经超过很多人了；但 Boris Cherny 在那次关于 Claude Code 的访谈里，字里行间谈的其实是另一个问题——你为什么要用它，以及你用什么标准来度量自己的成长。

这个问题值得展开说。Claude Code 火了之后，网上最多的搜索词是“安装”“配置”“接模型”“VSCode 里怎么用”，这些都属于工具使用层面，我当然会聊一些，但真正想聊的，还是那条从中级工程师到 Principal 的成长路径。Boris Cherny 本人就是这条路径上一个很有意思的样本：写编程语言出身，做过 TypeScript 生态里的事，最后跑去做一个终端里的编码 Agent。这篇不是访谈逐字稿，也不是工具营销文，而是我把访谈连同自己多年在大型代码库里的实操经验揉在一起，整理出来的一些判断。你把它当成一份“从会用工具到会造工具”的职业复盘来看就行。

1. 访谈背后那条职业连线：编译器老兵为什么会去做终端编码 Agent

1.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 之间最实际的分水岭。

我把这个观察整理成了一个表格，方便你对照自己的日常状态：

别急着反驳说“这不是岗位描述区别，这是职级带来的资源区别”。我见过很多中级工程师，手里并没有多高的权限，但照样能在团队里做出杠杆级的东西，关键不在资源，在于你有没有主动从“解决问题”切换到“定义并解决重复问题”。

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 处理一个大仓库的时候，最在意的不是它生成的代码质量，而是它有没有经过一个“可验证的循环”。典型过程是这样的：

1. 它先读取项目结构和说明文档，确认自己理解了仓库意图；
2. 然后定位到相关文件，打开上下文，分析当前实现；
3. 生成修改方案，通常是一个明确的 diff 级别描述；
4. 它在改动之后跑测试或语法检查；
5. 最后把人工确认的时机留给你。

这种“做一步、验一步、确认一步”的循环，本质上和工程师写代码的习惯完全一致。很多人以为 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 处理大型项目时，我推荐的工作流也是这样：

1. 让它先画出仓库的结构和模块关系；
2. 让它标出哪些文件是高危区域，也就是被大量依赖的核心文件；
3. 再让它深入到你要改的那个局部路径；
4. 最后才进入修改和验证。

这个流程不仅能让 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 就不只是一个头衔了，而是你做事的默认姿势。