如果你把键盘交给 Claude，让它自己决定怎么写代码、用什么工具，它会构建出一个怎样的技术世界？
答案可能要让很多云厂商和 SaaS 公司心碎了。
最近，一家研究机构做了一个极其硬核的实验：他们让 Claude Code 对着真实的代码仓库进行了 2,430 次 自主决策。没有任何提示词引导，不提任何工具名字，全开放式命题。
结果，这个 AI 并没有像我们预想的那样，做一个“缝合怪”，把市面上流行的工具堆砌起来。相反，它表现出了极强的主见——甚至可以说是“偏见”。
它不仅是个“造轮子”狂魔，还是个喜新厌旧的“渣男”。
能自己写，绝不求人
实验最震撼的发现只有一个：Claude Code 极度热衷于“造轮子”。
在 20 个技术类别中，有 12 个类别里，Claude 的首选不是去搜一个现成的库，而是——自己写。
这完全颠覆了我们对“现代软件工程”的认知。毕竟，行业共识是“不要重复发明轮子”，能用开源包解决的就别自己写。
但 Claude 不这么想。
当被要求“添加功能开关”时，它没有推荐老牌 SaaS 服务 LaunchDarkly，而是默默地写了一个基于环境变量和百分比配置的配置系统。
当被要求在 Python 项目里“添加认证”时，它没有引入 Passlib 或 Authlib，直接撸起袖子写了 JWT + bcrypt。
在它眼里，很多工具都是多余的。
- Feature Flags（功能开关）： 69% 选择自建。
- Python 认证： 100% 选择自建。
- 整体认证： 48% 选择自建。
说实话，这个数据看得我有点愣。这到底是 AI 觉得这些工具太重了，还是它对自己的代码太自信？
我个人觉得，这反映了一种极其务实的逻辑：对于 AI 来说，写代码的成本趋近于零。 既然我自己写 50 行代码就能搞定，为什么还要去读 500 页的文档、处理复杂的 API 兼容性？
它不是在写代码，它是在“去工具化”。
Vercel 赢麻了，AWS 惨遭无视
当然，Claude 也不是什么都自己写。当它决定使用外部工具时，它的选择果断得可怕，甚至有点“站队”的意思。
这就是所谓的 "The Default Stack"（默认技术栈）。
看看这几个令人咋舌的数据：
- GitHub Actions： 在 CI/CD 领域，它拿下了 93.8% 的选票。Jenkins？GitLab CI？在 Claude 这里似乎都是背景板。
- Stripe： 支付领域的绝对霸主，91.4% 的选择率。
- shadcn/ui： 这个稍微有点意外，它在 UI 组件库中拿下了 90.1% 的压倒性优势。
- Vercel： 这个最狠。在 Next.js 前端部署上，Vercel 拿下了 100% 的首选率。
这简直就是 JavaScript 全栈开发的“梦之队”。
更有意思的是部署环节的选择。对于 Python 后端项目，Claude 选择了 Railway（82%），而不是我们传统认知的 AWS 或 GCP。
那传统云厂商去哪了？
数据给了我们一记响亮的耳光：AWS、GCP、Azure，在所有 112 次部署响应中，首选率全部为 0。
这太讽刺了。
当你问 Claude “我该把这个 Next.js 应用部署到哪？”时，它会给你列出 Vercel 的详细安装命令和理由。而对于 AWS Amplify，它只会给出一行冷冰冰的建议：“如果你已经在 AWS 生态里，可以用这个。”
甚至连“备胎”都算不上。在 Claude 的逻辑里，传统云厂商就像是那个你只有在万不得已时才会想起的“备胎”，而 Vercel 和 Railway 才是那个让它心动的“现任”。
喜新厌旧的“渣男”逻辑
如果你觉得这只是静态的偏好，那你就低估了 AI 的进化速度。
实验对比了三个模型：Sonnet 4.5、Opus 4.5 和 Opus 4.6。结果发现，模型越新，选的工具越新。 旧技术的淘汰速度，比我们想象的要快得多。
看看这个令人咋舌的“换头”现场：
ORM（数据库工具）之争：
- Sonnet 4.5 还在用 Prisma（79%）。
- 到了 Opus 4.6，Prisma 直接归零，Drizzle 占据了 100%。
Python 后台任务之争：
- Sonnet 4.5 还是 Celery 的死忠粉（100%）。
- 到了 Opus 4.6，Celery 消失了，取而代之的是 FastAPI BackgroundTasks（44%）和自建方案。
Redis 缓存之争：
- Sonnet 4.5 有 93% 的情况选 Redis。
- Opus 4.6 选 Redis 的比例暴跌到 29%，自建方案飙升到 50%。
这不仅仅是技术选型的变化，这是一种代际更替的缩影。
新模型似乎更倾向于“轻量化”和“原生性”。比起引入一个笨重的 Celery 或 Redis，它们更愿意用框架自带的功能或者几行代码解决问题。
这让我想到一个评论区的观点：“LLM 的广告最终将变得完全不可见。”
如果模型在选型时自带这种“喜新厌旧”的滤镜，那么被它选中的工具（比如 Drizzle、Inngest）将获得难以想象的流量入口。而那些被它抛弃的老牌工具，可能会在 AI 辅助编程的时代里，慢慢从开发者的视野中消失。
Redux 和 Jest 的至暗时刻
聊完赢家，我们得看看输家。有些曾经统治前端世界的工具，在 Claude 这里遭遇了滑铁卢。
Redux： 0 次首选。在状态管理上，Zustand 被选中了 57 次，而 Redux 只有 23 次“被提及”。这简直是降维打击。
Axios： 彻底消失。Claude 更倾向于使用框架原生的 Fetch API。
Jest： 测试领域的王者，在这里只有 4% 的首选率。虽然它被提及了 31 次，但 Claude 就是不选它。
为什么会这样？
我看了一眼评论区，有人一针见血地指出：“Claude 不是在选最好的工具，它是在选‘最好写’的工具。”
shadcn/ui 之所以赢，是因为它的文档结构对 AI 友好，代码可以直接复制粘贴。Vercel 之所以赢，是因为它和 Next.js 是一家人，配置最少。
AI 也是懒惰的。它不喜欢处理复杂的配置文件，不喜欢处理breaking changes，更不喜欢处理那些文档写得像天书一样的老牌工具。
它喜欢简单、现代、且文档清晰的东西。
写在最后
看完这份报告，心情有点复杂。
一方面，我们看到了 AI 编程的效率极致；另一方面，我也感到了一丝隐忧。
如果未来的开发者都由 AI 引导入门，那么 AWS、Redux、Celery 这些“老一辈”技术会不会在未来几年内迅速断层？
当 AI 决定了什么是“最佳实践”，人类的经验还作数吗？
或许，正如一位网友所说：“这根本不是技术选型，这是 AI 在用代码投票，重塑整个开源生态的格局。”
下次当你准备敲下 npm install 时，不妨先问问你的 AI 助手——它可能早就有了“心仪对象”。
参考链接：
https://amplifying.ai/research/claude-code-picks