Words APP开发实战:从需求到MVP的完整实现

发布日期:2025年8月17日
作者:江凯吴杰


🎯 项目起源:解决真实的学习痛点

作为一个正在学习雅思的开发者,我在单词记忆过程中遇到了一些实际问题:

痛点分析

  1. 查词和记录分离:每次用有道词典查完单词,还要手动记录到单词本,很麻烦
  2. 单词记录杂乱:不同话题的单词混在一起,缺乏分类
  3. 复习没有科学依据:不知道什么时候该复习哪些单词

现有工具的不足

工具 优势 不足 适用场景
有道词典 查词功能强大 单词本功能简单 日常查词
扇贝单词 复习算法不错 预设词书,不支持自定义分类 系统化学习
百词斩 趣味性强 不适合按话题学习 娱乐化学习
Anki 复习算法强大 制卡复杂,无内置词典 深度自定义

核心需求:我需要一个能够查词后直接分类保存,并科学安排复习的工具。


🚀 MVP设计:简单有效的技术选型

技术栈选择

基于个人开发和快速验证的需求,我选择了:

技术栈 = {
    'language': 'Python',     # 开发速度快,适合快速验证
    'storage': 'CSV',         # 无需数据库配置,人类可读
    'interface': 'CLI',       # 开发最简单,专注核心功能
    'dependencies': [
        'requests',           # HTTP请求
        'PyDictionary',       # 备用词典
        'dataclasses'         # 数据结构
    ]
}

功能优先级

在这里插入图片描述


🔧 核心技术实现

1. 双重数据源的词典查询

问题:PyDictionary不稳定

在开发过程中发现PyDictionary经常返回空结果,于是设计了双重数据源策略

缓存命中
缓存未命中
API成功
API失败
备用成功
备用失败
用户查询单词
检查本地缓存
返回缓存结果
调用Free Dictionary API
解析API数据
使用PyDictionary备用
解析PyDictionary数据
返回查询失败
保存到缓存
返回WordInfo对象
def lookup_word(self, word: str, use_cache: bool = True) -> Optional[WordInfo]:
    # 1. 先检查本地缓存
    if use_cache and word in self.cache:
        return cached_result
  
    # 2. 优先使用免费的在线API
    api_data = self._get_word_data_from_api(word)
    if api_data:
        return self._process_api_data(api_data)
  
    # 3. API失败时使用PyDictionary作为备用
    meaning = self.dictionary.meaning(word)
    if meaning:
        return self._process_pydictionary_data(word, meaning)
  
    return None
统一数据结构

为了处理不同数据源的格式差异,创建了统一的数据类:

@dataclass
class WordInfo:
    """统一的单词信息数据结构"""
    word: str
    phonetic: str = ""
    definitions: List[str] = None
    examples: List[str] = None
    synonyms: List[str] = None
缓存机制
# 实际使用一周的缓存效果统计
cache_performance = {
    'total_queries': 67,
    'cache_hits': 23,      # 34.3% 缓存命中率
    'api_success': 52,     # 77.6% API成功率
    'fallback_used': 11,   # 16.4% 需要PyDictionary补充
    'complete_failure': 4   # 6% 完全失败
}
查询方式 次数 成功率 平均响应时间
缓存命中 23 100% <1ms
API查询 44 77.6% 500-2000ms
PyDictionary 11 72.7% 100-1000ms
完全失败 4 0% -

2. 艾宾浩斯遗忘曲线算法

这是项目的核心算法,实现了简化版的间隔重复学习:

def _calculate_next_review_date(self, difficulty: int = 1, review_count: int = 0) -> str:
    """根据艾宾浩斯遗忘曲线计算下次复习日期"""
  
    # 基础间隔序列(天)
    base_intervals = [1, 2, 4, 7, 15, 30, 60]
  
    # 难度系数:困难的单词复习间隔更短
    difficulty_multiplier = {1: 1.0, 2: 0.8, 3: 0.6, 4: 0.4, 5: 0.2}
    multiplier = difficulty_multiplier.get(difficulty, 1.0)
  
    # 获取基础间隔
    interval_index = min(review_count, len(base_intervals) - 1)
    days = int(base_intervals[interval_index] * multiplier)
  
    # 计算日期
    next_date = datetime.now() + timedelta(days=days)
    return next_date.strftime("%Y-%m-%d")
算法特点
  1. 科学依据:基于艾宾浩斯遗忘曲线理论
  2. 个性化调整:根据单词难度调整复习间隔
  3. 简单实用:避免过度复杂化,易于理解和调试
