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

如果你正在用AWS构建生成式AI应用，并且已经厌倦了在控制台里手动点击、配置各种服务，或者对着CloudFormation模板和一堆IAM策略文档头疼，那么 awslabs/generative-ai-cdk-constructs 这个项目，很可能就是你一直在找的“脚手架”。简单来说，这是AWS实验室（awslabs）官方出品的一个开源CDK构造库，专门用来帮你用代码（TypeScript/Python）快速、标准化地部署和管理生成式AI应用所需的各种AWS资源。

我最初接触它，是因为团队里一个常见的需求：快速为不同的业务线搭建基于Amazon Bedrock的聊天机器人原型。每次都要从头开始：创建Lambda函数、配置API Gateway、设置Bedrock的权限、处理流式响应、考虑日志和监控……重复劳动多，还容易出错。这个CDK构造库的核心价值，就在于它把这些繁琐的、模式化的基础设施代码，封装成了一个个更高层级的、可复用的“乐高积木”（Constructs）。你不再需要关心底层IAM策略的具体JSON怎么写，也不需要记忆Bedrock每个模型的确切ARN，只需要几行代码，就能拉起一个具备生产级基础配置的完整应用后端。

它解决的痛点非常明确： 降低生成式AI应用的基础设施复杂度，提升开发部署效率，并促进最佳实践的标准化 。无论是想快速验证一个想法，还是构建一个需要投入生产的系统，这个库都能让你把精力更集中在业务逻辑和提示词工程上，而不是基础设施的细枝末节。适合的读者包括：已经熟悉AWS CDK基本概念的开发者、正在或计划在AWS上构建生成式AI应用的团队、以及任何希望用“基础设施即代码”来管理AI工作负载的工程师。

2. 核心构造库深度解析：不止是Bedrock的快捷方式

很多人第一眼看到这个库，会以为它只是Amazon Bedrock的一个CDK包装器。这没错，但它的能力远不止于此。这个构造库提供了一系列不同层级的Constructs，从最底层的模型接口，到完整的、可部署的应用程序模式，形成了一个清晰的能力阶梯。

2.1 核心构造（Constructs）分类与选型

库中的Constructs大致可以分为三层，理解这个分层对正确选型至关重要。

第一层：基础模型层（Foundation Models） 这是最基础的构造，例如 BedrockKnowledgeBase 和 OpenSearchVectorStore 。它们直接对应AWS的AI服务资源。 BedrockKnowledgeBase 让你能够用代码创建一个知识库，并关联一个向量存储（如Amazon OpenSearch Serverless）。它的价值在于自动化了数据源连接、文本拆分、嵌入向量生成和索引创建的整个流水线。你只需要指定S3数据源的位置和嵌入模型，它就会在后台调用Bedrock的异步API完成所有工作。

注意：创建知识库是一个异步过程，CDK部署成功只代表资源创建完成，数据摄入可能仍在进行。在后续的Lambda函数或应用代码中，需要检查知识库的 status 字段，确保数据就绪后再进行查询。

第二层：应用模式层（Application Patterns） 这是库的精华所在，提供了几种开箱即用的、完整的服务器端应用架构。最常用的是 ChatBot 这个构造。你给它一个Bedrock模型ID（比如 anthropic.claude-3-haiku-20240307-v1:0 ）和可选的知识库，它会自动为你部署以下资源：

1. 一个处理对话逻辑的Lambda函数（默认带流式响应支持）。
2. 一个HTTP API Gateway作为前端接口。
3. 所有必要的IAM角色和策略，让Lambda可以安全地调用Bedrock、知识库以及CloudWatch Logs。
4. （可选）一个用于存储对话历史的Amazon DynamoDB表。
5. （可选）一个用于敏感词过滤的Amazon Comprehend端点。

使用 ChatBot ，你几乎可以在10行代码内获得一个功能完整的聊天后端。这对于快速原型（POC）和内部工具开发来说，效率提升是数量级的。

第三层：代理与工作流层（Agents & Workflows） 这一层代表了更复杂的编排能力，例如对Bedrock Agents和Prompt Flows的支持。它们允许你定义更复杂的多步骤推理、工具调用（如查询数据库、调用外部API）流程。虽然这个库在此层的抽象还在不断演进，但它指明了方向：用CDK来定义和部署复杂的AI智能体工作流，而不仅仅是简单的问答。

