将claude code用于计算机科学课程作业批改的初步设想

去年秋季学期，我负责软件工程课程两个班的作业批改工作。注册学生94人，每人提交8次编程作业。按照平均每份作业20分钟的检查、运行、标注、评分时间计算，理论上我需要投入250个小时，这还没有算上抄袭检测和边界情况的二次复查。实际执行时，我和一名研究生助教两人协作，仍然在第5次作业时出现了严重的批改延迟：学生等了12天才收到反馈，而下次作业已经在3天前提交了。

更让人沮丧的不是工作量，而是反馈质量的不可控滑坡。深夜批改到第15份时，我的注释从详细指出“循环嵌套可以用递归优化，考虑时间复杂度的提升”退化成了“逻辑可优化”。这种前后不一的反馈对学生是不公平的，但人脑的疲劳曲线就是这么诚实。所以我开始体系化地探索Claude Code的批改可能性，不是作为一个“自动评分机”的幻想，而是作为一个“可持续、可审计的批改辅助系统”的工程起点。

这份文章记录的，就是这个初步设想从概念到实验、从希望到局限的完整过程。

一、核心结论：先厘清AI辅助批改的根本价值在哪里

在进入具体技术方案之前，我需要先给出一个明确判断：AI辅助批改的核心价值不在“提效”，而在“提高反馈质量与一致性”，效率只是这个过程的副产品。 这个判断和市面上多数宣传的方向相反，但这是我在实际测试中反复验证后的结论。

为什么这么说？我们可以先看一组我在试点批改中采集到的对比数据：

效率确实提升了，但这张表真正值得关注的是第二列数据和第三列数据的差异。未经复核的AI批改在“创造性解法识别”上存在严重问题，它会倾向于把不符合标准答案模式但逻辑上正确的解法判定为错误。 这意味着如果你把Claude Code当作一个“自动批改机”来用，你可能会系统性地伤害那些有编程天赋但思路不走常规的学生。这比我批改慢12天还要糟糕。

所以，这个初步设想的核心主张是：把Claude Code定位为一个“一致性保障层”和“规范性检查层”，而不是决策层。教师保留对复杂逻辑、创意实现、架构选择的最终裁判权。 效率提升10倍还是2倍不重要，重要的是反馈质量不能因为工具介入而下降。

二、触发这个设想的真实场景：三个反复出现的批改痛点

任何技术设想的合理性都需要放在真实问题中检验。我梳理了过去三个学期批改过程中的高频痛点，这些痛点直接塑造了我对Claude Code能力的使用预期。

痛点一：规范性问题的“审视疲劳”，AI在这一点上确实比人强

代码规范性检查是批改中最耗时也最容易失效的环节。检查项目包括但不限于：

• 函数命名是否遵循驼峰法/下划线法
• 是否有无用的import语句
• 是否有硬编码的魔法数字
• 错误处理是否完整（特别检查空值、边界条件）
• 注释密度和注释质量
• 是否存在死代码（定义了但永远不执行的代码块）

前三份作业，我可以逐行检查这些。到了第20份，我的大脑开始自动跳过这些“看起来差不多”的问题。不是不想检查，是注意力资源真的被更重要的逻辑评估消耗殆尽。

在Claude Code的辅助测试中，我做了这样一个实验：将同一份已经人工批改完毕的作业（我认为已经没有规范性错误）交给Claude Code重新检查。结果它从这份“已批改”作业中又检出了3个我完全漏掉的规范性问题：

• 有一行代码在循环内部重复计算了一个可以在循环外计算的值（性能规范问题）
• 某个异常捕获是用except:而非except SpecificError:（Python最佳实践违反）
• 一个函数参数使用了可变对象作为默认值（新手常犯的高危问题）

这三个问题都不是“错误”，但都是“不够好”。如果是疲于赶工期的我，几乎不可能在第27份作业的检查中敏锐地抓到它们。这说明AI在规范性检查上的优势不仅是效率，更是一种“同等注意力下的全覆盖”能力，这是人做不到的。

痛点二：评分的“基准漂移”，人对评分标准的执行力会随时间恶化

