基于MCP协议构建STIBO STEP主数据AI助手：原理、部署与实战

1. 项目概述与核心价值

最近在折腾企业数据治理和系统集成时，我遇到了一个挺有意思的项目：akash25de/stibo-step-mcp-server。乍一看这个仓库名，熟悉STIBO STEP平台的朋友可能会心一笑，而对于不熟悉的朋友，可能会觉得这串字符有点“劝退”。别急，让我用大白话给你拆解一下。简单来说，这是一个为STIBO STEP主数据管理平台打造的MCP服务器。MCP，也就是模型上下文协议，你可以把它理解为一个“翻译官”或者“适配器”。它的核心任务，是让像STIBO STEP这样功能强大但相对“传统”的企业级系统，能够无缝接入到现代AI驱动的开发工作流中，比如直接与Claude、Cursor这类智能编程助手对话，让AI帮你查询、分析甚至操作主数据。

为什么这件事有价值？想象一下，你是一个数据管理员或者开发工程师，每天需要频繁登录STIBO STEP的Web界面，通过复杂的菜单导航去查找一个产品的分类属性，或者验证一条供应商信息的合规性。这个过程繁琐、重复，而且容易出错。现在，通过这个MCP服务器，你可以在自己熟悉的代码编辑器或命令行里，直接用自然语言向AI助手提问：“帮我找出所有状态为‘活跃’且最近三个月有更新的供应商记录”，AI通过MCP服务器“翻译”你的指令，调用STIBO STEP底层的API，把结果清晰地带回来。这不仅仅是效率的提升，更是工作模式的革新，将主数据管理从手动操作变成了可编程、可自动化的数据服务。

这个项目由开发者akash25de开源，它瞄准了一个非常具体的痛点：如何释放企业核心数据资产（主数据）的潜能，让其融入快速迭代的AI辅助开发生态。对于正在实施或已经使用STIBO STEP的企业技术团队、系统集成商以及对主数据治理自动化感兴趣的开发者而言，这是一个极具前瞻性的工具。它不只是封装了几个API调用，更提供了一种将重型ERP/MDM系统“轻量化”、“智能化”接入的可行思路。接下来，我将从设计思路、实操部署、核心功能实现到避坑指南，为你完整拆解这个项目。

2. 项目整体架构与设计思路拆解

2.1 为什么选择MCP协议作为桥梁？

要理解这个项目，首先得弄明白MCP协议是什么，以及它为什么是连接STIBO STEP和AI助手的最佳选择。MCP不是一个具体的软件，而是一套开放协议标准，定义了AI应用（客户端）如何发现、调用外部工具和服务（服务器）。你可以把它类比成USB协议：你的电脑（AI客户端）通过标准的USB接口（MCP协议），可以连接键盘、鼠标、U盘（各种MCP服务器）而无需为每个设备重写驱动。

对于STIBO STEP这类系统，传统集成方式无外乎SOAP/REST API、文件导出导入或者直接数据库连接。但这些方式对AI助手并不友好：API需要复杂的认证和参数构造；AI无法直接理解其数据结构。MCP协议的价值就在于它做了“标准化抽象”：它将STIBO STEP的复杂功能（如查询产品、更新属性）封装成一个个带有清晰名称、描述和参数定义的“工具”。AI助手只需要知道“有一个叫search_products的工具，可以按名称搜索产品”，而无需关心这个工具背后是调用了STIBO STEP的哪个REST端点、认证头怎么加、返回的XML如何解析。

因此，akash25de/stibo-step-mcp-server的设计核心，就是实现MCP协议的服务端，将STIBO STEP的API“翻译”成MCP协议定义的标准化工具。这个选择非常聪明，它避免了为每一个AI客户端（Claude Desktop, Cursor, Windsurf等）单独开发插件，实现了“一次开发，多处使用”。只要客户端支持MCP，就能立即获得操作STIBO STEP数据的能力。

2.2 技术栈选型与项目结构解析

打开项目仓库，我们可以看到其技术栈清晰而现代：