在实际选型时，我的经验是： 从 ChatBot 模式开始 。它能解决80%的常见场景。只有当你有自定义的预处理、后处理逻辑，或者需要与非Bedrock服务深度集成时，才考虑组合使用基础层的Constructs来自行构建。避免“为了抽象而抽象”，直接使用高层模式能最大程度减少认知负担和运维成本。

2.2 关键配置参数与安全考量

使用这些构造时，有几个关键配置点决定了应用的性能、成本和安全基线。

模型与参数配置 以 ChatBot 为例，初始化时你需要指定 model 。这里不能只写 claude-3-haiku ，必须使用完整的模型ARN标识符。库通常提供了常量，如 BedrockFoundationModel.ANTHROPIC_CLAUDE_3_HAIKU ，使用它们可以避免拼写错误。更重要的是 modelProps ，你可以在这里设置推理参数：

modelProps: {
  maxTokens: 2000,
  temperature: 0.7,
  topP: 0.9,
}

temperature 和 topP 是控制生成“创造性”和“确定性”的关键。对于客服机器人， temperature 通常设低（如0.1-0.3）以保证回答稳定；对于创意生成，可以调高。 maxTokens 需要根据模型上下文窗口和你的提示词长度来设定，设置过低会导致回答被截断。

权限与安全边界 这是CDK的优势，也是容易踩坑的地方。构造库默认会创建具有最小必要权限的IAM角色。例如， ChatBot 的Lambda角色默认只有调用特定Bedrock模型和写入CloudWatch Logs的权限。但如果你需要让机器人访问S3桶或DynamoDB表，就必须显式地添加权限。

// 假设chatbot是一个ChatBot构造实例
const myBucket = new s3.Bucket(this, ‘MyDataBucket’);
myBucket.grantRead(chatBot.lambdaFunction);

务必遵循最小权限原则。不要因为图省事，就给Lambda函数附加 AdministratorAccess 或过于宽泛的S3 * 权限。构造库生成的默认策略是一个很好的安全基线，你应该在此基础上进行增补，而不是覆盖。

网络与数据安全 如果你的应用部署在VPC内，或者需要访问VPC内的资源（如私有的OpenSearch集群），你需要为Lambda函数配置VPC。构造库的 ChatBot 提供了 vpc 和 vpcSubnets 属性。一旦将Lambda放入VPC，就必须处理好网络出口问题（例如通过NAT网关）以便其访问Bedrock的公共API端点。另一种更安全的做法是使用VPC端点（PrivateLink）来访问Bedrock，这样流量就不会经过公网。构造库目前不会自动创建VPC端点，你需要自己添加：

// 在Stack中创建Bedrock的VPC端点
new ec2.InterfaceVpcEndpoint(this, ‘BedrockVpcEndpoint’, {
  vpc,
  service: ec2.InterfaceVpcEndpointAwsService.BEDROCK_RUNTIME,
});

然后确保Lambda函数所在子网的路由表能将该端点的流量指向正确方向。

3. 实战：从零构建一个带知识库的智能客服机器人

理论说了这么多，我们动手搭一个真实可用的东西。假设我们要为一个电商公司构建一个内部客服助手，它能回答关于产品退货政策的问题，政策文档已经以PDF格式存放在一个S3桶里。

3.1 环境准备与项目初始化

首先，确保你的环境符合要求：Node.js版本（18+），AWS CLI已配置好凭证，并且已经安装并引导（bootstrap）过CDK。然后，创建一个新的CDK项目（这里以TypeScript为例）：

mkdir customer-service-bot && cd customer-service-bot
cdk init app --language=typescript
npm install

接下来，安装这个生成式AI构造库：

npm install @cdklabs/generative-ai-cdk-constructs

同时，你很可能还需要安装处理S3和DynamoDB的AWS CDK库：

npm install aws-cdk-lib/aws-s3 aws-cdk-lib/aws-dynamodb

3.2 基础设施栈代码编写

打开 lib/customer-service-bot-stack.ts 文件，开始编写我们的栈。我们将一步步构建。

第一步：导入依赖并创建S3桶存放知识源

