mt logoMyToken
ETH Gas
日本語

Anthropic:很多内部产品从未发布

収集collect
シェアshare

作者:数字开物

近日, Anthropic 向美国证券交易委员会(SEC)公开提交了S-1招股书。招股书称,企业客户把Claude嵌入业务关键流程,带来了比消费级AI更强的留存和更高的变现。聚焦企业市场、孵化Claude Code,是Anthropic研究与实验室团队的两项产品实践,近日,Anthropic研究与实验室团队产品负责人Dianne Na Penn做客播客The Skip,团队负责从Claude 2到Claude 5.5家族的核心模型产品,并参与Claude Code、MCP、Skills、Claude Design等产品的孵化与扩展。本次对话探讨了研究驱动型公司的月度规划与长期假设、Claude Code从基层探索走向产品的过程、研究优先级与用户反馈之间的取舍、Anthropic内部的产品经理文化、前线部署工程师PDE的角色等话题。

Dianne Na Penn表示,Anthropic不会花三个月去制定一份两周后就作废的年度计划,而是以月度为单位规划,并建立在对未来6到12个月行业走向的高层假设之上;产品团队也没有陷入“有人发布了某项功能,明天就必须照做”的短期循环。

在产品孵化上, Claude Code 并非某天突然诞生,而是 API 客户、内部与外部人员长期试错的结果,命令行终端的交互范式加上让模型执行更多 Agent 循环的 Harness ,才真正产生了化学反应。团队曾就是否提供微调 API 激烈讨论,核心考虑是模型迭代太快,企业自行后训练、部署时往往已落后两到三代。

此外,研究优先级与用户反馈之间的取舍,主要靠与研究主管的持续讨论,产品经理的价值在于讲清问题对用户的冲击,而不是替研究团队指定训练参数;团队还通过集体休假、两人结对负责同一业务线等做法,应对高强度的工作节奏。

面对快速变化的行业,对产品团队帮助很大的一点,是 Anthropic 的研究组织同样具备中长期的战略思维。 Dianne Na Penn 介绍,公司的研究使命和北极星目标着眼长远,形成了一种有益的拉力,防止团队陷入“今天发布了 X 、 Y 、 Z 等功能,明天就必须照做”的短期应对循环。

具体到规划方式,团队更多以月度为单位,聚焦当月要达成的目标,但这建立在对未来六到十二个月行业走向的高层次判断之上。 Dianne Na Penn 说,团队不会花三个月制定一份两周后就作废的年度计划。早年曾尝试完整的 OKR 流程,要求所有人对齐同样的 OKR ,但随着对使用量和采用率的假设被证明严重偏低,这些 OKR 很快被抛诸脑后。

理想的工作方式是:先确定三到六个月维度上的核心假设,再分解到每个月,在保持对市场敏捷响应的同时,通过逐月计划向长期目标推进。以生命科学领域为例, Dario 等人经常谈到 AI 将在帮助生命科学机构攻克疾病方面发挥巨大作用,这不是短期项目,但需要转化为具体行动,比如每月需要进行哪些模型训练或产品投资测试,如何确保科学家和研究人员能够访问这些模型,同时兼顾对早期市场动态的响应。

Claude Code 的诞生,是理解 Anthropic 产品开发方式的一个样本。 Dianne Na Penn 认为,产品开发更偏向由基层探索驱动,因为这项技术及其生态存在无数种泛化的可能。在 Claude Code 出现很久之前,就已有 API 客户用模型做代码自动补全,写代码并非某天突然具备了 Agent 属性,而是经历了内部和外部人员不断试错的不同阶段。命令行终端这种交互范式,加上允许模型执行更多 Agent 循环,通过产品体验的 Harness 与模型能力结合,才真正产生了化学反应。

优先级的判断,很大程度取决于团队坚持押注的核心主题,以及能否快速验证当前技术栈在体验或效果上是否可行、用户是否感受到足够的惊喜。目前的策略更聚焦 To B 和企业级市场,原因是与瞬息万变的消费者市场相比,企业端的需求更具稳定性。

