1. 开发环境与项目概述
1.1 项目架构
1.1.1 整体架构
项目结构
├─ cloudfunctions (云函数)
│ ├─ duoAchievement (成就系统)
│ ├─ duoGameState (游戏状态)
│ ├─ duoGameStatistics (游戏统计)
│ ├─ duoReward (奖励系统)
│ └─ duoUser (用户管理)
└─ miniprogram (小程序本体)
├─ components (组件)
│ ├─ achievement-notification (成就通知)
│ ├─ game-complete-modal (游戏完成弹窗)
│ ├─ number-pad (数字键盘)
│ └─ ...
├─ pages (页面)
├─ services (服务层)
└─ utils (工具类)
1.1.2 核心模块划分
-
游戏核心模块
pages/game/
- 游戏主体逻辑components/sudoku-board
- 数独棋盘组件services/game/
- 游戏状态管理
-
用户系统
services/user/
- 用户管理pages/profile/
- 用户信息页面
-
成就系统
services/achievement/
- 成就管理pages/achievements/
- 成就页面展示
-
奖励系统
services/reward/
- 奖励管理pages/rewards/
- 奖励页面
1.1.3 数据流转关系
graph TD
A[用户界面] --> B[页面逻辑]
B --> C[服务层]
C --> D[云函数]
C --> E[本地存储]
1.2 技术栈
- 微信小程序原生框架
- 云开发
- 云函数
- 云数据库
- 云存储
- Cursor AI 辅助开发
1.3 开发环境配置
-
微信开发环境
- 微信开发者工具
- 云开发环境配置
- 项目基础配置
-
开发工具
- Cursor AI
- VS Code
- Git 版本控制
2. Cursor 开发实践
2.1 开发最佳实践
2.1.1 需求分析阶段
-
详细需求梳理
向 Cursor 提供: - 详细的功能需求列表 - 具体的用户场景 - 边界条件和异常情况 - 验收标准
-
需求验证
- 确保需求完整性
- 验证需求可行性
- 评估开发工作量
2.1.2 技术选型阶段
-
技术栈确认
明确说明: - 技术栈要求 - 性能要求 - 兼容性要求 - 扩展性要求
-
技术可行性验证
- 验证技术方案
- 评估技术风险
- 确定技术限制
2.1.3 逻辑实现阶段
-
业务流程设计
提供: - 业务流程图 - 模块关系图 - 数据流转图 - 状态转换图
-
逻辑验证
- 验证业务完整性
- 检查逻辑正确性
- 评估实现复杂度
2.1.4 代码实现阶段
-
代码规范
遵循: - 代码结构规范 - 命名规范 - 注释规范 - 错误处理规范
-
实现策略
- 分步骤实现
- 及时验证
- 持续优化
2.1.5 验证阶段
-
测试策略
包含: - 单元测试 - 集成测试 - 性能测试 - 用户测试
-
问题跟踪
- 记录问题
- 分析原因
- 验证解决方案
2.1.6 优化阶段
-
优化方向
关注: - 代码质量 - 运行性能 - 用户体验 - 维护成本
-
持续改进
- 收集反馈
- 分析数据
- 迭代优化
2.2 游戏核心模块实现
2.2.1 模块架构
miniprogram/
├── pages/game/
│ ├── game-core.js // 游戏核心逻辑
│ ├── game-interaction.js // 用户交互处理
│ ├── game-storage.js // 游戏存储管理
│ ├── game-style.js // 游戏样式管理
│ ├── game-ui.js // UI交互管理
│ ├── game.js // 页面主文件
│ ├── game.wxml // 页面模板
│ └── game.wxss // 页面样式
2.2.2 核心业务流程
-
游戏初始化流程
game.js (页面加载) └── GameCore.initializeGame() ├── GameStorage.loadProgress() ├── GameService.createNewGame() ├── GameUI.updatePageTitle() └── GameCore.startAutoSave()
-
用户操作流程
game-interaction.js ├── handleCellTap() ├── handleNumberSelect() └── handleHint()
-
存储流程
game-storage.js ├── autoSave() ├── saveProgress() └── loadProgress()
2.3 实际案例分析 - 游戏统计功能
2.3.1 功能概述
游戏统计功能主要负责:
- 记录游戏总局数
- 追踪完成情况
- 统计各难度级别数据
- 记录连续游戏记录
2.3.2 核心代码实现
async function updateGameStats(userId, gameData) {
// 处理游戏数据
const {
difficulty,
timeSpent,
errors,
hintsUsed,
completed
} = gameData
// 更新数据结构
const updateData = {
[`stats.gamesTotal`]: _.inc(1),
[`stats.difficultyStats.${difficulty}.total`]: _.inc(1),
updatedAt: db.serverDate()
}
// 处理完成状态
if (completed) {
// 更新完成统计
// 更新最佳时间
// 更新完美游戏记录
// 更新连续记录
}
}
2.3.3 数据结构设计
{
"stats": {
"gamesTotal": Number,
"gamesCompleted": Number,
"difficultyStats": {
"easy": {
"total": Number,
"completed": Number,
"perfectGames": Number,
"bestTime": Number
}
// ... medium, hard
},
"streaks": {
"current": {
"daily": Number,
"perfect": Number
},
"best": {
"daily": Number,
"perfect": Number
}
},
"lastPlayDate": Date
}
}
2.3.4 实现中的关键点
-
数据一致性
- 使用事务确保数据更新的原子性
- 合理设计更新策略
-
性能考虑
- 优化数据库查询
- 合理使用索引
- 控制数据量大小
-
可维护性
- 清晰的代码结构
- 完善的错误处理
- 详细的注释说明
2.1.5 开发过程中的经验
-
使用 Cursor 开发流程
- 先分析需求和数据结构
- 生成基础代码框架
- 逐步完善具体实现
- 及时验证和测试
-
遇到的问题和解决方案
- 数据更新逻辑复杂
- 需要考虑并发情况
- 数据一致性保证
3. 遇到的问题与解决方案
3.1 常见问题
-
Chat 上下文混乱
- 解决:重新开始会话,细化问题
- 经验:一次只处理一个问题
-
代码生成质量
- 解决:及时验证,多次迭代
- 经验:提供清晰的上下文
-
API 相关问题
- 解决:参考官方文档
- 经验:复杂 API 直接查询官方文档
3.2 开发技巧
-
代码分析
- 提供完整上下文
- 明确分析目标
- 逐步细化问题
-
代码重构
- 分步进行
- 及时验证
- 控制范围
4. 项目展示
4.1 核心功能
- 数独游戏界面
5. 经验总结
5.1 Cursor 使用心得
5.1.1 会话管理原则
-
单一问题原则
- 一次只提问一个问题
- 问题解决后及时结束会话
- 避免上下文混乱
-
会话重置策略
- 多次尝试未解决时重新开始
- 需要继续提问时重新开始会话
- 确保上下文代码是最新的
5.1.2 代码分析策略
-
文件处理
- 提供多个文件时确认是否都被读取
- 分析单个文件时效率更高
- 定位 bug 时更准确
-
代码生成验证
- 及时校验生成的代码
- 验证运行结果是否符合预期
- 注意数据正确性
5.1.3 API 使用建议
-
API 查询策略
- 如果生成两次还没成功,直接查询官方文档
- 复杂 API 优先参考官方文档
- 避免过度依赖 AI 生成
-
实践经验
- 记录有用的交互信息
- 保存关键代码片段
- 建立问题解决方案库
5.2 开发流程建议
5.2.1 需求管理
-
前期准备
- 开发前梳理好需求
- 确定是否需要本地缓存
- 评估是否需要云同步
-
工作量评估
- 评估自己的工作量
- 评估核查生成代码的工作量
- 合理安排开发计划
5.2.2 代码重构
-
重构策略
- 分步进行重构
- 控制每次重构范围
- 及时验证重构结果
-
重构建议
- 适时结束无效重构
- 开启新的会话继续重构
- 保持代码可控性