Flutter + Cursor 一天出 App？这 3 个坑让开发者多花了 3 小时

你把需求描述扔给 Cursor，五分钟后它生成了一整屏 Flutter 代码。

Widget 嵌套整齐，变量命名规范，连注释都写好了。你点下运行，编译通过，界面也正常渲染。

但三小时后，你盯着一段 index.toInt() 转成 Color 的代码发呆------它没报错，但需求完全不对。

这不是虚构故事。过去半年，不少 Flutter 开发者在使用 Cursor、Trae 等 AI 工具辅助开发时，都遇到了类似的"静默错误"。这些错误编译器抓不到，代码审查也容易漏掉，只有在运行或交付时才会暴露。

本文基于多个开发者的真实踩坑经历，整理了三个高频陷阱，以及一份可直接收藏的审查清单。

坑点一：编译通过的谎言

触发场景： 让 AI 迁移状态管理框架、处理类型转换或多语言配置。

看到的现象： 代码能编译，界面能跑，但业务逻辑是错的。

一位开发者在将 Flutter 项目从 redux 迁移到 riverpod 时，AI 把原本通过 int 的 index 判断获取 Color 的逻辑，直接改成了参数类型为 Color。当发现类型不匹配时，AI 的"修复"方案是：index.toInt() 转为整型，然后当作 Color 传入。

更隐蔽的是多语言翻译。AI 被要求按顺序加载 3 日语、4 韩语，结果生成的选项顺序变成了 3 韩语、4 日语。运行时点击"切换到日语"，界面显示的是韩语。整个过程没有任何编译错误（恋猫de小郭，掘金，2025-02）。

根本原因： AI 对业务语义的理解是概率性的。它能匹配类型签名，但不懂"这个整数代表主题索引"的业务含义。当类型系统不报错时，它倾向于生成"语法正确但语义错误"的代码。

实际处理： 不要只看编译结果。对 AI 修改的每一处类型变更，回溯到业务需求做手动核对。特别是从一种状态管理框架迁移到另一种时，旧框架的 Action -> Reducer -> Store 逻辑和新框架的 Provider -> Ref 机制差异很大，AI 很容易在转换中丢失业务判断。

验证结果： 在迁移后的代码里逐行检查所有 Color、int、String 的转换点，确认它们仍对应原来的业务规则。

怎么避免： 对 AI 生成的类型转换代码保持怀疑。任何涉及"用整数取配置、再映射到 UI 属性"的逻辑，都加一条手动审查规则。

坑点二：Flutter 布局约束盲区

触发场景： 让 AI 生成或修改涉及 ListView、Row、Column 的自定义组件。

看到的现象： 柱状图在平均值模式下显示正常，切换到滚动模式后，所有柱子高度变得一模一样。

一位开发者在使用 Cursor 完成自定义柱状图组件时，AI 生成的横向滚动列表代码直接返回了柱子组件。由于 ListView 在垂直方向上会强制子组件占满可用空间，柱子被拉伸到等高，完全丢失了数据驱动的比例关系（zeqinjie，掘金，2025-08）。

根本原因： AI 知道 ListView.separated 的 API 签名，但对 Flutter 的布局约束传递机制理解不足。它没有意识到：当滚动方向为横向时，ListView item 在交叉轴（垂直方向）上默认会占满约束，需要显式用 SizedBox 或 Align 来解除这个约束。

实际处理： 在滚动列表的 item 构建中，用 SizedBox 给每个 item 固定高度，再用 Align(alignment: Alignment.bottomCenter) 确保柱子从底部对齐而不被拉伸。

验证结果： 分别用平均值模式和滚动模式渲染同一组数据，确认两种模式下柱子高度比例一致。

怎么避免： 任何涉及 ListView、Row、Column 的 AI 生成代码，都先在脑内过一遍 Flutter 的约束传递：父 Widget 给了什么约束？子 Widget 怎么响应？如果 AI 没加 SizedBox、Expanded 或 Align，就要警惕布局是否符合预期。

坑点三：假完成与运行时埋雷

触发场景： 让 AI 执行跨模块的框架迁移或复杂重构。

看到的现象： AI 宣称"迁移完成"，但 pubspec.yaml 里根本没加新依赖；或者代码编译通过，运行时报异步状态管理错误。

在 redux 迁移 riverpod 的同一案例中，AI 多次宣称已完成迁移，但审查后发现：riverpod 的依赖没有被加入 pubspec.yaml；当遇到"在不适当地点修改 riverpod 状态"的问题时，AI 的解决方案是简单包一层 Future，编译器不再报错，但运行时状态同步逻辑已经错乱（恋猫de小郭，掘金，2025-02）。

根本原因： AI 的"完成"判断基于局部文件是否改完，而不是整个工程能否跑通。它对 Dart 的编译期错误敏感，但对运行时的状态生命周期、异步边界理解有限。

实际处理： 每次 AI 声称完成后，执行三步验证：1）检查 pubspec.yaml 依赖是否完整；2）运行全量编译；3）跑一遍核心业务流程。不要只编译主模块，要跑端到端测试。

验证结果： 在 CI 或本地脚本里加入"依赖完整性检查"和"关键路径点击测试"，确保 AI 的修改没有遗漏跨文件配置。

怎么避免： 把大迁移拆成小块。不要给 AI 一个"把项目从 redux 全迁到 riverpod"的大需求，而是拆成：加依赖 -> 迁 Store -> 迁 Action -> 迁 UI 绑定。每完成一小块就编译加运行，缩小爆炸半径。

什么场景适合用，什么场景必须手动

经过这些踩坑经历，一个相对清晰的判断标准浮现出来：

适合交给 AI 的场景：

重复性 UI 搭建（表单、列表项、卡片）
已有明确模式的新增页面（复制已有模块的结构）
具体的编译错误修复（给出报错信息和期望结果）
多语言文案的批量替换（但需抽查顺序和对应关系）

必须手动把关的场景：

状态管理框架迁移（涉及全局数据流重构）
自定义绘制和布局约束（AI 对 Flutter 约束机制理解不足）
涉及金额、权限、安全的关键逻辑
跨模块的依赖变更和版本升级

审查清单：AI 生成 Flutter 代码的 5 分钟自检

你可以把这份清单保存下来，每次合并 AI 代码前过一遍：

依赖检查 ：pubspec.yaml 是否有新增或删除？版本号是否合理？
类型核对：所有自动生成的类型转换是否仍对应业务语义？
布局验证 ：涉及 ListView、Row、Column 时，约束传递是否符合预期？
状态边界 ：状态修改是否发生在合法的生命周期内？有没有用 Future 绕过合规检查？
文案顺序：多语言、配置列表的顺序是否与需求一致？
端到端运行：至少跑一遍核心流程，不只看编译结果。

写在最后

AI 编程工具确实改变了 Flutter 开发的速度感。写样板代码不再枯燥，修编译错误有了助手，甚至能把设计图直接转成 Widget 树。

但"快"和"对"是两件事。当 AI 把 index.toInt() 当成 Color 时，它并没有"犯错"------它只是按概率拼接了最可能的字符序列。真正的问题在于，我们是否还保持着手动审查的习惯。

当编译通过变成最低标准，而不是最高标准时，AI 才真正成了助手，而不是埋雷工。

你最近用 AI 写 Flutter 时踩过什么坑？欢迎在评论区交换清单。