为什么别人用 Claude Code 像开挂一样，而我天天在收拾残局？

有一次，我让 Claude Code 修一个登录状态失效的问题。

这个问题其实不复杂。用户刷新页面后，登录状态会丢失，正常来说应该去检查认证逻辑或者 Token 存储流程。

结果 Claude Code 修着修着，开始重构请求层。

请求层改完之后，又顺手调整了几个公共模块。

最后登录问题没解决，反而多出了两个新的 Bug。

当时我盯着终端里的修改记录看了半天，脑子里只有一个想法：

我明明让你修门锁，你怎么把房子拆了？

但更让我困惑的是。

当天晚上刷 X 的时候，我又看到了熟悉的内容。

有人说自己已经几个月没写代码了，开发工作几乎全部交给 Claude Code。

有人说自己不会编程，却靠 Claude Code 做出了自己的产品。

还有人说，一个人完成了过去需要整个团队才能完成的工作。

看到这些分享的时候，我是真的羡慕。

因为那时候我的体验完全不是这样。

---

刚开始使用 Claude Code 的时候，我一直以为问题出在模型身上。

同样的需求，上次这样做，下次换一种做法。

昨天刚纠正过的问题，过几天还能再犯一次。

有时候修 Bug 修到一半，突然开始优化架构。

有时候写功能写到一半，又开始重构代码。

最离谱的一次，我让它修一个小问题，它最终提交的修改涉及十几个文件。

我甚至开始怀疑：

是不是 Claude Code 根本没有大家说的那么厉害。

---

后来我开始看别人的使用经验。

结果发现一个很有意思的现象。

原来很多人也遇到过类似的问题。

有人抱怨长任务做到后面越来越跑偏。

有人抱怨同一个错误会反复出现。

还有人吐槽 Claude Code 特别喜欢说：

“已经修复完成。”

结果运行之后发现问题根本没解决。

看到这些讨论的时候，我反而松了一口气。

因为至少证明了一件事。

问题不只是出在我这里。

---

但新的问题来了。

为什么同样是 Claude Code。

有的人用起来像开挂一样。

有的人却天天在收拾残局？

后来我发现，那些真正把 Claude Code 用得很好的人，讨论的东西和我完全不一样。

他们讨论的不是模型，不是怎么写出最完美的提示词。

而是规则。

是工作流。

是记忆系统。

是自动化。

是验证机制。

甚至有人专门给 Claude Code 建了一套完整的管理体系。

看到这里的时候，我突然意识到一件事。

我可能一直理解错了 Claude Code。

---

以前我把它当工具。

后来我发现，它更像一个能力很强的新员工。

新员工最大的特点是什么？

不是能力差。

而是不知道你的标准。

不知道你的习惯。

不知道你的工作流程。

更不知道哪些事情该做，哪些事情不该做。

于是它只能猜。

猜对了很惊艳。

猜错了很离谱。

而我之前一直在做一件事情：

不断寻找更强的模型。

不断寻找更好的提示词。

不断寻找更厉害的技巧。

却很少去思考：

如果我是这家公司的老板，我有没有把规则讲清楚？

---

后来我做了一个实验。

我不再折腾模型。

开始折腾管理。

把经常犯的错误写成规则。

把验证流程固定下来。

把用户纠正过的问题记录下来。

把危险操作提前拦截掉。

把任务执行流程标准化。

结果很有意思。

模型没有变。

能力没有变。

但体验变了。

最明显的变化不是它变聪明了，而是它开始变稳定了。

以前，同一个任务可能会出现三种不同做法。今天这样做，明天那样做，过几天再来一次可能又是另一套流程。

现在虽然偶尔还是会犯错，但大部分时候都会按照同样的思路执行，结果变得更可预测了。

以前，一个错误可能要提醒三四次。

现在很多错误提醒一次就够了。

以前做复杂任务经常跑偏。

现在即使任务持续几个小时，也不太容易偏离最初目标。

---

最近我越来越觉得。

Claude Code 最大的问题可能从来都不是能力。

而是管理。

很多人看到别人用 Claude Code 做出很厉害的项目，会觉得差距来自模型。

但我最近的体会是。

差距很多时候来自系统。

同样的员工，放进不同的公司，表现可能完全不同。

同样的 Claude Code，放进不同的工作流里，结果也可能完全不同。

我一直以为自己在学习 Claude Code。

后来发现。

我其实是在学习怎么管理 Claude Code。

而这可能是我最近几个月最大的收获。

下一篇文章，我想具体聊聊。

我是怎么把 Claude Code 配成一家公司这件事的。

欢迎来到我的成长实验。