Claude Code团队实测：AI智能体如何重塑软件开发全流程

从接管单个函数到承接复杂目标

Claude Code团队的几位核心成员在一次对谈中回顾了过去一年的变化。一年前，他们还在反复给Claude Code提示、给出反馈、手动点击权限确认；而现在，团队的工作重心已经完全转移。

一位成员提到，自己70%到80%的工作都在Claude Code（及其Slack原生形态Claude Tag）上完成，剩下20%才会打开TUI或桌面端做精细调整。更根本的变化在于交互层级的抬升——从前团队极度关注每一条transcript、每一次工具调用、每一个模型决策，现在则是"我有一个目标，把目标交给模型去实现"的放大视角。

丢给模型的任务也从"实现这个类""写这个函数"，升级为复杂得多的工程挑战。Slack原生的形态让智能体能够主动查找产品上下文、团队此前做过的产品决策，从而让决策质量显著提升。

技术保鲜期从数年压缩到两个月

团队成员坦言，做Claude Code与做以往的软件产品有本质差异。过去一个产品底层技术的"保鲜期"以年计，你可以有信心它能撑好几年；但AI模型的技术每两个月就会在你脚下发生根本性位移，而且这个压缩速度还在加快。

这带来一种"双城记"式的平衡艺术：既要站在技术前沿、甚至要越过前沿去感受那条边界，又要为当下使用模型的用户提供真实价值。他们形容自己的团队像一个"超时空精神屋"（hyperbolic time chamber），提前体验了整个软件开发行业即将到来的样子。

To-do列表：抓住浪潮也要学会放手

一个标志性案例是待办清单功能。在Sonnet 3.5时代，模型还无法胜任长链条任务——给它五件事，它做完三件就放弃了。于是团队引入to-do list，效果立竿见影，"正是那个时间点所需要的东西"。但一年之后，随着更复杂的记忆状态出现，to-do列表几乎已经不再需要。

这成了团队哲学的缩影：对自己构建的东西要保持不执着（unattached），因为它们很快会消失。许多功能本质上是为了弥补当下模型的失败模式，当模型变强，这些功能就可以被果断移除，腾出手去应对更大、更有挑战的任务——而更大的任务又需要形态不同的新工具。

ask_user_question工具的兴衰

另一个例子是交互式提问工具。设计者花了很长时间才让Claude学会调用它，好不容易调好、模型开始擅长使用，最近他却发现自己已经不太用这个工具了——改用生成artifact的方式，让一个带图表、mockup的HTML页面来向他提问。从"模型勉强能做"到"模型做得非常好"再到"已经不需要"，整个周期短得惊人。

从本地到云端：Loops与远程智能体

关于"loops"（循环/例程）的来由，团队讲了一段颇具生活感的故事。最初所有agent都跑在本地笔记本上，一到下班要关机，agent就全停了——总不能一直待在停车场让别人侧目。于是转向远程托管的开发机，再到Claude Code on the Web：托管容器可以在后台持续运行。

配置容器访问开发环境确实有点麻烦，但成员直言"完全值得"，称这让他的生产力提升了10倍。一旦运行在云端，就能做很多有趣的事：比如设置例程，每天自动审视收到的反馈、按重要性分桶、并自主修复那些高置信度的问题。这正是从"在一个会话里提示模型"，跃迁到"提示一个高于会话层级的东西，让它替你去修bug、办事"的质变。

Loops（循环例程） 在这里指的是持续运行的自动化智能体任务，区别于由用户手动触发的单次对话会话。这一概念对应着AI工程中"异步/后台agent"与"交互式agent"的分野。传统的LLM交互是请求-响应式的：用户发问，模型回答，会话结束。而托管在云端容器中的Loop则更像一个常驻服务：它可以定时唤醒、主动拉取外部数据源（如用户反馈、GitHub issue、监控指标），自主判断是否需要采取行动，并在完成后将结果推送给人类。这种模式依赖几个基础设施前提：持久化的执行环境（不因用户关机而中断）、对外部系统的访问权限（读写代码仓库、调用API）、以及某种触发机制（定时任务、事件订阅）。团队提到的"每天自动审视反馈、按重要性分桶并修复高置信度问题"，正是Loop与代码执行能力、判断能力结合后的典型应用场景。

代码审查与Workflows：用测试时计算建立信任

当生成的代码量大幅增加，没人希望自己的工作变成纯粹地审代码。团队的做法是让Claude重新定位人类审查者的注意力。

传统代码审查里常见一种现象：审查者挑三个无关痛痒的小毛病发出来，本质只是"我读过这段代码"的信号。如今这些琐碎问题Claude可以自主发现并处理，人类审查的价值回归到更大的图景——比如某个API为何这样设计、服务边界为何画在此处，这些Claude在写PR时可能尚未完全内化的背景知识。

代码审查催生了团队所谓的"大扇出"（fan out）模式：让Claude并行搜索潜在bug，对每个bug做对抗性审查（从三种不同视角验证它是否真实存在），再把结果汇聚收敛。这本质是"测试时计算"（test time compute）的运用——投入大量推理算力为一个问题注入思考。

这套机制进而演化成Workflows。它可以泛化到性能问题、通用深度研究，乃至"下周带父母去Tahoe住哪里"这类生活决策：扇出10个搜索请求，再用agent排序、筛选、验证，最后给出结果。团队形容这就像一个MapReduce问题——扇出产生海量信息，必须再过滤回人类可消费的量级。

