软件工程实践——大模型评测作业

为了方便阅读以及助教评分，请大家在博客开头给出博文目录，作为内容的索引

• 请确认目录可以 正确跳转！

• 请在博客中 加一个链接指向本次大模型评测作业——大模型评测作业

• 请务必包含以下大标题，标题含义相近即可，你可以个性化你自己的大标题，并添加下属的小标题：

  • 第一部分 调研，评测

    • 大模型1

      • 体验

      • 自动化测试

      • 结论

    • 大模型2

      • 体验

      • 自动化测试

      • 结论

  • 第二部分 分析

    • 开发时间估计

    • 同类产品对比排名

    • 软件工程方面的建议

    • BUG存在的原因分析

    • 市场概况

    • 产品规划

Tips

🔺本次作业要求与邹欣老师发布的 软件工程-案例分析作业 类似，希望同学们认真对待本次作业~

本次作业截止时间为：2026年11月11日 23：59

注：博客发布后需要审核，请同学们记得提前发布博客，避免影响作业提交。

O、前言

很多同学有疑惑：

软件工程课是否就是枯燥的理论课？

或者是几个牛人拼命写代码，其他人抱大腿的课？

要不然就是学习一个程序语言，练习某个框架，搞一个职业培训的课？

都不对！软件工程有理论，有实践，更重要的是分析，思辨，总结。在课程中，同学们自己组织团队写一个软件发布，然后分析其中的得失，的确是学习软件工程的一个好方法。这样能根据切身体会来分析，很有价值，但也有可能“身在此山中，未能看清全局”。而且，课程时间有限，我们也不能做很多具体的项目。因此，我们也需要从间接经验中学习，分析。别的项目的成败同样给我们很多启发！

我们生活中很多时候要和软件打交道，大家上课开小差时候玩的手机游戏，背英语单词的手机App，买火车票的网站，互相联系用的微信微博，等等，都是软件，都很值得分析。

• 你为何成为该软件的用户？
• 软件背后的团队做对了什么，做错了什么？
• 软件工程质量如何？
• 如果你来做，会做得更好么？

通过各种案例分析，评测，思辨，总结，我们就能看到软件工程的原则在实践中的种种体现，学好软件工程，帮助我们在实践中做得更好。

分析什么样的软件也有讲究，这就要说到一个故事：

某国空军为了提高飞机在空战中的存活率，决定加固飞机，但是加固什么地方呢？他们研究空战后飞回基地的飞机，飞机各部分中弹的地方和密度，想以此得出结论。但是专家们忽略了一点，那些被击中要害的飞机，都没有能飞回基地，也没有能够参加这些调查。

幸存者偏差 (Survivorship bias) 是一种常见的逻辑谬误，意思是只能看到经过某种筛选而产生的结果，而没有意识到筛选的过程，因此忽略了被筛选掉的关键信息。这东西的别名有很多，比如“沉默的数据”、“死人不会说话”等等。

因此，我们不光要分析那些经历战场的考验而最后 "活着出来" 而胜利的软件，还要分析那些在战场中被打败，或者伤痕累累，正在挣扎的软件，这样才能全面地了解软件工程的原理在好/坏软件上所起的作用。

有的同学会说：

“我只会看看界面，写不出来...”

那么，可以看看这个 只评价界面的分析报告，争取写出类似水平的报告来：

2023年软件评测优秀作业展示：

• https://blog.csdn.net/m0_51697851/article/details/129953018 [作者 talada]
• https://blog.csdn.net/qq_53904588/article/details/130022579 [作者 凰宸ovo]
• https://blog.csdn.net/W_B_camel/article/details/129998914 [作者 琴和悠扬]
• https://blog.csdn.net/anshun33/article/details/130015029 [作者 赖安顺]

注：请先仔细阅读本次作业的要求，根据要求完成自己的思考，在完成作业后可以选择参阅，看看自己是否有可以提升的地方。前几次作业有出现模仿去年博客的情况，一旦助教发现将进行扣分处理，请同学们 独立完成作业，严禁一切形式的模仿和抄袭。

一、作业要求

1、本学期供分析的产品

随着人工智能和大语言模型（LLM）的发展，软件已从简单的规则/表单交互，演进为以自然语言为核心、具备多轮对话与工具调用能力的智能应用。当前大模型领域呈现出几个明显趋势：

• **从"问答"走向"智能体（Agent）"**：模型不仅能聊天，还能通过工具调用（Function Calling）、联网检索、代码执行等方式完成任务；
• 推理模型兴起：以 DeepSeek-R1 为代表的推理增强模型，在逻辑推理、复杂任务上表现突出；
• 多模态与开源生态繁荣：图文/音视频理解能力普及，开源模型（Qwen、DeepSeek、GLM、Kimi 等）与云上免费 API 大量涌现。

