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许可，任何教师都可以免费使用，模板拿来改改就能用在你自己的课上。