这个世界会变得 AI coding 肆虐，Claude Code 应该是“罪魁祸首”。

Anthropic 的Fiona Fung 在最近的播客里说，她如今关注点在代码生产力被解决之后，引发的一系列组织管理新问题上。

2024年年中，Anthropic 发布 Claude3.5，软件开发开始进入由人定义目标、AI 大规模生成代码的时代。

随着 Claude Code、Cursor 等agentic coding工具走向成熟，软件开发开始进入由人定义目标、AI 大规模生成代码的时代。

此刻，全球新产生的代码中，约 20%-42% 已经由 AI 生成或辅助完成。换算成最近大家关心的“AI替代人类员工”的问题，也就是说有1/3的开发者是AI了。

不过，AI参与代码生产的比例提高是真实的，代码质量指标全面恶化也是真实的。

今年3月的一项研究报告给大家泼了冷水，在 30 多万个 AI 生成/参与的代码提交中，研究者累计发现了 48 万多个被这些提交引入的代码质量问题，你以为请了个 24 小时无休的 AI 助手，实际上它每干一次活，都附赠了 1.5 个潜伏问题。

其中，九成是 code smells（虽然能跑、但写得极不规范的垃圾代码）。

所以，AI代码的治理成了系统问题。到了今年6月，GitLab 发布的《AI问责报告》则显示，已经有近九成受访企业开始或计划未来一年内为 AI 代码治理分配预算。

这之外，更关键的是整个软件工程系统的重心迁移。

工程师的角色从过去的码农变成了验证代码是否正确；管理者的责任也从分配任务转向定义标准；更深层次的是组织文化也需顺势而变：怎么确保团队在这样高速迭代的状态中，还能保持步调一致的产品理解和质量标准？

最近，Fiona Fung 登上了 Lenny’s Podcast。她所在的 Anthropic，几乎可以说是 AI coding 圈的“耶路撒冷”；而她本人，正是 Claude Code 与 Cowork 的工程和产品负责人。她参与构建了这次 AI coding 变革，也正在积极解决这些新问题。

在加入 Anthropic 之前，她在微软工作 11 年，参与主流开发工具 Visual Studio 以及工程级编程语言 TypeScript 的构建。随后加入 Meta，主导 Facebook Marketplace（如今 GMV 超过 1000 亿美元）的早期建设，并参与智能眼镜与 AR 产品研发，在 Instagram 负责基础设施、增长与安全体系。算下来，Fiona 已经拥有 25 年以上的工程经验。

她一直聚焦在产品、工程与组织规模化上，并且同时站在几条不同的软件时代路径上。

她见过前 AI 时代，她知道过去没有 AI 的世界里，软件是怎么造出来的，这是年轻工程师的经验盲区。

她也正在构建AI 时代的基础设施。她既是被改变者，也是改变者。这种双重视角，让她能同时看到工具的使用体验和工具的深远影响。

她管理着大规模的组织，这更让她有系统视角——工具如何改变人、团队如何重新分工、组织如何重新定义边界。

正因为这种交叉位置，她能看到结构迁移本身，并在访谈中分享了她是如何应对这些变化的：

对个人来说，现在的岗位边界已经开始模糊，所有人都要变成 Builder。

对团队来说，需要重新拉齐一套新的产品理解和质量标准共识，用来判断什么是“好”，以及什么是“不能退让的坏”。

而对管理者来说，变化更加彻底。工程管理必须重新回到一线参与判断——因为在 AI 放大不确定性的环境里，文化与责任感成为唯一还能稳定系统输出的锚点，而管理者本身，也正在从监督者变回参与者。

全文由《非标玩家UnDefined》团队听译、校核、增补背景数据，非简单机翻。不管你是工程师、团队 leader、还是企业主，又或是对AI软件工程感兴趣的anyone，相信你都能有所收获。

编码是盐：无处不在，但已不是主菜

Claude Code之父Boris Cherny 有一句很形象的说法：编码是盐。

盐很重要，但你在评价一道菜时，不会说这道菜有盐。因为它已经变成了隐形的、基础性的存在。

代码也一样，它是必需品，但不再是稀缺品。如今编码这个动作本身，已被自动化和商品化。

Lenny 在播客里中提到，“Anthropic 工程师平均每季度提交的代码量是 2025 年的 8 倍。人们可能忘了，不久前 100% 的代码还是由人类编写的，而现在正趋向于 100% 由 AI 编写。”Lenny 形容那张图时说，“突然拐了一个近乎垂直的角度”。

更关键的是，Fiona 说她今年还没亲手写过一行代码，但每天能在手机上提交几十个 PR（Pull Request）。

