对话式AI从零搭建宠物生命周期管理App：Flutter+SQLite全流程实战

1. 为什么我选择用对话式AI从零搭建一个宠物生命周期管理App宠物生命周期管理这个需求乍一听好像挺小众但真正养过宠物的人都知道从接回家第一天到最终告别中间涉及的事情琐碎到令人崩溃。疫苗什么时候打、驱虫多久一次、体重变化趋势、发情期记录、体检报告归档、不同阶段的饮食调整……这些信息如果全靠脑子记或者散落在各种备忘录里基本等于没记。我身边至少有三位养宠的朋友在宠物生病需要向兽医描述历史情况时翻遍手机找不到完整的记录。市面上确实有不少宠物管理类App但用下来总有几个问题要么功能太重什么社交、商城、直播全塞进来打开就卡要么数据存在云端我总担心哪天服务停了记录全丢要么就是界面花哨但核心的提醒功能做得稀烂疫苗到期不提醒驱虫时间算错。所以我决定自己动手做一个核心诉求就三条数据本地优先、提醒准确可靠、界面干净够用。那为什么标题里强调“Claude Code从零搭建”和“全流程AI实现”因为这次我刻意尝试了一种新的开发方式——不写一行手写代码全程通过对话式AI来完成从需求梳理、技术选型、架构设计到具体编码、调试、优化的所有环节。我想验证一件事在2025年这个时间点一个有一定开发经验但不想从零敲代码的人能不能靠AI把一个完整可用的App做出来。结论先放在这里能但前提是你得知道怎么跟AI对话以及哪些地方必须自己把关。这篇文章我会把整个过程的每一个关键决策、每一次踩坑、每一段实际可用的对话策略都拆开讲清楚。不管你是想做一个宠物管理App还是想用同样的方式做别的项目这套方法论都能直接复用。文章会比较长因为我会把“为什么这么做”和“具体怎么做”都讲透建议先收藏再慢慢看。2. 动手之前先把需求拆到AI能理解的粒度2.1 宠物生命周期到底包含哪些阶段和事件很多人做项目失败不是因为技术不行而是因为一开始需求就没想清楚。你直接跟AI说“帮我做一个宠物管理App”它给你的东西大概率是一个四不像。我的做法是先把“宠物生命周期”这个模糊概念拆成AI能理解的结构化描述。宠物的生命周期从时间维度上可以分成几个阶段幼年期0-1岁、成年期1-7岁、老年期7岁以上。不同阶段关注的重点完全不同。幼年期核心是疫苗和驱虫的密集安排成年期重点是体重管理和定期体检老年期则要关注慢性病筛查和饮食调整。从事件维度上我梳理了以下几类必须记录的内容医疗类事件疫苗接种、体内外驱虫、体检、就诊记录、用药记录、过敏史生理类事件体重记录、发情周期、绝育时间、食欲变化日常类事件洗澡、剪指甲、驱虫药投喂、特殊饮食调整纪念类事件生日、领养日、第一次学会某个技能把这些梳理清楚之后我写了一段结构化的需求描述给AI。这里有个关键技巧不要用自然语言长篇大论而是用类似数据库表结构的格式来描述。比如我会这样写实体宠物 字段id, 名字, 品种, 性别, 出生日期, 领养日期, 绝育状态, 当前体重, 头像路径 实体事件记录 字段id, 宠物id, 事件类型(枚举), 事件名称, 计划时间, 实际完成时间, 备注, 附件路径 实体提醒规则 字段id, 宠物id, 事件类型, 触发条件(时间间隔/固定日期), 提前提醒天数, 是否重复这样AI理解起来几乎没有歧义后面生成的数据模型和代码结构也会更合理。我试过用纯自然语言描述AI给出的方案里经常把“事件”和“提醒”混在一起后期改起来很痛苦。2.2 哪些功能必须做哪些坚决不做需求拆解完之后下一步是砍需求。这一步比加需求更重要。我给自己定了一个原则第一版只做“记录提醒”两个核心功能其他全部砍掉。具体来说必须做的功能包括添加/编辑/删除宠物档案按时间线查看某只宠物的所有事件记录创建基于时间间隔的提醒规则比如每30天驱虫一次本地推送通知数据导出为JSON文件防止数据丢失坚决不做的功能包括用户注册登录本地App不需要云端同步第一版不做降低复杂度社交分享完全没必要宠物商城跟核心需求无关多设备同步技术复杂度高收益低这个取舍逻辑很重要。我见过太多个人项目死在“什么都想要”上。你跟AI说“帮我做一个宠物App”它可能会给你生成一个包含登录、支付、社交的完整方案看起来很美好但你根本做不完。主动砍需求是让AI帮你聚焦的关键。2.3 把需求翻译成AI能直接执行的提示词结构需求想清楚之后最后一步是把它翻译成AI能直接执行的提示词。我的经验是一个好的提示词应该包含四个部分角色设定告诉AI它是什么角色比如“你是一个资深移动端开发工程师”上下文项目背景、技术栈、已有代码结构具体任务这次要完成什么输入是什么输出是什么约束条件代码风格、命名规范、不能用的库、性能要求举个例子我让AI生成数据模型时的提示词是这样的你是一个资深Flutter开发工程师正在帮我开发一个宠物生命周期管理App。 技术栈Flutter 3.x Dart 3.x SQLitesqflite包 Provider状态管理。 当前项目结构lib/目录下已有main.dart和models/文件夹。 任务在models/文件夹下创建pet.dart和event.dart两个数据模型文件。 要求 - 使用不可变类immutable class - 包含toMap()和fromMap()方法用于SQLite序列化 - 字段命名使用小驼峰 - 每个字段加注释说明用途 - 不要引入除sqflite之外的任何第三方包这种提示词结构AI几乎不会跑偏。我对比过用这种结构化提示词生成的代码一次通过率大概在80%以上而用“帮我写个宠物模型”这种模糊提示词基本都要返工。3. 技术选型为什么我最终选了Flutter加SQLite这套组合3.1 跨平台方案对比Flutter、React Native和原生开发技术选型这一步我让AI帮我做了一次完整的对比分析。我给它的提示词是“列出Flutter、React Native、Kotlin Multiplatform、原生Android/iOS五种方案在个人开发宠物管理App场景下的优劣对比用表格输出重点考虑开发效率、性能、本地数据库支持、学习成本四个维度。”AI给出的对比表格我整理如下方案开发效率性能本地数据库支持学习成本适合场景Flutter高接近原生sqflite成熟中等个人跨平台项目首选React Native高中等需要额外配置低有前端基础前端开发者快速上手Kotlin Multiplatform中高原生支持好高有Kotlin经验的开发者原生Android低最高Room非常成熟中等只做Android平台原生iOS低最高CoreData成熟高只做iOS平台我最终选Flutter的理由有三条第一我只需要写一套代码就能同时覆盖Android和iOS个人项目维护成本最低第二sqflite这个包对SQLite的封装非常成熟增删改查写起来很顺手第三Flutter的热重载在调试UI时效率极高改一行代码秒级看到效果。React Native其实也是不错的选择但我之前踩过一个坑RN的本地数据库方案在不同版本之间API变动比较大而Flutter的sqflite接口相对稳定。对于个人项目来说稳定性比先进性更重要。3.2 本地数据存储SQLite为什么比JSON文件更靠谱一开始我想过直接用JSON文件存数据简单粗暴。但跟AI讨论之后发现几个致命问题并发写入问题如果同时有多个提醒触发JSON文件写入会冲突查询效率低想查“所有宠物下周需要驱虫的记录”JSON需要全量加载再过滤数据完整性难保证JSON没有事务概念写到一半崩溃就全丢了SQLite完美解决这些问题。它支持事务、支持复杂查询、单文件存储方便备份、而且sqflite包让Flutter操作SQLite变得非常简单。我让AI帮我设计了数据库表结构核心就三张表CREATE TABLE pets ( id INTEGER PRIMARY KEY AUTOINCREMENT, name TEXT NOT NULL, species TEXT NOT NULL, breed TEXT, gender TEXT, birth_date TEXT, adopt_date TEXT, neutered INTEGER DEFAULT 0, current_weight REAL, avatar_path TEXT, created_at TEXT NOT NULL ); CREATE TABLE events ( id INTEGER PRIMARY KEY AUTOINCREMENT, pet_id INTEGER NOT NULL, event_type TEXT NOT NULL, event_name TEXT NOT NULL, planned_time TEXT, actual_time TEXT, notes TEXT, attachment_path TEXT, created_at TEXT NOT NULL, FOREIGN KEY (pet_id) REFERENCES pets(id) ON DELETE CASCADE ); CREATE TABLE reminders ( id INTEGER PRIMARY KEY AUTOINCREMENT, pet_id INTEGER NOT NULL, event_type TEXT NOT NULL, interval_days INTEGER, fixed_date TEXT, advance_days INTEGER DEFAULT 1, repeat INTEGER DEFAULT 1, last_triggered TEXT, FOREIGN KEY (pet_id) REFERENCES pets(id) ON DELETE CASCADE );这里有个细节值得说ON DELETE CASCADE这个外键约束非常重要。当你删除一只宠物时它关联的所有事件和提醒会自动删除不需要手动清理。我一开始没加这个结果测试时删了宠物之后数据库里留了一堆孤儿记录查起来各种报错。3.3 状态管理Provider够用别过度设计状态管理是Flutter开发里最容易过度设计的地方。我见过有人用BLoC写一个只有三个页面的App代码量翻了三倍。对于宠物管理App这种规模Provider完全够用。我让AI帮我设计了三个ProviderPetProvider管理宠物列表的增删改查EventProvider管理事件记录的增删改查ReminderProvider管理提醒规则的增删改查和触发逻辑每个Provider内部持有对应的RepositoryRepository负责跟SQLite交互。这种分层的好处是如果以后想换成云端存储只需要改Repository层Provider和UI层完全不用动。AI一开始给我生成的方案里用了Riverpod功能确实更强但学习曲线也更陡。我跟AI说“换成Provider理由是这个项目只有我一个人开发不需要团队协作级别的状态管理方案”它很快就调整过来了。跟AI沟通时给出明确的约束理由它会更精准地执行。4. 用对话式AI写代码的完整实操流程4.1 项目初始化从flutter create到第一个可运行页面项目初始化这一步我全程让AI指导我操作。提示词是“我是一个Flutter初学者请一步一步指导我创建一个新的Flutter项目项目名叫pet_lifecycle然后创建一个最简单的首页显示‘宠物生命周期管理’标题和一个空状态提示。”AI给出的步骤非常清晰在终端执行flutter create pet_lifecycle进入项目目录cd pet_lifecycle打开pubspec.yaml添加依赖sqflite、path、provider、flutter_local_notifications执行flutter pub get修改lib/main.dart替换为AI生成的首页代码这里我踩了第一个坑flutter_local_notifications这个包在Android上需要额外配置权限和通知渠道AI第一次生成的代码没有包含这部分导致通知功能在Android上完全不工作。我后来把报错信息直接贴给AI它才补充了AndroidManifest.xml的配置和初始化代码。提示跟AI协作时遇到报错不要自己瞎猜直接把完整的错误日志贴给它让它分析原因并给出修复方案。这比你自己查文档快十倍。4.2 数据模型和数据库层让AI生成可测试的代码数据模型和数据库层是整个项目的地基这部分代码必须保证质量。我的做法是让AI先生成代码然后我写单元测试来验证。AI生成的Pet模型大致是这样的class Pet { final int? id; final String name; final String species; final String? breed; final String? gender; final String? birthDate; final String? adoptDate; final bool neutered; final double? currentWeight; final String? avatarPath; final String createdAt; const Pet({ this.id, required this.name, required this.species, this.breed, this.gender, this.birthDate, this.adoptDate, this.neutered false, this.currentWeight, this.avatarPath, required this.createdAt, }); MapString, dynamic toMap() { return { id: id, name: name, species: species, breed: breed, gender: gender, birth_date: birthDate, adopt_date: adoptDate, neutered: neutered ? 1 : 0, current_weight: currentWeight, avatar_path: avatarPath, created_at: createdAt, }; } factory Pet.fromMap(MapString, dynamic map) { return Pet( id: map[id] as int?, name: map[name] as String, species: map[species] as String, breed: map[breed] as String?, gender: map[gender] as String?, birthDate: map[birth_date] as String?, adoptDate: map[adopt_date] as String?, neutered: (map[neutered] as int) 1, currentWeight: map[current_weight] as double?, avatarPath: map[avatar_path] as String?, createdAt: map[created_at] as String, ); } }这段代码质量不错但有一个隐藏问题current_weight在SQLite里存的是REAL类型但Dart的as double?转换在某些情况下会失败因为SQLite可能返回int。我让AI修复这个问题它改成了(map[current_weight] as num?)?.toDouble()。这种细节问题只有实际跑起来才会发现。数据库层的DatabaseHelper类AI生成得也比较完整包含了单例模式、版本管理、onCreate和onUpgrade回调。我额外让AI加了一个close()方法用于在App退出时关闭数据库连接避免资源泄漏。4.3 界面搭建从时间线视图到提醒设置页界面部分是我跟AI协作最多的环节。宠物管理App的核心界面是一个时间线视图按时间倒序展示某只宠物的所有事件记录。我让AI用ListView.builder实现每个列表项显示事件图标、事件名称、计划时间和实际完成时间。AI第一次生成的代码用了ListTile功能没问题但视觉效果太单调。我给了它更具体的描述“每个列表项左侧显示一个圆形图标图标颜色根据事件类型区分医疗类用红色、生理类用蓝色、日常类用绿色右侧显示事件名称和时间已完成的事件加删除线效果。”AI很快就生成了符合要求的代码。提醒设置页稍微复杂一些需要处理几种不同的提醒类型间隔重复提醒比如每30天驱虫一次需要计算下次触发时间固定日期提醒比如每年生日提醒需要处理闰年和月份天数差异一次性提醒比如某次体检预约完成后不再重复这里我让AI帮我写了一个ReminderCalculator工具类核心逻辑是DateTime? calculateNextTrigger(Reminder reminder, DateTime lastTriggered) { if (reminder.repeat 0) { return null; // 一次性提醒触发后不再重复 } if (reminder.intervalDays ! null) { return lastTriggered.add(Duration(days: reminder.intervalDays!)); } if (reminder.fixedDate ! null) { final fixed DateTime.parse(reminder.fixedDate!); final now DateTime.now(); var next DateTime(now.year, fixed.month, fixed.day); if (next.isBefore(now)) { next DateTime(now.year 1, fixed.month, fixed.day); } return next; } return null; }这段逻辑看起来简单但实际测试时发现一个问题如果固定日期是2月29日在非闰年时DateTime(now.year, 2, 29)会自动变成3月1日。我让AI处理这个边界情况它加了一个判断如果月份是2且日期是29在非闰年时改为2月28日。4.4 本地通知集成Android和iOS的差异化处理本地通知是宠物管理App的核心功能也是最容易出问题的部分。flutter_local_notifications这个包在Android和iOS上的配置差异很大。Android端需要在AndroidManifest.xml中添加POST_NOTIFICATIONS权限Android 13创建通知渠道NotificationChannel处理精确闹钟权限Android 12需要SCHEDULE_EXACT_ALARMiOS端需要在Info.plist中添加通知权限描述请求用户授权处理前台通知展示我让AI分别生成了Android和iOS的配置代码然后自己手动在真机上测试。这里踩了一个大坑Android 13的POST_NOTIFICATIONS权限是运行时权限必须在代码中动态请求光在Manifest里声明是不够的。AI第一次生成的代码漏了这一步导致通知在Android 13设备上完全不显示。修复方案是在App启动时调用权限请求final androidImpl flutterLocalNotificationsPlugin .resolvePlatformSpecificImplementation AndroidFlutterLocalNotificationsPlugin(); await androidImpl?.requestNotificationsPermission();注意通知权限请求的时机很重要。不要在App一启动就弹窗用户还没理解App是干什么的就拒绝授权后面很难再让用户手动开启。我的做法是在用户创建第一个提醒规则时再请求权限并附上一句说明“开启通知权限确保不会错过宠物的疫苗和驱虫时间。”5. 调试和优化阶段AI帮我解决了哪些棘手问题5.1 数据库迁移当表结构需要变更时怎么办项目做到一半我发现需要给events表加一个reminder_id字段用来关联事件和提醒规则。这就涉及到数据库迁移。SQLite的迁移逻辑是在onUpgrade回调里处理的。我让AI帮我写迁移代码它给出的方案是override Futurevoid onUpgrade(Database db, int oldVersion, int newVersion) async { if (oldVersion 2) { await db.execute(ALTER TABLE events ADD COLUMN reminder_id INTEGER); } }看起来很简单但这里有个隐患如果用户是从版本1直接升级到版本3oldVersion 2这个条件会执行但版本2到版本3的迁移逻辑也需要执行。正确的写法应该是用连续的if判断而不是else if。AI第一次写的是else if我指出问题后它改成了独立的if。另外ALTER TABLE ADD COLUMN在SQLite里不支持添加外键约束。如果需要加外键只能重建表。这个限制AI一开始没提到是我查文档后发现的。对于个人项目来说不加外键约束问题不大但需要在代码层面保证数据一致性。5.2 性能优化列表卡顿和数据库查询慢的排查过程App做到后期宠物事件记录积累到几百条之后时间线列表开始出现明显卡顿。我让AI帮我分析可能的原因它给出了几个排查方向列表项构建开销大每个列表项都重新解析日期、重新加载图标数据库查询没有索引events表的pet_id字段没有索引查询慢图片加载没有缓存宠物头像每次都从磁盘重新读取我逐一验证列表项问题把日期格式化和图标选择逻辑移到数据层列表项只负责渲染索引问题给events.pet_id和events.planned_time加了索引查询速度从200ms降到20ms图片问题用了cached_network_image的思路但因为是本地图片改用了一个简单的内存缓存Map优化之后列表滚动流畅度明显提升。这里有个经验Flutter的ListView.builder本身性能很好卡顿通常是因为itemBuilder里做了太多事情。把计算逻辑前置到数据准备阶段是解决列表卡顿最有效的方法。5.3 数据导出和备份防止用户数据丢失的最后一道防线本地存储最大的风险是数据丢失。用户换手机、卸载重装、手机损坏数据就没了。所以我做了一个数据导出功能把所有数据导出为JSON文件用户可以通过系统分享保存到网盘或发送给自己。导出逻辑不复杂核心是把三张表的数据查出来组装成JSONFutureString exportData() async { final db await database; final pets await db.query(pets); final events await db.query(events); final reminders await db.query(reminders); final data { version: 1, exported_at: DateTime.now().toIso8601String(), pets: pets, events: events, reminders: reminders, }; return jsonEncode(data); }导入逻辑稍微复杂一些需要处理ID冲突和数据校验。我的做法是导入时重新生成所有ID用旧ID到新ID的映射表来更新关联关系。这样即使用户多次导入同一份数据也不会产生冲突。AI在生成导入逻辑时一开始没有处理事务。如果导入到一半失败数据库会处于不一致状态。我让AI加上事务包裹确保要么全部成功要么全部回滚。6. 跟AI协作开发这件事我踩过的坑和总结的经验6.1 AI生成代码的常见问题模式用了几个月AI辅助开发我总结出AI生成代码的几个典型问题第一边界条件处理不完整。比如日期计算不考虑闰年、数组操作不考虑空数组、字符串处理不考虑空字符串。这类问题在正常流程下不会暴露但用户一用就会出问题。第二错误处理过于简单。AI倾向于用try-catch包住所有代码然后打印日志但实际项目中需要区分不同类型的错误给用户不同的提示。比如数据库打开失败和查询失败处理方式完全不同。第三依赖版本不匹配。AI训练数据里的包版本可能比较旧生成的代码用了新版本已经废弃的API。我的做法是在提示词里明确指定版本号比如“使用sqflite 2.3.0版本的API”。第四代码风格不统一。同一个项目里AI可能一会儿用final一会儿用var一会儿用命名参数一会儿用位置参数。我后来在提示词里加了一句“遵循Effective Dart规范”情况好了很多。6.2 哪些环节必须人工把关虽然AI能写大部分代码但有几个环节我坚持人工把关数据库表结构设计这是地基一旦设计不合理后期改起来成本极高数据迁移逻辑涉及用户数据安全必须逐行审查权限和隐私相关代码通知权限、文件读写权限必须确保符合平台规范核心业务逻辑比如提醒触发时间的计算必须写单元测试验证我的做法是AI生成代码我审查关键逻辑然后写测试用例验证。测试通过之后才合并到主分支。这套流程虽然比纯手写快很多但绝不是“无脑复制粘贴”。6.3 提示词工程的几个实用技巧最后分享几个我在这个项目里总结的提示词技巧技巧一给AI一个“角色”和“约束”。不要只说“帮我写代码”要说“你是一个有五年Flutter经验的开发工程师请遵循以下约束不使用任何状态管理库、所有异步操作必须有错误处理、代码必须通过flutter analyze检查”。技巧二分步骤执行不要一次性要太多。我从来不会说“帮我做一个完整的宠物管理App”而是拆成“先设计数据库表结构”“再生成数据模型”“然后写数据库操作层”“最后做界面”。每一步都验证通过再进行下一步。技巧三把报错信息完整贴给AI。不要只贴“报错了”三个字要贴完整的错误堆栈、相关代码片段、你期望的行为和实际行为。信息越完整AI修复越精准。技巧四让AI解释它的方案。每次AI给出代码后我会追问一句“解释一下这段代码的关键逻辑和可能的边界问题”。这不仅能帮我理解代码还能让AI自己发现潜在问题。技巧五保留对话历史。AI在长对话中能记住之前的上下文所以尽量在同一个对话里完成一个模块的开发。如果开新对话记得把关键上下文技术栈、项目结构、命名规范重新贴一遍。这个宠物生命周期管理App目前已经在我自己的手机上稳定运行了几个月记录了我家两只猫的所有疫苗、驱虫和体检数据。整个开发过程大概用了三周左右的业余时间其中跟AI对话的时间占了大头真正手写代码的时间不到20%。如果你也想用类似的方式做一个自己的项目我的建议是先从最小的核心功能开始跑通之后再逐步扩展。不要一上来就追求完美AI能帮你快速迭代但方向得你自己把控。