Claude Code团队讲究啊，这都往外说

程浅 发自 凹非寺
量子位 | 公众号 QbitAI

话说。

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

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

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

△《How the Claude Code team uses Claude Code》访谈截图

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

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

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

“我们现在的工作层级，已经比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