组件库秒变生产代码

本文主要介绍如何将现有的模版组件库封装为一个MCP，无需再用RAG，减少重复工作，提高开发效率。

需求背景#

为了保持UI风格统一并提高开发效率，我们前端组有一个模版库专门用于初始化项目，根据页面的需求使用不同模版。但是目前存在几个痛点😭：

模版过多时候，找寻合适的模版比较麻烦
模版内容过多，复制起来比较复杂
模版里面还有其他子组件引用，也需要依次手动复制

在存在上面痛点的情况下，MCP的大热让我思考是否可以用MCP来获取。

我第一次尝试是使用autobots，在里面构建知识库，然后对接auotobots的MCP来获取（这也是我最早的一篇MCP的文章里面提及的）。但经过我两个月的使用，我发现存在以下几个痛点😭：

构建知识库比较麻烦，需要将现有的代码重新复制到里面，也是一种重复劳动
有些对于知识库构建了解不多，导致构建的内容效果不是很理想
有些模版内容过多，会导致被截断
模版里面子组件依赖，无法获取
joycode+autobots的响应时间过长，有概率超时，并且随着返回的内容越多超时概率越大

还有其他痛点，就不再赘述。

所以我就思考第二种方式，能否基于我现有的模版库，将它封装为一个MCP服务向外提供，这样就能解决上面痛点。很幸运，我成功做出来了✌️，所以接下来这篇文章就介绍我是如何将我们的模版业务组件库封装成一个MCP服务的。

一、整体项目结构#

我在这个MCP服务提供了两个大类：

工具模块
prompt模块

工具模块提供以下工具供 LLM 与模版文档交互：#

list-templates: 列出所有可用的模版
get-template-codes: 获取指定模板的代码示例（仅获取模板文件本身，不包含依赖）
get-template-with-dependencies: 获取模板文件及其所有依赖文件的完整代码（包含 import/require 的依赖）

prompt模块提供标准的prompt供使用者调用，以便于减少prompt编写：#

template-description: 用于查询模版代码时使用

在工具模块下方配套对应的工具函数模块#

extra-templates: 提取当前可用的模版，并存为.json的文件
get-templates: 核心数据加载，用于获取模版的代码示例

用于查询的数据都放在数据存储模块#

template.json: 存放所有模版的信息
src: 存放模版代码位置

二、数据流#

三、工具的具体介绍#

3.1 list-templates#

这个是获取全部可用模版，我在基于我们项目中现存的menu.json文件，使用extra-templates的工具对这个内容进行解析，生成template.json文件，这样获取模版的时候，只需要从这个模版里面获取全部内容即可，无需在对项目的目录进行遍历。

在这个template.json文件主要包含几个要素：

title: 模版名称
fatherTitle: 父级类型，辅助精准查询模版地址
id: 模版的主文件地址
description: 模版的详细描述，复制LLM帮根据用户需要提供推荐的模版

最后出来的结果：

{  "fatherTitle": "列表页",  "title": "基础列表",  "id": "/table/base/index",  "description": "企业级完整功能表格模板，包含高级搜索(联合搜索、标签过滤)、自定义列表配置、批量操作、分页控制、多种列类型处理(状态、描述、实例、标签、操作列)、完整CRUD操作(新建、编辑、删除、导入)、异步数据加载、状态管理等功能。适用于需要复杂数据管理和操作的业务场景，如资源管理、用户管理、订单管理等企业级应用。",  "fileDirectory": ""}

3.2 get-template-codes和get-template-with-dependencies#

这两个功能都是获取模版代码。但是区别在于是否要把主文件中引用的子文件也查询出来。区分这两个功能有两个好处：

按需加载，不用展示过多代码干扰研发人员
节省token，不用子组件便不返回

具体思路：用户先告诉要查询什么模版，根据模版名称在template.json文件中查询到页面路径，然后解析路径找到对应的主文件。这时候如果需要子文件，则解析引用，包括import和require，依次循环遍历查找引用的文件路径。最后将路径整合好之后，去templateData的目录中查询对应的文件代码。

四、prompt的具体介绍#

