AI 技能AI 插件【免费下载链接】agentic-awesome-skillsAAS Core is the local, agent-first control plane for complete catalog discovery, agent-owned selection, stack validation, and planning, backed by 2,445 agentic skills. Includes CLI, local MCP, catalog, plugins, and Workbench.项目地址https://gitcode.com/gh_mirrors/an/agentic-awesome-skills点击查看免费下载导读本文以开源仓库 agentic-awesome-skills 中收录的 cdk-patterns 技能 为主体系统讲解如何用 AWS CDKCloud Development Kit设计可复用的基础设施即代码IaC架构从 L2/L3 构造Construct的选择、Serverless API Lambda DynamoDB 经典组合到生产级 Stack 的拆分、IAM 最小权限、标签与删除策略等最佳实践。读完本文你将掌握一套可直接用于 TypeScript、Python 或 Java 项目的 CDK 开发方法论并能识别常见反模式与循环依赖陷阱。一、技能定位cdk-patterns 在仓库目录体系中的角色在 agentic-awesome-skills 仓库中cdk-patterns 是一项以 Agent 技能Skill形式封装的领域知识存放于 plugins/agentic-awesome-skills-claude/skills/cdk-patterns/ 目录下主体文件为SKILL.md。其 Front Matter 元数据同时被仓库的目录体系索引例如在 data/catalog.json 中对应条目为{ id: cdk-patterns, canonical_id: cdk-patterns, name: cdk-patterns, description: Common AWS CDK patterns and constructs for building cloud infrastructure with TypeScript, Python, or Java. Use when designing reusable CDK stacks and L3 constructs., category: cloud, risk: critical, source: community, tags: [cdk], triggers: [cdk, common, aws, constructs, building, cloud, infrastructure, typescript, python, java, designing, reusable], path: skills/cdk-patterns/SKILL.md }从目录元数据可以看出几个关键事实分类与风险等级技能归类为cloud类别风险等级为critical涉及生产基础设施变更时需严格审查来源community属于社区贡献的技能触发器triggers字段列出了cdk、aws、constructs、infrastructure等关键词供 Agent 在任务匹配时自动唤起该技能多语言覆盖技能的 description 明确声明适用于 TypeScript、Python、Java 三种语言栈。技能主体SKILL.md采用标准的结构化格式Front Mattername/description/risk/source/date_added 专家定位声明 适用/不适用场景 执行指令 示例代码 最佳实践 故障排查 限制说明。这一结构也与仓库 docs/SKILL_ANATOMY.md 中定义的技能解剖规范保持一致读者可以对照该文档理解技能文件的通用骨架。二、何时使用 / 何时避免技能的场景边界技能正文首先划定了清晰的适用边界这是保证 Agent 不被误用、也不被滥用的第一道约束。适用场景Use this skill when构建可复用的 CDK 构造Construct或架构模式Pattern设计多 Stack 的 CDK 应用实现常见基础设施模式API Lambda DynamoDB、ECS 容器服务、静态站点等审查既有 CDK 代码检查最佳实践与反模式。不适用场景Do not use this skill when用户需要的是不带 CDK 的裸 CloudFormation 模板任务是Terraform 专属的该仓库另有 terraform-aws、terraform-azure 等技能覆盖一次性的 CLI 资源创建例如直接aws命令建单个资源就已足够。这一边界设计对读者有直接的工程启发技能Skill不是万能的模板引擎而是问题模式 → 解决方案模式的映射器。在把 CDK 引入项目前先判断需求是否真的需要可编程、可复用的基础设施抽象层。三、核心执行指令五步 CDK 设计流程技能给出了构建 CDK 基础设施的五个核心指令是贯穿全篇的方法论主线识别所需基础设施模式如 Serverless API、容器服务、数据管道优先使用 L2 构造而非 L1Cfn*构造以获得更安全的默认值对全部 IAM 角色与策略应用最小权限原则正确使用RemovalPolicy与Tags为生产环境就绪性负责面向复用组织 Stack将有状态资源数据库、Bucket与无状态资源计算、API分离到不同 Stack默认开启监控CloudWatch Alarms、X-Ray 追踪。其中值得展开理解的是第 2、5、6 条背后的工程动机L2 over L1L1Cfn*构造是 CloudFormation 资源的 1:1 映射参数名冗长且默认值贴近底层L2 构造则封装了安全默认值如默认加密、默认删除保护可选、简化权限授予能显著降低默认配置即隐患的风险。这一原则直接呼应后文反模式清单中Dont use L1 when L2 alternatives exist。有状态/无状态分离数据库与对象存储的生命周期、删除策略、备份策略与计算层完全不同。将它们拆到不同 Stack才能针对性地设置RemovalPolicy.RETAIN数据库与DESTROY可重建的计算资源也便于团队按风险级别分别审阅与部署。默认监控在构造资源的同时就挂上可观测性追踪、告警而不是上线后再补救是生产级 IaC 与能跑的 Demo之间的分水岭。四、示例精讲Serverless API 模式API Lambda DynamoDB技能正文给出了一个完整的 TypeScript 示例这是全文最具实操价值的部分下面完整继承并进行逐段深挖。import { Construct } from constructs; import * as apigateway from aws-cdk-lib/aws-apigateway; import * as lambda from aws-cdk-lib/aws-lambda; import * as dynamodb from aws-cdk-lib/aws-dynamodb; export class ServerlessApiPattern extends Construct { constructor(scope: Construct, id: string) { super(scope, id); const table new dynamodb.Table(this, Table, { partitionKey: { name: pk, type: dynamodb.AttributeType.STRING }, billingMode: dynamodb.BillingMode.PAY_PER_REQUEST, removalPolicy: cdk.RemovalPolicy.RETAIN, }); const handler new lambda.Function(this, Handler, { runtime: lambda.Runtime.NODEJS_20_X, handler: index.handler, code: lambda.Code.fromAsset(lambda), environment: { TABLE_NAME: table.tableName }, tracing: lambda.Tracing.ACTIVE, }); table.grantReadWriteData(handler); new apigateway.LambdaRestApi(this, Api, { handler }); } }4.1 DynamoDB 表按需计费与数据保留partitionKey: { name: pk, type: STRING }单分区键设计适合大多数按 ID 存取的业务场景若需要范围查询可进一步增加sortKeybillingMode: BillingMode.PAY_PER_REQUEST按需计费模式无需预估读写容量适合负载波动或早期阶段的 API避免为闲置吞吐量付费removalPolicy: cdk.RemovalPolicy.RETAIN数据保留策略。RETAIN意味着即使 Stack 被删除DynamoDB 表及其数据也会保留在账户中防止误删生产数据。对应地对于可重建的临时资源DESTROY才是合理选择——这正是技能指令第 5 条有状态/无状态分离的直接落地。4.2 Lambda 函数运行时、代码与追踪runtime: lambda.Runtime.NODEJS_20_X固定运行时版本避免未来运行时弃用导致的意外行为变化handler: index.handler指向lambda目录下index.js中导出的handler函数code: lambda.Code.fromAsset(lambda)从本地lambda目录打包上传代码是开发期最常用的方式environment: { TABLE_NAME: table.tableName }通过环境变量注入表名。这里 CDK 会在部署时自动解析为真实资源引用table.tableName属于 Token 引用会在合成阶段解析为动态值避免硬编码tracing: lambda.Tracing.ACTIVE为 Lambda 开启AWS X-Ray 主动追踪配合 API Gateway 即可获得端到端请求链路视图——这正是技能指令第 6 条默认开启监控的实例。4.3 最小权限授权一行代码背后的 IAM 语义table.grantReadWriteData(handler);这行代码是最小权限原则的最佳示范CDK 的grant*系列方法会自动创建一个Scope 最小化的 IAM 策略——仅授予该 Lambda 对此表的GetItem、PutItem、Query、Scan、UpdateItem、DeleteItem等读写操作不授予表删除、表描述或任何其他资源权限。相比手写iam.PolicyStatement并手动限定ResourceARN使用grantReadWriteData更安全、更不易出错。同理实践中应优先使用grantRead、grantWrite、grantReadWriteData、grantInvoke等封装方法而不是手写宽松策略。4.4 API Gateway 接入new apigateway.LambdaRestApi(this, Api, { handler });LambdaRestApi是 L2 构造中代理集成proxy integration的典型代表只需传入 handlerCDK 会自动创建 REST API、资源路径映射、ANY /{proxy}方法以及 Lambda 的调用权限。它把原本需要数百行 CloudFormation 的配置压缩为一行——这就是L2 构造抽象能力的直观体现。提示示例代码中引用了cdk.RemovalPolicy实际使用时需要在文件头部补充import * as cdk from aws-cdk-lib;以便获得RemovalPolicy、Aws等命名空间下的工具。五、最佳实践与反模式对照表技能正文以 Do/Dont 对照的形式给出了可直接执行的审查清单类型实践说明✅ Docdk.Tags.of(this).add()统一打标签一致性标签是成本分摊、资源归属审计与清理策略的基础✅ Do有状态与无状态资源拆分到不同 Stack便于分别制定删除策略与生命周期管理✅ Do每次部署前执行cdk diff合成阶段先查看将要发生的变更避免意外覆盖线上资源❌ Dont在有 L2 替代品时使用 L1Cfn*构造L1 缺少安全默认值与封装方法易埋下配置隐患❌ Dont硬编码账户 ID 或区域应使用cdk.Aws.ACCOUNT_ID、cdk.Aws.REGION等环境引用关于硬编码的替代方案可以进一步补充除了cdk.Aws.ACCOUNT_ID/cdk.Aws.REGION还可在cdk.json的context中声明环境参数或通过app.node.tryGetContext()读取上下文实现同一套代码在多个环境dev/staging/prod间的参数化复用。这也是面向复用设计 Stack指令第 5 条的配套手段。六、故障排查跨 Stack 循环依赖的根治方案技能正文给出了一条高频问题的处理方案问题Stack 之间的循环依赖Circular dependency解决方案将共享资源抽取到专用基础 Stack并通过构造函数参数constructor props传递引用。在多 Stack 应用中循环依赖的典型场景是Stack A 需要引用 Stack B 的某个输出而 Stack B 又反向引用 Stack A 的资源。CDK 在合成synth阶段会直接报循环引用错误无法生成模板。推荐的分层治理思路是抽取共享资源层把被多个 Stack 引用的资源如共享 VPC、共享 DynamoDB 表、KMS 密钥、跨账号的 IAM 角色下沉到独立的BaseStack或SharedStack引用传递而非反向依赖上层 Stack 通过构造函数接收BaseStack的导出属性如vpc、table对象形成单向依赖树必要时使用显式输出当资源需要被其他应用或阶段引用时通过CfnOutput导出配合Fn.importValue或 CDK 的Stack.fromLookup/ context 传递在另一端导入。这种基础栈 构造参数注入的模式同时提升了代码可读性与部署顺序的可控性CDK Pipelines 可依据依赖图自动排序部署。七、技能边界与限制什么时候该停下来技能正文在结尾明确声明了自身限制这些限制对使用者同样重要仅在任务清晰匹配上述范围时使用模式库是启发式的不是穷尽式的当需求偏离已知模式时不要强行套用输出不能替代环境专属的验证、测试与专家评审CDK 合成成功 ≠ 部署成功 ≠ 运行符合预期。仓库 docs/QUALITY_BAR.md 也强调了类似的交付质量底线——任何基础设施变更都应经过cdk synth、cdk diff、测试与人工 review缺少输入、权限、安全边界或成功标准时应停止并提问这是 Agent 技能设计中的安全护栏防止在信息不足时对生产环境执行破坏性操作。该技能风险等级为critical正对应仓库 docs/SECURITY_GUARDRAILS.md 中关于高风险技能需严格确认安全边界的约束。八、进阶延伸如何在本仓库中继续深化 CDK 技能如果你希望在本仓库基础上继续学习与扩展对照技能结构规范阅读 docs/SKILL_ANATOMY.md 与 docs/SKILL_TEMPLATE.md理解 SKILL.md 各章节Front Matter、Instructions、Examples、Best Practices、Troubleshooting、Limitations的撰写要求可以自行沉淀新的 CDK 模式查阅技能目录与触发器机制在 data/catalog.json 中检索cdk标签可找到关联技能在 data/skills_index.json 中可查看技能索引全貌理解 Agent 如何按triggers自动匹配技能了解技能质量评估标准schemas/skill-score.v1.schema.json 与 schemas/skills-index.v1.schema.json 定义了技能评分与索引的字段约束可作为自检清单参考云基础设施同类技能仓库中还有 terraform-aws、cloudformation、aws-ecs-fargate、aws-lambda 等相邻技能适合在工具选型对比时交叉阅读。总结cdk-patterns 技能以一份结构化、可执行的 SKILL.md浓缩了 AWS CDK 生产级开发的完整方法论L2 优先、最小权限、资源分层、默认可观测、前后 diff。配合仓库的目录元数据、技能规范文档与配套工具它既可以直接指导 TypeScript/Python/Java 项目的 CDK 开发与代码审查也可以作为团队沉淀自身基础设施模式时的范本。记住技能的边界声明——任何基础设施变更最终都必须以环境专属的验证与专家评审为准绳。赞分享AI 技能AI 插件【免费下载链接】agentic-awesome-skillsAAS Core is the local, agent-first control plane for complete catalog discovery, agent-owned selection, stack validation, and planning, backed by 2,445 agentic skills. Includes CLI, local MCP, catalog, plugins, and Workbench.项目地址https://gitcode.com/gh_mirrors/an/agentic-awesome-skills点击查看免费下载相关推荐使用 agentic-awesome-skills 的 aws-cdk-development 技能构建 AWS CDK 云基础设施命名规范、Lambda 开发与多层部署前校验实战使用 agentic awesome skills 的 aws cdk development 技能构建 AWS CDK 云基础设施命名规范、Lambda 开AI 技能AI 插件Agentic Awesome Skills 架构模式实战Clean Architecture、Hexagonal 与 DDD 实施手册Agentic Awesome Skills 架构模式实战Clean Architecture、Hexagonal 与 DDD 实施手册 本手册以 agentAI 技能AI 插件Chalice 的 CDK 模板实战用 AWS CDK 部署 DynamoDB 驱动的 REST APIChalice 的 CDK 模板实战用 AWS CDK 部署 DynamoDB 驱动的 REST API 本篇技术指南基于当前仓库 chalice/templ后端云原生创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/9/23 23:32:28 · 阅读 1.2k agentic-awesome-skills 中的 cdk-patterns：AWS CDK 可复用架构模式的实战指南
AI 技能AI 插件【免费下载链接】agentic-awesome-skillsAAS Core is the local, agent-first control plane for complete catalog discovery, agent-owned selection, stack validation, and planning, backed by 2,445 agentic skills. Includes CLI, local MCP, catalog, plugins, and Workbench.项目地址https://gitcode.com/gh_mirrors/an/agentic-awesome-skills点击查看免费下载导读本文以开源仓库 agentic-awesome-skills 中收录的 cdk-patterns 技能 为主体系统讲解如何用 AWS CDKCloud Development Kit设计可复用的基础设施即代码IaC架构从 L2/L3 构造Construct的选择、Serverless API Lambda DynamoDB 经典组合到生产级 Stack 的拆分、IAM 最小权限、标签与删除策略等最佳实践。读完本文你将掌握一套可直接用于 TypeScript、Python 或 Java 项目的 CDK 开发方法论并能识别常见反模式与循环依赖陷阱。一、技能定位cdk-patterns 在仓库目录体系中的角色在 agentic-awesome-skills 仓库中cdk-patterns 是一项以 Agent 技能Skill形式封装的领域知识存放于 plugins/agentic-awesome-skills-claude/skills/cdk-patterns/ 目录下主体文件为SKILL.md。其 Front Matter 元数据同时被仓库的目录体系索引例如在 data/catalog.json 中对应条目为{ id: cdk-patterns, canonical_id: cdk-patterns, name: cdk-patterns, description: Common AWS CDK patterns and constructs for building cloud infrastructure with TypeScript, Python, or Java. Use when designing reusable CDK stacks and L3 constructs., category: cloud, risk: critical, source: community, tags: [cdk], triggers: [cdk, common, aws, constructs, building, cloud, infrastructure, typescript, python, java, designing, reusable], path: skills/cdk-patterns/SKILL.md }从目录元数据可以看出几个关键事实分类与风险等级技能归类为cloud类别风险等级为critical涉及生产基础设施变更时需严格审查来源community属于社区贡献的技能触发器triggers字段列出了cdk、aws、constructs、infrastructure等关键词供 Agent 在任务匹配时自动唤起该技能多语言覆盖技能的 description 明确声明适用于 TypeScript、Python、Java 三种语言栈。技能主体SKILL.md采用标准的结构化格式Front Mattername/description/risk/source/date_added 专家定位声明 适用/不适用场景 执行指令 示例代码 最佳实践 故障排查 限制说明。这一结构也与仓库 docs/SKILL_ANATOMY.md 中定义的技能解剖规范保持一致读者可以对照该文档理解技能文件的通用骨架。二、何时使用 / 何时避免技能的场景边界技能正文首先划定了清晰的适用边界这是保证 Agent 不被误用、也不被滥用的第一道约束。适用场景Use this skill when构建可复用的 CDK 构造Construct或架构模式Pattern设计多 Stack 的 CDK 应用实现常见基础设施模式API Lambda DynamoDB、ECS 容器服务、静态站点等审查既有 CDK 代码检查最佳实践与反模式。不适用场景Do not use this skill when用户需要的是不带 CDK 的裸 CloudFormation 模板任务是Terraform 专属的该仓库另有 terraform-aws、terraform-azure 等技能覆盖一次性的 CLI 资源创建例如直接aws命令建单个资源就已足够。这一边界设计对读者有直接的工程启发技能Skill不是万能的模板引擎而是问题模式 → 解决方案模式的映射器。在把 CDK 引入项目前先判断需求是否真的需要可编程、可复用的基础设施抽象层。三、核心执行指令五步 CDK 设计流程技能给出了构建 CDK 基础设施的五个核心指令是贯穿全篇的方法论主线识别所需基础设施模式如 Serverless API、容器服务、数据管道优先使用 L2 构造而非 L1Cfn*构造以获得更安全的默认值对全部 IAM 角色与策略应用最小权限原则正确使用RemovalPolicy与Tags为生产环境就绪性负责面向复用组织 Stack将有状态资源数据库、Bucket与无状态资源计算、API分离到不同 Stack默认开启监控CloudWatch Alarms、X-Ray 追踪。其中值得展开理解的是第 2、5、6 条背后的工程动机L2 over L1L1Cfn*构造是 CloudFormation 资源的 1:1 映射参数名冗长且默认值贴近底层L2 构造则封装了安全默认值如默认加密、默认删除保护可选、简化权限授予能显著降低默认配置即隐患的风险。这一原则直接呼应后文反模式清单中Dont use L1 when L2 alternatives exist。有状态/无状态分离数据库与对象存储的生命周期、删除策略、备份策略与计算层完全不同。将它们拆到不同 Stack才能针对性地设置RemovalPolicy.RETAIN数据库与DESTROY可重建的计算资源也便于团队按风险级别分别审阅与部署。默认监控在构造资源的同时就挂上可观测性追踪、告警而不是上线后再补救是生产级 IaC 与能跑的 Demo之间的分水岭。四、示例精讲Serverless API 模式API Lambda DynamoDB技能正文给出了一个完整的 TypeScript 示例这是全文最具实操价值的部分下面完整继承并进行逐段深挖。import { Construct } from constructs; import * as apigateway from aws-cdk-lib/aws-apigateway; import * as lambda from aws-cdk-lib/aws-lambda; import * as dynamodb from aws-cdk-lib/aws-dynamodb; export class ServerlessApiPattern extends Construct { constructor(scope: Construct, id: string) { super(scope, id); const table new dynamodb.Table(this, Table, { partitionKey: { name: pk, type: dynamodb.AttributeType.STRING }, billingMode: dynamodb.BillingMode.PAY_PER_REQUEST, removalPolicy: cdk.RemovalPolicy.RETAIN, }); const handler new lambda.Function(this, Handler, { runtime: lambda.Runtime.NODEJS_20_X, handler: index.handler, code: lambda.Code.fromAsset(lambda), environment: { TABLE_NAME: table.tableName }, tracing: lambda.Tracing.ACTIVE, }); table.grantReadWriteData(handler); new apigateway.LambdaRestApi(this, Api, { handler }); } }4.1 DynamoDB 表按需计费与数据保留partitionKey: { name: pk, type: STRING }单分区键设计适合大多数按 ID 存取的业务场景若需要范围查询可进一步增加sortKeybillingMode: BillingMode.PAY_PER_REQUEST按需计费模式无需预估读写容量适合负载波动或早期阶段的 API避免为闲置吞吐量付费removalPolicy: cdk.RemovalPolicy.RETAIN数据保留策略。RETAIN意味着即使 Stack 被删除DynamoDB 表及其数据也会保留在账户中防止误删生产数据。对应地对于可重建的临时资源DESTROY才是合理选择——这正是技能指令第 5 条有状态/无状态分离的直接落地。4.2 Lambda 函数运行时、代码与追踪runtime: lambda.Runtime.NODEJS_20_X固定运行时版本避免未来运行时弃用导致的意外行为变化handler: index.handler指向lambda目录下index.js中导出的handler函数code: lambda.Code.fromAsset(lambda)从本地lambda目录打包上传代码是开发期最常用的方式environment: { TABLE_NAME: table.tableName }通过环境变量注入表名。这里 CDK 会在部署时自动解析为真实资源引用table.tableName属于 Token 引用会在合成阶段解析为动态值避免硬编码tracing: lambda.Tracing.ACTIVE为 Lambda 开启AWS X-Ray 主动追踪配合 API Gateway 即可获得端到端请求链路视图——这正是技能指令第 6 条默认开启监控的实例。4.3 最小权限授权一行代码背后的 IAM 语义table.grantReadWriteData(handler);这行代码是最小权限原则的最佳示范CDK 的grant*系列方法会自动创建一个Scope 最小化的 IAM 策略——仅授予该 Lambda 对此表的GetItem、PutItem、Query、Scan、UpdateItem、DeleteItem等读写操作不授予表删除、表描述或任何其他资源权限。相比手写iam.PolicyStatement并手动限定ResourceARN使用grantReadWriteData更安全、更不易出错。同理实践中应优先使用grantRead、grantWrite、grantReadWriteData、grantInvoke等封装方法而不是手写宽松策略。4.4 API Gateway 接入new apigateway.LambdaRestApi(this, Api, { handler });LambdaRestApi是 L2 构造中代理集成proxy integration的典型代表只需传入 handlerCDK 会自动创建 REST API、资源路径映射、ANY /{proxy}方法以及 Lambda 的调用权限。它把原本需要数百行 CloudFormation 的配置压缩为一行——这就是L2 构造抽象能力的直观体现。提示示例代码中引用了cdk.RemovalPolicy实际使用时需要在文件头部补充import * as cdk from aws-cdk-lib;以便获得RemovalPolicy、Aws等命名空间下的工具。五、最佳实践与反模式对照表技能正文以 Do/Dont 对照的形式给出了可直接执行的审查清单类型实践说明✅ Docdk.Tags.of(this).add()统一打标签一致性标签是成本分摊、资源归属审计与清理策略的基础✅ Do有状态与无状态资源拆分到不同 Stack便于分别制定删除策略与生命周期管理✅ Do每次部署前执行cdk diff合成阶段先查看将要发生的变更避免意外覆盖线上资源❌ Dont在有 L2 替代品时使用 L1Cfn*构造L1 缺少安全默认值与封装方法易埋下配置隐患❌ Dont硬编码账户 ID 或区域应使用cdk.Aws.ACCOUNT_ID、cdk.Aws.REGION等环境引用关于硬编码的替代方案可以进一步补充除了cdk.Aws.ACCOUNT_ID/cdk.Aws.REGION还可在cdk.json的context中声明环境参数或通过app.node.tryGetContext()读取上下文实现同一套代码在多个环境dev/staging/prod间的参数化复用。这也是面向复用设计 Stack指令第 5 条的配套手段。六、故障排查跨 Stack 循环依赖的根治方案技能正文给出了一条高频问题的处理方案问题Stack 之间的循环依赖Circular dependency解决方案将共享资源抽取到专用基础 Stack并通过构造函数参数constructor props传递引用。在多 Stack 应用中循环依赖的典型场景是Stack A 需要引用 Stack B 的某个输出而 Stack B 又反向引用 Stack A 的资源。CDK 在合成synth阶段会直接报循环引用错误无法生成模板。推荐的分层治理思路是抽取共享资源层把被多个 Stack 引用的资源如共享 VPC、共享 DynamoDB 表、KMS 密钥、跨账号的 IAM 角色下沉到独立的BaseStack或SharedStack引用传递而非反向依赖上层 Stack 通过构造函数接收BaseStack的导出属性如vpc、table对象形成单向依赖树必要时使用显式输出当资源需要被其他应用或阶段引用时通过CfnOutput导出配合Fn.importValue或 CDK 的Stack.fromLookup/ context 传递在另一端导入。这种基础栈 构造参数注入的模式同时提升了代码可读性与部署顺序的可控性CDK Pipelines 可依据依赖图自动排序部署。七、技能边界与限制什么时候该停下来技能正文在结尾明确声明了自身限制这些限制对使用者同样重要仅在任务清晰匹配上述范围时使用模式库是启发式的不是穷尽式的当需求偏离已知模式时不要强行套用输出不能替代环境专属的验证、测试与专家评审CDK 合成成功 ≠ 部署成功 ≠ 运行符合预期。仓库 docs/QUALITY_BAR.md 也强调了类似的交付质量底线——任何基础设施变更都应经过cdk synth、cdk diff、测试与人工 review缺少输入、权限、安全边界或成功标准时应停止并提问这是 Agent 技能设计中的安全护栏防止在信息不足时对生产环境执行破坏性操作。该技能风险等级为critical正对应仓库 docs/SECURITY_GUARDRAILS.md 中关于高风险技能需严格确认安全边界的约束。八、进阶延伸如何在本仓库中继续深化 CDK 技能如果你希望在本仓库基础上继续学习与扩展对照技能结构规范阅读 docs/SKILL_ANATOMY.md 与 docs/SKILL_TEMPLATE.md理解 SKILL.md 各章节Front Matter、Instructions、Examples、Best Practices、Troubleshooting、Limitations的撰写要求可以自行沉淀新的 CDK 模式查阅技能目录与触发器机制在 data/catalog.json 中检索cdk标签可找到关联技能在 data/skills_index.json 中可查看技能索引全貌理解 Agent 如何按triggers自动匹配技能了解技能质量评估标准schemas/skill-score.v1.schema.json 与 schemas/skills-index.v1.schema.json 定义了技能评分与索引的字段约束可作为自检清单参考云基础设施同类技能仓库中还有 terraform-aws、cloudformation、aws-ecs-fargate、aws-lambda 等相邻技能适合在工具选型对比时交叉阅读。总结cdk-patterns 技能以一份结构化、可执行的 SKILL.md浓缩了 AWS CDK 生产级开发的完整方法论L2 优先、最小权限、资源分层、默认可观测、前后 diff。配合仓库的目录元数据、技能规范文档与配套工具它既可以直接指导 TypeScript/Python/Java 项目的 CDK 开发与代码审查也可以作为团队沉淀自身基础设施模式时的范本。记住技能的边界声明——任何基础设施变更最终都必须以环境专属的验证与专家评审为准绳。赞分享AI 技能AI 插件【免费下载链接】agentic-awesome-skillsAAS Core is the local, agent-first control plane for complete catalog discovery, agent-owned selection, stack validation, and planning, backed by 2,445 agentic skills. Includes CLI, local MCP, catalog, plugins, and Workbench.项目地址https://gitcode.com/gh_mirrors/an/agentic-awesome-skills点击查看免费下载相关推荐使用 agentic-awesome-skills 的 aws-cdk-development 技能构建 AWS CDK 云基础设施命名规范、Lambda 开发与多层部署前校验实战使用 agentic awesome skills 的 aws cdk development 技能构建 AWS CDK 云基础设施命名规范、Lambda 开AI 技能AI 插件Agentic Awesome Skills 架构模式实战Clean Architecture、Hexagonal 与 DDD 实施手册Agentic Awesome Skills 架构模式实战Clean Architecture、Hexagonal 与 DDD 实施手册 本手册以 agentAI 技能AI 插件Chalice 的 CDK 模板实战用 AWS CDK 部署 DynamoDB 驱动的 REST APIChalice 的 CDK 模板实战用 AWS CDK 部署 DynamoDB 驱动的 REST API 本篇技术指南基于当前仓库 chalice/templ后端云原生创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考