大学校园里“是否允许学生使用 AI”正在成为一个比“AI 能做什么”更棘手的话题。不少高校在课程说明、论文规范中明确表示更希望学生不依赖生成式 AI甚至直接禁用某些公开 AI 服务。这背后不是简单的技术排斥而是因为通用 AI 应用在学术场景中存在内容不可信、数据不可控、行为不可审计等现实问题。对开发者来说与其争论“要不要用 AI”不如去解决“如何让 AI 在学术场景中可用”。本文从高校场景的真实约束出发围绕数据边界、私有化部署、内容安全、幻觉控制、日志审计等维度梳理一套可落地的 AI 应用工程实践并通过一个本地知识库问答助手的实现案例说明具体做法。1. 为什么高校更倾向于“不用 AI”限制背后的真实技术诉求1.1 学术诚信与生成内容边界高校最担心的是学生用 AI 直接生成论文、作业或实验报告导致学术不端。很多学校的处理方式是禁止使用生成式 AI但这并没有解决一个根本问题当 AI 确实可以帮助学生整理文献、理解概念、调试代码时如何区分“合理辅助”与“代写代答”。从技术上看这个边界很难通过一个“AI 检测工具”一劳永逸地划清。更务实的做法是在 AI 应用层做约束第一限制模型回答问题的范围只允许基于学校提供的教材、讲义、公开文献生成答案第二要求模型输出引用来源让使用者必须回到原文确认第三对超出知识库范围的问题模型必须明确回答“不知道”而不是编造一个答案。这些约束都属于 AI 工程实践中的提示词设计、RAG 检索增强和模型行为控制问题。高校想“不用 AI”本质上是希望避免不可控的 AI 输出而不是拒绝所有 AI 能力。1.2 数据隐私与敏感信息保护高校场景里有两类数据非常敏感一类是学生个人信息包括学号、成绩、家庭信息另一类是科研数据可能包含未公开的论文、实验数据、专利相关材料。这些数据一旦被发送到外部大模型服务就脱离了学校的管控范围。所以很多高校希望本地部署模型或者至少要保证数据不出校园网。所谓“Universities would prefer no AI”在数据层面可以理解为学校不愿意让私有数据进入不受自己控制的第三方推理服务。开发者需要提供的方案是私有化模型部署、本地向量检索、数据脱敏和访问控制。1.3 内容合规与责任归属高校是公共服务机构AI 生成的内容如果出现违法信息、错误医疗建议、歧视性言论或恶意的提示词注入责任很难定位。通用 AI 服务难以满足校园级内容安全要求。因此学术场景的 AI 系统必须增加内容过滤层包括输入检测、输出检测和人工审核兜底。同时要记录完整的问答日志谁在什么时间、通过哪个终端问了一句什么话系统返回了什么都应当可以追溯。这样一旦出现问题可以定位是模型问题、知识库问题还是使用者操作问题。1.4 从“禁止”到“可控”是更现实的目标完全不用 AI 在今天的科研、学习和日常办公中已经越来越不现实。高校真正的需求是“可控地使用 AI”。一个可控的 AI 系统至少满足四个条件数据边界清晰哪些数据可以进模型、哪些不能有明确的规则。行为边界清晰模型只回答允许回答的问题对不允许的问题直接拒绝。输出可验证回答的结果可以追溯到知识库中的原始材料。审计完整所有问答过程都有日志必要时可以回放。这四点也构成了下文技术方案的主要设计目标。后面所有代码和配置都围绕这四点展开。2. 高校 AI 应用的最小架构先想清楚数据边界和系统边界2.1 系统场景一个面向教务问答的本地知识库助手为了把问题说清楚本文选择一个小而完整的场景为某学院做一个“教务问答助手”。它只回答三类问题培养方案相关问题例如“网络工程专业毕业要求是什么”。选课规则问题例如“必修课不及格可以补考吗”。校园制度问题例如“请假流程怎么走”。所有答案必须来自学校提供的《培养方案》《选课管理办法》《学生手册》等文档。系统部署在校园网内大模型使用本地推理服务外部网络不可访问。2.2 核心模块划分系统可以拆成五个模块每个模块职责单一模块职责需要解决的技术点接入层接收 HTTP 请求校验身份接口鉴权、限流、参数校验安全过滤层对用户输入和模型输出做检测敏感词、PII、提示词注入检测RAG 检索层从知识库中检索相关片段文档切分、向量化、相似度检索大模型推理层根据 Prompt 和检索结果生成回答本地模型调用、参数控制审计日志层记录完整问答链路日志结构化、异步写入、查询分析模块之间通过接口调用不要把过滤逻辑写在 Controller 里也不要把模型调用逻辑和业务逻辑混在一起。这样后续替换模型、增加人工审核、调整过滤规则都不会影响整体结构。2.3 数据流与部署边界一次完整问答的数据流向是这样的用户提交问题。接入层校验用户身份和问题长度。安全过滤层检查输入是否包含违规内容或提示词注入特征。RAG 检索层将问题向量化在向量库中检索相关文档片段。构建 Prompt将检索结果和用户问题一起发送给本地大模型。模型生成回答。安全过滤层对输出内容再次检查。审计日志层记录输入、输出、耗时、检索命中等信息。接口返回回答。这里的核心边界是用户输入和模型输出都不可直接信任。两个方向都要过过滤层向量库中的文档必须经过权限审核模型只能依赖检索到的文档片段回答而不是凭空生成。2.4 技术选型表在实际项目中技术栈可以根据团队情况调整。下表是一组能够支撑上述架构的选型参考用途可选方案说明后端框架Spring Boot 3 Spring AI适合已有 Java 团队Spring AI 提供了统一的大模型客户端抽象向量数据库pgvector、Milvus、Qdrant、Chroma数据量不大时 pgvector 可以复用 PostgreSQL运维成本低本地大模型Qwen2.5、Llama 3.1、DeepSeek-R1 蒸馏版按显存和效果选择 7B 到 14B 模型学术问答场景 7B 通常够用Embedding 模型BGE-M3、bge-large-zh中文场景使用 BGE 系列效果更稳敏感词库自建关键词表 Hutool 敏感词工具先拦截强规则词再用模型语义分类兜底认证与审计Spring Security 数据库日志表校园网内可使用统一身份认证对接如果原始项目没有明确规定版本落地前要先确认依赖版本。Spring AI 的模块和 API 变化较快示例代码需要结合项目实际使用的版本调整。3. 从零搭建一个可审计的 AI 问答服务3.1 项目结构与 Maven 依赖这里用一个最小化的 Spring Boot 项目展示核心代码。假设项目名称为campus-ai-assistant结构如下campus-ai-assistant/ ├── pom.xml ├── src/main/java/com/campus/ai/ │ ├── controller/AssistantController.java │ ├── service/AssistantService.java │ ├── service/RagKnowledgeService.java │ ├── service/SafetyFilterService.java │ ├── service/AuditLogService.java │ └── model/Question.java │ └── model/Answer.java └── src/main/resources/ ├── application.yml └── prompts/ └── assistant-prompt.stpom.xml 中加入 Spring AI、PostgreSQL JDBC 驱动、pgvector 相关依赖。注意 Spring AI 的 starter 名称可能随版本变化示例只说明依赖方向dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdorg.springframework.ai/groupId artifactIdspring-ai-ollama-spring-boot-starter/artifactId /dependency dependency groupIdorg.springframework.ai/groupId artifactIdspring-ai-pgvector-store-spring-boot-starter/artifactId /dependency实际使用前要去 Spring AI 官方文档核对与 Spring Boot 版本对应的 starter 名称。在这个示例中Ollama 负责提供本地大模型和 Embedding 模型pgvector 负责保存向量数据。3.2 本地模型配置与 Prompt 模板application.yml 中配置 Ollama 地址、模型名称和向量库连接信息spring: ai: ollama: base-url: http://127.0.0.1:11434 chat: model: qwen2.5:7b embedding: model: bge-m3 pgvector: uri: jdbc:postgresql://127.0.0.1:5432/campus_ai username: campus_ai password: change-me在这里base-url指向校园本机的 Ollama 服务数据不会离开服务器。如果你的团队选择调用云端 API就必须在数据边界上做更严格的评估例如对请求文本脱敏后才允许发送。Prompt 模板是控制模型行为的关键文件。下面是一份面向教务助手的系统提示词你是一个高校教务问答助手。请严格遵循以下规则 1. 只允许使用上下文提供的材料回答用户问题。 2. 如果上下文材料中没有相关信息请回答抱歉知识库中没有找到相关信息请咨询教务处工作人员。 3. 回答时先给出结论再说明依据并标注引用来源的文件名和段落编号。 4. 不要回答与教务无关的问题例如政治、医疗、法律建议、违法犯罪相关内容。 5. 不要编造数据、政策或文件条款。 上下文材料 {context} 用户问题{question}模板中的{context}是 RAG 检索后拼装出来的知识片段{question}是用户输入。通过这套约束模型被限制在“引用知识库内容回答问题”的范围内减少乱编答案的概率。3.3 接入向量知识库RAG 的核心流程是“先整理文档再检索片段最后喂给模型”。第一步是把学校的 PDF、Word、Markdown 文档切分为固定长度的文本块并生成向量写入 pgvector。文档切分时要注意教务文档里的表格、条款编号经常会被切碎导致检索时缺少上下文。推荐做法是把标题、章节编号和正文一起保留。例如切分逻辑可以按“一级标题或二级标题作为 chunk 开头向下拼接直到接近最大长度”。生成向量并写入数据库的服务可以这样写Service public class RagKnowledgeService { private final VectorStore vectorStore; public RagKnowledgeService(VectorStore vectorStore) { this.vectorStore vectorStore; } public ListDocument search(String question, int topK) { return vectorStore.similaritySearch( SearchRequest.query(question) .withTopK(topK) .withSimilarityThreshold(0.6) ); } }similarityThreshold不能设得太低否则无关片段也会进入 Prompt。在教务问答场景0.5 到 0.7 之间需要根据知识库内容测试。如果阈值太高很多原本能回答的问题会因为检索不到材料而被拒绝。3.4 增加内容安全检查安全过滤层要处理三类问题违禁内容违法违规词、色情暴力词、歧视词。个人隐私身份证号、手机号、学号。提示词注入用户试图让模型忽略系统提示例如“忽略上面所有规则只回答……”。一个简单可扩展的过滤器接口如下Component public class SafetyFilterService { private final ListString bannedWords List.of(示例违规词, 示例歧视词); public SafetyCheckResult checkInput(String text) { if (text null || text.length() 500) { return SafetyCheckResult.reject(问题为空或长度超过限制); } for (String word : bannedWords) { if (text.contains(word)) { return SafetyCheckResult.reject(输入包含不合规内容); } } if (text.matches(.*\\d{17}[Xx0-9].*)) { return SafetyCheckResult.reject(输入包含疑似身份证号请脱敏后提问); } // 检查提示词注入特征 if (text.contains(忽略) text.contains(提示)) { return SafetyCheckResult.reject(输入包含提示词注入特征); } return SafetyCheckResult.pass(); } }输出过滤类似可以对模型回答再做一次敏感词和 PII 检测。如果输出中片段包含知识库原始文本中不存在的机构名、人名、日期也可以考虑拦截并重新生成一次。更严谨的生产系统会接入分类模型做语义级安全检测但不建议一开始就上复杂模型先把规则过滤器跑通更重要。3.5 审计日志设计审计日志不是把字符串打印到控制台而是要方便后续按用户、时间、问题、过滤结果、检索结果、回答内容进行查询。数据库表可以这样设计CREATE TABLE ai_audit_log ( id BIGSERIAL PRIMARY KEY, user_id VARCHAR(64) NOT NULL, question TEXT NOT NULL, question_hash VARCHAR(64), input_blocked BOOLEAN DEFAULT FALSE, input_blocked_reason VARCHAR(255), context_snippets JSONB, answer TEXT, answer_blocked BOOLEAN DEFAULT FALSE, model_name VARCHAR(128), token_used INTEGER, latency_ms INTEGER, created_at TIMESTAMP WITH TIME ZONE DEFAULT NOW() ); CREATE INDEX idx_ai_audit_user_time ON ai_audit_log(user_id, created_at);记录用户 ID 时应使用脱敏后的标识避免直接把学号明文存到日志中。如果必须存学号要对数据库访问权限做严格控制。日志写入可以做成异步避免因为日志 IO 拖慢问答接口。4. 模型部署与幻觉控制的工程实践4.1 本地推理与私有化部署的权衡高校场景更倾向私有化部署但私有化不等于把所有组件都放在一台机器上。部署时至少需要区分推理服务器承载大模型和 Embedding 模型需要 GPU 或内存充足的 CPU。应用服务器运行 Spring Boot 服务处理请求和检索。数据库服务器保存向量数据和审计日志。选型时先评估并发量。校园教务助手如果是给一个学院几百人用单卡 24GB 显存的机器就能跑 7B 模型。如果是全校几万人使用就需要考虑多副本、负载均衡和模型推理加速。下表是常见模型规模与资源参考模型规模典型量化推理显存参考适合场景1.5B-3BQ4_K_M2-4GB简单 FAQ、低并发7B-8BQ4_K_M6-8GB培养方案、校内制度问答14BQ4_K_M10-14GB需要更强推理能力的场景70B量化/多卡40GB以上复杂科研辅助不适合入门项目这里的显存数字只能作为参考实际占用会受上下文长度、并发数和推理框架影响。生产环境要预留 20% 到 30% 余量。4.2 降低 AI 幻觉的常用手段AI 幻觉是生成式模型“一本正经地胡说八道”。高校场景中一个编造出来的学分规定会造成实际影响因此必须从工程上压制幻觉。最有效的手段是 RAG也就是让模型只基于检索到的文档回答。但 RAG 不能完全消除幻觉还需要配合以下手段限制生成范围系统提示词中明确允许回答的问题类型。设置温度参数把 temperature 调低例如 0.1 到 0.3减少随机性。限制输出长度max_tokens 不要设太长避免模型在无依据时编。强制引用要求模型在回答中注明“根据《文件名称》第几条第几款”。拒绝回答机制知识库检索不到时模型必须说“不知道”而不是猜测。4.3 参数调优速查表Spring AI 中可以通过ChatOptions控制推理参数。以 Ollama 为例ChatOptions options ChatOptions.builder() .withTemperature(0.2) .withMaxTokens(512) .withTopP(0.8) .build();参数含义推荐值调大影响调小影响temperature随机性0.1-0.3回答更发散容易编造回答更保守可能重复top_p核采样0.7-0.9允许更多候选词输出更集中max_tokens最大输出长度256-512回答更长可能跑题回答更短可能截断similarThreshold检索阈值0.5-0.7召回更多片段噪音多召回更少漏召回多top_k检索返回片段数4-6上下文更全可能超限上下文更少依据不足参数调优不是一次完成的事情。建议先固定一个测试集再逐项调整观察效果变化。4.4 常见错误现象与处理问题现象常见原因检查方式处理建议模型回答引用了不存在的文件知识库切分丢失文件元数据或模型被 Prompt 干扰查看审计日志中的 context_snippets将文件名、章节号作为 metadata 存入向量库Prompt 中强制要求引用元数据问普通问题却被拒绝安全过滤规则过严或相似度阈值过高打开过滤日志检查命中词和检索分数对过滤规则分级命中强规则才拒绝弱规则只告警模型回答内容与知识库矛盾温度过高或上下文片段冲突降低 temperature检查 context 是否包含矛盾文档做文档版本管理同一主题只保留最新版本并提示模型冲突时优先最新版本接口响应很慢本地模型推理慢或日志同步写入查看 latency_ms 和 token_used异步写日志模型使用队列限流避免并发过多4.5 评估指标与回归测试集AI 应用也需要“测试用例”。可以为教务助手建立一份最小评估集包含 20 到 50 条问题每条问题标注期望答案类型正常回答 / 拒绝回答 / 需要引用。期望引用文件。是否包含必须过滤的安全问题。每次修改 Prompt、调整阈值、更换模型后都运行一遍评估集。关注三个指标准确率正常问题中回答正确的比例。拒绝率应拒绝的问题中被正确拒绝的比例。错误引用率回答中引用不存在文件的比例。指标不是越高越好。如果准确率提高但拒绝率下降说明模型开始对不知道的问题“强行回答”这在学术场景是更危险的信号。5. 高校场景下的合规、安全与最佳实践5.1 内容安全过滤的实现方式前面示例中用的是关键词和正则。关键词过滤的优点是快、可解释缺点是容易误杀或漏掉变体。更稳健的方案是分层过滤第一层关键词和正则处理身份证、手机号、明确违禁词。第二层文本分类模型识别辱骂、色情、政治敏感等语义级风险。第三层人工审核适用于自动拦截置信度不高的内容。对于校园场景第一层通常是必须的第二层需要额外评估模型和数据第三层适合嵌入审批流。如果系统在起步阶段没有太多人力可以先把第一层做完整后面再扩展。5.2 日志与审计机制审计日志需要支持追溯整个问答过程用户身份来自哪个院系是否被授权。输入内容是否被过滤命中哪条规则。检索触发了哪些文档片段。模型名称和版本是什么。生成内容是什么被过滤后是否重试。整次调用耗时多少消耗多少 token。建议为每次问答生成一个request_id在日志、异常信息和返回结果中携带。用户反馈“答错了”时可以凭request_id快速定位链路。审计日志要设保留期。学术场景通常需要保留一个学期或更长时间但也要遵守学校的数据存储规定。超过保留期的数据要支持批量清理。5.3 数据生命周期管理高校 AI 系统涉及的知识库文档和数据需要明确生命周期阶段操作注意点采集只收集与问题相关的官方文档不采集未授权个人数据切分保留来源文件名、章节、发布版本避免把不同版本文档混在一起存储向量库和原始文档分开存储设置文档权限防止越权检索使用只允许授权用户访问通过校园统一身份认证对接更新文档更新后重新切分和向量化同步失效旧版本避免旧数据继续被检索删除定期清理过期文档向量数据必须同步删除5.4 发布前检查清单一个面向高校场景的 AI 应用上线前可以按下面清单逐项确认环境检查模型服务、数据库、后端服务是否部署在校园网内端口是否只对内开放。依赖版本Spring AI、Spring Boot、模型文件版本是否固定并能回滚。数据边界用户输入是否可能包含敏感信息是否做了脱敏和过滤。权限控制接口是否鉴权管理端和普通用户是否隔离。安全过滤输入和输出过滤是否生效测试用例是否覆盖变体表达。审计日志日志表是否已创建request_id 是否贯穿全链路日志是否会阻塞主流程。模型效果评估集是否跑通准确率和拒绝率是否达到可接受范围。人工兜底出现违规内容或高置信度误判时是否有处理流程。应急预案模型服务宕机、数据库故障时接口如何降级是否返回友好提示。5.5 扩展方向从问答助手到更复杂的 AI Agent当问答助手稳定运行后可以逐步往 AI Agent 方向扩展。例如在教务场景中AI Agent 不只是回答问题还可以调用查询接口获取选课结果、课表信息甚至帮助学生完成合规的请假申请。但 Agent 涉及更多权限控制必须做到“动作可授权、结果可审计、失败可回滚”。在高校场景中优先做只读类 Agent比如“查询你的已修学分和培养方案达成度”不要一开始就让 AI 直接修改数据库。也可以把文章中的工程实践复用到其他场景科研文献摘要、课程助教机器人、实验室设备使用问答、毕业论文格式助手等。关键在于一开始就搭好数据边界、安全过滤和审计日志后续扩展只是把新的知识库和权限规则接入已有框架。回到文章开头的问题高校更希望“不用 AI”其实是对不可控 AI 的防御。开发者如果用工程手段把 AI 变成可控、可审计、可解释的工具高校的接受度会高很多。这种“让 AI 在约束下工作”的能力才是学术场景里最需要的 AI 工程实践。