不做什么同样重要。团队曾就是否提供微调 API 进行过激烈讨论,由此形成的产品思路是:核心模型迭代太快,等企业团队摸索出如何自己后训练、优化并部署模型时,可能已落后两到三代,到头来只能推倒重来, Dianne Na Penn 因此反问,这对公司、用户和客户而言是否是明智的投资。不断追问“三个月或六个月后会发生什么变化”,帮助团队理清什么产品值得推向市场;不少内部开发的原型最终没有对外发布,因为首要目的是激发创意或进行技术验证。

研究人员看的不只是眼前的用户。 Dianne Na Penn 指出,前沿 AI 实验室的研究人员思考的绝不仅仅是短期的现有用户,很多时候放眼的是尚未出现的用户群体,以及技术的二阶影响,尤其是在模型安全与对齐等领域。当团队内部达成共识,即服务的不仅是当下的用户盘,也是未来的用户生态,很多问题就迎刃而解。

举例来说,产品团队提出“为什么 Claude 输出 JSON 或 Schema 格式时不能做得更好”,可能意味着研究员要停下手头开发计算机控制或优化推理能力的工作,这不像传统 PM 路线图那样按部就班就能改善现有体验,而是在更长远的技术赌注与当前训练投资之间做权衡。评估一个问题时还要判断,随着模型智能的自然进化,它是否会自动降级、不再是 P0 级别, Dianne Na Penn 坦言,这对习惯规划完美路径的 PM 来说是令人沮丧的答案。

以记忆功能为例,两年前团队常收到“ Claude 没有很好发挥记忆功能”这类宽泛反馈,如今仍会听到,但背后的技术复杂性已不可同日而语。若记忆表现不佳直接导致用户流失,团队不会袖手旁观,也许可以从产品角度另辟蹊径,比如适当限制使用场景,在等待新一代模型能力跃升的过程中,让用户依然获得尚可的体验。总结起来有三点:必须兼顾不同生命周期的用户;必须承认与基于成熟技术做产品相比,这种充满不确定性的开发有时确实令人沮丧;最重要的是建立认知模型,明确终极目标和自身可控的手段,而不是迷信修改底层研究永远是唯一且最优的解法。

决策主要靠讨论。在训练每一个新版本的 Claude 期间,团队都与研究主管们举行定期站会,追踪训练进度,探讨需要调整什么、哪些有十足把握。产品经理的价值在于说明某个问题为何是 P0 :它对用户影响巨大,不解决就无法交付预期成果;反之,如果只在极小撮用户中听到抱怨,或者相关功能使用频率本身在萎缩,就可能判为 P2 ,转而设计替代路径。 Dianne Na Penn 强调, PM 无权越俎代庖要求研究团队修改某项训练参数,就像不会有工程团队接受被要求一行一行按指令写代码, PM 要做的是讲清楚问题会给用户造成怎样的冲击,再共同寻找解法,如果提示词等手段无法缓解,最终才落到调整模型训练上。

招人时,背景多元是团队的共同点。许多产品经理的职业轨迹并非在同一家公司按部就班晋升,而更像一场跨界探索,这赋予他们极强的适应能力,因为技术在飞速变化,以往的假设时刻被打破。其中有一类人擅长快速掌握新事物,或者曾在初创公司担任一号产品经理, Dianne Na Penn 认为这种履历极具竞争力,因为首位产品经理往往要兼任客户成功、 IT 运维甚至商务拓展,这种身兼数职锻炼出的敏捷性正契合团队需求。团队也招过前研究员,以及在一家公司待了很久、渴望打破对产品和工作流固有认知的员工。

入职之后,门槛同样不低。加入团队并不意味着入职第一天就能轻车熟路地做回老本行, Dianne Na Penn 在新员工入职计划里明确说过,前两个月应当是职业生涯中最煎熬的时期,如果感到痛苦,说明状态是对的,因为节奏极快,既要在短期目标与瞬息万变的中长期规划之间找平衡,又要为所负责的业务线制定产品计划、战略路线图并交付成果。

