1. 项目概述：当CDK遇上生成式AI

如果你正在用AWS搞生成式AI应用，大概率经历过这样的场景：想快速接入一个Bedrock模型试试效果，结果发现要配置IAM角色、设置VPC端点、处理网络策略，还得写一堆Lambda函数或者容器镜像来包装推理逻辑。一通操作下来，半天时间就没了，真正想验证的业务逻辑还没开始写。这种感觉，就像你想开车去兜风，结果光给车加油、检查轮胎、办通行证就耗尽了所有精力。

awslabs/generative-ai-cdk-constructs 这个项目，就是来帮你解决这个痛点的。它不是什么新的AI模型，而是一个 基础设施即代码（IaC）的“乐高积木”库 ，专门为在AWS上构建生成式AI应用而生。简单说，它是一组用AWS CDK（Cloud Development Kit）写好的、预先打包好的组件。你用几行TypeScript或Python代码，就能像搭积木一样，快速、安全、标准化地部署出包含模型访问、API网关、流式响应、监控等全套功能的AI应用后端。

这个库由AWS Labs出品，意味着它虽然不是官方的AWS产品级服务，但代表了AWS内部团队对于“如何更好在AWS上玩转GenAI”的最佳实践和模式总结。它的核心价值在于 将复杂的云资源配置抽象化、模式化 。你不用再关心底层的网络打通、权限细粒度控制这些繁琐的“脏活累活”，而是可以聚焦在提示词工程、业务逻辑编排和用户体验这些真正创造价值的地方。无论是想快速搭建一个智能客服的聊天接口，还是构建一个文档总结的批处理流水线，这个工具库都能让你事半功倍。

2. 核心设计思路与架构拆解

2.1 为什么是CDK Constructs，而不是SDK或Console？

要理解这个项目的设计初衷，得先看看在AWS上接入AI模型的几种常见方式及其痛点。

最原始的方式是直接用AWS管理控制台或AWS CLI。你手动创建IAM角色，在Bedrock控制台启用模型，然后可能再手动创建一个Lambda函数，把Bedrock的SDK调用代码写进去。这种方式 完全不可复制、不可审计、部署缓慢 ，只适合一次性实验。

进阶一点，会用AWS SDK（如boto3）在脚本或应用里直接调用。这解决了程序化调用的问题，但 基础设施配置（网络、权限）依然需要手动或另用工具（如CloudFormation）管理 ，导致应用代码和基础设施代码分离，维护成本高。

更现代的做法是使用IaC工具，如Terraform或AWS原生的CloudFormation。这能解决可重复部署的问题，但CloudFormation模板写起来冗长，Terraform的模块需要自己找或写，对于生成式AI这种较新的服务，成熟的社区模块可能不多。

而CDK（Cloud Development Kit）采取了一种“升维”思路： 用熟悉的编程语言（TypeScript、Python等）来定义基础设施 。你可以使用条件判断、循环、继承等编程特性，还能直接引用和复用经过良好设计的代码模块，这就是Constructs。

generative-ai-cdk-constructs 项目正是基于CDK的这一优势，提供了针对生成式AI场景的、开箱即用的Constructs。它的设计思路很清晰：

1. 封装最佳实践 ：把AWS Well-Architected Framework中关于安全、可靠、高效的原则，直接固化到Construct的默认配置里。比如，默认启用VPC端点来保证Bedrock流量不经过公网，默认设置最小权限的IAM策略。
2. 提供高级抽象 ：它提供的不是基础资源（如 aws-bedrock.CfnModel ），而是面向解决方案的组件。例如，一个 ChatBot Construct，可能直接帮你创建了API Gateway、Lambda函数、以及连接Bedrock所需的全部权限和网络配置。
3. 促进标准化 ：团队内部使用统一的Constructs，能确保不同项目的基础设施架构一致，降低运维复杂度和新人上手成本。

2.2 核心架构模式：从模型调用到可部署应用

这个库的Constructs大致可以分为几个层次，对应着不同的使用场景和抽象级别：

第一层：模型访问与代理层 这是最基础的Constructs，例如 BedrockModel 或 BedrockAgent 。它们主要封装了对Amazon Bedrock服务的访问。你指定一个模型ID（如 anthropic.claude-3-sonnet-v1 ），它就在背后为你创建好一个可以安全调用该模型的Lambda函数或Fargate任务，并配好所有权限。这一层的目标是让你用一行代码获得一个“可调用的模型端点”。