import * as cdk from ‘aws-cdk-lib’;
import { Construct } from ‘constructs’;
import * as s3 from ‘aws-cdk-lib/aws-s3’;
import * as dynamodb from ‘aws-cdk-lib/aws-dynamodb’;
import { ChatBot, BedrockKnowledgeBase } from ‘@cdklabs/generative-ai-cdk-constructs’;

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

    // 创建一个S3桶来存放我们的退货政策文档
    // 注意：在实际生产中，这个桶可能已经存在，你可以使用 fromBucketName 来引用
    const policyDocumentsBucket = new s3.Bucket(this, ‘PolicyDocumentsBucket’, {
      removalPolicy: cdk.RemovalPolicy.DESTROY, // 仅为演示，生产环境请使用 RETAIN
      autoDeleteObjects: true, // 配合DESTROY，删除栈时自动清空桶
    });

这里创建了一个新的S3桶。 RemovalPolicy.DESTROY 意味着删除CDK栈时，这个桶也会被删除，这非常适合开发和测试环境，可以避免资源残留。但在生产环境中，请务必使用 RemovalPolicy.RETAIN 或 SNAPSHOT ，防止数据丢失。

第二步：创建向量存储与知识库 知识库需要一个地方来存储文档的嵌入向量。这里我们选择完全托管的 OpenSearchServerless 作为向量存储，这是构造库内置支持且无需管理集群的最佳选择。

    // 创建知识库，它会自动处理文档分块、向量化和索引
    const knowledgeBase = new BedrockKnowledgeBase(this, ‘ReturnPolicyKB’, {
      embeddingsModel: BedrockFoundationModel.COHERE_EMBED_ENGLISH_V3, // 选择嵌入模型
      vectorStore: {
        type: ‘opensearchServerless’,
        // 构造库会自动创建必要的OpenSearch Serverless集合和索引
        opensearchServerlessCollectionName: ‘customer-service-vector-store’,
      },
      knowledgeBaseName: ‘customer-service-return-policy’,
      dataSource: {
        type: ‘s3’,
        bucket: policyDocumentsBucket,
        // 你可以指定桶内的前缀，例如 ‘policies/returns/’
        inclusionPrefixes: [‘’], // 这里我们索引整个桶
      },
    });

BedrockKnowledgeBase 构造完成了大量重型工作：它会在后台创建一个OpenSearch Serverless集合（如果不存在），配置网络和加密策略，创建向量索引，并设置一个持续同步的S3数据源。当你在桶中上传新的PDF、TXT或HTML文件时，Bedrock服务会自动将其处理并存入向量索引。 COHERE_EMBED_ENGLISH_V3 是一个在多语言和垂直领域表现都很好的嵌入模型，对于英文文档是可靠的选择。

第三步：创建聊天机器人并关联知识库 这是最核心的一步，我们将创建 ChatBot 构造。

    // 创建一个DynamoDB表来存储聊天历史，实现多轮对话上下文
    const chatHistoryTable = new dynamodb.Table(this, ‘ChatHistoryTable’, {
      partitionKey: { name: ‘sessionId’, type: dynamodb.AttributeType.STRING },
      sortKey: { name: ‘timestamp’, type: dynamodb.AttributeType.NUMBER },
      billingMode: dynamodb.BillingMode.PAY_PER_REQUEST,
      timeToLiveAttribute: ‘ttl’, // 设置TTL自动清理过期会话
    });

    // 创建ChatBot，这是我们的服务器端应用核心
    const customerServiceBot = new ChatBot(this, ‘CustomerServiceBot’, {
      model: BedrockFoundationModel.ANTHROPIC_CLAUDE_3_HAIKU,
      modelProps: {
        maxTokens: 1024,
        temperature: 0.2, // 较低的温度，让回答更稳定、可靠
      },
      knowledgeBase: knowledgeBase, // 关联我们创建的知识库
      chatHistory: {
        table: chatHistoryTable,
        // 定义DynamoDB表中存储消息的字段名
        messageIdField: ‘messageId’,
        sessionIdField: ‘sessionId’,
        userIdField: ‘userId’,
        textField: ‘text’,
        timestampField: ‘timestamp’,
      },
      streaming: true, // 启用流式响应，提升用户体验
      // 可以自定义系统提示词，引导AI行为
      systemPrompt: `你是一个专业、友好、高效的电商客服助手。你的主要职责是依据公司提供的知识库，准确回答关于退货政策的问题。如果知识库中没有明确信息，请如实告知用户“根据现有资料，我无法找到该问题的确切答案，建议您联系人工客服进一步咨询。”严禁编造政策。回答请简洁、清晰，使用中文。`,
    });

