#模型时代# Claude Code创造者的工程师成长路径：招人看业余项目，晋升靠常识，产品来自用户自我需求

Boris Cherny是Claude Code的创造者，也是前Meta的主任工程师。这期播客由Ryan Peterman主持，Boris完整分享了他在Meta从中级工程师（E4）一路晋升到Principal Engineer（E8）的成长历程，以及加入Anthropic后创建Claude Code的故事。他的经历揭示了一个核心法则：优秀的工程师不只是写代码，而是用common sense（常识）解决真正的问题。

播客中有一个惊人的数据：尽管Anthropic今年员工数翻了三倍，但因为Claude Code的普及，每个工程师的生产力反而提升了近70%。Boris认为这只是开始，6个月后情况会完全不同。

一、找到对的机会：Latent Demand（潜在需求）

Boris把latent demand称为"产品领域最重要的原则"。

1、什么是latent demand

用户已经在用你的产品做某件事，只是方式很笨拙。你的工作是发现这个行为，然后为它专门设计一个更好的产品。

Facebook Marketplace就是典型案例。当时Facebook Groups里40%的帖子都是买卖东西，用户在一个不是为交易设计的产品里硬生生造出了交易场景。团队发现这个数据后，先做了buy-sell groups，再做了Marketplace。Facebook Dating的逻辑也一样，数据显示60%的个人主页浏览来自异性非好友用户，这说明用户本来就在用Facebook找对象。

2、关键原则

"你永远不可能让用户做他们还没在做的事。你能做的是找到他们已有的意图，然后让他们更容易实现这个意图。"

Boris强调要设计能被"hack"（改造）的产品，然后观察用户怎么滥用它，这些滥用行为就是潜在需求的信号。

二、通用型工程师的价值

Boris反复强调一个选人标准：他喜欢招"generalists"（通用型人才）。

1、工程师应该跨界

在Facebook Groups早期，团队没有用户研究员，Boris就带着工程师去食堂找厨房员工测试新功能。"我们没有告诉他们怎么用，就看他们能不能自己找到开聊天的入口，看他们在哪里卡住。"后来他把这套方法教给整个团队，大家午饭时间都去食堂做用户测试。

Claude Code团队现在延续这个传统：产品经理会写代码，数据科学家会写代码，用户研究员也会写一点代码。

2、副业项目（side quests）是成长引擎

Boris招人时专门看候选人有没有side projects。"我喜欢有side quests的人，哪怕只是特别喜欢酿康普茶也行。你要找那些对主业之外的事物有好奇心的人。"

他自己就是这样成长的。在加入Facebook之前，他做了一个叫Undux的React状态管理框架，只是因为Redux太复杂他搞不懂。后来他还写了一本TypeScript的书，"吃掉了我一年的生命，不推荐"，但这让他建立了TypeScript meetup，认识了Ryan Dahl（Node.js创始人）等一批人。"这让我意识到，这些人都只是普通人。每个人都在做有趣的东西，有些东西在特定时间点特别酷，但归根结底都是人，任何人都能做这些事。"

3、"Think in types"的思维方式

Boris提到改变他编程方式的一本书：Functional Programming in Scala。"你可能永远不会用Scala，但这本书教你思考编程问题的方式，跟大多数人学的完全不同。它会彻底改变你写代码的方式。"

他的核心观点是：写代码时最重要的是type signatures（类型签名），这比代码本身还重要。把类型定义清楚，代码自然就干净了。

三、跨组织协作：一场噩梦的教训

Boris在Facebook Groups做一个需要和Messenger团队合作的项目时，遭遇了巨大的文化冲突。

1、两种完全对立的文化

Facebook Groups团队的目标是快速发布产品、追求DAU和用户参与度。Messenger团队的目标是可靠性和性能，他们有SLA（服务等级协议）要维护。"我们想快速上线，他们所有的组织设计都是为了慢慢上线、不让指标退步。"

这不只是工程师之间的文化差异，而是深植在组织设计、绩效目标、激励机制里的根本性分歧。

2、解决方案：找到共同的上级

Boris的反思是："如果真的要让两个价值观完全不同的组织合作成功，你必须找到某种共同的目标，或者某种共同的假设，让双方都觉得如果成功了会很有趣。"

更实际的建议是：合作的两个团队，共同汇报对象不能是Chris Cox这样的高层，必须是更下层的共同管理者，这样才能真正对齐激励。

四、如何在大公司做技术scoping

Boris曾经负责为数百名工程师规划工作，他分享了一些实操技巧。

1、时间框定是关键

"大多数技术scoping，30分钟就能粗略做完。如果你不熟悉系统，现在可以用Claude Code跑一遍代码库，问它有哪些系统涉及到，它真的能帮你做这件事。"

他的建议是：不要陷入细节。花30分钟到最多几个小时，找专家聊，给他们一个strawman（草案），而不是问他们意见。有了草案他们才能给你有价值的反馈。