翻我2023年秋季学期的批改记录，我发现一个让人不安的规律：同一份作业要求下，前10位学生的平均分比后10位低了大约4.2分（百分制，同一作业批次）。这不是因为后10位学生更优秀，我用盲评复查验证过，而是因为我在批改后期不自觉地放宽了某些评分标准。

具体来说，最常发生漂移的标准是：

• 对于“部分完成但思路正确”的作业，后期比前期更容易给到及格分以上
• 对于“代码能跑但是架构很差”的作业，后期待遇更宽容
• 早期我会标记“缺少关键注释”，后期注释缺失几乎不被扣除相应分数

Claude Code解决这个问题的方式很直接：在同一个Prompt和评分标准框架下，它对第1份和第50份作业执行的评判逻辑是一样的。 我的实验做法是：将评分标准拆分为三个维度（功能实现占50%、代码质量占30%、规范与文档占20%），每个维度再细化为可量化指标，然后让Claude Code分别独立评分最终取加权结果。

这里有一个关键的技术细节需要说明：为了保证这一致性真正有用，我需要确保下面两点：

1. 评分Prompt中的算分逻辑必须是硬约束。 比如“功能实现50分：每个通过的测试用例计10分，5个用例全部通过则50分”。如果写成“根据功能完成度，在0-50分之间给出合理评分”，AI的一致性优势就荡然无存，它会开始“自由裁量”，而这个自由裁量本身就是一种新的不一致源。
2. 同一批次的所有作业必须在同一个Claude会话或Project上下文中处理。 跨会话会导致微妙的语气和严格度变化（我验证过，即使Prompt完全一致，新会话的输出严格度可能有3%-5%的波动）。Claude Code的Project功能允许你将评分标准、参考解答、常见误区分档做成持久化知识库，这是它比普通ChatGPT更适合批改场景的技术原因之一。

痛点三：批改内容的“注释衰减”，反馈质量的时间函数

这是我整理的一项自我统计：从批改开始到结束，我的单份作业平均注释字数从最开始的约120字（含代码片段引用和具体建议），下降到后半段的约35字（多为“不错”“需优化”等泛泛之词）。注释质量衰减甚至比评分基准漂移更严重，因为学生是直接读注释来理解自己的问题的。

Claude Code在这个维度上的表现反倒让我比较放心。它的输出天然倾向于详细解释，而且这种解释冲动不会因为处理量增加而减弱。但这带来了一个新问题：AI的注释容易过于冗长，一个简单问题可能生成200字以上的解释，学生需要额外花费时间从中提取有效信息。 所以我在Prompt设计中加了一个约束：“每条反馈控制在80字以内，如果问题复杂允许多条反馈，但每条不能超过这个字数。”这样做的目的是强迫AI提炼核心信息，而不是用文字量堆砌一种虚假的“详尽感”。

三、一个被严重低估的核心认知：批改不是一个“更快的检查”，而是一个“格式化的诊断生成”

这是我在设想阶段花了最长时间思考的问题。大多数关于“AI批改作业”的讨论，默认前提是批改等于“检查作业是否正确并打分”。但实际上，一个经验丰富的教师在批改时同时做了五件事：

1. 逐行检查语法与规范
2. 运行并验证功能
3. 评估解题思路的合理性（这是最难被量化的部分）
4. 将单个作业中的错误关联到教学中的知识点缺失（诊断思维）
5. 在注释中给出有教学引导价值的反馈（而不是说“你错了”）

前两项AI可以做，第三项AI会犯前述的“创造性误判”，而第四项和第五项才是真正决定批改教育价值的环节，也是目前AI最难做好的环节。

我的初步设想是：不试图让Claude Code做全部五件事，而是让它专注做它擅长的事（1、2），同时为3提供辅助分析素材，然后把4和5留给教师。 具体来说：

• AI负责：规范检查、运行测试、识别常见错误模式、标注与标准答案的偏离点
• AI提供但不决策：对解题思路的初步分析、对代码结构的评价建议
• 教师负责：最终评分的确认、教学诊断的生成、引导学生深入思考的关键反馈