第二层：应用模式层 这是库的核心价值所在，提供了常见的生成式AI应用模式。例如：

• ChatBot ：快速创建一个带有WebSocket或HTTP API的聊天机器人后端，内置对话历史管理（可能用到DynamoDB）。
• RAG (Retrieval Augmented Generation) Pipeline ：构建一个完整的RAG流水线，可能包含文本切分、向量化（通过Bedrock Titan Embeddings）、向量存储（如OpenSearch）和检索增强的查询接口。
• AsyncInvokeChain ：处理需要长时间运行或链式调用多个模型的复杂工作流，可能涉及Step Functions进行状态编排。

第三层：工具与集成层 提供一些提升开发体验和运维能力的工具类Constructs。例如：

• MonitoringDashboard ：自动创建一个CloudWatch仪表盘，监控模型调用的延迟、错误率、令牌使用量和成本。
• SafeGuard ：集成Amazon Bedrock的Guardrails功能或自定义的内容过滤器，为你的AI应用添加安全护栏。

这种分层架构的好处是灵活。你可以从底层开始，自己组合构建复杂应用；也可以直接使用高层的模式，快速实现业务需求。所有Constructs都遵循CDK的最佳实践，输出标准的CloudFormation模板，可以无缝集成到你现有的CDK应用中。

3. 核心Constructs深度解析与实操要点

3.1 基石：BedrockModel Construct 详解

BedrockModel 可能是你最常用到的Construct。它看起来简单，但背后隐藏着很多实用的默认配置和可定制选项。

import * as genai from '@aws-cdk/generative-ai-constructs';
import * as cdk from 'aws-cdk-lib';

const bedrockModel = new genai.BedrockModel(this, 'MyClaudeModel', {
  modelId: 'anthropic.claude-3-haiku-20240307-v1:0',
  region: 'us-east-1', // 指定Bedrock模型可用的区域
});

就这么几行代码，部署后你会得到一个什么？它默认会创建一个 运行在Lambda上的模型代理 。这个Lambda函数已经内置了Bedrock Runtime SDK的调用代码，并拥有精确到指定模型ID的 bedrock:InvokeModel 权限。更重要的是，如果你当前的CDK栈部署在某个VPC内，并且指定了私有子网，这个Construct 默认会尝试配置VPC端点 ，确保Lambda调用Bedrock的流量走AWS内部网络，更安全、更稳定、延迟也可能更低。

注意 ：自动配置VPC端点是个很棒的特性，但需要你的CDK执行角色有足够的权限（如 ec2:CreateVpcEndpoint ）。在生产环境中，建议在组织的账户级预先配置好这些共享的VPC端点，然后在Construct中通过 vpcEndpoint 属性直接引用，而不是每次都新建。

关键属性与高级配置：

• runtime : 默认是 lambda.Function ，但你也可以指定为 ecs.FargateTaskDefinition 。如果你的模型调用需要更大的内存（例如处理超长上下文）、更长的超时时间（超过15分钟）或者需要GPU，那么使用Fargate是更好的选择。
• environmentVariables : 可以向承载模型的Lambda或容器传递环境变量。一个常见的用法是传递模型参数，比如 { “MAX_TOKENS”: “2000”, “TEMPERATURE”: “0.7” } 。
• timeout 和 memorySize (针对Lambda): 对于Claude 3 Haiku这类轻量模型，默认配置可能够用。但对于Sonnet或Opus，或者处理大量文本时， 务必调高内存和超时 。我的经验是，Lambda内存至少设置为1024MB，超时设置为30秒，以应对模型“思考”的波动。
• vpc 和 vpcSubnets : 这是控制网络隔离的关键。强烈建议为生产环境的AI应用配置独立的私有子网，并将模型Construct部署其中。

3.2 快速成型：使用 ChatBot Construct 搭建对话接口

当你需要的不只是一个模型调用点，而是一个完整的、可对外提供服务的聊天API时， ChatBot Construct就派上用场了。