2、设计竞赛解决僵局

有一次团队在数据模型设计上卡住了，一个资深工程师迟迟不做决定。Boris把全组的tech leads分成两队，给3小时时间各自设计方案。"进去之前我们完全不知道该怎么做，出来之后我们有两个80%相同的方案。剩下20%不同的地方，清晰地告诉我们风险在哪里。"

他没有提前征求同意，直接把会议放到所有人日历上。"有些时候需要共识，有些时候你必须行动。在这个case里，因为方向不清楚，必须先行动。"

五、晋升的秘密：Level不重要

Boris有一个反直觉的观点：入职时被低估定级其实是好事。

1、低级别意味着低预期

"我入职Meta时是E4，但我之前已经有很多经验了。低级别给了我空间去探索，去为了做有趣的事而做有趣的事，而不是追着impact跑。"

他还给出一个通用建议：很多工程师跳槽时拼命要求level+1，但这可能有很大的downside。预期太高，反而难以建立口碑。

2、冒名顶替综合征（imposter syndrome）是正常的

Boris晋升到E6后，要带和自己同级别的senior engineers做一个大项目。他坦承当时有很强的imposter syndrome。但他现在的看法是："级别根本不重要。有些很junior的人能交付惊人的结果，有些很senior的人交付的结果很差。级别说明不了什么。"

他的建议是：不要overthink。"没有人真正知道自己在做什么，不管在什么级别。我们都在摸索。"

3、晋升是做对的事的副产品

Boris从E7晋升到E8时，他的manager Will Bailey主动提出："我觉得我们应该给你提名IC8。"Boris的反应是"cool"，他之前根本没想过这件事。

"我没有主动要求过。Will很擅长recognizing people、为团队争取机会，他觉得我ready了，就这样了。"

六、加入Anthropic与Claude Code的诞生

Boris离开Meta加入Anthropic有两个原因：mission（使命）和common sense（常识）。

1、为什么选Anthropic

"ChatGPT出来的时候，我在日本的乡下，是镇上唯一的工程师，唯一说英语的人。我没有人可以聊技术。用了ChatGPT后我完全被震撼了，我知道我必须做这个方向。"

他去Anthropic面试时，午餐提到一本冷门的Greg Egan科幻小说，结果桌上所有人都读过。"这是一群intense的科幻nerds，他们跟我一样深入思考这些问题。"

2、为模型6个月后的能力而构建

Claude Code一开始并不好用。Boris的manager Ben Mann推着他思考更大的图景："不要为今天的模型构建，要为6个月后的模型构建。"

"很长一段时间，Claude Code不是一个好产品。我用它大概写10%的代码。然后我们发布了Sonnet和Opus 4，产品突然就work了。这正好是项目开始后的6个月。"

现在Claude Code团队80-90%的代码是用Claude Code自己写的。一些团队90%的代码都是这样写的。

3、AI coding的未来

Boris描述了一个场景：团队的Daisy要发布一个plugins功能，她让Claude设置了一个Asana board，创建任务，然后用20个Claude agents同时在周末跑，几天后就完成了。"这就是工程的未来。"

他自己每天早上用手机版Claude Code启动几个agents开始写代码，到办公室再检查进度。"6个月前如果你问我会不会这样写代码，我会说你疯了。但它真的work。"

关于AI生成代码质量的担忧，Boris的回答是：Claude Code团队对模型生成的代码和人写的代码用完全相同的标准审查。"如果代码不好，我们不会merge它，跟人写的一样。你让模型改进就行了。"

总结

Boris的职业哲学可以归结为一句话：用common sense做事。

大公司里有太多因为惯性存在的流程、太多错位的激励。创业公司里也一样，你需要用常识判断市场要什么、用户要什么。

他的建议：

• 学编程要从实践开始，理论以后再补

• 找对问题比找对解法更重要

• 做你喜欢做的事，然后delegate你喜欢的工作（这样你才能监督好）

• 信任要earn（赢得），哪怕你之前再厉害

---

核心归纳

Q1: 工程师怎么找到有impact的side project？

观察你自己每天碰到的问题。如果一个问题出现两三次，去看看别人是不是也有这个问题。Boris在Meta时把code review中重复提的问题记在spreadsheet里，出现几次就写成lint rule自动化掉。"最无聊的工作都可以自动化，这是工程师的超能力。"

Q2: 跨组合作失败的根本原因是什么？

激励不对齐。不只是工程师之间的文化差异，而是组织设计、绩效目标、资源分配都指向不同的方向。解决方案是找到真正共同的利益点，或者把两个团队放到一个更近的共同汇报线下面。

Q3: 现在学AI coding应该怎么学？

不要只想着autocomplete（自动补全），那是一年前的思路。学习用多个agents并行工作，把自己变成orchestrator（协调者）而不是coder。Boris的数据科学家同事、销售团队都在用Claude Code工作，这不是程序员专属工具了。