Fiona Fung 是 Anthropic Claude Code团队的工程与产品负责人，她在 2026 年 Code w/ Claude SF 大会上分享了《Running an AI-native engineering org》，分享了 Claude Code 团队的流程、规范和组织如何重构。

而其实，这个逻辑可以运用在几乎所有团队。。。代码，本质也是一种 know how 而已。

他们极高效率的发布产品的 5 条经验是：xxxxxx

1计划层面，Planning：从长期 roadmap 转向 JIT（Just-In-Time）规划。六个月 roadmap 很快过时，转为快速原型 + 内部用户验证 + 基于真实反馈迭代。少做重设计文档，多在 PR 或原型中讨论。

而如果你是一个消费硬件品牌，那么直接把 demo 给团队或者用户看。不需要过多讨论。

2Knowledge Sharing：先问 Claude，而不是找作者“谁写了这个代码”不再是首要问题。先让 Claude 总结/回答，之后再问“能否自动化”。例如，自动总结客户反馈等。

这适用于任何文本化的团队 know how，不仅仅是代码。你找作者解释，还不如让 AI 总结，理解了之后，你接手就好了。

3Code Review：从人类把关转向 Trust-but-Verify让 AI 做 review 和测试。人类重点审查领域专长、安全边界、法律风险、产品品味等高价值部分。分工会随模型进步而变化。

4Team Roles：角色模糊PM 也在写代码，工程师也做设计/内容。

优先招聘：有产品感和创造力的 builder，以及深厚系统专长的专家。

5Org Structure：保持扁平，经理先当 IC经理先作为 Individual Contributor 发货代码，深入理解工程师日常和工具，再带人。团队整体使命统一，经理支持 pods（小团队），保持敏捷。

而不可谈判的核心团队原则是（Non-negotiable Must-Dos ）：xxxxxxxx1Relentlessly dogfood your product：每个团队成员（包括跨职能伙伴）必须使用 Claude Code（和 Cowork）。领导者要亲自用产品构建产品。

2Claudify everything you can：先问“这个能自动化吗？”（用 Claude 处理），再决定是否人工做。

3Don’t hesitate to kill processes that no longer work：明确授权团队质疑和淘汰过时流程，持续审视“这个还服务我们吗？”。

Fiona 的实用建议：从你团队最吵闹/最痛苦的 workflow 开始，问“它还服务目的吗？能自动化或取消吗？”

最后的话（我的总结）：xxxxxxx

1AI-native 组织的本质是构建规则让人类判断力和 AI 执行力高效协作。

2人不应该做 AI 可以搞定的事情，反之亦然。

3而产品领先的瓶颈并没有消失，只是转移了，过去编码吞吐量昂贵，现在生成代码、测试、重构都很快，但验证、审查、安全、维护等成为新瓶颈。

4因此，人类把有限的时间和精力聚焦在必需的事项上才是根本。