放在几年前，这会显得不可思议，但今天它已经变成默认状态。

工程师的职责开始上移，从写代码，变成定义目标、组织上下文、调度 Agent、审查结果，以及最终做判断。

类似迁移并不是第一次发生。

Fiona 早年在 IBM 做 DB2（企业级关系型数据库），用的是 Vim （文本编辑器）和命令行环境。后来加入微软 Visual Studio 团队时，她甚至一开始并不理解 IDE（集成开发环境）的意义，还以为只是一个更复杂的编辑器。

但后来她意识到，IDE 做的事情从来不是帮你少写几行代码，而是把开发从“写一行代码”变成“在一个系统里完成开发”。

再往后，软件从本地持续交付（CD）变成在线发布，又发生了一次抽象层上移。

过去发版需要刻盘、运输、上架，所以流程极重，节奏很慢。在线化之后，交付成本下降，迭代速度提升，组织方式随之重写。

现在轮到 Claude Code 和 Cowork 这一层。

过去软件工程最稀缺的是工程产能，所以组织围绕写代码的人展开设计。

现在软件团队的竞争力取决于组织系统的控制能力——目标怎么定义、上下文怎么组织、Agent 怎么调度、结果怎么验证，以及最终谁来承担责任。

瓶颈转移了：从写代码，到验证问题，到成为builder

AI 编程工具变强后，很多工程师都尝过轻松开发软件的甜头，现在他们中的不少人开始吃苦头了。

Fiona 团队也没逃过，她在访谈中说：“当吞吐量是原来的 8 倍时，我们如何确保这些东西是对的？以前我们花大量时间写代码，现在必须花更多时间验证（代码是否真的正确、稳定、有价值）。”

被放大的只有提交频率、实验速度和代码生成速度，可人的注意力没有被同步放大。

最近在开发者社区中被热议的一起AI删库事件，发生在一套基于 Cursor 与 Claude 的编码代理系统中。一个看似普通的开发任务，最终演变为生产数据库与备份被同时删除的事故。整个过程只用了不到10秒，丝滑到更像是一次自动化执行的正常路径。

AI 无需为此承担责任，它只是放大了错误的速度，但同时也放大了人的价值——验证。

motion is not progress（动作不等于进展，产出不等于结果）。

在Anthropic，Fiona 团队是怎么做验证的？

第一，验证前置，用测试驱动开发。

她提到自己在 Claude Code 上修的第一个 bug，是让 Claude 帮她做 TDD（测试驱动开发），确保测试失败，然后再修复问题，最后让测试通过。

工程师普遍不爱写测试，它们消耗时间和精力，不像构建产品和Shipping（发货）时那样让人有成就感。Fiona形容这种感觉就像在“交税”——没有直接产出，却又必不可少。

现在她不再“缴税”，她只需要对 Claude 说“帮我写测试”，AI 就立刻把那段枯燥、强制性、没有直接产品价值的代码写好了。

AI让老流程跑出了新体验，这就是验证前置。

它不是让测试变轻了，而是让测试从成本中心变成 AI 工作流的护栏。没有验证前置，AI 不只会更快生成代码，也会更快生成技术债。

第二，从组织层面建立统一的质量语言和标准，来把“什么是好的”落到实处。

Fiona 还分享了他们团队使用的质量框架，叫bad（坏）vs sad（伤心）。“坏”是不可恢复的问题，比如崩溃、丢失工作、打断关键流程；“伤心”是可恢复但让人不舒服的小痛点，比如闪烁、卡顿、对话中断、体验别扭。

很多产品并不是被一次 bad 杀死的，而是被无数个 sad 慢慢拖垮的。

他们甚至做过一个仪表盘，统计用户在使用 Claude Code 时骂脏话的频率。

骂脏话，代表用户“sad”了。一个功能在技术上可能完全正确，但在真实使用中，体验可能会非常糟糕，而人的情绪又是很难被传统评估体系捕捉和判定的。

bad 和 sad 就像一套内部语言，让 Fiona 团队在高速交付中快速对齐什么是好的、什么是严重的、什么是急需处理的，将主观感受变成可讨论的共识，让验证相对有据可循。

但她也提到，他们每个团队都拥有高自主权，自己定义什么是坏、什么是伤心，以及每个团队想要达到的目标。

第三，让AI化解争论。

在一次 API refactor 的讨论中，Fiona分享了一个实际案例。

有次她和同事在方案上有分歧，如果按照传统方式，这会变成长时间的技术争论，但很快她换了一种方式来解决问题：既然构建成本已经下降，为什么不直接让 Claude 生成几个可运行的方案？于是系统一次性生成了三个 competing PR。

