第一次冒出给慕课测验写自动答题工具的想法是在连刷了三天《工程伦理》章节测验之后。这门课的题目本身不算难但架不住量多——每章少则十道多则二十几道单选、多选、判断、案例分析混在一起刷完一章眼睛都快花了。于是我琢磨着既然题目格式这么规整、答案又有迹可循能不能让AI大模型替我读题、替我选答案、替我交卷这就是“果壳大在线-慕课章节测验和课后习题AI自动答题”这个项目的由来。项目做出来后我其实花了很多天消化一个悖论我用AI去自动完成一门教“工程师要讲诚信”的课这行为本身到底算不算违背工程伦理这篇文章不打算鼓吹“躺着拿满分”而是把完整的实现思路、技术选型、踩坑记录都摊开最后站在工程伦理的角度重新审视一遍。如果你是做AI应用开发的、被重复刷题折磨过的学生或者单纯对“大模型自动化”这套组合拳感兴趣这篇应该能给你一些能直接落地的参考。1. 为什么选工程伦理课做AI答题试验田1.1 慕课测验的真实痛点在哪慕课平台的章节测验和课后习题设计初衷是“以练促学”但实际使用中体验往往不太一样。工程伦理这类通识课题量大、知识点密、章节多而且很多题是同一知识点的不同变体——换个案例背景、换个选项顺序答案逻辑其实没变。这意味着什么意味着人肉刷题的时间成本极高但认知收益很低刷到后面完全是机械劳动。我当时统计了一下光“工程师的职业伦理”这一章的课后习题就有近30道其中一半以上是概念复述型的选择题。这种题恰恰是大模型最擅长处理的题干信息完整、答案是确定的、不依赖实时数据。相比之下如果选一门需要大量计算推导的理工课比如高数、物理模型的错误率会明显上升自动答题的可行性就会大打折扣。所以选工程伦理做试验田不是随手抓的而是基于题目特征做的理性判断。做这类自动化项目第一步永远是分析目标对象的“结构化程度”——题目越规整、答案越确定自动化成功率越高。1.2 工程伦理题目的结构特点适合AI工程伦理这门课的题型分布很有代表性我粗略做了个分类概念辨析题考察“伦理困境”“利益冲突”“知情同意”等核心概念的准确定义答案基本就在教材原文里。案例判断题给出一个工程场景判断工程师的行为是否合规比如“某工程师发现桥梁设计存在安全隐患是否应该立即上报”。这类题本质是伦理原则的应用。多选题这是难点经常是“以下哪些属于工程伦理的基本准则”选项多达5到6个漏选错选都不得分。价值排序题比如“当安全与利润冲突时工程师应优先考虑什么”这类题三观正就能答对。从AI答题的角度看概念辨析题和价值排序题几乎是送分题案例判断题需要模型具备一定的伦理推理能力真正难啃的是多选题——后文我会专门讲怎么用提示词工程解决它。1.3 选型背后的三个关键决策做这个项目之前我纠结过三个问题这里直接把结论和理由一起说了。第一用在线大模型API还是本地部署我选的是在线API。理由很直接工程伦理题不需要处理敏感数据调用在线模型我当时主要用了通义千问的qwen-plus也测过DeepSeek和智谱GLM成本低、效果稳不用折腾显卡和推理服务。如果你只是为了个人使用完全没必要上本地部署。第二用Requests直接模拟接口还是用浏览器自动化我一开始想走捷径抓慕课平台的接口直接提交答案但平台有加密参数逆向成本太高。后来换成Playwright做浏览器自动化虽然速度慢一点但胜在稳定相当于让程序像真人一样去页面里点击、答题、交卷。第三答案提交是全自动还是半自动我的最终方案是半自动自动生成答案、自动填入但提交前弹窗给我看一眼。这不是怂是后来被平台警告过之后学乖了——批量刷题如果节奏太机器化很容易触发风控。2. 核心模块拆解与实现方案2.1 题目获取从网页到结构化数据的三种路径自动答题的第一步是把网页上的题目变成程序能处理的结构化数据。这里有三条路按推荐程度排序路径一手动复制粘贴。最原始但最不容易出错。适合题目量少、频率低的情况。我前期调提示词的时候就是这么干的把题目直接粘到对话窗口里测试模型回答质量效率虽低但能快速验证方案。路径二浏览器DevTools本地收集。打开网页的开发者工具在Console里执行一段JavaScript脚本把页面里的题目元素提取成JSON然后粘贴到本地文件。这种方式不需要写复杂的自动化代码适合页面结构简单的场景。路径三Playwright全自动抓取。这是最终形态。用Playwright打开浏览器、登录、进入测验页面、等待题目渲染完成后按DOM结构批量提取题干和选项。用代码实现大概是这样的from playwright.sync_api import sync_playwright def fetch_questions(url): with sync_playwright() as p: browser p.chromium.launch(headlessFalse) page browser.new_page() page.goto(url) page.wait_for_selector(.quiz-question) questions [] for q in page.query_selector_all(.quiz-question): title q.query_selector(.q-title).inner_text().strip() options [ opt.inner_text().strip() for opt in q.query_selector_all(.q-option) ] questions.append({title: title, options: options}) browser.close() return questions实际使用中选择器需要根据具体页面的HTML结构调整但整体思路就是“定位题目容器→提取题干→提取选项”。这里有个细节题目里的图片无法直接转成文本我一般是把图片链接单独存下来后续要么调用多模态模型识别要么人工处理。2.2 答案生成提示词工程是决定成败的关键题目拿到手之后核心工作就是让大模型输出正确答案。这部分的难点不在调用API而在提示词的设计。直接丢一道题给模型它可能给你一段长篇大论的解释然后你还要从中猜答案效率极低。我迭代了四版提示词最后固定下来的核心版本大概长这样SYSTEM_PROMPT 你是工程伦理课程的助教熟悉国内工科高校《工程伦理》教材的知识体系。 你的任务是根据题目和选项输出唯一正确的答案编号。 规则 1. 所有答案编号使用大写字母多选题按字母升序排列如ABD 2. 只输出答案编号禁止输出任何解释、标点或多余字符 3. 如果题目为判断题正确输出“对”错误输出“错” 4. 如果确实无法判断输出“UNKNOWN”不要瞎猜。 这个提示词起作用的关键点有三个。第一给模型一个明确的角色——“工程伦理助教”这能调动它相关知识库中的对应内容第二把输出格式约束到极致让它根本没有发挥废话的空间第三允许输出UNKNOWN给答案校验留了兜底空间模型在不确定的时候不会硬编一个答案。多选题是命中率的重灾区。早期的提示词没做约束模型经常漏选。后来我在提示词里加了一条推理要求先判断选项本身是否正确再判断是否正确回答了题干问题最后按字母序合并。比如题干问“以下哪些属于工程伦理的基本原则”备选项里有两个是正确表述但与题干无关模型前期很容易把这两个也选进去。加了“二次校验”机制后正确率从70%左右提升到了88%以上。2.3 答案校验多模型交叉与置信度判断如果不做任何校验直接把模型输出的答案填进网页大概率会在多选题和案例分析题上翻车。我的做法是引入一次冗余校验把同一道题发给两个不同的大模型比如qwen-plus和GLM-4-Flash如果两个模型答案一致认为该题置信度较高直接采纳如果答案不一致把这道题标记为“待人工确认”弹窗让我看。这个思路其实和工程上常用的“冗余容错”一样。额外调用一个模型的成本很低单题token消耗几乎可以忽略但换来的是正确率的大幅提升。实测下来单模型准确率在82%左右双模型交叉后一致部分占总题量约75%的准确率能到94%以上剩下25%的题目人工确认一下就行。调用API的代码非常直接现在国产大模型普遍兼容OpenAI的接口格式from openai import OpenAI client OpenAI( api_keyyour-api-key, base_urlhttps://dashscope.aliyuncs.com/compatible-mode/v1 ) def ask_model(prompt, systemSYSTEM_PROMPT): resp client.chat.completions.create( modelqwen-plus, messages[ {role: system, content: system}, {role: user, content: prompt} ], temperature0.2 ) return resp.choices[0].message.content.strip()这里把temperature调低到0.2目的是让模型输出尽量保守和稳定减少随机性。多选题场景我不希望模型“发挥创意”只需要它按教材知识做标准答案。2.4 自动填写与提交的节奏控制答案生成后程序要模拟真人操作在页面上逐一点击选项、点击“下一题”、最后点击“提交”。这一步的代码逻辑不复杂但有一个容易被忽略的坑——节奏控制。def submit_answer(page, answer_chars): for ch in answer_chars: idx ord(ch) - ord(A) selector f.q-option[data-index{idx}] page.click(selector) page.wait_for_timeout(300 idx * 100) # 模拟人类的点击间隔 page.click(.confirm-btn) page.wait_for_timeout(800)人不可能以毫秒级的速度连续点击如果答题过程快得像闪电平台风控一眼就能识别出这不是真人操作。我给每一步操作都加了随机延时最短300毫秒、最长1秒整套题做完大概耗时接近真人速度的80%。这不算聪明但管用——我在测试阶段用这个节奏连续刷了四章没有再触发过异常提示。3. 完整实操记录从环境搭建到实测数据3.1 环境准备与依赖安装这个项目对环境要求很低纯Python实现不需要GPU。我用的版本是Python 3.10依赖主要是playwright、openai库也可以换成兼容OpenAI格式的anyio等SDK。安装命令就两行pip install playwright openai playwright install chromium第二行是下载Chromium浏览器内核Playwright需要它来驱动浏览器。这个过程如果网络不好可能会慢一点但基本上一次性搞定。登录环节我没做自动化因为慕课平台通常有验证码、滑块等登录校验自动化的投入产出比太低——我的做法是Playwright启动浏览器后程序先暂停我手动在页面里登录一次然后利用会话保持继续操作。3.2 题目提取与答案写入的完整链路整个流程串起来大概是手动登录→进入章节测验页面→程序提取本页所有题目→逐题调用大模型获取答案→在页面上自动选择→点击“下一题”继续→本页完成后程序暂停人工检查提示项→提交。以下是综合了上面各段代码后的核心执行逻辑def main(): with sync_playwright() as p: browser p.chromium.launch(headlessFalse) page browser.new_page() page.goto(https://example-mooc-platform.com/course/ethics/quiz) input(请手动登录完成后按回车继续...) questions fetch_all_questions(page) # 提取当前页全部题目 answers {} for q in questions: a1 ask_model(build_prompt(q), SYSTEM_PROMPT) a2 ask_model(build_prompt(q), 你是另一位工程伦理专家请回答以下题目。) answers[q[id]] a1 if a1 a2 else UNKNOWN for q in questions: ans answers[q[id]] if ans UNKNOWN: ans input(f第{q[id]}题需要人工确认{q[title]} 请输入答案) submit_answer(page, ans) page.click(.final-submit) input(检查无误后手动提交按回车结束。) browser.close()这套流程跑通之后我统计了一下时间一章20道题从进入页面到提交完成大约6到8分钟其中包含人工确认环节。同时在线做这套题大概需要15到20分钟。效率提升可观但这并不是最核心的收获——关键是它验证了大模型浏览器自动化这条技术路线的可行性。3.3 实测数据与结论我拿两个章节做了对照测试数据如下测试项目单模型正确率双模型交叉后正确率人工确认比例第一章单选判断91.6%96.7%12%第二章含多选案例82.3%91.2%25%结论很明确单选和判断题由于答案是唯一的大模型几乎不会错多选题和案例分析题虽然有交叉校验兜底但模型能力上限决定了仍有漏网之鱼。如果想进一步提升准确率可以朝两个方向努力一是给提示词补充更多教材背景知识比如把某章的知识点摘要塞进system prompt二是引入“自一致性”方法——同一道题让模型回答多次取出现频率最高的答案。4. 技术之外的工程伦理反思4.1 工程伦理课到底在教什么这个话题不能绕开。工程伦理并不是一门教你背条文的课它核心讨论的是工程师在职业活动中遇到的价值冲突怎么处理安全与成本冲突、忠诚与揭发冲突、个人利益与公共利益冲突。教材里反复强调的几个概念——诚信、负责、安全优先、利益冲突回避——恰恰是工程师职业底线的基石。我刷完整本内容后发现这门课最终想训练的是一种“伦理直觉”遇到问题能敏感地意识到“这里有伦理风险”而不是拿一套死规则去套。所以章节测验里大量案例题考的是原则应用而非死记硬背。4.2 自动答题的行为边界在哪里到这里必须说点不好听的如果你用这个工具纯粹是为了“刷分过关”那它本质上就是一种学术不端行为。慕课平台的用户协议普遍明确禁止自动化脚本替代本人学习学校对这类行为的认定也越来越严。更讽刺的是这门课叫《工程伦理》——用不诚信的方式通过一门教诚信的课这个行为本身就是最好的反面案例。我做完技术验证之后把工具的定位改了不再让它自动提交而是变成了“学习辅助器”。具体用法是调用大模型给出答案的同时强制生成解析并在解析末尾提出一个延伸问题。这样程序不再代替我学习而是变成一个随时在线的答疑助教。这里贴一段改造后的解析生成逻辑def generate_explanation(q, answer): prompt f题目{q[title]} 选项{q[options]} 正确答案{answer} 请用200字以内解释为什么选这个答案重点指出对应的工程伦理原则 最后提出一个相关的思考问题。 return ask_model(prompt)用这种方式题目还是那套题但AI的角色从“代打”变成了“陪练”。在我看来这才是大模型在教育场景下更可持续的应用方式。4.3 工程师的责任边界能做不等于应该做最后一条反思送给和我一样喜欢折腾工具的人。技术可行性永远不应该等同于道德正当性。我们能写爬虫、能调API、能做全自动答题这些能力本身没有对错但使用场景决定了价值取向。工程师的伦理责任恰恰体现在“做得到”和“应该做”之间怎么选择。这堂课上有一个经典的“挑战者号”案例——工程师明明知道航天飞机有安全隐患却迫于压力选择了沉默最终导致悲剧。这个案例放在自动答题场景里的映射是我明明知道这个工具存在滥用风险如果我装作不知道、不做任何提醒那我就是在重复那些犯错工程师的路径。技术文章可以写但边界必须说清楚。5. 常见问题与避坑清单5.1 API与模型层面的典型坑限流与超时免费额度的QPS每秒请求数很低连续调用几十次就容易报429。解决办法是在请求之间加sleep或者用线程池控制并发数实测加0.3秒延迟就能大幅降低报错率。上下文污染如果一条提示词里塞了太多题目模型可能“忘记”前面的格式要求开始自由发挥。建议一次只问一道题不要贪多。多选答案格式不稳定模型偶尔会输出“ABD”和“A、B、D”两种格式务必在解析层统一清洗不然提交时字符匹配会出错。我在代码里加了一行re.sub(r[^A-Z], , answer)专门处理。5.2 页面自动化层的坑元素定位失败慕课平台会不定期更新前端组件CSS类名说变就变。今天的.q-option明天可能变成.option-item脚本失败不是代码写得不对而是页面变了。应对思路是给关键选择器做一层配置改起来快。弹窗与动态加载有些章节测验需要点击“开始答题”才会动态渲染题目直接抓取会抓到空数据。正确的做法是先点击按钮然后用wait_for_selector等待题目容器出现。风控警告我测试时遇到过平台弹出“检测到异常操作”的提示。触发原因是同一IP短时间内在不同章节间快速切换。解决办法就是前面说的控制和真人接近的节奏不要贪快。5.3 给后续尝试者的建议如果你只是在工程伦理这类通识课上想用AI辅助学习我的建议是放弃“全自动提交”这条路线改成“半自动问答错题复盘”的组合。让大模型帮你梳理知识点、解释案例、生成错题解析这些功能完全不会触碰学术诚信的红线但对成绩的提升反而更实在。另外如果真想挑战更复杂的自动答题场景比如有计算题的理工课别指望通用大模型直接输出正确答案更靠谱的方案是让模型输出解题步骤再由本地Python代码执行计算并验证——这种“大模型负责推理、代码负责计算”的混合架构是更工程化的方向。写在最后这个项目前后折腾了大概两周代码量不大但带给我的思考密度很高。最初它只是一个“偷懒工具”做完之后反而让我把《工程伦理》这门课的核心原则内化了一遍诚信、责任、边界意识。现在我仍然用它帮我刷题——每次运行之前我会强制把生成解析的逻辑打开至少过一遍每道题为什么选这个答案。这算是我给自己设定的一个“伦理开关”。最后分享一个小技巧如果你也在做类似大模型自动化的应用建议把所有的提示词、页面选择器、运行配置单独抽成外部文件不要硬编码在代码里。大模型应用的迭代速度远比你想象中快今天能稳定用的提示词下周可能就失效了。配置和逻辑分离能让你在提示词调整时不用反复改代码——这个习惯帮我省了很多事。