多与你的编程助手交流

# 多和你的编码智能体对话 —— Data and Programming with Will Jones 来源：https://www.datawill.io/posts/2026-06-my-agent-workflow/ 关于编码智能体，我学到的最有用的一点是：花更多时间与其对话，少花时间阅读它们的输出。我使用 Claude Code 已近一年，主要用在 Lance 数据库上。这篇文章是我最终形成的方案、一个实际案例，以及背后的经验教训。 在处理一个问题时，我的典型工作流是： 1. **与智能体进行讨论。** 输入可能是一个 issue、一个 Slack 讨论串，或者我自己的想法。我会说类似“看看这个，有什么问题尽管问”或者“我想就这个讨论一下”。重要的是，我不使用计划模式。（下文会解释原因。） 2. **让智能体将我们的讨论提炼成一个计划。** 如果只是一个单元的工作，就写在一个临时的 markdown 文件里[^1]。如果有多个工作单元，我会让智能体为每个单元创建一个 GitHub issue。我不阅读计划，相信它能忠实地总结我们的讨论。 3. **分配一个新的智能体来执行计划。** 如果有多个 ticket，我会并行地为每个 issue 运行一个智能体。通常，它可以不需要进一步指导就完成任务。 4. **让智能体起草一个 PR，然后调用我的 `/polish-pr` 技能。** 这个自定义技能仅仅复现了我以前自己审 PR 时做的最后一遍检查：删除死代码、检查测试覆盖率、提高可读性等等。[^2] 5. **在 GitHub 上审查。** 我经常像审查别人的 PR 一样，直接在 GitHub 上评论。然后我会告诉智能体我留下了评论需要处理。如果有较大的修改，我会回到第 4 步。 这就是我的工作流。相比刚开始时，我花在阅读计划、盯着权限确认提示或逐行查看代码改动上的时间少了很多。大部分时间都花在初始讨论和最终审查上。我会再多分享一些我是如何得出这个结论的，以及为什么我喜欢这样的设置。但首先，通过一个例子来看这个工作流会更有帮助。 ## 例子：一次对话，两个 PR 我的同事向我报告了一个 BM25 索引中的性能问题。将所有 posting list 预热到缓存需要数千次 20 字节的读取（糟糕！）。并非所有 posting list 都很小，但由于自然语言的 Zipf 分布特性，大多数都很小。我的想法是：能不能把 posting list 分组为 4KB 的 chunk？我们有两个关键约束。第一，不能破坏磁盘格式的兼容性。第二，不希望读取 posting list 时增加 IO。我把这个想法和约束告诉了 Claude，然后让它检查这是否可行。这就是我的初始 prompt。 Claude 反馈了一个问题：分组所需的偏移数据现在是以惰性方式加载的。不增加 IO 我们就无法获取它们。但我们不需要每个 posting list 的偏移，只需要每个 chunk 起始位置的偏移。这些偏移量小得多，所以 Claude 推理道：为什么不把这些偏移存储在索引的头部呢？这是一个很好的发现，也是一个合理的建议。在一个快速发展的代码库中，智能体让跟上代码现状变得*容易得多*。 我喜欢 chunk 偏移的想法。但放在头部？我觉得我们可以做得更好。别处我们有一个优化叫做“机会性读取”：我们开始读取一个文件时，先提取最后一个 block 以获取最后几个字节。有时我们能捕获超过一个消息。如果数据很小，我们经常是免费获得了额外的结构；如果数据很大，我们也不会为可能用不上的东西付费。这看起来很适合这个场景——但我记不清我们是否对索引文件实现了这个优化。不过，让智能体查一下很容易。 Claude 报告说这个优化已经部分实现了，我们可以完成它。于是我们现在有了两件事要做：chunk 偏移和机会性读取。这时我让 Claude 为每件事创建一个 GitHub issue。 这种对话是我开始会话时的典型方式。我带来对问题的理解、一些想法以及对类似问题解决方式的回忆。Claude 带来对代码库的最新理解、一些有用的建议方案，以及对我的想法进行一些健康的反驳。我们不断迭代，直到找到我们都认为可行的方法。 至此，我关闭了当前会话，并打开了两个新会话，每个在自己的工作树中。我将每个会话指向其对应的 issue，并询问它们在开始实现之前是否有任何问题。现在，当我已经调研过某个 issue 时，这是我典型的 prompt。 我会让智能体在实现时进入 Auto 模式。首先，不必看着它们等待权限确认，这样不会分散注意力。其次，对于实现这样的 ticket，我通常不担心权限问题。我通常是在修改库代码并参与开源项目。而且权限分类器对标准操作相当智能，例如它在强制推送分支之前总会问我。不过，我不推荐在生产环境中使用这种模式。那种环境需要比 Auto 模式下的智能体所能提供的更多的问责和信任。 有了经过充分调研的 ticket 和自动权限模式，我发现智能体可以在不需要太多指导的情况下完成实现。这里就是这种情况，最终得到了两个相当干净的 PR[^3]。 ## 为什么我不再使用计划模式 刚开始使用 Claude Code 时，我总是使用计划模式。我告诉它我想要什么，它会问一些问题，然后生成一个计划。我会阅读整个计划，让它做一些修正。然后它会给我一个全新的计划。经过两三次迭代后，我通常会对阅读那一大段文字感到厌倦。（好吧，说实话，我可能第一次迭代到一半就厌倦了。）不仅纠正起来很累，而且计划模式会直接跳到解决方案。我需要的是验证我的假设，或者探究我的想法，而不是一个立即的实施计划。而且如果我屈从于它直接给出的建议，最后往往得到一个需要重大方向调整的 PR。 后来我看到了 Matt Pocock 关于使用编码智能体的 YouTube 视频。他的视频重点在于将软件设计原则——例如来自《程序员修炼之道》[^4]——应用到编码智能体工作流中。关键技能是 `grill-me` 技能，它指示智能体采访用户（Anthropic 也推荐这种方法）： > “对计划的每一个方面对我进行无休止的提问，直到我们达成共识。” 其中一个关键思想是“直到我们达成共识”。当我直接进入计划模式时，我们缺乏这种共识。智能体不知道我想要什么不同的东西，就直接根据初始 prompt 中描述的问题规划解决方案。然而，找到一个好的计划需要智能体和工程师之间来回几轮。双方都有有价值的见解可以贡献，但计划模式并没有很好地构建来促进思想的轻松交流。而面试环节则可以做到。 智能体不是读心者——你需要告诉它们你需要什么。好的想法需要迭代；它们几乎从来不是第一个想到的。对话是分享信息和提炼思想的绝佳媒介。它极大地改善了我的编码智能体工作流。事实上，我发现它在更多地方都很有用。（我甚至花 15 分钟对话开发了我下一个啤酒配方[^5]。）在你的下一个项目中试试看。你会发现它更不累人，而且更高效。 ## 脚注 [^1]: `handoff` 技能对此很有帮助。↩ [^2]: 一个小插曲——如果你在编写自己的技能，我**强烈**推荐使用 Anthropic 的 `Skill Creator` 技能。如果你给它一些你不得不编写额外 commit 来清理工作的示例 PR，它可以运行一个良好的评估循环来检查技能性能并进行改进。↩ [^3]: 你可以在 https://github.com/lance-format/lance/pull/7043 和 https://github.com/lance-format/lance/pull/7042 看到它们。↩ [^4]: 《程序员修炼之道》由 Andy Hunt 和 Dave Thomas 合著，是软件工程领域的经典之作，最初出版于 1999 年。我最近读了这本书，和 Matt 一样，认为它依然很有价值。↩ [^5]: 我们最终确定了一种比利时风格的琥珀小麦啤酒。是的，很美味。🍻↩