[I.2] 个人作业：软件案例分析

开源软件分析：Anki —— Open source is FREE!

项目	内容
这个作业属于哪个课程	首页 - 2026年春季软件工程 - 北京航空航天大学 - 班级博客 - 博客园
这个作业的要求在哪里	[I.2] 个人作业：软件案例分析 - 作业 - 2026年春季软件工程 - 班级博客 - 博客园
我在这个课程的目标是	系统掌握现代软件工程的核心概念与常用方法（需求分析、团队协作、开发流程、测试与发布等），并能通过阅读、提问与实践，在课程项目中运用这些方法，提升工程化思维与协作能力。
这个作业在哪个具体方面帮助我实现目标	通过深入分析具体软件案例，实践软件工程中的评测、分析、对比与规划方法，提升批判性思辨、用户调研、竞品分析和产品规划能力。

选题：第 4 题 · 开源软件分析

分析对象：Anki（间隔重复记忆卡片软件）

竞品对比：SuperMemo 、 Quizlet等笔记、记忆类产品

---

一、调研与评测

1. 软件评测

1.1 软件使用

Anki 是一款基于间隔重复算法的记忆卡片程序。本次作业中，使用 Anki 桌面版（Windows）进行基本功能体验，包括创建牌组与笔记类型、添加卡片、复习、查看统计、同步与偏好设置等。

• Anki 主界面（牌组列表），可以创建牌组、查看当前所有牌组等，顶端有设置栏。

  

• 添加/编辑卡片界面，可以选择卡片模板，制作卡片并加入某个牌组中。

  

• 复习界面（正面/背面）。通过卡片正面的内容进行回想，显示答案后比对卡片背面的内容。

  

• 显示答案后，根据记忆情况选择重来/困难/良好/简单，系统会根据算法得出卡片下一次出现的时间。

  

• 牌组选项，可以对所有牌组进行设置，也可针对某个牌组。选项具体内容含义参见官方文档。

  

• 统计/图表页面，有丰富的统计图，查看自己的学习情况。

  

• 同步设置。可以不注册登录，本地使用；也可以选择登录账号，多端同步使用。

  

1.2 软件分析

产品使用基本流程：

1. 安装与启动：从 官网 或 GitHub Releases 下载安装包，安装后启动，无需注册即可本地使用。
2. 创建牌组与笔记：通过 “创建牌组” 并添加笔记，建立学习结构；笔记类型可自定义字段与卡片模板。除了自行创建牌组，也可以导入他人创建的牌组进行学习。
3. 添加卡片：在 “添加” 界面选择笔记类型、填写正反面内容，支持文字、图片、音频、视频及 LaTeX 等。
4. 复习：在 “学习” 中按间隔重复算法推送卡片，用户选择 “重来” “困难” “良好” “简单” 等，系统据此调度下次出现时间。
5. 同步（可选）：注册 AnkiWeb 账号后可多端同步牌组与学习进度；移动端有 AnkiDroid（Android 开源免费）与 AnkiMobile（iOS 付费）。

是否解决用户需求：对长期记忆、考试/语言/知识巩固类需求，Anki 能较好满足：算法成熟、可定制性强、数据本地为主、支持大量卡片与媒体，适合严肃学习者。对快速浏览、社交化学习、AI 自动出题等需求则需依赖插件或竞品。

优缺点分析：

维度	优点	缺点
数据量	支持10万+ 卡片、媒体丰富；SQLite 本地存储，可扩展	牌组过大时同步与备份略慢；无内置 “云端协作编辑”
界面	桌面端功能完整；UI简洁	默认界面偏工具向，虽然简洁，然而美观度不及部分竞品；无指引，需自行探索用法
功能	间隔重复算法（含 FSRS）强大；可自行制作牌组或导入；统计反馈详尽；插件多	无内置 AI 生成卡片；制卡步骤较复杂
准确度	调度算法可预期、数据一致性好；支持撤销与检查数据库	依赖用户自评（按钮选择），无自动判题
用户体验	快捷键完善、可定制性强、多平台与同步	牌组选项众多，新手上手需花费一定时间学习；部分高级功能入口较深

1.3 改进意见

