---
source_url: https://aws.amazon.com/cn/blogs/china/ai-understanding-component-library-intelligent-d2c-architecture-aws-kiro-mcp-skills/
publish_date: 2025-12-08
title: 让 AI 理解你的组件库：新一代智能 D2C架构 — 基于 AWS Kiro MCP Skills 的智能转换实践 | 亚马逊AWS官方博客
review_value: 8
review_confidence: 8
review_recommendation: neutral
ingested: 2026-05-16
tags: [aws-china-blog, kiro]
sha256: 3c15da5fb3eb30d7824383faa95a3e4fcee8dc6b2d87be4a381a6d2e66c332a8
---
# 让 AI 理解你的组件库：新一代智能 D2C架构 — 基于 AWS Kiro MCP Skills 的智能转换实践 | 亚马逊AWS官方博客
让 AI 理解你的组件库：新一代智能 D2C架构 — 基于 AWS Kiro MCP Skills 的智能转换实践 by awschina on 08 12月 2025 in Case Study Permalink Share 摘要 随着企业级前端开发的复杂度不断提升，设计到代码（Design-to-Code, D2C）工具虽然能够自动生成代码，但往往无法理解和利用企业内部的组件库。本文探讨了如何利用 AWS Kiro IDE、Model Context Protocol (MCP) 和 Skills 构建新一代智能 D2C 平台。核心创新在于通过 Skills 将组件知识封装为可调用工具 ，结合 Steering 策略引导，使 AI 能够自动发现、理解并正确使用企业组件库。我们成功将组件库利用率从接近 0% 提升到 80% 以上，开发时间从数小时缩短到数分钟。 背景 传统 D2C 工具的核心缺陷 无法理解企业组件库 ：只能生成基础的 HTML/CSS 代码，无法识别设计中应该使用哪些企业级组件 缺乏上下文理解 ：无法理解设计的业务语义和 UI 标签的含义 缺少决策能力 ：即使提供了组件库，也无法智能判断在什么场景下使用哪个组件 D2C 的核心挑战 组件发现问题 如何让 AI 知道企业组件库中有哪些可用组件？ 如何动态获取组件的 API 文档和使用规范？ 当组件库更新时，如何避免手动更新 AI 的知识库？ 智能选择问题 如何根据设计稿自动识别应该使用哪些组件？ 如何理解 UI 标签的语义（单选 vs 多选 vs 批量操作）？ 如何在多个相似组件之间做出正确选择？ 质量保证问题 如何确保生成的代码符合企业规范？ 如何实现像素级的视觉还原？ 如何自动验证生成代码的功能正确性？ 新一代智能D2C 平台设计 基于 AWS Kiro 的实践经验，我们总结出的核心设计理念是： 将组件知识封装为 Skills ，通过 MCP 协议让 AI 可调用，用 Steering 控制调用策略 。这种”知识工具化”的方法，让 AI 能够像调用 API 一样使用组件库。 整体架构： D2C 工作流： 用户请求："根据设计稿生成代码" ↓ 【STEP 1】获取设计内容 • 调用设计工具 MCP 获取设计图和结构信息 • 支持 Figma/Pixso/Sketch 等多种设计工具 • 输出产物：design_spec.json（设计元数据）、design_image.png（设计截图） ↓ 【STEP 2】分析设计需求 • AI 分析设计图中的 UI 元素 • 识别功能需求和交互模式 • 理解 UI 标签的业务语义 • 输出产物：ui_analysis.json（UI 元素列表、标签语义、交互模式） ↓ 【STEP 3】发现并匹配组件 • 调用 Skills 元数据服务发现所有可用组件 • 调用组件选择 Skill 获取决策树和映射规则 • 根据设计需求匹配最合适的组件 • 输出产物：component_mapping.json（组件匹配结果、匹配理由） ↓ 【STEP 4】获取组件规范 • 调用具体组件 Skill 获取 API 文档 • 理解组件的 Props、Methods、Events • 获取使用示例和最佳实践 • 输出产物：component_configs.json（组件配置参数） ↓ 【STEP 5】生成代码 • 优先使用组件库实现 UI 元素 • 仅对无匹配组件的部分自定义实现 • 遵循企业代码规范和架构模式 • 输出产物：src/ 目录（Vue/React 组件代码） ↓ 【STEP 6】自动验证 • 安装依赖并启动开发服务器 • 使用自动化测试工具验证功能和视觉 • 发现问题自动修复，迭代优化 • 输出产物：test_report.json（测试结果）、screenshots/（验证截图） 流程控制特性 ： 通过 Steering 文件配置自主执行模式，AI 会自动完成所有步骤，不会中途询问确认。 核心技术模块 模块一：Skills – 组件知识的工具化封装 核心创新：将组件知识转化为 AI 可调用的工具 传统方法的问题：在提示词中描述组件 API（Token 消耗大）、硬编码组件列表（更新需手动同步）、AI 无法理解使用场景（选择错误）。 Skills 解决方案： 每个组件封装为独立 Skill ，通过 MCP 协议暴露给 AI Skill 的设计原则： 专用而非通用 ：一个 Skill 对应一个组件，而非返回所有组件 API 的通用工具。优势：精准、Token 低、易维护。 渐进式披露 ：两层按需加载，基于 MCP tool 机制 第一层 – Tool Description （元数据）： 包含在 MCP tool description 中（tools/list 返回） 格式：文件路径 + Skill Description（frontmatter 字段） AI 快速扫描所有可用组件，Token 消耗 ~50-100 **第二层 – SKILL.md Content**（~200 行）： 通过 tool call 返回完整 markdown 内容（去除 frontmatter） 包含：概述、识别指南、决策表、Quick API Reference 可选引用 references/ 详细文档路径，AI 自行读取 Token 消耗 ~200-500 per Skill AI 工作流：扫描 tool descriptions → 选 2-3 个相关 Skill → 调用 tool 获取 SKILL.md → （可选）读取 references/ **3. 决策树驱动**：提供明确的决策路径，避免 AI 主观臆断。 识别设计稿中的选择场景： ├─ 选择数量 ≤ 5 项？ │ ├─ 是 → 表单字段？ → use-dropdown-selector │ │ 独立功能？ → use-modal-selector │ └─ 否 → use-modal-selector（批量选择） Skill 的核心结构示例： --- name: use-dropdown-selector description: 适用于 1-5 项的单选/多选场景 --- # Dropdown Selector 配置指南 ## 组件概述 用于小规模选择（1-5 项）的下拉选择组件，支持单选和多选模式。 ## Design-to-Implementation Workflow ### Step 1: 从设计稿识别需求 - 视觉指标：下拉框、选择标签、预期 1-5 项 - 上下文：表单字段、非批量操作 ### Step 2: 分析配置需求 | 设计特征 | 配置 | 示例标签 | | 单个值 | mode: 'single' | "负责人"、"创建人" | | 多个值 | mode: 'multiple' | "协作人"、"审批人" | ### Step 3: 输出格式 { "component": "DropdownSelector", "props": {...} } ## Quick API Reference [核心 Props 速查表] ## 详细文档 - references/api_reference.md - 完整 API - references/code_examples.md - 代码示例 Skills 的动态发现机制 传统做法的问题： 在 Steering 中硬编码组件列表 → 新增组件需手动更新所有文档 列表过长消耗大量 Token → AI 每次都要处理完整列表 无法获取最新 API → 组件更新后文档不同步 // Step 0: AI 调用 MCP tools/list（自动发现所有 Skills） await mcp.call("tools/list"); // 返回格式（基于 agent-skills-mcp） { "tools": [ { "name": "get_skill_use_dropdown_selector", "description": "Returns skill file: ~/skills/use-dropdown-selector/SKILL.md\n\n## Skill Description\n适用于 1-5 项的单选/多选场景" }, { "name": "get_skill_use_modal_selector", "description": "Returns skill file: ~/skills/use-modal-selector/SKILL.md\n\n## Skill Description\n适用于 5+ 项的批量选择场景" }, { "name": "get_skill_use_info_card", "description": "Returns skill file: ~/skills/use-info-card/SKILL.md\n\n## Skill Description\n用户信息悬浮卡片" } ] } // Step 1: AI 根据设计需求调用具体 Skill await mcp.call("tools/call", { name: "get_skill_use_dropdown_selector" }); // 返回完整 SKILL.md 内容（去除 frontmatter） **关键优势**： ✅ **动态发现**：新增组件无需修改任何配置，AI 自动感知 ✅ **Token 优化**：只在需要时查询，避免每次携带完整列表 ✅ **职责清晰**：元数据提供概览，Skill 提供详细规范 component-selection 元 Skill 的特殊作用 这是一个”元 Skill”，帮助 AI 从组件库中选择最合适的组件： # Component Selection Skill ## Workflow 获取可用 Skills → 分析设计 → 匹配组件 → 返回结果 ## Decision Logic（决策树） 用户选择场景： ├─ 1-5 人 → DropdownSelector │ ├─ 单选 → single=true │ └─ 多选 → multiple=true └─ 5+ 人 → ModalSelector ## Semantic Mapping（语义映射） | 标签 | 组件 | | "负责人"、"创建人" | DropdownSelector (single) | | "协作人"、"审批人" | DropdownSelector (multiple) | | "批量添加"、"批量选择" | ModalSelector | ## Output {"skill": "use-dropdown-selector", "reason": "...", "props": {...}} 为什么 Skills 方法优于传统方法？ 传统 D2C 平台的致命缺陷： 硬编码组件知识 问题：在系统 Prompt 中列举所有组件 API 后果： 新增组件需要更新多处配置 Prompt 过长导致 Token 消耗巨大 AI 难以准确匹配大量信息 真实案例：某企业组件库 50+ 组件，Prompt 超过 10000 tokens 静态知识库 问题：组件 API 文档更新后，AI 使用的仍是旧版本 后果：生成的代码使用已废弃的 API，导致运行时错误 维护成本：每次组件更新需要手动同步文档到 AI 知识库 Skills 动态知识系统的优势 A B C 1 维度 硬编码方案 Skills 方案 2 Token 成本 10000+ tokens/请求 500 tokens/请求 3 新增组件 更新 5+ 处配置 零配置（自动发现） 4 API 同步 手动更新知识库 实时获取最新文档 5 维护成本 高（多处重复维护） 低（单一数据源） 6 扩展性 差（Prompt 长度限制） 好（按需加载） Skills 设计的关键原则：运行时优化 **关键优势**： ✅ Token 消耗降低 ✅ 按需加载 + 渐进式披露 ✅ 每个 Skill 独立测试和更新 Skill 是 Model Context Protocol (MCP) 定义的标准化能力封装格式，正在被越来越多的 AI 工具所支持。通过采用这一开放标准，Kiro 不仅能够与其他工具实现互操作，还为 D2C 工作流预留了扩展空间——未来可以无缝集成支持 Skill 标准的其他工具和能力，而无需重新开发适配层。这种标准化的互操作性就像 MCP 协议一样，它降低了生态系统的集成成本，让开发者能够专注于核心能力的打磨，而不是在各种私有格式之间疲于转换。 模块二：AWS Kiro 与 Steering – 策略驱动的 AI 编程 AWS Kiro IDE 核心能力 AWS Kiro 是亚马逊云科技推出的 AI 原生集成开发环境，其核心特性包括： **MCP 原生支持**：通过 Model Context Protocol 集成外部工具和服务，使 AI 能够调用设计工具、测试框架、组件库等 **Steering 策略引擎**：通过声明式配置文件控制 AI 行为，实现企业级规范约束 **自主执行模式**：AI 可完全自主完成复杂任务，无需频繁人工确认 **上下文感知**：理解项目结构、技术栈、业务逻辑，提供针对性建议 Steering 文件：AI 行为的策略控制器 Steering 是 Kiro 的独特功能，通过 `steering/` 目录下的 Markdown 文件定义 AI 的决策规则。与传统 Prompt 相比，Steering 具有以下优势： A B C 1 对比维度 传统 Prompt Steering 文件 2 持久性 每次对话需重复输入 自动加载，持续生效 3 结构化 自然语言，难以维护 声明式配置，清晰可控 4 优先级控制 无法强制执行 支持 HIGHEST PRIORITY 等标记 5 团队协作 难以共享和版本管理 Git 管理，团队共享 Steering 的三层结构 .kiro/steering/ ├── tech.md ← 技术栈约束和架构规范 ├── product.md ← 产品需求和业务规则 └── structure.md ← 项目结构和文件组织 tech.md 示例（技术规范） ## Core Tech Stack (MANDATORY) Framework: [您的框架] (Vue3/React/Angular) Component Library: [您的组件库] Build Tool: [您的构建工具] Styling: [您的样式方案] ## Component Library First (HIGHEST PRIORITY) CRITICAL: 本项目的首要目标是使用现有组件库。 ALWAYS 优先使用组件库而非自定义实现。 ## Code Standards - 使用 TypeScript 严格模式 - 遵循 [您的代码规范] - 组件命名采用 PascalCase Steering 的工作机制 **加载时机**：Kiro 启动时自动加载 `.kiro/steering/` 下所有 Markdown 文件 **优先级处理**： `HIGHEST PRIORITY` 标记的规则优先级最高 `MANDATORY`、`CRITICAL`、`REQUIRED` 标记强制执行 `DO NOT`、`NEVER` 标记为禁止项 **动态更新**：修改 Steering 文件后，Kiro 会在下次对话中应用新规则 Kiro + Steering + Skills 协同工作流程 用户："根据设计稿生成代码" ↓ Kiro 读取 Steering（tech.md + product.md + structure.md） ↓ STEP 0: 调用 Skills 元数据服务（MCP） ↓ STEP 1-2: 获取设计并分析（Steering 规则） ↓ STEP 3: 调用 component-selection Skill ↓ STEP 4-6: 生成代码并验证（强制组件库优先） **Steering 对 D2C 的关键价值**：避免工具选择歧义、强制企业规范、控制 AI 行为、知识传承和团队协作 Kiro 在 D2C 场景中的独特价值 自主执行能力 传统 AI 助手：每一步都需要用户确认 → 效率低下 Kiro + Steering：配置 AUTONOMOUS MODE 后完全自主执行 6 步流程 效果：从 30 分钟（频繁交互）缩短到 2-5 分钟（全自动） MCP 生态集成 设计工具 MCP（Figma/Pixso）：自动获取设计稿 Skills MCP：动态发现和调用组件知识 测试工具 MCP（Playwright）：自动验证生成的代码 所有工具通过统一的 MCP 协议集成，AI 可自主编排调用 企业规范强制执行 场景：AI 生成代码时可能忽略组件库，直接写 HTML/CSS Steering 方案：`## Component Library First (HIGHEST PRIORITY)` 标记强制 AI 优先使用组件库 结果：组件库利用率从 20% 提升到 90% 模块三：MCP 协议 – 工具标准化接口 MCP (Model Context Protocol) 是 Anthropic 推出的标准化工具集成协议，也是 AWS Kiro 的核心扩展机制： **Skills 作为 MCP Server 实现**：每个 Skill 通过 MCP 协议暴露为标准化工具 **Kiro AI 通过 MCP 协议调用 Skills**：发现、查询、执行 Skills **支持动态发现**：无需预先配置，AI 自动感知新增工具 **标准化接口**：统一的工具描述格式，便于 AI 理解和调用 技术实施与部署 MCP Server + Kiro Steering Skills MCP Server 配置 使用 agent-skills-mcp 开源工具，支持 Python 部署 // .kiro/mcp.json - Kiro 配置文件 { "mcpServers": { "skills": { "command": "uvx", "args": ["agent-skills-mcp"], "env": { "SKILL_FOLDER": "~/skills" } }, "design-tool": { "command": "python", "args": ["-m", "pixso_mcp_server"], }, "playwright-test": { "command": "npx", "args": ["@playwright/mcp-server"] } } } Skills设置 skills/ ├── components/ ← 组件 Skills │ ├── use-dropdown-selector/ │ │ ├── SKILL.md ← AI 首先读取 │ │ └── references/ │ │ ├── api_reference.md │ │ └── code_examples.md │ ├── use-modal-selector/ │ └── use-info-card/ │ ├── patterns/ ← 模式 Skills │ ├── component-selection/ ← 组件选择决策引擎 │ │ └── SKILL.md ← 语义映射表 + 决策树 │ └── form-generation/ ← 表单生成模式 │ └── tools/ ← 工具 Skills └── component-doc-generator/ ← 自动生成组件文档 **关键优势**： ✅ **零配置发现**：新增 Skill 只需放入 skills/ 目录，MCP Server 自动感知 ✅ **独立进程**：MCP Server 崩溃不影响 Kiro IDE ✅ **开源可扩展**：基于 agent-skills-mcp，支持自定义 Skill 格式 Kiro Steering 设置 .kiro/steering/ ├── tech.md ├── product.md └── structure.md 触发与集成 触发方式 **Pixso 插件**：在 Pixso 中选中元素 Kiro 命令触发 # 在 Kiro IDE 中输入 根据选中的 Pixso 内容生成设计代码 结论 通过构建基于 AWS Kiro、MCP 和 Skills 的智能 D2C 平台，我们成功解决了以下核心问题： 组件库理解 ：Skills 元数据系统实现动态发现，组件库利用率提升到 ~90% 智能选择 ：组件选择 Skill 提供决策树和语义映射，根据上下文自动选择最合适组件 质量保证 ：Steering 文件强制执行企业规范，自动化测试验证功能和视觉，AI 自主修复问题 开发效率 ：从设计到可运行代码从数小时缩短到数分钟，自主执行模式减少人工干预 架构优势 可扩展性 ：新增组件无需修改核心代码，MCP 独立部署，元数据系统支持动态扩展 可维护性 ：三层架构职责清晰，Steering 集中管理策略，MCP 标准化便于测试 智能化 ：AI 自主发现工具、理解上下文、决策过程可追溯 成本优化 ：元数据按需查询节省 Token，专用 Skill 避免传递完整历史 这套设计模式具有良好的通用性，可适配不同设计工具（Figma、Sketch 等）、前端框架（React、Vue、Angular 等）和组件库，为企业前端开发提供基础设施支撑。 总结与展望 本文介绍的不仅仅是一个D2C工具的实现，更重要的是，它揭示了一个构建可靠、可控、可扩展的企业级AI应用的通用设计模式。这个模式带来了4大核心观念的转变： 从“提示工程”到“AI系统工程” ：开发者的角色正在发生变化。我们的工作不再是“写好一个完美的Prompt”，而是转变为“设计一个由AI、工具(Skills)和规则(Steering)组成的稳定系统”。正如我们看到的，通过md, product.md和structure.md对AI进行结构化约束，就是“AI系统工程”的最佳实践，它允许多角色协作，共同构建一个可靠的AI系统。 从“静态知识库”到“动态工具调用” ： 知识工具化 是这场革命的核心。通过 tools/list 这样的动态发现机制，AI可以在运行时按需调用外部工具来获取最新知识。这从根本上解决了大型语言模型知识更新不及时、扩展性差的核心痛点。 从“黑盒化决策”到“白盒化控制” ：通过可读性极强的Steering文件和内置决策树的Skills，AI的决策过程变得更加透明、可追溯。我们可以清晰地知道AI为何做出某个选择，并能通过修改规则来精确控制它的行为，使其决策始终符合企业规范。 从 “ 辅助编程” 到 “ 自主研发单元” ：开发者将不再是编写每一行代码的人，而是 “AI 行为的设计师” 。开发者的工作重点将从 编写 React 组件 转移到 编写 Steering 策略 和 定义 Skills 边界。由于 AI能够自主完成 Step 1-6 ，人类的角色将彻底转变为 Architect (架构师) 和 Reviewer (审核者)。 基于这些洞察，我们可以预见未来的几个技术发展方向： 方向 一：知 识 即工具 (Knowledge as a Tool) 过去我们把文档喂给 RAG（检索增强生成），现在我们将文档封装为 Skills 。这标志着 AI 对知识的使用方式从 “ 模糊 检 索 “ 转向了 “ 精确 调 用 “ 。MCP 协议让知识具有了”接口”，这解决了大模型在垂直领域（Domain Specific）落地的关键最后一公里问题。 方向 二： 设计资产 的 语义 化 (Semantic D2C) 强调该方案不仅是生成代码，更是 语义对齐 。通过 component-selection Skill ，系统实际上是在进行”设计语言”到”工程语言”的翻译（例如：将设计稿的”多选负责人”翻译为 DropdownSelector(mode=’multiple’)）。这比单纯的代码生成更有价值，因为它保持了业务逻辑的一致性。 方向 三：代 码 治理的左移 (Governance Shift Left) 利用 Steering Files ，企业将代码规范、架构约束从 Code Review 阶段提前到了 Code Generation 阶段。这是 AI 时代的 “Compliance as Code” ( 合 规 即代 码 ) 的最佳实践。 通过AWS Kiro、MCP和Skills构建的智能D2C平台的实践，指明了一条通往更强大、更可靠的AI原生应用的道路。我们鼓励每一位开发者思考如何将“知识工具化”的理念应用到自己的工作中，去构建真正能够解决复杂问题的下一代智能应用。 参考资料 AWS Kiro 官方文档 Model Context Protocol (MCP) 规范 Claude Code Skills 文档 *前述特定亚马逊云科技生成式人工智能相关的服务目前在亚马逊云科技海外区域可用。亚马逊云科技中国区域相关云服务由西云数据和光环新网运营，具体信息以中国区域官网为准。 本篇作者 邓冠群 AWS 快速原型解决方案架构师，在机器学习领域有多年工作经验，在目标检测，OCR，AIGC 等方向有丰富的算法开发以及落地实践经验。 刘知言 AWS 资深原型解决方案架构师，FDE 工程师。 杨振轩 亚马逊云科技快速原型团队资深项目经理，负责协调团队资源进行客户原型项目交付。项目的技术方向包括，大数据平台，Agentic /LLM 系统工程化落地，应用现代化改造和边缘计算。 梁一鸣 亚马逊云科技解决方案架构师，致力于云计算方案架构设计、应用和推广。具有 15 年 IT 行业工作经验，擅长开发与数据灾备保护领域，历任软件开发工程师，项目经理，系统架构师。在加入AWS之前，曾服务于 EMC、Microsoft 等公司。