Claude Code 实战提效工作流

加入 Tano 已有大约 6 周，我的提交历史现在是这样的：

Commit 数量衡量产出很不靠谱，但它们是我能看到的最直观信号。我的工作方式确实改变了，commit 数量只是这种改变的副作用。

那么，到底什么改变了呢？

自动化繁琐工作

刚加入 Tano 时，我是手动创建每个 pull request 的。暂存改动、写 commit message、撰写 PR 描述、push、在 GitHub 上创建 PR。标准流程，没什么问题。

花了一段时间后我才意识到，这其实是繁琐工作。我已经习惯了这样做，从未质疑过它。

这是第一个真正的转变：我不再是实现者了。我变成了管理执行实现的 agent 的经理。而经理们会自动化团队的繁琐工作。

然后我写了我的第一个 Claude Code skill：/git-pr。1

它做我曾经做的所有事，而且做得更好。PR 描述比我写的要详尽，因为它读了完整的 diff 并恰当地总结了改动。我已经习惯了琐碎工作，以至于没注意到这其实是琐碎的。

省下的时间很重要，但真正的解锁是消除了心理负担。每个 PR 曾经都是一个小的上下文切换：停止思考代码，改而思考如何描述代码。现在我输入 /git-pr，然后继续下一件事。

审查改动有这个烦人的循环。

在本地预览改动，离开我正在做的事，杀死 dev 服务器，在新分支上重启它，检查一切是否运行正常，审查代码。

服务器构建耗时约一分钟，当你在上下文切换中时这痛苦地冗长。长到足以破坏专注力，但太短而无法做任何有用的事。

我把构建换成了 SWC，服务器重启降到了一秒以下。这令人欣喜。

听起来像是个小改动。其实不是。亚秒级重启意味着你永远不会离开流畅状态。保存文件，服务器已经启动了，检查预览。没有间隙让你的注意力漂移。这就像有尴尬停顿的对话和自然流畅的对话的区别。

让 Claude 看到会发生什么

在此之前，我检查每一项 UI 改动。在本地预览，扫一眼，决定是否符合预期。能用，但这意味着我是每个功能的瓶颈。

在 Chrome 扩展持续崩溃后，我切换到了 Claude Code 的预览功能。它让 agent 设置预览、保持会话数据，看到 UI 实际是什么样子。

我把它整合进工作流里：改动在 agent 自己验证了 UI 之前不算"完成"。这意味着我能委派验证，只在最终审查时介入——这也意味着 agent 可以运行更长时间而不需要监督。他们会自己捕捉错误。这比我当时意识到的要重要得多。

快速重建和自动化预览暴露了另一个摩擦点：我一次只能舒适地处理一件事。

我在审查来自其他 agent 和队友的 PR。工作流很痛苦：检出 PR 分支到 main，重建，测试。但这会搞乱我未提交的改动。所以我会 stash、checkout、重建、测试、切回来、pop stash。或者手动创建 worktree，设置它，尝试运行预览——结果发现端口与我其他运行中的服务器冲突。

我们的应用有前端和后端，各自需要自己的端口。每个 worktree 共享相同的环境变量，所以它们都会尝试绑定到相同的端口。同时运行两个东西是个麻烦。

我围绕这一点构建了一个系统。每当创建 worktree 时，每个服务器都会从唯一的范围获得分配的端口。没有冲突。如果我想，可以同时运行十个预览。

我从被两个并行分支压垮，变成了同时运行五个 worktree。我的工作循环改变了：在单独的 worktree 上启动多个 agent，每个构建不同的功能。他们只在自己验证了 UI 后才停止。

我会深度参与规划。然后我会消失，直到代码审查。Agent 自己捕捉错误在同时运行五个时重要得多。

审查也变得更顺畅了。没有设置的麻烦。没有重建。没有端口冲突。就是：读、验证、合并。下一个。

这是基础设施，不是 AI

我的角色改变了。我曾经从解决复杂问题中获得快乐，花费数小时精心打磨完美的 UI。我仍然有时会这样做，但现在少得多。变得更有趣的是构建让 agent 有效的基础设施。是管理一个十人团队而不是单人开发。像任何好的经理一样，你可以为你"团队"的所有工作邀功。

这些不是光鲜的问题。它们是基础设施。但基础设施决定了你是否在流畅状态，还是在与环境搏斗。

我在 Tano 做过的最高杠杆工作不是写功能。是构建了基础设施，把 commit 的涓流变成了洪流。

这些阶段中的每一个都消除了不同类型的摩擦：

/git-pr 消除了格式化的摩擦——把代码改动变成可呈现的 PR。

SWC 消除了等待的摩擦——进行改动和看到改动之间的死时间。

预览消除了验证改动的摩擦——我可以快速看到发生了什么。

worktree 系统消除了上下文切换的摩擦——处理多个工作流而不让它们冲突。

每当我消除一个，下一个就变得可见。当 PR 不费力时，我注意到我在重建上浪费了时间。当重建是即时的时，我注意到我不能并行运行东西。这是经典的约束理论——修复一个，系统立即向你展示下一个。

工作的性质改变了。我不是"使用一个写代码的工具"。我在一个紧密的循环中：启动一个任务，agent 写代码，我检查预览，读 diff，给反馈或合并，启动下一个任务。反馈循环是如此之紧密，以至于没有间隙让我的注意力泄漏。

构建东西现在是一种不同的快乐——它非常快，以至于游戏变成了改进速度。我能走得多快？当循环足够紧密时，工程本身就成了娱乐。

---

1. 之所以是 /git-pr，是因为我们仓库的 CLAUDE.md 说使用 Graphite，但我更喜欢原生 git。