CLOUD SECURITY LAB

Kiro vs Claude Code, 谁是更好的Terraform合作伙伴？

—

by

cslab
in

“与AI一起使用Terraform”这句话现在已经很常见了。

然而，与哪种AI一起使用会决定结果。

AWS培养的新秀Kiro，以及，

全球开发者选择的通用强者Claude Code。

谁更适合作为Terraform的合作伙伴呢？

>

本文涵盖的内容

  • Kiro与Claude Code的根本哲学差异（Spec-driven vs Prompt-native）
  • 各自的Terraform集成方式（Kiro Powers vs MCP Server）
  • AWS原生集成与多云/厂商中立的权衡
  • 实战场景选择指南
  • 基于AI编写IaC时常见的陷阱

为何现在进行此比较很重要

就在1-2年前，编写Terraform还是一项艰巨的任务：打开Registry文档，翻阅官方模块的README，并验证旧博客文章中的版本兼容性。然而，到了2025年下半年，情况已完全不同。

AWS正式发布了名为Kiro的AI驱动IDE，并在re:Invent 2025上与HashiCorp携手推出了Terraform Power。与此同时，Anthropic的Claude Code与HashiCorp官方的Terraform MCP Server相结合，从简单的代码自动补全发展成为一个能够与Registry API实时对话的代理。

这意味着，“用AI编写Terraform”的选择已经分化为两种路径的时代已经到来。如果无法判断哪种更适合您的团队，初期生产力可能会提高，但长期维护成本可能会增加。

Kiro — AWS亲自设计的“规范驱动”IDE

Kiro的定位

Kiro是AWS在2025年夏天推出的一款代理式AI IDE（+CLI）。其最大特点是规范驱动开发（Spec-driven Development），即在编写代码之前，它会先自动生成需求（Requirements）→设计（Design）→任务（Tasks）三个阶段的规范，并在用户审查后执行。需求采用官方的EARS表示法编写。

简而言之，它在保留Vibe coding（凭感觉编码）优点的同时，通过规范这一“围栏”来防止AI在复杂项目中随意“狂奔”。

Kiro的Terraform集成方式 — “Powers”

Kiro拥有一种独特的扩展机制，称为Powers。Power将MCP服务器、转向文件（指导方针）和钩子（自动化任务）捆绑成一个包。当安装由HashiCorp直接作为启动合作伙伴参与的Terraform Power时，它只会在对话中出现“Terraform”、“infrastructure”等词语时自动激活。

这种结构的优点显而易见：

  • 节省令牌/上下文：仅在需要时加载专业知识。
  • 深度集成AWS生态系统：与AWS Cost Optimization Hub、Cost Explorer、IAM、Bedrock和MCP服务器进行原生联动。
  • 一致的治理：在Steering文件中永久存储“Lambda使用ARM64 Graviton，S3默认使用智能分层”等组织规则。

Kiro大放异彩的时刻

在AWS环境中进行遗留系统现代化项目时，Kiro会分析现有代码库，并根据组织偏好生成IaC（CloudFormation/CDK/Terraform）。由于其内部协调EKS/ECS MCP、Cost MCP、Diagram MCP等，对于“仅使用AWS的团队”来说，它就像一把瑞士军刀。

Claude Code — 厂商中立、灵活的通用强者

Claude Code的定位

Claude Code是基于Anthropic Claude模型构建的代理式编码工具。它以终端CLI为核心，支持VS Code/JetBrains插件、GitHub Actions和Slack集成。如果说Kiro强调“规范先行”，那么Claude Code则更接近于

“通过自然语言对话进行灵活探索”

。

最近，新增了名为Skills的功能，允许Claude自动加载并遵循特定领域（如Terraform、HCP Terraform等）的最佳实践。这在功能上与Kiro的Powers相似，但设计更为开放。

Claude Code的Terraform集成方式 — “MCP Server + Skills”

将HashiCorp官方维护的Terraform MCP Server连接到Claude Code后，Claude将直接与Terraform Registry API对话。设置很简单：

# 在Claude Code中注册Terraform MCP Server
claude mcp add terraform -s user -t stdio 
  -- docker run -i --rm hashicorp/terraform-mcp-server

如果您使用HCP Terraform（原Terraform Cloud），可以一并传递令牌：

claude mcp add terraform -s user -t stdio 
  -e TFE_TOKEN=your-token-here 
  -- docker run -i --rm hashicorp/terraform-mcp-server

只需这样设置，在接下来的对话中，Claude将实时查询Provider的最新版本和Schema来编写代码。这大大减少了因学习数据截止而消失的资源参数或滥用已弃用语法的问题。

简单提示示例

Using the latest AWS provider, generate a Terraform module named `vpc_subnet`
that creates a VPC with a configurable CIDR, a variable number of public and
private subnets, NAT gateways per AZ, route tables, and outputs the VPC ID
and subnet IDs. Use official HashiCorp modules where possible.

