开局先说一个真实感受很多校园里的AI项目一开始都长一个样——某个实验室或学生团队接了个任务拿ChatGPT或国内大模型API跑通了一个Demo能在微信里回答课程问题、能生成文献综述初稿、能当智能助教。演示效果惊艳答辩顺利然后项目就“死”了。死因不是模型不行而是完全没有工程化换一个模型整个流程重写提示词散落在每个人的本地文件和聊天记录里效果好坏全凭感觉根本说不清哪些Prompt改对了、哪些改动反而让回答变差了。我去年在帮一所高校搭建校园AI中台的时候就被这三个问题反复折磨过最后沉淀出一套组合方案多模型路由、提示词版本管理和效果评估体系。这篇文章就是把完整的落地过程拆开来讲适合正在做AI应用开发、想从“单模型Demo”走向“可维护的AI产品”的开发者、技术负责人以及高校里帮老师搭AI系统的同学参考。1. 校园AI落地的真实痛点为什么需要“工程化”而不是“调API”校园环境的AI应用表面上看起来场景简单实际上约束条件比商业项目还多。这一节先把我踩过的坑摊开来说清楚后续所有的方案都是围绕这几个痛点设计的。1.1 从“能用”到“好用”校园场景的独特诉求高校里最常见的AI应用场景翻来覆去就那么几类智能课程问答助手课程信息、作业要求、考试安排、文献阅读辅助总结论文、对比观点、AI助教布置作业、批改初稿、图书馆/招生智能客服、校园内部的知识库检索问答。这些场景有一个共同的特殊性用户群体是学生和老师对回答质量的容忍度非常低但对响应速度的敏感度非常高。举个例子我做过一个面向大一新生的校园问答助手学生问“这学期高数补考是什么时候”如果系统吭哧吭哧等上8秒才回复学生立刻觉得这玩意儿是废物下次就不再用了。而同样的问题如果答错了哪怕只错一次也会被截图发到班群里“公开处刑”。这种容错率比绝大多数商业客服场景都要苛刻。另一个容易被忽略的问题校园项目的开发人手极度不稳定。学期初可能有三四个研究生投入期末全去赶论文了留下一个半成品。如果代码和提示词没有一套明确的工程规范换个人接手就得重新从阅读代码开始项目几乎必然烂尾。我见过太多校园AI项目死在“核心开发同学毕业”这个时间点上。1.2 单模型架构的“三座大山”不做工程化、只调单个模型API的校园AI应用通常会撞上三堵墙第一堵墙模型单点故障。你接的是某个云厂商的模型API某天它服务不稳定、报错率上升或者干脆限流了你的应用就完全瘫痪。我遇到过一次真实事故合作方用的模型服务商在考试周前一天晚上突然大规模超时而学校的课程问答助手恰恰在那天晚上迎来了流量高峰结果学生全在问“系统怎么挂了”、“明天考试范围到底是什么”体验直接崩盘。第二堵墙提示词没法管理和演进。校园项目迭代极快每个学期都有新需求今天要加“严格按照2024版培养方案回答”明天要加“如果学生有情绪化表达要先安抚再回答”这些逻辑几乎全写在提示词里。但提示词放在代码的字符串里、放在Jupyter Notebook里、放在飞书文档里、放在同学的个人便签里——改一处忘了另一处版本对不上出了Bug都不知道是代码的问题还是Prompt的问题。第三堵墙效果说不清道不明。老师问“为什么有些问题回答有些问题不回答为什么有的回答好有的回答差”如果你只能回答“感觉换了提示词之后好一点吧”那项目在汇报时基本等于没穿衣服。没有多维度的量化评估指标就没有调优的依据也没有向学校展示项目价值的证据。1.3 工程化目标不是大厂平台而是一套可控机制我在设计方案时反复提醒自己不要过度设计。校园项目的资源就那么多不可能上K8s、搞完整的MLOps平台。工程化的核心目标只有四个可控任何一次提示词变更、模型切换都有记录出了问题能回滚。可量化每一次回答的好坏都能用指标表达迭代优化有理有据。可复用新的校园应用比如新开一门课的AI助教能复用同样的体系而不是从零开发。可交接任何人接手项目扫一眼文档和目录结构就能明白系统怎么运转。后续的多模型路由、提示词版本管理、效果评估全部围绕这四个目标展开。2. 多模型路由不让任何单一模型决定体验上限如果说整篇文章只能留一个方案我一定留多模型路由。它解决的是“模型能力、成本、稳定性的平衡”问题也是校园AI应用工程化的地基。2.1 路由的必要性不同模型各有所长组合使用才划算很多人的第一直觉是选一个“最强”的模型所有请求都走它不就行了这个想法在校园场景下有两个漏洞。第一最强模型的成本往往是普通模型的几倍甚至几十倍。校园项目预算本来就紧张全校师生的问答请求量上去了以后费用是肉眼可见在烧。第二最强不是全能的。我实测过有些通用大模型在“从结构化课程表里查信息”这类任务上反而不如一个小而专的模型好用后者响应更快、格式更稳定。也就是说不同的任务类型本身就有“更擅长它的模型”这不是玄学是工程现实。路由要做的事非常简单在请求进来的那一刻决定由哪个模型来处理它并且让这个决策有依据、可回放、能优化。2.2 路由决策的输入信号路由不能瞎转需要有一组判断依据。我设计的路由决策模型核心参考以下几个信号信号说明示例任务类型分类标签决定模型选型方向知识问答、摘要生成、意图识别、文本改写输入长度直接影响模型上下文窗口和成本短文1K、中长文1K-8K、长文8K输出格式要求是否需要JSON结构化输出或特定格式普通文本 vs. 需严格JSON Schema成本预算不同模型单价差异大高成本模型仅限关键任务用户等级/场景是否为老师端、是否为演示场景全校公共问答 vs. 实验室内部工具实时可用性健康检查结果主模型故障时切换到备用模型以我做的课程问答助手为例路由逻辑是这样的如果是简单的课程信息查询“老师办公室在哪”“作业提交截止到什么时候”走本地部署的轻量化模型成本低、速度快典型响应在1秒内。如果是文献总结、长文本理解给学生上传了一篇论文要总结走云端大模型延迟高但理解力好。如果是学生情绪宣泄或极端提问直接走内容安全过滤通道不调用生成模型而是返回预设的安抚话术或提示学生联系辅导员。这样一来高成本模型的调用占比从100%降到了大约25%月度API账单下降了七成多而用户体验因为响应变快反而更好。这就是路由的直接价值。2.3 落地路由策略从规则路由到“小模型分流”路由策略的复杂度可以分几档我建议校园项目从最简单的一档开始不要一上来就搞基于embedding的语义路由。第一档基于规则的关键词/正则路由。给每个任务类型配置一组触发关键词和正则模式比如包含“论文、文献、综述、研究方法”就走文献处理链路包含“补考、重修、成绩、学分”就走教务问答链路。这个方案的好处是零模型成本、延迟为0、逻辑完全可控。缺点是遇到没覆盖到的说法会路由错误。所以规则要经过一个“爬虫式”的积累过程从历史对话日志里挖高频问题不断补充触发词。第二档基于小模型分类器的意图路由。用文本分类模型甚至可以直接调用价格极低的分类API对用户问题做意图识别输出概率分布再根据置信度决定路由目标。这一档能处理口语化、多样化的表达比纯规则鲁棒得多。我当时用一个三四万条真实校园问答标注数据微调出来的分类器意图识别准确率超过96%完全够用。我的建议是两档结合先跑规则命中不了再交给分类模型兜底。这样既保证高频问题的确定性又具备对长尾问题的泛化能力。2.4 降级与容错路由不只要“选对”还要“救急”多模型路由体系里最重要但最容易被忽略的模块是降级方案。我在校园项目里遇到过不止一次模型服务商大规模故障如果路由只具备“分发”功能而没有“降级”能力那和单模型就没有本质区别。降级的思路是分层兜底云端主模型 → 云端备选模型当主模型连续3次请求超时或返回错误码路由自动将流量切换到同级别的备选模型。这个切换粒度可以是“每5分钟评估一次”避免频繁抖动。云端大模型 → 本地轻量模型如果云端全部不可用这种情况极少但我确实遇到过路由将请求降级到本地部署的小模型虽然回答质量会下降但至少保证服务不中断、学生能拿到一个可用的回答。对于校园场景来说“有响应”比“最优响应”更重要。兜底话术如果连本地模型都超载就返回预设话术“AI助手暂时繁忙请稍后再试或联系XXXX。” 这看起来简单但没有兜底话术的后果就是系统直接报错甚至白屏对学生来说体验极差。为了方便排查每次路由决策我都会记录一条结构化日志包含请求ID、时间戳、用户输入摘要、路由依据规则命中还是模型分类、选中的模型名称、各候选模型当时的健康状态、最终响应耗时。这套日志后来成了效果评估体系的数据来源之一。此外校园项目常常有多套环境开发环境、测试环境、生产环境路由配置必须和环境解耦。我通常将这些内容放在配置中心或环境变量里比如通过Spring AI这类框架的配置抽象来管理而不是硬编码在代码里。3. 提示词版本管理把提示词当作一等代码资产多模型路由解决的是“谁来回答”的问题而提示词决定的是“回答得好不好”。然而校园AI项目里提示词恰恰是最不受重视、最混乱的东西。这一节我说说如何把提示词管起来像管代码一样管它。3.1 提示词失控的典型现状我相信很多做过AI应用的人都有这样的经历调试某个Prompt反复试了几十个版本最后跑通的版本是“加了这句话之后突然变好了”但为什么变好说不清楚。后来另一个同学接手看着一大段Prompt无从下手也不敢改因为“一动效果就崩”。校园项目里面提示词常见的存放位置包括代码里的f-string、Jupyter notebook的某个cell、飞书文档表格的某一列、微信群聊记录里的某条消息、某个人电脑上的.txt文件。提示词一旦变成这样就谈不上管理了。更严重的是同一个意图在不同位置被分别写了N套不同的表达。比如“AI助教”这个应用课程答疑一套提示词、作业辅导一套提示词、实验报告反馈一套提示词三套之间互不相同又互相影响。改动一个地方不会自动同步到其他地方出问题的概率可想而知。3.2 用Git管理提示词把提示词当代码管最直接的手段就是纳入Git版本库。我在项目里专门建了一个prompts/目录结构大概长这样prompts/ ├── agents/ │ ├── course_qa/ │ │ ├── v1.0_base.txt │ │ ├── v1.1_add_format.txt │ │ └── v1.2_add_emotion_response.txt │ ├── document_summary/ │ │ └── v2.0_base_with_json_schema.txt ├── common/ │ ├── system_prompt_base.txt │ └── guardrails.txt ├── templates/ │ ├── fewshot_course_qa.yaml │ └── output_schemas/ │ └── course_info_response.json └── CHANGELOG.md每个提示词文件都有独立的版本号v1.0、v1.1文件名里带上版本和改动要点比如v1.2_add_emotion_response.txt这样Git历史里不仅能看到变更还能从文件名直接知道每个版本的重点。这里需要特别注意提示词里的具体业务信息要与提示词本身解耦。比如课程名称、老师姓名、作业截止时间这类内容是高频变化的不应该硬编码在提示词文件里而是通过模板变量注入。我自己用的做法是提示词是一个带{{variable}}占位符的模板业务数据从知识库或数据库查出来之后再填充进去。这样改业务数据不用动提示词改提示词不用碰业务数据。3.3 提示词版本化和代码发布如何联动提示词的改动直接影响线上系统的行为不能随手改了就算完。我在项目里做的流程是开发者在本地改提示词模板文件。在测试环境里用一批“黄金测试集”跑一遍确认效果没有回退。发Pull Request由至少另一个同学进行Code Review重点看Prompt措辞是否引入安全风险或答案偏差。合并到main分支后通过CI流水线将提示词部署到线上。这里的部署指的不是“放个文件到服务器”而是把提示词内容保存到配置中心或数据库中线上应用在运行时动态读取。线上运行一段时间观察效果评估指标下一节会详细说如果有问题一键回滚到上一版本。这个流程的核心理念是用代码变更的规范来管理提示词变更。刚开始团队会觉得太繁琐但跑过一次“改了一句话导致所有答案带上了错误信息”的事故之后所有人都认可了这套流程存在的意义。另外校园项目常常会有同一个Prompt在不同版本模型上的兼容性问题。比如模型供应商升级了模型版本原来要求模型输出“课程代码课程名”的JSON格式新模型可能会把字段顺序打乱或者多出一个字段。所以提示词版本管理还要跟模型的版本管理绑定我的习惯是在提示词文件的头部加上一段备注写明这个版本适用于哪个模型、哪个日期之前测试通过。Changelog里也会记录每个提示词版本对应的模型版本。3.4 提示词模板化与Few-shot案例管理提示词不只是“一段文字”它往往还包含少量示例few-shot examples。管理few-shot案例比管理提示词本身更琐碎因为你不仅要管“这些案例存在哪”还要管“这些案例的质量和分布”。我的建议是不要把few-shot案例直接写在提示词文件末尾而是单独放在YAML或JSON文件里在运行时由代码加载后拼接到提示词中。这样做的好处是案例可以像数据一样被单独增删改不会污染Prompt的主结构。比如课程问答助手的few-shot案例文件结构如下examples: - user_input: 高数补考什么时候 assistant_response: 根据教务系统显示本学期高等数学补考时间是2025年3月8日上午9:00-11:00地点在三教201教室。请携带学生证和准考证参加。 note: 标准日期类问答注意格式 - user_input: 我挂科了怎么办…真的好难受 assistant_response: 同学别担心挂科并不代表学习能力有问题。建议你先查看教务系统的补考安排同时可以约任课老师在答疑时间聊一聊试卷中的薄弱点。如果需要心理支持也可以联系学校心理健康中心。 note: 情绪安抚类先共情再给信息案例的数量不用多每个场景5-10条就足够但必须覆盖典型的边界情况。把这些案例当作数据资产来管和提示词版本一起走Git流程。这样当模型升级导致few-shot效果变差时你能够知道是哪些案例在什么时候加进来的、当时基于什么考虑而不是一脸茫然。4. 效果评估体系没有量化反馈优化就是空中楼阁做校园AI项目最常见的汇报方式是“你看它能回答这个问题回答得还不错”。这种演示型验证在项目初期有效但它无法回答真实运营状态里最重要的三个问题它到底帮了多少人它有没有在关键问题上出错改动Prompt之后是把系统变好了还是变差了要回答这些问题必须有一套效果评估体系。4.1 先定义清楚什么算“好回答”评估的前提是把“好”拆解成可测量的维度。我在校园项目里用的评估维度如下评估维度说明测量方式回答相关性Relevance是否针对用户问题给出了直接、相关的回答LLM打分或人工评分1-5信息准确性Accuracy是否存在事实性错误尤其是课程/教务类硬信息人工抽检程序化校验如课程名正则比对格式合规性Format输出是否匹配预定的JSON结构/列表/分段程序自动校验内容安全性Safety是否包含不当、有害信息是否有效拒绝敏感话题安全模型检测人工抽检响应延迟Latency从请求发出到完整回答返回的时间程序自动采集成本Cost单次请求的模型调用成本程序自动统计每个维度设立一个最低通过阈值达不到阈值的回答计入“失败案例”。比如我的系统里规定课程信息类的准确率必须达到95%以上平均数相关性评分不低于4.0/5.0响应延迟P95不超过5秒成本单次不超过0.05元。一旦某类指标连续下滑就触发告警并进入排查流程。4.2 评估数据从哪来黄金测试集和线上日志缺一不可评估体系需要两类数据一类是“离线评估集”一类是“在线运行日志”。离线评估集我习惯叫它“黄金测试集”是从真实对话日志中筛选出来的有代表性的高质量问题集覆盖所有任务类型目标数量不少于300条并包含每个问题的标准答案和评估标注。这就像软件工程里的单元测试用例每次提示词变更或模型切换先用它跑一遍回归测试。我不建议从一开始就追求几千上万条测试数据校园项目没有那个标注资源。300条精心维护的测试集已经能抓出绝大多数明显回退的问题。在线运行日志是效果评估的“第一现场”。每一条线上请求的处理结果都可以通过异步任务做一次自动评估。我通常会用一个小模型来给大模型的回答评分就是用一个模型评价另一个模型实践下来相关性、格式等维度的打分足够可信然后再对一定比例的数据做人工抽检兜底。在线评估数据比离线测试集更能反映真实分布。比如某天学生集中问“毕业实习学分怎么认定”这些真实问题会进入当天的评估样本如果系统回答准确率低于阈值就能立刻发现并介入。4.3 基于评估的Prompt迭代闭环效果评估体系最大的价值是让“调提示词”从玄学变成工程。我自己总结了一套适合校园项目的迭代闭环发现问题通过在线评估或人工反馈发现一个失败案例例如“系统把2024级培养方案答成了2022级”。分析归因翻出这个案例对应的提示词版本、模型版本和路由日志确定是提示词引导不够、还是知识库数据缺失、还是路由分配错了模型。设计改进针对归因修改提示词模板或者补充few-shot案例。改动要尽量小而聚焦不要一次改一堆东西否则无法判断是哪个改动生效。离线回归用黄金测试集跑一遍新提示词确认旧的功能没坏且该失败案例已修复。小流量灰度新提示词版本先让5%-10%的流量使用对比新老版本的评估指标。发布或回滚灰度指标优于或持平老版本则逐步放开至全量否则回滚并记录失败原因。沉淀案例把这次问题、分析、解决的过程写进评估报告/变更记录形成知识库。这个闭环最核心的原则是“一次只改一个变量”但很多人做不到。我见过一个同学在一次迭代里同时改了提示词结构、换了模型、加了few-shot结果效果变差了他根本不知道是哪个环节的问题最后只能全部回滚重来。4.4 人工反馈渠道别忽视学生和老师的声音自动化评估再完善也替代不了真实用户的感受。我在校园项目里设计了一套简单但有效的人工反馈机制每次AI回答的界面下方提供“有帮助/没帮助”两个按钮并附带一个选填文本框让用户写出期望的回答。这个按钮的数据虽然粗糙但量大了以后能反映趋势。每周从“没帮助”的样本里随机抽取50条做人工复盘由项目组的同学逐条阅读并分类是回答错误、是答非所问、是语气生硬还是数据过期。每学期末邀请使用系统的老师做一次深度访谈专门收集那些自动评估发现不了的“软性”问题比如“回答太啰嗦”“感觉像是复读机”这类主观感受。有一次我们通过反馈渠道发现很多学生问“这门课期末怎么考”时AI回答虽然内容正确但太啰嗦学生只看第一句话就走了。后来我们在提示词里加了一条指令“回答应优先给出简洁结论再附详细说明”这一条改动让“有帮助”点击率提升了将近10个百分点。这就是人工反馈带来的价值光靠自动评估指标很难发现这种细微体验问题。5. 稳定性、成本与合规校园环境特有的工程约束前三节讲完了核心框架这一节讲校园落地时最容易被忽视但在生产环境里真正决定生死的三条约束稳定性保障、成本控制和数据安全合规。作为一个在校园环境里摸爬滚打过的人我敢说这几条才是项目能不能持续运营的胜负手。5.1 统一接入层把“裸调API”升级为“受控调用”很多校园项目的API Key直接写在代码里或者放在前端请求里这种裸调用方式有巨大的安全隐患和成本风险。一旦Key泄露任何人都可以拿着你的Key去疯狂调用模型月底账单直接爆掉。我的建议是加一层统一的API接入层所有AI请求都经过这个网关。这个网关负责几件事Key统一管理不在业务代码里直接暴露任何模型API的KeyKey只存在于后端配置中心。调用配额与频率限制对每个用户、每个应用设置每分钟/每天的最大调用次数。校园里经常发生“某个班的同学同时刷同一个AI助手”导致限流的事配额管理能有效防止这种情况。成本告警与熔断设定月度成本预算当成本达到预算的80%时告警达到100%时自动熔断高成本模型切换到低成本或本地模型。审计日志完整记录每一次请求的应用来源、用户标识、模型名称、提示词版本、用量和费用。这不仅是排查问题的依据也是当老师询问“这个月AI开销为什么这么大”时的解释凭证。早期项目里我甚至见过直接暴露在Nginx配置里写死另一个团队的API Key后来对方团队发现账单一路狂飙找上门来才发现是这个原因。统一接入层之后这个问题就彻底解决了。5.2 校园网络与预算限制本地小模型做兜底云端大模型做增强校园网络环境的稳定性说实话并不总是理想。有的学校出口带宽在白天高峰期特别拥挤云端模型API的延迟会明显上升甚至出现大量超时。针对这个问题我采用的架构是“混合模型双轨制”轻量级、高频且格式化的请求优先走本地部署的小模型比如7B-14B级别的开源模型。本地说不上高质量但胜在响应稳定、几乎零成本、数据不出校园内网。重理解、长文本、需要深度推理的请求走云端大模型。由于这类请求占比不大即使偶尔延迟也可以接受。这套架构需要注意“本地模型的模型能力边界”。校园问答场景里大量问题是事实性、表格化的查询本地小模型完全能胜任但像“帮我把这段代码逐行讲解一下”这样的任务本地小模型基本答不好必须路由到云端大模型。所以路由决策时要把“模型能力边界”作为约束条件考虑进去不要让本地模型处理它明显做不了的任务。另外本地部署模型时要考虑推理加速。我用的是vLLM它对并发请求的处理能力远强于原生HuggingFace的transformers pipeline而且支持动态批处理能把GPU利用率拉高一大截。对于校园项目一台双卡3090/4090的服务器跑7B-14B模型做高频简单问答基本够用。不要一上来就追求70B大模型在本地跑硬件成本和维护成本都扛不住。5.3 数据合规与内容安全学生隐私是不可逾越的红线校园AI应用处理的数据里有大量学生个人信息学号、成绩、课程表、心理状况等如果这些数据被当作普通文本发给外部模型服务商从合规角度讲是有风险的。虽然很多时候学校没有严格的法务来审查但一旦出问题比如学生成绩数据泄露整个项目可能被直接叫停这种风险必须提前规避。实操层面的几个原则遵循最小化原则AI请求里只携带完成任务所必需的信息能脱敏就脱敏。比如查询“学生挂科怎么办”时不需要把学生的姓名、学号传给模型只需要把问题文本传过去即可。隐私数据不出内网涉及学生成绩、心理辅导等敏感场景的请求一律走本地模型禁止发往外部API。内容安全前置过滤用户输入模型之前做一次安全检查过滤掉辱骂、极端敏感的内容或明显不属于校园业务的问题。这个前置过滤可以用规则加分类模型组合实现拦截率能做到很高。我还专门在提示词里设计了一条“安全护栏”当用户要求你发表涉及违法违规、伤害他人、极端观点等内容时必须拒绝回答并温和地引导用户咨询学校相关部门。这条护栏作为guardrails.txt在Git里独立管理不允许任何人随意删除。内容安全在校园环境里是底线再怎么强调都不过分。5.4 从“个人的项目”到“可持续维护”最后一条算是我给所有校园AI项目团队的过来人建议项目是否可持续取决于“如果主力开发离开后剩下的人能不能接手”。我见过太多校园项目核心开发一毕业系统立刻进入“苟延残喘”模式——没人敢动代码新需求堆积没人接。要让项目可持续至少要做三件事把工程化体系写进项目文档文档不能是一篇Installation Guide而是要包含“如何新增一个AI应用”“如何修改提示词”“如何评估指标变化”“如何接入新模型”这四类操作说明。每一条都要有具体的操作步骤别写空话。保持架构的简单性。能用一个脚本解决的不要做成微服务能用数据库存配置的不要上分布式配置中心。校园项目的人力流动决定了越简单的架构越长寿。定期做知识传递。每个学期末安排一次“系统架构讲解会”让低年级同学了解全貌。不要指望靠个人“传帮带”要靠在流程和文档里固化的机制。我见过几个校园AI项目因为坚持了这些原则在核心成员换了三轮之后依然在稳定运行而且不断有新应用接入。反过来那些不重视工程化、靠一两个人硬扛的项目无一例外都死在了成员更替上。如果你是想长期运营一个校园AI项目的人请把这句话刻在脑子里你的代码和提示词不是写给你自己看的是写给你的下一任看的。