夜雨聆风
Fiona Fung 这场演讲，最有意思的地方不是她讲了多少 Claude Code 的新功能。
更准确地说，她讲的是一个工程团队被 AI 编程工具真正撞上之后，旧流程怎么一块一块松动。
演讲标题叫 Running an AI-native engineering org。官方页面显示，这场 session 发生在 2026 年 5 月 6 日的 Code w/ Claude 2026 San Francisco，时长半小时左右。
它值得听，不只是因为讲者在 Anthropic。更重要的是，Fiona 不是外围评论者，而是站在工具交付和团队运转现场的人。换句话说，她讲的不是“别人应该怎么用 AI 写代码”，而是一个被 AI 编程工具反复改造的团队，自己怎么重新安排工作。
这不是一个“AI 会不会替代程序员”的演讲。
它更像一个工程负责人站在台上说：我们真的把 AI 编程工具吃进团队日常之后，发现最先坏掉的不是 IDE，不是模型，也不是 prompt。
最先坏掉的，是过去那套默认假设。
这场演讲的核心不是“怎么让工程师多写代码”，而是：当代码产出不再稀缺，团队应该把管理重心移到验证、评审、协作、安全和产品判断上。
读这场演讲，我建议先分清两层。
第一层，是 Fiona 在演讲里明确讲到的团队实践：路线图变短，设计文档减少，PR 变成技术讨论的主要媒介，Claude 参与几乎所有提交，经理要先下场做 IC，指标不再围着“写了多少代码”转。
第二层，是我从这些实践里推出来的判断：AI 原生工程管理不是“把流程砍掉”，而是把流程从管理产能，改造成管理风险、学习速度和责任边界。
这个区别很重要。
如果只看到“少开会、少写文档、多用 AI”，团队很容易把这套东西学歪。真正的关键不是动作本身，而是动作背后的成本结构变了。
01 从“写得慢”到“接不住”：流程负债开始暴露
Fiona 一开场先把时间拨回 2000 年代。
她职业早期参与过 Visual Studio 2005。那还是盒装软件的年代：版本要交给生产线，刻盘，装盒，再进入零售渠道。发布动作天然笨重，团队流程也会跟着长出很多刹车和闸口。
后来互联网分发来了，软件不再靠盒装光盘送到用户手里。发布频率变了，团队方法也跟着变。
现在轮到 AI。
但这一次，它动到的不是“软件怎么发出去”，而是“代码怎么被生产出来”。
很多工程管理方法，底层其实都默认一件事：写代码贵。
所以我们要做长路线图，要开排期会，要写设计文档，要划代码所有权，要排队做评审，要把工程师时间当成非常稀缺的资产来分配。
这些东西过去不是没道理。它们是上一代瓶颈的产物。
问题在于，瓶颈变了，流程不一定会自己死。
Fiona 在演讲里有一句很直白的话：流程很少会自然消失，组织更常见的动作是一层一层往上加。一个 SLA 不够，再加一个优先级表；优先级表不够，再加一个排序会议。最后工程师不是在交付系统，而是在理解这周到底该服从哪张表。
AI 编程工具把“写代码”这块成本打下来之后，旧流程里很多原本合理的部分，会突然显得很重。
这里的逻辑不是“过去的流程都错了”。
更准确地说，流程是对瓶颈的回应。写代码贵的时候，提前对齐、减少返工、限制变更范围，就是合理选择。可一旦代码原型、测试补齐、局部重构的边际成本下降，继续用同样重的流程去管每一次尝试，就会把团队卡在另一个地方。
所以这场演讲给我的第一个启发是：不要先问“我们要不要保留这个流程”，而要先问“这个流程当年是在替哪个瓶颈服务”。
如果那个瓶颈已经移动，流程就会从保护团队，变成消耗团队。
02 不是不要规划，而是别把半年后的世界假装写死
Fiona 加入 Claude Code 团队后，也问过一个很传统的问题：不做六个月路线图吗？
后来她发现，路线图当然能写。真正麻烦的是，它前面一段时间还像地图，过一阵子再看，就更像历史文件。
她把现在的做法叫 JIT planning，借的是 just-in-time 编译的意思：不是完全不规划，而是在合适的时间做刚好够用的规划。
这句话容易被误解成“AI 时代不用计划”。
恰恰相反。
真正的变化是：当原型成本下降，提前半年把所有细节写死的价值会下降；当代码可以很快跑出来，团队更应该把精力用在验证方向、确认边界和收集真实反馈上。
Claude Code 团队的一个明显变化，是少写“每次写代码前必须有的长设计文档”，更多时候直接做 PR 或 prototype。
不是因为文档邪恶。
而是因为很多技术争论，如果可以直接变成几个可运行版本，就没必要先把大家关进一间白板房里比谁画箭头更有气势。
Fiona 讲了一个具体例子。她刚加入团队时想做一次重构，和 Boris Cherny 对方案有分歧。她本能上差点想说：我们去白板前画一下。
下一秒她意识到，现在可以让 Claude 直接生成几个不同版本的 PR。
这件事的关键不只是“快”。
关键是三个方案都能看到真实 API 改动，看到调用方影响范围，看到代价。技术争论从“我觉得”变成“我们看代码”。
她的表达可以压成一句话：原型已经便宜到可以先做出来看，继续争论反而成了更贵的那件事。
这背后其实是一个很朴素的决策原则：当验证成本低于讨论成本，就应该先验证。
过去很多技术会议并不是大家喜欢开，而是“做一个完整方案”的成本太高。白板、架构图、设计文档，是在真实实现太贵时，用来降低不确定性的替代品。
但如果 Claude 能在短时间里做出几个可对比的版本，白板就不再是最好的事实载体。代码可以暴露接口变化、迁移成本、调用方影响和测试缺口；白板最多暴露一个人的表达能力。
当然，这不等于“谁更快提交谁就赢”。
它只说明一件事：技术团队的争论方式，要从抽象说服，转向可验证证据。
但这里也有一个很重要的反面提醒：不能变成“最后 commit 的人赢”。
如果谁熬夜到凌晨、或者用定时任务在上线前抢最后一手，谁就决定方向，那不是 AI 原生团队，那是流程被速度反噬。
所以 AI 时代的技术管理不是少开会这么简单。
它要求团队更早把争论落到事实，同时更清楚地声明：哪些决策必须公开对齐，哪些动作不能靠“我已经做了”来绑架团队。
03 验证能力，才是 AI 编程后的硬通货
Fiona 在演讲里反复说，Claude Code 团队现在看到的新瓶颈，主要是四类：
验证； 代码评审； 跨职能协作； 安全。
这很合理。
当代码产出提升一个量级，维护成本不会因为生成成本下降而自动消失。相反，团队会更频繁地面对一个问题：这些变化到底对不对？
以前人工 QA、人工 review、人工回归测试还能勉强接住，因为代码流速没那么夸张。现在如果每个人都能快速发起修改，甚至设计师和 PM 也开始提交代码，靠人肉在尾部兜底就会越来越吃力。
所以 Fiona 说要 shift left，把质量保障往源头推。
这不是一句 DevOps 黑话。
它的意思很朴素：不要等代码快要发出去时才发现问题，而是尽量让自动化、测试、静态检查、AI review、风险提醒更早介入。
更早发现，才接得住更高吞吐。
她还讲了一个很真实的小瞬间：自己修了一个和简历相关的 bug，第二天看到有人在内部消息里反馈 bug，心里立刻一沉，担心是不是自己改坏了。
这个感受非常工程现场。
AI 时代不是大家突然都变成十倍工程师，然后开心地刷 PR。
更多时候是：每个人都能动更多东西，于是每个人也更怕自己把东西搞坏。
真正成熟的 AI 原生工程团队，必须让这种焦虑被系统接住，而不是靠个人胆子变大。
这也是我觉得很多团队会低估的地方。
AI 编程工具最先放大的，不一定是交付能力，而是变更频率。变更频率一上来，真正被考验的是测试体系、CI 稳定性、灰度机制、回滚能力、日志可观测性，以及 review 规则是否足够清楚。
如果这些东西没有跟上，AI 工具带来的不是“十倍工程师”，而是“十倍待确认变更”。
所以判断一个团队是不是用好了 AI 编程工具，不能只看 PR 数量，也不能只看代码行数。更应该看：高风险变更有没有被提前识别，常规错误有没有被自动拦住，线上问题有没有更快定位，新人是不是更快理解系统。
产出变多只是表面，验证能力变强才是底层。
04 评审要分层：机器清场，人守边界
代码评审是整场演讲里最值得工程团队立刻拿去对照的部分。
Fiona 的分工很清楚。
Claude 很适合处理风格、lint、重复、常规 bug、补单元测试、回应 review 意见，以及在人工正式接手前把 PR 打理干净。
这些事情有共同特点：高频、规则明确、相对低风险、容易验证。
但是有三类东西，她仍然强调要保留给人：
第一，法律和合规。
第二，安全敏感代码和信任边界。
第三，产品 sense 和品味。
前两类很好理解，出问题代价太高。
第三类更微妙。
她举了一个轻松的例子：她想让终端里的 Claude 多一点节日气氛，于是试着做雪人风格的 ASCII 画。设计同事看完之后的反馈很直接：这看起来更像 Mr. Peanut。
这个故事有点好笑，但背后是个严肃问题：
模型可以非常勤快地生成方案，但它未必知道一个东西“看起来哪里不对”。
产品品味、审美取舍、用户感受、语气边界，这些暂时还不能简单外包。
所以，AI 代码评审的关键不是问“我们能不能让 Claude 审更多代码”。
更好的问题是：
哪些评审只是体力活？哪些评审是在承担组织风险？哪些评审是在守住产品判断？
这三个问题不拆开，团队就很容易一边抱怨 review 爆炸，一边又不敢真正自动化。
我更愿意把代码评审拆成三层。
第一层是格式和惯例，交给工具最合适。比如 lint、命名、重复逻辑、常见测试缺口。
第二层是工程正确性，可以让 Claude 做第一轮，但要有可运行的测试、类型、CI 和日志来交叉验证。
第三层是组织风险，只能由人来承担。法律、合规、安全边界、产品体验和用户承诺，本质上不是“看代码细不细”的问题，而是“出了问题谁来负责、代价多大、是否符合产品方向”的问题。
如果一个团队没有先分层，就直接喊“AI 帮我们 review”，最后往往会出现两种坏结果：该自动化的地方继续堵人，该人工判断的地方被模型稀里糊涂带过去。
05 别问“谁写的”，要问“谁负责解释和验证”
在 Fiona 描述的团队日常里，PR 默认已经不是纯人工产物。Claude 会参与起草、修改、补测试、回应意见，人的工作和模型的工作混在同一个提交链路里。
这会让一个老问题变得越来越奇怪：这段代码到底是谁写的？
过去问这个问题，通常是在找责任、找上下文、找专家。
但当每个提交都有人和 Claude 的共同参与时，“谁写的”这个问题会变得不够精确。
Fiona 的建议是往下追问一层：
你真正想知道的是谁引入了这个 regression？ 还是谁最懂这块逻辑，能回答客户问题？ 还是谁能解释这个模块的历史上下文？
如果问题拆得更准确，反而更容易自动化。
比如她自己原本有一个早晨例行动作：拿着咖啡，让 Claude Code 读客户反馈频道，给她做摘要。后来 Routines 上线，这个动作就可以被放进云端自动化里定期跑。
Anthropic 在 2026 年 4 月 14 日发布 Routines 时，把它定义为可以配置一次、再按计划/API/GitHub 事件触发的 Claude Code 自动化。也就是说，这类“每天早上读一遍反馈、总结风险、开一个跟进任务”的工作，已经不必依赖某个人手动打开终端。
这也是为什么“代码所有权”会变模糊。
不是因为团队不需要责任。
而是责任要从“谁敲下了这一行”转向“谁拥有上下文、谁定义边界、谁验证结果、谁对用户解释”。
这点其实比“AI 写了多少代码”更值得管理者紧张。
因为传统组织里的很多责任制度，是围绕“人写代码”设计的。谁改了文件，谁就是第一责任人；谁负责模块，谁就是默认解释者；谁 review 过，谁就背一部分质量责任。
但 AI 参与之后，提交记录只能回答一部分问题。它能告诉你谁触发了变更，却不一定能告诉你谁真正理解这个变更。
管理者要补上的，是新的责任字段：谁提出了意图，谁确认了边界，谁看过风险，谁能对客户解释，谁负责后续维护。
这不是把责任变轻，而是把责任从“手工归属”升级成“上下文归属”。
06 让知识靠近代码，而不是供在知识库里
Fiona 还有一句很重的话：the code is the source of truth.
在 Claude Code 团队，她会让 Claude Code 挂载本地 repo，直接从代码里找逻辑，帮助回答技术类客户问题。
这解决了软件行业一个老毛病：文档总是比代码慢半拍。
不过这句话也不能粗暴理解成“以后都别写文档”。
有些行业、有些组织、有些协作方式，确实需要完备 spec。那怎么办？
Fiona 给出的处理方式很实用：如果 spec 是硬约束，就别让它孤零零地待在另一个知识库里。把它版本化到 repo 里，让 Claude 对照实现做一致性检查。
这其实是一条很实用的原则：
如果某个信息会影响系统行为，它就不该只躺在某个聊天记录、某份飞来飞去的文档、某个只有老人知道的知识库里。
它要尽量靠近代码，靠近测试，靠近可验证的地方。
AI 时代的知识管理，不是把知识库写得更漂亮。
而是让知识变得可读取、可追踪、可校验。
这里有一个很现实的判断：AI 只能放大它能读到、能验证、能操作的知识。
如果关键决策散落在聊天记录里，模型很难可靠继承；如果设计意图只存在某个老员工脑子里，新人还是会卡住；如果文档和代码长期不一致，AI 只会把不一致放大。
所以“代码是事实来源”不是反文档，而是反孤岛。
文档当然可以存在，但它最好进入版本控制，和测试、代码、变更记录放在同一个可追踪系统里。这样 AI 才不只是帮你搜索知识，而是能帮你检查知识是否还成立。
07 经理下场，是 AI 工具落地的最低诚意
Fiona 在组织设计上的观点也很硬。
她不想要层层嵌套的结构，而是尽量保持团队扁平。Claude Code 和 Cowork 放在同一个大目标下推进，不鼓励每个小组先各写一版使命宣言，再在方向变化时重新同步。
理由很直接：AI 产品变化太快，目标一变，层级越多，对齐损耗越大。
更有意思的是，她坚持所有经理都要先做 IC。
招聘同事一开始觉得她疯了：哪有经理愿意倒回去先写代码？
她的态度很明确：这就是 Claude Code 团队的 dogfooding。如果候选人不愿意，早点分开对双方都好。
这条要求不是在怀旧，也不是说经理必须重新变成全职工程师。
它是在说：如果一个团队的核心产品和核心工作方式都已经变了，管理者不能只靠会议、表格和汇报理解它。
你得亲手用一次。
你得知道 Claude Code 在什么时候好用，什么时候会问错问题，什么时候会改得太多，什么时候需要你收住它。
否则你很难判断团队的抱怨到底是工具问题、流程问题、能力问题，还是管理层自己没下场的问题。
这点对国内团队也很有启发。
很多公司引入 AI 编程工具时，管理层最容易做的动作是买账号、发通知、看周报。
但真正的组织变化，往往要从负责人自己的一线体验开始。
这条经验放到国内团队里尤其重要。
很多 AI 工具推广失败，并不是工具完全没用，而是管理层只把它当成采购项目：买账号、设目标、看周报，然后要求一线“提高效率”。
问题是，AI 编程不是一个简单的效率插件。它会改变需求拆分方式、代码评审方式、测试责任、设计协作、值班交接，甚至改变谁能提出技术方案。
如果经理没有亲自走过一次完整链路，很难判断团队到底卡在模型能力、上下文管理、仓库结构、测试缺口，还是卡在旧流程不肯让路。
经理先做 IC，不是姿态，是为了获得判断力。
08 指标看链路，不看“AI 代码占比”的热闹
Fiona 提到三个可观察指标：
第一，新人上手时间。
第二，PR 生命周期。
第三，Claude 辅助提交比例。
前两个很好理解。
新人更快产生有效产出，说明代码库理解、环境搭建、上下文获取正在变容易。PR 周期变短，说明从想法到合并的链路变顺了。
但 PR 周期这个指标还有一个额外价值：它会暴露下游瓶颈。
比如 CI 跑不动了，测试环境不稳定了，产品基础设施跟不上提交频率了。表面看是 AI 工具采用问题，实际可能是工程基础设施被新的吞吐量打穿了。
第三个指标更容易被误用。
Fiona 提到，在 Claude Code 团队，Claude 辅助提交已经是默认状态。她甚至说自己好几个月没见过非 Claude 辅助的提交。
但她也提醒，不要只盯“AI 写了多少代码”。
这类数字很适合出现在新闻稿里，看起来很振奋：我们 30% 的代码由 AI 写，50% 的代码由 AI 写，80% 的代码由 AI 写。
问题是，代码比例不是业务结果。
真正要看的还是产品质量、可靠性、客户体验、系统可维护性，以及团队是不是更少被低价值流程拖住。
AI 原生工程管理最容易犯的错，就是把吞吐量本身当成目的。
这三个指标背后的含义，其实都不是“AI 用得多不多”。
新人上手时间，衡量的是知识是否可获得、系统是否可解释。PR 生命周期，衡量的是从想法到验证再到合并的链路是否顺畅。Claude 辅助提交比例，只能说明 AI 已经进入日常工作流，不能单独说明团队变强了。
我会更警惕另一类指标：AI 生成代码占比。
它太容易被包装成成绩，但很难解释质量。一个团队可以生成很多代码，同时引入更多维护负担；也可以让 AI 只写少量关键辅助代码，却显著缩短理解系统和验证方案的时间。
真正有价值的指标，应该能回答一个问题：团队是不是更快、更稳地做出了正确决策？
09 没答案的地方，恰好是管理者要补课的地方
这场演讲的好处是，Fiona 没有把一切讲得像标准答案。
她最后也承认，有几件事还没完全想清楚。
第一，当工程师能跨平台流转之后，传统的 iOS 团队、Android 团队、后端团队这种边界还应不应该原样保留？
第二，自动化评审到底要推多远？今天还需要人看的，下一代模型可能就能可靠处理；今天可以托管给 Claude 的，到了安全敏感场景又必须收回来。
第三，角色边界模糊以后，怎么让每个人都有公平的产出感？
工程师能做内容，PM 能写代码，设计师能修 bug，这听起来很酷。但如果组织的评价体系还停留在旧岗位边界里，人的感受会很复杂。
这三个问题对任何团队都不是小事。
AI 工具让边界变软，但组织里的信任、评价和归属感不能跟着变糊。
这三个问题之所以难，是因为它们已经不是工具问题，而是组织契约问题。
当工程师能跨平台写代码，原来的专业边界会松动；当 PM 和设计师也能提交 PR，原来的产出边界会松动；当 Claude 能承担第一轮 review，原来的质量责任边界也会松动。
边界一松，短期看很兴奋，长期看就会冒出公平感问题。
谁的贡献被看见？谁承担最后责任？谁有资格做产品判断？谁可以跨到别人的领域，谁又会被要求守在原地？
AI 原生组织真正难的地方，可能不是让大家都“会用工具”，而是重新设计一套让人愿意协作、敢于负责、也能被公平评价的规则。
10 先拆掉一条最吵的流程
如果只从这场演讲里带走一个动作，我会选 Fiona 最后的建议：
找出你们最吵、最烦、最折腾人的那条工作流，重新问一遍：它到底还在服务谁？
她讲过一个例子。过去某个团队有个固定周会，五十多个人坐在一起。她观察后发现，除了被点名汇报的人会抬头，其他人大多在低头做自己的事。
后来她问：我们到底为什么还在开这个会？
会就这么被解散了。
这不是“反会议”。
这是提醒团队：旧流程不会自己走，必须有人负责把它请出门。
对大多数团队来说，下一步不用宏大。
不要上来就宣布“我们要全面 AI 原生转型”。
先选一个很具体的流程：
每周进度同步； PR review； bug triage； 客户反馈摘要； 新人 onboarding； 文档与代码一致性检查； 值班交接。
然后问四件事：
第一，它当初是为了解决什么问题？
第二，现在这个问题还存在吗？
第三，有多少步骤只是因为“写代码和整理信息很贵”才存在？
第四，哪些环节可以交给 Claude 打底，哪些必须由人做最终判断？
这比喊口号更接近 AI 原生。
如果要把这件事落到一个最小动作，我会建议从“高噪音、低判断”的流程开始。
比如周报汇总、客户反馈摘要、重复性 bug triage、文档和代码一致性检查。这类工作有两个特点：信息量大，人工整理烦，但真正需要人的判断点相对清楚。
先让 Claude 做信息归并和初步分类，人只负责确认优先级、风险和下一步行动。
一旦这个闭环跑通，团队就会自然看到 AI 适合放在哪里，不适合放在哪里。比起一开始就改组织架构，这种小流程更容易验证，也更不容易伤筋动骨。
结尾
Fiona 这场演讲真正有价值的地方，是她没有把 AI 编程讲成一个效率神话。
她讲的是工程团队的底层假设正在变。
过去最贵的是写代码，所以流程围着工程师时间转。
现在代码变得便宜，最贵的东西变成了判断、验证、对齐、品味和责任。
这也是为什么 AI 时代的工程管理不会消失。
相反，它会变得更难。
难点不在“怎么催大家多用 AI”，而在“怎么避免团队被更高吞吐量拖垮”。
因为你不再只是管理“谁来写、多久写完、什么时候发版”。
你要管理的是：当每个人都能更快动系统，团队怎样仍然知道什么是对的，什么是安全的，什么是值得做的，以及什么时候应该停下来。
这才是 AI 时代工程团队真正的管理题。
参考资料
Running an AI-native engineering org | Code w/ Claude 2026：Anthropic 官方 session 页面，包含演讲标题、日期、讲者和视频入口。 Running an AI-native engineering org | YouTube：Claude YouTube 频道原视频。 AI 时代到底该怎么管一个工程团队 | 宝玉：中文整理和演讲 slide 截图索引。 Running an AI-native engineering org | TalksIntel：演讲摘要、时间戳和要点索引。 Running an AI-native engineering org | uListen Transcript：公开 transcript，用于核对演讲细节。 Introducing routines in Claude Code：Anthropic 官方 Routines 发布文章。 Automate work with routines | Claude Code Docs：Claude Code Routines 官方文档。