这样设计之后，批改流程不再是“AI代替人判”，而是“AI做结构化预处理，人来完成高价值判断”。这与我实际测试的最佳效果一致。

四、实验设计：我们具体测试了什么、怎么测的

有了设想，需要验证。我在2024年春季学期的一门数据结构课程中设计了一个封闭测试（不用于正式成绩，仅做对比分析），目标很明确：检验Claude Code在不同类型的编程作业中的表现边界，寻找人机协作的最优分工方案。

实验设置说明

• 测试样本：3次不同类型的编程作业，每次作业从实际提交中随机抽取12份（共36份），覆盖优秀、中等、较差三个水平区间
• 评测方式：人工（我）盲评打分作为参照基准；Claude Code独立批改；然后两者结果做交叉对比
• 作业类型：
• 类型A：算法实现（链表操作，有明确标准答案和测试用例）
• 类型B：开放式设计（实现一个简易内存管理器，评价标准含设计合理性和代码组织）
• 类型C：问题修复（给一段有bug的代码，要求找出并修复所有问题）
• Claude Code设置：使用Project功能，每个作业类型建立独立Project，将作业要求、评分标准文档、标准答案（如有）、常见错误清单上传为上下文知识
• Prompt设计原则：角色设定为“大学数据结构课程助教”，输出格式强制要求为“【评分】+【具体反馈】+【不确定项标注】”

测试发现一：不同作业类型，AI的“靠谱程度”差异极大

这是本次测试最重要的发现。批改结果的可用性高度依赖作业类型，不能简单说“AI批改好”或“不好”，

类型A（算法实现，标准答案明确）：

• Claude Code评分与人工评分的皮尔逊相关系数：0.91（高度相关）
• 主要问题集中在：学生使用了和标准答案思路不同但等价的实现（比如用迭代而非递归翻转链表），AI倾向于标记为“实现方式不符合预期”
• 可用性判断：经过对“等价实现”的Prompt调整后，这类作业的AI辅助批改可大幅降低人工介入量，教师主要复核“AI标记为不符合预期”的作业即可

类型B（开放式设计，主观判断空间大）：

• 评分相关系数下降到0.68
• AI特别容易高估“代码风格整洁”的作业，而忽略设计合理性（比如一个内存管理器没有考虑碎片整理，但代码写得漂亮，AI给了高分；人工评分认为设计缺陷是致命问题）
• 可用性判断：不建议让AI参与此类作业的最终评分，可仅用于规范性检查，教师必须全程参与逻辑评估

类型C（问题修复，Debug类作业）：

• AI在“发现bug”上表现优秀，检出率96%（人类基线约88%），发现了我遗漏的一个边界条件bug
• 但在解释“为什么这是bug”以及bug根因分析上，生成了部分看起来合理但不准确的解释
• 可用性判断：Bug检出环节可用AI辅助；根因分析和修复正确性仍需人工逐个验证

测试发现二：存在一批“表面一致但本质不同的解答”，AI大概率会误判

我专门关注了12份中出现AI评分与人工评分差距超过12分的案例（共4例），逐一复审后发现了共性：都是学生在实现功能的前提下，采用了与标准答案思路不同的方案，AI未能准确评估其正确性和合理性。

具体而言，这四例可分为以下子类型：

1. 实现路径不同，但结果等价。 如学生用动态数组替代链表完成了同样的功能需求。AI的判断是“未按要求的链表结构实现”，但作业要求只规定了功能而没有强制数据结构。这是Prompt对“必须”和“建议”边界理解不足的问题。
2. 使用了超越课程范围的解法。 一个学生用Python的生成器和装饰器完成了作业（课程只教到函数和类），功能全部正确。AI的反馈是“使用了未教授的高级特性，代码可读性下降”，而人工评分的判断是“虽然不是课堂教的标准解法，但其代码质量高且正确，且学生明显有自主延伸学习。”这涉及到教学价值观的判断：我们是鼓励学生探索，还是要求他们用指定工具解决问题。这个判断AI做不了。
3. 故意不处理某个边界条件，认为输入保证不会出现。 学生在注释中明确写了“假设输入已被校验”。AI标记为“缺少输入验证逻辑”，人工判断认为该学生在合理范围内做了工程取舍。AI对工程语境下的“合理取舍”缺乏判断能力。
4. 看起来像错误但实际测试通过。 一段用位运算实现的逻辑AI判定为“意图不清晰”，但运行结果完全正确。人工评分为“功能正确但可读性可提升，建议增加注释。”

