亚马逊为何向员工开放 Claude Code 和 OpenAI Codex

这意味着重点从“是否允许用第三方 AI 编程助手”，转向“如何把第三方工具纳入公司可控的访问路径”。在此之前，Claude Code 用于生产代码或线上产品场景的门槛更高，工程师需要特殊许可或正式审批，这也是内部不满的来源之一 ^[3][14]。

背景：Kiro 优先路线曾遇到开发者反弹

亚马逊此前曾推动工程师优先使用自家的 Kiro。Reuters 报道的一份内部备忘录称，亚马逊建议工程师避免采用第三方 AI 代码生成工具、转向 Kiro，并表示“目前不计划支持更多第三方 AI 开发工具” ^[12]。

这种策略很快遇到阻力。报道显示，约 1,500 名亚马逊工程师在内部论坛支持采用 Claude Code，并反对他们认为会影响生产力的工具限制 ^[5][6]。Business Insider 也报道称，亚马逊内部曾通过指导把团队引向 Kiro，同时要求 Claude Code 在生产代码或线上产品中使用时经过正式批准 ^[14]。

因此，这次转向背后的直接压力并不是抽象的“AI 战略调整”，而是一线工程师对工具体验和开发效率的集中反馈。

为什么亚马逊不再只依赖 Kiro

1. 工程师偏好变成了组织效率问题

当约 1,500 名工程师公开支持 Claude Code，并把现有政策与生产力受损联系起来时，工具选择就不再只是采购或平台标准化问题 ^[5][6]。对亚马逊这样的工程组织来说，AI 编程助手如果不能被开发者真正接受，就可能带来审批绕路、采用阻力和交付效率损失。

开放 Claude Code 和 Codex，等于承认开发者实际使用效果必须进入决策。自研工具仍有治理和集成优势，但如果部分团队认为外部工具在复杂开发工作中更顺手，继续只推单一路线就会变得难以执行 ^[3][6][8]。

2. Kiro 没被判失败，但“唯一优先”很难服众

现有公开报道没有提供 Kiro、Claude Code 和 Codex 的统一基准测试，所以不能据此断言 Kiro 在能力上一定落后。更稳妥的结论是：Kiro 优先策略没有说服所有工程团队，部分开发者更希望 Claude Code 进入正式可用工具清单 ^[5][6][14]。

这对 Kiro 的意义很明确：它没有出局，但不能只靠内部政策获得采用。未来它需要在真实开发流程中证明自己的效率、稳定性和与亚马逊内部系统的集成价值。

3. 受控开放比全面限制更可执行

从报道看，亚马逊选择的是“纳管”而不是“放任”。Claude Code 和 Codex 将运行在亚马逊环境中，并由 AWS 管理；部分报道还提到 Amazon Bedrock 作为承载路径 ^[1][2][3]。

这给亚马逊提供了一条折中路线：工程师获得更多工具选择，公司仍能在基础设施、访问路径和部署层面保留集中控制。不过，公开报道没有披露完整的数据隔离、日志、权限、代码审查或模型使用政策，因此不能据此推断亚马逊已经解决了所有安全治理问题 ^[2][8]。

4. AI 合作生态也降低了外部工具的阻力

Business Insider 将这次开放放在亚马逊与 Anthropic、OpenAI 的合作关系中理解，并称亚马逊是两家 AI 公司的密切合作伙伴 ^[8]。因此，内部采用 Claude Code 和 Codex 不只是“使用外部竞争产品”，也符合大型云平台把多家 AI 工具纳入生态的趋势。

Kiro 的位置：从优先选项变成竞争选项

目前更准确的说法是：Kiro 从被优先推动的内部工具，变成了亚马逊 AI 编程工具组合中的一个选项。相关报道描述的是亚马逊扩展到 Claude Code、Codex 和自家工具并存，而不是宣布关闭 Kiro ^[1][3][8]。

这会让 Kiro 面临更直接的内部竞争。过去，Kiro 可以依赖公司政策获得优先位置；现在，它必须与 Claude Code、Codex 一起接受工程师在实际工作流中的选择。

对企业 AI 编程工具选择的信号

亚马逊的案例说明，大型企业很难长期只用一种 AI 编程助手解决所有开发场景。自研工具便于治理、集成和合规管理，但开发者会按照实际效率选择工具；当第三方工具明显受到欢迎时，把它们纳入统一管理，往往比继续依赖限制和个别审批更现实 ^[2][6][8]。

这次调整的核心逻辑可以概括为一句话：Kiro 仍然存在，但亚马逊不愿为了坚持单一自研路线，而牺牲工程师已经明确表达的生产力需求。