Nólëbase

切换主题

毕业答辩“模块实现”类问题 Q&A（不涉及具体函数/接口） ​

字数
3737 字
阅读时间
15 分钟

以下问题围绕“系统中某个模块是怎么实现的”，回答均采用通俗语言，不涉及具体代码细节，适合答辩现场表述。

Q1：你系统中的“多源数据接入模块”是怎么实现的？ ​

A1：
这个模块的核心功能是让系统能够读懂三种不同格式的数据：Excel文件、SQL文件、网页表格。
实现思路上，我为每种数据源设计了专门的“读取器”。当用户在前端选择上传Excel时，系统就知道调用Excel读取器；选择SQL文件时，调用SQL解析器；输入网页URL时，调用网页抓取器。
这三种读取器都会把原始数据统一转换成一种内部通用的表格格式（类似于Excel工作表）。转换完成后，还会经过一道“清洗”工序——比如去掉空行、清理列名中的特殊符号、删除重复数据等。
这样一来，无论用户上传什么格式的数据，最终系统拿到的都是一张干净、规整的表格，方便后续处理。

Q2：目标表单解析模块是怎么实现的？ ​

A2：
这个模块的目标是“理解”目标网页里有哪些表单字段。
我使用了一个能模拟真实浏览器的工具。当用户输入目标网页的URL后，系统会在后台打开一个浏览器（不显示窗口），访问该网页，等网页完全加载后，读取页面中的所有表单控件（比如输入框、下拉框、单选按钮等）。
对于每个控件，系统会尝试找到它的名称、类型以及它旁边的文字标签（比如“姓名”“手机号”）。对于下拉框，还会把所有选项都记录下来。
最后把这些信息整理成一个字段列表，返回给前端展示。用户就能清楚地看到目标表单长什么样、有哪些字段需要填写。

Q3：字段智能匹配模块是怎么实现的？ ​

A3：
这个模块相当于系统的“大脑”。它会自动判断源数据的某一列应该填到目标表单的哪个字段里。
实现上，我先从源数据中提取每一列的列名、数据类型和前几行示例值；同时从目标表单中提取每个字段的名称、标签和选项。然后把这些信息组织成一段描述文字，发送给大语言模型。
大语言模型就像一个非常聪明的“语义理解专家”，它能看懂“姓名”和“fullName”是同一个意思，“手机号”和“phone”也是对应的。模型分析后会返回一个映射建议，并且每条建议都会附带一个“置信度”分数。
如果模型觉得某个匹配很靠谱，置信度就高，反之则低。前端会用颜色标出来，方便用户审核和调整。

Q4：表单自动填充模块是怎么实现的？ ​

A4：
这个模块负责把数据真正填到网页表单里。
它的核心是一个能驱动真实浏览器的自动化工具。用户确认映射关系后，系统会启动一个浏览器窗口，打开目标网页。
然后按照映射规则，一条一条地处理数据。对于每一条记录，系统会按顺序找到每个表单字段的位置，比如根据字段的ID、名称或者它旁边的文字标签来定位。
定位到文本框，就自动输入内容；定位到下拉框，就在选项中找到匹配的那一项并选中；定位到单选或复选框，就直接点击对应的选项。
每条记录填充完成后，浏览器会保持打开状态，用户可以亲眼检查填得对不对。手动关闭浏览器后，系统再继续填充下一条记录。这样既保证了自动化效率，又保留了人工确认的环节。

Q5：人机协同的映射修正功能是怎么实现的？ ​

A5：
这个功能的目的是让用户既能享受大模型推荐的便利，又能保留自己的判断和调整能力。
实现上，前端用一个表格来展示所有目标字段。每一行显示目标字段的名称、系统推荐的源列以及置信度分数。置信度的高低会通过背景颜色区分：绿色表示很靠谱，黄色表示一般，红色表示不太确定。
表格的每一行还配了一个下拉框，里面列出了所有源数据的列名。用户可以随时从下拉框里换一个源列，或者选择“不映射”。
这样设计的好处是：用户不需要从头开始想映射关系，只需要快速浏览和微调即可。系统把大模型的能力和人的经验结合在了一起，既高效又准确。

Q6：结果导出模块是怎么实现的？ ​

A6：
填充完成后，系统会把填充好的数据保存为一份内部表格。当用户点击“导出”按钮时，系统会把这内部表格转换成用户指定的格式（Excel或CSV），生成一个临时文件，然后通过浏览器自动下载到用户的电脑上。
导出完成后，后台会自动删除那个临时文件，不会在服务器上留下用户的敏感数据。整个过程很快，用户基本上感觉不到延迟。

Q7：系统前后端是如何进行交互的？ ​

A7：
系统采用前后端分离架构，前端和后端通过网络请求进行通信，具体方式如下：

  • 前端（Vue.js） 负责展示界面和接收用户操作，后端（FastAPI）负责处理业务逻辑和数据。
  • 当前端需要获取数据或执行操作时（比如上传文件、获取映射推荐、执行填充），会向后端发送一个HTTP请求（主要是POST和GET）。
  • 请求中包含必要的参数（例如文件内容、URL、映射关系等），后端接收到请求后，调用相应的功能模块进行处理，然后将处理结果以JSON格式返回给前端。
  • 前端收到返回的数据后，动态更新页面内容（比如显示数据预览、展示映射表格、提示填充结果）。

举个例子：用户点击“加载源数据”按钮 → 前端把文件打包发送到后端的/source/preview地址 → 后端读取并清洗数据，把列名和示例数据返回 → 前端用这些数据刷新预览表格。

这样做的好处：前后端各司其职，前端专注界面交互，后端专注业务逻辑，一方修改不影响另一方，也便于后续扩展（比如未来可以开发手机App调用同一个后端接口）。

