「如果6个月后你再问我这个问题，我的答案会完全不同。」Boris说这句话时，Anthropic团队规模已经翻了三倍，但工程师人均效率却增长了70%。
原因只有一个：Claude Code。
如果你现在还在逐行敲代码，你可能正在用打字机时代的方式工作——当12个工程师花两年才能完成的迁移项目，如今只需要5个人6个月就能搞定时，这不是夸张，而是Boris亲眼见证的现实。
这个人叫Boris Chney，Claude Code的创建者，前Meta首席工程师。他在Meta从中级工程师升到IC8（相当于技术VP），带过600人的团队，写过影响5000名工程师的基础设施。
但他的故事里有个细节很少人知道：10年前他骑摩托车出了车祸，两只胳膊都骨折了，戴着双臂吊带一个月无法写代码。正是这次意外，逼着他学会了用更少键盘敲击完成更多事情——从CoffeeScript到Haskell，再到函数式编程。他说：「那时候我开始用类型系统思考问题，代码的类型签名比代码本身更重要。」
这种「用更少做更多」的思维，后来贯穿了他整个职业生涯。
Boris刚进Meta时是个underleveled的中级工程师，尽管他已经有丰富的创业和开发经验。「低预期是幸运的，」他后来复盘说，「没人盯着你刷KPI，你有空间去探索真正重要的事。」
他做的第一件事是去餐厅找咖啡厅工作人员做用户测试。那时Facebook Groups刚上线Chats功能，Boris带着团队在午餐时间跑到公司餐厅，拦住咖啡厅员工：「嘿，你能找到这个聊天入口吗？」有时对方能找到，有时完全找不到。这种观察式用户研究（observational UX research）很快成了整个团队的习惯——不需要专门的用户研究员，工程师自己就能快速验证设计。
真正的困境出现在跨组织协作上。
Facebook和Messenger是两个完全不同的世界。Facebook的文化是「快速发布」，Messenger的文化是「绝对可靠」。Boris想打通两者的聊天功能，结果发现Messenger团队的工程师对他们充满戒心——因为任何新功能都会拖累Messenger的性能指标，而组织考核目标完全不一致。Facebook看DAU（日活），Messenger看SLA（服务可用性）。
「难？这简直是噩梦。」Boris说。
这个项目最后失败了。但Boris学到的教训改变了他后来所有的协作方式：如果两个团队价值观根本对立，你必须找到一个双方都在乎的共同目标，或者直接去找CEO重组组织架构。「当时我应该直接去找扎克伯格，说如果你真的想做这件事，就把Messenger并入Facebook的组织——共同汇报的层级不能是Chris Cox那么高，必须低一两层，才能真正对齐激励。」
但事情没结束。
转折点在Comet项目。Comet是Facebook在桌面端用React重写整个网站的大型迁移，Boris想把Facebook Groups作为第一个试点产品。领导一开始拒绝了——这需要大量工程师资源，Groups团队根本不够人手。
Boris没有放弃。他先主动联系Comet基础设施团队，说「我们可以当小白鼠」，然后回去跟Groups的领导说：「Comet迁移迟早要来，我们现在提前做，可以抢先制定标准、建立关系、还能影响基础设施的设计方向。」
这个策略奏效了。他最终拿到了12个工程师的headcount，带着团队花了一年时间完成迁移。但更重要的是他做的三件事：
**第一步：用具体问题建立信任。**Boris发现Relay（Meta的GraphQL客户端）有个棘手的bug：如果你快速点击一个按钮，每次点击都会发送API请求并切换按钮状态。但如果网络响应乱序返回，UI最终状态可能跟实际数据不一致。他花时间写了一个「mutation队列系统」，确保请求按顺序更新缓存。这个系统后来被整个Meta采用，也让他认识了Relay核心团队。
「我喜欢那些愿意往下挖一层的工程师，」Boris说，「产品工程师可以做基础设施，基础设施工程师也可以去跟用户聊天——好奇心比title重要。」
**第二步：把痛点变成可复用的lint规则。**Boris在做code review时，会用一个Excel表格记录每次他评论的问题类型——比如某种代码风格问题、某个常见的逻辑错误。当同一个问题出现超过3次，他就写一个lint规则自动化检查。到后来，他的大部分code review工作都被一堆lint规则自动完成了。
这不是懒，是杠杆。
**第三步：找到那些卡住5000人的小问题。**有一次Boris发现团队频繁遇到生产环境bug——原因是没有人测试「拥有1000万成员的Facebook Group」这种极端数据场景。写一个包含1000万条mock数据的单元测试太麻烦，所以大家都跳过了。Boris找了一个工程师，让他专门做一套「大数据集单元测试基础设施」。这套工具后来防止了无数线上事故，影响了整个Meta的测试标准。
问题出在下一步。
Boris升到Staff（IC6）后，扎克伯格决定ALL IN社区功能，给Facebook Groups组织疯狂扩张headcount——Boris刚加入时团队150人，离开时已经600-800人。Boris和领导团队需要在几周内为几百个工程师规划工作：「这周给30个人做技术方案，这个项目选三个技术方向；下周给20个人做方案，再选三个方向……」
Boris后来复盘说：「如果重来一次，我会建议投入少得多的人力。产品market fit需要自下而上慢慢验证，不能靠堆人头。」
但有个例外让他印象深刻。当时要把Facebook Groups和Pages的数据模型合并，这是个极其复杂的迁移工程——涉及数据模型、产品层、完整性系统、广告系统，完整做完可能需要几百个工程师干好几年。负责的技术lead Ysef迟迟无法决定数据模型设计方案。
Boris做了一件疯狂的事：他把整个组织的tech leads分成蓝队和绿队，给他们3小时时间，在白板上各自设计一套数据模型合并方案。
结果是两个团队的方案有80%一致。
「进去之前我们完全不知道怎么做，出来之后我们有了两套80%相同的设计，」Boris说，「一致的部分可以立刻执行，不同的20%就是风险所在——我们可以先做一些技术spike来验证。」
这不是共识会议，是技术设计竞赛。Boris没有征求意见，直接把活动排上了所有人的日历。「有些时候你需要共识，有些时候你必须先行动——当路径不清晰时，行动本身就是建立共识的方式。」
Boris后来去了Instagram，又去了Anthropic。在Anthropic他做了Claude Code——一个让AI帮你写代码的工具。
这改变了一切。
他说的那个数字再次出现：过去12个工程师花两年才能完成的Facebook Groups迁移项目，如果放到今天，5个工程师用6个月就能搞定。「每个人都跑着一堆Claude实例，让它们并行工作几个小时，回来就有一个PR等着你review。你再给它Puppeteer之类的工具，让它能看到UI，它就能自己调整代码。」
不止如此。Anthropic团队规模翻了三倍，但工程师人均效率增长了70%——因为Claude Code。
想想你上次做技术scoping（范围评估）花了多久。Boris说现在他会直接让Claude Code跑一遍代码库，问它：「这个功能涉及哪些系统？」过去需要工程师花几天时间梳理的依赖关系，现在30分钟就能搞定。
「我做这些工作的时候，从来没想过AI能帮我做，」Boris说，「但现在它就是可以。」
两个字：杠杆。
这背后有个更深层的逻辑。Boris提到过一个Meta内部的产品原则：latent demand（潜在需求）。
什么意思？Facebook Marketplace（二手交易平台）是怎么来的？因为团队发现Facebook Groups里40%的帖子都是在买卖东西——用户在用一个不是为电商设计的产品做电商。Facebook Dating（约会功能）怎么来的？因为数据显示60%的陌生异性profile浏览都是在「偷偷看」对方——用户已经在用Facebook约会了，只是产品没承认而已。
「你永远无法让用户做他们不想做的事，」Boris说，「你能做的是找到他们已经在做的事，然后让他们做得更容易。」
这也是Claude Code的逻辑：工程师已经在用ChatGPT、GitHub Copilot写代码了，只是工具还不够好、流程还不够顺。Boris做的不是发明新需求，而是把一个已经存在但被压抑的需求释放出来。
就像当年他骑摩托车摔断胳膊后，被迫学习用更少键盘敲击完成工作——真正的突破不是做更多，而是找到更高效的方式做同样的事。
但这不是万能药。
Boris强调Claude Code有明确的适用边界：「不要为今天的模型设计产品，要为6个月后的模型设计。」模型进化太快，如果你的工作流建立在当前模型的能力上限上，6个月后就会过时。
另一个限制是：AI不能替代你对业务的理解。「工程师必须保持对代码的直觉，」Boris说，「如果你完全脱离代码，你会很快失去这种直觉——那是非常危险的状态。」他在Instagram时因为时区问题（东京和纽约完全错开），被迫减少会议、大量写代码，反而成了他的「超能力」——因为他是少数几个还在深度coding的高级工程师，能发现别人看不到的基础设施问题。
Claude Code不是让你不写代码，而是让你有更多时间写最重要的那部分代码。
Boris现在还是不开standing 1:1，不参加大部分会议。他说自己「永远在想怎么做更少的事」。
他最喜欢的管理书是Andy Grove的《高产出管理》（High Output Management）——「听起来超无聊的书，但是最好的一本」。书里有条原则：永远委托你想做的事，而不是你不想做的事。因为只有你喜欢的事，你才能监督进展、确保做好。
这听起来反直觉，但仔细想想：如果你把不想做的事委托出去，你根本不会关心结果好坏；如果你把最在意的事委托出去，你会密切跟踪、及时纠偏，最后培养出真正靠谱的继任者。
Boris把Instagram的Python到Hack迁移项目委托给Jake，因为他太了解这个项目了，可以准确判断进展是否在轨道上。结果Jake做得比他想象的还好。
这也是杠杆。
Anthropic现在所有人的title都是「Member of Technical Staff」——不管你是工程师、PM还是设计师，一视同仁。Boris说他喜欢这种文化：「你必须靠实际工作赚取信任，而不是靠头衔。就算你以前做过牛逼的事，在新环境里也得重新证明自己。」
他在Meta没有title的时候，学会了在餐厅拦住陌生人做用户测试； 在Instagram没有时区重叠的时候，学会了用代码而不是会议建立影响力； 在Anthropic做Claude Code的时候，把「用AI做更少的事」变成了整个行业的新标准。
如果6个月后你再读到这篇文章，Boris对「工程师应该怎么工作」的答案可能又完全不同了。
但有一件事不会变：那些真正改变游戏规则的人，从来不是做得最多的人，而是找到杠杆的人。