毕业答辩问答报告
多源Web表格自动填写系统的设计与实现
一、选题相关问答
Q1：为什么选择这个题目？
回答：
选择这个题目主要基于以下几点考虑：
第一，问题真实存在。在日常学习和生活中，我经常遇到需要把Excel表格数据填入网页表单的情况，比如填写各种申请表、报名信息等。这个过程很繁琐，容易出错，所以我想做一个工具来解决这个问题。
第二，技术有创新性。近年来大语言模型技术发展很快，我想尝试把这项新技术应用到实际问题的解决中，看看能不能比传统方法做得更好。
第三，工作量适中。这个题目既涉及前端开发、后端开发，又涉及人工智能技术的应用，技术栈比较全面，适合作为本科毕业设计的选题。
Q2：这个系统和市面上现有的表单工具有什么区别？
回答：
主要的区别在于智能化程度和使用门槛。
市面上现有的工具大致分为两类：
一类是浏览器自带的自动填充功能，比如记住密码、记住表单数据。这类工具只能填充你之前填过的内容，不能处理新的数据源。
另一类是专业的数据集成工具，比如ETL工具。这类工具功能强大，但使用门槛很高，需要懂数据库、会写代码，普通用户很难上手。
我们的系统定位在中间地带：
比浏览器自动填充更智能，可以处理各种新的数据源
比专业ETL工具更易用，普通用户通过网页界面就能操作
引入了AI技术，可以自动分析字段对应关系
Q3：这个系统的实际应用价值大吗？
回答：
我认为应用价值还是比较大的，主要体现在以下几个方面：
场景一：企业办公。很多企业的财务人员需要定期把Excel报表数据填入各种业务系统，比如报税系统、统计系统等。用这个系统可以大大提高工作效率。
场景二：数据迁移。企业更换业务系统时，经常需要把旧系统的数据迁移到新系统。传统方式需要开发专门的迁移程序，成本很高。用这个系统可以快速完成数据迁移。
场景三：重复性数据录入。比如数据录入员的工作，每天面对大量重复性的数据录入任务。用这个系统可以自动化完成，减轻工作负担。
当然，这个系统目前还是原型阶段，如果要真正投入使用，还需要在稳定性、安全性等方面做更多工作。
二、技术相关问答
Q4：为什么选择Python作为开发语言？
回答：
选择Python主要有以下几个原因：
第一，生态丰富。Python在数据处理和人工智能领域有很多成熟的库，比如Pandas用于数据处理，LangChain用于大模型应用开发，Selenium用于浏览器自动化。这些库可以大大减少开发工作量。
第二，语法简洁。Python的语法比较接近自然语言，代码可读性强，适合快速开发和迭代。
第三，FastAPI框架优秀。FastAPI是一个现代的高性能Web框架，支持异步处理，可以自动生成API文档，非常适合构建RESTful API服务。
第四，个人熟悉。我在课程学习和项目实践中主要使用Python，对这个语言比较熟悉。
Q5：大语言模型在系统中起什么作用？
回答：
大语言模型在系统中主要承担字段语义匹配的任务。
具体来说，当用户上传了源数据表并指定了目标表单后，系统需要找出源数据列和目标表单字段之间的对应关系。比如：
"姓名"列对应"申请人姓名"字段
"手机号"列对应"联系电话"字段
"出生年月"列对应"出生日期"字段
这个任务看似简单，但实际很复杂，因为：
字段命名不规范，同一个意思可能有多种表达方式
涉及同义词、近义词的理解
有时需要根据上下文推断含义
传统的基于规则的匹配方法很难处理这些情况。而大语言模型通过阅读海量文本，已经"学会"了很多知识，能够理解同义词、近义词，甚至能理解缩写和简写，所以更适合做这个任务。
在系统中，我们把源数据列和目标表单字段的信息整理成文本，发给大语言模型，让它分析对应关系，返回JSON格式的匹配结果。
Q6：为什么选择通义千问作为大模型？
回答：
选择通义千问主要基于以下几点考虑：
第一，中文理解能力强。通义千问是阿里云开发的大语言模型，针对中文进行了优化，在中文理解和生成方面表现很好。而我们的系统主要面向中文场景，所以选择通义千问比较合适。
第二，API调用方便。通义千问提供了标准的OpenAI兼容API，可以通过HTTP请求调用，集成到系统中很方便。
第三，成本可控。相比国外的一些大模型API，通义千问的价格相对合理，适合学生项目使用。
第四，国内访问稳定。由于服务器在国内，访问速度快，稳定性好，不会出现因网络问题导致API调用失败的情况。
当然，系统架构设计时考虑到了模型的可替换性。如果需要使用其他大模型（比如GPT、Claude等），只需要修改配置文件中的API地址和密钥即可，不需要改动核心业务代码。
Q7：系统的字段匹配准确率如何？
回答：
根据测试，系统的字段匹配准确率如下：
大模型推荐准确率：80%左右
经过人工确认修正后：95%以上
这个结果是基于100组真实表格对的测试得出的，涵盖了人事信息、财务数据、商品信息等多种类型。
80%的推荐准确率意味着，系统推荐的10个匹配中，大约有8个是正确的，有2个可能需要人工修正。这个准确率虽然不算完美，但已经能大大减少人工工作量。
之所以没有达到100%，主要有以下几个原因：
某些字段的命名过于模糊，连人也不好判断对应关系
某些缩写或代码类字段缺乏语义信息
大模型对某些专业领域的术语理解不够准确
所以我们设计了"人机协同"机制，让系统给出推荐结果后，由用户进行确认和修正，这样既发挥了AI的效率，又保证了结果的准确性。
Q8：如果大模型API不可用，系统还能工作吗？
回答：
能工作，但准确率会降低。
系统设计了降级策略：当大模型API调用失败时，会自动切换到基于规则的后备匹配模式。
后备匹配策略比较简单，主要是比较字段名称的字符串相似度：
如果源列名和目标字段名完全相同，认为匹配
如果源列名包含目标字段名，或目标字段名包含源列名，认为匹配
其他情况认为不匹配
这种基于规则的匹配虽然准确率不如大模型，但胜在稳定可靠，不依赖外部服务。而且系统会提示用户当前使用的是降级模式，推荐结果可能不够准确，需要仔细核对。
Q9：系统如何保证数据安全？
回答：
数据安全是我们重点考虑的问题，系统从以下几个方面做了保障：
第一，本地处理优先。源数据文件上传到后端后，只在服务器内存中处理，不会持久化存储。处理完成后立即释放内存，不会留存数据。
第二，敏感信息过滤。调用大模型API时，只发送字段名称和少量示例数据（前3行），不会发送完整的数据内容。而且示例数据中的敏感信息（如手机号、身份证号）可以进行脱敏处理。
第三，传输加密。前后端通信使用HTTPS协议，数据在传输过程中是加密的，不会被中间人窃取。
第四，访问控制。系统可以配置访问权限，只有授权用户才能使用。
当然，对于对数据安全要求很高的场景，建议采用本地部署的开源大模型，这样数据就完全不会离开本地服务器。
Q10：系统能处理多大规模的数據？
回答：
目前系统对数据规模的限制如下：
源数据规模：
理论上Pandas可以处理百万行级别的数据
但考虑到内存占用和响应时间，建议单次处理不超过1万行
批量填充限制：
当前版本限制最多填充5条记录
这是为了防止误操作，万一匹配关系有误，不会造成大量错误数据
之所以限制为5条，主要是出于谨慎考虑。在实际使用中，用户可以先填充几条测试数据，检查无误后再继续填充下一批。
如果需要处理更大规模的数据，可以考虑以下优化方向：
使用流式处理，分批读取和填充数据
引入任务队列，支持异步批量处理
优化浏览器会话复用，减少重复创建浏览器的开销
三、系统设计相关问答
Q11：系统为什么选择前后端分离架构？
回答：
选择前后端分离架构主要有以下几个原因：
第一，职责清晰。前端负责用户界面和交互，后端负责业务逻辑和数据处理，两者职责明确，便于开发和维护。
第二，技术选型灵活。前后端可以独立选择最适合的技术栈。前端用Vue.js做响应式界面，后端用Python的FastAPI提供API服务，各司其职。
第三，便于扩展。前后端通过RESTful API通信，接口规范统一。未来如果要开发移动端App或其他客户端，可以直接复用后端API。
第四，开发效率高。前后端可以并行开发，前端用Mock数据模拟后端接口，不需要等后端完成才能开始开发。
Q12：系统的核心模块有哪些？它们之间是什么关系？
回答：
系统的核心模块可以分为四个层次：
表现层（前端）
使用Vue.js开发
负责用户界面和交互
通过HTTP请求调用后端API
业务逻辑层（后端服务）
数据接入服务：负责读取Excel、SQL、网页等不同来源的数据
字段匹配服务：负责调用大模型进行字段语义匹配
数据填充服务：负责数据转换和浏览器自动化填充
智能代理层
匹配智能体：基于LangChain框架构建，封装了大模型调用逻辑
填充智能体：封装了Selenium浏览器自动化逻辑
工具层
Excel工具、SQL工具、网页抓取工具：负责具体的数据读取
数据清洗工具：负责数据标准化处理
浏览器填充工具：负责表单自动填充
它们之间的关系是：上层调用下层提供的服务，下层不感知上层的具体业务逻辑。这种分层设计使得系统结构清晰，便于维护和扩展。
Q13：人机协同机制是如何设计的？
回答：
人机协同是系统的重要设计理念，主要体现在字段匹配环节。
为什么需要人机协同？
虽然大语言模型很聪明，但它不是万能的，有时也会出错。比如：
把"手机号"错配给"紧急联系人电话"
漏掉某些字段没有匹配
对不明确的字段强行匹配
如果完全依赖自动匹配，一旦出现错误，后续的填充结果就全错了。所以我们设计了人机协同机制，让系统给出推荐，由用户确认。
具体实现方式：
置信度评分：大模型为每个推荐匹配给出置信度（0-1之间的小数），表示系统对这个匹配的确信程度。
可视化展示：前端界面以表格形式展示推荐结果，用颜色标注置信度高低：
- 绿色：高置信度（>0.8），大概率正确
- 黄色：中置信度（0.5-0.8），需要关注
- 红色：低置信度（<0.5），建议人工审核
- 人工干预接口：用户可以：
- 修改映射关系（下拉选择其他源列）
- 删除错误的映射
- 添加遗漏的映射
- 确认后执行：只有用户确认无误后，才会进行后续的填充操作。
这样既发挥了AI的效率，又保证了结果的准确性。
Q14：系统如何处理不同格式的数据源？
回答：
系统支持三种数据源，分别采用不同的处理方式：
Excel文件
使用Pandas的read_excel方法读取
支持openpyxl和xlrd两种引擎，兼容.xlsx和.xls格式
自动处理多工作表、合并单元格等情况
SQL文件
使用正则表达式解析SQL文本
提取CREATE TABLE语句中的列定义
提取INSERT语句中的数据行
转换为DataFrame格式
网页表格
采用动静结合的两阶段策略
第一阶段：使用requests库静态抓取，用Pandas的read_html解析
第二阶段（如果第一阶段失败）：使用Selenium动态渲染页面，等待JavaScript执行完成后再提取表格
所有数据源读取后，都会经过统一的数据清洗流程，包括：
列名清理（去除空格、特殊字符）
空行删除
重复行去重
数据类型转换
最终都转换为Pandas的DataFrame格式，便于后续统一处理。
Q15：系统如何定位网页表单中的输入元素？
回答：
系统使用Selenium进行浏览器自动化，定位表单元素采用四级回退策略：
第一级：按name属性定位
driver.find_element(By.NAME, field_name)这是最常用的方式，大多数表单字段都有name属性。
第二级：按id属性定位
driver.find_element(By.ID, field_name)如果name属性不存在，尝试使用id属性。
第三级：按placeholder定位
driver.find_element(By.XPATH, f"//input[contains(@placeholder, '{field_name}')]")如果name和id都没有，尝试匹配placeholder属性。
第四级：按label关联定位
label = driver.find_element(By.XPATH, f"//label[contains(text(), '{field_name}')]")
for_attr = label.get_attribute("for")
if for_attr:
element = driver.find_element(By.ID, for_attr)如果以上都失败，尝试找到对应的label标签，再通过for属性找到关联的输入元素。
这种多级回退策略提高了系统对不同网页结构的适应性。如果所有策略都失败，系统会记录错误并跳过该字段，继续填充其他字段。
四、测试与评估相关问答
Q16：系统是如何测试的？测试结果如何？
回答：
系统的测试分为三个层面：
功能测试
对每个功能模块进行单独测试
测试各种正常和异常情况
测试结果：所有功能均通过测试
字段匹配准确率测试
收集了100组真实表格对作为测试集
对比系统推荐结果和人工标注的正确答案
测试结果：
- 大模型推荐准确率：80.6%
- 人工修正后准确率：95.4%
性能测试
测试各操作环节的响应时间
测试结果：
- Excel文件加载（1000行）：2.3秒
- 字段匹配推荐：8.2秒
- 单条记录填充：2.1秒
- 各项指标均达到预期要求
Q17：80%的匹配准确率是否足够实用？
回答：
我认为80%的推荐准确率是可以接受的，原因如下：
第一，有后续的人工确认环节。系统不是全自动的，推荐结果会展示给用户审核，用户可以修正错误的匹配。经过人工确认后，准确率可以达到95%以上。
第二，置信度提示。系统为每个推荐匹配标注了置信度，低置信度的匹配会高亮显示，提醒用户重点关注。这样用户可以把注意力集中在需要审核的地方，高置信度的匹配可以快速确认。
第三，效率提升明显。即使只有80%的准确率，也意味着用户只需要审核20%的匹配，而不是像传统方式那样100%手动匹配。这仍然能大幅提升工作效率。
当然，80%还有提升空间。未来可以通过以下方式改进：
优化提示词，给大模型更多上下文信息
引入 Few-shot Learning，给大模型一些示例
学习用户的修正行为，不断优化推荐算法
Q18：系统在实际使用中可能遇到什么问题？
回答：
根据测试和分析，系统在实际使用中可能遇到以下问题：
技术层面
某些网页使用了复杂的JavaScript框架，表单元素动态生成，可能无法正确解析
某些表单需要登录才能访问，系统目前不支持自动登录
某些表单有验证码，系统无法自动识别
大模型API偶尔会出现网络超时或服务不可用的情况
业务层面
某些字段的对应关系很主观，不同用户可能有不同的理解
某些数据需要复杂的转换逻辑，系统目前只支持简单的格式转换
大规模数据填充时，浏览器可能卡顿或崩溃
安全层面
数据上传到服务器处理，可能存在隐私泄露风险
浏览器自动化需要驱动真实浏览器，可能存在安全风险
针对这些问题，系统设计了降级策略和错误处理机制，确保即使遇到问题也能给出合理的反馈，不会完全不可用。
五、创新与不足相关问答
Q19：这个系统的创新点在哪里？
回答：
我认为系统的创新点主要体现在以下几个方面：
技术创新
将大语言模型技术应用到表格字段匹配场景，相比传统方法准确率更高
设计了人机协同的工作模式，既发挥了AI的效率，又保证了结果的准确性
实现了多源异构数据的统一接入和标准化处理
应用创新
降低了数据集成工具的使用门槛，普通用户通过网页界面就能操作
探索了大语言模型在结构化数据处理领域的应用边界
提供了一种轻量级的数据填充解决方案
设计创新
采用分层架构，职责清晰，便于维护和扩展
设计了置信度评分和可视化展示机制，提升了用户体验
实现了降级策略，确保系统在各种情况下都能工作
当然，这些创新都是在现有技术基础上的组合创新，不是从零开始的原始创新。
Q20：系统有哪些不足之处？未来如何改进？
回答：
系统的不足之处主要有以下几点：
数据源支持有限
目前只支持Excel、SQL和网页表格
未来可以扩展支持JSON、XML、API接口等更多数据源
批量处理能力不足
目前限制最多填充5条记录
未来可以优化浏览器会话复用，支持大规模批量处理
大模型依赖性强
核心功能依赖云端API，网络不稳定时体验受影响
未来可以引入本地部署的开源大模型，降低对外部服务的依赖
复杂表单支持不足
对包含复杂逻辑的动态表单支持有限
未来可以研究表单字段依赖关系识别，支持条件字段、联动字段等
智能化水平有待提升
目前还不会学习用户的偏好
未来可以引入机器学习，根据用户的历史修正行为优化推荐算法
六、总结相关问答
Q21：通过这个项目，你学到了什么？
回答：
通过这个项目，我在以下几个方面有所收获：
技术能力
深入学习了Python Web开发，掌握了FastAPI框架的使用
了解了Vue.js前端开发，能够构建简单的单页面应用
学习了大语言模型的应用开发，了解了LangChain框架
掌握了Selenium浏览器自动化的基本用法
工程能力
学会了如何进行需求分析和系统设计
掌握了分层架构的设计思想
了解了如何编写技术文档和测试用例
体验了完整的软件开发流程
问题解决能力
学会了如何分解复杂问题，逐个击破
了解了如何调研技术方案，权衡利弊做出选择
掌握了调试和排查问题的方法
最重要的收获是认识到：技术是为解决问题服务的。在选择技术方案时，要考虑实际需求和约束条件，而不是盲目追求新技术。
Q22：如果让你重新做这个项目，你会怎么做？
回答：
如果重新做这个项目，我会做以下改进：
需求分析阶段
多做用户调研，了解真实用户的痛点和需求
明确系统的边界，不要试图解决所有问题
技术选型阶段
提前评估大模型API的稳定性和成本
考虑引入本地部署方案作为备选
设计阶段
更详细地设计数据库结构，考虑缓存和持久化
设计更完善的错误处理和日志记录机制
开发阶段
采用测试驱动开发，先写测试用例再写代码
更早地进行集成测试，避免后期出现兼容性问题
文档阶段
及时更新文档，保持代码和文档的一致性
编写更详细的部署和运维文档
Q23：你认为这个系统的最大价值是什么？
回答：
我认为这个系统的最大价值在于探索了一种新的工作模式：人机协同。
传统的自动化工具要么是完全手动的（效率低），要么是完全自动的（不可靠）。我们的系统尝试走中间路线：
让AI做它擅长的事：快速分析、初步匹配
让人做他擅长的事：判断、决策、审核
这种"AI推荐+人工确认"的模式，既发挥了AI的效率优势，又保证了结果的准确可靠。我相信这种模式在很多场景下都比"全手动"或"全自动"更实用。
此外，这个系统也证明了大语言模型在结构化数据处理领域的应用潜力。以前大家觉得大模型只会聊天、写文章，我们这个项目展示了它也能处理表格数据、理解字段语义。这为未来更多AI应用提供了思路。
七、其他可能的问题
Q24：系统的部署方式是怎样的？
回答：
系统采用B/S架构，部署方式如下：
后端部署
需要Python 3.10+环境
安装依赖包：
pip install -r requirements.txt配置环境变量（大模型API密钥等）
启动服务：
uvicorn main:app --host 0.0.0.0 --port 8000
前端部署
前端是静态HTML文件，可以直接用浏览器打开
也可以用Nginx等Web服务器托管
浏览器驱动
需要安装Firefox浏览器
下载与Firefox版本匹配的geckodriver驱动
注意：由于系统使用Selenium驱动真实浏览器，需要在有图形界面的环境中运行，或者配置无头浏览器模式。
Q25：系统的代码量有多少？开发周期多长？
回答：
代码量统计
后端Python代码：约3000行
前端HTML/JS代码：约1000行
总计约4000行代码
开发周期
需求分析和调研：2周
系统设计：1周
编码实现：6周
测试和优化：2周
论文撰写：3周
总计约14周（3个多月）
Q26：系统的开源协议是什么？可以商用吗？
回答：
目前这个系统是毕业设计项目，还没有明确的开源协议。如果未来要开源，可能会选择MIT或Apache协议，允许自由使用和修改。
关于商用，需要注意以下几点：
系统使用了通义千问大模型API，商用需要遵守阿里云的服务条款
系统使用了Selenium和Firefox，需要遵守相应的开源协议
如果要商用，建议对代码进行安全审计和性能优化
Q27：你在开发过程中遇到的最大困难是什么？如何解决的？
回答：
开发过程中遇到的最大困难是大模型输出格式不稳定。
大语言模型生成的文本是自由的，有时候返回JSON格式，有时候会在JSON前后加上解释文字，有时候JSON格式不合法。这给后续的解析带来了很大麻烦。
解决方法：
优化提示词：在提示词中明确要求"只返回JSON，不要有任何其他文字"
使用结构化输出：利用LangChain的with_structured_output功能，强制要求模型按照预定义的JSON模式返回
增加解析容错：在解析JSON时，先尝试提取JSON部分（找第一个{和最后一个}），再解析
设计降级策略：如果解析失败，切换到基于规则的后备匹配模式
通过这些措施，最终解决了输出格式不稳定的问题。
该系统中，重命名列是为了做什么？
在系统中，重命名列发生在数据填充阶段，其目的是将源数据 DataFrame 的列名统一修改为目标表单所要求的字段名。
这样一来，系统在后续逐条填充时，可以直接用目标字段名（如 fullname、phone）作为键，从每一行数据中取出对应的值，然后准确地填入网页表单中对应 name 属性的输入框里。
简言之，重命名列就是实现源数据列到目标表单字段的“名称对齐”，是数据转换与自动填充之间的关键衔接步骤。
答辩技巧提示
1. 态度诚恳，实事求是
不要夸大系统的功能和性能
对于不会的问题，坦诚承认，不要胡编乱造
对于系统的不足，主动说明，并给出改进思路
2. 突出亮点，体现思考
重点介绍系统的创新点和特色功能
展示你在设计和实现过程中的思考
说明你是如何解决问题的
3. 准备演示，直观展示
提前准备好系统演示环境
准备几个典型的使用场景
演示时讲解操作步骤和设计意图
4. 控制时间，详略得当
自述部分控制在10-15分钟
重点讲清楚"做了什么"和"为什么这么做"
技术细节可以简要带过，留待问答环节详细解释
5. 保持冷静，从容应对
答辩老师的问题可能比较尖锐，不要紧张
听清楚问题后再回答，不要急于辩解
如果遇到确实不会的问题，可以说"这个问题我目前还没有深入研究，答辩后我会认真思考"
祝你答辩顺利！
贡献者
freeway348