• 新手引导：虽然有官方文档供用户阅读，但是文档过长且复杂，难以直观展示使用场景。可在实际使用界面增加可选 “引导模式” 或交互式教程，提供基本功能的使用指引。
• 界面与主题：在保持可定制的前提下，提供更多官方主题或布局预设，兼顾 “效率型” 与 “美观型” 用户。

1.4 用户调研

1.4.1 采访对象背景与选择理由

• 采访对象：我的舍友胡wq同学
• 所属班级：周二上午王德庆/欧阳元新班
• 选择理由：首先是我的舍友，采访很方便；其次，她曾经使用过多种记忆软件背英语单词，属于 Anki 的目标群体之一。
• 需求简述：语言学习（背英语单词）

1.4.2 采访对象实际使用的产品与栏目

• 主要使用的产品：扇贝单词、百词斩，最主要使用的是扇贝单词。
• 常使用的栏目/功能：单词学习与复习。

1.4.3 使用中遇到的问题与亮点

采访其在使用扇贝单词时的感受。

问题：

• 觉得扇贝单词的记忆算法不够准确，复习节奏有时不合理。

亮点：

• 有同桌/打卡等社交或督促功能，能增加坚持背词的动力。
• UI 简洁易懂，界面简单好上手，同时功能比较全，用起来方便。
• 可以主动将单词加入错题本，单独进行复习。

1.4.4 从用户体验角度的改进建议

• 增加图片：背词时希望有内置配图（如词义图、场景图），帮助记忆。可以自行选择是否开启。

向其介绍 Anki 并让其试用后，对 Anki 的初步看法：

• 认为 Anki 的算法强大、统计图完备。学习单词时有多个选项，更加准确合理。
• 同时觉得 Anki 的 UI 较简陋，做卡片较复杂，且共享牌组不够权威（相比专业背词 App 的词库）。
• 背英语单词不会选择 Anki，倾向于专业背单词 App ；但是记忆其他知识点愿意尝试使用Anki。

下图为胡wq同学试用 Anki 时的实拍照片：

1.5 评测结论

在间隔重复类记忆软件产品中，Anki 开源免费、功能完整、算法效率高、生态成熟，上手后功能强大，适合有记忆需求且愿意投入一定学习成本的用户。

综合上述使用与调研，本人给出的评价为：d) 好，不错。

定量评价：
8分良好，6分及格，3分无法正常使用。

类别	评分	简评
核心功能	9/10	间隔重复算法（SM-2/FSRS）科学高效；卡片支持多媒体；多平台同步免费（iOS 除外）。
细节	6/10	支持标签、统计、快捷键；但新手引导缺失，界面文字提示不足。
用户体验	5/10	使用过程无广告，但是上手较难，界面陈旧，偶发bug。
辅助功能	7/10	官方有限，但插件生态丰富，可扩展功能。
差异化功能	9/10	集成 FSRS 算法，算法优势明显；开源免费；用户数据完全自主。
效能	8/10	启动快（约 2-3 秒），内存占用适中，偶发稳定性问题。
适应性	8/10	完全离线可用；跨平台协作良好。
成长性	9/10	FSRS 根据个人数据动态优化参数；记忆习惯自适应。
用户控制权	7/10	统计反馈详尽；但冲突解决界面复杂，快捷键自定义不直观。
社区生态	9/10	GitHub 26.9k 星，插件丰富，用户社区活跃。
总分	77/100

---

2. Bug 分析与提交

2.0 量化标准

星级	综合含义
5 星	致命问题：核心功能崩溃/数据丢失/严重安全漏洞。
4 星	严重问题：主要功能受损/敏感信息泄露/体验极差。
3 星	中等问题：非核心功能故障/中等风险/体验明显不便。
2 星	轻微问题：功能轻微缺陷/风险极低/体验小困扰。
1 星	可忽略：几乎不影响使用。

2.1 Bug #1：标签重命名为非法名称时界面与数据不一致

• 测试环境：Windows 11，Anki 25.09.2；在对标签进行重命名操作时发生。

• 可复现性：必然发生。只要将标签重命名为非法名称（如包含空格），在弹出错误提示后即可观察到该问题。