const chatbot = new genai.ChatBot(this, 'CustomerServiceBot', {
  bedrockModel: bedrockModel, // 传入上面定义的模型
  chatHistoryConfig: {
    storageType: genai.ChatHistoryStorageType.DYNAMODB,
    tableName: 'ChatSessions',
    ttlAttribute: 'expireAt',
  },
  apiGatewayConfig: {
    stageName: 'prod',
    throttling: { rateLimit: 100, burstLimit: 50 },
  },
});

部署这个Construct，CDK会在后台为你创建以下资源：

1. 一个 Amazon API Gateway (REST或HTTP API)，提供 /chat 之类的端点。
2. 一个处理HTTP请求和对话逻辑的 Lambda函数 （或Fargate服务）。
3. 一个用于持久化对话历史的 Amazon DynamoDB表 。
4. 将所有资源连接起来所需的 IAM角色、策略和VPC配置 。

实操心得与避坑指南：

1. 对话状态管理 ： ChatBot Construct内置的对话历史管理是比较基础的，通常是将整个对话轮次序列化后存入DynamoDB的一个属性中。对于超长对话，这可能会触及DynamoDB的单项属性大小限制（400KB）。 解决方案是 ：要么在构造时设置 maxHistoryTokens 来限制保存的历史长度，要么自己实现一个更复杂的历史管理逻辑，例如只存储最近N轮或通过摘要压缩历史。
2. 流式响应 ：生成式AI的体验精髓在于流式输出（Token-by-Token）。 ChatBot Construct 应该支持配置为返回流式响应（例如使用API Gateway的WebSocket或HTTP API的流式响应功能）。在配置时，务必确认 responseStreaming 选项已开启，并且前端代码能够处理服务器发送事件（Server-Sent Events）或WebSocket消息。
3. 认证与授权 ：Construct默认创建的API可能是公开的。 在生产环境中，你必须额外配置认证 。可以通过 apiGatewayConfig 集成Cognito用户池、Lambda授权器或IAM授权。不要遗漏这一步，否则你的API可能面临滥用风险。
4. 冷启动优化 ：如果后端是Lambda，模型加载可能带来冷启动延迟。考虑以下方案：使用Provisioned Concurrency（预置并发）；或者，对于对延迟极其敏感的场景，使用Fargate作为运行时并保持至少一个任务常驻。

3.3 进阶模式：构建RAG流水线

RAG是目前让大模型获取最新、专有知识的最有效范式之一。这个库提供了构建RAG流水线的高级抽象。

一个典型的RAG Construct（可能叫 RagPipeline 或类似）可能会要求你提供以下配置：

• sourceDataBucket : 存放原始文档（PDF, Word, TXT）的S3桶。
• embeddingModel : 用于生成向量嵌入的模型，通常是Bedrock的Titan Embeddings。
• vectorStore : 向量数据库配置，可能是内嵌的OpenSearch域，或连接外部的Pinecone等。
• queryModel : 用于最终生成答案的LLM，如Claude 3。

部署后，它会创建一套完整的无服务器流水线：

• 摄取管道 ：由S3事件触发，启动文本提取（可能用Amazon Textract）、分块、向量化并存入向量库。
• 查询接口 ：一个API端点，接收用户问题，先到向量库检索相关片段，再将片段和问题一起发给LLM生成答案。

核心难点与调优点：

1. 文本分块策略 ：这是RAG效果的决定性因素之一。Construct可能会提供简单的按固定长度分块。但对于技术文档、法律合同等，你需要更智能的分块（按章节、按语义）。 你需要做的是 ：深入研究分块逻辑，很可能需要提供一个自定义的分块函数（Lambda）给Construct。
2. 向量搜索的精度 ：默认的相似度搜索（如余弦相似度）可能不够。考虑启用 重排序（Re-ranking） 步骤。可以在检索出Top K个片段后，用一个更小、更快的模型（或交叉编码器）对它们进行相关性重排，再将Top N个最相关的片段送给LLM。这能显著提升答案质量。
3. 元数据过滤 ：在向量存储时，除了嵌入向量，还要存储元数据（如文档来源、章节、日期）。查询时，除了向量相似度，还可以结合元数据过滤器（如“只搜索2023年以后的文档”）。确保你使用的Construct支持配置元数据字段。

4. 完整实操：从零部署一个智能文档问答助手

让我们通过一个具体场景，串联使用多个Constructs，部署一个能回答关于公司内部技术文档问题的智能助手。

4.1 项目初始化与环境准备

