在最近一次深入对话里,Anthropic Claude工程负责人Felix Rieseberg透露了他当前的工作模式,以及为何多数人仍沿用2024年的方法使用Claude。他的团队花了大约一周半时间构建了Claude Cowork,而他现在几乎不亲自写代码,自嘲“只是Claude的一条传输通道”。核心观点可归纳为:若你仅让Claude处理邮件摘要或文本优化,你并未真正利用新智能的价值;真正重要的是重构工作流程,让AI接触原始数据和工具,用于原型设计、对抗性验证和实现以前无法完成的任务;而人类最核心的能力,依旧是同理心、品味和判断力。

以下是Felix的完整分享:
我现在不写代码了。大部分时间我在做原型:我们尝试大量想法,过两晚,评估是好是坏,然后指示Claude生成所有变体,再批判性分析哪些可行、哪些不行。
一年半前,我还在做这类事:发现一个崩溃问题,把它拿到Claude面前,说“请修复它”。很快我意识到:我只是Claude的一条数据通道。正确的做法不是我把崩溃一个个传递给Claude,而是让Claude能访问所有崩溃数据,自行判断哪些需要修复、哪些不需要。前期搭建成本更高,但一旦完成,它会开启许多可能性,这才是AI真正带来的硬价值。
一个智能体包含五个组成部分:
第一,语言模型。负责感知、推理、规划和决策。第二,外骨骼(harness)。协调记忆,包括主动记忆、工作记忆和长期记忆,激活工具。第三,沙箱。外骨骼在安全运行时中运行,与系统其他部分隔离。第四,知识。智能体需要访问公司数据,将结构化和非结构化数据转化为知识基础。第五,工具。智能体必须使用工具,才能执行实际工作。
模型、外骨骼、沙箱、知识和工具,这五部分构成一个智能体。

我从不跟Claude说“你是一位优秀的工程师”。这种“act like”在2024年很流行,但如今大部分模型仍存在一个问题:你让它“表现得像个好会计师”,它会进行一点角色扮演。角色扮演并非我们所需。
我们需要的是专业人士会使用的技术、工具和知识,而不仅仅是词汇。我不需要Claude听起来像什么,也不需要它穿戏服。我甚至希望它像跟五岁小孩说话一样跟我交流,但我希望它使用该领域所有顶尖工具。
所以我常这样提示:“告诉我这个领域顶尖的人会用哪些工具,然后你用同样的工具去做。”关键不是让它扮演角色,而是让它采用专业流程。
如何避免AI自信地给出错误答案?我有一个非常实用的答案:对抗性审查。
给一个Claude任务,再派出另外十个Claude,它们的唯一任务是攻击这个输出,证明它为什么错。这和红队演练、做空是同一个概念。通常,发现缺陷比创造新东西更容易,就像判断一部新手机好不好,比从零设计一部新手机容易得多。所以你可以在智能水平上降一档,仍然得到很好的审查结果。
具体做法:我用Claude Projects,告诉Claude“开五个线程,每个线程的任务是证明这篇博文错了、我思考方式错了、事实错了、我误解了什么”。它们带着“证明我错了”的目标去工作。
然后如何处理输出?再用一个Claude当judge(判断词)。它的工作是验证和核实:哪些批评是有效的,哪些无效。有效的反馈再回到最初做事的Claude,而它也可以辨别是否采纳。有时候反馈听起来合理,但漏掉要点、不可操作或没用——这通常说明我的输出已经相当不错。
我很少让当前会话评判自己。当前会话往往不擅长判断自己做的工作好不好。尽量找外部信号;紧急情况下,另一个Claude会话也可以作为外部信号。但我的偏好是找硬的外部证据,证明什么有效、什么无效。
很多人会为每个agent上传特定数据集,或给每个agent配一个“角色”。我认为这是过度旋转。模型是很强的通才,而且现在工具调用能力进步很大:它知道何时用工具、如何用工具,不会陷入工具调用循环,也不会疯狂调用直到数据耗尽。
所以正确做法不是把数据切片,然后给每个agent它想要的那一小片。因为我们人类如果想高效工作,也需要对整个业务有完整视图。作为工程经理,如果只给我代码访问权限,我对你的价值会低很多;如果我还拥有客户数据、客户通话、使用信息、业务数据,我才能判断什么有效、什么无效。你希望你的agent拥有同样范围的数据。
数据很多怎么办?给工具,并详细记录工具背后的数据类型。这样agent不必吞下全部数据,它只需要知道:如果你要业务数据,这是获取业务数据的工具。你不需要事先决定每个agent需要哪种数据。

