每天挑选一期硅谷AI科技值得关注的播客，让你与前沿同频。如果你现在没空可以收藏进 ，在通勤、走路或做家务时一篇篇轻松听完
"我现在 70% 到 80% 的工作，都在 Claude Tag 上完成。"
"不要太依恋自己做的东西，它们很快就会消失。"
"Claude 其实很擅长搭建自己的运行框架。"
在 Slack 里提出想法，让 AI 找到需要沟通的同事、做出原型、完成实现，再接着看使用数据和用户反馈。这已经是 Claude Code 团队讨论的日常工作场景，而一年前，他们还主要在终端里输入提示、纠正结果，一次次批准工具调用。
Claude 官方请来团队成员 Thariq Shihipar、Sid Bidasaria 和 Robert Boyce，聊了聊他们自己怎样用 Claude Code。谈话里有不少具体的开发经历：曾经管用的待办清单为什么可以删掉，合上笔记本后任务怎样继续，以及 AI 交付代码以后，人还要检查什么。代码越写越快，工程师省下来的时间该用在哪里，他们的日常做法提供了一些参考。
先把目标交出去，别急着规定每一步
团队成员现在交给 Claude Tag 的问题，已经远比“实现一个类”或“写一个函数”复杂。Claude Tag 是他们使用的 Slack 原生 Agent，可以查找产品背景、团队讨论过的取舍，以及某个决定为什么会被作出。这些信息会影响实现方式，单看代码仓库往往找不全。
"我有一个目标，我想实现这个目标。"
一位成员估计，自己七到八成的工作已经在 Claude Tag 上完成，剩下的才会打开终端界面或桌面应用做细调。这是他个人的使用比例，却很能说明他怎样分配精力： 先交代自己想完成什么，再在确实需要干预时进入执行细节。 过去，他会频繁查看模型的完整记录，关注每一次工具调用和中间决定，现在则更愿意把一段完整的工作交出去。
Robert 提到，Slack 消息与完整执行记录已经分开：Claude 通过消息工具决定什么时候联系用户，详细记录仍可通过链接查看。起初，看不到每一步过程让人不太安心，实际使用下来，他们发现模型已经能在较少干预下完成一些复杂工作。有疑问时仍然可以追查，只是不用一直守着它执行。
团队成员谈自己在 Slack 中使用 Claude Tag 的经历：先交代目标，再在需要时介入细节。
曾经最有用的功能，也可能该删了
做传统软件时，团队通常能相信底层技术会稳定几年；他们现在的感觉却是，模型能力大约每两个月就有一次根本变化。好不容易为当前模型补上的短板，下一代模型也许已经没有了，待办清单就是这样一个让他们印象很深的例子。
"你必须对自己正在构建的东西不那么依恋，因为它们很快就会消失。"
在 Sonnet 3.5 前后，模型还不擅长长任务，给它五件事，可能做完三件就停下。团队加入待办清单后，效果明显改善，这正好补上了当时模型的短板。大约一年后，随着能力和记忆机制变化，这种清单已经不再像当初那样必要。 一个功能今天有价值，并不代表它应该永远留在产品里。
他们把围绕模型的工具、权限和执行机制称为 harness，也就是支持模型工作的运行框架。有些设计专门应对当前模型容易出错的地方，能力提升后就可以拿掉；但用户随即会交来更大的任务，需要团队提供新的工具。对开发者的考验在于，熟悉旧模型的毛病还不够，也要及时发现新模型已经能做到什么。
让 AI 提问，也不一定只能靠问答框
AskUserQuestion 的起点很简单：让 Claude 能主动和用户互动。最早的设想，是在规划结束后安排一次提问，后来才把它改成模型可以自行调用的工具。设计者花了很长时间，才让 Claude 学会在合适的时候、用合适的方式提问，接着模型又很快越过了原来的限制。
"现在我没那么常用这个工具了，我直接创建一个交互页面，让页面来问我问题。"
他所说的页面，是模型生成的 HTML artifact，可以同时包含问题、图示和界面草图。要讨论一个产品想法，用户因此能对着具体画面给反馈，无须只靠几轮文字把脑中的设计解释清楚。 当模型可以生成更合适的交互形式，固定的问答框就不必承担所有沟通。
这类变化会同时影响好几项开发工作：有人重做权限系统，有人开发交互页面，还有小团队尝试让 Agent 更主动地工作。对谈中的成员形容，Claude Code 团队像是待在一个时间流速特别快的房间里。他们并不认为所有软件产品都需要这样频繁地推倒重来，只是自己恰好离模型能力的变化最近。
合上电脑以后，工作不该跟着停下
Loops 和 routines 的来历，没有那么抽象。一位成员以前把所有任务都放在笔记本上运行，下班回家一合电脑，Agent 也就停了。他后来把开发环境移到远程机器，虽然不用一直开着电脑，却要反复通过 SSH 连回去，重新找到自己的工作现场。
"每天查看我们收到的所有反馈，按重要性分类，修复那些它有较高把握解决的问题。"
再往后，网页端的托管容器让环境可以在后台持续运行。配置访问权限和开发环境仍然有门槛，但任务不再依赖本地电脑是否开着，才有了日常循环的基础。团队给出的例子是，每天读取用户反馈，按重要性分类，再修复其中它有较高把握解决的问题。
人交代的工作开始跨过单次会话，变成需要持续执行的安排。 每天读取反馈、判断哪些值得处理，再尝试修复，这是一个不断重复的过程。开发环境能够在云端保持运行后，团队才有条件把这样的安排交给 routines，而不用每次都从本地终端重新发起。
代码审查，别再靠挑小毛病证明认真
代码生成量上升后，团队并不希望工程师把省下来的时间全部用来逐行审查。一位成员回忆，以前常见的评审是挑出三处小问题，借此表明自己认真读过代码。如今 Claude 能发现并处理很多这类细节，人更值得追问的是它没有完全掌握的系统背景。
"Claude 帮助人工审查者决定，把时间和精力放在哪里。"
比如，某个 API 为什么设计成这样，两个服务为什么在这里划分边界，当初有哪些产品或架构方面的考虑。即使提交的改动在局部看起来正确，也未必符合这些约束。 把缺失的背景带进评审，再交给人作出决定，比继续围绕小问题反复评论更有价值。
他们的代码审查还采用了多路并行搜索：先让多个 Agent 找潜在错误，再针对每个问题，从不同立场进行对抗式复核，检查它究竟是不是真问题。这样做会花更多推理计算，但能过滤大量不成立的报告，最后只把值得关注的部分交给人。团队后来发现，这套做法也能用在代码审查之外。
并行 Agent 越多，越需要有人替你收拢
Sid 发现，代码审查里的“展开搜索，再筛选核验”，也适合性能排查和深度研究。对谈里甚至用了家庭旅行的例子：让不同 Agent 查酒店、民宿和活动，再安排其他 Agent 整理与验证。如果所有原始结果都直接扔给用户，并行带来的收益很快就会被阅读负担抵消。
"如果让我读完并行展开的所有输出，我会疯掉。"
因此，工作流不只有任务分发，还包括结果怎样流向下一步、哪些发现需要复核，以及最终该给用户什么。团队发现 Claude 已经很擅长编写组织这些子 Agent 的代码，可以针对问题设计连接方式。用户提出目标后，它会搭出搜索、筛选、验证和汇总的过程，不必事先把每条路径全部写死。
让他们更放心的一个细节，是这套流程里依然有熟悉的程序代码。 普通的 for 循环负责逐项遍历，模型负责每一项里的分析判断，两者可以搭配使用。 开发者能看到循环如何执行，也知道每个项目都会接受同样的处理，不必只靠一句“别漏掉任何一个”来约束模型。这种可检查的过程，增加了他们交出任务时的信心。
让 Agent 交付结果，先让它有办法自证
Robert 正在用 Claude Tag 开发 Claude Tag，他花了不少精力清除 Agent 在开发环境里遇到的障碍。目标是让它能完成一个人类开发者需要做的操作，并自行检查软件是否端到端运行正常。产品与外部系统的集成越复杂，这部分工作就越难省略。
"确保开发环境和开发循环对 Claude 来说非常容易使用。"
另一位成员讲了一个内部工具的开发过程：先请 Claude Tag 找出可能关心这个想法的同事，再做草图和实现。随后把使用事件记录下来，在内部部署，让它跟踪使用情况与同事反馈，有新消息时提醒自己。这样一来，开发者不用隔一会儿就去问有没有人试用，收到提醒便可以及时参与讨论。
当数据表明用户没有走完整个流程时，开发者原本想指定一个修改方案，后来改为让 Claude 设法改善漏斗，把自己的想法只作为一个例子。 给出目标、接通数据，再让它提出办法，Agent 才能参与到产品改进中。 这与只让它执行一个已经决定好的改动，是不同程度的委托。
验证环节仍然保留了人的检查：Claude 创建 PR 后会运行测试、发回截图，也能录下使用终端界面的过程。那位开发者看完演示后，依然亲自拉取代码试了一遍，确认基本体验。对谈里还谈到以后可能进一步减少这一步，但当时的实际做法并没有把“相信 Agent”等同于不再验证。
团队成员分享内部工具的开发经历：上线后继续跟踪使用数据与同事反馈，让 Agent 参与后续改进。
少了一些钻研的快乐，也多了能做的事情
说起以前的开发生活，他们也有舍不得的部分。一位成员过去很享受性能工程，愿意深入系统，把速度一点点调上去，如今他觉得 Claude 已经比自己更擅长这件事。另一位则怀念琢磨界面细节的日子：他曾花一整天叠加 CSS 径向渐变，只为复刻 macOS 10.4 的 Aqua 按钮。
"你解决的是不同的问题，但你依然在解决问题。"
现在，Claude 很快就能做出类似效果，他们大概不会再手动重复那一天的工作。少了亲手调出一个满意效果的快乐，也多出时间尝试以前来不及做的想法。 他们现在更关心的，是怎样把一个想法做成原型，再把原型变成真正可用的产品。
那位喜欢界面设计的成员想起自己七八岁时，想做游戏却不会编程，只能用 PowerPoint 的形状和可点击区域拼出效果。如今技术能力不再那么容易挡住一个想法，他可以先说清想完成什么，再和 Claude 一起拆解。团队最后仍把软件工程理解为解决问题，只是能尝试的问题范围更大，变化的速度也更快了。
写在最后
不必一次搬走全部开发流程，可以先挑一个目标明确、能够验证结果的任务，把相关背景、测试环境和反馈来源接给 Agent，观察自己还在哪些地方反复介入。这些卡点会告诉你，接下来需要补什么工具、保留哪些人工检查，也可能让你发现，某些过去必要的步骤已经可以省掉。
内容来源："How the Claude Code team uses Claude Code"丨Claude（嘉宾：Thariq Shihipar、Sid Bidasaria、Robert Boyce）
原视频：https://www.youtube.com/watch?v=S-sYlFiGFv8
相关文章
- 《Anthropic 工程师：他们到底怎么用 Claude 工作丨How I AI》
- 《好用的 Agent Skill 到底怎么构建？丨AI Engineer》
- 《Claude Code 实战：如何用一个工具支撑整个小团队丨Aakash Gupta》
如果你现在没空，可以收藏进晚点再听，通勤、走路或做家务时一次性听完⇣