分歧于职场来说是再正常不过的，用 Agent 具象化方案差异，正是 Fiona 团队在验证过程中用的小方法。

她后来总结了一句话：When building is cheap, arguing is expensive（当构建变便宜，争论就变贵了）。

在对谈中，Fiona 承认目前对于“如何定义理想体验、如何定义问题的验证标准”仍然是个难题，他们还在思考。

“这是也未来最大的（商业）机会”，Fiona说。

当定义问题、验证结果、驾驭 Agent成为核心能力之后，岗位边界开始模糊，最终所有人被迫变成 Builder 。

在 Claude Code 团队里，不只是工程师提交代码，PM、设计师，甚至原本不属于传统工程岗位的人，都开始进入代码工作流，所有核心角色都要具备把想法推进到可验证产物的能力。

在《非标玩家UnDefined》之前的一篇文章中，我们也讨论过类似的问题：在 Agent 时代，全栈能力和单一能力之间的价值差距正在被拉大。

有一些数据也在指向同一个方向：GPT-4 发布后，22-25 岁年轻人在高 AI 暴露岗位的就业率出现下降，而资深岗位反而在增长。

这并不难理解。入门级工作正在被 AI 吸收，原本用来建立经验的路径被压缩，新人反而更难进入真实的工作系统。就像 Fiona 提到的担忧：“如果新人从来不写底层代码，他们如何建立系统理解力？”

但这只是问题的一面。

另一面，是那些正在被市场疯抢的 AI-native 年轻人。到 2026 年，头部校招生拿到 100–200 万现金年包已经不罕见，极少数甚至可以达到 300 万以上；一些核心团队的实习薪资也已经被拉到 3000–5000 元/天。

同样是年轻人，差异为什么会被拉开？

本质不是“年轻”，而是企业在筛选一种能力：是否能在 AI-native 的新范式下直接理解产品并参与构建。这种能力往往在天才年轻人的过往经验中得到了验证。

Fiona 提到他们团队现在只招两类人：有产品 sense 的创造性构建者和深度系统专家。前者知道什么值得做（这里就包括天才年轻人），后者知道如何为复杂问题兜底。

这看起来有点反直觉：资深岗位需求在增加？

现实中，职场的“35岁分水岭”似乎正在提前，很多资深职场人开始被边缘化，甚至失去机会。

其实问题的关键不在年龄。

对很多资深职场人来说，过去积累的底层知识和经验并没有失效，只是被重新定价了。AI 改变的，是经验发挥作用的方式；放大的，是不同层级之间的优势差异。

Fiona 以团队中技术大牛 Boris 为例介绍了深度系统专家的价值：在 AI 普及之前，他亲手写了大量底层代码。正因为有过那段徒手搬砖的经历，他对系统底层逻辑有深刻理解。这种理解现在依然在发挥作用——即使他已经不再手动写代码了，他的判断力、架构设计能力，依然是团队的核心资产。

说到底，经验的价值正在从做得更快，转向在不确定条件下做出更少错误的判断，和从最开始就作对的判断。

对于资深职场人来说，优势就是在复杂系统中识别风险、约束边界，以及在信息不完整时做出更稳的取舍。

资深职场人之间的不同，是能否在当下快速用AI重构自己，他们必须完成从经验驱动到AI协同决策的转变，否则经验本身可能会失去效率优势。

当入门级任务变少，年轻人入职后要如何积累工作经验？这也是组织重新设计学习机制的问题。

Gartner 的一份研究或许给组织提供了设计方向：在 AI 的影响下，高级与初级开发者之间的能力差距正在被放大，团队需要通过结构化的培训、导师制以及同行学习机制，重新建立成长路径。

FIona 在访谈中也提到类似的想法，她说：“我怀疑可能需要重新引入学徒制。”

管理者要重回一线

重回一线，但不是回到过去那种“盯进度、开评审会”的管理方式，而是把自己嵌入产品和系统的反馈循环里。

Fiona 提醒，如果管理者仍然只通过周报、会议和仪表盘等汇报机制来理解团队和项目，那他看到的很可能是一个被延迟过的现实——信息是被汇总过的，状态是被筛选过的，而系统本身早已经发生了变化。

Fiona 一直强调一件事：管理者要dogfooding（“吃狗粮”）。

在 Claude Code 里，她会自己用产品写代码、审 PR、处理反馈；在 Cowork 里，她会直接用 Agent 协作完成工作流。

因为只有在真实使用中，才会知道哪里顺、哪里卡、哪里其实在悄悄制造摩擦。

