企业官网建设流程全解析

最近在折腾 Trae 的时候，我一直想找一个比 Todo 列表更像样、但又不至于让 AI 失控的项目来练手。2048 恰好是这类项目里的一个理想选项：规则清晰、状态空间有限，但合并逻辑、胜负判定、动画反馈、Web 端适配一样不少，特别适合用来验证“Trae 到底能不能从 0 到 1 把一个完整小游戏带出来”。这篇文章完整记录了我用 Trae 从创建 Flutter Web 项目到在浏览器里顺畅玩通 2048 的过程，包括每个环节怎么向 AI 提需求、核心逻辑怎么写、测试阶段又踩了哪些和手动编码方式完全不同的坑。文中的代码按三个文件整理，可以拆开看，也可以直接拼装运行，想拿这个项目练手或者只是想快速体验 Flutter Web 游戏开发的人，都能直接对照操作。

1. 为什么选择 2048 作为 Trae 的“第一个有逻辑的练手项目”

1.1 2048 看起来简单，逻辑密度却不低

很多人对 2048 的印象是“一个 4x4 格子里挪数字”，但真正动手拆需求时你会发现，它其实是典型的“逻辑密集但状态可控”的软件项目。一次合法的移动，背后包含遍历棋盘、压缩空白、相邻合并、更新分数、随机生成新块、检查胜负状态，至少六件事；而其中“棋盘没有发生任何变化时不应该生成新块”这个细节，很多第一版实现都会漏。

这种程度的需求，对纯手写来说有点繁琐，但对 AI 编程工具来说又刚好卡在舒适区边缘。它不像 Todo 应用那样一眼能看穿，也不像大型业务系统那样频繁出现 AI 上下文溢出。用一个 2048 来做 Trae 的实践载体，既能看到 AI 生成代码的短板，又能在可控范围内通过提示词把这些短板逐个修掉，很划算。

1.2 Trae 在“从 0 到 1”里承担的角色

我使用的流程是“模型逻辑先用 Chat 模式逐步确认，界面和样板代码用 Builder 模式快速生成”。Trae 的对话式编程体验和 Cursor 类似，但它对中文需求的理解、对项目内文件上下文的自动关联，目前在我这边的实际体验是够用的。

有一点必须提前说明：不要让 AI 一口吃掉整个项目。如果你一上来就说“帮我写一个 Flutter Web 的 2048 游戏”，它确实会给你一个能跑的东西，但大概率是那种把所有逻辑糊在 main.dart 里、方向处理冗余、无法扩展的单文件实现。更好的方式是像带实习生一样，先给它定边界，再让它填代码。这也是我下面两节要先花大量篇幅讲数据结构和代码拆分的原因。

1.3 这次的最终文件规划

我最终确定的结构只有四个文件：

lib/ ├── main.dart # 入口，运行 GamePage ├── models/game2048.dart # 游戏模型和规则逻辑 └── pages/game_page.dart # 页面、手势、键盘、动画渲染

main.dart只负责runApp，game2048.dart是纯 Dart 逻辑、完全不依赖 Flutter，game_page.dart接住了所有界面和交互。这个拆分的好处是：模型层可以单独做单元测试，以后如果要给 2048 加机器人自动求解、做多平台版本，都不用动界面代码。AI 在这种结构下也不容易“越界”，每次改动都限定在明确文件里。

2. 动手前的“翻译”阶段：把游戏规则变成数据结构

2.1 棋盘用二维数组，为什么不是一维

2048 的棋盘是 4x4，最常见的存储方式是List<List<int>>。用二维数组的好处是，网格坐标board[r][c]和玩家看到的行列关系完全一致，读代码时不用做索引换算。有些追求性能的实现会使用一维List<int>，用i ~/ 4和i % 4来换算行列，但在 Flutter Web 这种场景下，4x4 的规模根本不存在性能瓶颈，选择可读性更好的一方案降低出错概率，才是实际开发里更明智的选择。

我请 Trae 生成模型时，第一条约束就写死：“棋盘用List<List<int>>, 4x4，board[r][c]表示第 r 行第 c 列”。如果这个约定不提前固定，AI 很可能在某个版本突然给你换成一维数组，后续所有代码都要跟着断掉。

2.2 合并逻辑：去零、合并、补零

2048 里任意一行向左合并，可以拆成三步：

• 去掉所有 0，得到一个“压缩后”的序列；
• 从左到右扫描，如果相邻两个数相等，就把它们合并成一个数（数值翻倍），同时跳过一个位置；
• 末尾补 0，让序列长度重新变回 4。