团队会刻意安排极具挑战性的初期适应任务。能迅速适应的人很快进入发展快车道,而抱怨“太难了”、以种种原因做不到的人往往会越来越吃力,入职一两个月内基本就能摸清潜力,归根结底考验的是成长型思维。

被问及那些感到吃力的人通常卡在哪里, Dianne Na Penn 指出,尤其是来自大公司的产品经理,习惯了等级森严的工作模式:副总裁下达指令,执行链条便盲目执行,很少有人停下来质疑这项指令是否仍是当前的正确选择。这与最接近其研发模式的学术界截然不同,在学术界,哪怕是一年级博士生也敢质疑导师。

在 Anthropic ,员工需要打破固有的层级观念,敢于向首席科学家 Jared 表达意见,比如读了他关于某项技术的文章后,指出忽略了几个前提假设,并提出调整后对用户更有价值。这要求在早期就发声参与讨论,而不是默认高管们已经把一切都想透了;表达必须建立在好奇心与互信的基础上,而不是武断地指责别人错了却给不出细节论证。团队想要的是能融入深度探讨、补充新视角、在原有基础上迭代并推动落地的人。大家最先抛出的点子,可能正是两三年前考虑过但被搁置的,但如果有人愿意下苦功钻研、以得体的方式质疑固有假设并提出独到见解,往往能大获成功。

这种风气的根源, Dianne Na Penn 认为既与模型迭代频繁有关,但归根结底来自企业文化:公司以研究实验室起步,许多联合创始人极度推崇 第一性原理 ,这项技术之所以取得今天的突破,正是因为没有被过去的假设局限,勇于质疑假设并通过亲手做实验验证,是顶尖研究人员之间最核心的运转逻辑。内部沟通极度透明,大多数频道完全公开,当你在群里讨论某个产品细节时,一个你没注意到的人可能会礼貌插话,问大家是否考虑过另一种方案,团队推崇相互肯定、不断延展思路的协作。

关于成功的产品经理,还有一点是对这项技术近乎狂热的痴迷:一入职就在原型阶段深度试用自家产品功能,或反复测试最新模型并公开分享评测心得,用实际行动而不是嘴上功夫证明如何优化产品和模型。相比躲在角落里写需求文档,积极下场推动模型和产品落地,才是顶尖产品经理脱颖而出的标志。

不少初级产品经理抱怨大环境差、好岗位少,但 Dianne Na Penn 的观察恰恰相反:团队里资历较浅的产品经理展现出极高的工作效率和无穷的潜力上限,原因是不需要刻意摆脱固有组织架构的束缚,在这里无需苦等别人发号施令,或等老板在需求文档上签字才推进下一步。干劲十足、主观能动性强的人会想“这是我负责的模块,就要保证落地”,主动去与客户沟通、与研究员对接,不管对方是不是研究主管。

相比大公司背景的产品经理,这些人不需要走那么多先拉齐各团队、一步步走过场的核对流程,轻装上阵往往极为高效。不过这并不意味着中高阶资深产品经理不具备这些特质,团队里既有创过业的前资深产品经理,也有在内部攻克过艰巨项目、真刀真枪拼杀出来的人。

在 Dianne Na Penn 看来,核心在于是否做成过一件需要克服庞大组织惯性和阻力的事情,那种死磕到底的毅力和使命必达的态度,往往比其他任何特质都更具杀伤力,这意味着会永远保持好奇心、千方百计寻找答案,在面对未知难题时实现自我驱动,而不是被动等待。

培养上,团队的出发点是对产品管理的定义。 Dianne Na Penn 表示,要回归到一项新技术最初期的状态,而不是机械框定岗位职责,最核心的原则依然围绕用户,即如何以具备 复利效应 的方式为用户创造价值,其他执行动作都由此衍生。也许一年后写模型评测就不再是定义用户成果的最佳形式,也许每个人都要直接写代码搭原型,但北极星目标不变。

