推荐语
让AI帮你一句话搞定繁琐的填表工作，告别重复查询和手动统计的烦恼！核心内容： 1. 老师填表时面临的三大痛点：数据分散、查询复杂、重复填写 2. 智能问数解决方案：自然语言输入自动生成表格数据 3. 核心技术：意图识别与语义检索增强的查询系统
杨芳贤
53AI创始人/腾讯云(TVP)最具价值专家
每到学期末、评估期或者项目申报阶段，很多老师都会遇到同一件事情：
填表。
一张看起来并不复杂的表格，往往需要查询大量数据，例如：
近三年的科研项目数量
本学期的授课课程
指导学生情况
教学工作量统计
问题在于，这些数据往往分散在多个系统中：
教务系统
科研系统
人事系统
研究生系统
学生管理系统
于是老师需要：
1️⃣ 登录不同系统
2️⃣ 查找对应数据
3️⃣ 手动统计
4️⃣ 再填写到表格中
一张表格可能需要花费十几分钟甚至更久。
但实际上，这些数据早就存在系统里。
只是缺少一个简单的方式把它们取出来。
于是我们在想：
如果老师只需要问一句话，就能自动获取这些数据，会怎么样？
例如：
“我近三年的科研项目数量是多少？”
“我今年教了几门课？”
“帮我统计一下我带的研究生人数。”
系统自动查询数据，并生成结果。
这就是我们做的事情：
一个填表辅助AI助手。
一、我们想解决的核心问题
在调研过程中，我们发现老师在填表时主要有三个痛点。
1、数据分散
不同业务系统之间数据是割裂的。
老师往往需要：
而对于老师来说，他们并不关心数据在哪个系统。
他们只关心：
“我需要这个数据。”
2、查询方式复杂
很多系统的查询方式并不友好：
有些统计甚至需要：
导出数据 → Excel处理 → 再统计
3、表格填写重复
很多表格填写的数据其实是：
系统中已经存在的数据。
但因为系统之间没有打通，老师只能重复操作。
二、一个更简单的方式：智能问数
我们希望把这个流程变成这样：
老师只需要输入一句自然语言，例如：
“统计我近三年的科研项目数量和经费。”
系统就会自动：
1️⃣ 理解用户问题
2️⃣ 判断用户想查询什么数据
3️⃣ 自动查询数据库
4️⃣ 返回结构化结果
最终生成可以直接填写表格的数据。
整个过程可以理解为：
看起来很简单，但背后其实有两个关键能力：
接下来简单介绍一下这两个核心能力。
三、第一步：理解用户想查什么
人类表达问题的方式是非常多样的。
例如查询课程数量，老师可能会这样问：
我今年教了几门课
我本学期课程数量
我授课课程统计
我的教学课程情况
虽然表达不同，但本质是同一个需求：
查询教师课程数量
这一步在AI智能体中叫做：
意图识别。
简单来说，就是判断用户：
“到底想做什么”。
如果意图识别错了，后面的所有查询都会出错。
使用语义检索增强意图识别
为了让系统更好地理解问题，我们构建了一个意图库。
当用户提问时，系统会：
1️⃣ 将用户问题转换为语义向量
2️⃣ 在意图库中查找最相似的问题
3️⃣ 找到对应的业务意图
这种方式的好处是：
不需要写复杂规则，也不需要频繁修改代码。
如果未来出现新的问法，只需要：
补充新的示例问题即可。
完整流程如下：
（1）构建意图RAG知识库
例如，用户可能提问“近三年的学术论文有哪些？”
经过意图泛化后可能的提问有：
查老师近三年论文找老师近3年论文调老师三年论文老师近三年论文有吗老师近3年有论文吗老师三年论文有哪些想找老师近三年学术论文需要老师近3年学术论文求老师近三年相关论文...
意图RAG知识库中一条切片就是一个意图表达。
例如：
intent_id: paper_queryintent_name: 查询学术论文intent_expression: 教师论文数量
我们将意图识别结合RAG，实现了对泛化能力的可控化，保证了高准确率。遇到线上未覆盖场景时，无需修改提示词或调优，仅需补充知识库条目即可快速响应，极大简化了修复流程。（2）意图识别查询
用户提问后一般会匹配Top K个意图，然后让LLM判断真正意图。
用户问题：我近三年的学术论文有哪些候选意图：1-intent_id: paper_query意图表达: 查询教师论文2-intent_id: paper_query意图表达: 查询教师论文3-intent_id: research_award_query意图表达: 查询科研获奖最终输出：意图为{查询教师论文}
如果在意图识别RAG库中已经添加过泛化的内容，可能候选意图中大部分都是同一个意图表达，这样会更加稳定。
四、第二步：让AI自动查询数据库
当系统知道用户想查询什么之后，接下来要解决的问题是：
如何从数据库中获取数据？
系统中的数据本质上都存储在数据库中，例如：
teachercourseprojectstudent
但数据库的查询通常需要写SQL语句，例如：
SELECT count(*)FROM projectWHERE teacher_id = ?
对于大部分老师来说：
SQL是完全陌生的。
因此我们需要让AI完成一件事情：
把自然语言转换成SQL。
例如：
用户问题：
AI生成：
SELECT COUNT(*)FROM projectWHERE year >= 2022AND teacher_id = ?
然后系统执行SQL，就能获取结果。
如果直接让AI生成SQL，往往会出现一些问题：
例如：
为了解决这个问题，我们引入了一种知识增强机制。
系统会提前准备一些数据库及相关信息，例如：
数据表结构
字段说明
表之间关系
业务规则逻辑
示例SQL语句
当用户提问时，AI会基于这些知识生成SQL，这样可以大幅提升SQL生成的准确率。
为此我们添加一个Text2SQL节点，将数据库表结构信息、业务规则、用户提问以及参考示例都提供给它，让它生成SQL语句。相关示例内容如下：
数据库Schema示例：
数据库名称：faculty_research_db本数据库用于存储教师科研、教学、论文、获奖等相关信息。
教师基础信息表（teacher）表用途：存储高校教师唯一身份编号、姓名、所属学院、职称、入职年份等核心基础档案信息，是全库关联主表。字段：| 字段名 | 数据类型 | 约束 | 字段描述 || | teacher_id | INT | PK, NOT NULL, 自增 | 教师全局唯一标识ID || teacher_name | VARCHAR(50) | NOT NULL | 教师真实姓名 || department | VARCHAR(100)| NOT NULL | 教师所属二级学院 || title | VARCHAR(30) | NOT NULL | 教师专业技术职称 || hire_year | YEAR | NOT NULL | 教师正式入职年份 |
科研项目表（research_project）表用途：记录每位教师主持 / 参与的各类纵向、横向科研立项项目信息，包含项目等级、个人角色、经费、立项时间等核心业务字段。字段：| 字段名 | 数据类型 | 约束 | 字段描述 || | project_id | INT | PK, NOT NULL, 自增 | 科研项目全局唯一ID || teacher_id | INT | FK, NOT NULL | 关联教师基础表的教师ID || project_name | VARCHAR(200) | NOT NULL | 科研项目正式全称 || project_level | VARCHAR(30) | NOT NULL | 科研项目级别（国/省/校等）|| project_role | VARCHAR(30) | NOT NULL | 教师在项目中担任角色 || project_fund | DECIMAL(12,2) | NOT NULL | 项目总经费，单位：万元 || project_year | YEAR | NOT NULL | 科研项目正式立项年份 |
科研奖项表（research_award）表用途：存储教师科研工作获得的各级荣誉奖项数据，包含奖项名称、等级、获奖年份、成果排名等信息。字段：| 字段名 | 数据类型 | 约束 | 字段描述 || | award_id | INT | PK, NOT NULL, 自增 | 科研奖项全局唯一ID || teacher_id | INT | FK, NOT NULL | 关联教师基础表的教师ID || award_name | VARCHAR(200)| NOT NULL | 科研获奖项目全称 || award_level | VARCHAR(30) | NOT NULL | 科研奖项评定等级 || award_year | YEAR | NOT NULL | 奖项正式获评年份 || award_rank | INT | NOT NULL | 教师在获奖成果中排名 |
学术期刊论文表（academic_paper）表用途：收录教师发表的正式期刊学术论文数据，涵盖论文标题、发表期刊、论文质量等级、出版年份等关键信息。字段：| 字段名 | 数据类型 | 约束 | 字段描述 || | paper_id | INT | PK, NOT NULL, 自增 | 期刊论文全局唯一ID || teacher_id | INT | FK, NOT NULL | 关联教师基础表的教师ID || paper_title | VARCHAR(255)| NOT NULL | 学术期刊论文完整标题 || journal_name | VARCHAR(150)| NOT NULL | 论文发表的期刊名称 || paper_level | VARCHAR(30) | NOT NULL | 论文收录/质量等级 || publish_year | YEAR | NOT NULL | 期刊论文正式出版年份 |
...
业务规则文档示例：
科研项目统计规则：--------------------------------------------------科研项目数量统计：统计 teacher_id 对应的 research_project 表记录数量--------------------------------------------------科研经费统计：统计 research_project.project_fund 总和--------------------------------------------------论文数量统计：统计 academic_paper 表记录数量--------------------------------------------------SCI论文：paper_level = 'SCI'--------------------------------------------------核心期刊论文：paper_level = '核心期刊'
...
SQL语句示例：
用户提问：查询教师科研项目数量生成SQL：SELECT COUNT(*)FROM research_projectWHERE teacher_id = ?用户提问：查询指定教师的姓名、职称、所有SCI论文及发表期刊生成SQL：SELECT t.teacher_name, t.title, p.paper_title, p.journal_name, p.publish_yearFROM teacher tINNER JOIN academic_paper p ON t.teacher_id = p.teacher_idWHERE t.teacher_id = ? AND p.paper_level = 'SCI'用户提问：统计每个学院教师发表的北大核心论文总数生成SQL：SELECT t.department, COUNT (p.paper_id) AS core_paper_countFROM teacher tLEFT JOIN academic_paper p ON t.teacher_id = p.teacher_idWHERE p.paper_level = ' 北大核心 'GROUP BY t.department用户提问：查询获得过国家级科研奖项的教师姓名及学院生成SQL：SELECT DISTINCT t.teacher_name, t.departmentFROM teacher tINNER JOIN research_award a ON t.teacher_id = a.teacher_idWHERE a.award_level = ' 国家级'用户提问：查询指定教师第一作者的科研奖项及对应的科研项目生成SQL：SELECT a.award_name, a.award_year, r.project_nameFROM research_award aLEFT JOIN research_project r ON a.teacher_id = r.teacher_idWHERE a.teacher_id = ? AND a.award_rank = 1用户提问：查询指定学院2018年后入职教师的所有学术成果生成SQL：SELECT t.teacher_name, p.paper_title, c.conference_nameFROM teacher tLEFT JOIN academic_paper p ON t.teacher_id = p.teacher_idLEFT JOIN academic_conference c ON t.teacher_id = c.teacher_idWHERE t.department = ? AND t.hire_year >= 2018
...
Text2SQL节点LLM：
五、提升稳定性的关键：SQL执行校验
即使有知识增强机制，生成的SQL仍然可能出现问题。
因此我们设计了一套执行校验机制。
整体流程如下：
1️⃣ AI生成SQL
2️⃣ 系统尝试执行SQL
3️⃣ 如果执行成功 → 返回结果
4️⃣ 如果执行失败 → 使用备用查询方式
备用查询方式通常是：预定义SQL模板。
例如：
查询教师学术论文
查询教师科研项目
查询教师基础信息
...
这些模板SQL是经过验证的，因此执行成功率很高。
这样做的好处是：既可以利用AI的灵活性，又能保证系统稳定性。
六、最终输出：自动生成表格数据
当数据库查询完成之后，系统会：
1️⃣ 获取查询结果
2️⃣ 结合用户问题进行整理
3️⃣ 生成结构化数据
这些数据可以：
老师不需要再手动统计。
七、这个方案的几个优势
总结一下，这种方式带来了几个明显的改变。
1、查询方式更自然
老师不需要记住：
只需要：
像聊天一样提问。
2、系统扩展更容易
如果未来增加新的业务需求：
只需要：
系统就可以支持新的查询。
3、降低数据使用门槛
很多老师其实并不缺数据。
缺的是：
获取数据的简单方式。
AI助手正好填补了这个空白。
八、未来的想象空间
填表只是一个开始。
当系统具备智能问数能力之后，还可以扩展很多能力，例如：
自动生成统计报表
教学数据分析
科研数据分析
项目申报辅助
未来，老师只需要问一句话：
“帮我生成一份教学工作统计报告。”
系统就可以自动完成。
这或许是AI在教育信息化中最有价值的一种应用方式：
让数据真正为人服务。
填表只是我们实操场景的一个切面。知识库协同、智能问数、AI 客服、OpenClaw 智能办公、智能体一体机（纯内网也能跑）、写作辅助——这两年，我们陪着高校、政企、制造业等不同行业的用户，把 AI 从 PPT 里拽出来，塞进了真实的生产环境。如果你手上也有想落地又拿不准的场景，扫码加微信，咱们聊聊看。
粤ICP备14082021号
免费POC，
零成本试错