Q8：前端步骤化引导界面是如何实现的？ ​

A8：
步骤化引导的核心思想是：根据用户当前的操作进度，动态显示或隐藏界面中的某些区域和按钮，让用户自然地按照正确顺序一步步操作，不需要阅读说明文档。

具体实现思路如下：

  1. 定义几个关键状态：系统内部会记录“源数据是否已加载”、“目标表单是否已解析”、“映射推荐是否已获取”、“填充是否已完成”等信息。这些状态会随着用户操作而改变。

  2. 界面元素的条件显示：

    • 只有“源数据已加载”且“目标表单已解析”时，字段映射区域才会出现，同时显示“获取智能推荐映射”按钮。
    • 只有“已获取映射推荐”时，映射表格和“确认填充”按钮才会出现。
    • 只有“填充成功”时，导出按钮才会出现。

  3. 用户无法跳过步骤：因为后面的按钮或面板只有在满足前置条件后才会显示，用户不可能在没加载源数据的情况下就去点击填充。这样就形成了天然的步骤引导。

  4. 视觉反馈：除了显示/隐藏，系统还会用加载中状态（比如按钮显示“加载中…”并禁用）来提示用户请勿重复点击，用提示框告知操作结果。

通俗理解：就像玩一个解谜游戏，只有完成了当前任务，下一关的门才会打开。用户不需要记住先点哪里后点哪里，跟着页面上出现的按钮按顺序点下去就行，非常直观。

九、为什么要让大模型返回JSON格式的数据？ ​

答辩回答：

大模型返回JSON格式主要有以下几个原因：

  1. 结构化输出，便于程序解析
    大模型生成的映射推荐需要包含多个字段：推荐映射关系、置信度分数、未匹配的源列、未匹配的目标字段等。JSON天然支持键值对和嵌套结构，程序可以直接解析成对象，无需复杂的字符串处理。

  2. 格式标准化，跨语言通用
    JSON是一种轻量级、语言无关的数据交换格式。无论后端是Python还是其他语言，都能轻松处理。这保证了系统的可扩展性。

  3. 减少歧义，提高稳定性
    如果让大模型返回自然语言（如“建议将源列‘姓名’映射到目标字段‘fullName’”），不同次的回复格式可能不一致，解析困难。JSON格式明确要求特定的字段名和结构，大模型更容易遵循，解析失败率低。

  4. 便于前端直接使用
    后端拿到JSON后，可以直接转发给前端，前端无需转换即可渲染映射表格和置信度颜色。

  5. 支持降级处理
    如果大模型返回的JSON不符合预期格式，系统可以捕获异常并切换到子串匹配降级策略，保证健壮性。

十、前后端数据交互是以什么形式进行的？ ​

答辩回答：

系统采用HTTP协议 + JSON数据格式进行前后端交互。

  • 通信协议：HTTP（超文本传输协议），使用GET和POST方法。
  • 数据格式：JSON（JavaScript Object Notation），轻量级、易读、跨语言。

具体流程：

  • 前端（Vue）通过 axios 库向后端（FastAPI）发送异步请求，请求体中携带参数（例如上传的文件、URL、映射关系等），数据被封装成JSON格式。
  • 后端接收到请求后，解析JSON参数，执行业务逻辑，然后将处理结果（如数据预览、映射推荐、填充状态等）也包装成JSON格式返回给前端。
  • 前端收到JSON响应后，解析数据并动态更新页面（如刷新表格、显示提示）。

为什么选择JSON？

  • 相比XML，JSON更简洁、解析更快、体积更小。
  • 前后端主流技术（Vue、Python）对JSON支持都非常友好。
  • 调试时可直接查看网络请求内容，方便测试。

总结：大模型返回JSON是为了方便程序处理和结构化输出；前后端交互采用HTTP+JSON，保证了系统的灵活性、可维护性和跨语言兼容性。

前后端交互方式（优化版） ​

答辩回答：

本系统采用前后端分离架构，前端使用 Vue.js，后端使用 FastAPI，两者之间通过 HTTP 协议进行通信，数据格式统一为 JSON。

前端通过 axios 库向后端发送 GET 和 POST 请求，具体交互如下：

  • POST 请求：用于向服务器提交数据或文件。例如：

    • 上传源数据文件（Excel/SQL）时，前端以 multipart/form-data 格式发送 POST 请求到 /api/source/preview，后端接收后解析并清洗数据，返回预览信息。
    • 获取字段映射推荐时，前端将源数据列信息、目标表单字段信息等以 JSON 格式通过 POST 请求发送到 /api/mapping/recommend，后端调用大模型处理后返回映射结果。
    • 执行填充时，前端将最终映射关系、目标 URL 等通过 POST 请求发送到 /api/fill/execute，后端驱动浏览器完成填充。

  • GET 请求：用于从服务器获取数据，不改变服务器状态。例如：

    • 解析目标表单时，前端将目标网页 URL 作为查询参数通过 GET 请求发送到 /api/target/preview，后端解析并返回表单字段信息。
    • 导出结果时，前端通过 GET 请求访问 /api/export，并附带导出格式参数（excel/csv），后端返回文件供下载。

所有接口均遵循 RESTful 风格，利用 HTTP 方法本身的语义（GET 获取、POST 创建/处理）来设计接口，使得前后端交互清晰规范。这种设计不仅降低了前后端的耦合度，也便于后续扩展和维护。

贡献者 ​

The avatar of contributor named as freeway348 freeway348

文件历史 ​

用 ♥ 撰写

CC BY-SA 4.0 © 2022-PRESENT Nólëbase 的创作者们