• 复现步骤：

  • 打开 Anki 后点击 “浏览” ，在左侧边栏选中一个有笔记的标签。

  • 右键该标签，选择 “重命名” 。

  • 在 “新名称” 中输入包含空格的名称（例如 my tag），确认。

  • 弹出错误提示： “replacement name cannot contain a space” （替换名称不能包含空格）。

  

  • 关闭提示后，标签栏中的标签仍显示为刚输入的非法名称（如 my tag），重命名已成功。

  

  • 对该标签重命名，有概率提示 “无法重命名没有笔记的标签” 。关闭提示后，标签名称仍是非法名称。也有概率重命名成功。

  

  • 关闭浏览器窗口后重新打开 “浏览” ，该标签恢复为原来的合法名称，说明底层存储从未被修改。

  

• Bug 具体情况描述： 后端正确拒绝了非法标签名并弹出错误，但前端在报错后没有回滚界面状态，导致标签栏显示的是用户输入的非法名称，而数据库中仍是旧名称。用户会误以为重命名成功，再次操作时又因状态不一致出现 “无法重命名没有笔记的标签” 等误导性错误；只有重新打开该界面后界面才与数据一致。

• Bug 分析：

  • 可能成因：重命名流程中，前端在调用后端 API 之前或之后即更新了本地/界面上的标签名，而后端校验失败时未将失败结果反馈给前端以触发回滚，或前端在收到错误后没有恢复原标签名显示。
  • 严重性：系统功能 2 星（核心功能可用，但标签管理出现误导）；安全性 1 星（无直接安全问题）；用户体验 3 星（造成困惑与二次错误提示）。综合约 2 星。
  • 理由：不影响复习与制卡，但有损对 “标签管理” 的信任与操作预期。

• 发布前未修复的可能原因：

  • 测试不充分或未覆盖该配置/环境（非法名称与错误提示后的界面回滚路径可能未在测试用例中覆盖）

  • 设计质量不高（错误处理与 UI 状态同步未统一考虑）

• 改进建议：

  • 正常行为：当后端返回 “名称非法” 错误时，界面应保持原标签名显示，不更新侧边栏为非法名称；若有输入框仍打开，可保留用户输入以便修改，但树形列表中应显示原名称。
  • 实现思路：在后端返回校验失败时，前端不应用 “新名称” 更新侧边栏对应节点，或显式调用一次 “用当前服务器/本地真实标签名刷新该节点” 的逻辑；或在提交前做前端校验（如禁止空格），减少误操作的同时与后端规则一致。

2.2 Bug #2：同步弹窗显示问题

• 测试环境：Windows 11，Anki 25.09.2；在进行同步后出现此问题。

• 可复现性：必然发生。在进行同步后，出现 “集合同步成功” 的弹窗，该弹窗将会持续悬浮于所有应用程序界面最上方若干秒。

• 复现步骤：

  • 启动 Anki，进行一次同步操作。

  • 同步操作结束后，出现 “集合同步成功” 的弹窗。

  

  • 此时该弹窗无法被关闭、移动，并且会持续置于所有应用程序窗口的上方。

  

  

• Bug 具体情况描述： 同步完成后弹出的 “集合同步成功” 以独立窗口形式显示，且被设置为 “始终在最前” 。当用户切换到其他应用（如 Alt+Tab）或移动 Anki 主窗口时，该弹窗仍保持可见并悬浮于所有其他应用窗口之上，无法关闭或移动，直至其自动消失，违背常规桌面 UI 行为。

• Bug 分析：

  • 可能成因： 同步完成提示使用独立系统窗口实现，且被设置为 “始终在最前” ；该窗口未与 Anki 主窗口建立父子或归属关系，也未在 Anki 失去焦点或主窗口被移动时关闭或隐藏，导致弹窗脱离主应用、悬浮于所有应用之上。
  • 严重性：系统功能 2 星（同步与核心功能正常）；安全性 1 星（无直接安全问题）；用户体验 3 星（干扰多任务、违背常规 UI 预期）。综合约 2 星。
  • 理由：不影响数据与功能使用，但会干扰用户在其他应用中的操作，且与 “应用内通知” 的常见行为不符，有损对界面一致性的信任。

• 发布前未修复原因：

  • 测试不充分或未覆盖该配置/环境（未覆盖 “同步完成提示显示期间切换应用/移动主窗口” 等场景）
  • 设计质量不高（弹窗与主窗口/前端状态未统一设计）