首先，确保你的环境已就绪：

# 1. 安装Node.js和AWS CDK
npm install -g aws-cdk

# 2. 初始化一个TypeScript CDK项目
mkdir my-doc-qa && cd my-doc-qa
cdk init app --language=typescript

# 3. 安装生成式AI Constructs库
npm install @aws-cdk/generative-ai-constructs

4.2 基础设施栈定义 ( lib/my-doc-qa-stack.ts )

我们将创建一个栈，包含RAG流水线和聊天接口。

import * as cdk from 'aws-cdk-lib';
import * as s3 from 'aws-cdk-lib/aws-s3';
import * as dynamodb from 'aws-cdk-lib/aws-dynamodb';
import * as genai from '@aws-cdk/generative-ai-constructs';

export class MyDocQaStack extends cdk.Stack {
  constructor(scope: cdk.App, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    // 1. 创建存储原始文档的S3桶
    const sourceBucket = new s3.Bucket(this, 'SourceDocumentsBucket', {
      encryption: s3.BucketEncryption.S3_MANAGED,
      lifecycleRules: [{
        expiration: cdk.Duration.days(365), // 设置文档保留策略
      }],
    });

    // 2. 创建用于聊天历史的DynamoDB表
    const chatHistoryTable = new dynamodb.Table(this, 'ChatHistoryTable', {
      partitionKey: { name: 'sessionId', type: dynamodb.AttributeType.STRING },
      sortKey: { name: 'timestamp', type: dynamodb.AttributeType.NUMBER },
      timeToLiveAttribute: 'expireAt', // 设置TTL自动清理旧会话
      billingMode: dynamodb.BillingMode.PAY_PER_REQUEST,
    });

    // 3. 创建RAG流水线
    const ragPipeline = new genai.RagPipeline(this, 'TechDocRagPipeline', {
      sourceBucket: sourceBucket,
      embeddingModelId: 'amazon.titan-embed-text-v1',
      llmModelId: 'anthropic.claude-3-sonnet-20240229-v1:0',
      chunkingStrategy: genai.ChunkingStrategy.SEMANTIC, // 使用语义分块
      vectorStore: {
        type: genai.VectorStoreType.OPENSEARCH_SERVERLESS,
        collectionArn: 'arn:aws:aoss:us-east-1:123456789012:collection/your-collection-id', // 需预先创建
      },
    });

    // 4. 创建聊天机器人，并连接到RAG流水线
    const docQaBot = new genai.ChatBot(this, 'DocQaChatBot', {
      bedrockModel: ragPipeline.queryInterface, // 使用RAG流水线提供的查询接口
      chatHistoryConfig: {
        storageType: genai.ChatHistoryStorageType.DYNAMODB,
        existingTable: chatHistoryTable, // 使用我们上面创建的表
      },
      apiGatewayConfig: {
        stageName: 'api',
        defaultCorsPreflightOptions: {
          allowOrigins: ['https://your-frontend.com'], // 替换为你的前端域名
          allowMethods: ['POST', 'OPTIONS'],
        },
        authorizationType: genai.AuthorizationType.IAM, // 使用IAM进行API认证
      },
      systemPrompt: `你是一个专业的公司技术文档助手。请严格根据提供的上下文信息回答问题。如果上下文信息不足以回答问题，请明确告知“根据现有文档，我无法回答这个问题”，不要编造信息。`,
    });

    // 5. 输出有用的信息
    new cdk.CfnOutput(this, 'SourceBucketName', { value: sourceBucket.bucketName });
    new cdk.CfnOutput(this, 'ChatApiEndpoint', { value: docQaBot.apiEndpoint });
  }
}

4.3 部署与验证

1. 引导和部署 ：

   cdk bootstrap  # 首次在目标AWS账户/区域部署时需要
   cdk synth      # 生成CloudFormation模板，检查是否有误
   cdk deploy     # 部署到AWS
   

   部署过程大约需要10-15分钟，因为会创建OpenSearch Serverless集合等资源。

2. 上传文档 ： 部署完成后，控制台会输出 SourceBucketName 。将你的技术文档（PDF、TXT等）上传到这个S3桶。上传事件会自动触发RAG流水线的摄取处理。你可以通过查看RAG流水线创建的“状态” DynamoDB表或CloudWatch Logs来监控摄取进度。

