Claude近期发布了一则访谈视频，披露Claude Code团队如何使用Claude code持续优化Claude code。访谈里，多名员工回顾了过去一年工作方式的变化，重点谈到在极快迭代节奏下如何做产品，以及人与模型之间的分工正如何被重新定义。
团队在访谈中给出的几句表述，概括了他们当前的判断：一是「你必须对自己正在构建的东西保持非常不执着的态度，因为它们很快就会消失」；二是他们所处的工作层级，已经比Claude实际输出的token高出一个抽象层；三是很多时候需要被迫放手，让Claude自己发挥，因为信任比监督更重要；四是既要站在技术前沿，又要为当下正在使用模型的人提供价值，这件事「一半是艺术，一半是科学」；五是软件工程始终是一个围绕problem solving展开的职业。
团队如何工作：把70%-80%的日常工作交给Claude Tag
按照团队的说法，目前他们已经将70%-80%的日常工作交给Slack原生的AI agent——Claude Tag完成。相比之下，一年前Claude Code的工程师还在逐行阅读AI的工作记录，包括每一次工具调用、每一个参数选择，以及每一步推理决策。
现在的核心方法已经变成：不再逐条审视tool call和模型决策，而是先给出一个goal，再由模型自己完成达成路径。团队提到，他们将用户界面与模型的思考记录彻底解耦。这样一来，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，再通过这种方式向用户发问。
产品结构调整：不做固定方案，改搭“原语”
面对模型能力持续变化带来的不稳定性，团队没有选择去构建一整套固定的解决方案，而是转向搭建一个个可自由组合的“原语”。访谈中提到的原语包括Permissions、Visualizations、Verification、Code Review、Feedback等。
这种做法的直接好处是，当某个原语已经过时、需要被替换时，付出的代价会更小。与此同时，这些原语在层层叠加、相互组合之后，也可能涌现出原本没有预设到的新能力。
人与AI交互的颗粒度在上移
如果要概括这一年里最大的变化，团队的说法是，人和AI打交道的颗粒度正在持续上移。最早关注的是token和具体工具调用，之后变成一次对话，也就是session；再往后是一个完整目标，即goal；到了现在，则演变为能够持续运行、跨越多次对话边界的工作系统。
这种抽象层级的抬升，也体现在两条并行演进的线索上。
第一条是基础设施路线的变化：从最早的本地运行，到远程开发机，再到托管容器，再到可以运行在云端容器中的网页版。团队给出的目标很明确，就是确保任务能够持续在后台运行，并完成日常例行任务，也就是routines。
第二条是代码审查方式的变化。工程师开始从更琐碎的代码审查中抽身，转而让Claude先大范围搜索尽可能多的疑似问题；随后，再围绕每一个疑似问题进行对抗性审查，并从三个不同角度做交叉复核，尽可能过滤噪音，把真正需要人处理的问题留下来。
这套思路后来又演变成workflows：由Claude自己编写代码，去编排多个子智能体之间的协作方式，把确定性的代码逻辑与智能体的自主判断结合在一起。
团队判断：软件工程始终围绕解决问题展开
访谈最后提到，Claude code团队里一些原本热衷于手工打磨细节的员工，如今已经放下了对「被取代」的执着，开始享受性能提升带来的效率变化。
团队给出的结论并不复杂：软件工程本质上就是一个关于变化的行业。被解决的问题在变，解决问题的工具也在变。十几二十年前，开发者还在手写没有任何框架的JavaScript；现在，变化只是更快了，但底层逻辑没有变。归根到底，工程师始终是一个围绕「如何解决问题」展开的职业。
这篇内容整理自Claude发布的访谈视频，MarsBit原文注明参考链接为YouTube视频，文章作者为微信公众号「量子位」的程浅。