夜雨聆风我们每天为你更新硅谷最新的 AI 创业与科技播客总结，让你与前沿保持同频。全文约 3800 字，如果你现在没有时间，试试转成播客稍后再听晚点再听LaterCast
"在 Claude Code 团队，写代码很少再是最慢的部分。"
"构建变便宜后，争论变贵了。"
"流程很少会自己消失，我们往往只会一层一层往上加。"
这期视频来自 Claude 官方频道，主讲人 Fiona Fung 负责 Claude Code 与 Claude Cowork 的工程和产品。加入 Anthropic 之前，她在 Meta 和 Microsoft 带过团队，也经历过 Visual Studio 还要刻进 CD-ROM 的年代。她这次没有讲提示词技巧，而是把 Claude Code 团队内部的工作方法摊开：当写代码变快，团队最慢的环节会从哪里冒出来，经理、PM、设计师和工程师又要怎样改流程。她围绕五个变化展开：瓶颈迁移、团队规范重写、推广方式、衡量信号，以及她自己还没想完的问题。读完这篇，读者拿到的是一套可带回团队讨论的流程清单，而不只是一句“多用 AI”的口号。
瓶颈从写代码移到验代码
Fiona 开场先把时间拉回 2005 年。那时 Visual Studio 要进制造实验室、刻盘、装盒、发到商店，软件发布的节奏由物理分发决定。后来线上分发出现，团队流程跟着改变。她认为 AI 编程带来的也是同级别的迁移：过去昂贵的是工程师打字、写测试、排期重构；在 Claude Code 团队，生成代码的成本已经降到很低。慢下来的地方换成了验证、评审、跨职能沟通和安全边界。工程负责人问她最多的问题，也从“怎么写得更快”变成“人类怎么跟上代码评审”。
"过去几年，工程带宽一直是昂贵的东西；在 Claude Code 团队，写代码很少再是最慢的部分。"
这会改变管理动作。以前团队会专门排期重构，因为重构要吃掉宝贵工程时间；现在更多代码会更快进入仓库，维护成本和回归风险反而变得刺眼。Fiona 用“瓶颈已经移动”来提醒团队：旧流程没有坏掉的爆炸声，只会在新吞吐量下慢慢失效。她在分享里还提到 P0 bug SLA、high priority review SLA 这类层层堆出来的规则，最后团队甚至要给 SLA 再排优先级。流程曾经为了解决缺口而生，在新瓶颈出现后，也可能变成另一个缺口。
规划像 JIT 编译一样靠近现场
刚加入 Claude Code 时，Fiona 也问过团队要不要做六个月路线图。团队确实写了一版，三个月还算可用，过完新年再看，外部模型能力、内部功能和用户反馈已经变了太多。她后来把这种节奏叫作 JIT planning，像即时编译一样，只在足够接近现场时投入足量规划。原型和代码生成不再卡住团队，提前半年写死方案反而会消耗判断力。
"我们做更少规划，也更晚做规划；六个月路线图在三个月后就开始失真。"
Claude Code 团队减少了“每次写代码前必须先有设计文档”的仪式。Fiona 并没有否定设计文档，在异步讨论和复杂系统设计里，文档仍然有位置。但在她带的团队里，很多讨论直接落到 PR 或原型里：有想法，先做出来，让 Anthropic 内部用户试，再把反馈带回开发流程。她还提到，团队也减少了传统 product review，因为外部环境变化太快，原型被真实使用后带回来的信息，往往比会议室里的预测更早暴露偏差。对于正在推进 AI 编程的团队，规划动作也要从“写完整方案”改成“尽快拿到可运行材料”，让判断建立在真实交互、真实报错和真实反馈上。
技术争论先跑三个 PR
她讲了一个自己入职早期的场景。她想做一次重构，和 Boris Cherny 对 API 方向有分歧。按过去习惯，她差点拉 Boris 去白板间推演。转念一想，今天已经可以让 Claude 生成三种实现。她最后拿到三个 PR，不只看 API 长什么样，还能看所有调用方会受到什么影响。当实现成本下降，团队争论的材料就不该停在口头方案。
"构建变便宜后，争论变贵了。"
Fiona 也提醒，PR 变得容易并不代表最后提交的人赢。代码生成速度提高后，团队更需要提前对齐文化：可以快速做出三个版本，也要允许坦诚技术讨论，避免有人靠熬到凌晨三点提交 PR 抢到最后一句话。便宜的是实验，昂贵的是失控的协作。她关心的不只是实现方案本身，还包括所有调用方会怎样被影响；AI 把“想象影响面”变成“直接看 diff”，技术争论因此更接近用户和系统后果。
代码评审交给 Claude，边界交给专家
吞吐量上来后，Claude Code 团队把验证向左推。Claude 会处理样式、lint、PR 反馈请求，帮助补测试，也会在正式提交前发现并修掉一部分 bug。Fiona 说，团队大量使用 Claude 做 code review 和 PR babysitting。人类评审没有消失，只是位置更清楚：法律、安全、信任边界、产品品味，仍然要找对应专家。
"信任，但要验证；在信任边界和安全敏感代码里，我仍然会拉专家进来。"
她举了一个轻松的产品品味案例。她曾想给终端里的 Claude 做节日主题，让 Claude Code 把 Claude 变成雪人。设计伙伴看完后说，这更像 Mr. Peanut。最后她改成更简单的冰蓝色和雪花。模型可以帮你做很多事，但产品感、品牌边界和风险容忍度，仍然要由团队明确分工。她还提到设计师、PM、非工程伙伴也在提交代码，这会让“我改了会不会弄坏什么”的焦虑变强，所以自动化验证要服务所有角色，而不只服务资深工程师。Fiona 把这种边界称为 trust but verify：样式和测试可以交给 Claude 先跑，法律意见、安全敏感代码、信任边界和品牌体验，仍然需要人把关。
招人少看手速，多看产品感和系统功底
Fiona 在 Claude Code 团队更看重两类工程师。第一类是有产品感的 creative builders，他们会围绕一个用户痛点反复做原型，追求体验的 delightful。第二类是有深系统经验的人。她入职后发现团队里产品型通才不少，但做 Claude Code remote 这种“让 Claude 到处运行”的能力时，还需要分布式系统功底。原始手速的权重下降了，能判断该做什么、哪里会断、怎样验证的人更稀缺。
"我更少看原始吞吐量，因为模型已经让大家都更有效率。"
角色边界也在变。Fiona 说，她的 PM 会写代码，非工程伙伴也在 shipping code；工程师也能用 Claude 补上内容设计、调研整理、客户反馈分析等过去要跨职能排队的工作。她自己改 survey 文案时，没有等专门的 content designer，而是让 Claude 帮她压短、改清楚，避免终端里每一行文字被浪费。传统组织里，内容、设计、工程常常靠排期和交接连接；在 Claude Code 团队，很多小缺口会先被当事人用 Claude 填上，再把需要专家判断的部分交还给对应伙伴。
经理先当 IC，组织尽量扁平
她最“辣”的做法，是要求 Claude Code 的每位经理先以 IC 身份加入。招聘伙伴一开始担心没人愿意，因为传统组织会按十个 IC 配一个经理、再往上嵌套。Fiona 坚持这么做，因为她想让经理在代码里建立信用，也能每天真实使用产品。她在 Meta 时曾逼自己每年提一个 PR，但内部工具和命令变化太快；有了 Claude，她重新能跟上仓库和开发流程。
"我希望每个 Claude Code 经理都先从 IC 开始，和团队建立信用，学会做一个有效工程师。"
她还把组织压得尽量扁平。Claude Code 和 Cowork 共用一个总团队使命，pod 可以有自己的工作节奏，但不鼓励每个小组再写一套独立使命。原因很现实：外部变化太快，层级越厚，迁移方向时要解释和对齐的成本越高。Fiona 给 pod 留下 triage、planning、stand-up、on-call 和先 Claudify 哪个流程的自主权；统一的是少数团队原则，具体做法交给离现场最近的人调整。
代码库成了团队的事实来源
当知识分享和 onboarding 也被 AI 改写，Claude Code 团队把代码库看作最及时的事实来源。Fiona 每天早上会打开 Desktop Claude 和本地仓库，拉取客户反馈频道，让 Claude 总结用户在问什么。后来 routines 出现，她把早咖啡时手动做的动作自动化，形成固定晨间流程。她建议有好规格文档的团队，把 specs 放进仓库，让 Claude 检查执行是否符合规格。
"在我们团队，代码就是事实来源。"
衡量这些变化是否有效，她看三个信号：新人 ramp-up 时间是否缩短，PR cycle time 是否变短，Claude-assisted commits 是否上升。她还提醒团队别只盯 AI 生成代码占比，最终还要看产品是否更好、可靠性是否更稳。更多 commit 本身没有意义，用户拿到的体验才是落点。代码所有权也要重新拆开看：问“谁改的”时，团队可能是在找回归来源、找能回答客户的人，或者只是想补上下文；Fiona 的做法是把真实问题拆出来，再看哪些部分能自动化。PR cycle time 变短还会暴露新瓶颈，比如产品基础设施、build 和 CI 是否能承受更多提交；AI 采用率低只是一个原因，流水线其他环节也可能跟不上。
每几个月清一次旧流程
Claude Code 团队有几条常用原则：每个成员都用 Claude Code，包括跨职能伙伴；能 Claudify 的都尽量 Claudify；团队有明确许可去杀掉旧流程。Fiona 说，流程很少会主动结束生命，更多时候是团队为了补一个洞加一条规则，再为了规则冲突加优先级，最后只剩堆叠。
"每个 Claude Code 团队成员，包括跨职能伙伴，都使用 Claude Code。"
她建议团队从最吵的工作流下手：最贵、最烦、最多人不愿面对的流程。她曾参加一个每周 50 人的大型 review，大家低头看电脑，轮到自己报状态才抬头。她只问了一句“为什么要开”，团队很快同意取消。AI 原生组织的第一步，往往并非买新工具，而是把老流程的存在理由重新问一遍。Fiona 还保留了几个未解课题，比如 iOS 和 Android 组织边界是否仍然合理，自动评审该推进到什么程度，角色变模糊后怎样让每个人都同样有效。模型能力每次提升，信任和验证的比例都可能重新分配，所以这些答案也不能写死。她还提到 Claude Code 团队曾经用 spreadsheet 做周进度同步，后来团队变大，表格开始笨重；他们改成 stand-up script，让 Claude 帮每个人理解其他人在做什么。
写在最后
Fiona 的分享给团队一个很实用的起点：别急着宣布 AI 转型，先挑一个最吵、最贵、最让人拖延的流程，问它还服务谁，再决定自动化、缩短或取消。AI 原生组织跑得快，靠的往往是这些朴素动作：少一点过早规划，多一点真实原型；少一点层级汇报，多一点自动验证；少一点按岗位守边界，多一点围绕风险和品味重新分工。下次团队开周会、评审 PR、写路线图时，可以直接拿 Fiona 的问题做检查：瓶颈现在在哪里，谁还必须亲自看，哪些流程已经可以交给 Claude 先跑一遍。先从一条流程开始改，比一次性重画组织架构更稳，也更容易被团队接受。小步快跑，才能看见新的瓶颈在哪里出现，然后继续调整。
内容来源："Running an AI-native engineering org"丨Claude（嘉宾：Fiona Fung）
原视频：https://www.youtube.com/watch?v=igO8iyca2_g
如果你喜欢深度好文，试试用小程序将不方便立刻阅读的文章转成播客，用「听」的方式，稍后阅读，不再错过好文章⇣
⇣ 关注我，每天为你更新硅谷最新的 AI 创业／科技播客总结，让你与前沿保持同频 ⇣