在软件工程实践中，如何设计自动化测试场景来客观、量化地评估模型性能，是非常核心的能力——它直接决定了"选哪个模型、怎么集成、如何迭代"这些工程决策。

本次作业要求同学们：

💡 通过编写代码来自动化完成一个"购车决策"任务，并对不同大模型在该任务中的表现进行量化评测和对比分析。在传统多轮问答基础上，可进一步考察模型的工具调用、指令遵循与稳定性等新时代能力。

本作业旨在让学生掌握以下能力：

• 设计并实现自动化测试脚本；
• 构建多轮任务型对话场景，可进一步尝试接入工具调用/检索能力；
• 提炼可量化的模型评估指标（准确度、一致性、指令遵循、成本与延迟等）；
• 将测试结果可视化与分析。

推荐模型平台（可任选，不局限于一下这些大模型，仅做参考推荐，至少测试两个大模型，建议覆盖不同类型，例如一个通用对话模型 + 一个推理模型）：

以下列出当前主流的国内外大模型平台，均可通过官方 API 或网页端调用。可结合免费额度、模型类型与任务需求自由选择。

国内主流平台：

1. 阿里百炼（通义千问 Qwen） — 通义千问全系列（Qwen3、QwQ 推理模型等），新用户赠送较多免费额度，支持工具调用、多模态。
2. 智谱AI（BigModel，GLM） — GLM 系列（GLM-4/4.5、GLM-Z1 推理模型等），有完全免费模型可供调用 API，支持多模态与工具调用。
3. DeepSeek（深度求索） — 开源模型（DeepSeek-V3 通用、DeepSeek-R1 推理），性价比极高、推理能力强，是"推理模型"对比的代表。
4. Kimi（月之暗面） — Kimi 系列（K2 等），长文本理解与多模态能力突出，支持工具调用。
5. 火山方舟（豆包/Doubao，字节跳动） — 豆包系列（Doubao-1.5/2.x 等），中文能力强、免费额度充足，火山引擎统一平台支持工具调用。
6. 百度千帆（文心一言/文心 ERNIE） — 文心大模型 4.5 系列，中文语义理解能力强，百度智能云统一接入。
7. 腾讯混元（Hunyuan） — 腾讯混元大模型，支持多模态与工具调用，腾讯云平台。
8. 讯飞星火（iFlytek Spark） — 讯飞星火大模型，中文、语音能力突出，有免费体验额度。
9. MiniMax（稀宇科技） — MiniMax 系列（如 MiniMax-M1、abab 系列），长文本与多模态能力较强。
10. 阶跃星辰（StepFun） — Step 系列（Step-2/3），多模态理解能力强。
11. 华为云盘古（Pangu） — 盘古大模型，聚焦行业垂直场景（政务、制造等）。
12. 也可选择 Groq、OpenRouter 等统一网关，一个 key 对比多家模型。

国外主流平台：

13. OpenAI（GPT 系列） — GPT-4o/4.1、o 系列推理模型（o3 等），业界标杆，需付费。
14. Google Gemini（谷歌） — Gemini 2.x 系列，多模态能力领先，有免费额度。
15. Anthropic（Claude） — Claude 4 系列，长文本与代码能力出色，需付费。
16. Meta Llama（开源） — 开源系列模型，可本地部署或通过云平台调用。
17. Mistral AI（法国） — Mistral 系列开源模型，欧洲主流。

注：至少测试两个大模型，鼓励测试一个通用模型 + 一个推理模型，以观察两类模型在购车决策任务上的差异。

补充说明：以上平台及模型仅供选型参考，实际可用模型、免费额度、价格及接口能力以使用时的官方说明为准。网页端可用于使用体验，自动化测试应通过官方API、模型服务接口或本地模型接口完成。记录平台、精确模型标识、测试日期和主要参数；同一模型仅修改提示词或参数不算两个模型。不要求购买付费模型或设备，建议先少量试调用，确认额度和费用后再批量测试。

2、博客具体要求

第一部分 调研，评测

(参考知识点：软件的 bug，功能评测，黑箱测试，第8章用户调研，12章软件的用户体验)

体验两个产品的功能

（1）使用体验

• 介绍和使用软件: 介绍软件基本功能；注册并使用这个软件的主要功能，并上传使用软件的照片

• 优缺点分析: 描述使用这个产品的过程，解决了用户的问题么？软件在数据量/界面/功能/准确度上各有什么优缺点？用户体验方面有问题么？

• 用户对产品有什么改进意见？

