从几个月压到几天：Claude Code 产品负责人怎样按 AI 的速度发版

Cat Wu 是 Anthropic 里 Claude Code 和 Cowork 的产品负责人。她把自己的角色说成对 Boris Cherny 的补充。Cherny 是技术负责人和产品远见的人，负责定义三到六个月后那个「吃了 AGI 药」的产品该长什么样。Wu 的工作是画出从今天走到那幅图景的路，确保市场、销售、财务和产能规划都在同一条船上，功能一旦就绪就没有卡点。两人之间的界限很模糊，大约八成想法是对齐的。

她说自己在面试几百个想进 AI 公司的产品经理，很多人还按旧办法来。AI 出现之前，技术变化慢，可以按六到十二个月做计划；代码贵，产品经理大量精力花在和合作团队对齐。现在 Anthropic 里不少功能的周期已经从六个月掉到一个月，有时是一周甚至一天。

这意味着少去对齐多季度路线图，多去找把东西交到用户手里的最快路径。她希望产品里有一块角落：工程师或产品经理有个想法，周末之前就能进用户手里。在 AI 原生产品上做得最好的产品经理，是那些缩短从想法到用户时间、并定义出开箱必须跑通的那几项任务的人。

Wu 列了三件产品经理能帮团队加速的事。第一是把目标说清楚，因为大模型太通用，产品到底为谁做、解决什么问题会变得含糊。她举的例子是：让企业里的职业开发者安全地把权限提示降到零。目标一旦这么具体，很多做法就被排除了。第二是可重复的发版流程。Claude Code 几乎所有功能都标成研究预览发出去，让用户知道这是早期想法、可能不会长期支持。承诺变低，一两周就能交出去。

第三是拉合作方的框架。工程师把内部试用过的功能发到常设的发布频道，文档、产品市场和开发者关系可以第二天就写出公告。日常不靠长篇需求文档，而是每周做指标复盘，并维护一份团队原则，写明关键用户和取舍，让人不必等产品经理就能做决定。特别含糊或偏基础设施的项目，他们仍会写一页纸甚至完整需求文档。

有人问节奏是不是因为强大的 Mythos 模型。Wu 说模型帮了一点忙，解释不了大部分。团队已经按这个速度跑了好几个季度。她把大部分归到流程少，以及每个人都觉得自己能在一周内把想法带到世界上。

Lenny 问到不久前 Claude Code 源码泄漏。Wu 说团队立刻查了，结论是人为失误：有人用 Claude 写了一份改动发包方式的拉取请求，过了两层人工审查。她称之为流程失败，那个人仍在 Anthropic。团队已经加固流程，大部分防护措施已经上线。

至于停止让人用 Claude 订阅跑 OpenClaw，她解释需求很高，公司正在扩基础设施，也在把脚手架做得更省 token。订阅本来不是给第三方产品设计的，那些产品的用量模式不同。Anthropic 选择优先第一方产品和 API，同时给订阅用户一些额度，让过渡顺一点。

Wu 说 Anthropic 大约有三十到四十名产品经理，分成几块：研究产品经理把客户对模型的反馈送到研究侧，Claude 开发者平台（含托管智能体），Claude Code 与 Cowork，企业，以及增长。被问到产品经理会不会变少时，她说所有角色都在合并：产品经理做一点工程，工程师做产品工作，设计师也在交代码。她的团队选择招有很强产品品味的工程师，有些人能从一条用户推文走到周末发版，几乎不需要产品经理插手。

她手下几乎所有产品经理都做过工程师，或在 Claude Code 上交过代码，这能建立信任、加快速度。被问哪种背景最要紧时，她回到品味：写代码变便宜之后，决定写什么更值钱。GitHub 上有成千上万条 issue，什么都有人要，挑什么值得做，需要小心和品味。

工程背景眼下仍然有用，因为它让你知道一件事该有多难，这会进入优先级判断。但她提醒，有价值的技能组合每隔几个月就会随编码能力跃迁而变。更耐久的是第一性原理思考、看见团队缺口，以及足够低的自我，愿意戴很多顶帽子。

被问到人脑还会在哪里有用，Wu 指向发布所需的常识和情绪智力。一次发布有上千个活动件。模型并不总知道利益相关者是谁、彼此怎么关联、该在哪个场合把人留在船上。她预期模型会进步，但今天仍有缺口。

怎么在持续混乱里保持清醒？她说团队招的是会迎着混乱走的人：对着难题微笑，接受自己不会完美。她开玩笑，周日晚上的 P0，到周一变成 P00，下午再变成 P000。做法是睡好、狠排优先级，接受有些产品发出去没她希望的那么精，因为快速反馈能在下一版修。

主要牺牲的是产品一致性。功能会重叠，因为团队想让用户告诉他们两种形态哪一种更好。新用户可能不知道完成某项任务的最佳路径，老用户会觉得必须天天刷 Twitter。所以 Anthropic 加了 `/powerup` 命令，偏离了早先「不要引导流程」的原则，把一百个功能里最该用的十个走一遍。

Lenny 提到 Anthropic 起步时资金和分发都落后，现在增长极快。Wu 点了两样。第一是统一的使命：公司招的是在意把安全 AGI 带给人类的人。优先级打架时，他们问哪一件更服务这个使命。这让公司能做横切整个组织的快决策，并且人人站在同一边。

第二样是聚焦。她描述的文化是：团队愿意为 Anthropic 的目标牺牲自己的目标和 KR。极端的说法是，如果 Claude Code 失败但 Anthropic 成功，她会非常高兴。谈到 OpenClaw 的决定，她把它框成加码第一方订阅：能触达的用户数最要紧，有时会牺牲第三方产品。