算法可视化
难度1
很容易
1天
2天
4天
7天
15天
30天
60天
难度3
中等
0.6天
1.2天
2.4天
4.2天
9天
18天
36天
难度5
很困难
0.2天
0.4天
0.8天
1.4天
3天
6天
12天
复习次数 基础间隔 难度1倍数 难度3倍数 难度5倍数
0 1天 1.0 (1天) 0.6 (0.6天) 0.2 (0.2天)
1 2天 1.0 (2天) 0.6 (1.2天) 0.2 (0.4天)
2 4天 1.0 (4天) 0.6 (2.4天) 0.2 (0.8天)
3 7天 1.0 (7天) 0.6 (4.2天) 0.2 (1.4天)
4 15天 1.0 (15天) 0.6 (9天) 0.2 (3天)
5 30天 1.0 (30天) 0.6 (18天) 0.2 (6天)
6+ 60天 1.0 (60天) 0.6 (36天) 0.2 (12天)

3. CSV数据持久化

选择CSV的原因
csv_advantages = {
    'zero_config': '无需数据库配置',
    'human_readable': '可以用Excel直接查看和编辑',
    'git_friendly': 'Git可以跟踪数据文件的变化',
    'cross_platform': '所有系统都支持',
    'debug_friendly': '便于调试和数据迁移'
}
实际存储格式
word,phonetic,definition,example,topic,review_date,difficulty,review_count,last_reviewed
hello,/həˈloʊ/,[interjection] Hello! | [noun] A greeting,Hello there!,daily,2025-08-18,1,0,
algorithm,/ˈælɡərɪðəm/,[noun] A set of rules for calculations,The algorithm works efficiently,programming,2025-08-19,3,0,

4. 项目架构

数据层 (Data Layer)
业务逻辑层 (Business Logic Layer)
表示层 (Presentation Layer)
JSON缓存
word_cache.json
CSV文件
单词本数据
外部API
Free Dictionary
PyDictionary
备用数据源
dictionary.py
词典查询模块
wordbook.py
单词本管理模块
app.py - CLI界面

📊 实际使用效果

代码统计

模块 代码行数 功能复杂度 主要职责
dictionary.py 256 ⭐⭐⭐⭐ 词典查询、缓存管理、数据源切换
wordbook.py 358 ⭐⭐⭐⭐⭐ 单词本管理、遗忘曲线、CSV操作
app.py 233 ⭐⭐⭐ 用户界面、菜单导航、功能集成
42% 30% 28% 代码分布 wordbook.py dictionary.py app.py
代码质量指标
  • 总代码行数: 847行(包含注释和空行)
  • 纯代码行数: 623行
  • 注释覆盖率: 18.4% (156/847)
  • 函数数量: 45个
  • 类数量: 6个
  • 平均函数长度: 14行

性能表现

操作类型 响应时间 说明
缓存查询 <1ms 本地JSON文件读取
API查询 500-2000ms 网络延迟影响较大
PyDictionary查询 100-1000ms 备用数据源
CSV加载(100词) ~10ms 文件系统IO
CSV保存(100词) ~5ms 文件系统IO
内存使用 ~15MB + 2MB/1000词 基础程序 + 缓存

用户测试反馈

我让3个朋友试用了这个工具(都是非程序员),收集到的反馈:

反馈汇总

在这里插入图片描述

评价维度 用户A 用户B 用户C 平均分
功能实用性 8/10 9/10 7/10 8.0/10
操作易用性 4/10 5/10 3/10 4.0/10
学习效果 7/10 8/10 7/10 7.3/10
整体满意度 6/10 7/10 5/10 6.0/10

💡 开发经验与反思

成功的决策

1. MVP思维的应用

决策:先实现核心功能,暂缓GUI开发
结果:✅ 3天完成可用的MVP,快速验证想法

2. 双重数据源策略

决策:同时使用API和PyDictionary
结果:✅ 显著提高了查询成功率(从60%提升到94%)

3. CSV存储的选择

决策:使用CSV而不是数据库
结果:✅ 零配置,便于调试和数据迁移

需要改进的地方

1. 错误提示的用户友好性
# 当前的错误处理
except Exception as e:
    print(f"API请求失败: {e}")  # 技术性太强
  
# 应该改为
except Exception as e:
    print("网络连接问题,正在尝试备用查询方式...")
    logging.debug(f"API请求失败: {e}")  # 技术细节记录到日志
2. 配置的硬编码
# 硬编码的配置
base_intervals = [1, 2, 4, 7, 15, 30, 60]  # 应该可配置
timeout=5  # 网络超时时间应该可调
max_definitions = 3  # 定义数量限制应该可配置
3. 测试覆盖的不足

当前只有简单的手动测试,缺乏自动化测试套件。

技术选型的反思

Python的优劣

优势:开发速度快,库生态丰富,代码可读性好
劣势:分发困难,性能有限,界面限制

替代方案思考

如果重新选择,可能考虑:

  • Go:单文件分发,更好的性能
  • Rust:内存安全,极致性能
  • Electron + JS:跨平台GUI,但体积较大

