AI辅助开发Flutter记账App：从零到上线的实战经验

前阵子有个做产品的朋友问我说现在 AI 编程这么热是不是真能从一个想法直接生成一个能用的 App。我当时正好在用 AI 辅助开发一个 Flutter 的个人记账应用从项目初始化到核心功能落地再到上线前的一轮轮优化一路踩了不少坑也积累了一些方法论。这篇就围绕“AI 开发个人记账 App基于 Flutter”这件事把我实际的操作过程、关键决策和排查思路完整写出来。如果你正打算用 AI 提速开发又担心代码质量不可控、报错不会查这篇文章应该能给你一个比较踏实的参考。我先把结论放在前面AI 确实能帮你写出大部分业务代码但它不是“输入一句话就交付 App”的魔法。真正决定项目成败的是你怎么把模糊的想法描述成 AI 能理解的指令怎么在它生成的代码里做架构取舍以及遇到编译报错和运行异常时用什么样的排查链路去定位问题。下面我把整个过程拆开聊。1. 为什么我会用 AI 从零写一个 Flutter 记账 App1.1 记账需求驱动的技术选型先说说我为什么要做个人记账 App。市面上的记账软件不少但每个人的记账习惯差异很大有人只记支出有人要管多账户转账有人需要周期性的预算提醒。我之前用过几款主流产品总觉得分类逻辑、统计口径和我的使用习惯对不上数据还不能方便地导出。干脆自己写一个既能完全掌控功能和数据也能顺带验证一下 AI 辅助开发在真实项目里到底靠谱不靠谱。技术选型上我几乎没有犹豫就选了 Flutter。Flutter 的跨平台能力意味着我只需要维护一套 Dart 代码就能同时输出 Android 和 iOS 的应用桌面端的支持也让我后期可以用同一套代码跑在 Windows 上做数据复盘。对我这种“以个人项目和产品原型验证为主”的场景这是性价比最高的方案。再加上 Flutter 的组件系统非常成熟常用的 Material 组件开箱即用AI 模型对 Flutter 和 Dart 的训练数据也足够充分生成出来的代码可读性和准确率明显高于一些小众框架。还有一点很现实个人项目基本都是零预算Flutter 的免费开源生态和 pub.dev 上的丰富插件能把开发成本压到最低。比如我需要把记账数据导出为 CSV 或 Excel有现成的插件可以处理需要画饼图看支出占比fl_chart 这种图表库是免费的。这些基础能力如果从零开发少说要折腾几周。1.2 第一版需求清单怎么给 AI 描述开始动手之前我先花了半小时把需求整理成了一份清单。这份清单不是简单的一句话“帮我写个记账 App”而是按照功能模块拆开的、能直接作为 AI 输入的需求描述。我实际用的原始描述大概长这样支持收入/支出双类型记录记录字段包括金额、分类、备注、日期、账户。统计页面展示月度收支汇总、分类占比饼图、近 6 个月收支趋势折线图。设置页支持管理自定义分类增删改支持切换深色模式。数据存储采用本地 SQLite不接入后端服务不需要登录。页面结构底部 Tab 导航首页账单流水、统计、设置首页右上角悬浮按钮新增记账。之所以要把需求写这么细是因为 AI 的代码生成能力高度依赖输入的清晰度。你给它“做一个记账软件”这种宽泛指令它只能生成一个“看起来像记账软件”的空壳但如果你告诉它“账单列表每个 item 需要显示分类图标、金额、日期点击 item 进详情页详情页支持编辑和删除”它生成的就是基本可以直接跑的业务代码。这个差距在后面的开发过程中会被持续放大。我还做了一件事把技术栈提前指定清楚。我在需求描述里明确写了“使用 Flutter 3.x 版本 Provider 做状态管理 sqflite 做本地存储 fl_chart 做统计图表”。这样 AI 在生成代码时不会擅自引入其他状态管理库也不会把存储方案改成我不熟悉的东西。对于 Flutter 技术栈这是很关键的一步。因为 pub.dev 上能实现同一功能的包可能有好几个AI 如果每次生成代码都随机挑一个后期的依赖管理和问题排查会变得非常痛苦。2. 从零搭骨架AI 帮我完成项目初始化与页面路由2.1 环境准备与项目脚手架的取舍项目开始前环境准备是绕不开的第一步。我本机之前装过 Flutter 3.16 版本但这次项目想用更新的版本于是用 FVMFlutter Version Management装了一个新的稳定版。强烈建议做 Flutter 项目的朋友统一用 FVM 管理多版本 SDK尤其是当你有多个历史项目在维护时切版本是一个很频繁的操作而 FVM 可以针对每个项目锁定 Flutter 版本避免“这个项目能跑、那个项目编译不过”的混乱情况。环境变量、Android SDK、JDK 这些基础内容网上教程一堆我不展开。这里只提一个我遇到的典型坑在 Windows 上用 VS Code 新建 Flutter 项目时Android 项目构建偶尔会报 “unable to find suitable visual studio toolc” 之类的错误。这个错误通常不是你 Flutter 环境的问题而是 Android 构建链路里缺少 C 相关工具链或 CMake 配置不对。我当时的排查方式是先flutter doctor -v检查各链路是否正常再在 Android 模块的build.gradle里检查 SDK 版本和目标版本是否匹配。如果你也遇到类似报错优先排查这两个位置不要急着重装整个 Flutter。项目脚手架这一块我采用的是flutter create生成官方模板再让 AI 基于模板做改造。你可能会问为什么不直接用flutter create之后再让 AI 写全部代码原因很简单官方模板保证了 Android/iOS 原生工程的配置是完整且互相匹配的AI 生成的工程描述再详细也不如 flutter 官方工具直接生成的稳妥。AI 的价值在这里体现在业务代码层而不是代替原生工程脚手架。2.2 让 AI 生成主界面与导航的核心 Prompt 写法项目创建完成后我干的第一件事是让 AI 搭建基础的页面骨架和路由结构。这一步我用的 Prompt 大致是“我需要在 Flutter 项目里实现一个底部导航栏包含三个 Tab账单流水、统计、设置。请使用 go_router 管理路由主页面结构为 Scaffold BottomNavigationBar或 NavigationBar点击切换 Tab 时通过 IndexedStack 保留各页面状态。请先生成路由配置文件 lib/router/app_router.dart再生成主页面 lib/pages/main_shell.dart页面内容先用最简单占位文本。”这里有两个细节值得注意。第一我明确要求使用 IndexedStack 保留页面状态。如果不加这个要求AI 生成的底部导航常常是在切换 Tab 时销毁并重建页面这样一旦用户在“账单流水”页滚动到了很靠下的位置切走再切回来滚动位置就没了。对记账应用来说这种状态丢失的体验非常差。第二路由管理库我用 go_router 而不是 MaterialPageRoute 手动管理因为后期会有编辑详情页、分类管理页等多个页面需要参数传递go_router 的路径式管理更符合我“页面层级清晰”的需求。AI 生成的代码质量很稳定几个文件的代码基本可以直接编译通过。不过我在 Review 时发现它把 NavigationBar 的 selectedIndex 和 IndexedStack 的 index 绑定逻辑写在了 MainShell 内部这本身没问题但我希望页面切换时能通过路由感知当前 Tab方便后期做“点击 Tab 二次刷新数据”这类操作。于是我又追加了一轮指令让 MainShell 通过监听路由状态来同步 Tab 索引而不是自己维护一个局部变量。这个调整 AI 也顺利完成。到这里我对 AI 辅助开发的第一个结论已经形成了它能解决“从无到有”的速度问题但“架构怎么演进”仍然需要你心里有数。2.3 表单页与列表页的实现细节页面骨架通了之后接下来就是核心的记账页面。记账页的表单包含金额、分类选择、日期、账户、收支类型和备注。我让 AI 一次性生成这个表单并特别强调“金额输入框只允许输入数字和小数点最多保留两位小数分类选择使用底部弹窗的形式展示分类图标和名称”。实际生成效果不错但有一处需要我手动纠正AI 默认把金额字段处理成了 double 类型而我在需求里明确要求的是“金额用 int 存储单位是分”。这是记账应用的一个经典陷阱。如果你直接用 double 存金额0.1 0.2 这种浮点精度问题迟早会在汇总统计时爆雷。AI 没有业务上“金额必须用最小货币单位存整数”的常识它只会根据你的描述“金额字段”生成一个看起来对的类型。所以我在后续所有涉及金额的 Prompt 里都加了“金额字段在数据模型中存储为整数单位为分界面展示时转换为元”这个约束。这是一条值得所有做记账类应用的人记住的经验不要让任何一位小数进入你的数据库。账单流水列表页我要求 AI 实现分页加载每页 20 条使用 ListView.builder 懒加载并通过日期分组展示类似“今天”“昨天”“更早”的节分组。AI 在生成列表项结构时表现很好分类图标、金额、备注、账户等信息的位置排布合理。但它在处理“按日期分组”的逻辑时第一次生成的是在内存里遍历全部数据再手动分组这在小数据量下没问题可一旦记录数到了几千上万条内存和启动耗时都会明显变差。我后来让它改成“SQL 层先按日期倒序查出当天数据然后由 Dart 侧做分组的轻量处理”并且把分组逻辑封装到一个独立的工具类里方便后期做单元测试。这个案例很典型地说明了AI 生成的代码可以跑通但性能和扩展性需要你主动打补丁。3. 账本真正的难点本地存储与数据模型设计3.1 为什么记账 App 不需要后端个人记账 App 和团队协作类应用最大的区别在于数据完全属于用户个人不存在跨设备实时同步的刚需。因此第一版我直接放弃了后端服务器采用本地 SQLite 存储。这个决定大幅降低了开发复杂度——不需要设计接口、不需要考虑鉴权、不需要处理网络异常。数据就是用户最私密的资产存在本地反而让人更安心。本地存储我选择的是 sqflite 插件。sqflite 是 Flutter 生态里最成熟的 SQLite 封装库文档全、社区活跃、遇到的问题基本都能搜到答案。有些新项目会倾向选择 drift 这种更“现代化”的 ORM 框架它确实提供了类型安全的 SQL 操作和 migration 工具但学习成本偏高而且 AI 对 drift 的掌握程度明显不如传统 SQL 语句写得稳。所以如果你是靠 AI 辅助开发、又不想在数据层花太多时间 Debug我建议先选 sqflite把表结构和 DAO数据访问对象层设计好后期如果有复杂查询需求再考虑引入更高层的封装。3.2 用 AI 设计数据模型然后人工 review数据模型是整个记账 App 的基石。我在让 AI 建表之前自己先把表结构想清楚了然后再让 AI 据此生成建表语句。这一点想特别强调AI 可以帮你把建表 SQL 写出来但表字段的取舍必须由你自己决定。因为“要不要冗余一个分类名称字段”“预算表按月度还是按周期存”“账户表和账单表的关系是一对多还是多对多”这些问题没有标准答案完全取决于你的产品定位。我当时设计的核心表结构如下bill 表账单记录表。字段包括 id、type收入/支出、amount整数单位分、category_id、account_id账户关联、remark、billed_at业务日期存毫秒时间戳、created_at。category 表分类表。字段包括 id、name、icon、type区分收入分类和支出分类、sort_order、is_deleted。account 表账户表。字段包括 id、name、initial_balance初始余额整数单位分。budget 表预算表。字段包括 id、category_id可空空表示总预算、amount、month格式如 2025-06。我给 AI 的 Prompt 是“根据以下表结构定义创建 sqflite 数据库版本 1 的建表语句和基础 CRUD 方法注意金额字段为整数、日期字段为整数毫秒时间戳、外键关联需建立索引”。AI 返回的建表语句基本正确但我在 review 时发现它对外键索引的创建不够主动只对主键做了约束。后来我手动加了 category_id、account_id、billed_at 三个字段的索引。理由很简单账单流水表最大的查询场景就是按时间范围筛选billed_at 不建索引数据量大后查询会走全表扫描页面会明显卡顿。索引的建立对业务功能没有影响但对体验影响巨大AI 不会替你想这些。3.3 数据库表结构与查询逻辑的坑数据层开发中我踩了一个比较典型的坑AI 生成的“更新记录”方法默认是整行覆盖更新也就是把所有字段都 set 进去。这在普通编辑场景下没问题但如果你想要“只更新备注字段”或“只更新账户关联”这种部分更新能力就需要额外的更新方法。AI 根据“CRUD”这个宽泛指令生成的 update 方法通常是接收一个完整的 Bill 对象。我当时因为账单详情页支持编辑金额、分类、备注等多个字段所以整行覆盖勉强够用但事后想想这是运气好如果后面加一个“批量修改分类”的功能这个结构就不够灵活了。我自己后来补了一个动态更新方法只更新非空字段。还有一个坑是关于事务的使用。AI 生成的批量删除方法是一个 for 循环逐条 delete。如果一次删 50 条记录意味着 50 次独立的事务提交速度慢且中途出错无法回滚会留下半删半不删的脏数据。我让 AI 把整段循环包在db.transaction()里一次性提交。这种数据一致性问题在个人项目里不容易被发现因为数据量小、出错概率低但既然做的是记账应用用户数据的一致性比什么都重要该补的还是要补。数据库查询这块AI 生成的“按月统计收支汇总”SQL 是SELECT type, SUM(amount) AS total FROM bill WHERE billed_at ? AND billed_at ? GROUP BY type这个写法正确且高效。统计页的饼图数据我让它按 category_id 分组查询同时 JOIN category 表拿到分类名称和图标AI 也处理得不错。唯一的问题出在时区上它按“当前时间的 0 点到 24 点”去查当天数据但我传入的是本地时间的零点毫秒值在存储层面我用的又是 UTC 毫秒时间戳导致跨时区使用时统计口径可能偏差一天。这个问题对国内单一地区的用户影响不大但最好在数据层统一约定时间戳一律按 UTC 存储查询时传入本地时区换算后的起始和结束毫秒值。这里加一个方法专门做时间范围计算能省掉后面一堆隐患。4. 让 AI 改 bug 的完整排查链路一次状态丢失问题实录4.1 问题表象与初步猜测项目开发到中后期我遇到了一个让我比较头疼的 bug。现象是在“账单流水”页我把某条记录删除之后列表确实刷新了但切到“统计”页再切回来那条被删除的记录又出现在了列表里。这个 bug 不是每次都出现而是偶发的尤其当你在删除后快速切换 Tab 时更容易复现。拿到这个 bug 之后我的第一反应不是直接丢给 AI而是先复现、再缩小范围。我当时的猜测有两个方向第一列表的数据源没有真正从数据库删除只是界面层做了过滤第二IndexedStack 保留了页面状态删除操作虽然改了数据库但页面切回来时没有重新拉取数据。我倾向于第二个方向因为“切回来旧数据还在”这种表现非常符合“页面被保留了但没刷新”的特征。为了验证我在“账单流水”页面的生命周期方法里加了日志打印是否会触发数据加载逻辑。最终确认IndexedStack 模式下页面切换不会触发默认的生命周期回调来重新加载数据而删除操作后的局部刷新只刷新了列表没有刷新“那个被缓存的页面状态”。根因基本锁定。4.2 给 AI 喂上下文的正确方式找到根因之后我再把问题交给 AI但不是我预期解决方式而是让它基于现状给方案。我把项目相关代码片段MainShell 的 IndexedStack 部分、数据仓库的加载方法、账单列表页的状态管理粘给了 AI并附上了现象描述和我的排查结论。Prompt 我写得比较结构化“我的 Flutter 记账应用使用 IndexedStack 作为底部 Tab 容器用户删除账单后如果切换到统计页再切回账单流水页列表会重新显示已删除的记录。经过排查问题不是数据库层的删除失败而是 IndexedStack 中的页面状态未更新。请给出三种可选修复方案并按你推荐的优先级排序。不要直接改代码先解释方案。”这里有个很关键的点我给 AI 的是完整的上下文而不是一句笼统的“列表不同步怎么办”。AI 的上下文窗口有限如果你把整个项目几十个文件全丢给它它反而抓不住重点。但如果你只给它这一段出问题的代码链路它能很快定位到 IndexedStack 的状态缓存机制上。4.3 根因发现与修复验证AI 给出的三种方案分别是在账单流水页暴露一个刷新方法每次切换到该 Tab 的时候调用强制重新加载数据。使用事件总线或 Provider 的 ChangeNotifier在删除操作后通知列表页更新。放弃 IndexedStack改用每次切换都重建页面。我最终采用了方案一和方案二的结合MainShell 里监听 Tab 切换回调切到“账单流水”页时调用其暴露的刷新方法同时删除操作的 Repo 层在成功后发出一个数据变更事件页面收到事件后重新查询数据库。方案三被我否掉因为“切换到列表页就重建”虽然能解决问题但由于每次重建都会重新查库连续切换 Tab 时会出现明显的白屏闪烁交互体验较差。修复后我做了三步验证第一步删除一条流水后立刻切到统计页再切回来确认列表不保留已删数据第二步连续删除多条记录后快速切换 Tab 多次确认无偶发复现第三步杀掉 App 重新启动确认数据库层面数据确实已删除。三步全部通过后我才把这个 commit 收尾。整个过程走下来AI 在方案建议和代码生成上帮了忙但定位问题的思路、复现步骤的设计、验证范围的确定这些仍然是开发者自己的核心能力。5. 从能跑到好用的性能与体验打磨5.1 Flutter 内存优化和 isolate 的正确用法基础功能和主要 bug 都处理完之后我开始关注性能。记账 App 的数据量一般不会特别大但如果用户连续记了几年账流水表轻松能到几万甚至几十万条。此时如果不做性能优化列表滑动会掉帧统计页汇总时会卡顿体验就像走进了一片泥沼操作一步等半秒谁用谁崩溃。Flutter 的性能优化有几个基础操作必须做。第一是列表项的 build 方法尽量拆分避免一个巨大的 Widget 承载所有内容第二是合理使用 const 构造函数减少不必要的 Widget 重建第三是图片和图标资源用合适的分辨率不要在列表里加载大图。这些优化对 AI 生成的代码来说基本不会自动体现。AI 生成的列表 item 通常会把所有展示内容塞在一个方法里虽然能跑但离“流畅”有差距。统计页的计算开销是另一个重点。月度汇总需要遍历当月所有账单做分类汇总如果聚合逻辑放在 UI 线程当账单量很大时切到统计页的一瞬间会出现掉帧。Flutter 的解决办法是用 isolate 做并行计算。最简单的方式是使用compute函数把一个纯计算任务丢到后台 isolate计算结果再传回主 isolate。我让 AI 把月度统计的计算逻辑抽成一个独立函数然后用 compute 调用改造后的首帧渲染速度提升非常明显。这里想提醒一句compute的传入参数和返回值都必须是可跨 isolate 传递的类型比如基本类型、List、Map如果你传一个自定义对象需要确保它能被序列化否则会报错。我第一版改造时就踩了这个坑AI 生成的自定义统计结果类在compute里直接传报了个类型转换异常后来把结果类改成 Map 传递才解决。5.2 为什么 AI 生成的代码需要二次封装使用 AI 辅助项目几周之后我逐渐形成了自己的工作流AI 负责“功能级代码”的生成我负责“工程级代码”的重构和维护。举一个非常现实的例子AI 生成的数据仓库层Repository方法常常是直接暴露一个FutureListBill getAllBills()给页面调用。在页面少、逻辑简单的时候这样完全没问题。但当你需要在多个页面复用同样的查询逻辑时比如首页列表要查“最近一个月的支出”统计页也要查“最近一个月的支出”如果两个页面各自调用不同的 Repository 方法一旦查询条件变化你要改两个地方这种散弹式修改很容易漏。我的做法是让 AI 先生成一个最简版本跑通流程然后我手动把 Repository 的查询方法统一收敛比如定义getBillsByRange(start, end, {type})这样一个通用的方法页面层通过参数组合获取不同维度的数据。再配合一个简单的缓存层同一时间范围内的查询在短时间内复用结果避免重复查库。这种封装对 AI 来说不是不能做但需要你给它非常精确的设计指令而且每次生成完都要 review。与其反复调教不如自己动手把这层抽象做好。AI 的定位应该是“加速器”而不是“架构师”。5.3 图表统计功能的实现与账单分组逻辑图表统计是记账 App 最容易做出成就感的模块也是最容易让 AI 翻车的模块。我用的是 fl_chart它支持柱状图、折线图、饼图等多种图表自定义程度高。需求里的“月度支出占比饼图”和“近 6 个月收支趋势折线图”我用 Prompt 描述清楚后AI 生成的代码基本能用图表的颜色、图例、数值标签都有了。但有一个问题让我印象深刻AI 在生成饼图数据时对“空分类”的处理不够严谨。比如某个月某个分类下没有任何支出AI 生成的逻辑会把空分类忽略掉这没问题但如果某个月所有分类都为空也就是整月没有任何收支饼图的数据源为空列表fl_chart 在渲染空列表时会导致页面报错。这种边界情况在正常使用时很少遇到但对一个记账应用来说“没有记录”恰恰是很多新用户的第一状态。我后来让 AI 生成一个默认的空数据占位组件当统计结果为空时展示“本月暂无记录”的提示而不是渲染空图表。这种“自动补全边界逻辑”的能力AI 目前还做不到需要人为补漏。账单分组逻辑在前面提过我再补充一个经验按日期分组后需要显示“当天总收入/总支出”这样的小结。这个小结如果逐条累加在大数据量下会有性能问题。我让 AI 在 SQL 层用GROUP BY date(billed_at / 1000, unixepoch, localtime)这种写法按天聚合一下把所有日期的汇总算出来然后 Dart 侧做匹配避免遍历每一条账单。这个优化做完列表滑动和分组渲染的流畅度提升了一个档次。6. 几个可以直接抄作业的 Prompt 套路和一句大实话6.1 需求描述模板、Bug 修复模板与代码重构模板用 AI 写 Flutter 项目这段时间我沉淀了几套实用的 Prompt 模板。技术栈不同但思路是通用的这里直接分享给你可以按需改造成自己的版本。需求描述模板适用于新功能开发我正在用 Flutter 开发一个个人记账应用当前技术栈为 Provider sqflite go_router。请在 [文件路径] 中实现 [具体功能]要求如下 1. 功能行为[描述用户操作流程与预期结果] 2. 数据约定[字段类型、单位、取值范围] 3. UI 要求[组件风格、页面布局、交互反馈] 4. 性能要求[是否需要分页、是否需要 isolate、是否有大数据量处理] 5. 请复用项目现有的 [某个工具类/某个样式常量]不要重复定义。Bug 修复模板适用于遇到异常时的排查我在 [页面/功能场景] 中遇到了 [具体问题描述]。 复现步骤 1. [操作步骤] 2. [操作步骤] 3. [操作步骤] 预期结果[应该发生什么] 实际结果[实际发生了什么附上日志或截图] 相关代码段 [粘贴出问题区域的完整代码] 请先分析可能的原因按可能性从高到低列出再给出推荐的修复方案和具体代码改动。修复时请评估该改动对 [关联模块/其他功能] 的影响。代码重构模板适用于优化已有实现请重构 [文件/方法名]。当前实现的缺陷是[性能差/可读性差/重复代码多/耦合度高]。 目标是 1. [明确的目标] 2. [约束条件如不允许引入新依赖/保持对外接口兼容] 3. [希望采用的设计模式或规范] 请输出重构后的完整代码并简要说明变更点。这三个模板的共同核心是给 AI 足够的项目上下文、明确约束条件和预期结果。模板的意义不是机械套用而是强迫你把“模糊想法”转化成“结构化需求”。这个过程本身就是代码质量的第一道保障。6.2 AI 编程的边界哪些能全信哪些必须人审最后说一说我对 AI 编程边界的真实体会。经过这个项目我认为 AI 在以下场景表现是可靠的UI 页面搭建和基础业务逻辑生成。Flutter 的 Widget 组合方式、表单校验、列表渲染这些模式化代码AI 的正确率很高。标准 API 的调用方式。比如 fl_chart 的基础用法、sqflite 的 CRUD 操作AI 对这些常见库的掌握远超一般开发者。格式化代码和基础重构。变量重命名、提取方法、整理 import 这类机械性工作AI 能省下大量时间。但有几类内容我建议永远不要盲信 AI数据库迁移脚本。涉及已有数据升级的 ALTER TABLE、数据回填逻辑出错了很难察觉恢复成本高。支付、权限、文件读写等涉及系统能力的代码。这些功能出错可能会有额外的合规或安全问题必须逐行 review。涉及业务计算口径的代码。比如“本月结余 上月结余 本月收入 - 本月支出”这种AI 不了解你的业务定义可能把收入支出算反或在边界值处理上出错。一句话总结AI 是效率工具不是兜底方案。它跑得比你快但方向需要你把控。做这个记账 App 的过程中我最大的体会是不要指望 AI 帮你“思考”要把它当成一个执行力超强、但完全没有业务Sense的初级工程师。你描述得越清楚它交付得越靠谱你留给它的想象空间越大后面要填的坑就越深。如果你想用 AI 做自己的 Flutter 项目不妨从一个小而完整的工具类功能开始练手跑通一整条“需求描述 - 代码生成 - 编译调试 - 性能优化”的链路亲身感受几次成功和翻车你自然就知道该怎么用它了。