移动端App开发新思路：Flutter 结合AI编程快速开发跨平台应用

你大概已经用 AI 生成过几段 Dart 代码：单看都能跑，拼进项目就开始打架——状态管理两套写法、目录结构越改越乱、改到最后自己都说不清哪块是谁写的。这篇不讲哪个模型强，只讲 Flutter 项目里怎么跟 AI 分工：哪些活交给它、产物按什么结构落地、改完之后用什么判据决定留还是重写。前端 Web 那套流程另开一篇，这里只谈移动端。

你大概已经用 AI 生成过几段 Dart 代码：单看都能跑，拼进项目就开始打架——状态管理两套写法、目录结构越改越乱、改到最后自己都说不清哪块是谁写的。问题不在模型，在于你把它放进了没有边界的工程里。这篇不讲哪个模型强，只讲 Flutter 项目里怎么跟 AI 分工：哪些活交给它、产物按什么结构落地、改完之后用什么判据决定留还是重写。

前端 Web 那套流程另开一篇，这里只谈移动端。移动端有几个绕不开的特性：真机行为跟模拟器不一样、权限与平台通道两边配置不同、打包这一关反馈特别慢。这几点决定了 Flutter 场景下 AI 的用法跟写网页不是一回事，下面按分工、拆解、结构、审查、排查、验收、协作、边界八段说。

Flutter 场景里，AI 到底接哪一段

先说结论：AI 适合做有明确输入输出的局部活，不适合做需要全局一致性的决策。你把导航结构、状态管理选型、依赖取舍这三件事交出去，等于把整个项目的走向交给随机性——它每次给的答案可能都对，但彼此不兼容，三次对话之后你的项目里就有三套风格。

• 适合让它先动的，是「局部替换型」任务：改一个页面的布局、补一套序列化方法、把一段回调改成异步，边界清楚、回滚成本低。
• 不适合开场就做的：跨多个包的大重构、涉及签名与权限配置的活、需要统一全项目风格的改动。
• 判断标准很朴素：这个任务你能不能一句话说清「改完之后哪几个文件变了、怎么验证它对了」。答不上来，就先自己拆细再给 AI。
• 另一条线：改动会不会影响别人正在改的文件。会，就先约好时间，别让 AI 帮你制造合并冲突。

把需求拆成 AI 吃得下的粒度

「一次只改一个可验证单元」是最省事的原则。一个 Widget、一个 use case、一个 repository 方法，都算一个单元；一次把三层调用链丢过去，它就会开始自己发明中间接口，而你没有对应的实现去接。

1. 固定三样信息目标文件路径、现有相关代码片段、验收方式。前两样决定它改哪里，第三样决定你怎么知道它对——缺了验收方式，你只能肉眼读代码猜。
2. 明确写出记录的平台差异返回手势、权限弹窗、键盘避让这几处两边行为不同。不写清楚，它默认按一套逻辑糊过去，真机上一测才发现。
3. 一次只碰一层不要让它在同一轮里同时改 UI 和数据层。改完出问题，你分不清是样式引起的还是取数引起的，排查顺序直接乱掉。
4. 要求它输出改动清单除了代码，让它列一行「改了哪些文件、每个文件改了什么」。你按这份清单对 diff，比通读代码快。

粒度不是越细越好。拆得比一次编辑还小，来回对话的成本会超过写代码本身。经验上的平衡点是：一个单元大约对应你一次提交。

工程结构怎么摆，才不被 AI 搅乱

目录结构要在放 AI 进来之前定好。按 feature 分目录（每个功能一个文件夹，内部再分 UI、逻辑、数据）比按类型全局分目录更容易约束产出位置，因为它给每个新文件都预设了一个「应该在哪」。

约定文件

命名规则、状态管理方案、网络层入口、错误处理方式各写几行，进版本库，每次对话贴相关那几行。

产物落地规则

新文件只放约定目录，不许随手新建 utils 塞进去；改完先看 diff，越界就原地重写。

回滚点

每轮 AI 改动前提交一次，改坏了直接回退，别在脏工作区里叠第二轮生成。

• 新文件落位：先看它有没有落在约定目录，落在外面直接让它重写，别自己搬过去——搬一次它就学会可以乱放。
• 命名一致：它经常给出一套自己风格的命名，跟项目里已有的对不上。这类问题在 review 时一次性指出，比逐个改省事。
• 状态管理只允许一种：同一份约定文件里写死用哪个方案，发现它混用两套写法，退回重写，别自己缝。
• 公共代码的边界：抽不抽公共方法由你定，别让它为了「看起来更整洁」把两个不相干的模块合并。

