title: "Claude Code 团队如何用 Claude Code 重塑软件开发流程"
source_url: "https://www.youtube.com/watch?v=S-sYlFiGFv8"
author: "Claude"
excerpt: "公共早报 Claude Code 团队说明，目标导向的智能体、可组合的基础能力、扇出式工作流与验证产物，正如何把软件开发从逐步监督工具调用转向更高层次的编排。"
Brief Description
Claude Code 团队的成员讨论了他们现在如何将 Claude Code 和 Claude Tag 用于日益复杂的软件工作。他们反思了模型能力的快速变化、工作流和长期运行智能体所扮演的角色、代码审查和验证如何演变，以及为什么工程师们正从监督单个工具调用转向指挥更高层次的目标。
Table of Contents
从单独提示词到目标导向的工作
跟随模型变化的速度进行构建
交互式工具、产物和可组合的基础能力
长期运行的智能体与循环
代码审查、扇出与工作流
Claude Tag 作为软件开发界面
开发循环中的验证与反馈
工程师保留了什么，改变了什么
从单独提示词到目标导向的工作
发言者 1：团队首先指出，即使是几个月后的规划也非常困难。自从一位成员加入 Claude Code 以来，已经差不多一年了，与早期产品相比，变化令人瞩目：人们过去常常提示 Claude Code、给出反馈，并直接接受权限提示。
发言者 1：现在，大部分工作是通过 Claude Tag 完成的，这是一个基于 Slack 的原生智能体。交给它的问题远比实现一个类或编写一个函数复杂得多。由于它可以查找产品背景和团队决策，它能够更好地判断该做什么。
发言者 1：另一位参与者表示，他们 70% 到 80% 的工作都是在 Claude Tag 中完成的。他们可能会打开 TUI 或桌面应用来精调某些内容，或者当他们想要微观管理自己的 Claude 时。团队已经不再关注每一个对话记录、工具调用和单独的模型决策，而是转向表达一个目标，然后让模型去追求它。
发言者 1：构建 Claude Code 以及输入到 Claude Tag 的基础能力，已经改变了软件开发生命周期。团队现在将这些能力用于验证、代码审查、头脑风暴和监控。
跟随模型变化的速度进行构建
发言者 1：每个产品及其底层技术都有生命周期，但这个生命周期已经缩短了过去，一个团队可以满怀信心地制作一个产品，因为技术会在数年内保持稳定。而使用 AI 模型，技术可能每两个月就会发生根本性的变化，也许随着时间的推移会更快。
发言者 1：挑战在于保持在前沿，有时候甚至超越前沿，同时仍要为使用当前模型的用户提供价值。为如此快速变化的技术构建产品，是在艺术和科学之间的平衡。
发言者 1：一个很好的例子是围绕 Sonnet 3.5 的待办事项功能。当时的模型无法可靠地完成长时程工作：给它们五个任务，它们可能完成三个就停止了。待办事项列表正是那个时刻的恰当支持，但一年后就不那么必要了，因为更丰富的记忆状态和其他能力已经出现。
发言者 1：经验教训是，不要执着于正在构建的东西。Claude Code 工具链中的功能通常是为了弥补当前模型的失败模式。随着模型的改进，团队可以删除不再相关的功能，专注于构建新工具，以保持模型在更大、更苛刻的任务上的连贯性。
发言者 1：Claude Code 团队工作在某种软件开发的双曲时间舱中。它必须紧跟模型能力的发展，有时还要快速做出重大改变，比如创建一个新的主动式智能体，同时重写权限系统并创建配套的产物。其他产品的工程师也需要一个当前的思维模型来了解模型能力的走向，而产品应该帮助他们维持这个模型。
交互式工具、产物和可组合的基础能力
发言者 1：ask-user-question 工具说明了这种快速变化。它最初是为了让 Claude 变得交互式而设计的，最初放在规划之后。设计者意识到它也可以成为 Claude 自己调用的工具，但让模型很好地调用它需要大量工作。
发言者 1：一旦这个工具开始可靠地工作，模型能力很快就会超越最初的交互方式。发言者现在经常创建一个产物来代替：HTML 产物可以提问，包含图表和模型。一个最初对模型来说很困难的能力，出人意料地很快就变得常规了。
发言者 1：这就是团队构建 Claude Code 的方式：它为权限、可视化和相关能力创建基础能力，然后将它们分层组合。正确基础能力的细节随着模型行为的变化而变化。
长期运行的智能体与循环
发言者 1：关于循环的讨论从一个实际问题开始。一位参与者过去在笔记本电脑上本地运行所有东西，但离开办公室意味着关闭它并停止智能体。远程托管的开发箱允许工作继续进行而不必保持笔记本电脑开机，但需要 SSH 访问并返回托管界面。
发言者 1：Claude Code 网页版就是从这种需求中产生的。托管容器可以在后台持续运行，尽管让容器访问开发环境可能很难设置。发言者认为这是值得的，并估计这使他们的生产力提高了十倍。
发言者 1：这个演进过程是从本地运行的 Claude，到云端运行的 Claude，再到可以执行例程的智能体。例如，它可以检查每日反馈，按重要性分组，并修复它有高度信心能够解决的问题。
发言者 1：这就是循环的演进之路：不再在一个会话内提示模型，而是在高于会话边界的层次上进行提示。由此产生的智能体可以继续工作、修复错误，或者以其他方式执行用户的意图。
代码审查、扇出与工作流
发言者 1：更多的生成代码使得代码审查和安全变得尤为重要。Claude 可以帮助人类审查者决定把注意力放在哪里。在传统审查中，审查者可能会留下一些小的评论，部分是为了表明他们已经阅读了代码。Claude 可以自主发现并解决许多这类小问题。
发言者 1：人类重要的工作变成了更大的图景：理解为什么一个 API 具有特定的结构，或者为什么服务边界被画在特定的位置。Claude 可以将这种背景信息带入审查并交给人类，让审查者能够在更高层次的抽象上工作，而不是逐行挑剔。
发言者 1：代码审查也是大规模扇出的第一个主要应用。Claude 可以搜索许多可能的 bug，然后合并结果。团队称之为测试时计算：将大量推理时的思考和计算应用于一个问题。
发言者 1：工作流就是从这种方法中发展出来的。定制的工具链可以让 Claude 出去寻找 bug，然后运行对抗性审查，从多个角度评估每个可能的 bug。这过滤掉了误报，只留下真正值得人类关注的问题。
发言者 1：同样的模式可以应用于性能问题或一般研究。例如，一个旅行规划工作流可以发出许多关于太浩湖住宿和游览地点的搜索，然后使用智能体对结果进行排序、选择和验证，最后生成答案。
发言者 1：扇出产生的信息量太大，人类无法直接消化，所以必须过滤回来。发言者将这个模式比作 MapReduce。信心来自于应用测试时计算，而结果仍然在人类可管理的范围内。
发言者 1：Claude 可以通过决定扇出的拓扑结构、将一个智能体的输出连接到下一阶段、并总结结果来创建自己的工具链。工作流将确定性代码与智能体化的 LLM 行为结合在一起。对一组项目进行 for 循环，提供了一个令人安心的保证，即相同的技术将被应用于每个项目，这增加了对工作流的信任。
Claude Tag 作为软件开发界面
发言者 1：团队正在积极使用 Claude Tag 来构建 Claude Tag 本身。一个主要重点是确保它有一个轻松的开发环境和开发循环，这样它就可以完成构建软件和端到端测试所需的人类任务。随着软件变得越来越复杂和集成，这件事变得更难了。
发言者 1：Claude Tag 还代表了用户界面与模型对话记录的更完整解耦。来自 Claude Tag 的 Slack 消息是通过消息工具发送的；模型的内部独白不会暴露在主要界面中，尽管一个链接可以显示完整的对话记录。
发言者 1：最初，看不到 Claude 思维的每一个细节让人感到不安。随着时间的推移，这反而成为一种解放：Claude 选择说什么以及何时说，人类不再需要监控每一个工具调用或参数。这种体验迫使人们让 Claude 工作，并证明当前的模型可以在没有详细对话记录监督的情况下返回良好结果。
发言者 1：一位参与者描述了他们开发一个需要广泛认同的新工具的经历。他们向 Claude Tag 询问应该和谁交谈，得到了相关的利益相关者，在 Slack 中创建了可以在手机上查看的模型，并让它帮助实现。然后他们添加了事件、内部部署，并使用 Claude Tag 来监控使用情况和反馈。
发言者 1：当有人提供反馈时，智能体可以标记开发者，使他们反应更灵敏，也更有信心相信工具是有效的。当发言者看到用户从漏斗中流失时，他们从告诉 Claude 一个具体的解决方案转向要求它改进漏斗并在更高层次上提出想法。
开发循环中的验证与反馈
发言者 1：团队将验证、代码审查和反馈识别为相互关联的基础能力。反馈可以来自数据或事件存储、指标、Slack、GitHub issues 或其他来源，这些都是 Claude Code 中有用的构建块。
发言者 1：验证对团队来说尤为重要。当 Claude 为 Claude Code 创建一个拉取请求时，它会测试更改并发送截图，展示结果应该是什么样子。这些产物在人类检查工作之前提供了信心。
发言者 1：一位参与者解释说，他们仍然通过要求 Claude 用 TUI 录制自己来进行健全性检查，然后克隆并亲自尝试结果。他们预计，随着验证循环的改进，他们可能甚至不需要自己克隆它。
工程师保留了什么，改变了什么
发言者 1：回顾过去一年，团队添加了自动模式、记忆和工作流等基础能力。开发者需要跟踪的东西很多，但作为软件工程师现在更困难的部分是释放思维空间：理解什么是可能的，自动化更多的事情，退后一步思考更大的图景。
发言者 1：一位参与者过去从性能工程中获得极大的满足感：深入理解一个系统并改进其性能。Claude 现在在很多这样的工作中表现更好，但这个人仍然从这些改进中受益。他的注意力已经转向更快地产生想法，以及更快地从想法到原型再到生产。
发言者 1：另一位参与者喜欢细致的 UI 工作，并回忆起曾经花了一天时间用 CSS 重现 Mac OS 10.4 Aqua 按钮，仔细地叠加径向渐变。那现在是他会请 Claude 去做而不是手动完成的工作。
发言者 1：他们将这种感觉比作七八岁时想在不知道如何编码之前制作电子游戏。那时，PowerPoint 是创建可点击元素和形状的工具。Claude 现在让整个软件工程领域都变得触手可及：一个人可以说出他们想要完成什么，加以分解，然后与 Claude 合作实现它，而不必首先具备每一种技术技能。
发言者 1：软件工程一直是一个不断变化的职业。人们曾经在框架、编译器和其它工具改变工作之前手写 JavaScript。现在的节奏更快了，但核心仍然相同：使用可用的工具来创建卓越的软件和解决问题。问题可能不同，但工作仍然是解决问题。