举个例子，一行原始数据是[2, 2, 0, 4]，去掉 0 后是[2, 2, 4]，相邻的2和2合并成4，得到[4, 4]，补 0 后就是[4, 4, 0, 0]。

向右移动时并不需要单独写一套算法，把这一行反转后执行同样的“左合并”，再反转回来即可。这个“方向归一化”技巧是我在动手前就跟自己确认过的，因为只要这一层想明白，向上和向下就只是行列转置的问题，代码量直接少一半。

2.3 胜负判定：什么时候算无路可走

游戏是否结束，只要满足下面任一条件：

• 棋盘上还有 0，一定可以继续；
• 存在一对左右相邻且数值相同的格子，可以横向合并；
• 存在一对上下相邻且数值相同的格子，可以纵向合并。

注意这里不能漏掉“数值相同的相邻格子”这种没有 0 也能动的情况。比如棋盘已经满了但有两格紧挨着都是 2，照样能滑动合并出空位。我一开始让 Trae 写isGameOver时，它只检查了“棋盘满没有”，结果在一个满盘但还能合并的状态下直接弹了 Game Over，这就是逻辑翻译阶段没对齐导致的。

获胜条件反而简单，任意一个格子出现 2048 就触发胜利弹窗，但也提供了“继续挑战”的入口，方便玩家继续追求更高的分数。

2.4 为什么不在这一步就让 AI 直接写代码

结构化设计的优先级，一定要高于让 AI 早产出代码。Trae 这种工具最擅长的是把“已有明确拆解的需求”翻译成代码，而不是替你做领域分析和需求决策。如果你自己都没想清楚“无变化不生成新块”或“满盘但有相邻相同能继续”这些规则，指望 AI 在生成时主动替你想全，风险很高。

我把规则用自然语言画清楚之后，才打开 Trae 输入第一轮提示词。这半小时看起来拖慢了进度，实际上省掉了后面至少十次“AI 改逻辑，UI 跟着返工”的无意义迭代。

3. 用 Trae 落地游戏逻辑：提示词与核心代码解析

3.1 第一轮提示词：我要的是“模型层”，不是“满屏代码”

在lib/models/game2048.dart新建文件后，我通过 Trae 的对话输入了下面这段需求：

你是 Flutter 开发者，请帮我在 lib/models/game2048.dart 里实现一个 2048 游戏模型类，要求：

1. 只能导入 dart:math，不要依赖 Flutter；
2. 棋盘用 List<List > 表示，大小 4x4；
3. 提供 reset、moveUp、moveDown、moveLeft、moveRight 方法，move 之后如果棋盘发生变化，要随机生成一个新数字，90% 概率是 2，10% 概率是 4；
4. 移动合并的同时累加分数；
5. 提供 won、over 两个状态字段，并有 canMove 的判断逻辑；
6. 所有方法加注释。

大家可以看到我把“移动之后是否变化”单独提出来放在了第 3 条，这是我吃过亏之后养成的习惯：需求里的隐藏规则必须显式写出来，不能让 AI 去猜。

Trae 在大部分情况下会直接给出一个完整类。如果你对生成结果不放心，还可以继续追加一个需求，让它为Game2048补一组针对moveLeft、canMove的 Dart 单元测试，这个项目的模型层是纯 Dart，测试起来非常顺手，这也是我坚持把模型和 UI 分开的原因之一。

3.2 四个方向的移动怎么复用同一套逻辑

下方是模型类的核心，我删掉注释后的关键代码：