3. 测试API ： 部署还会输出 ChatApiEndpoint 。由于我们设置了IAM授权，你需要使用AWS SigV4签名来调用API。一个简单的测试方法是使用Postman配合AWS签名插件，或者写一个简单的测试脚本：

   import boto3
   import requests
   from requests_aws4auth import AWS4Auth
   
   region = 'us-east-1'
   service = 'execute-api'
   endpoint = 'YOUR_API_ENDPOINT'  # 替换为输出值
   
   credentials = boto3.Session().get_credentials()
   auth = AWS4Auth(credentials.access_key, credentials.secret_key, region, service, session_token=credentials.token)
   
   response = requests.post(
       f"{endpoint}/chat",
       auth=auth,
       json={"message": "我们公司的数据备份策略是什么？", "sessionId": "test-session-123"}
   )
   print(response.json())
   

5. 常见问题、排查技巧与成本优化

5.1 部署与运行时常见错误

问题现象	可能原因	排查步骤与解决方案
cdk deploy 失败，提示 VPC endpoint creation failed	1. CDK执行角色权限不足。 2. 指定的VPC子网没有空闲IP地址。 3. 该区域不支持Bedrock的VPC端点服务。	1. 检查并确保角色有 ec2:CreateVpcEndpoint 权限。 2. 检查子网的可用IP数量，或换一个子网。 3. 在AWS官方文档确认你的区域Bedrock支持VPC端点。 临时方案 ：在Construct属性中显式设置 vpcEndpoint: undefined 并确保Lambda函数具有公网访问能力（NAT网关）。
Lambda函数调用超时	1. 模型响应时间过长。 2. Lambda内存或超时设置过小。 3. 网络延迟（如果走公网）。	1. 在Bedrock控制台测试该模型的典型响应时间。 2. 增加Lambda内存（如2048MB）和超时时间（如3分钟） 。内存增加也会提升CPU性能，可能加速推理。 3. 确保使用VPC端点，并检查VPC配置（路由表、安全组）是否允许Lambda访问端点。
API返回 403 Access Denied	1. IAM角色权限未正确附加。 2. API Gateway的IAM授权策略配置错误。 3. 请求签名不正确。	1. 检查部署后Lambda函数的执行角色，是否包含Bedrock的 InvokeModel 权限。 2. 检查API Gateway的Resource Policy，确保调用的用户/角色有 execute-api:Invoke 权限。 3. 使用AWS SDK或确保签名算法正确。可以用 aws cloudformation describe-stack-events 查看部署时有无IAM错误。
RAG流水线摄取文档无反应	1. S3事件通知未成功配置。 2. 处理文档的Lambda函数出错。 3. 向量数据库连接失败。	1. 检查源S3桶的事件通知配置。 2. 查看处理函数的CloudWatch Logs，常见错误是文本提取库缺失或权限问题。 3. 检查向量数据库（如OpenSearch）的安全组、IAM角色权限是否正确。 关键 ：为处理函数设置足够的DLQ（死信队列）以便捕获失败信息。

5.2 性能与成本优化实战

生成式AI应用的成本主要来自两部分： 模型推理费用 和 基础设施资源费用 。以下是一些实战优化技巧：

1. 模型层优化：

• 选择合适的模型 ：不是所有任务都需要Claude 3 Opus。对于信息提取、简单分类，Haiku甚至Titan Text Lite可能就足够了，成本相差数十倍。使用Construct时，可以定义多个不同规格的 BedrockModel ，根据任务路由。
• 缓存模型响应 ：对于常见、重复的问题（如产品FAQ），可以在API Gateway或Lambda层添加缓存（如使用Amazon ElastiCache for Redis）。Construct本身不包含此功能，但你可以很容易地在它创建的Lambda函数前放置一个API Gateway缓存。
• 设置使用限额与监控 ：利用Bedrock本身的用量限额（Provisioned Throughput）来控制预算。同时，使用Construct自带的或自定义的 MonitoringDashboard ，密切关注 InputTokenCount 和 OutputTokenCount ，设置CloudWatch警报。

2. 基础设施层优化：

