毕业答辩常见问题 Q&A 准备
以下回答基于你的论文《多源Web表格自动填写系统的设计与实现》及代码实现，语言简洁、逻辑清晰，适合答辩现场表述。共六问六答，并附拓展问题供演练。
Q1：你设计的这个系统，整个具体流程是怎么样的？
A1：
我的系统分为四个主要步骤：
- 数据接入：用户上传 Excel 文件、SQL 文件或提供网页表格 URL。后端根据类型调用不同工具读取数据（如
ExcelReadTool、SQLFileTool、WebScraperTool），然后通过DataCleanerTool进行清洗（去空行、去重、清理列名等），统一转换成 Pandas DataFrame，并在前端展示预览。 - 目标表单解析：用户输入目标网页的 URL，后端启动 Selenium 驱动 Firefox 浏览器，解析页面中的表单结构，提取每个字段的标签、名称、类型以及下拉框/单选框的选项列表，返回给前端展示。
- 字段智能匹配：系统基于 LangChain 框架构建一个智能体（Agent），调用通义千问大语言模型，自动分析源数据列与目标表单字段的语义对应关系，生成带置信度的映射推荐。用户可以在前端表格中查看并手动调整映射。
- 自动填充与导出：用户确认映射后，系统按映射规则转换源数据，然后驱动 Selenium 自动打开目标网页，逐条将数据填入表单对应控件中（支持文本框、下拉框、单选/复选框）。填充完成后，用户可将结果导出为 Excel 或 CSV 文件。
整个流程实现了从多源数据到目标表单的自动化填写，同时保留了人工确认环节，兼顾效率与准确性。
Q2：你设计的系统数据来源在哪、使用了哪些库？分别用这些库干了什么？
A2：
系统的数据来源有三种：本地 Excel 文件、本地 SQL 文件、网页表格 URL。
使用的核心库及其作用如下：
| 库名 | 作用 |
|---|---|
| Pandas | 统一处理表格数据（读取 Excel/CSV、数据清洗、列映射、导出结果） |
| openpyxl / xlrd | Pandas 读取 Excel 文件的底层引擎，分别支持 .xlsx 和 .xls 格式 |
| sqlparse | 解析 SQL 文件中的 CREATE TABLE 和 INSERT 语句，提取列名和数据行 |
| BeautifulSoup / lxml | 静态解析 HTML 表格，用于网页表格的快速抓取 |
| Selenium | 驱动真实 Firefox 浏览器，用于动态渲染的目标表单解析以及自动填充操作 |
| LangChain | 构建字段匹配智能体（Agent），管理大模型调用、工具调用和输出解析 |
| dashscope | 调用阿里云百炼平台的通义千问大模型 API，进行语义推理和选项匹配 |
| FastAPI | 提供后端 RESTful API，支持异步处理，自动生成接口文档 |
| Uvicorn | ASGI 服务器，用于运行 FastAPI 应用 |
这些库共同支撑了数据接入、语义匹配、自动化填充和结果导出的完整功能。
Q3：你对参考文献项目的了解程度？本项目相对参考项目有什么改进或者优势？哪些方面借鉴了参考项目的经验/思路呢？
A3：
我重点参考了以下三篇文献：
《Using Large Language Model to Fill in Web Forms to Support Automated Web Application Testing》（Chen et al., 2025）
该文献使用 T5 模型对表单字段分类，再用数据伪造器生成值，并用 GPT-4o 判断表单提交是否成功。借鉴了其“大语言模型+自动化填充”的思路，但我将其应用场景从软件测试转向日常数据填充，并增加了多源数据接入和人工确认环节。《Matchmaker: Self-Improving Large Language Model Programs for Schema Matching》（Seedat & van der Schaar, 2024）
该文献将模式匹配拆分为候选生成、精炼和置信度评分三个阶段，并提出用大模型评估自身输出来优化提示词。我借鉴了其“分阶段匹配”和“置信度评分”的思想，设计了我的字段匹配 Agent；同时引入了其“人机协同”理念——用颜色标注置信度，让用户审核修正。《LLMATCH: a Unified Schema Matching Framework with Large Language Models》（Wang et al., 2025）
该文献提出了 Rollup（聚合）和 Drilldown（下钻）的两阶段匹配策略，以及表选择机制。我借鉴了其模块化设计思想，将我的系统分为数据接入、字段匹配、自动填充三个独立模块，便于扩展和维护。
本项目的改进与优势：
- 端到端完整流程：参考文献大多聚焦于字段匹配本身，而我的系统覆盖了从多源数据读取、清洗、匹配、填充到结果导出的全过程。
- 多源数据统一接入：支持 Excel、SQL 文件和网页表格三种异构数据源，而多数对比工作只处理单一格式。
- 人机协同的可视化交互：不仅用大模型推荐映射，还提供置信度颜色标注和手动调整下拉框，用户可随时修正，提升了实用性。
- 选项值智能匹配：针对下拉框、单选框等控件，单独设计了
OptionMatchingTool，使用大模型直接匹配源值到选项，并支持多值拆分和同义词降级，这是参考文献未详细处理的细节。
Q4：后端代码为什么要用Python写，而不是使用其他语言？
A4：
主要基于以下几点考虑：
- 生态成熟：Python 拥有 Pandas、Selenium、LangChain、FastAPI 等与本项目需求高度契合的库，开发效率高。
- 大模型支持：通义千问等大模型 API 均提供 Python SDK，LangChain 框架也是 Python 原生，用 Python 可以无缝集成。
- 快速原型开发：Python 语法简洁，适合学术研究性质的毕设项目，能够快速实现并验证想法。
- 跨平台性：Python 在 Windows、Linux 上都能良好运行，便于部署和演示。
其他语言如 Java（Spring Boot）虽然稳定，但生态中缺少像 LangChain 这样成熟的 LLM 编排工具；Node.js 在异步 I/O 上有优势，但数据处理（Pandas）和自动化测试（Selenium）的 Python 实现更成熟。因此 Python 是最合适的选择。
Q5：为什么不使用Python2？Python2和Python3的区别是什么？
A5：
我使用的是 Python 3.10+，不使用 Python 2 的主要原因是：
- 官方已停止维护：Python 2 在 2020 年 1 月 1 日正式停止支持，不再有安全更新和 bug 修复。
- 现代库不支持：本系统依赖的 LangChain、FastAPI、DashScope 等库均要求 Python 3.7+，无法在 Python 2 上运行。
- 语言特性优势：Python 3 引入了类型提示（Type Hints）、异步
async/await、f-string 等特性，让代码更清晰、更高效。
Python 2 与 Python 3 的主要区别（答辩重点）：
| 方面 | Python 2 | Python 3 |
|---|---|---|
| print 语句 | print "hello" | print("hello") 函数形式 |
| 整数除法 | 3/2 = 1（整除） | 3/2 = 1.5（浮点），3//2 为整除 |
| Unicode | 默认 ASCII 字符串，需要 u"中文" | 默认 Unicode，直接支持中文 |
| 异常捕获 | except Exception, e: | except Exception as e: |
| 库生态 | 大量库停止更新 | 所有新库均基于 Python 3 |
因此，从技术趋势、库支持和代码质量角度，Python 3 是唯一合理的选择。
Q6：解释一下你论文中用到的专业术语。
A6：
以下是论文中出现的核心术语及其通俗解释：
- 多源异构数据：来自不同来源、格式不同的数据，例如 Excel 文件、SQL 数据库、网页表格。
- 字段映射：确定源数据表的列（如“姓名”）应该填入目标表单的哪个字段（如“fullName”）。
- LangChain：一个开源框架，用于构建以大语言模型为核心的应用，可以方便地编排提示词、工具调用和输出解析。
- Agent（智能体）：一个能够自主调用工具、推理并执行任务的程序。在我的系统中，Agent 先调用工具分析源列和目标字段，再让大模型给出映射建议。
- 置信度：大模型对每条映射推荐的把握程度，取值范围 0~1，越高表示越确信。前端用绿、黄、红三色标注。
- Selenium：一个自动化测试工具，可以驱动真实浏览器（如 Firefox）模拟人类操作，如点击、输入、选择等。
- DataFrame：Pandas 库中的核心数据结构，类似于 Excel 表格或数据库表，支持高效的行列操作。
- 无头浏览器：在后台运行、不显示窗口的浏览器模式，用于解析动态网页时节省资源。
这些术语在论文中都有明确定义，答辩时能用通俗语言解释会更加分。
拓展问题：你使用LangChain创建智能体时用到了哪些基本操作？有哪些基本参数？temperature的作用是什么？
A1（拓展）：
我在 MatchingAgent 中使用了 LangChain 的 create_agent 方法创建智能体。基本操作包括：
- 定义工具（
@tool装饰器）：analyze_source_columns和analyze_target_fields，分别用于获取源数据列信息和目标表单字段信息。 - 创建 LLM 实例：
ChatOpenAI类，配置模型名称、API Key、Base URL 等。 - 调用
create_agent将 LLM 和工具列表绑定，生成一个可执行的 Agent。 - 通过
agent.invoke()传入系统提示词和用户问题，得到最终输出。 - 解析返回的 JSON 内容，并做降级处理（若解析失败则回退到子串匹配）。
基本参数（在 ChatOpenAI 中设置）：
model：模型名称，如qwen-turbotemperature：控制输出随机性max_tokens：最大生成 token 数api_key和base_url：连接阿里云百炼服务
temperature 的作用：
- 调节生成文本的随机程度。取值范围一般是 0~1 或 0~2。
- temperature 越低（如 0.1），模型输出越确定、越保守，倾向于选择概率最高的词，适合需要精确答案的任务（如字段匹配）。
- temperature 越高，输出越多样、越有创造性，适合开放生成任务（如写诗）。
- 在我的系统中，字段匹配需要稳定、可重复的结果，所以设置
temperature=0.1，避免模型随机输出不同的映射建议。
其他可能被问到的简单问题（自备）
| 可能问题 | 简要回答 |
|---|---|
| 你的系统能处理验证码吗？ | 目前不支持。验证码需要额外的打码服务或人工介入，属于系统限制，可在后续改进。 |
| 如果大模型 API 断网怎么办？ | 系统设计了降级策略：字段匹配失败时自动切换到子串规则匹配；选项匹配失败时使用同义词扩展。用户也可手动调整映射，确保基本可用。 |
| 为什么最多只支持 5 条记录批量填充？ | 当前演示版本为了避免浏览器长期占用，便于用户逐条检查填充结果。代码中实际限制为 100 条，可根据需求调整。 |
| 你的系统能填充哪些类型的表单控件？ | 支持文本框、多行文本域、下拉框、单选框、复选框。对于需要上传文件或复杂交互的表单暂不支持。 |
| 前端为什么用 Vue 而不直接用 HTML+JS？ | Vue 提供了响应式数据绑定和组件化开发，可以轻松实现步骤化引导（v-if 控制面板显隐）和映射表格的颜色标注，代码更简洁易维护。 |
| 你的系统能保证填充百分之百正确吗？ | 不能。大模型推荐存在误差，但系统设计了人工确认和修改环节，用户可审核后填充，大大降低了错误率。测试中用户确认修正后准确率可达 95% 以上。 |
祝你答辩顺利！以上内容已覆盖常见问题，建议熟记核心答案，并用自己的话复述一遍。
贡献者
freeway348