- tags
- [AI, 产品, 工程, 流程, Anthropic, 发版]
- created
- 2026-04-27
- updated
- 2026-05-06
- sources
- [raw/notes/anthropic-kat-wu-pm-shipping-cadence-2026-04-25.md, raw/notes/karri-saarinen-some-notes-on-ai-2026-04-26.md, raw/notes/anthropic-openai-pe-jv-fde-mid-market-2026-05-04.md]
定义¶
Anthropic Claude Code / Cowork 团队把产品迭代周期从 6 个月压至 1 个月、部分功能 1 天的具体工程化机制。最近 40 天发布 30+ 项功能，由三个互锁的实践支撑：Research Preview（发"未完成"的合法性）+ Launch Room（发布流程的 evergreen 频道化）+ 工程师 PM 融合（把"决定写什么"的人和"能写出来"的人合一）。
Kat Wu（Claude Code + Cowork PM）："大部分加速来自流程和团队文化"——不是模型能力本身。这给 pivot-speed-as-moat "组织效率才是护城河"加了一个 Anthropic 视角的具体可复制的工程化样本，而不只是 CREAO 那种"创业公司因为人少所以快"的体感判断。
三个互锁机制¶
1. Research Preview：发"未完成"的合法性¶
做法：功能以早期版本形式发布，用户了解其临时性质，团队无需完美即可在一两周内推出。
关键创新点：把"早期版本"当成产品形态而不是开发阶段。Research Preview 不是 Beta（Beta 暗示"几乎完成只差用户测试"），是"本来就应该有用户参与的实验性功能"。
对完美主义的对冲：传统 PM 流程里"质量门槛"会不断推迟发布；Research Preview 把质量门槛降到"能学到东西就发"，把质量提升机制变成"发出去后再迭代"。
2. Launch Room：发布流程的 evergreen 频道化¶
做法：工程师将功能提交至 "evergreen launch room" 频道，文档、市场营销和开发者关系团队迅速跟进，次日即可发布。
关键设计：把"发布"从一次性大型项目变成日常窗口。任何工程师写完功能扔进频道 → 文档/marketing/DR 团队默认每天 watching → 次日上线是正常节奏。
Kat："我们希望移除一切阻碍发布的障碍。"
机制层面： - evergreen = 频道一直开着 watching，不是项目制启动 - 文档 / marketing / DR 不是事后被叫来配合，是默认监听 - 跨职能依赖被工程化（频道 + 默认监听）而不是被组织化（开会 + 排期）
3. 工程师 PM 融合：决定写什么 + 能写出来 = 同一个人¶
做法：Anthropic 倾向于招聘有产品品味的工程师而非传统 PM。"几乎所有 PM 都有工程背景"——能更快判断实现难度。
Kat："代码变得越来越便宜了。那什么变得更有价值呢？决定写什么。"
典型流程：工程师从看到社交媒体用户反馈开始 → 周末就自己上线功能，几乎不需 PM 参与。
与 ai-first-engineering CREAO "架构师 vs 操作员" 的关系： - CREAO 框架：架构师（六边形战士） + 操作员（其他人） - Anthropic 实践：工程师 + 产品品味在同一人身上 - 两者方向一致——都在重组"决定做什么 vs 能做什么"的传统分工 - 区别：CREAO 是新组织从头设计；Anthropic 是头部公司主动改造已有 PM 角色
三个机制的互锁关系¶
三件事单独看都不新鲜（早期版本概念有 Beta、跨职能频道化各家都有、PM 工程化也有先例），关键是三件事必须同时成立：
| 缺哪一件 | 后果 |
|---|---|
| 没有 Research Preview | 发布门槛高 → Launch Room 没东西可发 |
| 没有 Launch Room | 跨职能等齐才能发 → Research Preview 也卡住 |
| 没有工程师 PM 融合 | "决定做什么"和"能做出来"中间有人际摩擦 → 节奏卡在沟通成本 |
互锁后的产物：可以让"想到"和"上线"在同一周内发生。
副作用：产品一致性的代价¶
Kat 承认两个副作用：
- 同一需求会有两个功能在做——内部方案都被认为可行
/powerup功能违背了"产品应直觉到不需教程"的原则——但"功能实在太多了，用户确实需要有人告诉他们这一百个功能里，哪十个是必须用的"
含义：高速发版换来的是功能爆炸 + 内部对齐损耗。Anthropic 的取舍是接受这个代价（提供 /powerup 教程让用户自己挑），不为消除冗余而放慢。
这条与 pivot-speed-as-moat "保持小、保持快、保持变" 同源——速度优先于一致性。
删功能习惯：模型升级时的首要响应¶
Research Preview + Launch Room 之外，Kat 提到一个互补习惯：每次新模型发布时第一件事是删功能。
"每次发布新模型，我们都会通读整个 system prompt，逐段反思：模型还需要这个提醒吗？如果不需要了，就删掉。"
具体例子：Claude Code 早期有待办事项功能（帮模型在大规模代码重构中追踪修改点）。升级到 Opus 4 后，模型能自主列清单并逐个完成，该功能变为可选。
这条对 harness-engineering 的补充：Harness 不是单调累积的——模型变强会让一部分 Harness 过时。"删 Harness" 是与"加 Harness" 并行的能力。这与传统软件"功能只增不删"的惯性方向相反。
操作性指标：Anthropic 内部合并代码前必须通过 Claude 审查（早期版本精准度不足，到 Opus 4.5/4.6 才达可靠水平）——这是删功能的反向例子：从"可选辅助"变成"强制门控"。
与 harness-engineering 的关系¶
Research Preview Pattern 是 Harness Engineering 在产品发布层的具体落地： - Harness 处理的是 agent 运行时（让 agent 跑起来） - Research Preview Pattern 处理的是产品发布运转（让功能上得去） - 两者共享同一原则：移除一切阻碍——Harness 移除模型完成任务的障碍，Research Preview 移除功能上线的障碍
Anthropic 自己作为 Harness Engineering 范式的提出者，把同一原则推到产品流程层是预期内的——但作为外部观察，这是"组织也是 Harness 的一部分"判断的具体实证。
与 ai-first-engineering CREAO 的对照¶
| 维度 | CREAO（用户视角） | Anthropic（平台视角） |
|---|---|---|
| 公司规模 | 25 人 | 千人级 |
| 速度数据 | 14 天每天 5-8 部署 | 40 天发布 30+ 功能 |
| 速度来源 | AI-first 改造（瓶颈级联 + 自愈循环） | Research Preview + Launch Room + 工程师 PM 融合 |
| 关键约束 | 组织小所以可以全员 AI-first | 组织大但用流程工程化解决跨职能依赖 |
| 95% 自动化 | "95% 工作交给 AI"（CREAO 操作定义） | "95% 不是真正的自动化"（Kat：剩 5% 才是关键） |
| 对外输出 | Super Agent 平台 | Claude / Claude Code / Cowork / SDK |
两条路径不矛盾：CREAO 适合 25 人级新组织；Anthropic 适合千人级已有组织重构。关键的共同判断是"速度 = 流程文化 > 模型能力"——两家头部都明确说了。
与 pivot-speed-as-moat 的关系¶
pivot-speed-as-moat 提出"组织效率与 pivot 速度才是护城河"，给的是 CREAO + Cursor 等创业公司样本。Research Preview Pattern 给该判断加了 Anthropic 这个 frontier 实验室样本——证明"速度即护城河"不是创业公司专利，头部已建组织也可以工程化达成。
具体含义：Anthropic 在模型层有结构性优势（自家模型最早可用），但 Kat 明确说"大部分加速来自流程和团队文化"——模型优势不能取代流程优势，反而是叠加关系。
对 Sentino 的具体含义¶
Sentino 当前组织规模约 20 人（与 CREAO 同级），处于 sentino 横向客户机会扩张期。Research Preview Pattern 三个机制的可借鉴度：
| 机制 | Sentino 当前 | 借鉴成本 / 可行性 |
|---|---|---|
| Research Preview | 多数功能内部完成度高才对外 | 低成本——把"早期版本对客户公开"作为新策略，给 sentino-tenga / yukai-agora-poc / hotmind-client 客户演示用 |
| Launch Room | 发布流程未频道化 | 中等成本——需要内部 Slack/飞书加 evergreen 频道 + 文档/marketing 默认监听机制 |
| 工程师 PM 融合 | Sentino 团队结构未公开（Chris=CEO/子昕=产品/姜涛=技术，三层分离） | 高成本——涉及组织角色重构，与现有分工冲突。但可以从"产品和工程的紧密协作"开始（如子昕跟工程师每周工作 1-2 天） |
优先级判断：先采纳 Research Preview（最低成本最高 ROI），观察客户反馈后再决定是否推 Launch Room 与工程师 PM 融合。三个机制不互锁的话效果会大打折扣，但可以作为有节奏的引入。
与 sentino-tenga 的具体含义：当前 TENGA 提案"营收优先"准则下，Research Preview 模式可以让客户在方案完整前先用早期版本——降低客户决策门槛 + 加速学习反馈环。这与 sentino-tenga 当前"等 Chris 回答 4 题再推进"的节奏可以叠加，不冲突。
适用边界¶
- 不适合 B2B 大客户合规场景：金融/医疗/政府客户合同要求"功能定义清晰、SLA 承诺明确"，Research Preview 的"早期版本性质"违反这种合同语义
- 不适合硬件 + 长开发周期产品：Research Preview 假设的快速迭代基础设施（云端发版、用户即时升级）在硬件领域不成立
- 依赖团队文化的高信任：Launch Room 的 evergreen 频道默认监听机制需要文档/marketing/DR 团队对工程师有高度信任，不能"先评审再决定上不上"
待观察¶
- 三个机制的引入顺序对效果的影响——是否必须从 Research Preview 开始？还是可以从 Launch Room 切入？
- 工程师 PM 融合在 100+ 人组织里能否维持？Anthropic 千人规模下"工程师周末上线功能"的故事可能只代表少数顶尖工程师而非全员
- 长期看 Research Preview 模式是否会让用户对"功能稳定性"预期普遍下降，反而拖累品牌？或者反而培养了用户接受迭代的习惯？
相关概念¶
- pivot-speed-as-moat — Anthropic 是该判断的第三个独立样本（CREAO + Cursor 之后），证明速度即护城河不是创业公司专利
- ai-first-engineering — 用户视角（CREAO）vs 平台视角（Anthropic）的对照样本
- harness-engineering — Research Preview Pattern 是 Harness 原则在产品发布层的延伸
- claude-agent-sdk — SDK 是 Anthropic 这套发版机制的产物之一
- agent-runtime-architecture — 删功能习惯对七层模型 Layer 1（启动层）+ system prompt 设计有直接含义
- agent-tool-design — 删功能 / 模型升级响应是工具集设计的"减法"维度
- sentino — 三个机制对 Sentino 横向客户线推进有具体借鉴可能
- expertise-paradox — "100% 才是真自动化" 的心理学解释：novice 容易满足于 95%，expert 才坚持到 100% — 95%→100% 最后 5% = expert vs novice 评估差的具体长度
- anthropic-openai-pe-jv-2026-05 — Anthropic 一贯的"挑客户 / 做窄而深"战略风格在 JV 阵营选择上的延续（$1.5B / ~10 投资人 + Goldman Sachs / Sequoia / GIC 战略基础设施型参与，对比 OpenAI $10B / 19 投资人 / 17.5% guaranteed return 资本密集型）—— Research Preview Pattern 的产品迭代速度优势支撑了"纯软件主体"叙事的产品力 credibility