生成代码怎么审：四个必看项

审生成代码不是通读，是按清单扫。下面四项覆盖了绝大多数线上才暴露的问题，把它们过一遍比逐行读高效得多。

最后一项容易忽略：生成代码里引一个新包，往往是因为那个包让它的写法更短。但对你的项目来说，多一个依赖就多一份维护和版本冲突的可能。查清楚再加。

• 生命周期问题的特点是延迟暴露：页面来回切几次、后台切前台几次才看出来，所以代码审的时候看不见就先放着，验收阶段必须补测。
• 空安全问题是编译期不报、运行期崩，属于必须当场改的那类。
• 异步边界问题通常表现为偶发崩溃或状态错乱，日志里能看到，但不好复现，早点改掉最划算。
• 隐式依赖问题在打包阶段才炸，尤其是只在某个平台生效的包，早查早省事。

跑不起来时，按这个顺序排

很多人一遇报错就怀疑 AI 写错了，其实是构建残留。排查顺序固定下来，能省掉大量来回。

1. 冷启动重来清缓存、重新拉依赖、完整重建一次。很多「生成代码有问题」在这个阶段就消失了。
2. 看第一条报错异常链很长，最后那条往往是连锁反应。先解决最上面那个文件与行号，再往下看。
3. 二分定位把新加的代码整块注释掉，确认能起来，再一块块放开。比逐行读快，也比问 AI 快。
4. 带上下文回去问贴报错原文、贴相关文件、说明你已经试过什么。只说「还是不行」，下一轮多半又给你一个猜测。

flutter clean && flutter pub get && flutter run

如果这条命令跑完问题依旧，那才轮到怀疑代码。问 AI 的时候把这条命令的结果一起贴上，它会少给你一半的无效建议。

每个阶段拿什么验收

验收标准要提前定，不能改完再看。按四个层级走：页面级、数据流级、打包级、提交级。每一级都有明确动作，过了再进下一级。

• 单页面级：能加载、能交互、切走再切回状态正常、无异常日志。四条都过再进下一个页面。
• 数据流级：断网、慢网、返回错误码三种情况各走一遍，看有没有兜底提示——AI 默认只写成功路径。
• 打包级：至少在两种屏幕尺寸各跑一次，横竖屏切换、深色模式、系统字体放大各看一遍，这几项最容易在真机炸。
• 提交级：扫一遍 diff，确认没有把调试打印、写死的测试地址、临时绕过逻辑一起带进去。

验收里最容易被跳过的是数据流级。成功路径跑通了不代表能用，失败路径才是用户投诉的主要来源，而 AI 生成的代码在失败路径上通常只有一行异常抛出。

多人协作与数据边界

多人用 AI 时，最麻烦的不是重复劳动，是风格分叉。两个人各自跟 AI 对话，生成的命名、状态管理、错误处理方式可能都不一样，合并时全是对不上的写法。

关于代码归属，别等到出问题才讨论。团队里先约定好：AI 生成的代码进仓库前由谁审、出了问题由谁跟进。这件事说清了，后面省掉很多扯皮。

个人项目、练手工程，这些规矩可以省，按自己节奏来就行。前面这些约束是给有协作和上线压力的项目准备的。

这些情况别让 AI 主导

有三类活建议自己写、让 AI 只做检查。它们的共同点是：反馈慢、出错代价高、或者依赖对底层流程的理解。

• 性能敏感的滚动列表、复杂动画、自定义绘制：这块靠的是对渲染流程的理解，AI 给的方案常常「能看」但帧率不稳，得自己按 Profile 结果改。
• 原生插件与平台通道：两边的配置细节多，生成的东西经常对不上当前工程配置，建议自己写。
• 上线前的签名、混淆、商店配置：出错代价高、反馈慢，别拿它练手。

凡是反馈周期超过一天、出错了要重来一遍的活，都别让 AI 主导——你没法用它快速验证对错。

除了这三类，还有一种情况：需求本身还没想清楚。这时候让 AI 生成代码，只会把你脑子里模糊的部分固化成一份看起来完整的实现，后面推翻的成本更高。先把需求和边界写下来，再开对话。