AI-Native Shipping（AI 原生发布）
定义
AI-Native Shipping 是 Cat Wu 描述的 Anthropic 极速迭代模式。 它把发布从“稳定承诺”改造成“可撤回的学习探针”，让工程师能在清晰目标和低摩擦协作下更快接触真实用户。
机制拆解
AI-Native Shipping 的核心不是单纯更快写代码，而是把产品发布链条拆成一组可被工程团队直接触发的低摩擦机制。
- 目标显性化：团队用 Metrics Readout 和 Team Principles 共享用户、指标和取舍，而不是每个功能都重新写厚重 PRD。
- 发布降承诺：Research-Preview 让早期功能先以实验版本接触用户，降低“必须一次完美”的心理和组织成本。
- 跨职能常驻化：Evergreen Launch Room 把文档、PMM 等支持角色前置到固定流水线中，避免每次发布重新找人对齐。
- 工程师产品化：工程师不只是执行需求，而是在清晰边界内直接判断功能是否可以发给用户。
- 反馈可回滚：新模型到来后，团队不仅新增功能，也会删除为旧模型能力缺口服务的功能，避免产品层负担堆积。
这种机制把产品组织从“排期驱动”转向“反馈驱动”：先让真实用户触碰能力，再决定加固、修改或撤回。
关键数据点
- 周期压缩：6 月 → 1 月 → 1 周 → 1 天，"这种状态已持续好几个季度"
- Engineer-Launch Flow：工程师觉得功能 OK → 发到 evergreen launch room 频道 → 文档负责人 + PMM 第二天交出公告
- 替代 PRD：Metrics Readout（每周全员业务指标同步）+ Team Principles 文档（核心用户是谁、什么重要、什么可舍弃）
- 团队配置：Claude Code 团队每个人（工程经理、PM、设计师、数据科学家、财务、用户研究员）都写代码
- Newton 的 Caveat: Cat 引用 Newton（Instagram 联合创始人，现 Anthropic CPO）的观点——"AI 时代的产品开发不是让 PM 做更多产品工作，而是让工程师做更多产品工作"
与传统敏捷的区别
| 维度 | 传统敏捷发布 | AI-Native Shipping |
|---|---|---|
| 发布含义 | 对稳定功能的承诺 | 对能力假设的试探 |
| 主要瓶颈 | 开发排期和跨团队等待 | 判断什么值得被真实用户验证 |
| PM 工作 | 写需求、排优先级、协调团队 | 设计让工程师低摩擦发布的系统 |
| 风险控制 | 延后发布、增加审批 | 降低承诺、明确预览、快速回收 |
| 学习方式 | sprint 复盘和用户研究 | 真实使用反馈推动加固或撤回 |
所以它不是“敏捷再快一点”，而是发布语义改变：发布本身成为产品研究工具。
前提与局限性
- Anthropic 的极速模式依赖 Developer-first 用户群（高容忍度 early adopters）
- Mission Alignment 是组织摩擦低的核心前提——不一定能迁移到使命模糊的公司
- AI-native shipping 达到"1 天"周期的功能主要是 incremental improvements，不是核心架构变更
- 这种方式要求团队能区分可逆功能和不可逆承诺；涉及安全、合规、账务或客户关键工作流时，Research Preview 不能替代严肃验证
- 若所有功能长期停留在预览状态，用户会把“可撤回”理解成“不可靠”，反而损害信任
判断标准
判断一个团队是否真正进入 AI-Native Shipping，不看它是否宣称使用 AI，而看四个信号：
- 工程师是否能在清晰原则内独立推进小功能，而不是等待 PM 逐项批准。
- 跨职能支持是否是常驻机制，而不是每次发布临时拉群。
- 发布是否能明确标注承诺等级，让用户知道这是稳定功能、预览能力还是短期实验。
- 团队是否有撤回和删除功能的纪律，而不是只会堆叠新能力。
关联概念
- Research-Preview — AI-Native Shipping 的核心机制
- PM-in-AI-Era — PM 角色从"流程守护"到"高速公路设计"的转变
- Product-Overhang — 加速迭代以匹配模型能力溢出的策略
- AI-Native-Product-Operating-System — 将该机制放入能力发现、发布试探、反馈闭环和验证纪律的完整系统中