简介：大模型技术正加速渗透教育信息化场景，其中以自然语言理解为核心的智能阅卷成为典型落地方向。传统阅卷系统受限于规则引擎，难以对主观题进行语义级评判，而结合OCR识别与生成式大模型，可实现对语文作文、政治简答等开放题型的自动评分与多维反馈。这类系统通常采用多层架构，通过提示词工程拆解评分维度，配合多轮采样与人工复核机制保证评分一致性，从而在真实教学环境中达到可用标准。从试卷扫描、区域切分到成绩统计，大模型驱动的阅卷平台不仅显著提升教师批改效率，还能沉淀学情数据用于精准教学。一套基于文心大模型的智能阅卷系统完整呈现了上述技术路径，覆盖架构设计、评分策略与落地实践。 做教育信息化这些年，阅卷系统是我接手过需求最明确、但技术坑也最多的项目之一。学校要的不只是把客观题扫出来，而是真正把老师从主观题批改里解放出来。所以当文心大模型的接口能力成熟之后，我意识到这条路终于可以走通了——这套“基于文心大模型的智能阅卷系统平台”就是把大模型放进传统阅卷流程的一次完整落地实践。
这套平台覆盖从试卷扫描、答题区域切分、OCR识别，到主观题自动评分、人工复核、成绩统计导出的完整链路，核心是用文心大模型处理过去规则引擎完全搞不定的开放式试题，比如语文作文、英语书面表达、政治简答、历史论述。我在设计时就确定了目标是“让系统能真正被学校用起来”，而不是做一个只能在演示环境里跑通的demo。
如果你是教育信息化从业者、正在做AI应用落地的后端工程师，或者想了解如何把大模型接进真实业务系统的开发者，这篇文章值得完整看完。我会把平台整体设计思路、核心模块的拆解方式、评分引擎的提示词工程、工作流编排细节，以及我在实际部署运维中踩过的坑，全部整理出来。
1. 项目定位：阅卷系统的传统短板与大模型的破局点
1.1 传统阅卷系统长期存在的三个痛点
过去几年市面上常见的阅卷系统大多走的是“扫描识别+客观题比对”的路子。客观题通过答题卡读取填涂信息就能稳定判分，但一旦遇到需要理解语义的主观题，传统方案基本束手无策。我见过不少学校仍然采用“机器扫客观题+老师手动批主观题”的混合模式，这套流程最大的问题在于主观题批改依然占用大量人力，一场模考几百份试卷，语文组老师要连续批改一整天，效率瓶颈非常明显。
第二个痛点是反馈维度的单一性。传统系统只能告诉学生“这道题对了还是错了”，完全没有办法解释“为什么丢分”。老师在批改作文时写下的评语、指出的具体问题，这些宝贵的个性化反馈在传统流程中很难被沉淀和复用。
第三个痛点是应用场景割裂。扫描、识别、批改、统计分散在不同系统里，数据要反复导来导去，老师光是处理格式就耗费不少精力。这些问题叠加在一起，导致阅卷系统在学校的实际使用率一直不高，很多学校买回去以后又退回纯人工模式。
1.2 为什么大模型而不是规则引擎
传统规则引擎做主观题评分的思路是关键词匹配加正则表达式，比如一篇作文里出现了“坚持”“努力”“梦想”几个预设关键词，就判定分数区间。这种方案看起来简单，实际效果非常差。学生的表达千差万别，同样的意思可以用完全不同的方式写出来，靠关键词命中来判断质量，误判率会高到无法投入使用。
大模型的核心优势在于语义理解能力。它能读懂一段学生作答文本在说什么、有没有扣题、逻辑是否完整、表达是否恰当，这些能力恰好对应阅卷评分时老师真正关注的维度。以文心大模型为评分引擎，系统不再依赖关键词字典，而是把评分标准和参考答案作为上下文输入，让模型在理解语义的基础上输出结构化评分结果。
我选择的切入点是主观题评分，而不是全流程替换。保留传统系统稳定的扫描、图像处理能力，把大模型嵌进最需要智能化的评分环节，这样既降低了落地风险，又能在教学场景中快速看到价值。
2. 方案选型与整体架构设计
2.1 为什么选文心大模型作为评分引擎
项目启动时我对比过几类方案，选择文心大模型并不是因为它各项指标都绝对领先，而是综合考量了三个现实因素。
第一是中文语义理解的适配性。阅卷场景处理的是大量中文文本，尤其是语文作文和简答题，文心系列在中文语料上的训练更充分，实际测试中对于“表达是否通顺”“观点是否明确”这类判断的稳定性要优于我用同样预算测试的其他方案。
第二是接口形式与开发成本。文心大模型通过API方式提供服务，我可以直接通过HTTP调用，不需要自己维护推理集群，对于做应用系统开发来说部署成本很低。平台开发阶段我把主要精力放在业务流程和评分策略上，而不是去啃模型部署和GPU调优。
第三是内容安全与合规要求。教育行业对数据安全比较敏感，文心大模型在国内提供服务，调用链路上的合规性风险更可控，学校侧也更容易接受。虽然模型本身不开源，但作为应用层开发者，我关注的是它能不能稳定输出我要的结果，而不是底层权重细节。
2.2 平台整体架构与核心模块划分
整个平台从逻辑上划分为四层，每一层的职责边界非常清晰。
底层是数据存储层，使用MySQL保存考试、题目、答题卡、评分结果等结构化数据，Redis用于缓存任务状态和热点数据，对象存储服务存放扫描件和切分后的答题图片。
中间是业务逻辑层，包含试卷模板管理、答题区域切分、OCR识别、任务调度、评分服务、人工复核、成绩统计七个核心模块。这层是平台开发工作量最集中的部分，每个模块都设计成独立的Spring Boot服务，通过API网关统一暴露接口。
再往上是接入层，对接文心大模型API和OCR识别API。接入层的设计重点是做超时控制、重试机制和结果缓存，避免外部服务波动影响核心流程。接入层内部还做了一个结果修复模块，专门处理大模型返回的非预期格式。
最上面是应用层，面向管理员、教师、学生三种角色提供不同功能。管理员可以创建考试、配置试卷模板、查看系统运行状态；教师可以设置评分标准、发起自动批改、对分歧结果进行人工仲裁；学生可以查看成绩、评语和知识薄弱点分析。
2.3 技术栈选型与实际理由
后端采用Spring Boot 3.x，这是团队最熟悉的技术栈，生态成熟，真要出问题排查起来快。前端使用Vue 3加Element Plus，教师端页面有大量的表单配置和表格展示，这套组合做后台管理类界面效率很高。
数据存储上MySQL 8.0用于核心业务数据，试卷图片存在MinIO里。这里有个实际考量，阅卷系统会产生大量图片文件，MinIO部署简单，API兼容S3协议，后面想切到云对象存储也不会改代码。
OCR部分我没有自己做模型训练，直接对接了现成的OCR接口，重点放在手写体识别能力上。评分引擎对接文心大模型的ERNIE系列接口，通过千帆平台统一管理API Key和配额。
消息队列用的是Redis Stream。选它不是因为功能多么强大，而是因为在这个场景里真的够用。阅卷批改任务的并发峰值为每秒几十条消息，Redis Stream完全能扛住，还能少维护一套消息中间件，部署架构也精简不少。
2.4 API选型与并发设计细节
文心大模型平台提供了多种规格的模型接口，我的实际使用经验是：答题区域短文本评分用ERNIE Speed这类响应更快的模型，作文等长文本评分用ERNIE-4.0-Turbo这类推理能力更强的模型。不同题型走不同模型，不是一刀切。
并发设计上，平台侧做了两层控制。第一层是任务并发限制，通过Redis实现令牌桶限流，防止批量批改时瞬时请求量打爆API配额。第二层是线程池隔离，评分任务和OCR识别任务使用不同线程池，避免一个环节阻塞影响另一个环节。
当时实测的QPS控制在20左右，单题平均耗时约2.3秒，2000份试卷5道主观题的批改任务大约需要20分钟跑完。老师可以一边上课一边等着结果出来，这个效率在实际使用中完全够用。
3. 试卷预处理与文本识别建模
3.1 扫描图像预处理流程
试卷扫描后拿到的原始图片质量参差不齐，有的偏暗、有的倾斜、有的带无关标记。预处理环节我做了灰度化、透视校正和去噪三步处理。灰度化让后续边缘检测更稳定，透视校正是关键，扫出来的试卷多少有点歪斜，不用透视变换校正的话，答题区域会切割不准。
透视校正的实现方法是先通过轮廓检测找到试卷外边框的四个顶点，再计算变换矩阵，把试卷区域映射到标准矩形。这里要特别注意，不同扫描仪的边框粗细不一样，轮廓检测时要做一个简单的膨胀操作，把边缘连接成完整的封闭轮廓，否则顶点定位容易失败。
去噪用的是高斯滤波加自适应阈值二值化。高斯滤波能去掉扫描产生的椒盐噪声，自适应阈值能处理光照不均的问题。这套流程跑下来，在600DPI扫描件上的区域定位误差控制在2个像素以内，对后续切分来说足够用了。
3.2 答题区域切分与模板配置机制
答题区域切分是整个识别流程中最容易翻车的环节。一开始我尝试过纯图像特征自动识别题目区域，效果不稳定，后来改成了模板配置方式——教师第一次使用某套试卷模板时，在页面上用鼠标框选出每道主观题的答题区域，系统保存每个区域的归一化坐标。
归一化坐标是切分模块的一个关键设计。保存的不是绝对像素坐标，而是相对于整张试卷图片宽高的比例值。这样即使同一套试卷每次扫描尺寸有细微差异，也能准确定位到答题区域。区域模板数据以JSON格式存储在数据库中，包含区域编号、所属题型、归一化坐标范围等信息。
后续正式扫描时，系统读取试卷模板，把每个答题区域对应的图片区域裁剪出来，单独保存。将区域图片和整卷图片分开存储的设计，让我在后续做OCR识别和评分时不用重复处理大图，节省了大量I/O时间。
3.3 OCR识别与文本重建
答题区域裁剪完成后，进入OCR识别环节。对于印刷体识别，我用的OCR接口准确率很高，实测在干净试卷上能达到99.2%的识别准确率。但主观题的难点在于手写体识别，尤其是连笔字和学生涂改痕迹，识别率会明显下降。
针对手写体识别，我做了两个优化。一是在调用OCR接口时开启手写体识别模式，这个参数对识别率提升非常明显。二是在识别完成后增加文本置信度标记，对于单字置信度低于阈值的内容，在最终送给大模型评分前做特殊处理，告诉模型“这段文字可能存在识别错误，请结合上下文理解”，让模型不要对个别错字过度敏感。
文本重建模块负责把OCR返回的文本按答题区域重新组织，把识别的片段时间顺序拼接，清除明显的乱码和空白行。值得注意的是，有些学生会在答题区域用箭头标注补充内容，这些在传统的文本重建里很难处理，我在设计时直接选择了忽略箭头标注部分，因为这类情况比例不高，处理成本和收益不成比例。
4. 评分引擎：核心提示词设计与评分策略
4.1 评分流程设计思路
评分引擎是整个平台技术含量最高的部分，设计原则是“不要大模型直接给总分”。最开始我尝试过让模型直接打分，结果分数波动非常大，同一篇文章的两个批次调用能差出10分。后来改为按维度拆解评分，每个维度单独打分、单独写评判依据，最后在平台侧合成总分。
这种设计有三个好处。一是评判逻辑更透明，每个维度都能看到评分理由，教师复核时不用逐字推导模型的想法。二是维度分可以用于生成详细的学情反馈，告诉学生哪一块丢分多。三是维度拆分以后，分数波动明显收敛，因为模型对“语言表达是否流畅”这类单维度判断的稳定性远高于对“整篇文章值多少分”的整体判断。
评分模块的核心流程是：接收OCR识别的学生作答文本、读取评分标准配置、组装提示词、调用大模型、解析返回结果、校验一致性、写入评分结果表。
4.2 主观题评分提示词模板实例
提示词模板我整理成了平台内的可配置资源，不同学科、不同题型对应不同模板。下面是一套用于简答题的模板，这个版本经过多轮迭代，在稳定性上的表现让我比较满意。
你是经验丰富的中学政治阅卷教师，请对以下学生作答进行评分。 题目：{{question}} 参考答案要点：{{reference_points}} 评分标准：{{scoring_rules}} 学生作答：{{student_answer}} 请按照以下维度评分： 1. 要点覆盖（40分）：对照参考答案要点，判断学生回答是否覆盖核心得分点。 2. 概念准确性（30分）：判断学生使用的概念、术语是否准确。 3. 逻辑条理（30分）：判断学生表述是否有层次、有逻辑。 严格按以下JSON格式输出： {"scores":[{"name":"要点覆盖","score":32,"reason":"覆盖了...未提及..."},...],"total":78,"comment":"整体评价不超过50字"} 只输出JSON，不要输出任何解释性文字。作文评分模板稍有不同，维度拆成了切题程度、内容充实度、结构逻辑、语言表达四项。在评分标准配置里，教师还可以添加评分细则，比如“议论类文体需明确观点、论据充分”，这些细则会作为额外上下文拼接到提示词中。
有个关键细节：提示词里必须给出分数上限和评判导向，不能只放“请评分”。没有明确约束时，模型倾向于打保守分，所有作文都集中在中间区间，区分度很差。加了评分标准和维度说明以后，分数分布才拉开了。
4.3 评分一致性保障机制
大模型不是确定性算法，同样的输入多次调用结果可能不同。为了让评分结果可信，我引入了多轮采样机制。评分服务对每道主观题调用三次大模型，每次使用相近但略有差异的提示词变体，然后把三个结果放在一起做一致性校验。
一致性校验规则是：三次评分总分的极差小于等于3分时，取中位数作为最终成绩；极差在3到5分之间时，取三次成绩的平均值；极差超过5分时，该题直接标记为“待人工复核”，不再自动给出成绩。这个阈值的设定我调整过很多次，最终极差阈值没有设得太宽松，因为阅卷场景对公平性的要求很高，宁可多送几份到人工复核，也不能让明显有分歧的分数直接生效。
这套机制上线后，各科主观题的自动评分通过率稳定在90%以上，也就是说大约不到一成的试卷需要人工介入，教师的复核负担已经非常小了。
4.4 大模型返回结果解析与异常兜底
大模型输出的解析是很多开发者容易忽略但实际很容易踩坑的地方。官方文档说会返回JSON，但实际调用中我遇到过不少意外情况：返回了JSON但外面包了markdown代码块标记、JSON里夹杂了多余的逗号、把中文引号当成JSON字符串定界符、偶尔还会在JSON后面加一段总结性文字。
所以我在接入层做了一个结果解析模块，专门处理这些脏数据。解析流程是先去除markdown代码块标记，再用正则提取第一个“{”到最后一个“}”之间的内容，最后用宽松模式的JSON解析器处理。如果仍然解析失败，就不走重试，直接把该题标记为异常状态，进入人工复核队列。重试在这个场景下价值不大，因为模型输出格式错误时，简单的重试大概率还是错的。
import re import json def parse_model_score(raw_output): # 去除markdown代码块标记 raw_output = re.sub(r'```(?:json)?', '', raw_output).strip() # 提取最外层大括号内容 match = re.search(r'\{.*\}', raw_output, re.DOTALL) if not match: raise ValueError("未找到JSON结构") content = match.group(0) # 处理中文引号导致的解析失败 content = content.replace('“', '"').replace('”', '"') return json.loads(content)这段代码看着简单，但解决了实际生产环境中至少三成以上的解析异常。建议所有对接大模型API做结构化输出的应用都保留这样一个兜底模块。
5. 任务编排与平台工作流实现
5.1 批改任务状态机设计
阅卷平台是一个典型的多阶段任务系统，每份试卷要经历扫描上传、图像预处理、区域切分、文本识别、自动评分、结果核对、人工复核等多个阶段。这些阶段不能编排得太松散，否则很容易出现某个任务卡在中间状态没人处理的情况。我用了状态机来管理每个批改任务的生命周期。
状态机定义了七个状态：待处理、识别中、评分中、已完成、待复核、复核中、异常终止。每个状态之间的转移条件都有明确约束，比如“评分中”状态只能由“识别中”转移过来，且必须当前题的OCR文本已经写入数据库。我在状态变更的代码里加了严格的前置校验，禁止随意跳转状态。
状态机的实现没有引入额外的流程引擎，就在任务表里维护了一个status字段，配合一个定时扫描任务处理超时任务。如果某个任务在评分状态超过5分钟没有变化，就触发超时重试逻辑，最多重试三次，超过三次就直接改状态为异常终止并通知管理员。
5.2 批量任务并发调度与QPS控制
批量批改场景下，几百份试卷的上百道主观题会同时进入评分队列，如果一股脑全部发给文心大模型，必然会触发接口限流。我在调度层加了双层控制：第一层是任务队列加线程池，控制并发数上限；第二层是令牌桶限流，保证每秒实际发往API的请求量不超过配额。
令牌桶这里的实现逻辑是：系统启动时初始化一个容量为当前账号QPS配额的桶，每个评分请求先尝试从桶里取一个令牌，取不到就等待200毫秒后再试。限流配置放在数据库配置表里，后续如果开通了更高QPS配额，在线调整配置即可生效，不用重启服务。
实际接了一个初二数学期中考试的批改任务，67份试卷有2道主观题，共134个评分请求，配合令牌桶限流后稳定跑了不到3分钟出结果。整个过程中API限流没有发生一次报错。
5.3 教师端复核面板与仲裁流程
就算自动评分准确率做到了90%以上，学校也一定会有复核需求。教师端复核面板按“分数极差大”“低置信度”“模板未匹配”三个维度筛选出待复核题目，展示学生作答原图、OCR识别文本、模型各维度评分和评分理由。
复核界面设计上我坚持要做到一键仲裁。教师看到模型评分结果后，要么直接确认，要么调整总分和维度分，要么重新批改。仲裁结果会覆盖模型评分，并记录仲裁人、仲裁时间、仲裁原因，方便后续追溯。
这里有个容易被忽略的点：仲裁过的数据必须回流到评分优化循环里。我设计了复核结果导出功能，定期把这些数据导出来做人工分析，看模型在哪些维度上老出错。虽然这次实现没有做自动化模型微调，但积累下来的带标签数据本身非常有价值。
6. 成绩统计与学情报告
6.1 报表维度的设计思路
成绩统计不是简单的算平均分和排名，需要在报表层面解决两个实际诉求：一是教师需要快速了解整个班级的作答情况，二是学生需要知道自己的薄弱点在哪里。
系统输出的报表包含三个层级。班级层级展示平均分、最高分、最低分、及格率、各分数段人数分布，以及每道题的正确率和班级平均得分率。题目层级展示每道主观题的维度得分分布，比如一篇作文的“切题程度”班级平均得分是否明显低于其他维度，这能帮教师快速定位共性问题。个人层级展示每个学生的总分、各题得分、排名变化趋势，以及基于维度分的薄弱知识点分析。
报表生成逻辑是任务完成后由定时任务自动执行，统计结果写入独立的统计表。这里我特意没有用实时查询的方式做统计，因为阅卷完成后同时涌进来几十个老师查看报表，实时聚合计算压力太大，预生成统计结果表可以大幅降低查询耗时。
6.2 学情报告生成与导出
学情报告模块是在完成基础统计后，再调一次大模型来生成评语摘要。系统把学生的维度得分情况拼装成结构化的摘要文本，让大模型生成一段针对性的学习建议。比如一个学生作文“切题程度”得分低而“语言表达”得分高，模型生成的评语会侧重点出审题方面的问题。
这个功能上线后反馈非常好，很多班主任专门把这个模块生成的评语转发给学生和家长。我在设计时有意把生成评语和自动评分拆成了两个独立的大模型调用，因为两者的提示词目标完全不同。评分要求严格的评判输出，评语要求温和的鼓励指导，混在一起会让模型的角色切换很混乱，分开调用反而两个结果都更稳定。
导出功能支持Excel和PDF两种格式，Excel用于教师做二次统计分析，PDF用于直接发给家长与学生。每个报告文件生成后在对象存储中保留7天，到期自动清理，减少存储成本。
7. 落地难点与问题排查实录
7.1 手写体识别误差对评分的影响
手写体识别质量直接决定评分上限，这是我做这个项目最重要的教训之一。学生字迹潦草、连笔、涂改严重时，OCR识别出的文本会带大量错字甚至漏字，这些错误文本送到大模型后，评分质量必然下降。
我起初的应对思路是提升OCR参数，后来发现单纯调参数解决不了根本问题。真正有效的手段是在提示词里加入“容忍识别误差”的说明，引导模型依据可识别的核心内容做判断，而不是在个别错字上纠结。一条有效的话术是“学生作答可能存在个别文字识别误差，请结合整体语义判断”。
另一个很有用的补充策略是把识别置信度信息一起送进提示词。对置信度低的内容，在提示词里明确标注“此处文字识别可能不确定”，模型在有心理预期的情况下，判断要稳定很多。这个策略让手写体作文的评分通过率从76%提到了85%。
7.2 模型输出不稳定时的降级方案
大模型服务偶尔会出现响应时间超过10秒甚至直接报错的情况，这在批量批改时会直接影响整体任务进度。我的降级方案分三层。第一层是超时重试，单次请求超过15秒就重试一次，重试间隔1秒。第二层是熔断机制，连续失败5次时触发熔断器，暂停评分请求30秒，避免服务雪崩。第三层是降级到候补评阅方案，把未完成评分的试题标记为待处理状态，人工介入批量处理。
这个降级链路在双十一期间没有出现，但在一次教研系统做夜间例行维护时触发过，整个熔断和一个进程重启的流程下来，任务队列没有丢数据，恢复后自动续跑，验证了这套方案的可靠性。
7.3 评分公平性的争议处理策略
自动评分系统上线后，最大的争议来自于评分公平性。有家长质疑“机器批改作文会不会有偏见”，有老师担心“模型是否对某些表达风格更偏爱”。我的应对思路是不回避问题，把系统设计成可解释、可申诉的透明机制。
系统为每道评分题保留了完整的评分快照，包括模型评分请求的原始提示词、模型返回的完整响应、计算总分的中间过程。任何一道题的评分有争议，都能一键导出完整的评分记录供教研组核查。
我也把“每份试卷的自动评分结果都会经过抽样复核”写进了产品说明，实际上在配置方面给了教师很大的灵活性，可以按10%、20%、50%的比例设置抽检率。校长信任度的建立，靠的是不是一句“AI很准”，而是随时可以复盘、可以追踪的机制设计。
7.4 平台启动初期OCR返回延迟
有个细节问题在测试阶段没有暴露，正式使用时才出现。OCR识别接口在并发达到一定量级后，单张图片的识别耗时从1秒飙到了8秒以上。表现就是批量扫描上传后，前端上传进度迟迟不完成。
排查后发现是任务并发数和OCR接口服务端的QPS限制不匹配，请求大量堆积在等待队列中。解决方式是给OCR识别任务单独设置一个更保守的并发池，同时把上传操作改为异步处理——前端只负责上传图片，后台任务队列异步完成识别，前端通过轮询接口获取处理进度。这样用户体验更流畅，后台的压力也变得可控。
8. 源码结构与文档体系设计
8.1 后端工程模块划分
整个后端工程采用多模块Maven结构，分成七个模块，每个模块的职责单一。这里我截取核心模块的目录设计供参考：
exam-platform/ ├── exam-common // 公共工具类、统一返回体、异常定义 ├── exam-auth // 登录鉴权、角色权限管理 ├── exam-template // 试卷模板管理、答题区域标注 ├── exam-recognition // 图像预处理、区域切分、OCR接入 ├── exam-scoring // 评分引擎、提示词管理、结果解析 ├── exam-workflow // 任务调度、状态机、队列消费 └── exam-report // 成绩统计、报表生成、数据导出模块之间只允许上层依赖下层，禁止循环依赖。exam-scoring是核心模块，我单独维护了一组提示词版本管理，每次调整提示词都记录版本号和生效时间，方便回溯对比效果。
8.2 数据库设计关键点
核心表我设计了六张：考试表、题目表、答题卡表、答题区域表、评分结果表、复核记录表。这里说几个设计时容易踩坑的细节。
评分结果表里除了总分和维度分，一定要保存模型返回的原始JSON和解析后的结构化数据。原始JSON用于排查问题，结构化数据用于统计。两个字段分开存，不要只保留一个，排障时缺了原始数据会很被动。
答题区域表保存的是归一化坐标，这个字段类型用JSON，不要拆成四个独立的坐标字段。因为题目区域可能是任意多边形框选，JSON格式可以灵活存储不同数量的顶点。我第一次设计时拆成左上右下四个字段，后来碰到一个老师框选了不规则的椭圆区域，只能改表结构，痛苦得很。
8.3 部署运维与性能实测
部署架构采用了Docker Compose编排，一个脚本拉起全部服务。核心组件包括Nginx、后端应用镜像、MySQL、Redis、MinIO。服务器配置用的4核8G的云主机，跑了两个月没有遇到资源瓶颈，说明这个量级的阅卷平台并不需要很豪华的硬件。
性能实测在初三模拟考场景做过一次完整压测。测试数据是6个班280名学生的试卷，每张试卷包含2道主观题。从扫描件上传到成绩统计报表生成，全流程耗时大约7分钟，其中OCR识别占3分钟，大模型评分占3分半，其余为任务排队和统计计算时间。
对比人工批改，原来两位老师批改一个班的作文需要约40分钟，现在系统自动批改加教师抽检复核，单班耗时缩减到10分钟以内，效率提升非常明显。同时我记录了自动评分与人工评分的一致性，在3分误差范围内的一致率为86.4%，剩余分歧主要集中在评分标准边界案例上。
8.4 文档说明与交付物组织
“源码+文档说明”的项目交付体系，我在文档方面做了四个维度。需求文档描述产品目标和用户场景；技术设计文档记录架构决策和核心流程；提示词规范文档专门说明评分模板的编写原则，以及不同题型的模板示例；部署运维手册则覆盖环境准备、配置说明、常见故障处理。
文档写作过程中我坚持一个原则：文档要能支撑一个新人独立完成部署和二次开发。所以每份文档都包含可执行的步骤、完整的配置示例和常见问题清单，而不是写一堆抽象的架构图。系统上线半年后，团队里一位刚入职的同事照着部署文档在全新服务器上搭建了一套测试环境，全程没有需要我介入，说明文档的完备性是达标的。
从项目中沉淀下来的一些体会
做完这个项目，我最大的体会是：用大模型改造传统业务系统，难度不在接口调用，而在业务逻辑的重新设计。评分维度怎么拆、提示词怎么写、阈值怎么定、异常怎么兜底，这些决策才真正决定了系统能不能被用户接受。
这套平台后续可以扩展的方向不少，比如接入更多学科的评分模板、做基于历史数据的分数预测、把复盘的评分案例沉淀下来做持续优化。但从工程的视角来看，当前版本已经解决了“主观题自动批改能不能用”这个核心问题，剩下的都是在这个基础上持续打磨。
如果你也在做类似的AI应用落地项目，我建议不要一开始就追求大而全，先找一两个真正有痛点的场景打透。当老师和学生真的因为你做的系统节省了时间、获得了有价值的信息，那种成就感会远超技术方案本身的完美程度。
本文还有配套的精品资源，点击获取
