Claude Code创始人：程序员想成长，要找到自己的职业杠杆

今天想跟大家聊聊程序员的职业成长。

起因是我看了一个 Boris Cherny 的技术访谈，Boris 是 Anthropic 明星产品 Claude Code 的创造者，也曾是 Meta 的高级工程师。

Boris 总结自己的职业生涯时，给我的感觉其实并不是传统意义的「上台阶」，而是用少数几个核心杠杆撬动更多资源，最重要的是，我们应该学习如何找到并利用这些杠杆。

Boris 提到一个词，叫“Latent Demand”（潜在需求）。

什么是潜在需求？简单说，就是用户已经自发在做某件事了，只是用得很别扭，因为你还没给他们提供合适的工具。

Boris在Facebook时期的第一个成功项目是“社群聊天”。这个项目是观察到人们的行为已经开始从公共广场式的社交，转向更私密、更即时的聊天群组。Groups 最初并不是为即时聊天设计的。于是，他和团队要做的，不是去“创造”一个全新的用户行为，而是去“疏导”一个已经存在但被压抑的需求。

然后团队发现，Facebook Groups里有高达40%的帖子是关于买卖东西的。于是，Marketplace又诞生了。

同样的逻辑也适用于Facebook Dating，当时的数据显示，60%的用户主页浏览来自非好友的异性。这些都是用户的潜在需求。

“潜在需求”极大地降低了产品失败的风险。

这个思维方式不仅限于产品经理。对于工程师来说，它同样是寻找高价值项目的办法。

在你的团队、你的公司里，是不是有很多人在用一个极其难用的内部工具？是不是有某个流程，大家都在私下吐槽？

你发现了这些需求，并且用一个优雅的解决方案去疏导它，你撬动的就不是一行代码，而是一群人的生产力。

Boris 反复强调“Side Quests”（支线任务/业余项目）对他的成长有多么重要。当他招聘工程师时，他甚至会专门寻找那些有“业余项目”的人，哪怕只是业余爱好是酿茶。

因为这代表了一种超越本职工作的好奇心和行动力。

Boris 在 Meta 时期最著名的“业余项目”之一，是一个叫 undux 的 React 状态管理框架。当时，官方推荐的 Redux 对他来说太复杂了，他想不通为什么更新一点点状态需要走那么一套繁琐的流程。他相信，遇到这个问题的肯定不止他一个人。这就是前面说的“潜在需求”的工程版本。

于是他自己写了一个更简单的 undux。怎么在公司内部推广呢？他写了个脚本，抓取了内部论坛里抱怨 Redux 难用的人，按团队统计，然后挨个联系这些团队的技术负责人和经理，给他们安排专门的技术分享。他骑着自行车在 Meta 的各个园区里，做了二三十场这样的分享。最终，undux 成为了当时 Facebook 内部最流行的状态管理框架。

这个项目本身可能没有直接让他晋升，但带来了影响力网络和杠杆效应。

另一个例子是他写了一本关于 TypeScript 的书，还组织了当时全球最大的 TypeScript 线下聚会。这些事，同样不是他的本职工作。但通过这些，他不仅成了这个领域的专家，还认识了像 Ryan Dahl (Node.js 创始人) 这样的顶尖人物。

他得出一个感悟：原来这些大神也都是普通人，任何人都可以去做很酷的事情。

这种“业余项目”思维的本质，是在组织的正式结构之外，建立自己的影响力和价值网络。

你的正式项目决定了你的下限，但这些“业余项目”决定了你的上限。它们是你职业生涯的期权，平时看似无用，但在关键时刻，会给你带来意想不到的回报。

Boris 的职业生涯中，有两次关键的晋升都和大型基础设施项目有关。

一次是从E6升E7，他主导了 Groups 前端的重写，从老旧的 PHP 迁移到全新的 JavaScript 框架 Comet。另一次是在 Instagram 期间，他推动了将后端从 Python 迁移的大工程，这为他晋升E8奠定了基础。

这两件事的共同点是：他都是在公司层面的技术浪潮到来之前，主动迎上去，甚至成为浪潮的一部分。

在Comet项目上，当他提出要把庞大的 Groups 作为新框架的小白鼠时，组织内部是有很大阻力的。但他坚持这么做，因为他看到了抢跑的好处。

他们是最早的实践者，所以他们不仅是新框架的用户，更是新框架的共建者。他们有机会去定义和影响整个 Facebook 未来Web开发的基础设施。比如他为了解决一个按钮快速连击导致状态不一致的问题，写了一套管理API请求队列的系统，后来这个系统被所有团队采用。

在大公司里，技术迁移往往是自上而下的任务，大部分团队是被动接受者。而被动接受，意味着你只能在别人定好的规则里干活，没有多少创造空间。

但如果你能提前预判，你就从一个棋子，变成了半个棋手。你获得了定义规则的权力和机会。

今年 vibe coding 火了以后，很多人都在思考为什么 Claude Code 能在众多竞品中脱颖而出。

Boris 的回答是：他的老板给了他一个关键的建议——“不要为今天的模型构建产品，要为六个月后的模型构建产品。”

在传统的软件开发世界里，我们总是基于当前的技术约束来设计产品。CPU就是这么快，内存就是这么大，API就是这个样子。

但在 AI 领域，尤其是大模型领域，底层平台（模型本身）正以指数级的速度进化。你如果为今天的模型设计了一个刚刚好能用的产品，那么当三个月的新模型出来时，你的产品可能就已经显得“设计过于保守”了。

所以，Boris 团队在开发 Claude Code 的很长一段时间里，产品体验其实并不好。因为他们是为未来的、更强大的模型能力而设计的。

但奇迹发生在模型能力终于“追上”产品设计的那一刻。当 Claude 3.5 Sonnet 和 Opus 发布时，Claude Code 的产品体验突然就“对了”。一切都流畅了起来。这恰好是项目启动大约六个月后。

这是一个范式级的转变。

它要求产品构建者有一种“预言能力”，或者说，是对“Scaling Law”（规模定律）有深刻的信仰。

你必须相信，六个月后，模型的推理能力、代码生成能力、上下文理解能力会达到一个新的高度，然后基于这个“未来”去设计你的产品架构、交互和功能。

这意味着，你开发的产品在发布之初，可能感觉上是“超前”甚至是“残缺”的。但当模型能力这条S曲线陡然爬升时，你的产品会是第一个、也是唯一一个能完美承接住这股新力量的容器。

今天，Anthropic 内部工程师生产力因为 Claude Code 提升了近70%，有些团队90%的代码都是用 Claude Code 写的。这背后，正是得益于这种“为未来编程”的远见。

不要只盯着眼前的 prompt engineering，要去思考当模型的智能水平再提升一个数量级时，你的产品应该是什么形态。

回到最初的问题：一个程序员的职业生涯到底是什么？

看完 Boris Cherny 的故事，我的答案是：这是一场不断寻找并应用杠杆的游戏。

你会发现，所有这些杠杆，都和写好代码这件事关系不大。它们都需要你抬起头，去看代码之外的世界：看用户在做什么，看同事在抱怨什么，看公司的技术版图在如何演变，看整个科技行业的正在发生怎样的变化。

所以，多去找找你的杠杆吧。