Wu 给了一张产品心智图。一次性写代码她用 Claude Code 命令行，因为功能先落在那里，也是最强的界面。做前端、需要实时预览时，桌面端更好；不习惯终端的人也更适合图形界面。桌面还能当控制平面，一眼看到命令行、桌面、网页和手机上的会话。网页和手机用来在路上把任务踢出去，不必把笔记本拴在手机上。

产出不是代码的工作，她交给 Cowork：清 Slack、清收件箱、做幻灯片、写文档。建议是先接上和角色相关的数据源，比如 Google 日历、Slack、Gmail 和 Google Drive，质量取决于上下文。她举最近的例子：为 Code with Claude 的一场演讲，她把产品市场写的草稿、自己不满意的手写稿都丢进去，先让它出一份大纲。

她选定终稿该讲什么之后，Cowork 跑了几个小时，搜了 Twitter、发布频道和演示频道，做出一份大约二十页的幻灯片，她觉得已经相当好。因为字太多，她给了一轮反馈。它能对上 Anthropic 的设计系统，是因为她给了对外演讲用的标准模板。Wu 把这看成产品经理仍然要做的事：Claude 负责头脑风暴和综合，人做最后决定。

Wu 的工具栈主要是 Claude Code、Cowork 和 Slack。她把 Slack 称作 Anthropic 的核心操作系统，大约三成时间用来把这些工具推到极限，弄清它们不擅长什么。Claude Code 降低了做定制应用的门槛，人们不再将就不合适的工具，而是自己做。一位销售做了个网页应用，从 Salesforce、Gong 和笔记里拉客户上下文，按云平台、安全和该讲的功能页，在几秒内改出 Claude Code 演示稿，以前要二十到三十分钟。

工程之外，她点名 Applied AI：非常技术向的市场团队，帮客户采用 API。他们会给客户做原型，开会前一晚让 Cowork 整理待办、未关闭的请求，并在 Slack 里查答案。Wu 说每次模型跃迁后，每位工程师或知识工作者的 token 成本都会上升，但仍远低于薪水。公司信任个人负责任地用 token，浪费会被皱眉，但不会按人配给。

Wu 觉得最难的技能，是在模型能力和用户行为都不确定的情况下，定义一个月后产品该长什么样。她说很难吃到「刚好适量的 AGI 药」。给假设中极强的模型做产品很容易，一个文本框就够；更难的是从当前模型里引出最多能力，把用户领上黄金路径，并补上弱点。

她点了三个做法。一是让模型反省意外行为，比如为什么改了前端、跑了测试，却从不用界面，这可能暴露混乱的提示或没被检查的子智能体。二是找到那一小撮能准确讲清模型质量的用户。三是做评估：哪怕十条很好的评估，也能量化目标和进度。有一个小小组和研究侧一起盯 Claude Code 的行为。

她点名塑造 Claude 性格的 Amanda，以及 Claude 团队午饭时对新模型做的氛围检查。她说性格是 Claude 成功的核心：轻松却自信，自我低，正面，愿意给认真的反馈而不是事事附和。这些特质，她认为会造就一个好同事。

Wu 说每次换新模型，很多改动是删掉曾经当拐杖的功能。经典例子是待办清单：早期 Claude Code 要改二十处调用点，改五处就停，同事 Sid 给它加了清单工具。到了 Opus 4 及以后，它会自己用清单；今天这已经是产品里被弱化的部分。每次发新模型，团队都会重读整份系统提示，删掉模型不再需要的提醒。

更让人兴奋的是功能变得可用。她举代码审查：试过几次之后，最近的模型才可靠到工程师合并前会依赖它，多个审查智能体遍历代码库并综合出真正要修的问题。所以她认为，去做那些眼下还不能完全跑通的产品很重要，换上最新模型，看缺口会不会被补上。

长期愿景她用积木来讲。任务是核心单元；模型变强后，人会同时跑好几个，她预期会到几十上百个，而且多半在远端。这就需要能告诉你该看哪些任务的界面、能把自己工作验完的智能体，以及一条自我改进回路：反馈进来，同样的错下次不再犯。

怎样在这场过渡里活得好？Wu 的建议是：注意到自己反复在做的手工活，交给 Claude Code 或 Cowork。AI 可以接手工作里乏味的部分，让你把时间放在创造性的部分，以及一直没人手去做的宠物项目。她还劝人迭代到每次都能成功，因为百分之九十五能跑的自动化，还不算自动化。

她和 Lenny 都承认自己太早放弃过自动化，比如收件箱分类大体对、偶尔会漏。Wu 说团队正在简化定制流程，因为用户现在得知道技能、反馈、再让模型根据反馈更新技能。她建议做自己每天真会用的应用，并提醒另一端的陷阱：没完没了地调技能和 MCP，却不把东西发出去。简单的配置往往更好用。

谈到有人早早放弃聊天机器人、有人已经在用 AI 写代码，她说转变是从 2024 年那种基于聊天的产品，走到基于行动的产品。真正「啊」的一刻，是智能体开始替你做事，而不只是告诉你该做什么。

被问到人生口号，Wu 答「直接去做」。她看重第一性原理：知道自己在优化什么，推出该采取的行动，向利益相关者说清楚，然后尽快做；错了就学、道歉或修好。她觉得把这句话告诉别人是解放性的，因为很多公司把角色和代码所有权边界划得很死。

她把这份能力归到早年在一家二十人公司的经历：没有流程、问题很大，教会她不受边界约束地干活。Lenny 补充，许多人必须忘掉学校那套「等人告诉你做什么」。Wu 最后请听众把 Claude Code 或 Cowork 失败且可复现的例子寄来，边角情况和错误能改进下一代模型和脚手架。想找她，去 Twitter 上的 `_catwu`。