失去 Claude Code 之后

——关于工具、依赖，以及一个程序员突然缩短的双手

前些天，因为一些原因，我不得不停止使用已经非常熟悉的 Claude Code，转而尝试其他AI编程工具。

起初没觉得这是什么大事。

现在的AI编程工具已经不少了。Codex、OpenCode，以及各种可以接入的模型，能力都在快速进步。况且我也不是刚学编程的新手，Linux、Docker、网络配置、数据库、微服务部署，这些东西原本就会。无非是换个工具，重新适应一下罢了。

可真正换过之后，才发现麻烦远比想象中多。

最初只是一些小事。

比如，我想在一台服务器上部署刚写好的服务。按照过去的习惯，把需求交代给Claude Code，它便可以通过SSH连接目标主机，检查环境、安装依赖、上传程序、调整配置、启动服务，然后测试接口是否正常。

过程中如果出了问题，它会继续查看日志，分析原因，修改后重新部署。只要权限允许、任务足够明确，很多事情并不需要我反复介入。

这当然不是说它从来不犯错。有时它也会误判，有时还会把简单问题弄复杂。但用得久了，我大致知道它能做到什么程度，哪些地方需要提醒，哪些操作必须亲自确认。

这种熟悉很重要。

后来换成Codex，才发现许多过去顺手完成的事情，现在需要重新考虑执行环境、权限和工具调用方式。有些任务它能很好地完成，有些则在当前配置下无法直接执行，或者执行到一半就需要人工接手。

单论理解代码、分析问题、修改程序，Codex并不逊色，有些时候甚至更好。

但我的工作并不只有写代码。

这就像一个人原本请了位很能干的助手，写文书、查账、跑腿、盯工程都能做。后来换了一位，学问可能更好，写出来的文章也更漂亮，却不太方便出门办事。

你不能说新来的没有本事。

只是原来那些事，突然又得自己跑了。

一、从写代码到管理一群机器

回想起来，我对Claude Code的依赖，是在不知不觉中形成的。

最开始，当然还是让它写代码。

写函数、改接口、重构模块、补测试，这些是AI编程工具最常见的用途。那时它对我的帮助，主要是减少重复劳动。

后来，我开始让它处理开发环境。

一台新服务器装好Ubuntu，需要配置Go、Python、Node.js、Docker，还要处理各种依赖和网络问题。以前这些事情得自己一项项完成，碰上版本冲突，半天就过去了。

有了Claude Code，我可以把任务交代清楚，让它先检查机器的实际情况，再决定如何安装。

接下来是部署。

程序写完了，需要编译，上传到服务器，配置Nginx，启动Docker容器，检查服务日志，验证接口。

再后来，是日常运维。

我手里有多台电脑和服务器，有的运行数据库，有的部署微服务，有的承担反向代理，还有一些带GPU，专门运行语音识别、语音合成等模型。

机器多了以后，麻烦并不在于某一台有多难管理，而在于它们总有各种零碎的问题。

某个容器重启了，某个接口响应变慢了，某台机器的磁盘空间不够了，或者一项服务明明显示运行正常，实际却已经无法提供完整功能。

这些问题单独处理并不复杂，但需要不断切换上下文。

登录一台机器，检查日志；再登录另一台，查看网络；发现问题可能出在反向代理上，又得回到入口服务器。

有时折腾一圈，真正需要修改的不过是配置文件里的一个参数。

后来，我把一些日常检查工作也交给了Claude Code，配合已有脚本和连接，让它协助巡检主机、查看微服务状态、整理系统数据，并分析可能存在的问题。

它能把分散在不同机器上的信息汇集起来，再给出一份相对完整的判断。

我不必亲自盯着每个终端窗口。

渐渐地，我的工作重心发生了变化。

过去，我花大量时间处理具体操作。后来，我更多地考虑系统应该如何设计、哪些服务需要调整、下一步该增加什么功能。

这种变化很容易让人上瘾。

因为它不只是让工作变快，而是让一个人有能力同时照顾更多事情。

二、突然回到手工时代

真正意识到问题，是在一次普通的部署任务中。

我像往常一样，希望新的工具帮我连接开发服务器，检查环境并完成安装。

结果事情并没有按预期推进。

工具可以理解我的要求，也能分析应该执行哪些命令，但在实际访问服务器时遇到了限制。于是，我需要自己登录机器，执行检查，复制结果，再让它分析下一步。

有时还得重新调整配置，或者换一种执行方式。

一件原本已经形成习惯的事情，突然变成了人和AI之间反复传递信息的过程。

这让我非常不适应。

倒不是那些命令有多难。

问题在于，我已经习惯了不去做这些事。

比如部署一个Docker服务，以前我关心的是部署后是否正常，接口能否访问，日志有没有异常。

现在，我又得关心SSH是否连得上、命令在哪台机器执行、文件怎么传过去、工具能否获取执行结果。

