每到学期末、职称评审或项目申报期，高校教师都绕不开一件事：填表。
一张看似简单的表格：近三年科研项目数量、本学期授课课程、指导研究生人数、教学工作量统计。
背后往往要登录教务系统、科研系统、人事系统、研究生系统等五六个平台，逐一查询、手动汇总，一张表填下来十几分钟起步。
而这些数据，其实早就静静躺在学校的数据库里，缺的只是一个把它们简单取出来的方式。
如果老师只需要问一句话，数据就自动出来，会怎么样？
> "我近三年的科研项目数量是多少？"
> "帮我统计一下我带的研究生人数。"
这正是我们为高校落地的AI填表助手：基于智能问数（自然语言数据查询）和Text2SQL技术，让老师像聊天一样提问，系统自动理解意图、查询数据库、返回可直接填表的结构化结果。本文完整分享这套方案的技术实现——从意图识别到SQL自动生成，再到保证稳定性的执行校验机制。
一、高校教师填表的三个核心痛点
在前期调研中，我们发现老师在填表环节的困扰主要集中在三个方面。
第一是数据分散。
教务、科研、人事、研究生等业务系统之间的数据是割裂的，老师需要登录多个系统、在不同页面查询、再手动整合。而对老师来说，数据存放在哪个系统并不重要，他们只关心一件事："我需要这个数据。"
第二是查询方式复杂。
很多业务系统的查询入口层级很深，字段名称晦涩难懂，统计功能也有限。有些统计甚至需要先导出数据、再用Excel处理，才能得到想要的结果。
第三是重复劳动。
表格里要填的大部分数据，系统中其实早已存在。但因为系统之间没有打通，老师只能一遍又一遍地重复"登录—查询—统计—誊写"这套流程。
二、解决思路：智能问数，让查数据像聊天一样简单
我们希望把整个流程简化为：老师输入一句自然语言，例如"统计我近三年的科研项目数量和经费"，系统就自动完成理解问题、判断查询目标、查询数据库、返回结构化结果这四个步骤，最终生成可以直接填写表格的数据。
这个过程看起来简单，但背后依赖两个关键的AI能力：理解用户意图和自动查询数据库。下面分别展开介绍。
三、意图识别：让AI准确理解老师想查什么
人类表达同一个问题的方式非常多样。以查询课程数量为例，老师可能会问"我今年教了几门课"、"我本学期课程数量""我授课课程统计""我的教学课程情况"——表达各不相同，但本质是同一个需求：查询教师课程数量。
在AI智能体架构中，这一步叫做意图识别，即判断用户"到底想做什么"。意图识别是整条链路的第一环，如果这一步判断错了，后面的所有查询都会出错。
用RAG语义检索增强意图识别
为了让系统更好地理解各种问法，我们构建了一个意图RAG知识库。当用户提问时，系统会先将用户问题转换为语义向量，再在意图库中查找最相似的问题，从而定位到对应的业务意图。
这种方式的最大好处是：不需要编写复杂规则，也不需要频繁修改代码。如果未来出现新的问法，只需在知识库中补充新的示例问题即可。
（1）构建意图RAG知识库
以"近三年的学术论文有哪些"这个问题为例，经过意图泛化后，可能的问法包括：
查老师近三年论文
找老师近3年论文
调老师三年论文
老师近三年论文有吗
老师近3年有论文吗
老师三年论文有哪些
想找老师近三年学术论文
需要老师近3年学术论文
求老师近三年相关论文
...意图RAG知识库中的一条切片就是一个意图表达，例如：
intent_id: paper_query
intent_name: 查询学术论文
intent_expression: 教师论文数量将意图识别与RAG结合，实现了对泛化能力的可控化，保证了高准确率。遇到线上未覆盖的场景时，无需修改提示词或调优模型，仅需补充知识库条目即可快速响应，极大简化了修复流程。
（2）意图识别查询
用户提问后，系统会先匹配出Top K个候选意图，再由大模型判断真正的意图：
用户问题：我近三年的学术论文有哪些
候选意图：
1 - intent_id: paper_query 意图表达: 查询教师论文
2 - intent_id: paper_query 意图表达: 查询教师论文
3 - intent_id: research_award_query 意图表达: 查询科研获奖
最终输出：意图为 {查询学术论文}如果意图RAG库中已经充分补充过泛化问法，候选意图中大部分都会指向同一个意图，识别结果也会更加稳定。
四、Text2SQL：让AI把自然语言自动转换成SQL查询
当系统明确了用户想查什么之后，下一个问题是：如何从数据库中获取数据？
业务系统的数据本质上都存储在数据库表中，例如 teachercourseprojectstudent 等。查询数据库通常需要编写SQL语句，例如：
SELECT count(*) FROM project WHERE teacher_id = ?但对绝大多数老师来说，SQL是完全陌生的。因此我们需要让AI完成关键的一步：把自然语言转换成SQL，这就是Text2SQL技术。例如用户问"我近三年的科研项目数量是多少？"，AI自动生成：
SELECT COUNT(*) FROM project
WHERE year >= 2022 AND teacher_id = ?系统执行这条SQL，即可获取结果。
知识增强：大幅提升SQL生成准确率
如果直接让大模型"裸生成"SQL，往往会出现表名错误、字段不存在、SQL逻辑不正确等问题。为此我们引入了知识增强机制：系统提前准备好数据库表结构、字段说明、表间关系、业务规则逻辑和示例SQL语句，在用户提问时一并提供给Text2SQL节点，让AI基于这些知识生成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语句示例：
-- 用户提问：查询教师科研项目数量
SELECT COUNT(*) FROM research_project WHERE teacher_id = ?
-- 用户提问：查询指定教师的姓名、职称、所有SCI论文及发表期刊
SELECT t.teacher_name, t.title, p.paper_title, p.journal_name, p.publish_year
FROM teacher t
INNER JOIN academic_paper p ON t.teacher_id = p.teacher_id
WHERE t.teacher_id = ? AND p.paper_level = 'SCI'
-- 用户提问：统计每个学院教师发表的北大核心论文总数
SELECT t.department, COUNT(p.paper_id) AS core_paper_count
FROM teacher t
LEFT JOIN academic_paper p ON t.teacher_id = p.teacher_id
WHERE p.paper_level = '北大核心'
GROUP BY t.department
-- 用户提问：查询获得过国家级科研奖项的教师姓名及学院
SELECT DISTINCT t.teacher_name, t.department
FROM teacher t
INNER JOIN research_award a ON t.teacher_id = a.teacher_id
WHERE a.award_level = '国家级'
-- 用户提问：查询指定教师第一作者的科研奖项及对应的科研项目
SELECT a.award_name, a.award_year, r.project_name
FROM research_award a
LEFT JOIN research_project r ON a.teacher_id = r.teacher_id
WHERE a.teacher_id = ? AND a.award_rank = 1
-- 用户提问：查询指定学院2018年后入职教师的所有学术成果
SELECT t.teacher_name, p.paper_title, c.conference_name
FROM teacher t
LEFT JOIN academic_paper p ON t.teacher_id = p.teacher_id
LEFT JOIN academic_conference c ON t.teacher_id = c.teacher_id
WHERE t.department = ? AND t.hire_year >= 2018五、SQL执行校验：兼顾AI灵活性与系统稳定性
即使有了知识增强机制，AI生成的SQL仍有小概率出现问题。为此我们设计了一套执行校验与模板兜底机制，整体流程是：AI生成SQL后，系统先尝试执行；执行成功则直接返回结果；执行失败则自动切换到备用查询方式——预定义SQL模板。
这些模板覆盖了"查询教师学术论文"、"查询教师科研项目"、"查询教师基础信息"等高频场景，全部经过人工验证，执行成功率极高。三层机制叠加之后，系统既保留了AI理解自然语言的灵活性，又保证了生产环境要求的稳定性。
六、最终输出：自动生成可直接填表的数据
数据库查询完成后，系统会获取查询结果，结合用户的原始问题进行整理，生成结构化数据。这些数据可以直接填写到表格中，也可以导出Excel或复制使用——老师不再需要手动统计。
七、这套AI填表方案的三个核心优势
查询方式更自然。 老师不需要记住系统入口、查询路径和字段名称，像聊天一样提问即可获得数据，学习成本几乎为零。
系统扩展更容易。 未来增加新的业务需求时，只需新增意图条目、补充数据库知识，系统就能支持新的查询场景，无需改动代码。
降低数据使用门槛。 很多老师并不缺数据，缺的是获取数据的简单方式。AI填表助手正好填补了这个空白，让沉睡在各个业务系统中的数据真正被用起来。
八、从填表到教育数字化：智能问数的想象空间
填表只是一个开始。当系统具备智能问数能力之后，还可以延伸出更多应用：自动生成统计报表、教学数据分析、科研数据分析、项目申报辅助等。未来老师只需要说一句"帮我生成一份教学工作统计报告"，系统就能自动完成。
这或许是AI在教育信息化中最有价值的一种应用方式：让数据真正为人服务。
常见问题（FAQ）
Q1：智能问数支持私有化部署吗？
支持。整套系统（包括大模型、意图识别RAG库、Text2SQL引擎）均可部署在学校内网环境，纯内网也能运行，数据不出校园，满足高校和政企对数据安全的合规要求。
Q2：需要改造现有的教务、科研等业务系统吗？
不需要。AI填表助手通过只读方式对接现有系统的数据库，不改动原有系统的任何功能和代码。原系统照常使用，AI助手作为一个独立的查询入口叠加在上面。
Q3：老师问的问题AI理解错了怎么办？
系统采用"意图识别RAG + SQL执行校验 + 预定义模板兜底"三层机制保证准确率。遇到未覆盖的新问法，只需在意图库中补充示例问题即可，无需修改代码，运维成本很低。
Q4：除了高校，其他行业能用吗？
可以。智能问数的本质是"自然语言查数据库"，同样适用于政企、制造业等有多系统数据分散问题的场景，例如经营数据统计、生产报表查询等。
填表只是我们实操场景的一个切面。上海云璨信息技术有限公司成立于2011年，这两年我们陪着高校、政企、制造业等行业的客户，把AI从PPT里拽出来，塞进了真实的生产环境：知识库协同、智能问数、AI客服、OpenClaw智能办公、智能体一体机（纯内网也能跑）、写作辅助——都有已交付的落地案例。
