Claude Code团队讲究啊,这都往外说
量子位
2026-09-09
热度3942

Claude Code团队分享其在快速技术迭代下的工作范式转变:从逐行审查AI决策,转向以目标为导向、信任驱动的协作模式;通过构建可组合的抽象原语(如Permissions、Visualizations等)应对模型能力月级跃迁,强调工程师核心始终是问题解决而非固守具体实现。

摘要由 Mars AI 生成
本摘要由 Mars AI 模型生成,其生成内容的准确性、完整性还处于迭代更新阶段。

话说。

Claude发布了一则Claude code团队如何使用Claude code持续优化Claude code的访谈视频。

访谈中,Claude员工们对最近这一年工作方式的变化大发感慨。

由此重点谈到了他们如何看待“要在非常快的迭代节奏下做产品”这件事。

△(这画面温馨得像三个超级奶爸在讨论如何育儿。)

本文整理了这次访谈的核心内容,精华包括不限于:

“你必须对自己正在构建的东西保持非常不执着的态度,因为它们很快就会消失。”

“我们现在的工作层级,已经比Claude实际输出的token高出了一个抽象层。”

“被迫放手让Claude自己发挥,因为信任比监督更重要。”

““你必须既站在技术前沿,又为今天使用模型的人提供价值。这是一门艺术,也是一门科学。”

“软件工程是「变化的职业」。你解决的问题在变,但核心始终是problem solving。”

希望对同样处在快技术迭代节奏下的你有所启发。

团队现在是怎样工作的?

团队表示,当前已经将70%-80%的日常工作交给Slack(美国飞书)原生的AI agent——Claude Tag完成。

而一年之前,Claude Code的工程师还在逐行阅读AI的工作记录。

包括每一次工具调用、每一个参数选择、每一步推理决策……

(这工作量。)

他们现在工作的核心理念是:不再逐条审视tool call和模型决策,而是下达一个goal,让模型自行达成。

不知道这种理念是否与Claude Tag产品设计有关,或许是为了让它更像一个真实的Slack参与者,他们将用户界面和模型的思考记录彻底解耦了。

如此,AI的内部独白将被Slack界面隐藏起来,人类看到的每一条消息,只是Claude在调用发消息的工具,它真正的思考过程并不会实时展示。

团队认为这是一种有点吓人的强制性放手

与此同时,他们也在激进地使用Claude Tag开发Claude Tag自身。

随之举了一个新内部工具的开发案例,很有意思:

第一步是问Claude Tag:“我在想这样一个点子,我应该去找谁聊聊?谁会对这个感兴趣?

Claude Tag交付了一批stakeholder的名单

聊完之后,第二步就直接让Claude Tag做原型示意图和具体实现

第三步,让Claude Tag加入大量埋点,把工具部署到内部使用,观察“大家是怎么用这个的?有没有人给我反馈?”

此后,Claude Tag会持续监控这个工具的使用数据,一旦收到反馈就会主动提醒负责人,同时让它“去改进这个转化漏斗,你自己想想办法”。

总之就是一个纯粹的放养型,他们表示,到了现在这个阶段,或许信任比监督更重要

核心要义是“不恋战”

实际上,所有的问题都要放在一个前提下去考虑。

底层模型的能力每两个月发生一次根本性跃迁。

“技术的地基每两个月就会在你脚下发生根本性的变化……你必须待在前沿,其实得越过前沿才能真正感受到那个边界。但与此同时,你又得为今天正在使用这些模型的人提供价值。”

而这是一种平衡,一半是艺术,一半是科学。

由此带来的一条工作准则是,“你必须对自己造的东西保持非常不执着的态度。”

毕竟很多写进harness里的功能,本质上是为了弥补当时模型能力上的短板,一旦模型变强,这些功能就需要立刻拿掉。

一个很经典的案例就是to-do list功能。

在Sonnet 3.5阶段,模型还没办法完成连续多步的复杂任务,因此需要给它一份待办清单。

但一年之后,模型具备了更复杂的记忆能力,这个曾经的救命功能就像脚手架一样被拆除了。

另一个例子是AskUserQuestion工具。

最初是为了让Claude能在任务中途主动向用户提问而精心设计,但模型生成HTML的能力变强之后,开发者自然地转向让Claude直接生成带图表和mockup的可视化artifact来提问。

面对如此摇摇欲坠的现实,团队采取的方法是不再去构建一整套固定的解决方案,而是搭建一个个可以自由组合的“原语”(primitive)。

比如Permissions、Visualizations、Verification、Code Review、Feedback……

这样做的好处是,当某一个原语过时、需要替换时,付出的代价更小。

并且,当这些原语层层叠加、组合在一起时,往往会涌现出超乎意料的新能力。

工程师的核心永远是Problem Solving

如果非要说这一年里工作方式的最大变化,概而言之就是,人与AI打交道的颗粒度不断上移

先是token和具体的工具调用,到一次对话(session),再到一个完整的目标(goal),再到如今的“持续运行、跨越多次对话边界的工作系统。”

抽象的层级在不断上升,这一点也体现在两条并行的线索上。

第一条是基础设施的演进,从最早的本地运行到远程开发机,再到托管容器,再到可以运行在云端容器里的网页版,确保了任务能够一直在后台运行,并完成例行任务(routines)。

第二条是代码审查路线的演变。

人从更琐碎的代码审查中得以抽身——让Claude大范围搜索出尽可能多的疑似问题,再针对每一个疑似问题做对抗性审查,从三个不同角度做一次交叉复核,从而过滤掉大部分噪音,只把真正需要关注的问题留给人。

而这套思路后续也演变成了workflows,由Claude自己编写代码,去编排多个子智能体的协作方式,把确定性的代码逻辑和智能体的自主判断结合在一起。

目前,Claude code团队里那些热衷于匠心手作的员工们已经放下了“被取代”的执着,开始享受性能提升的快感……

毕竟,软件工程本质上就是一个关于变化的行业,尽管解决的问题一直在变,解决问题的工具也一直在变。

谁能想到?十几二十年前人们还在手写没有任何框架的JavaScript。

如今,变化的速度快了些,但底层的逻辑始终没有变,归根结底——

工程师,始终是一个关于“如何解决问题”的职业。

参考链接:[1]https://www.youtube.com/watch?v=S-sYlFiGFv8

本文来自微信公众号“量子位”,作者:程浅

本内容旨在传递行业动态,不构成投资建议或承诺。
为你推荐

商务合作:TG:@Lottie96