• 改进建议：

  • 正常行为：当同步完成时，提示应仅出现在 Anki 窗口内，或在 Anki 失去焦点时自动关闭/隐藏，且不置于其他应用窗口之上；用户切换应用后不应再看到该弹窗。
  • 实现思路：将 “集合同步成功” 等通知改为在前端页面内以内嵌提示展示，而非独立置顶窗口，使提示与主窗口同显同隐；或保留现有弹窗但在创建时绑定到主窗口、取消 “始终在最前” ，并在主窗口失焦时关闭该弹窗。

2.3 Bug 反馈

经过查询，这两个问题均在Anki的Github Issue中有反馈，但暂未得到修复。

Bug #1

Bug #2

---

二、分析

1. 工作量分析

假设条件：团队约 6 人（计算机相关专业本科毕业生水平），含专业 UI 支持；从零做到 “与当前 Anki 桌面版功能与质量相当” 的同类产品。

Anki 代码库结构大致为：

• 核心层 (rslib)：Rust 实现调度算法、存储、同步、搜索等，约 300+ 个 Rust 源文件，逻辑复杂。
• 桥接与脚本 (pylib, proto)：Python 封装 Rust API，Protobuf 定义前后端与多端通信协议。
• 桌面 GUI (qt/aqt)：PyQt 界面与业务逻辑，约 195+ Python 文件，嵌入 Web 视图。
• Web 前端 (ts/)：Svelte/TypeScript 实现的编辑器、统计、导入等现代界面，约 235+ Svelte 文件。
• 构建与多平台：Ninja/Bazel 类构建、多平台启动器与安装包、国际化（Fluent）等。

考虑到算法设计、多端一致、同步与冲突处理、插件机制、文档与测试，粗略估计：在 6 人团队 + 专业 UI 且技术栈选型合理的前提下，达到 “可用的、功能相近的桌面 + 同步” 产品，约需 2～3 年的全职等效开发；若只做 “核心复习 + 简单牌组 + 本地存储” 的 MVP，约 6～12 个月。

2. 软件质量分析

2.1 与同类软件相比的优劣及排名估计

竞品范围：RemNote、Mochi、SuperMemo、Quizlet、Brainscape 等（部分为笔记+记忆，部分为纯卡片/练习）。

• 优势：

  • 间隔重复算法成熟（集成最新FSRS算法等）
  • 数据以本地为主，隐私与可控性好
  • 插件生态丰富
  • 跨平台同步（桌面 + AnkiDroid + AnkiMobile）
  • 开源免费

• 劣势：

  • 默认 UI 偏 “工具感” ，美观度不如部分竞品
  • 无内置 AI 生成卡片/笔记（需插件或外部工具）
  • 笔记与卡片的概念对新手有一定学习成本

质量排名估计：在 “严肃间隔重复 + 本地/可控数据” 这一细分里，Anki 可估计为第1～2名；若放在 “大众化记忆/学习 App” 大类中（Quizlet、RemNote 等），则综合体验与受众面约在前3～5名，因竞品在易用性与 AI 集成上各有优势。

2.2 软件工程方面可改进的一个重要方面

建议：加强端到端与回归测试的自动化覆盖，尤其是 GUI 与同步场景。

理由：项目已有单元测试（Rust/Python）和ninja check，但桌面端涉及 PyQt + 内嵌 Web、多平台与同步，容易出现 “仅在特定平台或特定操作顺序下” 出现的缺陷。若在 CI 中增加：

• 关键用户路径的自动化 GUI 测试（如添加卡片→复习→同步）
• 同步与冲突的自动化场景测试

可在不显著增加开发成本的前提下，减少回归问题、提高发布信心。

---

三、建议和规划

1. 市场现状

1.1 市场概况

• 直接用户：全球范围内使用 Anki/AnkiDroid/AnkiMobile 的用户数量级在数百万级；官网论坛、知乎等社区活跃。
• 潜在用户：所有需要 “长期记忆、考试复习、语言学习、专业知识巩固” 的学习者（学生、职场、自学者），潜在市场很大，与在线教育、知识付费用户有重叠。

1.2 竞争产品

• RemNote：笔记 + 双向链接 + 自动生成间隔重复卡片，偏 “知识管理 + 记忆” 。
• Mochi：间隔重复 + Markdown + 本地优先，界面简洁。
• SuperMemo：老牌间隔重复，算法理论强，界面与生态偏传统。
• Quizlet：卡片与练习为主，强社交与现成词库，偏轻量记忆与课堂场景。
• Brainscape：间隔重复 + 现成课程/卡片库，偏 “学习内容” 而非 “自制卡片” 工具。