Claude通过MCP从Registry查询官方的terraform-aws-modules/vpc/aws模块的最新用法，并以此为基础生成脚手架。此外，它还可以轻松与其他MCP（如用于安全检查（Checkov, tfsec）或GitHub Actions的MCP）结合，使其在多工具编排方面表现出色。

Claude Code大放异彩的时刻

  • 多云（AWS + Azure + GCP）或混合云环境
  • 希望保持现有VS Code/JetBrains/终端中心工作流的团队
  • 希望将Claude Code集成到GitHub Actions中，运行“每周Provider更新自动检测”等代理式工作流的团队

⚖️ 正面比较表
项目 Kiro Claude Code
开发主体 AWS Anthropic
核心理念 规范驱动 (EARS表示法) 提示原生 + 技能
基本界面 独立IDE + CLI 终端CLI + VS Code/JetBrains插件
Terraform集成 Terraform Power (HashiCorp官方捆绑包) Terraform MCP Server + Terraform Skill
云亲和性 AWS原生 (内置EKS/ECS/Cost MCP等) 厂商中立 (AWS/Azure/GCP均等支持)
治理存储方式 Steering文件 (永久规则) AGENTS.md, Skill文件
自动化钩子 Hooks (fmt/lint/scan自动执行) 基于GitHub Actions的代理式工作流
学习曲线 需要熟悉规范阶段 更接近普通聊天，易于上手
离线/气隙环境 有限制 有限制 (MCP可通过Docker本地运行)

—

相同任务，不同方法 — “ECS Fargate + ECR”部署场景

Kiro中的流程

  1. 在聊天窗口中用自然语言请求 → Requirements.md自动生成EARS表示法
  2. 审查并批准后，生成Design.md（反映HashiCorp官方模块使用等）
  3. 将分解到Tasks.md中的任务逐个或批量执行
  4. Hook自动运行terraform fmt、tfsec、checkov
"terraform-infra 디렉터리에 멀티 아키텍처 Docker 이미지를 빌드해 
ECR에 푸시하고, ECS Fargate로 프론트/백엔드 2티어를 배포하는 스펙을 만들어줘.
kreuzwerker/docker와 aws provider를 사용하고, 백엔드는 Task Role로
Secrets Manager에서 OpenAI API 키를 읽게 해줘."

Claude Code中的流程

  1. 在.mcp.json中注册Terraform MCP + AWS Diagram MCP
  2. 自然语言提示 → Claude查询Registry并立即编写HCL
  3. 如有需要，将terraform plan执行结果反馈给Claude → 反复修改
  4. 将Claude Code集成到GitHub Actions工作流中，实现基于PR的自动化审查

两种方法都能产生出色的结果。区别在于您是希望“为组织留下结构化的交付物（规范/需求/任务）”，还是希望“通过快速对话和迭代走最短路径”。

⚠️ 注意事项 / 常见错误

1. 不要直接应用AI生成的IaC

特别是在试用Kiro的Vibe模式的案例中，有报告称“部署一个Hello World容器”的请求最终变成了每月150-200美元的生产级EKS集群。AI的“友好默认值”可能对您的账单造成致命影响。

2. MCP服务器原则上应为本地专用

HashiCorp Terraform MCP Server在其官方文档中警告

“切勿与不受信任的MCP客户端或LLM一起使用”

。如果将Terraform状态或TFE令牌暴露给不受信任的远程MCP端点，您的基础设施密钥将立即被窃取。

3. 不要在Steering/Skill文件中放置凭据

虽然AI可以永久记住规则是一个优点，但同时，如果不小心将密码或API密钥放入其中，它们将永远伴随上下文。请仅记录Secrets Manager/SSM Parameter Store的引用。

4. AI依赖与工程能力的平衡

“我不知道Claude生成的VPC为什么能正常工作”这种状态是灾难的种子。AI是倍增器（force-multiplier），而不是架构理解的替代品。特别是对于初级工程师来说，仔细审查规范/生成代码并将其纳入学习循环是必不可少的。

✅ 总结 / 结束语

首先，结论是，没有哪一个绝对优越。选择标准很简单：

  • 如果整个组织都基于AWS，并且希望留下基于规范的交付物 → Kiro
  • 如果是多云/混合云环境，或者希望保持现有的VS Code·GitHub Actions工作流 → Claude Code
  • 如果希望在组织层面强制执行安全和治理规则 → Kiro的Steering + Hook组合更有利
  • 如果希望将代理式自动化（如每周Provider更新检测）集成到CI中 → Claude Code + GitHub Actions

我个人将这两种工具视为互补而非排他性的选择。我将设计和规范初稿交给Kiro，而实际的模块重构、多云桥接和CI自动化则交给Claude Code。

最终，AI改变的不是Terraform本身，而是“工程师将时间花在哪里”。我们可以将记忆语法和检查版本的工作交给AI，而将精力集中在架构决策和成本·安全审查上。这就是2026年IaC工程师新的工作方式。

Comments

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注