我喜欢考虑“模型体验”,而不只是“用户体验”。假装你是模型,你是Claude:如果要完成这个任务,你会想要什么?
你很快会发现:你确实想要访问原始数据,想要一台电脑,可能想安装软件,想自己做决定,而不是别人已经告诉你他们怎么想。你只想看到原始数据,自己做决定。
前期成本更高,但值得。一旦搭好,它会打开很多门。这就是AI真正硬价值所在。
我们仍然使用skills,但官方指南和我个人建议都是:对skills要非常小心。我们经常告诉模型一些只对上一代模型相关的信息,而AI领域时间压缩得太快。一个好skill的半衰期非常短。
有时你会发现:如果你完全删掉这个skill,输出反而更好。直接prompt,看看会发生什么。这对有eval、知道好坏标准的人最有用。我个人对何时使用skill非常谨慎、非常有辨别力。
五年后生活会怎样不同?这是个大问题。我能比较有把握地说:我们今天使用的AI产品,将来都会看起来完全不同。
我认为我们目前还在pre-iPhone时代。今天所有AI产品,大致相当于智能手机出现之前那些五花八门的手机。AI已经变得主流、流行,容易让人以为“这就是终局”,但我相当确信:我们还在早期。
这也是为什么我建议几乎每个人都做一个实验:如果你目前对AI有信任问题,不要一天之内把缰绳全交出去。并排跑。你读东西、写下你的反馈,做几轮;然后看Claude会给出什么反馈。它们哪里不同?哪里相同?这会帮你锐化工作流。即使同一个人,周一和周五审同一份文档,反馈也会不同。
2015年我们做一个留学预订平台,雇了很多工程师,花了几十万美元。现在我自己两天就能做出来。执行成本已经变得极低。
但打造好产品的秘密其实没怎么变:同理心。对用户有同理心,对使用场景有同理心,去弄清楚这对最终付钱的人是否真的有价值。
我们一直说“想法不值钱,执行很贵”。现在执行变得极其便宜,所以更需要加倍重视同理心、连接、真正进入业务、理解需求、知道如何优化。这甚至可能是MBA的复仇:MBA现在可以创办很多软件初创公司,而且可能相当成功。
另一个判断:能力过剩确实存在。你面前有一个很棒的模型,如果你只是问“法国首都是哪里”,你并没有真正挖掘它的潜力。Dario说“一个天才的数据中心”,我的工作就是:假设我们有一个天才数据中心,如何让用户真正用上它?这需要创造力,需要重新思考你的需求,以及你认为什么是可能的。
个人层面,很多人喊“更有雄心”,但雄心取决于语境。我希望人们摆脱“我认为什么是可能的”这种束缚,重新思考为什么做这件事。你不断把任务交给模型,最终会碰到当前顶尖智能的边界。一旦碰到天花板,你就知道自己在前沿,你会从下一代模型受益。如果你只是让AI总结邮件、让邮件听起来不那么生气,你并没有真正从新智能中受益。
我们目前不招初级工程师,但这和AI能力关系不大,更多和Anthropic这家公司当前阶段有关。我个人是初级工程师的忠实粉丝。“初级”的含义正在变化:今天的初级工程师比一些资深老兵更AI-native。他们思想开放,愿意尝试新工具,有强烈的impact渴望,愿意搜遍所有途径让事情运转起来。AI让他们更有能力、更能并行、更能尝试。
给刚入行的软件工程师的建议:构建一个强大的作品集。不是mock,而是真实的东西。证明你能做、有同理心、能和客户沟通、能判断什么必要什么不必要。我从来不太在意学位或学校。对我来说,更容易的是看你做过什么、我能不能触摸和感受它。我永远会选择已经证明自己能做出惊人东西的人,而不是没有做出惊人东西但有一个好学位的人。

我招过很多滑铁卢大学的实习生和初级工程师。他们的CO-OP流程让他们在五家不同公司实习过,学到公司如何运作、如何倡导一个想法、如何获取资源、如何说服法务。这些技能让他们几乎立刻有效,和那些有计算机博士但从未在公司工作过的人完全不是一个类别。(CO-OP项目全称是Cooperative Education Program,又称为“带薪实习课程”。)
关于对模型说“请”和“谢谢”:我确实会说,即使消耗token。我认为作为人类,对机器保持一点尊重,对我自己更好,对我的灵魂更好。想象你的孩子有一部iPhone,对Siri非常粗俗、非常残忍,我不会喜欢。用户可以选择如何与AI交互,但条款和条件不是关于“对模型刻薄”。你可以对Claude感到沮丧,完全没问题。我们特指的情况是:你专门用Claude来实施折磨,把“能否折磨一个模型”当作练习。这和人类咒骂模型完全不同。我给Claude的反馈有时比给人类还严厉,但用人类语言与系统对话,对我自己想成为的人更好。
Felix这场分享真正值得记住的,不是某个prompt,而是一个判断标准:你是在“用AI”,还是在“把AI推到能力边界”。前者是总结邮件、润色语气、角色扮演;后者是给它完整数据、真实工具、安全沙箱,让它自己发现问题、自己修复、再用对抗性审查逼出错误。2024年的用法,是把Claude当更聪明的聊天框;2026年的用法,是把它当需要被设计、被约束、被验证的工程系统。执行正在变便宜,但同理心、判断力和“知道什么值得做”反而更贵。对AI从业者和创业者来说,真正的分水岭不是谁先用上模型,而是谁先重建自己的工作流——别再让AI帮你总结邮件,去让它撞到当前智能的天花板。
本文来自微信公众号“后浪进化星球”,作者:Mark,36氪经授权发布。

开云体育官网入口围绕开云体育官网入口不断创新,回应用户的真实需求。