这段代码创建了一个功能完整的聊天机器人后端。关键点在于：

1. 关联知识库 ：通过 knowledgeBase 参数，机器人获得了检索增强生成（RAG）的能力。当用户提问时，它会先从知识库中检索相关片段，再结合这些上下文生成回答。
2. 对话历史 ：通过 chatHistory 配置，机器人可以将对话上下文存储到DynamoDB。 sessionId 用于区分不同对话， userId 可用于区分用户（如果前端传递了该信息）。这使机器人能理解上下文，进行连贯的多轮对话。
3. 系统提示词 ： systemPrompt 是控制AI行为的“宪法”。这里我们明确界定了它的角色、职责、知识边界和回答风格。一个好的系统提示词能极大提升回答的准确性和安全性。
4. 流式响应 ： streaming: true 使得API能够以流的形式返回AI生成的token，前端可以逐字显示，用户体验远优于等待整个回答生成完毕。

第四步：为前端输出API端点 最后，我们需要将API Gateway的端点输出，以便前端应用调用。

    // 输出API Gateway的URL，前端应用将调用这个地址
    new cdk.CfnOutput(this, ‘ChatBotApiEndpoint’, {
      value: customerServiceBot.api.url,
      description: ‘The URL of the ChatBot API Gateway endpoint’,
    });
  }
}

至此，栈的定义就完成了。整个代码大约50行，但背后部署的资源涉及十多个AWS服务，并配置了数十条IAM策略。这就是CDK和高级构造库的威力。

3.3 部署、测试与数据灌入

保存代码后，在项目根目录下进行部署：

# 合成CloudFormation模板，检查是否有错误
cdk synth
# 显示将要创建或变更的资源，确认无误
cdk diff
# 开始部署
cdk deploy

部署过程可能需要10-15分钟，因为Bedrock知识库和OpenSearch Serverless集合的创建相对耗时。部署成功后，命令行会输出 ChatBotApiEndpoint 的URL。

测试API 你可以使用 curl 或 Postman 进行测试。API通常接受一个JSON请求体：

curl -X POST “https://your-api-id.execute-api.region.amazonaws.com/prod/” \
  -H “Content-Type: application/json” \
  -d ‘{
    “sessionId”: “test-session-123”,
    “userId”: “user-001”,
    “message”: “请问商品退货的期限是多久？”
  }’

如果启用了流式响应，你可能需要使用支持Server-Sent Events (SSE)的客户端来接收数据块。

灌入知识库数据 部署完成后，知识库是空的。你需要将退货政策的PDF文档上传到之前创建的S3桶中。上传后，Bedrock服务会自动开始处理。你可以通过AWS控制台进入Bedrock的“知识库”页面，查看数据源同步状态，直到显示“就绪”。之后，你的机器人就能基于这些文档内容进行回答了。

4. 高级场景与定制化开发

基础机器人搭建好后，你可能会遇到更复杂的需求。构造库提供了一定的扩展性，但有时也需要“跳出”框架进行定制。

4.1 自定义Lambda函数逻辑

ChatBot 构造生成的Lambda函数处理逻辑是固定的：接收请求 -> 检索知识库 -> 调用Bedrock -> 返回响应。如果你想在调用模型前对用户输入进行预处理（如敏感词过滤、意图识别），或者在模型响应后进行后处理（如格式化、情感分析），就需要自定义Lambda代码。

构造库的 ChatBot 构造暴露了底层的Lambda函数对象 lambdaFunction 。你可以通过CDK的 Code.fromAsset 方法，用自己的代码覆盖默认的Lambda处理程序。

// 假设你有一个自定义的Lambda处理函数代码在 `lambda` 目录下
import * as lambda from ‘aws-cdk-lib/aws-lambda’;

const customChatBot = new ChatBot(this, ‘CustomChatBot’, {
  // ... 其他配置
});

// 覆盖默认的Lambda代码
customChatBot.lambdaFunction.code = lambda.Code.fromAsset(‘lambda’);
customChatBot.lambdaFunction.handler = ‘index.handler’; // 你的handler函数

