折腾了一周 Claude 接入 AWS，我悟出了大模型调用的终极奥义

过去这一周，我的技术推特时间线几乎被 "Claude" 和 "AWS Bedrock" 这两个词淹没了。

起因是 Anthropic 官方的 Claude Code 终于支持了 AWS Bedrock。看着社区里大佬们纷纷晒出自己把 AI 工作流迁移到云端的截图，我没忍住诱惑，决定也跟风折腾一把。

结果？我度过了极其痛苦的几天。今天写下这篇文章，就是想和大家聊聊这段踩坑经历，以及我最终找到的“解药”。

那些让人崩溃的瞬间

我本以为这会是一个简单的 npm install 加上配置几个环境变量的轻松过程。但我太低估亚马逊 AWS 的门槛了。

第一天，我卡在了环境变量上。官方说加上 CLAUDE_CODE_USE_BEDROCK=1 就行。我加了，然后运行 claude doctor 检查环境。结果终端就死死定在 "Checking installation status..." 这行字上，一动不动。我以为是网络问题，挂了代理、换了节点，折腾了两个小时。最后去 GitHub 翻 Issue（#31478）才发现，原来这是个官方 Bug，程序就是会无限期卡死。

第二天，我开始和 AWS 的权限系统作斗争。由于我平时用的是 AWS SSO（单点登录），我理所当然地设置了 AWS_PROFILE。结果一运行就报权限拒绝。查了半天资料才知道，Claude Code 目前根本不支持 SSO 凭证链。我不得不退回到最原始的方法，手动导出临时的 Access Key 和 Secret Key 贴到环境变量里。

看着终端里密密麻麻的报错信息，我突然陷入了沉思：我到底在干嘛？

为什么大家还要前赴后继地跳坑？

冷静下来后，我仔细研究了那些成功迁移的大佬们的动机。比如知名的开源项目 Cline，他们最近甚至把底层的 Anthropic SDK 全删了，换成了原生的 AWS Bedrock SDK（PR #2742）。

其实核心诉求就一个：安全感。

对于那些手里攥着公司核心机密代码、医疗数据、金融报表的团队来说，把数据直接发给外部 API 是绝对不被允许的。AWS Bedrock 提供了一个封闭的沙盒，数据在自己的 VPC 里流转，亚马逊还承诺绝对不拿这些数据去训练模型。加上 AWS 原生的 Guardrails（护栏）功能，可以对 AI 的输出进行严格的合规过滤。

这种企业级的安全感，确实值得他们去忍受目前工具链的难用。

认清现实：我的妥协与最优解

但我只是个做独立产品的开发者啊！我没有几百万的用户数据需要保密，也没有严苛的安全合规部门天天盯着我。我花这么多时间去配 IAM 角色、搞凭证轮换，完全是本末倒置。

想通了这一点，我果断放弃了 AWS Bedrock，转投了 API 聚合平台的怀抱。

我现在用的是 147AI。说实话，用上之后有一种“早知如此，何必当初”的懊悔感。

它不需要你懂任何云架构知识。注册账号，拿一个 API Key，然后把代码里的 base_url 换成他们的地址，结束了。最爽的是，它完全兼容 OpenAI 的接口格式。我可以用同一套代码，今天调 Claude 3.5 写前端，明天换 GPT-4o 处理数据。不用管什么网络连通性，也不用处理恶心的权限认证，按量计费，清清爽爽。

结语

技术圈很容易产生一种“幸存者偏差”：大家都在讨论最高深、最复杂的架构，让你觉得不这么搞就落伍了。

但其实，工具终究只是工具。大厂为了合规去啃 AWS 这块硬骨头，那是他们的业务需要。对于我们普通人来说，找到像 147AI 这样能让你专注业务、不折腾基础设施的工具，才是真正的生产力奥义。

别被技术名词绑架了，去写代码吧。

参考资料：

GitHub Issue: anthropics/claude-code #31478
GitHub Pull Request: cline/cline #2742