大家好。我是Zach，在WorkOS工作。感谢大家到来。WorkOS提供即插即用的API，让你能将软件升级并面向企业市场，以促成更大规模的交易。不过，我今天想谈谈的是，我目前发现的一种应对每天层出不穷的疯狂新工具、试图保持平衡的方法。如果最近有人在使用AI代理进行编码，并且感觉有点像我这样——尽管做得比以往任何时候都多，但一天结束时却彻底精疲力竭，肾上腺素不断分泌——请举手示意。

这种经历我也深有体会。我注意到，最糟糕的部分在于上下文切换的成本一直很高，而现在比以往任何时候都要糟糕。我想我们很多人都感同身受。这些工具极其强大，我们的技能比以往更受欢迎，但我们却在上午11点前就感到疲惫不堪。为了具体说明这一点，我想分享一个最近的故事。我在WorkOS的应用AI团队工作，当时正在构建一个Slack机器人，旨在让每个人都能民主化地撰写统一风格的博文。

即使以前从未写过博文的人，只要进入Slack频道发出简单请求，就能获得一篇符合正确规范、一切合规的博文。当时我的同事报告了一个bug，说：“我们需要使用句子大小写格式，而当前的句子大小写处理正在破坏一些缩写词，比如SKIM和SSO。”通常，我会陷入我之前展示的那种“窗口地狱”中。

但这次，我做了一个微小的改变，却产生了巨大的影响。我将Claude Code——我目前偏好的工作界面——赋予了读写Slack的能力。它原本就拥有我Linear工单的访问权限。于是，我告诉它：“你需要修复这个问题，然后还要验证自己的工作，直到完成为止。”

大致情况是这样的：我的终端在左侧，我运行了Claude并说“修复句子大小写强制器，它在破坏缩写词”。它执行了修复，并通过MCP连接将结果发送到了博文频道。它正在处理的博文机器人从我的工作目录代码库中拾取了该结果，一直运行到相关步骤。

随后，Claude验证了访问和结果，并确认：“好的，我现在确定已修复此bug。”当我回来时，面对的是一个已完成的闭环，问题已解决，我不需要再告诉它“这部分还是坏的”。这种感觉棒极了，我认为这是我们都要构建到工具包中的重要部分，而且我们已经在做了。

但这同时也让我感到害怕，因为我意识到这没有上限。工具现在是核武器级别的，而我们的神经系统仍然相对古老。因此，我最近一直在思考，如何在这个世界中找到属于开发者的平衡点？为什么不直接堆叠同样的流程，利用这种机制每天修复150个bug呢？

代理确实可以做到这一点，特别是如果你给它们足够的上下文、正确的验证标准以及验证自身工作的工具。但归根结底，我无法坐在所有这些工作之上确保质量，也无法在第二天继续投入8小时的工作而不至于彻底崩溃。

我认为，我和最近交谈过的许多人都发现，代理不再是瓶颈，这种情况会日益明显，但我们才是瓶颈。代理可以无限扩展，特别是现在它们已作为云API提供。你可以赋予它们验证标准和所需的工具，但我们的注意力仍然受限于物理世界，在负载下会退化。这本质上是一个硬性约束。

这不仅仅是我或你一个人的问题，而是所有在演讲开始时举手表示感同身受的人共同面临的问题。Simon Willison最近提到，他启动了四个并行代理，结果在上午11点就被击垮了。因此，他建议我们每个人都需找到个人的平衡点和极限。

我在应用AI团队也明显看到了这一点。这里分享几个我最近使用并取得成功的技巧，其中一些你们可能已经见过了。我们需要将人类开发者与新工作方式重新平衡，因为现在有了这些超充能的工具， burnout（倦怠）的速度前所未有，特别是当你线性增加工作量和产出时。

我脑海中的大致划分是：代理在无限扩展方面表现更好，它们会无限循环直到达到你设定的标准。但我们仍拥有判断力、品味，知道问题是否真正解决，知道标准是否在人类需求和商业需求层面得到满足。这是我看到的早期分层结构。