Workflows还有个微妙的信任来源：由于是agent写代码来编排子agent，形成了确定性代码行为与agentic LLM行为的混合。当看到Claude写了一个for循环去遍历所有条目，成员会更放心——"它不会漏掉某一项，会对所有东西一视同仁地应用同样的处理"。

测试时计算（Test-Time Compute） 是近年大语言模型领域的重要研究方向，指在模型推理阶段（而非训练阶段）投入更多计算资源以提升输出质量。与传统的"训练更大模型"思路不同，测试时计算通过让模型反复推理、自我验证或并行采样多条路径来换取更高精度。OpenAI o1系列和DeepSeek^广告-R1等推理模型是这一思路的典型产品，它们在回答复杂问题前会进行链式思考（chain-of-thought）推演。在智能体场景中，"大扇出"模式是测试时计算的工程化应用：把一个问题拆成多个并行子任务分配给不同agent实例，再聚合结果，实质上是用横向扩展的推理算力来对抗单次推理的不确定性。MapReduce 是源自分布式计算的编程模型（由Google于2004年提出），其核心思想正是"扇出处理、汇入归约"：Map阶段把大任务并行分发到多个节点，Reduce阶段把分散结果合并为最终输出。团队用这个词类比Workflows的运作方式，说明该模式在计算机科学中有深厚的工程传统。

Claude Tag：抽象层再上一级

团队正用Claude Tag激进地构建Claude Tag本身。关键在于让开发环境和开发循环对Claude足够友好，让它能完成人类端到端构建、测试软件所需的一切。

这是团队第一次把用户界面与transcript更彻底地解耦——现在工作在"距离Claude实际输出token一个抽象层之外"。当你在Slack看到Claude Tag发来的消息，那是它调用工具主动发送的；它的内部独白默认不可见，只保留一个查看完整transcript的链接。

起初这种抽象有点吓人——"我没法看到Claude思考时的全部内容"。但它也带来解放感：你不再纠结它调用了哪个工具、传了什么参数，而是被迫"让Claude放手去做"（let Claude cook）。能在不细看transcript的情况下拿到好结果，本身就印证了模型已经足够强。

一位成员分享了Claude Tag真正"开窍"的时刻：开发一个新工具时，他先问Claude该找哪些可能感兴趣的干系人，然后在Slack里（甚至在手机上）让它做mockup、做实现，加上埋点事件，内部部署观察使用情况。Claude Tag持续监控，一旦有人反馈就@他，让他能高响应地介入。当他想优化转化漏斗时，不再是"我有个想法让你照做"，而是在更高层级与模型协作"你来出几个主意"。

抽象层（Abstraction Layer） 这一概念在此具有特定的工程含义。传统CLI/TUI（终端用户界面）形态的Claude Code，让开发者直接面对模型的原始输出流：每一步工具调用、每一段内部推理都暴露在视野中，开发者可以精细干预。而Claude Tag作为Slack原生的智能体形态，在模型输出与开发者感知之间增加了一层：模型的"内部独白"默认隐藏，只有最终发送到Slack的消息才可见。这与软件工程中常见的"封装"思想一脉相承——高层抽象屏蔽底层细节，换取更流畅的上层体验，但代价是失去对底层行为的直接观察与控制。团队描述的心理变化（"从害怕看不到细节，到觉得解放"）实际上反映了从"调试者心态"到"产品/目标导向心态"的转变，这也是人机协作层级提升时普遍会经历的适应过程。

验证闭环：三大原语的交汇

这些实践指向三个在Claude Code中都已成为原语（primitive）的能力：验证（verification）、代码审查（code review）、获取反馈（feedback，可以来自metrics、Slack、GitHub issues等数据源）。

验证尤其被团队重视。当Claude为Claude Code创建PR时，它会测试，并发来界面效果的截图，让人获得信心。有成员分享了自己的验证流程：先让Claude录制自己使用TUI的过程，再亲自clone下来试一遍"图个安心"——并预判这种亲自验证的步骤未来也会逐渐消失。

软件工程师失去了什么，又得到了什么

对谈最后触及一个感性话题：怀念旧时代的软件工程吗？

有人怀念性能工程带来的乐趣——深入系统、压榨性能。如今Claude比他做得更好，但他仍能坐享性能提升的成果，注意力转向了"更快地把新想法从idea到prototype到production"。另一位是UI细节控，曾花整整一天用层层radial gradient精确复刻Mac OS X Aqua按钮；现在Claude能瞬间搞定，他反而不会再手动去做了。

但这位成员也给出了全文最动人的注脚：Claude让整个软件工程对他重新变得"触手可及"。他想起七八岁时想做游戏却不会写代码，只能用PowerPoint画可点击的形状——那是当时唯一能用的工具。而现在，无论什么想法，他都不必因"没有技术能力"而却步，只需说清要达成什么，再和Claude一起拆解实现。

正如团队所言，软件工程本就是"变化的职业"：从手写无框架的JavaScript，到框架、编译器的发明，变化只是在加速。但软件的本质从未改变——如何用这些工具解决问题、创造出了不起的东西。换的是问题，不变的是解决问题本身。