你需要自己编写Lambda函数，但依然可以复用构造库提供的上下文环境（如知识库ARN、模型ID等），它们会通过环境变量传递给函数。这给了你最大的灵活性，但也意味着你需要自己处理与Bedrock API的交互、流式响应等细节。

4.2 集成外部系统与工具调用

一个高级的客服机器人可能需要查询订单系统、库存数据库，或者发起一个退货工单。这可以通过两种方式实现：

方式一：在自定义Lambda中集成 这是最直接的方式。在你的自定义Lambda函数代码里，使用相应的SDK（如AWS SDK for DynamoDB, HTTP客户端）去调用其他服务或API。你需要确保Lambda函数的执行角色拥有调用这些服务的权限。

方式二：利用Bedrock Agents的“工具”概念 如果你希望AI模型能自主决定何时、调用何种工具，那么应该考虑使用Bedrock Agents。 generative-ai-cdk-constructs 库也提供了对Agents的初步支持（例如 BedrockAgent 构造）。你可以用CDK定义一个Agent，为其配置“工具”（本质上是一个Lambda函数），这个工具可以封装对订单系统的查询逻辑。当用户问“我的订单12345到哪里了？”，Agent可以自动调用这个工具来获取实时物流信息，再整合到回答中。这种方式更符合“智能体”的范式，但设置起来也更复杂。

4.3 成本优化与监控告警

生成式AI应用，尤其是调用大型语言模型（LLM），成本是一个重要考量。构造库本身不控制成本，但你可以通过CDK轻松添加监控和优化措施。

成本优化

1. 模型选型 ：在POC阶段使用 Haiku 或 Sonnet ，在生产流量稳定后再评估是否需要 Opus 。不同模型的价格差异可达10倍以上。
2. 缓存 ：对于常见、重复的问题，可以在API Gateway或Lambda层添加缓存（如使用Amazon ElastiCache for Redis），直接返回缓存结果，避免重复调用昂贵的Bedrock推理。
3. 知识库优化 ：优化文档质量，避免冗余。使用高效的嵌入模型（如 Cohere Embed ）和适当的块大小、重叠度，以提高检索精度，减少送入模型的无关上下文（token）。
4. 设置用量预算 ：在AWS Budgets中为Bedrock服务设置月度成本预算，并配置警报。

监控与告警 CDK可以方便地创建CloudWatch仪表盘和警报。

import * as cloudwatch from ‘aws-cdk-lib/aws-cloudwatch’;
import * as actions from ‘aws-cdk-lib/aws-cloudwatch-actions’;
import * as sns from ‘aws-cdk-lib/aws-sns’;

// 创建SNS主题用于发送告警
const alarmTopic = new sns.Topic(this, ‘ChatBotAlarmTopic’);

// 监控Lambda函数错误
const lambdaErrorAlarm = customerServiceBot.lambdaFunction.metricErrors().createAlarm(this, ‘LambdaErrorAlarm’, {
  threshold: 1,
  evaluationPeriods: 1,
  datapointsToAlarm: 1,
});
lambdaErrorAlarm.addAlarmAction(new actions.SnsAction(alarmTopic));

// 监控Bedrock调用延迟
// 注意：Bedrock的详细指标可能需要通过CloudWatch Logs Insights或自定义指标来获取

你还可以监控API Gateway的4XX/5XX错误、DynamoDB的读/写容量等。全面的监控是生产系统稳定的基石。

5. 常见陷阱、调试技巧与经验之谈

在实际使用这个构造库和构建生成式AI应用的过程中，我踩过不少坑，也总结了一些调试技巧。

5.1 部署与权限问题排查

问题1：部署失败，提示“OpenSearch Serverless collection creation failed” 这通常是由于服务相关角色权限或网络设置问题。首先确保你部署的AWS区域和账户，已经开通了OpenSearch Serverless服务。其次，检查构造库自动创建的IAM角色（名称通常包含 BedrockKnowledgeBaseExecutionRole ）是否具有 aoss: 相关权限。有时需要等待几分钟让IAM策略完全生效。最彻底的排查方式是查看CloudFormation栈事件的详细错误信息，并去IAM控制台核实角色策略。