import 'dart:math'; enum MoveDirection { up, down, left, right } class Game2048 { static const int size = 4; late List<List<int>> board; int score = 0; bool won = false; bool over = false; Game2048() { reset(); } void reset() { board = List.generate(size, (_) => List.filled(size, 0)); score = 0; won = false; over = false; _addRandomTile(); _addRandomTile(); } void _addRandomTile() { final empty = <int>[]; for (var i = 0; i < size * size; i++) { if (board[i ~/ size][i % size] == 0) empty.add(i); } if (empty.isEmpty) return; final index = empty[Random().nextInt(empty.length)]; final value = Random().nextDouble() < 0.9 ? 2 : 4; board[index ~/ size][index % size] = value; } bool move(MoveDirection dir) { final before = List.generate(size, (r) => List.of(board[r])); switch (dir) { case MoveDirection.left: for (var r = 0; r < size; r++) board[r] = _mergeRow(board[r]); case MoveDirection.right: for (var r = 0; r < size; r++) { board[r] = _mergeRow(board[r].reversed.toList()).reversed.toList(); } case MoveDirection.up: _moveAlongColumn(true); case MoveDirection.down: _moveAlongColumn(false); } if (_identicalBoard(before, board)) return false; _addRandomTile(); _refreshStatus(); return true; } List<int> _mergeRow(List<int> row) { final compact = row.where((v) => v != 0).toList(); final merged = <int>[]; var i = 0; while (i < compact.length) { if (i + 1 < compact.length && compact[i] == compact[i + 1]) { final value = compact[i] * 2; merged.add(value); score += value; i += 2; } else { merged.add(compact[i]); i += 1; } } while (merged.length < size) merged.add(0); return merged; } void _moveAlongColumn(bool isUp) { for (var c = 0; c < size; c++) { final column = [for (var r = 0; r < size; r++) board[r][c]]; final newColumn = isUp ? _mergeRow(column) : _mergeRow(column.reversed.toList()).reversed.toList(); for (var r = 0; r < size; r++) board[r][c] = newColumn[r]; } } bool _identicalBoard(List<List<int>> a, List<List<int>> b) { for (var r = 0; r < size; r++) { for (var c = 0; c < size; c++) { if (a[r][c] != b[r][c]) return false; } } return true; } void _refreshStatus() { for (var r = 0; r < size; r++) { for (var c = 0; c < size; c++) { if (board[r][c] >= 2048) won = true; if (board[r][c] == 0) return; if (c + 1 < size && board[r][c] == board[r][c + 1]) return; if (r + 1 < size && board[r][c] == board[r + 1][c]) return; } } over = true; } }

这里最关键的一步是“先记录移动前的棋盘，移动后判断是否发生过变化”。_identicalBoard这段逻辑是第二次迭代时我让 Trae 补上的。第一次它生成的版本里，无论棋盘是否变化都会补一个新块，导致连续按同一个方向，棋盘上会莫名其妙多出很多块，这是 2048 的严重规则错误。

3.3 合并顺序为什么不能反过来

有朋友可能觉得，2048 的合并可以“先合并再压缩”，比如[2, 2, 2, 2]先合并成[4, 4]再补零。但如果面对[2, 2, 2, 0]，直接按相邻合并会得到[4, 2, 0, 0]，这看起来对，实际却是错的，因为正确的左移结果是[4, 2, 0, 0]没错，而面对[4, 4, 4, 0]时如果先压缩成[4, 4, 4]再合并，结果是[8, 4, 0, 0]，也正确；可如果你先“合并”再“压缩”，[2, 2, 2, 2]从左到右一次遍历就会变成[4, 2, 2, 0]，这就错了。

这就是我坚持用“先压缩、再合并、最后补零”顺序的真实原因。2048 的合并规则里，每一轮滑动中每个格子最多参与一次合并，不能用类似俄罗斯方块那样“反复塌陷”的思路。注释里写清楚这一点，以后换个人甚至换一个 AI 工具来继续维护这段代码，都不容易踩坑。

3.4 状态字段的更新时机

won和over的刷新必须在_addRandomTile()之后，否则可能出现“新生成一个数字后棋盘满了，但没有触发 over”的漏判。其实新补的数字也可能填满最后一个空位，所以状态刷新放到最后是最稳妥的。

如果玩家选择“继续挑战”，可以把这个状态做成一个手动开关，比如在界面上放一个“继续游戏”按钮，点击后把won重置为 false，但保留棋盘和分数。

4. 界面层：让 Trae 把 2048 的经典视觉做出来

4.1 对 AI 描述 UI 需求：直接给经典配色表

模型层稳定之后，我开始给 Trae 下 UI 需求。我这次没有写“做个好看的界面”，因为“好看”太主观，AI 最后容易给你发挥成花里胡哨的样子。我直接复用了 2048 官方最常见的配色体系，并提供给了 Trae。

同时补充了两个硬性要求：“不要用额外图片资源，所有格子都由容器颜色和文本组成”，“移动和合并过程要有动画”。有了这些明确约束，Trae 生成的第一版界面已经接近可发布状态。

4.2 网格布局与数字渲染

棋盘 UI 用GridView不是最好维护的方案，因为你要精确控制间距、每个格子的圆角，还要叠加动画。我最后采用的是Column + Row手动生成 4x4 网格，或者用Wrap按固定宽度排列。

