让Claude Code在个人电脑上跑起来很简单。但把它变成整个团队都能触发的共享计算资源，完全是另一回事。关于本地部署的文章已经很多，团队协作层面的实践却少得可怜。

我推动这个转变，源于我们团队处理故障部署的方式。我是团队里唯一的DevOps工程师。一次CloudFormation部署失败，Slack通知弹出，然后十有八九有人@我问怎么回事。

打开网易新闻 查看精彩图片

我理解这种反应。AWS不是每个人的日常，CREATE_FAILED事件加上回滚日志，读起来确实不友好。但真正的瓶颈不是那些@我的消息——依赖单个人的故障排查流程，注定无法扩展。

所以我决定用工程手段解决。我要给团队一个起点，让他们在部署失败时能先拿到信息，而不是直接找我。这不会自动修复问题，但能告诉他们什么坏了、从哪里开始查。

最终产物是一个我称之为cfn-investigator的工具。我在GitHub上放了一个精简版本，叫headless-claude-on-aws。它只聚焦CloudFormation，作为参考起点而非工作环境的完整复制——核心思路相同，但从头重建。足够接近，你可以跟着做、学东西，或者fork后作为基础改造。

架构很精简：一个CodeBuild项目，无头运行Claude Code。输入失败的堆栈名，可选带上怀疑的提交版本。它通过AWS MCP服务器以只读角色读取堆栈状态，推断可能原因，输出简短分析。示例代码把结果记到CloudWatch，留了一行位置可以转发到任何地方。我的版本直接发到Slack告警线程里，就在那个问题下面。

有个设计选择值得单独说：置信度处理。系统提示词要求它保持诚实，包含一个"不确定"选项，对假设进行排序而非编造干净答案。排过序的短名单，胜过自信的误判。

为什么选择这样的实现？它不是什么"最佳实践"。

我选了CodeBuild而不是Lambda或Fargate，给Claude Code直接配Anthropic API key而不是走Bedrock。这些都不是教科书选择。但它们让我最快拿到能工作的原型。CodeBuild匹配这个任务：克隆源码、运行脚本、输出结果到某处。这就是investigator做的事。其余理由，包括为什么跳过Bedrock，README里有写。

说实话，最大的考量是我知道这玩意儿只能我一个人维护。所以我优化两个目标：尽快交付能用的东西，同时保持足够"无聊"以便单人维护。花哨是负债，这是工程权衡，不是疏忽。

不完美但能用的部分，才是我真正在乎的。

这个仓库是一堆YAML和bash。IAM权限比应该的更宽（用了AWS托管的ReadOnlyAccess，实际应该缩小范围）。工具每次运行都重新安装，而不是预置到镜像里。双角色设计只限制了MCP服务器的AWS调用，没限制Claude本身。