这个习惯她很早就有。在 Visual Studio 团队时，他们用 Visual Studio editor 开发 Visual Studio editor，在那个没有社交媒体快速反馈的年代，团队依然能形成快速反馈循环，就是因为他们自己天天在用。

后来在 Facebook Marketplace时，她曾把一台 MacBook Air 放在平台上卖，结果刚上架就就遇到一种之前没发现的新诈骗方式。这个经历让她深刻体会到，用户总会以意想不到的方式使用产品。产品数据未必会第一时间告诉你这种事，但你亲自使用就会撞上。

还有她在 Meta 时，团队想向拉美市场推出 Facebook Marketplace。出发前，数据看起来还行。但她亲自带团队去智利，打开当地手机发现 LTE 网络比美国慢得多，Marketplace 首页根本加载不出来。

如果只看数据，他们可能永远发现不了这个致命问题。而“吃狗粮”——亲自在当地用产品——让他们立刻找到了真正的增长阻碍。

所以吃狗粮是管理者保持产品触感的方法。

Fiona 现在大量使用 Claude Routines：每天早上 7 点，查看产品反馈渠道和代码仓库，总结出 Bug 热点和值得审查的 PR。当她早上醒来，就会直接收到报告和 PR，而不是守着屏幕等。

AI时代的日不落，已经脱离时区依赖，转为对Agent的持续运行能力的依赖。

孤独是AI超级个体的影子

你可能正在切身体会着职场里人与人之间的协作越来越少。

Fiona 进一步指出，过了一段时间，我们可能会觉得这成为一种孤独的体验，因为我们都和我们的智能体一起工作太久了。

过去，工作是人与人之间的协作：讨论方案、一起 debug、review 代码、反复争论取舍。

这些过程慢，但它们在不断建立一个隐性的东西——共享语境。

而现在，这个过程正在被拆解。越来越多的协作，被重新映射成“个人 + Agent”的结构：一个人对话模型，一个人调度工具，一个人完成原本需要多人完成的链路。

结果是，能力变强了，但连接变弱了。

每个人都有自己的 prompt、自己的工作流、自己的上下文系统。看起来团队产出在提升，但团队之间共同理解世界的方式正在减少。

孤独，是 AI 超级个体的影子。

当技术和流程都变了，如何让新同事快速融入并跟上团队，如何让团队在高速变化中保持一致性，就成了难题。

Fiona的做法是刻意引入一些看起来不那么高效的机制，比如 pair programming lunch、hackathon，以及 shared maker time。

表面上看，Fiona 是在重新制造“可被看见的协作”，更深层次的目的，其实她是在重新构建AI时代的团队文化。

因为当每个人都在和自己的 Agent 工作时，如果不主动设计交汇点，团队就会慢慢失去共同语境。

而那些不成文的规则，正是AI时代对组织文化的终极验证机制。

对中国创业者的启发：重写组织操作系统

真正的 AI-native，是组织应该重写操作系统——工作流、岗位边界、验证机制、管理方式、计划方式，都在围绕 Agent 重新排列。

有几个点很容易被忽略，但其实很关键。

如果AI只是接到旧流程上，结果往往只是让旧流程跑得更快，但问题本身没有变。

不要只看产出数字、代码量、PR 数、token 数。看起来都在增长，但很多时候只是新的代码行数崇拜，不一定代表真实进步。

真正需要警惕的，是把动作变多误认为能力变强。

更重要的是验证系统。AI 时代最危险的是越追求速度，越容易失控。

还有一点经常被低估，不要用旧组织去管理新生产力。

如果模型能力每个月都在变化，那些半年 roadmap、层层审批、固定节奏复盘，本质上都会开始变慢，甚至变成负担。

Fiona 的团队曾经试图用一个半年路线图来对齐方向。但几个月后他们发现，这份计划几乎不再被引用，于是改成更轻的方式：月度优先级 + 每周快速校准一次判断是否仍然成立。

变化的背后，其实是组织正在从提前设计未来，转向实时应对变化；从固定路线图，转向持续调整优先级；从一次性决策，转向不断校准。

说到底，这一轮变化真正拉开组织间差距的，是组织本身是否已经进入了一个持续重写的状态。

回顾整场访谈，我们会发现，通过Fiona 的视角，我们看到组织变革的全景图——不仅是效率提升，更是工作方式被重写的过程，以及那些在速度加快后才会暴露的结构性陷阱。

某种意义上，这一轮变化就像 Peter Drucker 说的：“效率是把事情做对，效能是做对的事情。”

AI 没有让软件工程变简单，它露出了真正难的那一面。