第一，我称之为信号层（Signal Layers），稍后我会详细展开。第二，语音优先流程。我进行语音优先编码已有约一年半，这改变了我的生活。第三，远程控制，这越来越适用，我认为我们很快会在各处看到它。目前这主要是Claude Code特有的功能。

第四，系统自我改进。仅仅微调你工作和存储消息历史的方式，就能带来极其强大的效果。现在有了代理，它们能在几秒钟内快速浏览所有材料，并在循环中为你寻找模式，甚至无需你记得去做。让我们快速看看这些概念的含义。

回顾我之前修复的bug，让Claude去处理。我的问题是，如果我去……

我自己梳理 Slack 时，有 80% 的把握会被其他线程分散注意力。我会发现别的事情，或者有人给我新的任务，这会把我的注意力从当前任务上拉走。因此，我让 Claude Code 能够读取我的 Slack 并循环执行，以便查看是否有 @提及、私信，或者是否有真正需要处理的高优先级任务。与此同时，它通过 MCP 始终访问我的 Linear，从而去重任务并找出真正的工单。这为我提供了一种必要的表象，让我能够继续专注于作为人类开发者必须完成的关键事项。

我认为现在涌现出许多工具，我们在这里也都能看到，它们将为任何工作场所打造定制化的体验。但这本质上是在管理如今异常庞大的流量、通知和噪音。第二点是语音优先的工作流，如果你还没试过，强烈建议尝试。我是一个热爱打字的人，从三岁起就开始打字。在我状态最好时，用我那巨大的香肠手指以非标准方式能达到每分钟 90 词的速度。

但现在有了语音优先工具，速度显著提升了。我经常能达到每分钟 184 词的速度。这不仅意味着快速说话并更快完成，还实现了并行工作流。想象一下，作为一名开发者，我同时在三个不同的 Cursor 窗口、Codex 以及多个标签页中的 Claude 进行语音输入。由于速度达到每分钟 184 词，当传统开发者还在输入第一个提示词时，我的多个任务往往已经在运行了。

考虑到小事会迅速累积，在软件开发的两年、三年甚至更长的时间里，这种优势会如何复利增长？这对我来说非常关键，因为随着我对语音工作流越来越熟悉，它还使我能够展示接下来的内容：在仍完成工作的情况下，减少在办公桌前的时间。接下来是远程控制。目前这主要是 Claude Code 特有的功能，但我预计这会迅速改变。

在深入探讨 Claude 生态系统中这意味着什么之前，我们先简要谈谈“淋浴原理”。我相信大家都听说过。基本理念是存在两种思维模式。如果你全神贯注于 IDE，正在打字和搜索符号，你可能处于专注模式。你的脑海中很可能有一个清晰的蓝图，知道要构建什么以及如何构建。这种专注对于将项目推向完成并按你想要的方式构建事物非常出色。

但它也容易导致盲点，错过创造性的解决方案，并增加你的抑制感。然而，矛盾的是，当你站起来走开，开始逗狗、送孩子去公园或洗澡时，你会突然灵光一闪，获得完整的解决方案。“淋浴原理”的核心论点是，你的潜意识一直在处理这些难题。因此，当你走开并打开视野、降低抑制时，发散模式能让你更快地看到更多创造性的解决方案。

我想强调的关键点是，我们一直拥有这种能力，数百本书籍对此进行了论述，我们也讨论了数十年。但过去，发散模式和离开办公桌意味着停止工作。现在情况不再如此，特别是有了远程控制这样的工具。以 Claude Code 生态系统为例，如果我启动一个 Claude Code 会话，传递远程控制标志，或在配置中启用远程控制，我就可以从办公桌开始。它在本地开发机上运行，可以访问文件系统等等。

但当我在另一个网络、家庭 Wi-Fi 之外的 CDMA 网络上用手机打开 Claude 时，比如远在几英里外的步道上，我仍然可以看到该会话，并与之交谈、发送消息或与其互动。这非常强大，因为一旦我离开办公桌，我最好的想法和解决方案就会涌现。因此，我现在提议的这种能力是：以专注模式开始一天，加载所有重要的任务，然后让代理开始工作，确保进展符合预期，接着离开办公桌。