• 采访另一个用户: 让TA使用10–30分钟被测产品的基本功能，TA能上手使用么？有什么明显的困难，这些困难可能与哪些产品设计有关？请区分实际观察与原因推测。（请将采访过程以图片和文字的方式记录下来，且要求采访对象为计算机、软件相关专业的学生）

  记录请至少包含以下几点：

  a. 采访对象的背景，为什么选择这个人采访？TA的需求是什么？

  b. 描述采访对象实际使用的产品栏目

  c. 采访对象使用软件的过程中会遇到的问题和亮点

  d. 采访对象觉得从用户体验的角度来说需要改进的地方有哪些？

（2）自动化测试

1. 请通过编程方式创建一个模拟的购车决策环境

在该环境中，程序应能与两个大模型（例如：阿里百炼 Qwen、智谱 GLM、DeepSeek、Kimi 等）进行多轮对话，完成从需求到决策的全过程。鼓励在此基础上接入模型官方的工具调用（Function Calling）能力——例如让模型通过"查询车型库/联网搜索/价格计算器"等工具获取真实数据后再作答，以考察其在真实工程场景下的表现：

为保证比较公平，实验设置应满足以下要求：

• 统一测试条件：两个模型使用相同的测试场景、提示词、车型数据及输出要求，尽量统一可配置参数；无法统一的设置应说明。
• 固定车型数据：基础实验可自行整理一份固定车型数据集，在每次任务开始时提供给两个模型。数据至少注明车型年份与配置、价格口径、参数单位及来源日期。也可采用明确标注的教学模拟数据，但不得将其称为真实市场数据。
• 说明联网条件：使用联网检索时，应单独说明检索条件和核验来源，避免将数据获取差异直接解释为模型推理差异。

测试场景与运行次数应满足以下要求：

• 场景设计：至少设计3个不同购车场景，每个场景明确预算、使用需求及至少一条预算以外的硬约束，并在正式运行前写明预期结果和评分规则。
• 重复运行：每个场景对每个模型独立运行至少3次，即两个模型至少完成 2个模型×3个场景×3次＝18次完整多轮任务。
• 上下文管理：同一次任务内保留对话上下文，不同运行之间重新开始对话。
• 需求变更测试：至少一个场景在后续轮次增加或修改约束，以检查上下文保持能力。用户明确修改需求后，采用新需求不算前后矛盾。

2. 提出购车意图

例如：“我最近打算买车，预算大约20万元左右，主要用于城市通勤，希望空间舒适、安全性高。”

3. 大模型给出初步推荐

程序自动捕获模型推荐的几款车型，并保存为候选列表。

4. 输入购车要点

程序向模型逐条提出更具体的购车需求（如动力、续航、油耗、安全、保值率、品牌口碑等），要求模型基于这些要点分析或更新推荐。

5. 性能参数表格化对比

让模型输出几款候选车型的性能参数对比表（例如动力、续航、空间、安全配置等），程序自动提取表格内容并保存。

6. 选出目标车型

程序要求模型结合前面信息，给出最终推荐，并说明理由。

7. 自动化评测

程序对模型的回答进行自动或半自动评分，量化其表现差异。建议至少从以下维度进行量化评分（可自拟权重）：

• 推荐合理性/准确度：推荐的车型是否符合预算与需求约束；
• 多轮一致性：多轮对话中是否出现前后矛盾、忘记已给约束；
• 指令遵循：是否按要求输出表格、给出理由、调用指定工具；
• 工具调用正确性（若实现）：是否调用正确的工具、参数是否规范；
• 信息真实性/防幻觉：是否编造不存在的车型或数据；
• 稳定性：依据每个场景至少3次完整任务的独立运行，比较成功率与指标波动；多个车型均满足要求时，不因推荐车型不同而直接判为不稳定；
• 成本与延迟：单次任务的平均响应时间与 token 消耗（可在同一成本/时间预算下比较）。

各指标须写明判定标准、计算方式及样本数，避免只凭主观印象打分。

8. 测试结果可视化与分析

将多个维度的评分汇总为对比表格或图表（如雷达图、柱状图），清晰展示模型在不同评测维度上的表现。图表应注明指标含义、单位及必要说明。

补充要求：

• 案例分析：至少分析2个失败或边界案例，说明具体表现、相关测试记录及可能原因。未出现失败时，可补充边界测试，并单独标注。此处侧重测试现象与证据，工程改进建议放在第二部分展开。
• 改进与方案比较：针对评测中发现的技术问题，提出一项改进方案，与至少一个备选方案比较，说明选择理由及验证方法，无需实际实现。
• 结论范围：模型对比或排名仅适用于本次数据、场景和实验设置，不代表行业整体排名。每个场景仅重复3次时，应说明样本量较小，结论存在局限。

代码与实验材料提交要求：