• 语言: TypeScript。这保证了代码的类型安全，便于维护和扩展，尤其适合需要与复杂企业系统API打交道的场景。
• 运行时: Node.js。轻量、高效，拥有庞大的npm生态，方便集成各种HTTP客户端、认证库等。
• 核心依赖:
  • @modelcontextprotocol/sdk: 这是MCP协议的官方SDK，提供了构建MCP服务器所需的所有基础类、类型定义和通信逻辑。使用官方SDK能确保协议实现的正确性和兼容性。
  • 用于HTTP通信的客户端（如axios或node-fetch）: 用于实际调用STIBO STEP的REST API。
  • 认证相关库: 由于STIBO STEP通常采用OAuth 2.0、Basic Auth或API密钥认证，项目会集成对应的库来处理令牌获取、刷新等复杂逻辑。
• 项目结构通常如下：

  src/ ├── index.ts # 服务器主入口，初始化MCP服务器，注册工具和资源 ├── clients/ # STIBO STEP API客户端封装 │ └── step-client.ts # 封装所有与STIBO STEP API交互的细节 ├── tools/ # MCP工具定义 │ ├── product-tools.ts # 产品相关的工具，如search_products, get_product_details │ └── supplier-tools.ts # 供应商相关的工具 ├── resources/ # MCP资源定义（可选） │ └──># 1. 克隆项目 git clone https://github.com/akash25de/stibo-step-mcp-server.git cd stibo-step-mcp-server # 2. 安装依赖 npm install # 3. 复制环境变量示例文件并配置 cp .env.example .env

  现在，打开.env文件，填入你的STIBO STEP连接信息：

  # STIBO STEP 连接配置 STEP_BASE_URL=https://your-step-instance.example.com STEP_API_PATH=/api/rest/v1 STEP_AUTH_TYPE=oauth2 # 或 'apikey', 'basic' STEP_CLIENT_ID=your_client_id STEP_CLIENT_SECRET=your_client_secret STEP_TOKEN_URL=https://your-step-instance.example.com/oauth/token # MCP 服务器配置 MCP_SERVER_PORT=3000 MCP_SERVER_HOST=localhost # 是否启用写操作工具，默认false更安全 ENABLE_WRITE_TOOLS=false

  关键配置解析：

  • STEP_AUTH_TYPE: 决定了客户端使用哪种认证方式。项目代码中会根据这个变量来初始化不同的认证策略。
  • STEP_TOKEN_URL: 仅OAuth 2.0客户端凭证模式需要。用于自动获取和刷新访问令牌。
  • ENABLE_WRITE_TOOLS: 这是一个重要的安全开关。在开发和测试初期，强烈建议设置为false，只启用只读工具，避免误操作生产数据。

  3.3 运行、测试与连接AI客户端

  配置完成后，启动服务器：

  # 开发模式，使用ts-node或nodemon，便于热重载 npm run dev # 或者编译后运行 npm run build npm start

  如果一切顺利，终端会输出类似MCP Server running on ws://localhost:3000的信息。接下来，我们需要测试这个MCP服务器是否正常工作。

  使用官方测试工具： MCP SDK通常提供简单的测试客户端，或者你可以使用一个通用的MCP客户端测试工具。更直接的方式是将其配置到支持MCP的AI助手。

  以Claude Desktop为例：

  1. 找到Claude Desktop的配置文件位置（macOS通常在~/Library/Application Support/Claude/claude_desktop_config.json，Windows在%APPDATA%\Claude\claude_desktop_config.json）。
  2. 在配置文件中添加你的MCP服务器配置：

  { "mcpServers": { "stibo-step": { "command": "node", "args": [ "/absolute/path/to/your/stibo-step-mcp-server/build/index.js" ], "env": { "STEP_BASE_URL": "https://your-step-instance.example.com", "STEP_CLIENT_ID": "your_client_id", "...": "其他环境变量" } } } }

  3. 重启Claude Desktop。在聊天界面，你应该能看到新的工具出现（可能需要输入/查看工具列表）。尝试输入：“使用stibo-step工具，列出所有的产品数据模型。” 如果配置正确，Claude会调用MCP服务器，并返回从STIBO STEP获取的信息。

  实操心得：在配置AI客户端时，command和args的路径一定要使用绝对路径，相对路径很容易导致启动失败。另外，首次连接时，注意观察Claude Desktop或服务器的日志，认证失败、网络不通等错误信息会在这里清晰呈现。如果服务器启动但AI客户端看不到工具，检查MCP协议版本是否兼容。

  4. 核心工具实现与STIBO STEP API封装深度解析

  4.1 构建健壮的STIBO STEP API客户端

  MCP服务器的基石是一个可靠、易用的STIBO STEP API客户端。这个客户端需要处理认证、重试、错误处理和请求/响应数据的转换。我们来看一个简化的step-client.ts实现思路：

  // src/clients/step-client.ts import axios, { AxiosInstance, AxiosResponse } from 'axios'; import { AuthManager } from './auth-manager'; // 假设有一个处理认证的类 export interface StepEntity { id: string; name: string; type: string; // ... 其他动态属性 } export class StepClient { private client: AxiosInstance; private authManager: AuthManager; constructor(baseURL: string, authConfig: any) { this.authManager = new AuthManager(authConfig); this.client = axios.create({ baseURL, timeout: 30000, // 30秒超时 }); // 请求拦截器：自动添加认证头 this.client.interceptors.request.use(async (config) => { const token = await this.authManager.getAccessToken(); config.headers.Authorization = `Bearer ${token}`; return config; }); // 响应拦截器：统一错误处理 this.client.interceptors.response.use( (response) => response, async (error) => { if (error.response?.status === 401) { // 令牌可能过期，尝试刷新 const newToken = await this.authManager.refreshToken(); if (newToken) { error.config.headers.Authorization = `Bearer ${newToken}`; return this.client.request(error.config); // 重试原请求 } } // 将复杂的API错误转换为更友好的消息 const message = error.response?.data?.message || error.message; throw new Error(`STIBO STEP API Error: ${message}`); } ); } async searchEntities(entityType: string, query: string, filters?: Record<string, any>): Promise<StepEntity[]> { const response: AxiosResponse = await this.client.post('/search', { entityType, queryString: query, filters, maxResults: 50, // 限制单次返回数量 }); // 将STIBO STEP的响应结构映射为更通用的实体数组 return response.data.items.map((item: any) => ({ id: item._id, name: item.attributes?.name?.value, type: entityType, ...item.attributes, // 展开其他属性 })); } async getEntityDetails(entityType: string, entityId: string): Promise<StepEntity> { const response = await this.client.get(`/${entityType}/${entityId}`); return response.data; } // ... 其他方法：updateEntity, createDraft, listModels等 }

  关键点解析：

  • 认证封装：AuthManager类独立处理OAuth令牌的获取、刷新和存储，客户端无需关心细节。这是企业级集成稳定性的关键。
  • 拦截器：利用Axios拦截器，优雅地实现了自动添加令牌和全局错误处理。401自动重试机制能有效应对令牌过期问题，提升用户体验。
  • 数据映射：STIBO STEP的API返回的数据结构可能非常嵌套和复杂。在客户端层做一次“扁平化”或“标准化”映射，可以极大简化后续工具层的逻辑，让AI处理起来更简单。

  4.2 定义MCP工具：以产品搜索为例

  有了强大的客户端，定义MCP工具就水到渠成了。我们看看search_products工具是如何定义的：

  // src/tools/product-tools.ts import { Server } from '@modelcontextprotocol/sdk/server/index.js'; import { CallToolRequestSchema, Tool } from '@modelcontextprotocol/sdk/types.js'; import { StepClient } from '../clients/step-client.js'; export function registerProductTools(server: Server, stepClient: StepClient) { // 工具定义：搜索产品 const searchProductsTool: Tool = { name: 'search_products', description: '在STIBO STEP中根据产品名称、SKU或其他属性搜索产品。支持关键字和过滤条件。', inputSchema: { type: 'object', properties: { query: { type: 'string', description: '搜索关键词，例如产品名称、SKU号的一部分。', }, status: { type: 'string', description: '按产品状态过滤，例如 "ACTIVE", "DRAFT", "OBSOLETE"。', enum: ['ACTIVE', 'DRAFT', 'OBSOLETE'], }, maxResults: { type: 'number', description: '返回的最大结果数量，默认20，最多50。', default: 20, }, }, required: ['query'], // query是必填参数 }, }; // 工具处理函数 server.setRequestHandler(CallToolRequestSchema, async (request) => { if (request.params.name !== 'search_products') { return; // 不是这个工具处理的请求，交给其他handler } const args = request.params.arguments as any; try { // 调用封装好的API客户端 const products = await stepClient.searchEntities( 'Product', args.query, { status: args.status } // 传递过滤器 ).slice(0, args.maxResults || 20); // 应用结果数量限制 // 格式化返回给AI的结果 return { content: [ { type: 'text', text: `找到 ${products.length} 个产品：\n` + products.map(p => `- **${p.name}** (ID: ${p.id}, SKU: ${p.sku})`).join('\n'), }, ], }; } catch (error: any) { return { content: [ { type: 'text', text: `搜索失败: ${error.message}`, }, ], isError: true, }; } }); // 将这个工具注册到服务器 server.registerTool(searchProductsTool); }

  设计精妙之处：

  1. 清晰的Schema定义：inputSchema不仅定义了参数类型，还通过description和enum为AI提供了丰富的上下文。这能引导AI如何正确地使用这个工具，比如它知道status参数只能填哪几个枚举值。
  2. 友好的结果格式化：返回给AI的不是原始的JSON数组，而是结构化的自然语言文本。这样AI可以直接将结果呈现给用户，无需再进行复杂的解析。同时，也包含了关键信息（ID、SKU），方便后续操作。
  3. 统一的错误处理：将底层API的异常捕获，并转换为带有isError: true标志的标准化响应，让AI客户端能明确知道操作失败并告知用户。

  4.3 资源（Resources）的巧妙运用

  除了工具，MCP还有“资源”的概念。资源代表一些静态或半静态的、可读的信息。在这个项目中，可以将STIBO STEP的数据模型定义（Schema）作为资源发布。

  // src/resources/data-models.ts import { Server } from '@modelcontextprotocol/sdk/server/index.js'; import { ReadResourceRequestSchema } from '@modelcontextprotocol/sdk/types.js'; export function registerDataModelResource(server: Server, stepClient: StepClient) { // 定义一个资源：数据模型列表 server.registerResource({ uri: 'stibo-step://schema/models', name: 'STIBO STEP Data Models', description: '当前STIBO STEP实例中所有可用的主数据模型列表及其描述。', mimeType: 'application/json', }); server.setRequestHandler(ReadResourceRequestSchema, async (request) => { if (request.params.uri !== 'stibo-step://schema/models') { return; } try { const models = await stepClient.listDataModels(); return { contents: [{ uri: request.params.uri, mimeType: 'application/json', text: JSON.stringify(models, null, 2), // 美化输出JSON }], }; } catch (error) { // ... 错误处理 } }); }

  当AI助手需要了解“STIBO STEP里都有哪些类型的数据可以查询”时，它可以读取这个资源，从而获得上下文，进而更准确地调用search_entities等工具。资源为AI提供了宝贵的“背景知识”。

  5. 安全、权限与生产环境部署考量

  5.1 认证与授权策略深度设计

  将企业核心的MDM系统暴露给AI，安全是重中之重。akash25de/stibo-step-mcp-server项目本身是一个无状态的中间层，其安全完全依赖于STIBO STEP的API认证和自身的配置。

  1. 最小权限原则：

     • 在STIBO STEP中为MCP服务器创建专用的API账号或OAuth客户端。
     • 授予该账号绝对最小的必要权限。例如，如果只用于查询，就只给读取权限。对于写操作，考虑创建更细粒度的角色，比如只能更新特定分类下的产品状态。
     • 绝对不要使用具有管理员权限的账号。

  2. 令牌安全管理：

     • OAuth的client_secret或API Key必须通过环境变量注入，绝不能硬编码在代码中。
     • 如果运行在服务器上，考虑使用密钥管理服务（如AWS Secrets Manager, HashiCorp Vault）来动态获取凭证。
     • 确保服务器运行环境（容器、虚拟机）的网络隔离和安全加固。

  3. MCP服务器层面的访问控制：

     • 可以通过配置，让MCP服务器只监听本地回环地址（127.0.0.1），这样只有本机上的AI客户端可以连接。
     • 如果需要在团队内共享，可以部署在内部网络，并通过防火墙规则限制访问来源IP。
     • 考虑在MCP服务器前增加一个简单的API网关或反向代理（如Nginx），增加一层HTTP基础认证或IP白名单。

  5.2 生产环境部署与高可用性

  对于个人或小团队，在本地运行可能就够了。但对于希望团队共享或集成到CI/CD流程的场景，需要考虑生产部署。

  1. 容器化部署（推荐）：

     # Dockerfile FROM node:18-alpine WORKDIR /app COPY package*.json ./ RUN npm ci --only=production COPY dist ./dist USER node EXPOSE 3000 CMD ["node", "dist/index.js"]

     使用Docker或Podman容器化，能保证环境一致性，方便在Kubernetes或云服务器上部署和扩展。

  2. 进程管理： 使用pm2或systemd来管理Node.js进程，实现故障自动重启、日志轮转和开机自启。

     # 使用pm2 npm install -g pm2 pm2 start dist/index.js --name stibo-step-mcp-server pm2 save pm2 startup

  3. 日志与监控：

     • 集成winston或pino等日志库，将日志结构化输出到文件或日志收集系统（如ELK）。
     • 监控服务器的健康状态（内存、CPU）和STIBO STEP API的调用延迟、错误率。简单的HTTP健康检查端点很有用。

  5.3 性能优化与缓存策略

  频繁查询STIBO STEP可能会对后端系统造成压力，尤其是复杂的搜索。引入缓存可以显著提升响应速度并降低源系统负载。

  1. 查询结果缓存： 对于不常变化的只读数据（如数据模型列表、产品分类树），可以在MCP服务器内存或外部Redis中设置短期缓存。

     import NodeCache from 'node-cache'; const cache = new NodeCache({ stdTTL: 300 }); // 缓存5分钟 async function getCachedModels() { const cacheKey = 'data-models'; let models = cache.get(cacheKey); if (!models) { models = await stepClient.listDataModels(); // 调用真实API cache.set(cacheKey, models); } return models; }

     注意：缓存需要谨慎设计失效策略。对于主数据，缓存时间不宜过长（几分钟到几小时），并确保在STIBO STEP中有数据变更时，有能力清空或更新相关缓存（可通过Webhook或定时任务）。

  2. 分页与异步处理： STIBO STEP的搜索API可能返回大量数据。MCP工具应强制设置合理的maxResults默认值（如20）。对于AI发起的、确实需要大量数据的请求，可以考虑实现异步“作业”模式：先返回一个任务ID，让AI稍后通过另一个工具来获取结果。但这需要更复杂的MCP会话状态管理。

  6. 典型应用场景、问题排查与扩展方向

  6.1 真实场景下的工作流示例

  让我们构想几个这个MCP服务器如何改变工作方式的场景：

  场景一：快速数据核查与报告

  • 传统方式：产品经理需要一份所有“定价未审核”的产品清单。他需要登录STIBO STEP，打开产品管理模块，创建高级查询，设置状态过滤，导出Excel，再整理。
  • AI + MCP方式：在产品需求文档的会议中，产品经理直接在Claude里问：“帮我看一下STIBO STEP里所有状态是‘PRICING_PENDING’的产品，列出它们的名称、SKU和负责人。” Claude调用search_products工具，几秒后返回格式化列表。甚至可以进一步要求：“把结果整理成Markdown表格。” 效率提升是数量级的。

  场景二：开发与测试数据准备

  • 传统方式：开发人员需要测试一个与产品数据相关的接口，需要一些测试产品的ID。他要么去数据库里找，要么麻烦数据管理员导出。
  • AI + MCP方式：开发人员在Cursor中编写测试代码，需要产品ID时，直接对AI说：“从STIBO STEP测试环境里，随机找5个‘手机’分类下的活跃产品，把它们的ID给我。” AI通过MCP服务器查询并嵌入到代码注释或变量中。

  场景三：批量数据更新与巡检

  • 传统方式：需要批量将一批供应商的国家代码从旧标准更新为新标准。这需要写脚本调用API，或者手动在UI上逐个修改。
  • AI + MCP方式（在安全可控的前提下）：数据管理员编写一个清晰的指令：“找到所有国家代码为‘UK’的供应商，将其更新为‘GB’。执行前先告诉我会影响多少条记录。” AI可以先调用搜索工具确认数量，在用户确认后，再调用update_entity_attribute工具执行批量更新。整个过程在对话中完成，可审计、可确认。

  6.2 常见问题与故障排查手册

  在部署和使用过程中，你肯定会遇到一些问题。以下是一个快速排查指南：

  问题现象	可能原因	排查步骤
  MCP服务器启动失败，端口占用或立即退出	1. 端口被其他程序占用。 2. 环境变量配置错误或缺失。 3. TypeScript编译错误。	1.netstat -an | grep 3000检查端口。 2. 检查.env文件格式和变量名是否正确，使用echo $STEP_BASE_URL验证。 3. 运行npm run build查看编译错误。
  AI客户端（如Claude）连接失败，提示“无法连接到服务器”	1. MCP服务器未运行。 2. 客户端配置的路径或命令错误。 3. 防火墙/网络策略阻止。	1. 确认服务器进程是否在运行 (ps aux | grep node)。 2. 检查Claude配置中的command和args，确保是绝对路径且可执行。 3. 尝试在终端用curl http://localhost:3000（如果服务器暴露了HTTP端点）或检查WS连接。
  AI能看到工具但调用时返回“认证失败”或“权限不足”	1. STIBO STEP API凭证无效或过期。 2. API账号权限不足。 3. MCP服务器中认证逻辑有bug。	1. 使用Postman直接测试STIBO STEP API，验证凭证。 2. 检查STIBO STEP中该API账号的角色和权限分配。 3. 查看MCP服务器日志，确认请求发出的认证头是否正确。
  搜索工具能调用，但返回结果为空或不符合预期	1. 搜索关键词或过滤条件有误。 2. STIBO STEP API的查询语法与预期不符。 3. 数据映射逻辑错误，丢失了结果。	1. 在STIBO STEP的UI上用相同条件搜索，验证是否有数据。 2. 查看MCP服务器日志中发出的实际API请求体，与STIBO STEP文档对比。 3. 调试step-client.ts中的searchEntities方法，检查原始API响应和映射后的结果。
  调用写操作工具（如更新）失败	1.ENABLE_WRITE_TOOLS环境变量未设置为true。 2. STIBO STEP工作流限制（如数据处于审批中状态）。 3. 请求数据格式不符合API要求。	1. 确认服务器已启用写工具。 2. 在STIBO STEP UI上手动尝试相同操作，看是否有业务规则阻止。 3. 检查MCP工具处理函数中构建的请求体，确保字段名和值类型正确。

  调试技巧：

  • 启用详细日志：在启动MCP服务器时，设置DEBUG=mcp:*环境变量，可以输出MCP协议层的详细通信日志，对于理解客户端和服务器之间的交互非常有帮助。
  • 模拟AI请求：你可以使用一个简单的Node.js脚本模拟MCP客户端发送请求，这能隔离AI客户端的问题，直接测试服务器逻辑。

  6.3 项目扩展与二次开发思路

  akash25de/stibo-step-mcp-server提供了一个优秀的起点。你可以根据自己企业的需求进行深度定制：

  1. 增加更多工具：项目可能只实现了最常用的几个工具。你可以参考现有模式，轻松添加如get_product_hierarchy（获取产品层级）、validate_address（验证地址合规性）、run_data_quality_report（运行数据质量检查）等工具。

  2. 实现更复杂的操作流：有些业务操作涉及多个步骤，比如“复制一个产品并创建新版本”。你可以设计一个组合工具，或者在MCP服务器内部维护简单的会话状态，引导AI完成多步操作。

  3. 集成其他数据源：除了STIBO STEP，企业可能还有ERP、CRM等系统。你可以将这个MCP服务器扩展为一个“企业数据网关”，集成多个后端系统，为AI提供一个统一的、语义化的数据访问入口。

  4. 添加审计日志：所有通过MCP执行的操作，都应该被详细记录（谁、何时、通过哪个AI助手、执行了什么操作、参数是什么、结果如何）。这不仅是安全合规的要求，也是后续分析和优化AI使用体验的基础。

  5. 开发自定义UI/聊天机器人：除了依赖Claude、Cursor，你完全可以基于MCP协议开发自己的前端应用或聊天机器人，为特定部门（如客服、采购）提供定制化的数据问答界面。

  这个项目的真正魅力在于，它打开了一扇门，让企业里那些“沉睡”在复杂系统里的核心数据，能够以一种前所未有的自然、流畅的方式被访问和利用。它不仅仅是节省了点击鼠标的时间，更是将数据能力直接注入到了思考和创造的工作流中。从我实际部署和使用的体验来看，初期最大的挑战在于企业系统的安全策略对接和API的稳定性处理，一旦打通，其带来的效率提升和可能性扩展是令人兴奋的。如果你所在的企业正在使用STIBO STEP，并且对AI辅助开发感兴趣，这个项目绝对值得你花时间深入研究和实践。