Claude Code 工程负责人 Fiona Fung：如何打造全世界最 AI Native 的工程团队-
公众号名称：十字路口Crossing
作者名称：Shirley
发布时间：2026-06-27 11:21
过去让你成功的，未必还能带你往前。
👩 编译: Shirley
🧑🎨 排版: NCon
Fiona 带领的，可能是全世界最 AI Native 的一支工程团队。
当写代码本身不再是瓶颈，她要回答的是一整套新问题：怎么验证、怎么衡量、怎么重组团队？
这场 Lenny’s Podcast 的近两个小时播客，是一份难得的一线管理者手册，而它真正想说的，或许是那句贯穿始终的话：
过去让你成功的，未必还能带你往前。
嘉宾背景
**Fiona Fung｜**Claude Code 与 Cowork 负责人，统管两条产品线的整个工程与 PM 团队，人们所熟知的 Boris Cherny、Cat Wu 都向她汇报。
她是一位既懂底层工程、又带过超大规模组织的资深 leader，拥有 25 年以上工程经验：从 IBM 起步，在 Microsoft 的 11 年里参与打造 Visual Studio 与 TypeScript；后加入 Meta，从 0 到 1 创办 Facebook Marketplace（目前年 GMV 超 1000 亿美元），参与 Meta 第一代智能眼镜与 Orion AR 眼镜，并在 Instagram 带过基础设施、增长与安全团队，管理过 500 人以上的组织。
核心观点
•**写代码不再是瓶颈，验证和衡量才是。**连设计师和 PM 都在提交代码，约束从”谁来写”变成”怎么验证”：把”什么算好”写成规范放进仓库让 Claude 比对，同时警惕别把“动起来”当成“有进展”。
•**招人只认两类：会做梦的产品型 builder 和啃硬骨头的系统专家。**一类端到端把想法做成好产品，一类守住分布式系统这种要深度把关的地方，底层是 trust but verify。
•**管理动作正在被自动化，工作转向异步。**一个挂在所有代码库上的常驻 Claude 掌握全队动向，Routines 比 cron job 多一颗脑子。
•**高 agency 必须配高 accountability。**给每个人放手去做的自由，同时要说清你想验证什么假设、谁为结果负责，自由与担当是一枚硬币的两面。
•**管理者要一直活在产品里。**再好的 dashboard 也替代不了亲手用产品的手感，很多关键判断常来自具体个例，当数据和个例打架时，有时要信个例。
•拉开差距的是成长型心态，挡住人的是恐惧。“过去让你成功的，未必还能带你往前”；面对恐惧，先问”哪些在我掌控之内”，再去做那件让你害怕的事。
从 VIM 到 Visual Studio：写代码，正在退出瓶颈的位置
👱♂️ 主持人 Lenny
一个月前我去了 Code with Claude，听了你的演讲，当时就想”我一定得请 Fiona 来上播客”，因为你想得比大多数人都要超前。
你做工程师 25 年了，从 IBM 起步，放今天看，那是个完全不一样的地方。这两年工程师这份工作变化大到离谱：不久前还是 100% 的代码由人写，如今正走向 100% 由 AI 写。就像 Boris Cherny 那句名言：“coding is solved（编码已被解决）”。
你们前不久还发了条推：
Anthropic 工程师如今人均每季度提交的代码量，是 2025 年前的约 8 倍。
作为一名亲历者，这一路走来，哪些时刻真正改变了你的思考方式？
👩💻 Fiona Fung
我太爱回看这种时间线了。
我在 IBM 做 DB2 的操作系统服务团队，当时一心想”去技术栈里最硬核的地方”，觉得越靠近操作系统越能学到东西。有意思的是，从 IBM 到 Microsoft 本身就是一次大跳跃。
在 IBM 我基本只用 VIM 加终端调试，公司好像有 Eclipse 的 license，但大多数人都不用。到了 Microsoft，说出来你别笑，我那会儿天真到根本不知道 IDE 是什么。
那是 2000 年代初，正值互联网泡沫破裂，我那届很多公司都在冻结招聘，所以当 Microsoft 给我 offer 的时候，我感激得不行。
他们说”你去开发 Visual Studio”，可我是 Unix 出身，压根不知道 Visual Studio 是什么，还真问了一句：“这是个更高级的画图软件吗？“我经理脸上的表情我至今都记得。但 Visual Studio 后来成了我职业生涯头 11 年的挚爱。
我在 VS 编辑器团队，自己天天拿 VS 编辑器去开发 VS 编辑器，我对 dogfooding 的热爱就是从那儿来的。（dogfooding 指团队自己先当用户，好在第一时间发现问题）
那时候还没社交媒体，工程师很难快速拿到用户反馈，好在我们整个团队都是 VS 的重度用户，彼此之间能给出特别快的反馈。
我做 Visual Studio 那会儿，软件还是刻在光盘上发行的，你得保证它能按时交付生产、压成光盘、再摆上货架。正因为工程时间稀缺、又有这种铁打的 deadline，那时候你会做大量规划，想把有限的时间用到极致。
而现在，跟 Claude Code、Cowork 一同见证的转变是：**写代码不再是瓶颈了。**不只是工程师，设计师、PM，Claude Code 团队里每个人都在提交代码。
所以，当提交代码的人越来越多、专业背景还各不相同、产出效率又这么高时，我们该怎么考虑”验证”这一环？这是我看到的另一大转变。
管理者把“盯全局”交给了一个常驻的 Claude
👱♂️ Lenny
那我先给这场对话定个基调：一支 AI Native 的软件团队，在 2026 年会是什么样子？
👩💻 Fiona
因为角色在融合，大家都在往 builder 这个方向走，人人都是 builder。
我最近在试一个做法：我有一个常驻的 Claude Code 远程会话，挂在我们所有代码库上，这样我对每个成员正在做的事都有全局视野。这个实例还能访问我们所有 Slack 频道，也能看到我们追踪的各项指标。
所以每个月我会说”嘿，咱们一起回看一下”，把屏幕一共享，开着 Claude Code 会话就问它：“这个月的重点是什么？发了哪些产品？市场反馈怎么样？反馈都来自哪些渠道？”
以前我用这种会话只是生成 PR、修 bug，现在我用它，是为了能和我带的同事，对着这些洞察一起复盘、展开对话。
👱♂️ Lenny
所以这是一种**管理手法：**交付产品的同时，能更清楚团队产出的实际影响？
👩💻 Fiona
没错。除了”提交”这个动作本身，还要看它在市场上表现如何、有没有抓到一些 bug。
我有句话叫 make new mistakes（要犯，就犯新的错）。犯错没关系，但要犯新错，这样我们才一直在学。如果你追求零失误，那多半说明你行动不够快、或者太过谨慎了。
有了 Claude，我还能让它横着看一遍：比如”综合这些线上事故，能不能提炼出一个共同主题？接下来在质量上哪块最值得投入？哪里藏着我们忽略的隐患热点？“放在一年前，这些几乎全是手工活，我根本拿不到这种洞察。
👱♂️ Lenny
除了这个，还有什么方法能帮你和团队既能跟上进度，又能确保质量？
👩💻 Fiona
反馈渠道对我们很重要。以前我每天早上的仪式是：端杯咖啡，扫一遍反馈频道，有空就挑一个缺口去补。一两个月前上线 Routines 后这件事彻底变了——我设好一个 Routine，它每天早上自动盯反馈、归纳主题，等我醒来，一份总结、甚至几个能直接审的 PR 就摆在那儿了。
👱♂️ Lenny
反馈都从哪来？邮件、Twitter，还是各种来源混在一起？
👩💻 Fiona
内部很多，也有各种外部反馈，朋友私信、LinkedIn、社媒，我们都会转发到 Slack 里，当然还有合作方。我们给不同来源建了不同频道，正因为量这么大，我才需要 Claude 帮我跟上。
从写到验，再到盯质量
👱♂️ Lenny
代码审查显然也是个大挑战。Claude 现在也有自己的自动代码评审（Code Review），这块你最近摸出什么新门道了吗？
👩💻 Fiona
说出来挺疯狂的，去年我们连 Claude 的自动代码评审都还没有。所以说到瓶颈，人工评审当时就是一个非常大的瓶颈。对那些需要深度专业判断的关键领域，我们当然还是要确保有合适的人来审。
但真正帮到我们的是：**越能把”什么算好”沉淀成一个框架，自动化就越能发力。**当你给 Claude 一个”what good looks like（什么样才算好）“的框架去对照验证时，它往往表现得非常出色。
我们最近就把内容设计规范（按钮文案、报错措辞、语气调性这些 UX writing 标准）写成一个 Skill 放进了代码库。所以只要你有 Spec（规范文档），把它 check 进仓库、和代码放在一起、并让规范随代码一起更新，Claude 的代码评审每次就能拿”最新的标准”去比对产出还合不合规。
👱♂️ Lenny
本质上这有点像**测试驱动开发（TDD）**的一种演进。
👩💻 Fiona
对。TDD 在 2000 年代很火：先写测试 → 跑一遍确认它失败（红）→ 再写代码让它通过（绿）。原理无可挑剔，但我自己当年挺挣扎的，那感觉像”得先把西兰花吃了”，可我想赶紧上手做产品、享受发布的快感。
有意思的是，我在 Claude Code 上修的第一个 bug，就是跟 Claude 说：“我想做 TDD，帮我先写测试、确认它失败，再做修复、让测试通过。”
以前测试生成是我不得不交的一笔”税”，现在它自动化了，那些老掉牙的工程原则（TDD、Spec、Skills）反而可能更高效，因为模型能替你扛更多活。
👱♂️ Lenny
那产出量这么大，怎么还能盯住质量？
👩💻 Fiona
我们特别想做好、也还在打磨的是主动质量（proactive quality），越早发现问题越好。
我起了个很简单的框架，叫 bad & sad：bad 是很糟糕且不可恢复的错误（比如 CLI 崩了活丢了）；sad 是难受但还能恢复的痛点（比如界面闪烁）。有意思的是，一堆 sad 叠加，往往就会演变成 bad。
这里也提一下 agency：每个团队自己定义，在自己负责的产品面里什么算 bad、什么算 sad，以及要冲的目标是什么。
👱♂️ Lenny
我听下来，盯质量最好的工具其实是监控和测试，而不是花更多时间人工 review——相当于给 agent 闭环：它知道什么叫成功，就能自己发现、自己修。
👩💻 Fiona
对，我们正是往这个方向走的。质量越能往”早发现、自动捕获”上推，就越不用靠人一行行去 review。
别把”动起来”当成”有进展”
👱♂️ Lenny
最近有个明显的氛围转变：从 token maxing（把用量拉满），转向”我们到底拿到了什么、ROI 如何”。Boris 在 Meta 时就是做工程效能的，关于怎么衡量 AI 带来的生产力提升，一直有争论。你怎么看？
👩💻 Fiona
一开始我们也想过用”代码行数”，但很快就有争议：某人代码行数爆表，结果只是把一个库搬过来 check 进去；那要不要算”有效代码行数”？可要是更新框架、生成的代码更少、产出却一样呢？是不是该看”PR 落地的时间”？
绕来绕去我的结论是：先看产出有没有真的指向结果。
Don’t forsake motion for progress. 别拿”忙碌”冒充”进展”。只盯工具用量，你量的是”动作”，可它真的让你想要的那个结果发生了吗？
我举个例子：Facebook Marketplace 早期按地区逐个上线，当时盯的指标是”卖家数量”。第一个地区上线后我发现，卖家数量不高，但买家真能找到想要的东西，那个地区卖家不多，却有一批”超级卖家”，而买家能找到东西，才是我们真正要的。
所以无论衡量生产力还是产品，都要常回头看一眼：这个指标，还在为你真正的目标服务吗？环境变得太快，指标本身也得跟着改。
会做梦的产品型 builder 和啃硬骨头的系统专家
👱♂️ Lenny
说到 builder，你演讲里我最喜欢的一页是讲你招什么样的人。你说现在主要找两类：1）有产品 sense 的创意型 builder；2）能搞定最难部分的深度系统专家。
👩💻 Fiona
对，先说深度专业那类。
我刚到 Claude Code 时，团队有很棒的产品型通才，但我发现缺有系统背景的人，尤其是分布式系统这块。原则是 trust but verify——模型确实很强，但很多地方仍然需要验证，凡是需要深度专业把关的地方，就值得继续投这类人。
另一类是产品型的 dreamer：对产品有热情，有个想法就把它端到端做出来，再看反馈、迭代、打磨，把体验做到好用。这种”从想法到上线一肩挑”的人，在 Claude Code 上帮了我们大忙。
👱♂️ Lenny
特别有共鸣，我脑子里冒出来的词是野心（ambition）。前两天我跟一个 10x 工程师聊，他说有人提了个功能想法，放以前他会觉得”太难太复杂”，现在的反应是”这完全可能啊，我让 Claude Code 去做，它就做出来了”。
所以现在命题变成了你能有多大野心。理论上一切皆有可能，关键是你敢想多大。
👩💻 Fiona
对。我昨天还跟一个工程师聊，他不是移动端出身，但我们有个功能急需做移动端。他说”多亏了 Claude，我现在真能在移动端上做这件事”。哪怕你不是 Android 专家，现在也有个搭档帮你搞定，Claude 把每个人能力的天花板都抬高了。
拉开差距的是成长型心态，把人挡在门外的是恐惧
👱♂️ Lenny
那我顺着这条线问：随着角色的转变，有人如鱼得水，有人却很沮丧、抵触。那些适应得很好的工程师，身上都有哪些共同点？
👩💻 Fiona
成长型思维真的特别管用，实际上在 AI 工具出现之前我就有这个体会。它的核心是永远带着好奇心去学，并承认：过去让你成功的东西，未来不一定还管用。
至于沮丧，我有时还看到一点恐惧。
沮丧常常来自恐惧，来自“觉得一切都不受我控制、这事是冲我来的”。如果你换个角度想：**这事不是”冲我发生”（happening to me），而是”为我而发生”（happening for me），那我能改变点什么？**这会很有帮助。
讲个我自己的经历。
高中时我想当视觉艺术家，那会儿电脑很贵，但学校有门打字课，下一门才是 HTML 编程。我爱上编程的原因和爱艺术一样：有个想法，就能去创作、讲一个故事。
但我当时有个更大的恐惧是“该怎么负担起工程学校的学费？” 我在安大略省长大，知道有个 OSAP（安大略省学生助学计划），但不知道能覆盖多少学费。我就想”那我现在能做点什么？“，碰巧加拿大国家银行在我们高中贴了张传单，招高中实习生当银行柜员，虽然是最低工资，但我觉得那是根救命稻草。
好笑的是，我高中最讨厌的课就是会计，但我还是报了名，整个夏天上班攒钱，之后周一到周五上学、周六去当柜员，一干就是两年。这是我当时唯一能抓住、又在我掌控之内的行动，用来对抗”可能根本读不起书”的恐惧。
所以我另外两句很爱的话是：“如果你不害怕，你会去做什么？” 以及 “时不时去做一件让你害怕的事。”
当你在擅长的事上做到极致、处于效率峰值时，怎么继续成长？就是去做一件以前没做过、会让你害怕的事。你会经历一段下坡，因为得重新学，但成长就是这么来的。
👱♂️ Lenny
我在这档播客里用得最多的一句话是：
The cave you fear contains the treasure you seek. 你所畏惧的洞穴中，藏着你追寻的宝藏。
👩💻 Fiona
很酷，我要把它抄下来。
用户绕路的地方就是下一个产品
👱♂️ Lenny
Anthropic 总能比别人更早发现更大的机会——编码、Cowork、对模型人格的重视都很早。你觉得团队是做对了什么，能在别的 labs 之前发现这些机会、还敢于押注？
👩💻 Fiona
别的 labs 我没待过，但我们很关注**潜在需求（latent demand）：**编码这个用例我们自己就是第一批用户，反馈很快；后来又注意到很多非程序员在用 Claude Code，于是想把那段体验做得更好，这才有了 Cowork。我自己对小微企业也一直有兴趣，走访过几家后，团队真的做出了打包好的 Claude for Small Business。
📹 此处为视频内容（vid: wxv_4579083026927632387）（上图为封面），未能直接提取，请前往原文查看：在公众号原文中观看
所以我的建议是除了把自己的产品持续打磨好，也要留意那些你没预料到、正冒头的新用法。
软件里有一条铁律：用户一定会用你没设计过的方式来用你的产品，有好有坏；当你看到有人为了跑通一件事各种绕的时候，那往往就是下一个该做顺的体验。
Routines 比定时任务多了一颗脑子
👱♂️ Lenny
工程的下一个前沿你怎么看？是 agent 舰队（fleets of agents），还是别的？
👩💻 Fiona
我们在往**异步（async）**走。以前我是同步发一个 prompt、最多手动开几个并行的；现在我能用一个 Routine 来替我生成这些 prompt，抽象的层级一直在往上抬。
👱♂️ Lenny
帮我们搞清楚 Routines 到底是什么。
👩💻 Fiona
简单来说，就是把我那些每天手动重复的事，做成一个定时自动跑的例程。
📹 此处为视频内容（vid: wxv_4579084641147846658）（上图为封面），未能直接提取，请前往原文查看：在公众号原文中观看
👱♂️ Lenny
有点像 cron job（定时任务）。
👩💻 Fiona
对，但它能真的替你把 agent 派出去。
以前 cron job 也能自动化，但现在是”看看这些反馈，如果有 bug，有哪些能顺手修掉的？“，它就去开 agent，等我醒来，手上已经有一批 PR 可以审了。
以前是 AI 把不同 agent 跑完，我还得自己想”拿到这些信息接下来该干嘛”；现在是我写一个 routine，让它替我生成派发不同 agent 的 prompt，相当于在 cron job 上多了一颗脑子。
我们会越来越往这种异步的方式走。
👱♂️ Lenny
所以作为管理者，你每天要做的那些事——项目进展如何、谁掉队了、该疏通什么、哪里还能再打磨——都能写成 prompt，让 Claude 每天替你做，再把”我做了什么、有什么可审”摆给你看。
👩💻 Fiona
然后再给它更多自主权，比如验证做得很好的地方，就跟它说”放手去做”。
👱♂️ Lenny
这让我想起 Tyler Cowen 一个很棒的演讲。他说这个时代做得最好的人，关键词是 initiative（主动出击），也有人叫 agency（自主性）。
👩💻 Fiona
我超爱 agency 这个词，它正是 Claude Code 和 Cowork 团队最看重的。但我们总把它和”high”连在一起说：一个问题摆出来，团队每个人都有自己的解法，这就是 high agency。
而 high agency，我们会配上 **high accountability（高担当）：**给大家放手去做的自由（freedom to cook），但也要问清楚“这事谁负责、你想验证的假设是什么？”
就像一枚硬币的正反两面，对我们团队特别管用。
管理者要先当 IC，并一直活在产品里
👱♂️ Lenny
回到你怎么带团队。我听说你推行了几个挺独特的做法，其中一个是：每位管理者都得从 IC 做起，当上管理者之后还要继续兼职当 IC（个人贡献者），一种”球员兼教练”的打法。
为什么这在今天这么重要？
👩💻 Fiona
作为 leader，如果你先从 IC 做起，给自己动手时间去钻代码、把代码库和产品摸透，会特别值。我自己做 PR，重点不在我修了什么，而在于借此每天用产品、保持手感，因为 Cowork 和 Claude Code 更新得太快了。
如果你不是每天都在亲身用自己的产品，你会慢慢失去对它的手感。
让新来的管理者先扎进去当工程师，他们和团队建立的默契会好很多。否则管理者一来就想”我得管理啊”，然后做各种管理动作，可你要是先踏实体会一把”在这个团队当工程师是什么感觉”，反而更能赢得信任。
我加入过的每个团队（VR、智能眼镜、Instagram），最先收到的一句反馈往往都是”我真的很喜欢你居然在用我们造的东西”。我在 Meta 也是以管理者身份面试进去的，但头一个季度同时做 IC，因为工具、代码库、语言全是新的。
我上一次发布生产软件大概是 2017 年，之后很久没碰，但我在 Claude 上的第一周，本想走老路去约每个工程师喝杯咖啡，转念一想”先问问 Claude 吧”。于是它成了我很棒的入职伙伴：帮我做自动化测试，我想手动测，它就帮我想清楚怎么覆盖所有情况。
👱♂️ Lenny
我跟很多和你共事的人聊过，提得最多的就是你对 **living and breathing the product（活在产品里、亲自用产品、dogfooding）**的痴迷。为什么这么重要？
👩💻 Fiona
做产品总有个梦想，就是你希望成全某种体验或把它变得更好，dogfooding 让我更接近这种触感。我还在 Meta VR/AR 团队时，常因为自己摆设备的方式，发现一些很奇怪的地面高度 bug，等于无意中拿到了一个绝佳的复现环境。
其次，这常常也是我最能帮到团队的方式。我带 VR 团队时一直没往那个代码库提交过代码，怕搞砸操作系统，但我们在做大量打磨修复，我就说”那我用 dogfooding 的时间帮你们把体验过一遍、验一验”。这既守住了质量线，团队成员通常也很领情。
除了指标，每个人其实都想确认”我的工作是有意义的”，看到 leader 在用自己造的产品，大家会更有归属感。
👱♂️ Lenny
这点很重要，总有”个例 vs 数据”之争，而你说的是，作为产品和工程的 leader，你从那些具体的、一次性的亲身个例里反而收获了很多。
👩💻 Fiona
对。如果你带的团队实在很难亲自用它的产品，那就去见客户，总之找到那条”贴近真实使用”的路。
Facebook Marketplace 要进拉美时，我们在智利测试，数据一直不如别的地区。后来我们三个人做了次很小的实地调研，一落地我打开当地的 Android 手机就明白了：LTE 网络比美国慢太多，Marketplace 的信息流在弱网下根本加载不出来。连页面都打不开，这是多大的增长障碍。
所以才说，永远要听客户反馈、保持快速反馈闭环。
👱♂️ Lenny
我记得是 Jeff Bezos 说过：**如果数据和个例打架，意外的话，要相信个例。**这就是个很好的例子。
角色都在融合，但有些东西得守住
👱♂️ Lenny
你管的这支团队，恰恰是最改变工程师这份职业的团队，这本身就很套娃。那我沿着这条线问：你担不担心工程师因为不再亲手写代码，其编码能力会退化？这件事在你看来重要吗？
👩💻 Fiona
我们团队内部还真讨论过这个。
像 Boris，早期是手写代码的，现在不写了，但他那种工程思维是从代码库里挣来的。所以对加入的工程师我会说：你做每件事时，还是要花时间去理解架构和这次改动，这又回到 trust but verify。
也许有一天这不重要了，但以现在的节奏，我仍然建议**要往下去深挖一层、去看清你依赖的那一层。**这样依赖一变，你更清楚，也不会错过它带来的新能力。
👱♂️ Lenny
工程之外，Anthropic 内部第二个被改变最多的角色是什么？
👩💻 Fiona
所有与代码相关（coding-adjacent）的角色都在变。
你也跟 Cat Wu 聊过，PM 变了很多，有了想法不再被工程带宽卡住，我们的 PM 还真帮我们改过一些工程没空做的功能。接下来是设计、数据科学，这些都是我们下一步值得改善体验的领域。
现在大多数 commit 都是 Claude 辅助的，这是个转变，让工程师锻炼出更强的产品 sense 这块肌肉很重要。那些传统上非工程的活儿，现在也常由工程师顺手做了，因为不再干等一个跨职能伙伴来解锁，模型补上了你本来不具备的能力。
👱♂️ Lenny
所以是双向奔赴：工程师变得更产品导向、对产品的成败负责，同时其他人也越来越像工程师。
👩💻 Fiona
对，全都在融合。
👱♂️ Lenny
那深度专家还要吗？你演讲里也留过一个没解的题：还需不需要分开的 iOS 和 Android 组织团队？
👩💻 Fiona
我们仍然觉得引进这类深度专家很重要，只是不需要那么大规模了，因为大家都在灵活补位（flexing）。所以 Android、iOS 专家还是要有，但那种很大的移动端组就不需要了。只是”够不够、对不对”这个平衡，我们还在摸。
👱♂️ Lenny
还有个我特别想听你答的：AI 照说该让工程师变得没那么必需，可你们、OpenAI 都在疯狂招工程师，需求也很大。你觉得这会往哪走？
👩💻 Fiona
你我走上工程这条路的方式，和现在太不一样了。
现在的人一毕业，怎么快速落位、同时还真正理解我说的”往下深挖一层”？我在想，软件工程会不会更像师徒制（fellowship）。我们当然也有实习，但那是三个月的小项目，我们这代人靠多年攒下的经验和直觉，到底该怎么传给下一代 builder？这是我一直思考的问题。
👱♂️ Lenny
对，如果你永远不用看代码，一个新工程师还有什么动力去真正搞懂基础设施、内存分配这些底层的东西？
👩💻 Fiona
也许模型会好到那一步，让这一切不再要紧。但我还是觉得”往下深挖一层”有是价值的，改进产品或系统的机会，往往就藏在那一层。只是怎么学会它，未必还要靠敲很多年代码。
我有个很早的经理，入行时还在用打孔卡（punch cards），现在天天给我发他用 Claude Code 做的东西，多精彩的一段职业生涯。从打孔卡到现在，他经历的变化也是天翻地覆。
所以也许我们该想的是：什么会一直重要、什么的重要性会变，以及怎么在那件真正重要的事上练出本事。
👱♂️ Lenny
我常听到的论点是：这就是又一层新的抽象，像从二进制到汇编一路往上。现在我们不用看代码了，prompt 和 Claude 的思考过程本身就是新的一层。
👩💻 Fiona
而且变化速度太快了。我记得大概是 Sonnet 3.5 或 3.6 那会儿，它还会犯些错，有些抵触 AI 工具的工程师就说”你看，这不行吧”。
但难的是理解那种指数级的进步：我有些曾经自动化失败的东西，到下一个模型就够好了。所以也要常想：那些当时没跑通的事，过段时间值得回来再试一次，因为现在它可能已经是一项新能力了。
👱♂️ Lenny
去做一件”几乎能用、卡在能力边缘”的事，等模型一旦跨过去，你就会遥遥领先。
我自己当过 10 年工程师，最爽的就是进入心流写代码，看着它编译通过、跑起来。但现在你不这么干了，只是坐着等 agent 把东西造出来。
在这个新世界里，工程师还失去了什么？
👩💻 Fiona
我刚跟一个工程师聊过心流。以前碰到一个特别棘手的问题，音乐一放、整个人进到 zone 里，最后总有个”终于破解了”的顿悟时刻。现在快乐更多来自产品本身，但也确实有人说”我以前最享受的，恰恰是那些最难啃的部分”。
还有一个现象：大家越来越只和自己的 agent 干活，慢慢变得孤独。所以我们搞了结对编程，也办过几期黑客松，每个人用 Claude Code、Cowork 的方式都不一样，凑在一起反而学到很多。
Fiona 提到的黑客松，最近就有个很具体的例子。
在「Built with Opus 4.7」Claude Code 黑客松上拿到第一名的，是医生出身的工程师 Bedirhan Keskin。他做了一个专门给医学生、住院医师练手的虚拟门诊 Medkit：你对模拟病人问诊、开化验、读影像、下诊断、开处方，最后由一个 agent 对照真实临床指南，像主考官那样给你打分。
他几乎全程只用语音，在四个并行的 Claude Code 会话里搭了语音引擎、内容生成、3D 游戏层和核心应用，各自上下文干净且同时推进。如今已有三家医学院和一家药企准备试点。
📹 此处为视频内容（vid: wxv_4579091743496994816）（上图为封面），未能直接提取，请前往原文查看：在公众号原文中观看
他给其他 builder 的建议是：
Work with Claude as a thought partner, not just a coding agent. 把 Claude 当作思想搭档，而不只是写代码的 agent。
这正是 Fiona 口中 AI-pilled builder 在做的事——有了一个想法，先和 Claude Code 讨论，再把它变成能落地的产品。
砍掉没用的流程：JIT 即时规划
👩💻 Fiona
我们团队有条很看重的做法，是明确允许砍掉那些不再为我们服务的流程。
给在带团队的人一个建议：挑一件你最怵、最吵、最贵、或最手工的流程，先问它一句”还有存在的意义吗”。比如规划，我刚到 Claude Code 时还想”要不做个六个月路线图，但要超轻量”。
那次练习对启动对话、对齐方向确实有用，可三个月后我就发现”等等，我们还回头看过它吗”，因为变化太多了。
👱♂️ Lenny
那你现在怎么做规划？
👩💻 Fiona
我管它叫 JIT 规划（just-in-time，即时规划）。
六个月太长了，现在只做月度规划，超轻量，甚至没有文档，就是一张小表格，对齐我们认为重要的事；每周再快速确认一遍”这还是不是这个月的优先级”。我还在想怎么把这一步也自动化，因为我从不想让谁觉得“更新表格”是种负担。
因此，给定优先级后就回到 agency，每个人自己决定怎么推进；每六个月把全团队聚一次定大主题，但环境一变，这些主题也会很快过时。
写在最后
听完这场近两个小时的对话，你会发现对于某些问题—— iOS 和 Android 还要不要分家、自动评审能推行得多彻底、角色边界模糊后怎么让每个人都同样高产、这代人攒下的经验又怎么传给下一代 builder…… Fiona 几乎没给出标准答案。
但过去让你成功的，未必还能带你往前。
所以面对变化，她先问”哪些在我掌控之内”，再迎着恐惧去做那件让自己害怕的事；面对流程，定期问一句”它还在发挥作用吗”，不再有用就果断砍掉；面对手里的活，把能自动化的交给 Claude，把省下来的力气留给那些只有人能做的判断与连接。
写代码正在退出瓶颈的位置，工程师这份职业也在被重新定义。
真正带你穿越周期的，是保持成长型心态、盯住真实反馈以及亲手用自己的产品。
十字路口正在寻找独立撰稿人，撰写 AI 产品和模型评测。
如果你写过类似文章：《实测 PixVerse C1[1]》、《实测 LibTV[2]》，请联系 zeo0811@gmail.com ，邮件内容请包括：① 个人介绍、② 你写过的 AI 评测文章。
我们会提供有竞争力的稿酬。期待与你一起观察与记录 AI 时代 🎪
内容效果不满意？点此反馈