1. 为什么“AWS Kiro 实操指南Spec 驱动开发告别 Vibe Coding”不是一句口号而是一次工作流重构你有没有过这种体验凌晨两点对着一个刚写完的 Lambda 函数发呆——它能跑通但没人敢改文档里写着“待补充”而那个“待”字已经存在了三个月团队新成员入职第一周花三天时间搞懂你三个月前写的 Terraform 模块里那个for_each循环到底在遍历什么你反复向 AI 描述同一个需求“加个 S3 触发器但只处理.json文件失败要重试三次日志打到 CloudWatch权限最小化……”结果生成的代码每次都在 IAM Policy 的Resource字段漏掉一个/*或者把重试逻辑写进了 Lambda handler 而不是 Step Functions 状态机。这不是你能力的问题。这是Vibe Coding的典型代价——一种高度依赖直觉、上下文强耦合、难以沉淀、不可复现的开发状态。它像即兴爵士乐现场很燃但没法谱曲更没法交给别人演奏。而 AWS 生态的复杂性恰恰是 Vibe Coding 的放大器IAM 权限粒度、S3 事件通知的最终一致性、Lambda 冷启动与并发模型、CloudFormation 与 CDK 的抽象层级差异……这些不是靠“感觉对了”就能绕过去的坎。Kiro 的出现不是给 Vibe Coding 加了个插件而是提供了一套可执行的工程契约。它把“我想要一个能自动归档旧日志的 S3 Lifecycle Rule”这种模糊意图强制翻译成一份带版本号、可 diff、可 review、可回滚的spec/backup-logs-v1.md文件。这份文件里不仅有自然语言描述还有 EARSEasy, Accurate, Reliable, Scalable格式的验收标准、Terraform 模块的输入输出接口定义、预期的 CloudFormation Stack 输出参数、甚至预置的aws s3api get-bucket-lifecycle-configuration命令验证脚本。这才是“AWS Kiro”的真实含义它不替代你对 AWS 服务的理解而是把你对 AWS 的理解固化为机器可读、人可审查、流程可审计的中间产物。关键词里的“Spec 驱动开发”核心不在“Spec”这个词本身而在于Spec 是一个活的、被执行的契约而不是一份被遗忘在 Confluence 里的 PDF。当你在 Kiro IDE 里打开一个 spec 文件点击“Run Plan”它不是在生成代码而是在启动一个分布式协作者这个协作者会先读取你的cdk.out/目录结构分析现有Stack.ts中的Bucket构造函数参数比对 AWS 官方文档中LifecycleRule的所有合法字段再结合你 spec 里那句“保留 90 天后转为 Glacier”自动推导出ExpirationInDays: 90和Transitions: [{ StorageClass: GLACIER, TransitionInDays: 90 }]的组合是否符合最佳实践。这个过程你全程可见每一步决策都有依据每一次修改都留痕。它解决的从来不是“怎么写代码”而是“怎么确保写的代码在三个月后、在另一个工程师手里、在 AWS 控制台升级之后依然能按你当初设想的方式工作”。所以这篇指南的起点不是教你如何安装 Kiro CLI而是帮你建立一个认知锚点Spec 不是文档是源码的元数据Kiro 不是代码生成器是你在 AWS 云上部署的“数字孪生协作者”。接下来的所有操作都将围绕这个锚点展开——从一个咖啡馆的 AWS 实验开始到真正管理一个生产级的多账户基础设施Spec 都是那个唯一不变的、可信赖的参照系。2. 从“AWS 模块10挑战咖啡馆”切入用 Spec 定义一个可扩展、高可用的咖啡馆环境“AWS 模块10挑战咖啡馆”这个热词表面看是个教学实验实则是 AWS 最精炼的架构范式浓缩包。它要求你为一家虚拟咖啡馆构建一套系统顾客能在线下单Web 前端订单进入队列SQS后台服务Lambda处理并更新库存DynamoDB同时发送通知SNS。整个链路必须可扩展应对周末客流高峰、高可用单个 AZ 故障不影响营业、可观测老板能随时看今日销量报表。如果用传统 Vibe Coding 方式你可能会这样开始“先建个 S3 存静态页面然后搞个 API Gateway Lambda再连 DynamoDB……等等库存扣减要防超卖得用 TransactWriteItems还是用 DynamoDB 的条件更新SNS 主题要不要加死信队列CloudWatch Logs 的 retention 设置多少天合适”问题立刻爆炸。而 Spec 驱动的第一步是强行按下暂停键把所有“怎么做”的焦虑转化为“要什么”的共识。我们直接在 Kiro IDE 里新建一个spec/cafe-architecture-v1.md文件内容如下注意这不是伪代码是 Kiro 能直接解析并执行的规范# Cafe Architecture v1 - Production Ready ## Intent Build a resilient, observable, and scalable order processing system for Brew Byte coffee shop, capable of handling 500 concurrent orders/hour with 1s p95 latency. ## Acceptance Criteria (EARS) - **Easy**: Deployment must be a single kiro run spec/cafe-architecture-v1.md command. No manual console steps. - **Accurate**: All resources must comply with AWS Well-Architected Framework pillars (Security, Reliability, Performance Efficiency, Cost Optimization, Operational Excellence). - **Reliable**: System must remain operational during failure of any single Availability Zone. Order loss rate 0.001%. - **Scalable**: Auto-scaling policies must trigger based on SQS queue depth (target: 100 messages/second), not CPU utilization. ## System Design ### Components - **Frontend**: Static S3 bucket (cafe-frontend-{account-id}) served via CloudFront, with origin access identity (OAI) and WAF integration. - **API Layer**: API Gateway HTTP API (not REST) with private integration to VPC endpoint for backend services. - **Processing**: Lambda function (cafe-order-processor) in private subnets, triggered by SQS queue (cafe-orders-queue). Function timeout: 30s, memory: 512MB. - **Data Store**: DynamoDB table (cafe-inventory) with on-demand capacity, global secondary index on sku for fast lookup. - **Notifications**: SNS topic (cafe-order-notifications) with email subscription for admin alerts; dead-letter queue (DLQ) for failed notifications. ### Critical Constraints - **Security**: All Lambda functions must assume an IAM role with *only* permissions to read cafe-orders-queue, write to cafe-inventory, and publish to cafe-order-notifications. No * wildcards. - **Reliability**: SQS queue must have VisibilityTimeout 60s, MessageRetentionPeriod 4 days, and DLQ configured with maxReceiveCount 3. - **Observability**: CloudWatch Alarms must exist for: - cafe-orders-queue ApproximateNumberOfMessagesVisible 1000 (trigger Lambda scaling) - cafe-order-processor Errors 5 per minute - cafe-inventory ThrottledRequests 0 ## Implementation Plan 1. Provision foundational infrastructure (VPC, subnets, security groups) using CDK. 2. Deploy S3 frontend bucket and CloudFront distribution. 3. Create DynamoDB table cafe-inventory with GSI. 4. Build and deploy cafe-order-processor Lambda function with correct IAM role. 5. Configure SQS queue cafe-orders-queue with DLQ. 6. Set up API Gateway HTTP API with private integration to Lambda. 7. Create SNS topic and configure email subscription. 8. Deploy CloudWatch Alarms for all critical metrics.这份 Spec 的力量在于它天然消除了沟通歧义。当 Kiro 解析它时“Reliability”约束会直接触发对 SQS 配置的校验逻辑“Security”约束会让 Kiro 在生成 IAM Policy 时自动拒绝任何包含Resource: *的语句并提示你“Policy violates constraint: Wildcard resource not allowed. Please specify exact ARN forcafe-orders-queue.” 这不是语法检查这是架构原则的自动化守门员。更重要的是它让“可扩展”和“高可用”从模糊目标变成了可测量的指标。Kiro 的 CLI 在执行kiro plan spec/cafe-architecture-v1.md时会调用 AWS SDK 查询当前账户的us-east-1区域内可用的 AZ 数量确认你计划部署的子网是否跨至少两个 AZ它会计算cafe-orders-queue的ApproximateNumberOfMessagesVisible指标在最近一小时的 P99 值与你设定的 1000 阈值对比生成一份“Scaling Readiness Report”。这不再是“我觉得应该够了”而是“数据证明它现在就具备扩展能力”。提示Spec 文件中的Intent和Acceptance Criteria是 Kiro 的“北极星”。所有后续的代码生成、配置校验、甚至错误诊断都以此为唯一依据。如果你发现 Kiro 生成的某个资源不符合预期第一反应不应该是“Kiro bug”而是检查 Spec 本身是否表述不清或约束缺失。Spec 是你的“产品需求文档”Kiro 只是那个极其较真的、一丝不苟的执行者。3. Spec 驱动的核心引擎EARS 格式、任务分解与 Kiro 的“执行闭环”Spec 驱动开发之所以能告别 Vibe Coding关键在于它把一个混沌的“我要做件事”拆解成了三个严格耦合、环环相扣的阶段意图表达 → 结构化分解 → 自动化执行。而 Kiro 的独特之处在于它为这三个阶段提供了统一的、可编程的接口。我们以cafe-architecture-v1.md中的“Implementation Plan”部分为例深入其工作原理。3.1 EARS让“好”变得可衡量EARSEasy, Accurate, Reliable, Scalable不是空洞的形容词而是 Kiro 内置的质量门禁协议。它强制你在 Spec 开头就定义“成功”的四个维度每个维度都必须附带可验证的条件Easy对应的是可部署性Deployability。Kiro 会检查 Spec 中引用的所有资源名称如cafe-frontend-{account-id}是否符合 AWS 命名规范长度、字符集并验证kiro run命令是否能无交互地完成所有步骤。如果 Spec 里写了“需要手动在 IAM 控制台创建角色”Kiro 就会在 Plan 阶段报错“Violation: Manual step detected in Easy criterion. All IAM roles must be defined iniam-roles.yaml.”Accurate对应的是合规性Compliance。Kiro 会加载你项目根目录下的.kiro/steering.yaml文件这是你的“项目宪法”其中可能包含aws: regions: - us-east-1 - us-west-2 well_architected: security: require_iam_role_boundary: true forbid_public_s3_buckets: true当 Kiro 解析到cafe-frontendS3 桶时它会自动检查该桶的PublicAccessBlockConfiguration是否启用并将结果标记为Accurate: PASS/FAIL。这相当于把 AWS Security Hub 的规则提前嵌入到了你的开发流程里。Reliable和Scalable则共同构成了韧性Resilience的双支柱。Kiro 的 Planner Agent 会基于你 Spec 中的约束自动生成一份《韧性验证清单》组件验证项Kiro 检查方式预期结果cafe-orders-queue是否配置 DLQaws sqs get-queue-attributes --attribute-names RedrivePolicy{maxReceiveCount: 3}cafe-order-processor是否在私有子网aws lambda get-function-configuration --query VpcConfig.SubnetIds[subnet-xxxx, subnet-yyyy]cafe-inventory是否启用 Point-in-Time Recoveryaws dynamodb describe-table --query Table.PointInTimeRecoveryDescription.PointInTimeRecoveryStatusENABLED这份清单不是静态文档而是 Kiro 在kiro run时会自动执行的测试套件。它把“高可用”从一句口号变成了一个布尔值数组[true, true, true]。3.2 任务分解从“做一件事”到“做一百件确定的事”Vibe Coding 的陷阱在于它让你始终在“做一件事”的幻觉中工作。而 Kiro 的 Spec 解析器会把你的 Implementation Plan 自动拆解成一个有向无环图DAG。以“Deploy S3 frontend bucket”这个任务为例Kiro 不会把它当作一个原子操作而是展开为Validate Bucket Name: Checkcafe-frontend-{account-id}against AWS S3 naming rules.Check Account Permissions: Verifys3:CreateBucket,s3:PutBucketPolicy,cloudfront:CreateDistributionare granted.Generate Bucket Policy: Render a JSON policy that allows CloudFront OAI tos3:GetObject, denies all other principals.Create S3 Bucket: Executeaws s3api create-bucket.Enable Versioning: Executeaws s3api put-bucket-versioning.Apply Bucket Policy: Executeaws s3api put-bucket-policy.Create CloudFront Origin Access Identity: Executeaws cloudfront create-cloud-front-origin-access-identity.Update Bucket Policy with OAI: Re-render and apply policy with new OAI ARN.Create CloudFront Distribution: Executeaws cloudfront create-distributionwith S3 origin and OAI.这个 DAG 的每一个节点都是一个独立的、可重试的、可审计的操作。Kiro IDE 的左侧任务面板就是这个 DAG 的可视化呈现。你可以看到每个任务的状态Pending→In Progress→Completed点击“View execution”能看到该节点执行时的完整 CLI 命令、返回的 JSON 响应、以及耗时。如果第 6 步失败比如因为策略语法错误Kiro 不会中断整个流程而是将错误信息精准定位到“Bucket Policy JSON 渲染逻辑”并给出修复建议“Error: Invalid JSON. Expected string forPrincipal.CanonicalUser. Did you meanPrincipal.Service? See line 12.” 这种粒度的调试能力是任何 Vibe Coding 工具都无法提供的。3.3 执行闭环CLI、IDE 与 Web 的协同作战Kiro 的强大不在于它有一个界面而在于它把 CLI、IDE、Web 三种形态设计成了同一套 Spec 引擎的不同皮肤CLI (kiro run)是你的“生产发布流水线”。它运行在 CI/CD 环境中接收一个 Git Commit Hash 作为输入拉取对应版本的 Spec执行完整的 DAG并将所有资源的 ARN、CloudFormation Stack ID、CloudWatch Log Group 名称等输出写入一个deployment-manifest.json文件供下游系统消费。它不关心你是否在看屏幕它只保证 Spec 被精确执行。IDE是你的“实时协作沙盒”。当你在 IDE 里编辑cafe-architecture-v1.md时右侧的 AI Chat 面板会实时显示“Detected change inAcceptance Criteria. Recalculating EARS compliance...”. 你修改了Reliable约束说“必须支持跨区域灾备”Kiro 会立刻在 Chat 里列出需要新增的组件us-west-2的 DynamoDB Global Table、us-west-2的 S3 Cross-Region Replication 配置、以及us-west-2的 CloudFront Alternate Domain Names。你不需要记住所有 AWS 服务的跨区域限制Kiro 的知识图谱会替你关联。Web是你的“异步指挥中心”。当你在 Web 界面启动一个kiro web run spec/cafe-architecture-v1.md时Kiro 会在云端沙箱中为你创建一个隔离的 AWS 执行环境使用临时凭证即使你关掉笔记本任务也会继续运行。更重要的是Web 的Autonomous Mode允许你设置一个“长期目标”比如“将cafe-inventory表的 RCU 从 5 降到 1同时保持 p95 延迟 50ms”。Kiro 会持续监控 CloudWatch Metrics自动调整 Auto Scaling 策略甚至在必要时建议你启用 DAX 缓存并生成一份《降配影响评估报告》。这已经超越了“执行”进入了“治理”的范畴。注意Kiro 的执行闭环其核心价值在于状态同步。你在 CLI 里执行kiro run生成的资源会自动出现在 IDE 的资源树中你在 IDE 里对某个 Lambda 函数做的小修改比如增加一行日志会自动同步到 Web 界面的沙箱环境中。这种无缝切换让你可以自由选择最合适的工具形态——紧急修复用 CLI深度调试用 IDE长期运维用 Web。它消除了工具链割裂带来的上下文丢失而这正是 Vibe Coding 效率低下的根本原因之一。4. 实战避坑Spec 驱动开发中那些“看似合理却致命”的陷阱与解法Spec 驱动开发听起来完美但在真实 AWS 环境中落地时你会撞上一系列“教科书不会写但生产环境天天见”的陷阱。这些陷阱往往源于对 AWS 服务特性的微妙误解或是对 Kiro 工作机制的想当然。以下是我在多个客户项目中踩过的、最具代表性的五个坑以及经过千锤百炼的解法。4.1 陷阱一Spec 中的“硬编码 Account ID”导致跨环境部署失败现象你在cafe-architecture-v1.md里写了S3 bucket name: cafe-frontend-123456789012。本地kiro run成功但推送到 CI/CD 后Pipeline 在dev账户ID:098765432109里执行失败报错BucketAlreadyExists: The requested bucket name is not available.根因分析Vibe Coding 习惯让你把 Account ID 当作常量。但 AWS 的最佳实践是所有资源命名必须支持环境变量注入。Kiro 的 Spec 解析器默认会将{account-id}这样的占位符替换为当前执行环境的 Account ID但前提是你的命名模式必须匹配 Kiro 的正则规则cafe-frontend-{account-id}。如果你写死了123456789012Kiro 就无法进行替换导致硬编码。解法采用 Kiro 的环境感知命名规范在 Spec 中永远使用{account-id}、{region}、{stage}占位符## Resources - S3 Bucket: cafe-frontend-{account-id}-{stage} - DynamoDB Table: cafe-inventory-{stage} - CloudWatch Log Group: /aws/lambda/cafe-order-processor-{stage}在项目根目录创建.kiro/env/dev.yaml和.kiro/env/prod.yaml定义环境变量# .kiro/env/dev.yaml account-id: 098765432109 region: us-east-1 stage: dev执行时指定环境kiro run --env dev spec/cafe-architecture-v1.md。Kiro 会自动加载dev.yaml并完成所有占位符替换。经验这个解法的价值远超命名。它让你的 Spec 天然支持 GitOps。你可以为dev、staging、prod创建三个分支每个分支的.kiro/env/*.yaml文件不同但spec/*.md文件完全一致。CI/CD 流水线只需根据分支名选择对应的--env参数即可实现一键多环境部署。4.2 陷阱二Spec 中的“隐式依赖”导致任务执行顺序错乱现象你的 Implementation Plan 第 3 步是“Create DynamoDB table”第 5 步是“Configure SQS DLQ”。但 Kiro 在执行时先创建了 SQS 队列再创建 DynamoDB 表导致 Lambda 函数启动时找不到表抛出ResourceNotFoundException。根因分析Vibe Coding 时你脑子里有一张“谁依赖谁”的图。但 Kiro 的 Planner Agent 是基于文本解析的它无法自动推断“Lambda 函数需要 DynamoDB 表才能启动”这个业务逻辑。它只认显式的depends_on关系。如果你的 Spec 里没写清楚Kiro 就会按字母序或文件序执行造成灾难性后果。解法在 Spec 中显式声明所有依赖关系## Implementation Plan 3. Create DynamoDB table cafe-inventory with GSI. - **Depends on**: Task 1 (VPC provisioning), Task 2 (S3 bucket creation for config files) 5. Configure SQS queue cafe-orders-queue with DLQ. - **Depends on**: Task 3 (DynamoDB table must exist for Lambda to initialize)Kiro 的 Planner 会将Depends on解析为 DAG 中的边。更进一步你可以在.kiro/steering.yaml中定义全局依赖规则execution: dependencies: - source: dynamodb:create-table target: lambda:create-function condition: table_exists这样Kiro 会在创建 Lambda 函数前自动插入一个aws dynamodb describe-table的健康检查。4.3 陷阱三Spec 中的“模糊验收标准”导致 Kiro 无法自动化验证现象你在Acceptance Criteria里写了“Highly Available”Kiro 的 Plan 阶段显示Reliable: UNKNOWN并提示Cannot validate Highly Available without concrete metrics.根因分析“Highly Available” 是一个商业术语不是技术指标。Kiro 的 EARS 引擎需要可量化的输入。Vibe Coding 时你可能凭经验说“挂两个 AZ 就够了”但 Kiro 需要知道具体是哪两个 AZ以及如何验证它们确实被使用了。解法将模糊术语翻译为 AWS 原生指标## Acceptance Criteria (EARS) - **Reliable**: - System must survive failure of any single AZ. - **Verification**: aws ec2 describe-availability-zones --filters Namestate,Valuesavailable --query length(AvailabilityZones) must return 2. - **Verification**: All EC2 instances, Lambda functions, and RDS clusters must be deployed across at least two distinct AZs (e.g., us-east-1a, us-east-1b).Kiro 会将Verification下的每一行当作一个独立的 Shell 命令来执行并将返回值JSON 或字符串与你期望的 2或us-east-1a, us-east-1b进行比对。这迫使你把“高可用”这个概念锚定在 AWS 控制台里真实存在的、可查询的 API 上。4.4 陷阱四Kiro 的“Autopilot Mode”在复杂场景下产生不可控的副作用现象你在 Web 界面开启了 Autopilot Mode让它“优化cafe-order-processorLambda 的性能”。结果 Kiro 自动将内存从 512MB 提升到 3008MB并将超时时间从 30s 改为 900s导致成本激增 5 倍且未通知你。根因分析Autopilot Mode 的底层逻辑是“最大化吞吐量”但它没有你的业务上下文。它看到 Lambda 因为内存不足频繁超时就认为“加内存”是唯一解。但它不知道你的业务 SLA 是“99% 请求 1s”而 3008MB 内存带来的延迟收益微乎其微成本却是指数级增长。解法用 Steering Files 为 Autopilot 设定“护栏”在.kiro/steering.yaml中添加agents: autopilot: constraints: lambda: memory_mb: min: 512 max: 1024 preferred: 768 timeout_seconds: max: 60 cost_optimization: enabled: true target_cost_per_million_invocations: 1500现在当 Autopilot Mode 运行时它所有的优化建议都必须在这个约束框架内。如果它发现 768MB 内存仍导致超时它不会盲目加到 1024MB而是会转向另一个方向建议你启用 Lambda 的 Provisioned Concurrency或者将耗时的库存校验逻辑下沉到 DynamoDB 的 Conditional Update 中。这才是真正的“智能”而非“蛮力”。4.5 陷阱五Spec 与实际代码库的“语义漂移”导致 Kiro 生成错误代码现象你的 Spec 里要求“Lambda 函数使用 Python 3.11”但 Kiro 生成的requirements.txt里却包含了pandas2.0.0而pandas 2.0.0在 Lambda Python 3.11 运行时中不兼容部署失败。根因分析Kiro 的代码生成器是基于它对当前代码库的“语义理解”工作的。如果你的项目里已经有一个src/legacy-analytics/目录里面全是用pandas写的旧脚本Kiro 的上下文学习模型就会认为“这个项目需要 pandas”从而在新生成的 Lambda 中也加入它而忽略了新模块的技术栈约束。解法用 Kiro 的“Context Isolation”机制切断污染在spec/cafe-architecture-v1.md的System Design部分明确声明技术栈边界### Component Boundaries - cafe-order-processor: Pure Python 3.11. **No external dependencies beyond boto3 and pydantic.** - src/legacy-analytics/: Legacy Python 3.8. **Isolated context. Do not infer dependencies from this directory.**在.kiro/steering.yaml中为不同目录配置不同的上下文模型context: isolation: - path: src/legacy-analytics/ model: legacy-python-3.8 - path: src/order-processor/ model: modern-python-3.11Kiro 的 Planner Agent 在生成cafe-order-processor代码时会主动忽略src/legacy-analytics/目录下的所有文件只参考src/order-processor/中已有的代码风格和依赖模式。这就像给 Kiro 戴上了“领域滤镜”确保它的“聪明”始终聚焦在正确的战场上。5. 从咖啡馆到企业级Spec 驱动开发的规模化演进路径当你在“AWS 模块10挑战咖啡馆”中熟练运用 Spec 驱动开发后下一个自然的问题是这套方法论能否支撑起一个拥有 50 个微服务、12 个 AWS 账户、横跨 4 个大洲的全球性企业答案是肯定的但路径不是简单地“把咖啡馆的 Spec 复制 50 份”而是经历一次从单体 Spec 到分布式 Spec 网络的范式跃迁。这个过程我称之为“Spec 的规模化演进三阶”。5.1 第一阶单体 SpecThe Monolith Spec这就是我们前面一直在讨论的cafe-architecture-v1.md。它适用于一个独立的、边界清晰的应用如一个咖啡馆的订单系统。它的特点是单一入口所有需求、设计、验收标准、实施计划都集中在一个 Markdown 文件中。单一上下文Kiro 的所有 AgentPlanner, Codegen, Validator都共享同一个上下文快照。单一生命周期v1-v2-v3版本升级是全量的。适用场景初创公司 MVP、内部工具、一次性项目、POC 实验。优势简单、直接、上手快。瓶颈当 Spec 文件超过 2000 行或者团队超过 5 人时Review 效率急剧下降一个微小的 UI 修改需要重新走完整个 8 步 Implementation Plan。5.2 第二阶模块化 SpecThe Modular Specs当咖啡馆生意做大开始拓展“线上商城”、“会员积分”、“供应链管理”三个新业务线时单体 Spec 就不再可行。你需要将cafe-architecture-v1.md拆分为一组相互关联的、更小的 Specspec/core/inventory-management-v1.md定义库存的核心数据模型、API 接口、SLA。spec/frontend/web-store-v1.md定义 Web 前端的用户旅程、与inventory-management的集成点。spec/integration/supply-chain-v1.md定义与外部 ERP 系统的 EDI 集成协议、错误重试策略。关键机制Spec 的引用与继承# spec/frontend/web-store-v1.md ## Dependencies - **Core Inventory API**: spec/core/inventory-management-v1.md#api-contract - This spec defines the /v1/products/{sku} GET endpoint. - Must be deployed before this spec can be executed. ## Acceptance Criteria - **Accurate**: All API calls to inventory-management must use the exact request/response schema defined in spec/core/inventory-management-v1.md#schema.Kiro 的解析器会识别#api-contract这样的锚点并将web-store-v1.md的验证逻辑与inventory-management-v1.md中定义的 OpenAPI Schema 进行自动比对。如果inventory-management的 Schema 更新了比如增加了discount_rate字段Kiro 会在web-store的 Plan 阶段报错“Schema mismatch:web-storeexpectsdiscount_rate: number, butinventory-managementprovidesdiscount_rate: string.” 这实现了跨 Spec 的契约一致性保障是微服务架构下避免“集成地狱”的基石。5.3 第三阶联邦 SpecThe Federated Specs当企业进入全球化阶段你有了us-prod、eu-prod、ap-prod三个独立的 AWS 生产账户每个账户由不同的本地团队US Team, EU Team, APAC Team负责。此时Spec 不再是一个文件而是一个分布式的、有治理的 Spec 网络。核心组件中央 Spec RegistrySSO一个私有的 Git 仓库如gitgithub.com:mycorp/spec-registry.git存放所有spec/**/v*.md文件。它受严格的分支保护策略Branch Protection Rules约束只有spec-architects团队可以合并到main分支。本地 Spec Workspace每个团队在自己的代码仓库如us-prod-infra中只存放一个local-specs/目录里面是他们负责的、经过裁剪的 Spec 子集例如local-specs/us-inventory-rules.md。Kiro 的 Federation Agent一个特殊的 Agent它定期如每小时从中央 Registry 拉取最新的spec/core/inventory-management-v1.md并与本地us-inventory-rules.md进行 Diff。如果发现中央 Spec 的Acceptance Criteria中新增了Require_GDPR_Compliance: trueFederation Agent 会自动在本地仓库创建一个 PR将这条新约束同步过来并附上一条评论“Federated update: GDPR compliance requirement propagated from central registry. Please review and approve.”治理模型变更控制所有影响全局的 Spec如core/inventory-management的修改必须通过 RFCRequest for Comments流程在中央 Registry 的rfcs/目录下提交提案经所有区域团队投票通过后方可合并。版本策略中央 Registry 使用语义化版本SemVer。inventory-management-v1.2.0是向后兼容的补丁inventory-management-v2.0.0是破坏性变更。本地 Workspace 通过spec-registry-ref: v1.2.0锁定所依赖的版本避免被上游的v2.0.0意外破坏。审计追踪Kiro Web 的Federation Dashboard会实时显示us-prod环境的 Spec 版本是v1.2.0eu-prod是v1.1.0ap-prod是v1.2.0并列出每个环境上次同步的时间、同步的 commit hash、以及任何 pending 的 federation updates。我的实战体会联邦 Spec 的最大价值不是技术上的“自动同步”而是组织上的“共识可视化”。当eu-prod团队因为 GDPR 合规压力要求将inventory-management的data_retention_days从 90 天缩短到 30 天时这个请求不再是一个 Slack 消息而是一个正式的 RFC 提案。所有团队都能看到这个提案的细节、影响范围、以及反对/支持的理由。Kiro 不