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

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 日语。运行时点击“切换到日语”，界面显示的是韩语。整个过程，没有任何编译错误，你却拿到了一个完全错误的结果。

AI 对业务语义的理解，本质上是个概率问题。它能匹配类型签名，但不懂“这个整数代表主题索引”这样的业务含义。当类型系统不报错时，它就更倾向于生成“语法正确但语义错误”的代码。

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

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

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

---

坑点二：Flutter 布局约束盲区

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

柱状图在平均值模式下显示正常，一切安好。但切换到滚动模式后，所有柱子的高度变得一模一样，完全失去了数据驱动的比例关系。

有位开发者用 Cursor 完成自定义柱状图组件时，AI 生成的横向滚动列表代码，直接返回了柱子组件。问题在于，ListView 在垂直方向上会强制子组件占满可用空间，结果柱子被拉伸到等高，所有数据比例都丢失了。

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，编译器不再报错，但运行时状态同步逻辑已经完全错乱了。

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

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

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

把大迁移拆成小块。不要给 AI 一个“把项目从 redux 全迁到 riverpod”这样的大需求，而是拆成：加依赖 -> 迁 Store -> 迁 Action -> 迁 UI 绑定。每完成一小块就编译加运行，缩小爆炸半径，出了问题也好排查。

---

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

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

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

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

---

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

这份清单值得保存下来，每次合并 AI 代码前过一遍，能省不少事：

1. 依赖检查
   ：pubspec.yaml 是否有新增或删除？版本号是否合理？

2. 类型核对
   ：所有自动生成的类型转换是否仍对应业务语义？

3. 布局验证
   ：涉及 ListView、Row、Column 时，约束传递是否符合预期？

4. 状态边界
   ：状态修改是否发生在合法的生命周期内？有没有用 Future 绕过合规检查？

5. 文案顺序
   ：多语言、配置列表的顺序是否与需求一致？

6. 端到端运行
   ：至少跑一遍核心流程，不只看编译结果。

---

写在最后

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

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

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

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