每个数字格子的核心渲染代码大致是这样：

Widget _buildCell(int value) { return AnimatedContainer( duration: const Duration(milliseconds: 100), curve: Curves.easeOut, margin: const EdgeInsets.all(4), width: _cellSize, height: _cellSize, decoration: BoxDecoration( color: _colorOf(value), borderRadius: BorderRadius.circular(8), ), alignment: Alignment.center, child: value == 0 ? const SizedBox.shrink() : Text( '$value', style: TextStyle( fontSize: value >= 128 ? 20 : 32, fontWeight: FontWeight.bold, color: _textColorOf(value), ), ), ); }

_colorOf和_textColorOf就是上面那张映射表的 Dart 版本，用switch写即可。数字超过 128 后字号要缩小，否则 2048 这个四位数在手机小尺寸下会溢出格子，这是实测时发现的问题。

4.3 手势、键盘与点击冲突

2048 本身就是四个方向的滑动操作，Flutter Web 上同时要兼容触屏和键盘。我在GamePage里包了两层：Focus让页面能拿到键盘事件，GestureDetector负责触摸滑动。

滑动判定的关键是通过onPanEnd拿到velocity，比较水平方向和垂直方向上的速度绝对值，哪个大就走哪个方向。这个方案比计算“按压起点和终点距离”更符合直觉，玩家手指快速一划也能触发，而不是必须拖拽一定像素。

onPanEnd: (details) { final v = details.velocity.pixelsPerSecond; setState(() { if (v.dx.abs() > v.dy.abs()) { v.dx > 0 ? _game.move(MoveDirection.right) : _game.move(MoveDirection.left); } else { v.dy > 0 ? _game.move(MoveDirection.down) : _game.move(MoveDirection.up); } }); },

当时让 Trae 生成这版代码时，它也踩了个经典坑：第一次用的是onPanUpdate，那个事件会在拖动过程中连续触发，导致你手指还没松开，棋盘已经把几个方向都走完了，观感跟抽风一样。所以这里必须明确要求“在 onPanEnd 里根据 velocity 的方向处理”。每次 Trae 给的代码跟预期不一致，多半是我自己在提示词里少写了一个触发时机，后来我养成了凡是涉及交互就先描述“用户从按下到松开的完整动作链路”的习惯。

键盘部分用KeyboardListener，在onKeyEvent里拦截四个方向键，同时要注意阻止浏览器默认的滚动行为。如果不加拦截，方向键在页面上会同时滚动页面，导致棋盘跳动。

5. 动画、手感与响应式：这轮迭代跟着感觉走

5.1 先让界面“动起来”，再谈动画高级感

第一版能跑之后，界面是“跳变”的：按一下方向键，数字哗一下全变。2048 的乐趣很大程度上来自方块移动、合并的视觉节奏，没有动画的版本像在看 Excel 表格刷新。

我用AnimatedContainer包住每个数字格子后，移动和合并会有一个非常轻量的位移动画，时长控制在 100 到 150 毫秒之间。这个数值是调出来的，太短等于没有，太长会觉得拖沓，尤其是连续快速滑动时，动画队列没消化完会出现卡片闪跳。

5.2 新增方块“浮现”的细节处理

真正让我抠得比较久的是“每个 move 之后随机生成的数字要有一个放大浮现的效果”。因为_addRandomTile只是在模型层往数组里填了一个数，UI 层不知道这个数字是刚生成的。我采用的做法是：给每个格子存一个isNew标记，在一次移动完成后的短暂时间内，对新格子的容器做一次从0.5到1.0的AnimatedScale。刻度动画结束后把标记清掉，这样动画不会在下一次重建时重复播放。

这个点也可以求助 Trae，但我建议你自己想清楚这套状态如何存：模型里维护一个新块坐标列表，UI build 的时候查一下当前坐标是否在这个列表里，然后决定要不要加缩放动画。如果直接让 Trae 自由发挥，它可能会给你往模型里塞一个 Flutter 专用的AnimationController，把纯 Dart 模型又污染了。

5.3 分数和最佳成绩的即时反馈

分数变化如果没有反馈，玩家的“爽感”会少很大一截。我给分数文字外层包了一个AnimatedSwitcher，当分数变化时，数字会有一个向上淡入淡出的重绘效果，代码量很少，但感知非常明显。