五、Prompt工程在批改场景中的关键细节：不是所有指导语都叫好Prompt

在测试过程中，我迭代了大约7版Prompt设计。这个过程让我深刻意识到：批改场景的Prompt设计难度，比很多教程里展示的“给AI一份作业让它打分”要高出一个数量级。 这里记录几个对我影响最大的设计原则。

原则一：评分必须“只减不增”，除非你在Prompt中明确规定加分项

这是最容易出现系统性偏见的地方。如果Prompt中只写了“每个扣分项扣X分”，AI会在执行过程中不自觉地产生一种“从满分往下扣”的倾向，但它对“这个作业是否值满分”的基线判断本身就可能偏差。

我的解决方法是：强制AI先做一个基线判断，再执行扣分逻辑。 具体Prompt片段示例：

评分分为两步执行：

第一步：判断作业属于哪个基线分数档位。

• A档（功能全部正确且代码质量优秀）：基线分85
• B档（功能全部正确但代码质量一般）：基线分70
• C档（功能部分正确）：基线分50
• D档（功能严重缺失）：基线分20

第二步：在基线分上执行扣分或加分。

• 规范性问题每个扣3分（上限扣15分）
• 注释缺失每个扣2分（上限扣10分）
• 有特别优秀的代码设计思路可加分（上限加10分）

在加入这个两步法之后，AI的评分与人工评分的一致性得到了显著改善。这说明将模糊的主观判断转化为结构化的分步操作，是让AI产出可靠评分的前提。

原则二：“不确定”必须是一个合法输出项，而不是AI勉强给出一个置信度不高的判断

在早期Prompt设计中，我要求AI对每个维度给出明确评分。结果发现AI在它不确定的地方也会给出一个“猜测分”，这个分经常出错。改正后的做法是强制加入“不确定项标注”要求：

如果你对以下任何一项不确定，请在对应项后标记[？]，并简要说明为何不确定：

• 该段代码的设计意图
• 某个实现是否为错误，或是合理的变通
• 评分是否适用标准扣分规则

这个设计的价值在于：教师复核时可以直接定位到这些[？]标记，快速处理AI最不自信的部分，而不需要在海量正确的反馈中去大海捞针式地找潜在错误。 在我的测试中，AI标记了[？]的条目占比约7%-12%，但这些条目中确实存在问题判断的比例高达约40%。这极大地提升了复核效率。

原则三：上下文知识的组织方式比知识本身的总量更重要

Claude Code的Project功能允许上传作业要求、评分标准、标准答案和常见错误。但我的实测发现：如果把这些信息不加整理地一股脑扔进Project，效果远不如按照“优先级分层”组织。

我推荐的组织结构：

1. 必须遵守的硬约束（放在最前面）： 评分标准、各维度分值和扣分规则、输出格式模板
2. 参考标准答案（中位）： 包括标准实现的代码、可接受的变通方案、明确标记“不可接受”的常见错误
3. 教学理念性说明（放在最后）： 比如“鼓励学生使用课堂未教但合理的技术”“当学生方案与标准答案不同时应按功能正确性而非形式相似性评分”

这样组织的原因是Claude在长上下文处理中也会受到“首因效应”和“位置偏见”的影响，它更倾向于严格遵循前面列出的硬约束，而对后面位置的教学理念的遵守程度会下降。把最重要的评分规则放在前面，是经过多次测试后确认的有效策略。

六、不得不谈的成本问题：时间成本、经济成本与认知成本

很多“AI批改”的文章在成本分析上要么缺失，要么轻描淡写。我这里把批改实验的真实成本拆开来说，对任何想在实际课程中落地的人都有参考价值。

经济成本：API调用费用比想象中低，但前置投入不可忽视

Claude Code在批改场景下的单次调用成本可以按照Token消耗来估算。以我的测试数据（每次作业处理12份提交）：