这能减少你的重复性劳损（RSI）以及因整天保持同一姿势而受到的身体伤害，你可以去散步，同时保持极高的生产力。我对此做了大量实验，去年甚至拍摄了一部 32 分钟的影片，证明你可以在树林里通过手机审查代码提交（PR）。所以我不是在信口开河，这是可行的。

与之相关的好处是，当你通过手机与该会话交谈时，Claude Code 上的会话仍在你的机器上运行，仍然可以访问所需的一切。如果你有一个天才的想法，比如“这就是能解决问题的设计”，你只需将其发送回去。你不必记得回到办公桌时再去做，因为当你回来时，它已经被应用了。当然，为了做到这一点，我常说速度需要安全，因此存在不同层级的验证。

随着新工具如 Computer Use 的出现，这将变得更加复杂。第一道关卡是最小化的 lint、构建和单元测试，让代理通过钩子每次都在代码层面验证自己的工作，确保没有破坏任何东西。第二道关卡是告诉 Claude Code 必须通过浏览器验证自己的工作，点击浏览，确保没有破坏登录等功能。第三道关卡更接近 Anthropic 设想的“宪法 AI”，即存在必须遵守的宪法规则。

另一个代理会来验证你是否操作正确，否则给你需要执行的反馈。那么，这一切综合起来，如何真正改变软件开发者的一天呢？正如我之前所说，我建议在一天开始时进行深度专注工作。你可以浏览 GitHub 上的所有积压任务，这些是你需要排队的软件开发生命周期琐事，将它们全部输入 Codex，然后在 IDE 或 Claude Code 中开始处理你真正关心的功能。

随后，你基本上可以让它们按照你当天确定的工作轨道运行，然后离开。因为你在手机上就能访问它们，所以即使你在边缘地带漫游，或者使用 LTE 网络，你也能给它们发消息，并在手机上开始审查随着 PR（拉取请求）到来而提交的代码。

现在，再次强调，因为我们尚未触及大语言模型的瓶颈，比如 Opus 4.6 相当合理，你可以在手机上的 GitHub、Claude、Cursor 代理或 Vercelbot 上留下自然语言评论，说“这里需要修改”，大多数时候它都能做对。

这种模式实现了一个完整的闭环。你花在办公桌外的时间越来越少，花在办公桌前的时间越来越少，伤到手腕和手的时间也越来越少。当你外出散步时，你获得了氧气，产生了更好的想法，但你仍然处于工作流中，仍然在引导工作向前推进并取得进展。

我通过这种实验发现的一个关键学习点是：如果你只是独自使用工具，比如在一周开始时，周一感觉棒极了，我能快速完成大量工作。周二感觉也一样。但在周中，我遇到了一些随机的请求，这让我偏离了轨道，到了周五时，我完全筋疲力尽，不记得自己到底做了什么。

我知道工作已经交付，但一切都很混乱。正如我杰出的同事 Nick 提醒我的那样，所有 Claude Code 的对话都本地保存在 JSONL 文件中。这使你能够更聪明地工作，并安排定期回顾，让你的代理在每周结束或每天结束时回顾你自己的对话。

它会说：“寻找那些你需要花费大量思维代币才能做对的模式，或者我和你来回沟通以消除歧义才能正确完成任务的模式，找出缺失的技能。如果拥有这些工具、这个 MCP 服务器或这些技能，差距是多少？我们如何收紧这个循环，以免下周再发生？”

通过这种方式，只要你定期使用自己的工具，你的整个系统或整个框架就开始变得更聪明。现在 Claude Code 内置了一项技能，不仅能构建自己的技能，还能评估和改进技能，并将自然语言提示转化为你所需的定制技能。

我强烈建议这样做，然后收紧这个循环，这样你仍然可以完成工作，仍然能在工作中交付所需成果，但花在办公桌前的时间越来越少。