考虑到用户真实使用的时候不会用精准的语言来说明要的模版情况，一般都会说"我要一个列表页"，"我要一个XX的详细模版"，这种情况下，合适的prompt引导LLM帮做分析就很关键了。

我的prompt放在下方，也是我在真实业务里面不断尝试之后调整的版本，（当然，也请了Claude辅助优化了一下😌），大家可以按需取用。

你是一个专业的前端开发助手，专门帮助用户查询和使用样式模版。你的目标是提供最适合用户需求的模板，并指导他们如何有效地应用这些模板。
## 技能
### 1. 查询模版当用户需要查询模版时，请按照以下步骤操作：
1. **了解需求**- 询问用户需要什么类型的模版（如：列表页、表单页、详情页等）- 了解具体的功能需求（如：是否需要高级搜索、批量操作、分页控制等）- 评估用户项目的复杂度（如：是否为企业级应用、是否需要异步数据加载等）
2. **查看可用模版**- 使用 list-templates 工具列出所有可用模版- 根据用户需求和项目复杂度推荐合适的模版，参考以下标准：  * 对于复杂的企业级应用，推荐功能完整的模板（如基础列表模板）  * 对于简单应用或快速原型，推荐轻量级模板（如查询列表模板）  * 考虑特定功能需求（如高级搜索、自定义列表配置等）
3. **获取模版代码**- 如果用户只需要查看主文件：使用 get-template-codes- 如果用户需要完整实现（包含依赖）：使用 get-template-with-dependencies
4. **解释模版特性**- 详细说明模板的主要功能和特性- 解释模板的技术实现（如使用的框架、API等）- 指出模板的适用场景和潜在的定制化需求
### 2. 应用模版当用户需要将查询到的代码应用到项目中时，请按照以下步骤操作：
1. **获取代码**- 使用查询模版的技能，获取最适合用户的模版代码
2. **应用代码**- 询问用户需要将文件生成到什么位置- 处理文件冲突：  * 如果当前存在同名文件，询问用户是否覆盖  * 如果当前不存在文件，直接创建文件并将代码写入- 处理子组件：  * 如果文件存在引用的子组件，询问用户将子组件生成到什么位置  * 如果当前不存在子组件，直接创建文件并将代码写入  * 如果文件存在引用的子组件，询问用户是否覆盖- 文件路径处理：  * 如果用户指定了路径，使用用户指定的目录  * 如果用户没有指定，主文件默认放在当前目录下的src文件夹里  * 如果用户没有指定，子组件默认放在当前目录下components文件夹里- 无论何种情况，都直接创建文件，不考虑原模版提供的路径
3. **定制化指导**- 根据用户的具体需求，提供定制化建议- 指出可能需要修改的部分，如API接口、数据结构等- 建议最佳实践，如代码重用、性能优化等
4. **集成建议**- 提供将模板集成到现有项目的建议- 解释如何处理可能的依赖冲突- 建议如何组织和管理新增的组件和文件
请记住，你的角色是指导和协助用户，而不是替他们做决定。鼓励用户根据他们的具体需求和项目结构来调整和优化模板代码。

五、实现的功能效果#

查询所有可用的模版
查询指定模版的代码，包括区分是否需要包含依赖
可以根据用户的简单描述来判断适合的模版
提供prompt，供快速使用

六、总结#

本文主要介绍如何通过将现有模板库封装为MCP服务，提供标准化工具和Prompt模块，实现高效查询和代码获取。

核心设计#

工具模块：
- list-templates：列出所有模板（基于解析后的template.json）
- get-template-codes：获取主文件代码
- get-template-with-dependencies：获取主文件及其依赖代码
Prompt模块：提供标准化交互提示，减少用户输入成本
数据存储：
- template.json存储模板元数据
- src目录存放模板代码

效果与优势#

高效查询：通过自然语言描述快速匹配模板
完整代码获取：支持主文件及依赖的一键提取
降低使用门槛：标准化Prompt减少用户学习成本
性能优化：避免知识库构建和响应超时问题
无需RAG，减少重复构建成本