> ## Documentation Index
> Fetch the complete documentation index at: https://cc.cyber101.cc/llms.txt
> Use this file to discover all available pages before exploring further.
# 使用 Claude Code 的六周回顾
> 在生产开发中使用 Claude Code 六周后的回顾与思考
*2025年7月30日 - Orta Therox*
回想起来，这不过是几周前的事，感觉真是不可思议。
Claude Code 极大地改变了我与大规模编写和维护代码的关系。我仍然能写出同等质量的代码，但我感觉自己获得了一种难以言喻的全新表达自由。
Claude Code 将我从编写每一行代码的繁琐中解放出来。我仍然认为自己要为交付给 Puzzmo 的所有东西负全责，但是，那种能够瞬间创造出整个场景，而不是逐行逐字敲代码的能力，实在是太强大了。
我相信，有了 Claude Code，我们正处于编程界的“摄影术发明”时期。当一个概念可以直接呈现，而你只需用代码审查和编辑技巧将其塑造成你想要的样子时，亲手“绘画”就再也没有那么大的吸引力了。
如果这种思路让你感到畏惧，那么欢迎来到2020年代中期——这里再无稳定可言，变化是唯一的不变。抱歉，我并非说所有文化变迁都是“坏”的，但我确实认为大型语言模型（LLM）已经在造成社会损害，并且未来会更糟——但这个精灵已经从瓶子里被放出来了，它将从根本上改变我们对“编程”的认知。
## [对过去六周的回顾](#对过去六周的回顾)
本文建立在我使用 Claude 一周后写的《关于使用 Claude 编码》一文的基础上。如果你觉得我已经被 AI“洗脑”了，你可以在那篇文章的开头读到我对 LLM 更为细致入微的看法。
话虽如此，这确实是颠覆性的。我想通过过去六周在 Puzzmo 工程领域的活动，给你一些视角，让你看看我所见证的一切。
### [维护成本显著降低](#维护成本显著降低)
我曾和许多人一起参与过各种项目，其中一些单调乏味的任务需要花费数周全职时间才能完成，比如：“将这个 JS 代码库转换为 TypeScript”、“更新到 Swift X 版本”、“切换到 monorepo”。这些都是需要无数次 rebase 的精细迁移工作。
以下是我在获得 Claude Code 权限后，**独自**完成的一系列任务：
* 将数百个 React Native 组件转换为纯 React
* 用自研或成熟、有支持的替代方案替换了3个非简单的 RedwoodJS 系统
* 为多个内部和外部项目构建了复杂的 REPL（交互式解释器）
* 为几乎所有数据库模型切换到了一致的布尔值‘flags’系统
* 从 Jest 迁移到 Vitest
* 为 React 制定了我们的前端测试策略
* 将许多在代码中定义的东西移至通过 CMS 运行
* 在服务器端渲染方面取得了重大进展
* 因 API 废弃重写了 iOS 应用的启动系统
* 为排行榜、每日挑战等系统构建了一套由 LLM 创建（并明确标注如此，然后手动注释）的文档
* 将我们设计系统的大量基础组件转换为使用 base-ui
* 将大量代码从内联样式迁移到 stylex
* 将 puzzmo.com 中的所有动画转换为与游戏相同的技术
* 修复了多个自 Puzzmo 创立以来就存在的 bug
* 更新了所有 Vite 集成
* 将所有 Puzzmo 生产项目迁移到 Node 22
* 将游戏仓库转换为一个真正的 monorepo
* 为 Puzzmo 应用构建了 iPad 支持
这些项目没有一件是我今年作为 Puzzmo 的“业务开发”人员日常需要做的“本职工作”。这些是**字面意义上的副项目**，是我在做别的事情时**凭一己之力**完成的。
为了让大家明白这对我来说有多震撼，我需要强调一下：在过去六周里，我在继续完成 Claude Code 出现之前的既定路线图工作的同时，独自完成了以上所有事情。大部分是在后台进行的（对于一些较大的项目，会花一天时间进行润色）。我的工作时间也没有从每天约10小时增加到16小时之类。
这对我来说是积压了多年的\*“技术债”/“技术创新”\*！在短短一个半月内就完成了。
如果你明白自己在做什么，那么构建和处理那些通常被归为“技术债”范畴的各种任务的能力，*根本不需要被当作债务来对待*，你完全可以在处理其他工作时顺手就做了。
现在，“在日程表上挤出点时间”的成本变得如此之低，以至于你可以在开会前就启动一项任务并取得实质性进展，然后在会后再决定这个方向是否正确。这简直令人难以置信。
### [先写代码，后做决定](#先写代码后做决定)
我一直在努力养成一个习惯：在完全否定一个想法之前，先试一试。例如，从 Puzzmo 项目第一天起，我就一直在等待确定前端的测试策略，因为我想招聘一个人来全权负责“puzzmo.com”，而其中的一部分工作就是弄清楚如何减少我们遇到的回归问题。
为前端制定测试策略并非易事，我见过很多糟糕的测试套件，它们过度测试，变得脆弱，工程师们不喜欢使用。网络、React、上下文范围、DOM、工具的不稳定性等各种因素交织在一起，最终你只能在自己用过且有信心维护的方案中寻找那个“最不坏”的。
我曾想，是否需要等待别人来做。但后来，我没有直接“添加一个测试套件”，而是选择让 Claude Code 在两周的时间里，为我提交的每一个前端 pull request 编写测试。
然后，看完这些测试后，我就把它们删掉了。这个过程给我的工作流程增加了额外的5分钟，但每次都让我了解到其他项目是如何处理这个问题的。几周后，我已经准备好系统性地着手解决这个问题了。
为每个 pull request 写测试然后再删除，这种想法在以前是不可想象的，会耗费太多时间，我绝不可能同意这样做。
再举一个最近的例子，我在 Slack 上看到一个关于在我们的 CMS 工具中为 CRUD 资源制作抽象层的讨论，于是我就在后台“vibe”了半天去尝试实现它：
> 一个关于用 Relay + GraphQL 构建 CRUD 应用的 Slack 讨论
> 结果成功了吗？没有。但这次探索值得吗？当然。
### [“双克隆”生活方式](#双克隆生活方式)
Anthropic 提供了关于如何使用 worktrees 的信息——但我想提出一个更简单的方法：两个克隆仓库，不同的 VS Code 配置文件。
这意味着你可以在每个克隆中独立工作，并且通过使用不同的主题，在视觉上区分你的工作区：
我最好的论据很简单：每个克隆代表一个你可以同时处理的 pull request。如果你在编写 pull request 并与他人协作，这一点仍然非常重要。我设置了让我们的开发服务器能够关闭任何占用所需端口的进程，这样在 Claude Code 处理工作时，你可以轻松地在两个克隆之间切换，而无需等待构建完成。
### [游戏设计协作](#游戏设计协作)
自 Puzzmo 创立以来，制作一款游戏的流程是这样的：
* 我们使用各种技术创建一些原型
* 我们集体对原型进行反馈和迭代
* 我们决定这款游戏是否值得发布
* 游戏团队用我们的技术栈，并集成 Puzzmo 的系统，从头开始重写游戏
这个过程在任何生产代码被编写之前，就需要花费数周时间。以我们目前的产出速度，我们大约每季度才能发布一款达到我们期望的打磨水平的游戏。
在后 Claude Code 时代，这个模型可以大大简化，这也是我们正在探索的一个领域。我创建了一个新的 Puzzmo monorepo（现在有三个了：“app”、“games”，以及这个新的“prototypes”），它模拟了游戏仓库的基础设施，但对交付的代码类型有着截然不同的期望。有了这个仓库，游戏设计师可以在几个小时内从一个想法变成一个在 puzzmo.com 上供管理员使用的东西。你写好代码，然后进入我们的管理后台 CMS 点击几个按钮，就完成了。
从“这对团队有益”到“我们应该公开发布”，还需要我和 Saman 的一些实际操作，但这与我们目前的生产流程相比，工作量完全不在一个量级。
我们用这种技术发布了《Missing Link》，它似乎很受欢迎。但这……实际上也给我们带来了一点问题。我乐于让游戏设计师的代码在 Puzzmo 上作为一个限时实验运行，但我不希望这成为 Puzzmo 正式游戏库的一部分。
那种让游戏设计师能够快速制作原型的灵活性，也同样意味着代码质量达不到我想交付给用户的标准。这是我们仍在努力解决的一个矛盾。
### [副项目的“说干就干”](#副项目的说干就干)
在我整个编程生涯中，像所有人一样，我的副项目和一次性项目的能力很大程度上受限于我仍然想拥有自己的生活。我选择投身于大型开源项目，以使我对这门手艺投入的时间感到有价值。
具体来说，这意味着我把时间花在像 CocoaPods、Danger、Jest、GraphQL 这样的项目上，而不是做一些有趣的项目来探索技术或解决一些小问题。
现在不同了。我可以先试一试，再决定我是否喜欢结果。在用 Claude Code 进行一小时的探索中，我感觉自己大约能完成一个周末的探索量。
#### [示例：内联聊天记录](#示例内联聊天记录)
以这篇博文为例。当我在构思它时，我想，*“如果能内联显示 Claude Code 的对话就好了”*，接着又想，*“为它恢复 Adium 主题会不会很有趣”*。于是，我就动手了。
我大致勾勒出了我想要的东西的草图，并预先做了相当详细的描述，然后带狗散步一小时，回来时已经有了一个合理的 CLI（命令行界面）雏形，而这个东西如果我手动构建，可能需要花费几个小时。
代码量不多，但需要做很多研究：如何重现 Adium 主题的 HTML，如何理解 Claude Code 的消息格式，如何处理本地预览的资源。
在它基本能用，可以把各种想法正确地融合在一起之后，我对其进行了润色。
我已经润色和部署了足够多的 npm 模块（174个？！），所以这对我来说是信手拈来的事。我把这个项目当作看 Apex Legends 直播时的有趣副业。
如果你看聊天记录，你会发现我确实花了一些时间来研究如何过滤某些内容，如何以特定方式显示消息，但这都是系统性的“监工”，而且是我根本不关心的代码。
这样的一个功能是一个**完整的周末项目**，对我来说，轻松就需要10-12个小时才能做好并觉得可以发布。但现在，大部分工作在我离开的时候就完成了，然后润色是零星进行的。整个过程可能只花了我大约2小时的思考时间？**这太疯狂了**。
如果你想看我为了发布这篇博文而进行的其余对话，它们在这里：
* 按时间顺序接续上面的2个：3, 4, 5, 6
如果你安装了 Adium，现在就可以使用它，运行 `npx claude-code-to-adium`，它会引导你完成一个向导，最终生成一个包含 html/css/images 的独立子文件夹。
### [这些对话是什么样的？一些例子](#这些对话是什么样的一些例子)
我将尝试从我开始使用以来，在19个不同的仓库/项目中进行的147次对话中，挑选一些出来。我将力求目标的广度，并在旁边给出我的看法。
#### [创建一个“删除30天前游戏”的任务](#创建一个删除30天前游戏的任务)
这是一次对话，我大致知道我想要什么，但也知道我并不真正了解 PostgreSQL 索引及其对批量删除的影响。
所以我首先问了一个普遍性的问题，它利用我的 prisma 定义文件来确定数据库中当前的设置。
我们迭代了一个脚本改进，并使其可以在本地测试。
在本地尝试后，我给了它一个“还行”的评价，然后要求一个更明确的技术方案。
设置好之后，我检查了所有代码，在本地审查，修正风格，使其符合我的编码习惯。
你可能会注意到它做了一些猜测（“我们10-20%的游戏记录是匿名用户的”），然后基于这个猜测做出大胆的承诺：
> *“索引大小减少了80-85%！”*
> 对此我表示怀疑。然而，代码是可靠的，它比我写的日志要多得多（对于一个日常任务来说很有用），而且我感觉我理解了索引的作用。我还去添加了一些胶水注释，比如\*“这个脚本与迁移Y中的索引一起工作，所以任何更新……”\*
#### [为纵横字谜添加“Barred Grid”支持](#为纵横字谜添加barred-grid支持)
我知道这将是一个噩梦般的 PR，你可以在这里看到。
我首先在仓库中添加了固定的示例数据，并通过一个我之前留下想法的 issue 提供了上下文。开始时，我把这个任务框定为“这是长期目标，为了开始，我们将做Y”。这里的Y是指栏杆的 ASCII 快照。
我们从构建一个可视化工作的方式开始，Claude Code 做得非常接近了。最后，我接手了它的工作并完成了集成。
一旦我有了可视化解决方案的方法，我们就可以开始处理工作的主要部分了。
我使用基于 ASCII 快照的测试，通过在导入的文件格式 jpz 中使用栏杆的显式版本来硬编码测试，然后创建了一个依赖于我们将要创建的算法的测试。这意味着我，以及 Claude，有了一个非常明确的方式来判断算法的工作情况。
现有的 jpz 导入算法太幼稚了，导入的线索是错误的，这意味着我们花了很长时间试图让两个快照匹配。Claude 不停地作弊，硬编码答案！直到我重新评估了所有线索（通过为这些线索的导入制作一个单独的测试），才对算法进行了一次全新的审视，并开始有所进展。
#### [为一个谜题创建 REPL](#为一个谜题创建-repl)
这是一个为游戏《Circuits》视觉化设计谜题的快速、完全“vibe”出来的原型。
我给了一张截图，并试图描述游戏如何运作以及我设想的 REPL 如何工作。我们迭代了几次，我基本上没有写任何代码。
然后，这个原型被交给其他人进行实验，并弄清楚他们对于如何为这个游戏制作一个可用的开发工具有什么看法。
#### [纵横字谜的打印页面](#纵横字谜的打印页面)
我想为纵横字谜的可打印 PDF 设计一个版面。我已经有了一个可以生成它们的工作流程，需要专门处理布局。
我本以为这是一个相对容易处理的问题，但结果发现，根本没有一套 CSS primitives 能够同时支持分栏**并**围绕图像重新排版。
Claude 在尝试我正在使用的不同 CSS 属性和系统方面表现得很好，我用不同的方式描述或展示问题，但始终没能让它正常工作。
我认为我在这些对话中想错了核心抽象，要么是我的建议太具体，要么是通过半吊子的答案进行实验。
最后，我想我将不得不重写它，使用 JavaScript 来实现我想要的布局。
### [但说真的，这东西到底有多好？](#但说真的这东西到底有多好)
也许一个有趣的收尾方式是，我如何看待这个工具的能力。Claude Code 知识渊博，你可以轻松地以链接、截图和额外代码的形式向它发送参考资料以提供上下文。我发现它大概处于“后初级”阶段，经验丰富，精力充沛，但它在记住你要求的事情方面做得并不好（即使通过 `CLAUDE.md`），而且它负责的范围显然是微不足道的。
在 Artsy 的早期，我们为工程师设立了一个五级技术阶梯：
> **工程师 1** - 能够交付一个明确定义的产品功能。
>
> **工程师 2** - 能够独立负责一个产品功能，并能处理好与他人的沟通。
> 要达到第二部分，需要以某种形式实际存在，并具有某种程度的主人翁意识。这是一个有趣的话题，因为我猜它可能在某种意义上拥有所有权，即代码库中那些完全由“vibe”生成且人类不怎么阅读的部分，完全由这些工具“拥有”。
> 然而，从实际角度来看，作为一名经验丰富的工程师，不断审查、修改和理解其输出的配对伙伴——你真的可以把 Claude 当作一个拥有无限时间和耐心、有点过分谄媚、并且能在合理约束下以前所未有的速度交付合理代码的结对编程伙伴。
> 而这，就像一种全新的创造方式。
***
**来源:** [https://blog.puzzmo.com/posts/2025/07/30/six-weeks-of-claude-code/](https://blog.puzzmo.com/posts/2025/07/30/six-weeks-of-claude-code/)
**作者:** Orta Therox
**日期:** 2025年7月30日
* [一个半月高强度 Claude Code 使用后感受](/docs/guides/onevcat-experience) - 一个半月高强度使用 Claude Code 的个人体验和见解
* [社区技巧](/docs/guides/community-tips) - 发现 ClaudeCode 社区分享的技巧和窍门