Claude团队用AI自我迭代：快节奏产品开发之道

最近，Claude官方发布了一则团队访谈视频，主题正是Claude Code团队如何借助自身产品完成持续迭代优化。参与访谈的工程师们坦言，过去一年里他们的工作方式发生了彻底的改变，而这些变化也让他们对“要在非常快的迭代节奏下做产品”这件事有了更深刻的思考。访谈的画面温馨得像三位资深奶爸在讨论如何养育孩子，充满了对团队协作的从容和自信。这些实践对于同样处于快速技术迭代节奏下的团队来说，具有很强的参考价值。

据团队透露，目前他们已经将70%到80%的日常工作交给了Slack原生的AI代理工具Claude Tag来完成。而仅仅在一年前，Claude Code的工程师们还需要逐行阅读AI生成的每一份工作记录，包括每一次工具调用、参数选择以及每一步推理决策，繁重的工作量让团队倍感压力。

如今团队的工作核心已经转变为不再逐条审视tool call和模型决策，而是下达一个goal，让模型自行达成。为了让Claude Tag更像真实的Slack协作参与者，团队还将用户交互界面和AI的内部思考记录彻底解耦，AI的内部独白会被隐藏在界面背后，用户只能看到Claude调用工具发送的消息，无需关注其完整的思考流程。团队坦言，这种设计其实是有点吓人的强制性放手，被迫放手让Claude自己发挥，因为信任比监督更重要。

不仅如此，团队还在激进地用Claude Tag来开发Claude Tag本身。他们分享了一个内部工具开发的完整流程：首先向Claude Tag询问“我在想这样一个点子，我应该去找谁聊聊？谁会对这个感兴趣？”，AI会输出一份stakeholder的名单；完成沟通后，第二步直接让Claude Tag做原型示意图和具体实现；第三步则是添加大量埋点，将工具部署到内部环境中，观察“大家是怎么用这个的？有没有人给我反馈？”。后续Claude Tag还会持续监控工具的使用数据，一旦收到反馈就会主动提醒负责人，并自动提出“去改进这个转化漏斗，你自己想想办法”的优化建议。整个开发过程完全采用放养式管理，团队成员表示，到了当前的阶段，或许信任比监督更重要。

所有这些实践都建立在一个核心前提之上：底层模型的能力每两个月发生一次根本性跃迁。正如团队成员在访谈中提到的：“技术的地基每两个月就会在你脚下发生根本性的变化……你必须待在前沿，其实得越过前沿才能真正感受到那个边界。但与此同时，你又得为今天正在使用这些模型的人提供价值。”这种平衡既是一半是艺术，一半是科学。

基于这个前提，团队总结出了一条重要的工作准则：“你必须对自己正在构建的东西保持非常不执着的态度，因为它们很快就会消失。”很多写入系统的临时功能，本质上都是为了弥补当时模型能力的短板，一旦模型性能提升，这些临时功能就需要像脚手架一样被拆除。

比如to-do list功能，在Sonnet 3.5阶段，模型还没办法完成连续多步的复杂任务，因此需要给它一份待办清单来辅助规划工作流程；但仅仅一年后，模型就具备了更复杂的记忆能力，这个曾经的救命功能就像脚手架一样被拆除了。另一个典型案例是AskUserQuestion工具，最初是为了让Claude能在任务中途主动向用户提问而精心设计，但随着模型生成HTML的能力不断增强，开发者自然地转向让Claude直接生成带图表和mockup的可视化artifact来完成提问，旧的工具也就不再需要了。

面对不断变化的技术环境，团队没有选择搭建一整套固定的解决方案，而是转而搭建一个个可以自由组合的“原语”（primitive），比如Permissions、Visualizations、Verification、Code Review、Feedback等模块。这种架构的优势在于，当某一个原语过时需要替换时，付出的代价更小；并且当这些原语层层叠加、组合在一起时，往往会涌现出超乎意料的新能力。

如果要用一句话总结这一年里工作方式的最大变化，概而言之就是，人与AI打交道的颗粒度不断上移。团队成员提到：“我们现在的工作层级，已经比Claude实际输出的token高出了一个抽象层。”这种颗粒度的提升经历了四个阶段：先是关注单个token和具体的工具调用，再到一次完整的对话（session），再到一个明确的目标（goal），如今已经进化到“持续运行、跨越多次对话边界的工作系统”。

抽象层级的不断上升体现在两条并行的发展线索上：第一条是基础设施的演进，从最早的本地运行到远程开发机，再到托管容器，再到可以运行在云端容器里的网页版，确保了任务能够一直在后台运行，并完成例行任务（routines）；第二条是代码审查路线的演变，团队成员不再需要处理琐碎的代码审查细节，而是让Claude大范围搜索出尽可能多的疑似问题，再针对每一个疑似问题做对抗性审查，从三个不同角度做一次交叉复核，从而过滤掉大部分噪音，只把真正需要关注的问题留给人。这套思路后续也演变成了workflows，由Claude自己编写代码，去编排多个子智能体的协作方式，把确定性的代码逻辑和智能体的自主判断结合在一起。

目前，Claude code团队里那些热衷于匠心手作的员工们已经放下了“被取代”的执着，开始享受性能提升的快感。毕竟，软件工程是「变化的职业」。你解决的问题在变，但核心始终是problem solving。谁能想到？十几二十年前人们还在手写没有任何框架的JavaScript。如今，变化的速度快了些，但底层的逻辑始终没有变，归根结底——工程师，始终是一个关于“如何解决问题”的职业。

参考视频：https://www.youtube.com/watch?v=S-sYlFiGFv8