这开始呈现出这样的景象：你在工作，你仍然通过你主要偏好的界面保持专注，无论是 Zed、Cursor，还是终端里的 Claude Code，但模式正在建立，因为你没有丢弃你在工作中积累的所有上下文。

你将所有这些会话视为珍宝，因为它们确实是，因为一次 Opus 4.6 的交互就能揭示大量技能，如果下周拥有这些技能，我可以以更高效、更快速、更可靠的方式完成同样的工作。

最后分享一件趣事。我很喜欢我的 Oura 戒指，我做的第一件事就是通过 MCP 连接它。有几个 GitHub 项目可以实现这一点。然后我把它交给了 Claude。所以，当我与 Claude 争论一个项目时，有时他会直接回来对我说：“你昨晚没睡好，所以我们要解决这部分，剩下的部分不做，你明天再做。”

然后我会说：“去你的，你是机器，按我说的做。”但我最终还是照做了，至少我考虑过休息一下。这有点有趣，但我认为这也很有意义，因为你开始从整体角度审视工作，不仅关注你与同事的对话、你的工单以及你拥有的技能，还关注你的身体状况、你何时能最好地集中注意力、你获得了多少睡眠。

我认为这非常重要，因为如果我们只是盲目地这样做，默认路径将是倦怠，而且是“超快倦怠”，比以往任何时候都快且容易，这是由大语言模型推动的。而有意识的路径则更像是：我如何保持自我状态，同时发挥最佳工作水平，并引导代理为我处理琐事，而我仍然对质量、审查以及最终交付负责。

如果你对这些内容感兴趣，我建议尝试构建单一层级。它可以很简单，比如只是将 Slack 或 Linear 接入你正在使用的首选界面，无论哪个对你来说上下文切换成本最高。添加一些验证机制，对于 Claude Code 来说，只需传递 --chrome 参数，让它访问自己的浏览器即可。

然后利用你节省下来的时间，去公园独自野餐，或者去散步，或者遛狗，或者做其他任何事。是的，工具现在已经像核武器一样强大。而我们的神经系统仍然很古老。所以我最近在思考的是如何找到某种开发者平衡。希望这对你有帮助。

非常感谢。有问题吗？有。嗯，我想我的职业生涯还比较早期。是的。这意味着技能发展也很重要。>> 没错。还有进行深度工作。嗯，至少像你知道的，我是通过大量深度工作学会编程的。遇到问题。是的。并克服那些障碍。完全正确。嗯，而且我也非常……

你适应这种新的工作流了吗？对我来说，这似乎是一种技能缺失。它让学习变得更难了。那么，你是否找到了平衡点？是的，你仍然可以在那个技能水平上推进，同时获得这种方法的好处。这是一个很好的问题。为了以防没录上，我再重复一遍：如果你刚入行，这一切都关乎技能提升，那你到底如何进行硬技能的发展呢？我担心的是，这可能会剥夺我的这些能力。我该如何管理或保持它呢？

我认为最好的建议是：不要用 AI 去做你本来就不会做的事情。比如，我之所以能部署 TypeScript 系统、RAG 系统和 AWS 服务，是因为我多年来曾以艰难的方式做过这些。我有着“战痕”和“疤痕组织”。因此，当 Claude 产生幻觉或提出糟糕建议时，我能立即察觉并制止，比如“不，这太荒谬了，我们不这么做”，因为我为此投入了时间建立基础。我强烈建议你依然要这样做，深入钻研这些领域。

甚至利用 LLM 和 AI 可以更快、更深入地学习，你可以让它“测试我”，指出你思维模型中模糊的地方。所以，强烈建议构建这些技能，手动编写一些代码，找出其中的痛点。但一旦你建立了自信，开始大量开发 Ruby 应用时，使用 LLM 和 Claude 来加速开发是可以的。你还提到“只有想自己写代码时才委派代码任务”。如果我的重点是提升技能和夯实基础，我会推荐这样做。