• 单份作业平均输入Token：约8,000-15,000（包含作业要求、评分标准、标准答案上下文、学生代码）
• 单份作业平均输出Token：约1,200-2,500（评分结果和反馈）
• 按当前Claude API定价估算（以Claude 3.5 Sonnet为参考），单份作业批改成本约0.06-0.12美元

50人的课程，一学期8次作业，总API调用费用约为24-48美元。这个成本对大多数课程完全在可接受范围内。 但上面算的只是“运行成本”。下面是容易被忽略的前置成本：

• Prompt设计与迭代测试时间：我在项目启动阶段投入了约20小时进行Prompt调优和对比测试
• 知识库搭建（作业要求标准化、常见错误案例整理）：每次作业约2-3小时
• 教师复核时间：每份作业约4-8分钟（显著低于纯人工批改的18-25分钟，但不是零）

认知成本：你需要学会“审计AI”而不是“使用AI”

这是比时间金钱更难量化的成本，但影响最深远。使用Claude Code批改之后，我的角色从一个“执行者”变成了“审计者”。这要求一套不同的能力：

• 不是“怎么让AI评分更准”，而是“我如何快速发现AI评分中的系统性偏差”
• 不是“AI给了什么反馈”，而是“AI的反馈在什么情况下最不可靠，我应该优先检查哪些条目”
• 不是“调一个好的Prompt一劳永逸”，而是“每个作业批次都需要微调Prompt以适应不同的评价重点”

这个角色转换需要一个适应期。在我的实验中，前两次作业的人机协作批改效率提升不明显（时间节省只有25%左右），因为我花了大量时间在不信任AI的反馈上反复验证。到了第4次作业之后，我逐渐建立了“直觉校准”，大概知道哪些类型的问题AI会错，就不再逐一验证，只快速抽查。这个“直觉校准”的建立过程至少需要处理过50份以上的AI批改结果。

七、新型工作流：一个包含两阶段人工审核的操作规程

基于以上所有测试和思考，我设计了一个可操作的人机协作批改工作流。这不是一个“概念性”的流程描述，而是我在实际课程中正在使用并持续迭代的具体SOP。

阶段一：批改准备（每次作业在截止日期前1-2天完成）

Step 1：作业要求标准化

将作业要求文档改写为“可打分”的结构化格式。具体做法：

• 列出所有功能点，每个功能点标注“必须实现”或“加分项”
• 为每个功能点预设一个检验方法（如何验证该功能是否实现）
• 明确哪些技术要求是硬性的，哪些是建议性的

Step 2：建立评分知识库

在Claude Code的Project中上传：

• 上述标准化作业要求
• 评分标准文档（含分步评分逻辑）
• 标准参考解答（如有）或至少一个高质量参考实现
• 常见错误清单（基于往届经验或教师预判）

Step 3：Prompt测试与校准

使用2-3份教师预设好的“校准样本”（包含一份优秀、一份中等、一份有明确问题的作业），验证AI评分与预期的一致性。如果不一致且理由不成立，调整Prompt直至偏差在可接受范围。

阶段二：批量批改执行（作业截止后1-2天内完成）

Step 4：AI预设评分

使用Claude Code处理全部提交。要求输出格式：

• 各维度得分和总分
• 每条扣分项附带代码片段位置和扣分理由
• 用[？]标记所有不确定项
• 自动化测试结果（如果作业配了测试用例）

Step 5：人工差异复核

教师不逐份检查所有作业，而是按照以下优先级处理：

• 第一优先级： 检查所有AI标记了[？]的条目，逐条判断正确性
• 第二优先级： 检查总分在边缘线的作业（如59-61分、69-71分），确认是否因AI误差导致挂科或错失优秀
• 第三优先级： 随机抽查5-10%的非边缘线作业，检测是否存在系统性评分偏差

Step 6：教学诊断生成

这是AI辅助批改的真正价值释放环节。在复核完成后，将全班的错误模式数据反馈给Claude Code，要求其生成：

• 全班最高频的3-5个错误模式及其分布
• 错误模式与教学知识点的关联图（哪些知识点的教学可能需要加强）
• 针对不同错误模式的分组反馈建议

