Claude Code 团队自曝工作方式：把七八成日常活交给 AI，对代码「不恋战」

量子位 2026-09-18T00:15:14.228474

Anthropic 放出了一段访谈，主角是 Claude Code 团队，话题是他们如何用 Claude Code 持续优化 Claude Code。核心方法可以浓缩成两句话：给 AI 下目标、而不是逐条检查它的每个动作；对自己造出来的东西保持「不执着」，因为模型能力每两个月就会变一次天。

一年之内，工作方式被彻底改写

在这段访谈里，Claude 员工聊得最多的是过去一年工作方式的变化，以及一个更本质的问题：在极快的迭代节奏下，产品到底该怎么做。

他们自己整理出的几条心得，基本就是这套方法论的骨架：

团队给出的数字很直接：70%~80% 的日常工作，已经交给 Slack 里原生的 AI agent——Claude Tag（可以理解为一个常驻在聊天工具里的 AI 同事）来完成。

而仅仅一年前，Claude Code 的工程师还在逐行阅读 AI 的工作记录——每一次工具调用、每一个参数选择、每一步推理决策，都要人来看。

现在的核心理念是：不再逐条审视工具调用和模型决策，而是给出一个目标（goal），让模型自己想办法达成。

这套思路很可能也影响了 Claude Tag 的产品设计。为了让它在 Slack 里更像一个真实的人类参与者，他们把用户界面和模型的思考记录彻底解耦了：AI 的内部独白被 Slack 界面挡在后面，人看到的每一条消息，只是 Claude 调用「发消息」这个工具的结果，真正的思考过程不会实时展示。

团队自己的评价是，这是一种「有点吓人的强制性放手」。

他们同时在激进地用 Claude Tag 开发 Claude Tag 自己。访谈里举了一个内部新工具的例子，流程很能说明问题：

整个过程接近放养。团队的说法是，到了这个阶段，信任可能比监督重要。

所有判断都要放在一个前提下：底层模型的能力，大约每两个月就会发生一次根本性跃迁。

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

这中间的平衡，一半是艺术，一半是科学。由此推出的一条工作准则就是：对自己造的东西保持不执着。

原因很实在：很多写进 harness（包在模型外层、负责调度和约束模型行为的那套代码）里的功能，本质上只是在补当时模型能力的短板。模型一升级，这些功能就该立刻拿掉。

最经典的例子是 to-do list（待办清单）。在 Sonnet 3.5 阶段，模型还无法完成连续多步的复杂任务，所以需要给它一份清单来「扶着走」。一年之后，模型具备了更复杂的记忆能力，这个曾经的救命功能就像脚手架一样被拆掉了。

另一个例子是 AskUserQuestion 工具。它最初是精心设计出来、让 Claude 能在任务中途主动向用户提问的；但当模型生成 HTML 的能力变强之后，开发者很自然地转向让 Claude 直接生成带图表和 mockup 的可视化 artifact 来提问。

面对这样摇摇欲坠的现实，团队的做法是：不再去构建一整套固定的解决方案，而是搭建一个个可以自由组合的「原语」（primitive）——也就是最小的功能积木块。这样做的好处是，当某个原语过时、需要替换时，付出的代价要小得多。

并且，当这些原语层层叠加、彼此组合时，往往会涌现出意料之外的新能力。

如果说这一年在工作方式上最大的变化，一句话概括就是：人与 AI 打交道的颗粒度在不断上移。

一开始是人手去调 token、去指定具体调用哪个工具；接着是一次完整的对话（session）；再往后浓缩成一个完整的目标（goal）；到今天，已经变成一套"持续运行、能跨越多次对话边界的工作系统"。

抽象的层级一路往上抬，这一点在两并行线索上都能看出来。

第一条是基础设施的演进：从最早在本机运行，到远程开发机，再到托管容器，再到能跑在云端容器里的网页版——目的都是让任务能在后台持续运行，把例行工作（routines）自动完成。

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

人从琐碎的代码审查中被解放出来：先让 Claude 大范围搜出尽可能多的疑似问题，再针对每个疑似问题做一次对抗性审查，从三个不同角度交叉复核，过滤掉大部分噪音，只把真正需要关注的问题留给人。

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

目前，Claude Code 团队里那些偏爱匠心手作的成员，已经放下了"被取代"的执念，转而享受性能提升带来的快感。

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

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

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

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