企业官网建设流程全解析

大学校园里，“是否允许学生使用 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 核心模块划分

系统可以拆成五个模块，每个模块职责单一：

模块之间通过接口调用，不要把过滤逻辑写在 Controller 里，也不要把模型调用逻辑和业务逻辑混在一起。这样后续替换模型、增加人工审核、调整过滤规则都不会影响整体结构。

2.3 数据流与部署边界

一次完整问答的数据流向是这样的：

1. 用户提交问题。
2. 接入层校验用户身份和问题长度。
3. 安全过滤层检查输入是否包含违规内容或提示词注入特征。
4. RAG 检索层将问题向量化，在向量库中检索相关文档片段。
5. 构建 Prompt，将检索结果和用户问题一起发送给本地大模型。
6. 模型生成回答。
7. 安全过滤层对输出内容再次检查。
8. 审计日志层记录输入、输出、耗时、检索命中等信息。
9. 接口返回回答。

这里的核心边界是：用户输入和模型输出都不可直接信任。两个方向都要过过滤层；向量库中的文档必须经过权限审核；模型只能依赖检索到的文档片段回答，而不是凭空生成。

2.4 技术选型表

在实际项目中，技术栈可以根据团队情况调整。下表是一组能够支撑上述架构的选型参考：

如果原始项目没有明确规定版本，落地前要先确认依赖版本。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.st

pom.xml 中加入 Spring AI、PostgreSQL JDBC 驱动、pgvector 相关依赖。注意 Spring AI 的 starter 名称可能随版本变化，示例只说明依赖方向：

<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>org.springframework.ai</groupId> <artifactId>spring-ai-ollama-spring-boot-starter</artifactId> </dependency> <dependency> <groupId>org.springframework.ai</groupId> <artifactId>spring-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 List<Document> 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 List<String> 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 模型。如果是全校几万人使用，就需要考虑多副本、负载均衡和模型推理加速。下表是常见模型规模与资源参考：

这里的显存数字只能作为参考，实际占用会受上下文长度、并发数和推理框架影响。生产环境要预留 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();

参数调优不是一次完成的事情。建议先固定一个测试集，再逐项调整，观察效果变化。

4.4 常见错误现象与处理

4.5 评估指标与回归测试集

AI 应用也需要“测试用例”。可以为教务助手建立一份最小评估集，包含 20 到 50 条问题，每条问题标注：

• 期望答案类型：正常回答 / 拒绝回答 / 需要引用。
• 期望引用文件。
• 是否包含必须过滤的安全问题。

每次修改 Prompt、调整阈值、更换模型后，都运行一遍评估集。关注三个指标：

• 准确率：正常问题中回答正确的比例。
• 拒绝率：应拒绝的问题中被正确拒绝的比例。
• 错误引用率：回答中引用不存在文件的比例。

指标不是越高越好。如果准确率提高但拒绝率下降，说明模型开始对不知道的问题“强行回答”，这在学术场景是更危险的信号。

5. 高校场景下的合规、安全与最佳实践

5.1 内容安全过滤的实现方式

前面示例中用的是关键词和正则。关键词过滤的优点是快、可解释，缺点是容易误杀或漏掉变体。更稳健的方案是分层过滤：

1. 第一层：关键词和正则，处理身份证、手机号、明确违禁词。
2. 第二层：文本分类模型，识别辱骂、色情、政治敏感等语义级风险。
3. 第三层：人工审核，适用于自动拦截置信度不高的内容。

对于校园场景，第一层通常是必须的，第二层需要额外评估模型和数据，第三层适合嵌入审批流。如果系统在起步阶段没有太多人力，可以先把第一层做完整，后面再扩展。

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 工程实践。