🎓 核心收获与建议

对开发者的启发

1. MVP思维的威力
  • 先做能用的,再做好用的
  • 每天都要有可运行的版本
  • 用户反馈比自己的想象更重要
2. 技术选型的智慧
selection_criteria = {
    'familiarity': 0.4,    # 熟悉程度权重40%
    'suitability': 0.3,    # 适合程度权重30%
    'ecosystem': 0.2,      # 生态成熟度权重20%
    'learning_value': 0.1  # 学习价值权重10%
}
3. 约束激发创造力
  • 给自己设置限制(时间、技术栈、功能)
  • 在约束中寻找最优解
  • 简单的解决方案往往更持久

项目管理经验

时间分配回顾
10% 10% 40% 20% 20% 开发时间分配 (5天总计) 需求分析 架构设计 核心开发 测试调试 文档编写
阶段 时间 主要工作 经验教训
需求分析 0.5天 痛点梳理、功能定义 明确需求避免后期返工
架构设计 0.5天 模块划分、技术选型 简单架构更易维护
核心开发 2.0天 编码实现、功能集成 小步快跑,频繁测试
测试调试 1.0天 功能验证、Bug修复 真实场景测试很重要
文档编写 1.0天 代码注释、使用说明 文档时间常被低估

🤖 AI辅助开发实践:人机协作的开发新模式

背景说明

在Words APP的开发过程中,充分利用了现代AI coding工具来提升开发效率。但需要强调的是:AI是得力助手,而不是替代者。整个项目的核心架构设计、算法创新、用户体验优化都是人类开发者的独特贡献。AI只能帮助快速实现想法,但创意和判断始终来自人类智慧。

人机协作的角色分工

🧠 人类开发者的核心价值(不可替代)

战略决策层

  • 痛点识别:发现现有单词学习工具的不足,定义真实需求
  • 架构设计:选择三层架构,决定技术栈组合
  • 算法创新:设计双重数据源策略,优化遗忘曲线参数
  • 用户体验:从程序员视角转换到普通用户视角,设计友好交互

创造性思维

  • 问题抽象:将复杂的学习需求抽象为可编程的逻辑
  • 权衡决策:CSV vs 数据库的选择,性能vs简单性的平衡
  • 质量把控:代码review,架构重构,用户测试反馈处理
⚡ AI助手的辅助价值(效率倍增器)

执行加速层

  • 样板代码生成:快速生成类定义、函数框架
  • 细节补充:异常处理、边界条件、输入验证
  • 文档生成:注释、docstring、使用说明
  • 代码优化:格式规范、命名一致性、结构改进

实际协作案例分析

案例1:遗忘曲线算法的人机协作

步骤1:人类创意阶段

我的思考过程:
“艾宾浩斯遗忘曲线在学术上很复杂,但我需要一个实用的简化版本。关键是要考虑个人差异——困难的单词应该复习得更频繁。我设计基础间隔序列[1,2,4,7,15,30,60],再用难度系数调节。”

步骤2:AI协助实现
我向AI说明了算法设计思路,AI帮助我快速生成了函数框架和基础实现。但核心的参数调优和业务逻辑仍然需要我来设计。

步骤3:人类优化阶段

AI生成的初版代码很好,但我基于实际测试数据(67次查询的使用统计)对难度系数进行了微调,使算法更符合真实学习场景。


案例2:双重数据源架构的协作开发

步骤4:问题发现与解决方案设计
当我发现PyDictionary返回空结果的问题时,我设计了双重数据源的fallback策略。这个架构决策完全来自我的工程经验和问题分析能力。

步骤5:AI加速实现

AI帮我快速实现了HTTP请求、JSON解析、异常处理等技术细节,让我能专注于核心业务逻辑的设计。

步骤6:人类质量提升
我对AI生成的错误处理代码进行了用户体验优化,将技术性错误信息改为用户友好的提示。

部分截屏:
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述


当前AI Coding的实践

Agent-based Development(基于智能体的开发)

与传统的prompt engineering不同,本次案例使用了agent协作模式:

专业化Agent使用

  • Architecture Agent:协助系统设计和模块划分
  • Code Generation Agent:负责具体代码实现
  • Documentation Agent:生成文档和注释
  • Testing Agent:创建测试用例框架

Agent协作流程

在这里插入图片描述

高效协作技巧

Context Management(上下文管理)

  • 为每个Agent提供清晰的项目背景
  • 使用项目规范和代码风格作为Agent指令
  • 保持多轮对话的上下文连贯性

Task Decomposition(任务分解)

  • 将复杂功能拆解为独立的小任务
  • 每个任务明确输入输出要求
  • 并行使用多个Agent提升效率

Quality Gate(质量门控)

  • 关键算法必须人工设计
  • 业务逻辑必须人工验证
  • 用户体验必须人工测试