不要气馁。过去我在学习时，因为不知道不知道事物的名称，所以我无法提问。而现在你可以提问，从而更快、更深入地学习。如果你对自己“不知道”这一点更诚实，你就能进步得更快。我认为这有着非常光明的未来。你提到让 Claude 查看你所有的聊天历史记录（JSONL 文件）。我试过类似的方法，但发现 JSONL 文件并非专为 AI 消费设计，它们太长且包含大量垃圾数据。

你是直接指向它，还是有中间步骤将其解析为更友好的格式？这是一个好问题。我之前曾直接指向它。关键在于如何处理 Claude 对超级糟糕且非为 AI 设计的 JSONL 文件进行回溯和聚合分析。我直接指向它也有成功，但另一种方法是使用 Hooks。在每个编码会话结束时，保存讨论的关键点，特别是突出我们遇到困难或花费大量时间的地方，并存入单独的数据存储中。

可以是 Obsidian，可以是该周的 Markdown 纯文本文件，也可以只是一个简单的归档。然后在周末对该数据进行运行分析。是 AI 分析还是确定性分析？我会使用 Claude Hooks 作为触发器，比如在会话结束、我说“完成了”或合并 PR 时触发。你可以在提示词中指示它：专门寻找那些未来可以优化或表明挣扎和反复的地方。

你也利用“夜班”让代理在工作吗？是的，我一直在实验 OpenClaw。我通过 Cron 任务实现这一点，让它为我生成一些内容。早上醒来后，我会审查、惊慌、尖叫，然后合并其中很小的一部分。我希望通过更好的系统和验证，让它能持续处理。我最终打算采用的方案是：所有工作都使用 Linear 工单，子任务用于 Bug 和功能请求，标记工单为“Agent Ready”，然后设置一个循环，每 15 分钟全天候处理个人和公司的工作。

你让代理对你说话吗？还是你阅读它？如果它很冗长，你怎么办，因为显然阅读比听语音快。这是一个好问题。你问是否让代理通过语音与你交流。我确实都这么做。大多数时候我用 Claude Code，我对着它说话，它写回给我，我阅读。但我大量使用 OpenAI 的高级语音模式。这是 ChatGPT 我最喜欢的功能之一，也是我用它胜过 Claude 的唯一原因。

我会散步两小时，进行头脑风暴，来回交谈并打磨想法，最后说：“好了，现在把这个变成简洁的转录或架构，我可以粘贴。”我认为它足够智能，能进行有质量的对话。而且语音领域发展迅速，昨晚我发现了一个开源的“Ghost Pepper”，本质上是本地运行的 Whisper Flow，不使用 API。

我在 Twilio 上运行 OpenClaw。晚上我可以要求通话，而不是它读给我听，我可以对它说：“这就是你明天要做的。”我发现通用语音非常高效。你每类工作都用这种方式吗？我有过类似的工作流，发现它确实有效。

当你处理一些小bug或UI修复这类工作时，我可以并行做很多事情。但当我面对更庞大、更复杂的特性开发时，比如那些需要同时涉及后端数据库和前端，甚至改变整个应用程序工作流或架构的任务，感觉就像一切都被卡住了，导致我无法再并行处理，因为它们可能会相互干扰。

你能自己处理这类更庞大的任务吗？是的，我认为这是一个很好的问题，我觉得大家都在为此挣扎。关键在于，这些流程对于离散的、 bite-size（小块）的任务非常有效，我同意这一点。那么，对于那些会触及整个技术栈的更大、更复杂的任务，比如为分布式云系统创建一个全新的特性，该怎么做呢？

我的思路首先是获取工作树（work trees），以便代理（agents）能够真正并行运行，而不会互相干扰。其次是组建代理团队，并制定非常清晰的提示词（prompts）。再次，验证关卡、单元测试甚至持续集成变得更为重要。

我们要达到这样一种状态：我不断地测试应用程序，它们不断地根据规范进行构建。我将我的挫败感和愤怒反馈回系统中，然后随着开发的进行不断修复。不过，我认为这还会继续演进。我想象随着模型的进步，会有越来越多完整的测试框架来使这一过程更加可靠。

是的，这是一个很好的问题。好了，非常感谢。