这些当然也是工程工作的一部分，但我曾经以为，自己已经可以把相当一部分交给工具了。

后来又尝试OpenCode，接入Sol 6.1。

情况有所改善。

OpenCode在工具调用、终端执行和自定义配置方面提供了更多灵活性。通过适当配置，很多开发和运维任务可以重新串联起来。

但实际使用下来，还是觉得与过去的体验有差距。

这种差距不一定来自模型本身。

有时是工具对环境的控制能力，有时是权限管理，有时是任务执行的连续性，还有时只是它遇到错误后，能不能沿着原来的目标继续做下去。

一个AI助手能正确告诉我下一步该执行什么，和它能够自己执行、检查结果、发现错误并继续修正，是两种很不一样的体验。

前者是有人在旁边指导。

后者才是真正替我分担工作。

当然，这些差异与具体版本、配置和运行环境都有关系。换一套部署方式，结果可能完全不同。

但对一个已经形成固定工作习惯的人来说，工具的潜在能力是一回事，眼前能否顺畅地把事情做完，是另一回事。

三、我究竟失去了什么

最初几天，我有一种很奇怪的感觉。

电脑还在，服务器还在，项目也都在。

我知道每个系统大致是怎么运行的，也知道出了问题应该从哪里查起。

可面对这些原本熟悉的工作，竟然有些提不起精神。

尤其是想到要重新登录服务器、检查环境、修改配置、部署测试，就觉得麻烦。

这种感觉甚至有点可笑。

明明所有事情以前都会做，现在不过是需要自己重新动手，怎么就觉得什么都干不了了？

后来才慢慢想明白。

我失去的不是知识，也不是技术能力，而是一种已经习惯的工作节奏。

过去，一个想法出现，我可以立即让Claude Code着手实现。

它修改代码，我同时考虑下一步的设计。它部署测试，我去处理另一个项目。它遇到问题，会先尝试解决，实在需要我决定时再停下来。

当然，实际过程没有这么理想化。有时我也要不断纠正它，甚至推倒重来。

但总体上，我已经习惯了把任务交出去，再根据结果作判断。

现在，很多任务重新回到自己手里。

每件事都不算大，可它们加在一起，会不断打断思路。

尤其在软件开发中，最耗费精力的未必是敲代码，而是反复切换问题。

刚刚在思考某个模块的架构，突然需要处理服务器环境。环境刚弄好，又发现网络不通。网络问题解决了，之前想到一半的设计却已经忘了。

Claude Code过去帮我承担的，很大一部分就是这些切换成本。

失去它以后，才发现这部分工作原来占据了如此多的时间。

四、人的能力，究竟算在哪里

这件事让我想到一个有些古怪的问题。

假设一个人能够熟练使用计算器，完成复杂计算。那么计算器算不算他计算能力的一部分？

如果不算，为什么我们评价一个工程师的工作能力时，又会把他使用各种工具的本事考虑进去？

再比如，一个人不会背诵所有Linux命令，但他知道如何查找、组合和使用这些命令，能够维护复杂的服务器系统。

我们显然不能因此说他不懂Linux。

现代人的能力，早就不是单纯存在于脑子里的知识。

它还包括书籍、软件、工具，以及如何使用这些东西的经验。

哲学中有一个颇有意思的观点，叫作“延展心智”。

它认为，在某些条件下，人的认知活动并不完全局限于大脑，还可能延伸到外部工具和环境之中。

比如一个人长期依靠笔记本保存信息，查阅笔记已经成为他记忆活动中稳定的一环。

那么，这本笔记本在功能上，就可能承担了部分记忆的作用。

AI编程助手让我对这个观点有了更直接的感受。

因为它延伸的已经不只是记忆。

过去，搜索引擎帮我找到知识，IDE帮我补全代码，脚本帮我执行固定操作。

而Claude Code这样的工具，开始帮助我完成一段连续的工作过程。

从理解任务，到选择方法，再到执行、检查和修正。

这不意味着它真的成为了我的大脑，也不意味着我把所有判断都交给了它。

但在实际工作中，它确实承担了原本需要我亲自完成的一部分认知和操作活动。

久而久之，我开始按照这种能力安排工作。

承担更多项目，管理更多机器，同时推进更多任务。

我的工作规模扩大了，可每天能够投入的时间并没有增加。

多出来的那部分能力，实际上来自工具。

所以，当工具突然不可用时，我面对的不是原来那份工作，而是一份按照更高生产力水平安排好的工作。

这大概才是我觉得自己被抽空的真正原因。

五、工具改变了人，也改变了人的耐心

还有一件事值得琢磨。

使用Claude Code久了以后，我发现自己对许多事情的耐心变差了。

过去配置一套开发环境，花半天时间是正常的。

现在如果半小时还没有弄好，就会觉得效率太低。