• 完整代码：在博客中提供代码仓库链接。正文可展示关键代码，无需粘贴全部代码。
• 实验材料：提供车型数据、提示词、脱敏原始记录、评分结果及图表。原始记录可通过链接或附件提交，无需全部贴入正文。
• 密钥保护：API Key须通过环境变量或本地私有配置读取，不得在代码、博客或附件中上传真实密钥。

第二部分 分析

(参考知识点：8.6节对工作的估计，和14.1节软件工程的质量)

从书上我们可以得知：

程序 = 算法 + 数据结构

软件 = 程序 + 软件工程（软件服务还有数据，内容的因素）

软件企业 = 软件 + 商业模式

请分析你所使用的大模型平台或测试系统分别体现在哪些层次？

1. 程序层面：算法/数据结构体现？（如模型架构、上下文管理、工具调用的参数解析等）
2. 软件工程层面：有哪些服务、文档、协作机制？（如 API 网关、评测工具链、版本迭代、开放平台生态）
3. 商业层面：它的商业模式或竞争优势在哪里？（如免费额度获客、Token 计费、推理模型溢价、开源+云服务双轨策略等）

另外，请补充以下分析：

• 同类产品对比与选型：引用第一部分的评测结果，简要说明不同使用需求下，两个被测模型各自适用的条件及选型建议，无需重复展示图表、计算指标或进行排名，也无需另测更多产品。
• 软件工程建议与BUG原因分析：引用第一部分的失败或边界案例，分析问题可能来自模型、数据、提示词、解析程序还是接口服务，并从测试覆盖、接口适配、上下文管理或异常处理等角度提出工程改进建议，无需重复描述案例。无法观察的模型内部原因应标为假设，不作确定性断言。

(参考知识点：《构建之法》第8章功能的定位和优先级；第9章项目经理)

这个软件/网站/服务有很多可以提高的部分，如果你是新上任的项目经理，如何提高从而在竞争中胜出？请针对以下的问题进行思考

4. 市场概况

   • 首先市场有多大？（大模型 API 市场、智能体/Agent 应用市场的规模与增速）
   • 其次直接的用户有多少？潜在的用户又有多少？（开发者、企业客户、C端用户等）

5. 产品规划

   ​ 你要在当前模型的基础上设计什么样的新功能？为何要做这个功能，而不是其他功能？为什么用户会用你的产品/功能？你的创新点在哪里？（可结合智能体编排、行业垂直场景、多模态、低代码接入等方向展开）可以用 NABCD分析。

二、作业评分规则

本次作业满分100分：

第一部分（60'）：【覆盖教学目标4】

• （10'）大模型的体验描述（功能介绍与使用、优缺点分析、用户采访、改进意见）
• （25'）自动化测试代码实现（使用代码实现自动化测试（如 Python 调用 API、批量问答、结果记录、CSV输出））
• （10'）测试结果整理与可视化（汇总测试数据，制作表格或图表对比，如雷达图/柱状图）
• （10'）评测结论与量化对比分析（从多维度评分总结哪个模型更适合购车推荐，并说明理由）
• （5'）创新设计意识与方案优选（结合评测结果提出合理的优化/优选设计方案或创新点）

第二部分（40'）：【覆盖教学目标5】

• （10'）说明你对大模型对我们现实生活所带来影响的看法
• （10'）软件工程分析（评价同类产品优劣；分析软件工程层面的不足）
• （10'）说明该产品的市场概况
• （10'）说明该产品的未来可能规划（可采用 NABCD 分析）

三、作业格式以及提交规则

1、为了方便其他学校的老师或者助教了解课程实况，请大家在作业开头添加作业的基本信息：（必做）

2、作业提交规则

• 在 deadline 前 交，分数为实际得分；
  • 若帖子发布后在审核（帖子显示404），可以在 deadline 之前先于作业页面提交链接，再等待审核通过
  • 不接受上传失败、网络原因等补交理由
• 缺交：在 deadline 之后未补交视为博客缺交，分数为0分；
• 作业抄袭：当助教发现两篇博客文字/图片/代码过于相似时，判定两篇博客都为抄袭，分数都为-100%（注意是倒扣！）

3、注意事项

班级群如果发布相关通知也是作业要求一部分，请及时查看群通知；

若需要在群填写相关信息，未能在 deadline 之前完成填写的，**扣实际得分的50%**；

如对作业存在疑问，请在 deadline 之前三天在班级群提出；若助教对作业要求有修改，会在群内公告，请务必查看并按新的要求完善作业；

请及时回复老师或助教的点评并作出相应修改。即使提交了作业，也应该关注班级群中助教的公告！

4、疑惑解疑

若有对题意不清或者有不理解的地方，可在QQ群中直接提问