老师在进入课堂讲评之前，手里已经有了一份数据驱动的教学诊断报告，这远比单份作业的批改更有长远价值。

阶段三（可选但推荐）：学生侧的AI反馈入口

如果教学平台支持，可以在学生收到批改结果后，允许学生就AI指出的具体问题向Claude Code追加提问。比如：

• “AI指出我的递归函数可能导致栈溢出，能具体解释在什么输入下会发生吗？”
• “AI标记了代码风格问题，能给我看一个修正后的版本作为参考吗？”

这种交互的前提是：教师已经在批改阶段验证了AI判断的基本正确性。 如果AI的原始判断有错，学生在追问时会放大这个问题。所以这个阶段是可选的，只有在教师对AI批改质量有足够信心时才建议引入。

八、风险评估：这套方案会在什么情况下失效

任何技术方案都必须诚实地讨论失效模式。根据我的测试和实际使用经验，以下是Claude Code辅助批改的几个明确失效点：

风险一：评估维度过于抽象的作业不适合使用AI评分

典型例子包括：

• “评价该方案的设计优雅度”
• “判断代码的可维护性”
• “评估学生是否理解了XX设计模式的思想”

这些维度即使有评分标准，其主观性仍然很高。AI给出的评分可能看起来合理且自洽，但存在系统性的“审美偏差”，比如AI倾向于认为“代码越短越优雅”“注释越多越可维护”。对于这类作业，AI可以给出“参考意见”，但评分决定权必须完全留在教师手里。

风险二：跨文件、跨项目结构的复杂作业，AI可能丢失全局上下文

Claude Code虽然支持Project和长上下文，但在处理多个文件、多个模块相互依赖的作业时，仍然可能在分析局部代码时忽略其他模块的约束条件。这导致它可能在一个函数里看到Bug，但没有意识到这个函数根本没有被任何其他模块调用，这在实际工程中是一个信号，但在AI的分析框架里不总会触发警告。

缓解措施： 对于项目级作业，在Prompt中明确要求“除了分析每个文件的代码质量，还需要检查文件间依赖关系、未引用的代码模块、以及模块间接口的一致性。”

风险三：学生可能反向优化，针对AI评分规则写出“高分低质”代码

这是结构性风险。如果学生逐渐了解AI的评分偏好（比如知道AI对变量命名的规范检查更严格、但对算法复杂度的判断较宽松），理论上可能出现的投机行为是：花更多时间在“AI看得见的规范”上，而忽略“AI看不清的逻辑质量”。

目前我还没有观察到实际的学生投机案例（因为学生并不确切知道评分系统的工作机制），但这需要在系统设计中预设反制措施：

• 不公开AI评分的具体权重和检查规则
• 保留人工随机深度抽查作为威慑
• 在课程中明确传达：AI辅助批改只是第一层，所有关键评分最终由教师确认

风险四：教师对系统的过度信任可能导致批改质量事故

这是我个人最警惕的风险。当AI连续准确处理了20份作业后，人的自然倾向是减少复核投入， “看起来挺靠谱的，快速过一下就行了”。但恰恰是这种时候，AI可能在第21份作业上犯了一个离谱的错误（比如把一个有创意的O(n)解法误判为O(n²)），而教师因为信任惯性没有及时发现。

我给自己定的强制规则是：无论AI表现多好，不能跳过阶段五中的第一优先级检查（所有[？]标记条目的逐个验证）。 这条规则的存在不是为了怀疑AI，而是为了保持人的介入警觉。当你在持续复核中发现AI的[？]标记数量逐次下降且准确率上升时，你会获得真实的置信度增长，而不是源自偷懒的虚假置信。

九、写给不同角色的实操路线图

不同立场的人对这个设想的落地速度和深度会有不同考虑。这里分别给出针对性建议。

给有批改压力的课程教师/助教：从“最小试点”开始

如果你现在每周被批改压得喘不过气，不要尝试一步到位地部署完整的工作流。我建议的起步路径：

第一个月：只做规范检查。