问题2：Lambda函数超时或无法调用Bedrock 默认Lambda超时时间是3秒，对于LLM调用来说太短。你需要在创建 ChatBot 后，手动调整其Lambda函数的配置：

customerServiceBot.lambdaFunction.timeout = cdk.Duration.seconds(30);

如果Lambda部署在VPC内且无法访问互联网，会导致调用Bedrock API失败。确保VPC配置了NAT网关，或者为Bedrock创建了VPC端点。

问题3：知识库状态一直显示“处理中” 数据同步需要时间，特别是大型文档。首先在S3桶确认文件已上传成功。然后去Bedrock控制台的知识库页面，查看数据源同步详情和错误日志。常见原因包括：文件格式不支持、文件加密、或者嵌入模型在该区域不可用。确保你使用的嵌入模型（如 Cohere Embed ）在你部署的区域已获得访问权限（需要在Bedrock控制台中手动启用模型）。

5.2 应用层问题与效果调优

问题4：机器人回答“我不知道”，但知识库明明有相关内容 这是RAG系统最常见的问题。可能的原因和解决方案：

1. 检索不到 ：调整知识库的检索参数。 BedrockKnowledgeBase 构造允许配置 retrievalConfiguration ，比如可以调整返回的相似性搜索结果数量（ numberOfResults ，默认5个），或者尝试不同的相似性搜索类型（ semanticSearch vs hybridSearch ）。有时增加返回的片段数量能改善效果。
2. 检索到但不相关 ：问题可能出在文档处理和嵌入阶段。检查原始文档是否清晰（扫描的PDF可能效果差），尝试调整文本拆分（chunking）的大小和重叠度。目前构造库使用的是默认拆分策略，如果效果不佳，可能需要预处理文档（如手动分段）后再上传。
3. 提示词问题 ：系统提示词没有明确指令模型“必须基于检索到的上下文回答”。强化你的 systemPrompt ，例如：“请严格根据提供的‘参考上下文’来回答问题。如果上下文中的信息不足以回答问题，请直接说‘根据现有资料，无法回答此问题’。不要使用上下文之外的知识。”

问题5：回答包含幻觉或与知识库内容矛盾 这是LLM的固有问题，在RAG中可缓解但无法根除。除了优化提示词，还可以在架构上增加一个“答案验证”层。例如，在Lambda函数中，先让模型根据上下文生成答案，再调用同一个模型（或一个小模型）对答案进行验证：“请判断以下‘答案’是否严格基于提供的‘上下文’。只回答‘是’或‘否’。”如果验证不通过，则返回一个安全回复。

问题6：流式响应在前端显示异常 确保你的前端正确处理了Server-Sent Events (SSE)或HTTP流。API Gateway返回的流式响应有特定的格式。检查网络请求的响应头是否包含 Content-Type: text/event-stream 。一个常见的错误是前端没有正确处理分块数据，导致整个响应被缓冲到最后才显示。使用标准的EventSource API或Fetch API的流式读取功能。

5.3 维护与演进建议

1. 版本锁定 ：在 package.json 中锁定 @cdklabs/generative-ai-cdk-constructs 的版本。这是一个快速发展的库，API可能发生变化。使用固定版本（如 “1.2.0” ）可以保证部署的确定性。
2. 基础设施分离 ：考虑将知识库、向量存储等数据层基础设施与无服务器的应用层（ChatBot）部署在不同的CDK栈中。这样，更新机器人逻辑时，不会影响到已有的知识数据。
3. 蓝绿部署 ：对于生产环境的ChatBot，可以利用API Gateway的阶段（Stage）和Lambda别名（Alias）来实现蓝绿部署，在不中断服务的情况下进行版本更新。
4. 关注Bedrock模型更新 ：AWS会不断更新和发布新的Bedrock模型。定期评估是否有更适合你用例的新模型（在成本、性能、能力上）。切换模型通常只需要修改构造中的一个模型ID，但务必进行充分的测试，因为不同模型的行为可能有差异。

这个构造库极大地简化了在AWS上启动生成式AI应用的过程，但它不是一个“黑盒”。理解其背后的资源构成、掌握基本的调试方法、并根据业务需求进行适度定制，才能让它真正成为你团队的生产力加速器。从简单的内部助手开始，逐步扩展到更复杂的客户面向应用，这条路径已经被许多团队验证是可行且高效的。