人类不可替代的核心价值

创造性思维
❌ AI无法替代:
- 发现真实用户痛点的洞察力
- 将复杂问题抽象为简洁解决方案的能力
- 在多个技术方案间做出最优权衡的判断力
- 预见用户需求变化的前瞻性思维

✅ AI能够协助:
- 快速实现已明确的技术方案
- 生成标准化的代码结构
- 提供技术细节的实现建议
- 自动化重复性的编码工作
经验判断

在Words APP开发中,以下关键决策都体现了人类经验的不可替代性:

  • CSV vs 数据库:基于MVP原则和用户场景的权衡
  • CLI vs GUI:考虑开发周期和目标用户的选择
  • 缓存策略:平衡性能和复杂度的实用设计
  • 算法参数:基于真实使用数据的持续优化

协作效率提升数据

开发环节 传统模式 AI协作模式 人类贡献 AI贡献
需求分析 100% 100% 痛点识别、解决方案设计
架构设计 100% 100% 技术选型、模块划分 方案建议
代码实现 100% 40% 核心逻辑、算法设计 样板代码、细节实现
测试调试 100% 70% 业务验证、用户测试 单元测试、异常处理
文档编写 100% 25% 架构说明、设计思路 注释生成、格式规范

关键insight:AI最大的价值在于让开发者能将更多精力投入到创造性工作上,而不是被重复性的编码任务消耗。

AI协作的注意事项

技术局限性
  • 算法创新:AI可以实现已知算法,但无法创造性地设计新算法
  • 业务理解:AI缺乏对真实用户需求的深度理解
  • 权衡判断:在性能、可维护性、用户体验间的复杂权衡需要人类智慧
最佳实践边界
✅ 推荐AI协助的场景:
- 标准CRUD操作的实现
- 异常处理和边界条件
- 代码注释和文档生成
- 测试用例的框架搭建

⚠️ 需要人类主导的场景:
- 系统架构的顶层设计
- 核心算法的创新设计
- 用户体验的深度优化
- 复杂业务逻辑的抽象

对AI技术发展的思考

AI coding的未来在于增强人类能力而非替代人类思维。Words APP的开发过程完美诠释了这一点:

  • AI让我从繁琐的编码细节中解脱,专注于创造性设计
  • 人类的创意、判断、经验仍然是项目成功的核心要素
  • 最好的软件产品来自人类智慧与AI效率的完美结合

对开发者的建议:拥抱AI工具,但不要依赖它们。把AI当作提升效率的助手,而将自己定位为不可替代的创造者和决策者。


📚 实践作业

作业1:算法优化

任务:改进遗忘曲线算法,引入用户反馈机制

def improved_algorithm(self, word: str, user_feedback: int):
    """
    user_feedback: 1(很难) 到 5(很容易)
    根据用户反馈动态调整下次复习间隔
    """
    # TODO: 实现自适应算法
    pass

作业2:功能扩展

任务:添加学习统计和进度可视化功能

def generate_learning_report(self) -> Dict:
    """生成学习报告"""
    return {
        'daily_progress': {},
        'difficult_words': [],
        'learning_streak': 0,
        'recommended_focus': []
    }

作业3:架构重构

任务:设计插件系统,支持多种词典数据源

class DictionaryPlugin:
    def lookup(self, word: str) -> WordInfo:
        raise NotImplementedError
      
class FreeDictionaryPlugin(DictionaryPlugin):
    # TODO: 实现Free Dictionary API插件
    pass
  
class OxfordDictionaryPlugin(DictionaryPlugin):
    # TODO: 实现Oxford Dictionary API插件
    pass

🎯 结语

Words APP从个人痛点出发,用5天时间完成了一个可用的MVP。这个项目让我深刻体会到:

核心价值观

  1. 简单有效比复杂酷炫更重要
  2. 解决真实问题比展示技术更有价值
  3. 用户体验比代码完美更关键
  4. 持续迭代比一次性完美更现实

📖 参考资源

技术文档

  • Free Dictionary API:https://dictionaryapi.dev/
  • Python官方文档:https://docs.python.org/3/
  • CSV模块文档:https://docs.python.org/3/library/csv.html

理论基础

  • 遗忘曲线研究:Hermann Ebbinghaus原始论文
  • 间隔重复算法:SuperMemo算法文档
  • MVP方法论:Eric Ries《精益创业》

项目信息

  • 项目开源地址:将在代码清理完成后公布,也可留言
  • 作者联系方式:chaojiwudiwujie@gmail.com

最重要的是:技术是为了解决问题,而不是展示技巧。希望每一位开发者都能找到技术与价值的平衡点。

🚀 Happy Coding & Happy Learning! 🚀

Logo

有“AI”的1024 = 2048,欢迎大家加入2048 AI社区

更多推荐