• 搭建Claude Code Project，上传作业要求
• Prompt只要求AI输出“规范性问题清单 + 位置标注”，不要求评分
• 你仍然自己打分，但在打分之前先看一遍AI的输出，确认哪些需要纳入扣分

这个阶段的目的是让你自己建立对AI输出质量的直观感知，同时立刻获得规范性检查的人力减负。

第二个月：加入评分辅助。

• 在原来规范检查的基础上，加入评分功能
• 你仍然自己打分，但把AI的评分作为第二参考，重点关注二者不一致的地方
• 记录下AI评分与你的评分出现分歧的类型和频率

第三个月：如果前两个月效果满意，逐步过渡到完整工作流。

• 注意：这个过渡不是“把评分交给AI”，而是“用AI做初稿，你来定稿”

给教育技术决策者：关注系统性部署的前提条件

如果你在考虑将AI批改作为院系级的方案推广，有几个条件需要先满足：

1. 教师培训必须先行。 不是培训“怎么用工具”，而是培训“怎么审计AI的输出”。培训内容应包括AI评分偏差的典型模式、复核优先级策略、以及与教学理念冲突时的处理原则。
2. 不能强制所有课程统一使用。 如前所述，不同作业类型AI的有效性差异巨大。硬推可能导致设计类、开放性课程产生大量评分争议。
3. 建立教师间的知识共享机制。 一位教师迭代出的好Prompt和发现的新偏差模式，应该能惠及其他教师，而不是各自从头摸索。
4. 成本归口要明确。 API费用虽然不高，但如果推广到全院几十门课，需要有清晰的预算和结算机制。

给对AI教育应用感兴趣的研究者：几个有价值的研究方向

在做这个项目的过程中，我意识到有一些问题目前的公开研究还不足以给出明确答案：

• AI评分偏差与学生画像的关联性。 AI是否对特定类型的学生（如非母语者、代码风格独特的初学者）存在系统性评分偏差？
• 长期依赖AI批改对学生学习行为的影响。 学生是否会针对AI评分偏好调整自己的编程习惯？这种调整是良性的（更规范）还是策略性的（投机取巧）？
• 不同大语言模型在批改可靠性上的可测量差异。 Claude Code vs GPT-4 vs Gemini在这个具体场景下，各自的错误模式有什么不同？

总结：把AI放回它该在的位置

回到文章开头那个问题：这个初步设想的核心到底是什么？

经过近一个学期的测试和迭代，我的结论很清楚，它不是关于“让AI更快地改作业”的工程优化，而是关于“重新定义教师在批改环节的角色”的教学设计。

当Claude Code处理掉规范检查、基础评分、错误模式统计这些可以结构化的工作后，教师被释放出来的精力应该投入哪里？不是投入更多的批改（那样就只是把节省的时间又填回去了），而是投入到：

• 设计更好的作业题目（而不是因为批改成本高就减少编程作业）
• 基于AI生成的班级错误模式诊断，改进课堂讲解的重点
• 给那些解题思路有创意但不成熟的学生写真正有教学价值的引导性反馈

AI应该承担的是批改中“可以标准化”的部分，而教师应该聚焦在“不能被标准化”的部分。 这个分工逻辑如果搞反了，让AI去判断创造性，让教师去逐个检查缩进，那就是在用最贵的资源做最便宜的事。

至于下一步怎么走？如果你是一位正在阅读这篇文章的教师或助教，我建议你做的事情是：下周就拿一份已经批改完的旧作业，按照本文描述的流程跑一遍Claude Code，看看AI的输出和你的实际评分有多少差异，差异在哪些地方。 这个简单实验带给你的认知，会比阅读任何文章都更具体、更直接。你不需要立刻改变整个工作流，只需要先建立第一手的数据和直觉。然后你再回来判断：对于你教的这门课，这个初步设想应该推进到什么程度。

如果你根本就没有批改负担，只是想了解AI在教育中的应用，那么这篇文章至少说明了一件事：AI最令人兴奋的应用场景往往不是“替代人类专家”，而是“让人类专家有精力和信息去做更高级的决策”。 计算机课程作业批改的初步设想，也不过是这个更宏大命题的一个小注脚。