3月1号开学。今天2月22号。
下学期我教4门课,学生加起来500多人。先别急着同情我,听完作业量再说。
学校规定每门课至少3次作业,4门课就是12次起步。但其中两门是实训课,在机房上的那种。实训课的规矩是每节课都有实训作业。16周的学期,每周一次,两门实训课加起来32轮。这两门课大概200个学生,光实训作业就是三千多份。再加上另外两门课的常规作业,整个学期的批改量,保守估计四千多份。
就算每份只花5分钟,4000 × 5 = 20000分钟 = 333小时。16周平均下来,每周20多个小时在改作业。
我算过一次,不想再算第二遍了。
但数量还不是最要命的。最要命的是时间在跟自己打架:花在改作业上的每一个小时,都是从备课和自我进化里抢来的。如果把精力全耗在批改上,讲课质量一定掉。讲课质量掉了,布置再多作业、改得再认真也没用,源头就错了。
所以在开学前一周,我决定做一件事:造一个AI改作业系统。
不是那种"把作业扔给ChatGPT让它随便评"的方案。我需要的是一个有评分标准、有证据链、有偏差检测、有统计验证的完整系统。而这个系统对教师的核心要求只有一个——
把你的评分标准写清楚。
这到底是个什么东西
我用的工具叫Claude Code,Anthropic做的命令行AI助手。它有一个扩展机制叫Skill,本质上就是一个Markdown文件,写清楚遇到什么任务、按什么流程做,Claude读了就获得了相应的专业能力。你可以把它理解成给AI写了一份岗位说明书。
我写的这份岗位说明书,定义了一套完整的作业批改协议,包括怎么读评分标准(Rubric)、怎么逐维度评分、怎么检测偏差、怎么生成个性化评语。
教师使用时,只需要准备一个Rubric文件,就是你平时脑子里那套评分标准,写成结构化文本。定义几个评分维度,每个维度的权重,1到5分每个等级对应什么样的具体表现。然后在对话中说一句:
SCORE student-report.docx against my-rubric.yaml
Claude就会读取你的标准、读取学生作业、逐维度评分、给出分数和评语。
你需要的不是编程能力,而是把模糊的评分直觉变成清晰的书面标准。 这本身就是值得做的教学设计工作——只不过以前没有足够的动力去做,现在AI给了一个立竿见影的理由。
先设计再动手
在让Claude写一行代码之前,我先让它帮我做了两份设计文档,产品需求文档(PRD)和技术规格(Spec)。Spec写了1689行,比我有些学生的毕业论文还长。
PRD定义了"做什么"。五个核心工作流:定义评分标准、收集预处理作业、批量评分、质量审计、导出成绩单。也列出了成功指标:AI评分和教师评分的一致性系数(Cohen's κ)要达到0.70以上。
Spec里有几个关键决策:
5分制而不是10分制。 LLM没法稳定区分8分和9分的差异,但1到5分的界限清晰。3分制太粗,分不出优良中差。这个选择我很认同,平时改作业其实也就是"优良中及格不及格"五档。
强制"先找证据、再推理、再给分"。 不许AI先拍个分数再去找理由自圆其说。必须在作业里找到具体段落当证据,对照评分标准推理,最后才确定分数。研究表明这种方式比直接评分提高15-25%的可靠性。
PDCA质量循环。 Plan(定标准)→ Do(AI评分)→ Check(校准验证)→ Act(人工复核)。每个阶段都有量化的退出条件。不是走形式的那种PDCA。
这些设计我和Claude各出一半。我出教学场景的判断,它出评估方法论的知识。分工挺明确,我是甲方,它是乙方。
25个文件的诞生
设计完了,开始造。我唯一的要求就是"要按计划执行"。
Claude先把Spec通读了一遍,然后建了任务清单,分5个阶段推进。
第一阶段是核心:SKILL.md,814行的"系统大脑"。包含完整的评分协议和内联的评分Prompt。设计上有个考虑:即使不装Python脚本,只靠这个文件加一个Rubric,Claude也能完成单份评分。脚本是批量处理的加速器,不是必需品。
第二阶段是4个示例Rubric,对应我真实教的4门课。每个Rubric有4个评分维度、20段锚点描述(4维度 × 5个等级)。别的教师可以拿去改改直接用。
第三和第四阶段是5个参考文档(共1939行)和6个Python脚本(共4125行)。这里Claude做了一件我觉得挺聪明的事:对于互相独立的长文件,它启动了多个后台Agent并行写。两个Agent同时写两份最长的文档,主线程写其他的。说白了就是"一个人不够就叫同事",只不过它的同事也是它自己。
第五阶段是README,GitHub上的项目门面。
最终:25个文件,8667行代码和文档。最大的单个文件是批量评分脚本,1644行。
AI也会偏心
你可能觉得AI不会有人类评分的毛病。不完全对。它有它自己的一套。
长度偏差:写得多就给高分。3000字的报告可能比1500字的多拿分,即使多出来的都是凑字数。改过作业的老师应该都深有体会,学生用数量换质量是基本操作。
权威偏差:语气自信的表述会被高估。"显而易见""不言而喻"这类断言,AI可能不自觉地提高评价。实际上这些话经常什么都没论证。
冗余偏差:同一个观点换三种说法出现,AI可能误判为"论证充分"。
位置偏差:批量处理时,排在前面和后面的作业可能得分系统性不同。这一点人类改作业也有——前面标准严、后面标准松,只是我们自己不想承认。
自我增强偏差:某个维度给了高分,可能带动其他维度。
对策是三层防护。
Prompt层:评分指令里直接写"长度不等于质量,凑字数应扣分""自信的语气不等于正确"。
系统层:批量评分时随机打乱处理顺序、各维度强制独立评分。
检测层:事后用统计方法检测字数与分数是否相关、处理顺序与分数是否相关——如果显著相关,说明偏差没被有效缓解。
这5种偏差里至少3种我自己改作业时也有。区别在于,AI的偏差可以被量化检测和系统缓解;我的偏差,只能靠改累了去喝杯咖啡来对付。
最难的不是写代码
25个文件全部写完以后,我让Claude做了一次交叉检查。
它启动了4个专门的审计Agent,并行扫描不同维度:一个查数据结构是否对齐,一个查阈值数字是否跨文件一致,一个查Rubric格式三方一致性,一个查命令参数和文档是否匹配。
你可能觉得AI写的东西AI自己检查有点自己查自己的意思。但4个Agent查的是不同维度的交叉一致性——不是看代码对不对,是看25个文件之间有没有互相矛盾。
结果发现了22个问题。
"20%复核率"三个文件三种定义。 一个说"置信度低于0.8的都算",一个说"只算低于0.6的",还有一个含糊其辞。按0.8算,可能50%的作业都得人工复核,20%的目标就成了一句空话。最后统一为"低于0.6才算强制复核"。
文档里的命令和脚本参数不一样。 文档写 python stats.py workspace/scores/,脚本实际接受 workspace/。教师照着文档复制粘贴会直接报错,这种bug如果不检查,第一个用户就会踩到。
同一个数字出现在4个不同文件里,边界条件(< 还是 ≤)极容易不一致。25个文件的交叉引用,人工逐一比对几乎不可能。但4个Agent各盯一个维度并行扫描,能系统性地找出来。
这大概是整个项目最让我感慨的环节:写代码不是最难的,保证它们互相不矛盾才是。
发布:一行命令的事
检查完了,该发出去了。
我一开始打算走正常流程,创建GitHub仓库、配置远程地址、推送代码。结果第一步就翻车了:Git提交时报错"Author identity unknown"。在Windows上忘了配全局Git身份。一个造了几千行代码的项目,被一个用户名配置挡住了。
配好身份以后,用GitHub CLI一行命令搞定:
gh repo create homework-grader --public --source=. --push
仓库就出现在了 github.com/ChantillyAn/homework-grader。加了MIT许可证,打了13个标签——claude-code、ai-grading、rubric、education、bias-mitigation之类的,让有需要的教师能搜到。
25个文件,8667行,从零到公开仓库,一天。
评分标准的显性化
做完这个项目,我最大的收获是被迫把评分标准显化了,写清楚了。
显性化以后好处很多:标准不漂移了,第1份和第4000份用同一把尺子。另一位老师接手这门课,看Rubric文件就知道评分标准。学生拿到反馈,能看到"你在数据分析维度得了3分,因为缺少定量数据支撑;如果补充具体的数据分析,可以到4分",而不仅仅是一个干巴巴的分数。
这不是AI替代教师。人定标准、AI执行、人验收。教师做了真正该做的事——设计评价体系;AI做了重复性工作——4000份一致性批改;人再回来做判断——审核边界情况、修订评分标准。
批改4000多份作业的成本,估计也不小(这里自行脑补一个苦笑的表情)。
回到开头那个333小时。
用AI改,这个数字可以砍掉80%以上。省下来的不只是时间,是备课的精力,是自我进化的空间,是下学期讲课质量的基本盘。
让AI改作业不需要写代码,只需要把评分标准写清楚。 而写清楚评分标准这件事,不管用不用AI,本来就该做。AI只是给了一个立竿见影的理由。
这个项目已经开源在GitHub(搜 homework-grader),MIT许可,任何教师都可以免费使用,模板拿来改改就能用在你自己的课上。