为什么 Claude Code 一进大仓库就翻车

本地小项目里 Claude Code 写得飞起,搬到公司百万行老代码库就开始抽风——找错模块、token 烧穿、改完跑不起来——这种落差大家都熟。多数人最后的结论是 AI 编码工具只能玩玩 demo,企业级别还是算了。

但 Anthropic 自己的调研不是这么个画风。Stripe 一千三百多个工程师在用,Wiz 拿它把一个 5 万行的 Python 库一天转成 Go。能跑通的团队都在千万行 Monorepo、几十年的遗留系统、几十个微服务这种环境里。差距不在模型,在团队怎么搭脚手架。

它不是一个聊天机器人

落地失败的根源大多是认知错位:把 Claude Code 当 AI 聊天工具的命令行版来用。

它的定位是 Agentic Coding Environment——自主翻文件系统、grep 检索、跨文件追引用、跑 shell 跑测试、根据结果迭代。它不依赖代码索引,每次都基于最新的代码库工作,所以 RAG 类工具那种"检索出来的代码已经被删了"的尴尬不会发生。

自主翻文件系统、grep、跑测试、根据结果迭代的 Agentic 闭环

代价是它对工程脚手架的依赖比传统工具大得多。没有上下文治理、没有项目导航,它在大仓库里就是个看起来很自信、其实在盲搜的实习生。

大仓库里几个常见的坑

最常见的几种翻车:盲搜改错模块、token 一夜烧穿、长会话越改越乱、改完跑不起来。剩下的——团队配置不一致、跟内部系统对不上——多少都是这几个的变种。

解决这些不靠提示词魔法,靠几条朴素的工程纪律。

先把上下文当资源来管。 大仓库里限制 Claude Code 的不是模型多聪明,是上下文窗口多大。一次稍微复杂的排查就能产生几十万 token——源码、grep 结果、命令日志、报错堆栈、测试输出,混在一起塞进同一个会话。结果就是 AI 忘了你最初要干嘛。

上下文窗口是有限资源,各类 token 很快把它塞满

具体动作没什么花哨的:一个会话只处理一个需求;连续两次纠错没用就 /clear 重来;改错了用 /rewind 回滚不要硬 patch;Monorepo 里别在根目录启动,进到对应业务子目录再跑。

CLAUDE.md 写得轻一点。 这个文件不是 README,是给 AI 看的导航。但写太长反而稀释注意力——根目录放整体架构和最关键的避坑要点,子目录各自维护自己的模块约定。/services/payment/CLAUDE.md 里写"支付模块对账口径走这张表,历史遗留的兼容逻辑在那个文件,不要碰",比在根目录写一万字管用。

重构和复杂迭代,先 Explore 再 Plan 再 Implement。 跨文件改动直接让它写代码必然偏。先让它只读不改、把链路理清楚;再让它出方案给你看;方案没问题再动手。配上 Subagent 隔离上下文、MCP 接 Jira 和 GitLab,它才能看到代码以外的业务背景。

先 Explore 只读理清链路,再 Plan 出方案,最后 Implement

几句不太一样的话

上面这套方法论看着完美,真往大厂研发流程里塞,阻力大得很。

Claude Code 无论是 /goal 还是 /workflows,你想跑个夜里无人值守的"测试-修复-再测试"流水线,跑完之后一看账单估计要惊呆了。如今自动工作流的 token 费用高得吓人,成本得好好算一下。

维护 CLAUDE.md 的成本也被低估了。给几百个子模块挨个写、挨个更新接口和架构约定,本质上是用自然语言重写了一遍架构文档。对那些充满妥协和历史包袱的老系统,维护这套"AI 导航图"的时间,可能比直接改代码还多。写代码的工时变成调 prompt 的工时,对追求短平快的团队不一定划算。

最致命的还是隐私这一关。把百万行核心业务逻辑、密钥上下文、内部架构原封不动打包发给云端模型,在合规审查严格的厂里基本过不了审。所以不少团队真正在押注的是 Local-first 路线——本地沙盒里跑端侧模型,数据不出域。