过去部署一个服务，需要自己检查每个环节。

现在如果AI不能一次性完成大部分操作，就会觉得这个工具不够好用。

可这些工作的复杂程度，并没有因为我不愿意做就消失。

改变的只是我的预期。

技术进步常常如此。

有了汽车，人们开始觉得走十公里很远。

有了手机，人们开始无法忍受联系一个人需要等上半天。

有了即时通信，连几分钟不回复消息，都可能让人心生疑虑。

工具不断提高效率，也不断改变我们对正常效率的判断。

AI尤其如此。

因为它缩短的，不只是完成任务所需的时间，还包括从产生想法到开始行动之间的距离。

过去想到一个新功能，我会先评估工作量，看看有没有时间做。

后来，很多时候我会直接让AI开始尝试。

想法不再需要经过那么多准备，就有机会变成现实。

这种变化让人兴奋。

但它也使人越来越难以忍受那些不得不亲自动手的琐事。

有时候，我甚至怀疑自己是不是被惯坏了。

不过，既然已经体验过更高效的工作方式，要求自己心甘情愿地回到过去，似乎也不太现实。

六、把能力放在谁的手里

经历这次工具切换，我开始认真考虑另一个问题。

如果AI助手已经成为开发和运维工作的重要组成部分，那么整个工作体系是否应该依赖某一个特定产品？

以前设计软件系统时，我很注意避免单点故障。

数据库要考虑备份，服务要有健康检查，关键配置要能恢复，重要数据不能只保存在一台机器上。

可轮到自己的工作方式，却没有做到同样的事情。

许多流程之所以顺畅，只是因为Claude Code恰好能够把它们串起来。

一旦换了工具，原先隐藏在便利背后的依赖便暴露出来。

比如远程服务器管理，如果所有连接方式、操作习惯和执行流程都依附于某一个助手，迁移时就会很麻烦。

但如果主机清单、SSH配置、部署脚本、健康检查和日志分析都有相对独立的实现，那么无论使用Claude Code、Codex还是OpenCode，都可以在此基础上工作。

当然，不同工具的体验仍然会有差异。

但至少不至于因为换了一个助手，就得重新搭建整套工作流程。

说起来，这也不是什么新思想。

无非是把过去软件工程里讲的解耦、标准化、可替换性，用到AI工作环境上。

以前觉得这些原则主要是用来约束程序的。

现在发现，它们也应该用来约束自己对工具的依赖。

七、失去之后

写到这里，我仍然觉得Claude Code是我用过的最顺手的AI开发工具之一。

尤其是在跨主机操作、环境安装、部署测试、问题排查这些工作上，它与我的工作方式非常契合。

这不意味着它在所有方面都优于Codex或OpenCode，更不意味着其他工具以后无法达到相同的效果。

只是对于已经习惯了一套工具的人来说，迁移不是简单地替换一个模型。

它还意味着重新建立信任，重新熟悉执行边界，重新调整自己与工具之间的分工。

这些成本很难通过跑分体现。

有时候，真正让人依赖一个工具的，并不是它有多聪明，而是你知道把事情交给它以后，大致会发生什么。

最近，我仍然在不断尝试新的组合。

有些原来做不到的事情，经过配置后已经可以完成。有些工作还需要人工介入。偶尔也会发现新工具有自己的长处，并不像最初想象得那么难用。

工作总归还得继续。

只是这次经历让我意识到，自己早已不再按照一个纯粹依靠双手的程序员来安排工作。

我习惯了让AI帮我写代码、管理机器、处理环境、检查服务，甚至在夜里替我留意那些不太安分的微服务。

时间久了，这些能力便成了日常生活的一部分。

直到有一天，它们突然不在了。

那种感觉很难形容。

并不是失去Claude Code以后，我真的什么都不会做了。

而是我清楚地记得，自己不久以前还能轻松做到那么多事情。

现在依然知道该怎么做，只是每件事都要花更多时间，更多精力，更多耐心。

最难受的，恰恰是这种落差。

人似乎很容易适应能力的增长，却很难适应能力的收缩。哪怕那份能力原本就借自外物。

我想，以后大概还会遇到类似的事情。

今天是Claude Code，明天可能是另一个工具。技术更新得太快，谁也不知道几年以后，我们会把多少工作交给AI。

但至少这一次，我开始明白一件事：

当一个工具好用到让人忘记它的存在时，它就已经不再只是一个工具了。

它悄悄改变了你的工作习惯，改变了你对效率的预期，也改变了你认为自己能够完成多少事情。

直到失去它的那一天，你才发现，原来自己早已习惯了拥有那么长的一双手。

如今，这双手突然缩短了。

我只好重新坐回终端前，打开SSH，输入那些熟悉得不能再熟悉的命令。

屏幕上跳出密码提示。

我愣了一下。

以前，这一步好像也不用我来做。