AnimatedSwitcher( duration: const Duration(milliseconds: 200), transitionBuilder: (child, animation) => FadeTransition(opacity: animation, child: child), child: Text( '$_score', key: ValueKey<int>(_score), style: const TextStyle(fontSize: 28, fontWeight: FontWeight.bold), ), )

5.4 响应式与页面尺寸

2048 的棋盘是正方形，所以我在页面层级用一个LayoutBuilder，取constraints.maxWidth和constraints.maxHeight中较小的一个作为棋盘边长上限，再嵌套一层Center。这样桌面浏览器里拉大窗口，棋盘会保持居中稳定大小，不会被拉伸变形；在手机浏览器上也能自动缩到屏幕宽度以内。

字体建议和格子尺寸一起动态计算，避免在窄屏上显示溢出。

6. Web 发布与实测中的踩坑清单

6.1 构建发布：flutter build web 的静态部署

本地开发用flutter run -d chrome，发布时执行：

flutter build web --release

产物在build/web目录，是纯静态文件，放到任意 Nginx、OSS、GitHub Pages 都能运行。如果你要把游戏部署在某个子路径下，比如https://example.com/2048/，构建命令要加上--base-href=/2048/，否则 JS 资源路径会从根路径去找文件，导致白屏。这个坑很典型，第一次发布 Flutter Web 的人大概率会碰到。

6.2 热重载会“骗”你

Trae 编辑器里按热重载，Flutter 会保留状态，这对界面调试很方便，但它也会掩盖初始化问题。我在改reset()逻辑时，因为热重载不重建 State，旧棋盘状态一直残留，让我一度以为新逻辑没生效。后来强制刷新浏览器页面才看到干净结果。所以遇到“我明明改了代码，怎么行为没变”的情况，先别怀疑 AI 或编译器，手动刷新一次页面再说。

6.3 刷新即丢分的本地存储改造

Flutter Web 默认只在内存里保存状态，浏览器一刷新，分数和最佳成绩全没了。对一个 2048 游戏来说，最佳成绩丢失是非常影响体验的事。我让 Trae 引入了shared_preferences包，在分数变化时异步写入，启动时读取。

注意一点：shared_preferences的 Web 端实现封装的是 localStorage，所以它只能存字符串或基础类型，不要试图直接塞自定义对象。分数、最佳成绩都是整数，完全没问题。

6.4 让 AI 定位问题的提问姿势

实测过程中如果发现 bug，不要只说“棋盘出 bug 了”。我在 Trae 里最常用的问题描述模板是：

当前现象是什么、在什么操作后出现、期望的结果是什么，再附上相关的报错日志或截图。

比如滑动合并后分数不对，我会说：“我在浏览器里点了一次右键，能合并的 2 和 2 没有合并，但棋盘上还是多了一个新块。看代码 move 方法里移动前保存了 before，移动后判断 identicalBoard，请帮我看下是不是比较的时候没有深拷贝。”这样 Trae 的定位路径会短很多，因为List.of(board[r])只做了浅拷贝，如果内部元素仍是可变数组，比较就会出错。这个问题是实际开发中很常见、但直接丢给 AI“为什么我的棋盘不对”往往得不到精准答案的典型。

6.5 测试 2048 是否正确的土办法

做完之后想快速验证逻辑正确，我推荐在模型层测试时打印棋盘：准备一个已知初始布局，跑一次moveLeft，断言最终棋盘和分数。如果没有配置测试环境，直接在浏览器里手动按方向键观察也可以，但效率低一些。Trae 的对话里可以直接让它生成一组test/game2048_test.dart，然后把所有边界情况列给它，它生成的测试用例大多数时候比我手写还全。

这里再补充一个土办法：我玩的时候默认目标是 2048，但如果你跟我一样不想把全部流程走完，可以临时把获胜阈值改成 32，快速验证won状态、弹窗、继续挑战按钮这一整套链路，改回 2048 即可。这种“用最小路径验证状态流”的思路，在任何游戏开发里都通用。

这个项目做完之后，我最大的体会是：Trae 这样的 AI 编程工具，真正节省的时间不在“它一次写出了完整代码”，而在于你明确了数据和状态边界之后，它可以快速生成大量细碎、重复、容易分心的模板代码，把精力留给你去思考规则和体验。如果你也想拿它练手，建议先把 2048 的规则用自然语言写一遍，再让 AI 实现，最后按“移动、判定、动画、存储”这四层逐个迭代，做完你会发现 Flutter Web 开发最折腾人的其实不是代码，而是环境、构建路径和交互细节这些文档不太会告诉你的事。