1.3 产品定位与竞争态势

• Anki 定位：开源、通用、可定制、本地优先的间隔重复工具；核心用户为 “愿意自己制卡、重视长期记忆与数据控制” 的学习者。
• 优势：算法与规模能力强、插件与生态成熟、开源与多平台。
• 劣势：上手门槛与默认观感不如部分竞品；无内置 AI 生成。
• 态势：在 “硬核记忆工具” 细分中占优；在 “大众化学习 App” 中与 RemNote、Quizlet 等形成差异化竞争。

2. 市场与产品生态

2.1 核心用户与典型用户

• 核心用户：有明确长期记忆需求的人，如医学生、语言学习者、备考者等。
• 典型画像：学历从中等到高学历均有；年龄以青年为主（约 18～35 岁）；表面需求是 “高效复习、不遗忘” ，潜在需求包括 “可控数据、可定制、跨设备、可持续用多年” 。

2.2 用户群体关系与用户生态

• 用户间通过共享牌组、教程、插件和论坛形成社区；AnkiWeb 共享牌组、知乎等构成 “分享—改进—吸引新用户” 的生态，可进一步通过优质共享内容与模板增强粘性。

2.3 子产品与相关产品关系

• Anki 桌面 / AnkiDroid / AnkiMobile / AnkiWeb：同一套数据与同步协议，形成 “桌面制卡 + 移动复习 + Web 同步” 的产品矩阵；可强化各端体验一致性与协同场景。

3. 产品规划

3.1 新功能设计

• 要做的功能：在现有 Anki 基础上，增加可选的新手引导模式（首次使用或新建用户时）：通过 3～5 步简短任务（创建第一个牌组 → 添加 3 张卡片 → 完成一次复习），配合简短说明与高亮，帮助用户理解 “牌组—笔记类型—卡片” 关系。
• 为何做这个而不是别的：目前 Anki 内并无使用指引，只有官网的文档作为使用教程，且 UI 简陋、功能众多，难以上手。该新手引导功能可直接降低入门门槛，可能会吸引更多新用户；增加此功能不改变核心逻辑，风险小。
• 为什么用户会用：新用户希望 “马上会用” ；完成引导后更容易形成习惯，减少早期流失。
• 创新点：在保持 Anki 简洁、不打扰老用户的前提下，把 “引导” 做成可选、可跳过、可关闭，避免变成强制教程。

NABCD 分析：

• N (Need)：新手需要快速理解牌组/笔记/卡片概念，减少 “不知道从哪开始” 的挫败感。
• A (Approach)：轻量级、可跳过的步骤式引导 + 关键 UI 高亮与提示。
• B (Benefit)：帮助新用户快速上手，提高留存与口碑。
• C (Competitors)：部分竞品有入门教程或模板；Anki 可做成 “更短、更可关闭” 的版本以保持调性。
• D (Delivery)：通过官网、安装包更新与社区公告推送；可在设置中提供 “再次显示引导” 选项。

3.2 团队配置（6 人，16 周）

• 目标：在 16 周内完成 “新手引导模式” 从设计到上线（含需求、实现、测试、文档与发布），并预留约 2 周缓冲与修 Bug。

• 角色：开发 × 3（1 人偏 Rust/核心，1 人偏 Python/Qt，1 人偏 TypeScript/Svelte）、测试 × 1、UI/UX 设计 × 1、项目经理/协调 × 1（可兼开发或测试）。

3.3 16 周详细规划

周次	主要任务
1～2	需求细化、用户故事与原型；技术方案（在现有代码中接入引导的入口与状态）；环境与任务分工
3～4	UI/UX 出高保真与文案；开发搭建引导流程框架与 “步骤状态” 存储
5～7	实现各步骤界面与交互（创建牌组、添加卡片、复习）；与现有界面集成
8～9	测试用例编写与执行；修 Bug；文案与多语言占位
10	回归测试；性能与兼容性检查
11～12	文档（用户 + 开发）； “再次显示引导” 与设置项；内部试用
13～14	Beta 发布与收集反馈；小修小补
15～16	正式发布与发布说明；复盘与下阶段 backlog