入职流程极度高压:新员工要在最初的两到三周内完成用户调研、编写模型评测并制定产品路线图,常有人问能否再宽限两周,但这恰恰是为了逼出执行力,让他们进入必须跟上公司节奏的实战状态,事实证明很管用。同时,新人会被直接放到最高优先级的核心业务线上,团队偏向保持小规模,让每人同时兼顾两三个方向,倒逼跨部门沟通、碰撞想法和快速学习,也带来极强的交付紧迫感。

团队每年还举办一次训练营,核心是分享如何打造能驾驭指数级增长的产品,即随着模型底层能力提升,产品价值也会呈指数级爆发,内容包括如何优化 Claude 、编写高质量提示词和做模型评测,课程录制后成为每位新员工的必修课。这项倡议起于 2024 年,当时团队只有四五个人,日常工作已开始变得更像研究型 PM ,比如阅读用户授权的反馈数据、编写评估,既然对产品功能大有裨益,就想让更多人掌握,于是把操作步骤、重点指标和价值不大的部分记录下来,最初只面向研究型产品团队之外的 PM ,现在已对 Anthropic 全员开放。

训练营也是搭建开放问答平台的契机。 Dianne Na Penn 强调, PM 不必单纯等待模型迭代,完全可以通过修改提示词获得想要的结果。现场演示降低了门槛、打破了技术神秘感,连销售团队参加后都感叹“原来这就是评估,这就是提示,我也能做”。这些方法完全可以被复制并规模化推广,任何一家公司都能做到。

在导师制方面,新员工有团队资深员工一对一带教,并借助 Claude Tag 等内部工具协助入职。新人常被建议去翻过去两个月的群聊记录,因为加入公司就像是中途加入一场热烈进行的对话,最高效的做法是先做足功课,再表达自己对业务背景的理解并征询意见,主动融入,而不是等着公司把知识喂到嘴里。

对于产品经理是否应深入一线、嵌入客户场景, Anthropic 配备了前线部署工程师和专门的前线部署团队,协助企业客户在平台或应用端大规模落地。 Dianne Na Penn 认同这种深耕一线的技能必不可少,但现实的矛盾在于,在一端扎得过深,就不可避免要在另一端妥协。对此常感到撕裂:既想紧跟每一次研究模型迭代,又想倾听每个客户的反馈,在目前的体量下已无法旁听每一个客户的电话会议。

关键问题是,业务前线的深度洞见如何有效向上反馈,并反哺所负责的产品。团队会直接面向 API 客户和试用新模型能力的尝鲜客户收集反馈,但精力和产能不允许做完全专职的前线部署,因此与一线业务团队紧密协同,把他们的洞见作为补充验证。目前的模式更侧重全景式的业务上下文共享,而不是要求每位 PM 既扎根客户前线、又对齐顶级研究团队,要在两端都达到极深的专业度极其困难。

一条有效的经验是,团队后来从内部应用型及前线部署工程团队中选拔了一批人转岗担任 PM ,表现惊艳:他们有深厚的业务体感,深入理解 Harness 的原理、用户端的应用架构和使用动机,能顺畅地把一线声音反哺给研发团队。 Dianne Na Penn 回忆, 2023 年 Claude.ai 刚推出、还是唯一的内测产品时,系统提示词有很长一段时间是自己亲手在写,后来才交给新加入的 PM ,这其实就是前线部署工程师的日常。技术深度抽象地谈往往空泛,想要落到实处,最扎实的办法也许就是去做前线部署工程师、贴身倾听客户,这或许是重塑 PM 职业路径的一种答案。

免責事項:この記事の著作権は元の作者に帰属し、MyTokenを表すものではありません(www.mytokencap.com)ご意見・ご感想・内容、著作権等ご不明な点がございましたらお問い合わせください。
MyTokenについて:https://www.mytokencap.com/aboutusこの記事へのリンク:https://www.mytokencap.com/news/606353.html
community_x_prefix
X(https://x.com/MyTokencap)
community_tg_prefixcommunity_tg_name
(https://t.me/mytokenGroup)
関連読書