• Lambda配置调优 ：不要盲目使用大内存。通过负载测试，找到性价比最高的内存设置（如512MB vs 1024MB）。更高的内存通常意味着更强的CPU和更快的执行，可能反而降低总体成本（因为计费按GB-秒）。
• 向量数据库选型 ：OpenSearch Serverless按实际计算和存储收费，适合用量波动的场景。如果数据量巨大且查询稳定，考虑OpenSearch集群预留实例可能更经济。Construct通常支持配置，根据你的模式选择。
• 关闭开发环境 ：为开发环境栈设置 cdk destroy 计划任务，或在非工作时间手动关闭不用的资源（如将Fargate服务副本数设为0）。

3. 架构优化：

• 异步处理长任务 ：如果用户查询需要处理大量文档（如总结100页PDF），不要同步等待。改用 AsyncInvokeChain 模式，通过Step Functions异步触发处理流程，完成后通过WebSocket或轮询通知用户。这能提升API响应速度，避免超时。
• 批量处理文档 ：对于RAG的文档摄取，不要每上传一个文件就触发一次处理。可以设置一个定时器（如每5分钟），批量处理S3桶中新上传的文件，以减少Lambda的冷启动和向量数据库的写入次数。

5.3 安全加固要点

安全是生产应用的基石，Constructs提供了安全默认值，但你仍需关注以下几点：

1. 最小权限原则 ：检查Construct自动生成的IAM策略。虽然它已经尽量精确（如限定到具体模型ARN），但你仍应复查。特别是处理S3文档的流水线，确保其只有对源桶的 s3:GetObject 权限，没有不必要的 Put 或 Delete 权限。
2. 网络隔离 ：务必使用VPC和私有子网部署所有资源。确保Lambda函数、Fargate任务都在私有子网中，通过VPC端点访问Bedrock、S3等其他AWS服务。将API Gateway设置为私有类型，或通过VPC Link连接到内网负载均衡器。
3. 输入输出验证与过滤 ：Construct不会替你过滤用户输入和模型输出。 必须 在应用层（你自定义的Lambda处理逻辑中）添加输入验证，防止提示词注入攻击。同时，集成Bedrock Guardrails或自定义内容过滤器，对模型的输出进行审查，过滤掉有害、偏见或敏感内容。
4. 秘密管理 ：如果你的应用需要访问外部API密钥（例如用于第三方翻译服务），绝对不要硬编码在代码中。使用AWS Secrets Manager或Parameter Store来存储，并在Construct的 environmentVariables 中通过动态引用的方式传入。

6. 扩展思路：从应用到平台

当你熟练使用这些基础Constructs后，可以思考如何将它们组合，构建更强大的内部AI平台。

思路一：构建模型路由网关 创建一个统一的API网关，后面根据请求头或内容，动态路由到不同的 BedrockModel （如Claude、Llama、Jurassic）。可以基于成本、性能、功能特性来做路由决策。这需要你编写一个自定义的Lambda授权器或集成Amazon API Gateway的Mapping Template来实现路由逻辑。

思路二：实现复杂的多步工作流 利用CDK和Step Functions，将多个Construct串联起来。例如，一个“内容创作”工作流：先调用 BedrockModel (Claude) 生成草稿，再调用另一个 BedrockModel (Titan Text) 进行风格检查，最后调用Amazon Polly将文本转为语音。用Step Functions编排整个流程，并处理错误重试。

思路三：集成自定义模型或外部API Constructs主要面向Bedrock，但你的业务可能还需要使用SageMaker托管的自定义模型，或调用OpenAI的API。这时，你可以借鉴 BedrockModel 的设计模式，创建自己的 CustomModel Construct。封装一个调用SageMaker端点的Lambda函数，并配置好网络和权限。这样，你的团队就能以统一的方式消费所有AI能力。

awslabs/generative-ai-cdk-constructs 的价值，远不止于帮你节省几行CloudFormation代码。它更像是一个设计模式的集合和一套最佳实践的起点。它让你能站在一个更高的抽象层去思考AI应用架构，而不是陷在云资源的泥潭里。从快速原型到生产部署，从单一功能到复杂平台，这个工具库都能提供坚实的支撑。当然，它并非银弹，深入理解其背后的AWS服务原理，并根据自身业务需求进行定制和优化，才是用好它的关键。我的建议是，从一个小而具体的场景开始尝试，比如先部署一个简单的文档摘要服务，在实战中熟悉它的每一个参数和背后的资源，然后再逐步应用到更核心的业务场景中去。