企业官网建设流程全解析

上午刚打开工位电脑，茶水间还没走到一半，老板就在群里甩了张图过来："客户要个拼图小游戏，H5的，下班前出个demo。"我回了句"3D拼图我怕是搞不定"，老板秒回："3d拼图我不会，用Cocos做个会动的拼图总可以了吧！"

看到这条消息我是真想笑。老板理解的"会动"，不是让我去啃3D模型、光照、物理引擎那一套，而是要拼图块在屏幕上有动画、有反馈、能拖拽、拼对了能欢呼。说白了，这是个非常典型的2D交互游戏需求，而Cocos Creator干这个正好顺手。如果你也遇到过类似的情况——老板/客户说"要个会动的XXX"，而你差点被"3D"两个字劝退——那这篇文章就是给你写的。

带完整工程思路、能用键盘直接抄走的代码、还有我实际踩过的几个坑，一步一步说清楚怎么用Cocos Creator在三小时里做一个"会动"的拼图demo。不涉及任何复杂的3D内容，核心就是三件事：数据逻辑、触摸交互、tween动画。这篇文章适合刚接触Cocos的开发者，也适合被需求逼着快速上手的半路出家人。

1. 需求拆解：老板嘴里的"会动"到底是个啥

1.1 从一句吐槽变成需求清单

程序员最怕的不是需求复杂，是需求模糊。但"会动的拼图"这句话，其实比你想的要有用得多。我把老板的原话拆开，再结合客户那边可能想要的效果，整理成下面这份需求清单：

• 拼图块能拖拽移动，松手后自动滑到对应的格子位置
• 摆放正确时有明显的成功反馈（放大、发光、变亮）
• 摆放错误时有失败反馈（抖动、变暗）
• 拼图开局时所有碎片有一个"飞入"动画，不能直接干巴巴地铺在屏幕上
• 全部拼完后有一个通关动画，让客户觉得这钱花得值

你看，"会动"就变成了"拖拽滑动 + 自动归位 + 成功/失败反馈 + 入场/通关动画"。没有一条需要3D。这个思路非常重要，几乎所有的"我不会XX"其实都是"我不知道怎么把需求翻译成技术方案"。

1.2 为什么选Cocos Creator而不是现成库

当时我脑子里过的方案有三个：

第一，用原生JS手动实现。可行，但拼图涉及的碰撞判定、动画曲线、多点触摸、多分辨率适配全都要自己造轮子，半天根本做不完，何况我下午还要开两个会。

第二，找现成的拼图库。GitHub上确实有jigsaw相关的JS库，但那种现成库通常长得像"拼图游戏模板"，改UI、改动画、接客户的图都要和别人的代码搏斗，遇到bug很难排查。对demo阶段来说反而拖慢速度。

第三，就是Cocos Creator。它最合适当下的场景：场景编辑器和代码逻辑分离，UI搭建靠拖拽，拼图块做成预制体后一行代码就能批量生成；自带tween缓动系统，做"滑动、缩放、抖动"这类动画不需要引入任何额外库；导出H5直接就是一个静态站点，发给客户用浏览器就能打开，连环境都不用配。

我最终选了Cocos Creator 3.8，因为3.x版本的tween API比2.x更统一，触摸事件也走的是标准节点事件，写起来顺手。如果你还在用2.4.x也没关系，思路一样，API换个别名而已。

1.3 整体架构：数据、表现、动画三层分离

开发这种小游戏最忌讳的是把代码全堆在节点脚本里，动不动就是this.node.getChildByName这种写法，越写越乱。我做任何游戏demo都会把代码分成三层：

• 数据层：拼图的格子状态、每块拼图当前在第几行第几列、是否归位。这是游戏的"真相"。
• 逻辑层：拖拽开始/结束、交换判定、胜利检测。负责修改数据层并通知表现层。
• 表现层：节点位置、Sprite贴图、tween动画调用。只负责"好看"，不做任何判断。

为什么这么分？因为拼图的需求大概率会变。比如老板明天说"把图换成客户logo"，你只需要换贴图资源；后天说"改成4x4"，数据层和生成逻辑都不动。如果你把数据和动画全揉在一个脚本里，改一行配置可能牵出三处bug。这个习惯从这个小demo开始养成，后面接大项目会轻松非常多。

2. 核心玩法设计：拼图的数据结构与交互规则

2.1 先说清楚"拼图块"和"格子"是两个东西

新手最容易混的概念：拼图块（tile）是屏幕上能被拖的那些节点，格子（cell）是它们在正确位置上时底下的"坑"。我见过有人用两个二维数组分别维护，最后同步出问题，拼图明明拼对了却始终判不了胜利。

我的做法是只维护一个二维数组grid，它保存的是"当前每个格子里放了哪块拼图"。拼图块自身的节点属性上再记一个rid（原始编号，即它在完整图片里的编号，等于标准答案）。判断胜利时，挨个格子看grid[i][j]里那块拼图的rid是否等于i * col + j就行。这样只有一个数据源，不会出现"格子对但块不对"的错位问题。

2.2 相邻判定与拖拽交换

核心交互是：玩家按住一块拼图，拖到相邻格子的位置，松手后把两块拼图的位置交换。如果是拖到不相邻的位置，就弹回去。相邻判定其实就一个公式：两个格子的曼哈顿距离等于1。

// 判断两个格子是否相邻 function isAdjacent(r1: number, c1: number, r2: number, c2: number): boolean { return Math.abs(r1 - r2) + Math.abs(c1 - c2) === 1; }

交换逻辑也很简单，但有一个关键点：交换的是"格子里的拼图块引用"，而不是拼图块自己的行列属性。做完交换后必须同步更新两个拼图块身上的row和col，否则下次拖拽判定时拿到的位置就是旧的，会出现"明明相邻却说不能交换"这种鬼畜问题。

2.3 胜利检测与游戏状态机

有了数据层，胜利检测就是遍历一遍：

private checkWin(): boolean { for (let r = 0; r < this.rows; r++) { for (let c = 0; c < this.cols; c++) { const tile = this.grid[r][c]; if (tile.rid !== r * this.cols + c) { return false; } } } return true; }

光有这个方法还不够。你得防止玩家在动画播放过程中继续乱点，否则会触发"动画中的块被再次拖走"的bug。所以我给整个游戏维护了一个简单的状态机，四个状态：

状态切换靠一个_state字段加几个判断就搞定了。别觉得小题大做，这个demo里状态机可能只省了三五个bug，但你写任何交互类游戏都会用到，早点习惯这个写法不吃亏。

3. 让拼图"动"起来的动画设计

3.1 核心移动动画：Cocos的tween到底怎么用

Cocos Creator 3.x的tween系统是整个"会动"的灵魂。它的用法比2.x的cc.tween更直观，核心API就四个：tween(node)开启动画链，.to(duration, props)渐变到目标状态，.by()相对变化，.call()在某个时间点执行回调，最后.start()开始播放。

给我的拼图块写一个"滑到目标位置"的动画：

import { tween, v3, Vec3 } from 'cc'; // 让拼图块移动到目标格子对应的世界坐标 private tweenMoveToTarget(tile: PuzzleTile, targetPos: Vec3): Promise<void> { return new Promise((resolve) => { if (tile.node.position.equals(targetPos)) { resolve(); return; } tween(tile.node) .to(0.25, { position: targetPos }, { easing: 'sineOut' }) .call(() => resolve()) .start(); }); }

注意我用了sineOut缓动曲线。这是我在反复试手感后确定的：线性移动太生硬，像纸片被平移；sineOut是"快速启动、缓慢到位"，模拟真实物体滑过去然后自然停下的感觉，0.25秒这个时长也正好，再短会显得急促，再长会显得拖沓。缓动曲线是游戏手感的隐形功臣，值得在每个动画上都花几秒钟想一想。

3.2 反馈动画：拼对了与拼错了都得有"动静"

拼图这种玩法，反馈就是游戏体验本身。客户不会关心你的代码多优雅，他们只关心"拖对了有没有感觉"。

我做的成功反馈是"弹一下"：先放大到1.15倍，再回弹到1倍。配合一个半透明的发光底图同步渐显渐隐。

private playCorrectFeedback(tile: PuzzleTile): void { // 节点自身的缩放回弹 tween(tile.node) .to(0.08, { scale: v3(1.15, 1.15, 1) }) .to(0.15, { scale: v3(1, 1, 1) }) .start(); // 底图发光效果 const glow = tile.glowNode; if (glow) { tween(glow) .to(0.08, { opacity: 255 }) .to(0.2, { opacity: 0 }) .start(); } }

错误反馈用的是"颤抖"动画，原理是让节点在X轴上连续做几个小幅度的位移，幅度递减。这里有一个细节：千万别用.by()无限叠加位移，否则做完动画节点位置就偏移了。正确做法是在动画结束后把节点位置强制归回原位，或者记录初始位置后做相对恢复到原位。

3.3 入场动画：开局第一眼决定demo的观感

老板说"会动"，其实第一眼看到的东西最重要。如果我直接把拼图铺在屏幕上，老板的第一反应一定是"这也没动啊"。所以我在开局做了拼图碎片的飞入动画：每块拼图从屏幕外随机角度飞向自己的格子，间隔0.03秒一块，整体看起来像是一场"碎片雨"然后重组成完整图片。

这里有个性能细节：十几块拼图同时做tween没有任何压力，但如果你后续要做几十上百块，别用"每块一个独立tween"的写法，改成统一用tween的delay参数错开启动时间，或者直接用一个节点统一管理。这个demo里我选择了最简单可靠的方式——在外面用setTimeout错开，配合await，因为微信小游戏环境里setTimeout的精度其实够用了。

4. 实战：从零搭建一个会动的拼图Demo

4.1 场景搭建与预制体准备

打开Cocos Creator 3.8，新建一个2D空项目，在Canvas底下建好三个节点：

• Board：拼图容器，挂在屏幕中央，所有拼图块都是它的子节点
• WinMask：通关时闪一下的半透明遮罩，初始隐藏
• UI：放计时器和步数统计

接下来做拼图块的预制体。一个空的节点下面挂三样东西：Sprite显示图片切片，UITransform设置尺寸，Graphics或者一张纯白底图做发光底（放在Sprite底下，默认隐藏）。拼图块大小为120x120，所以图片切片必须是正方形的。我用一张确定的图片切好9宫格，分别命名part_0.png到part_8.png，这些是静态资源，运行时直接加载。

关于切图方式：我用的不是Cocos自带的图片切分，而是在制作原图时直接用PS分好格子导出9张图。为什么？因为运行时动态切片需要逐像素处理，还要处理边缘，代码量和排查成本都高；而设计阶段就切好图，运行时代码只需要"根据编号选贴图"，一行this.getComponent(Sprite).spriteFrame = frame就完了。对小demo来说，把复杂度往设计阶段挪永远是划算的。

4.2 拼图块脚本：数据与表现的最小单元

每块拼图是一个PuzzleTile组件挂上去。这个组件只负责两件事：记住自己的编号和行列，提供被拖拽时的起始位置记录。

import { _decorator, Component, Node, Vec3, tween, v3, Sprite, SpriteFrame } from 'cc'; const { ccclass, property } = _decorator; @ccclass('PuzzleTile') export class PuzzleTile extends Component { rid: number = 0; // 标准答案编号：第几块 row: number = 0; // 当前所在行 col: number = 0; // 当前所在列 startPos: Vec3 = v3(); // 拖拽开始时的节点位置 setContent(frame: SpriteFrame) { this.getComponent(Sprite)!.spriteFrame = frame; } }

注意startPos这个字段。拖拽的过程中，节点的位置一直在变，但松手后如果判断出"这次拖拽无效"，你得知道把节点放回哪里。保存拖拽开始瞬间的位置就是干这个的。这是我踩过坑之后补上的——第一次写的时候我忘了保存，结果拖歪了只能靠"记住之前格子的坐标"兜底，代码丑得不行。

4.3 拼图管理器脚本：生成、布局与调度

PuzzleGame是挂在Board上的管理器，负责开局生成拼图块、处理拖拽事件、执行交换动画和判定胜负。代码分几个部分来讲。

先看初始化与布局。生成拼图块时，我让每块节点记录自己的"格位坐标"，这个坐标是相对Board的本地坐标。核心公式是：第r行第c列的格子中心点位置是((c - (cols-1)/2) * tileSize, ((rows-1)/2 - r) * tileSize)。这样算出来的好处是拼图整体居中，不需要再手动偏移。

private initPuzzle(): void { this.tiles = []; this.grid = Array.from({ length: this.rows }, () => Array(this.cols).fill(null) ); // 随机打乱编号顺序，保证至少有一块不在原位 const shuffled = shuffleArray( Array.from({ length: this.rows * this.cols }, (_, i) => i) ); for (let r = 0; r < this.rows; r++) { for (let c = 0; c < this.cols; c++) { const rid = shuffled[r * this.cols + c]; const tileNode = instantiate(this.tilePrefab); tileNode.setParent(this.boardNode); const tile = tileNode.getComponent(PuzzleTile)!; tile.rid = rid; tile.row = r; tile.col = c; // 设置贴图 const frame = this.frames[rid]; tile.setContent(frame); // 计算格子中心坐标 const pos = v3( (c - (this.cols - 1) / 2) * this.tileSize, ((this.rows - 1) / 2 - r) * this.tileSize, 0 ); tileNode.position = pos; tile.startPos = pos; this.grid[r][c] = tile; this.tiles.push(tile); } } }

这里有个我自己都差点写错的地方：rid是"标准答案里的编号"，它决定了贴图用哪一张；而row和col是"当前所在的位置"。两个概念千万不要合并成一个字段，否则切图对应关系和判断胜利会互相污染。命名上我特意用rid而不是id来提醒自己：这只是一个参考编号。

接着看拖拽事件。我选择的是在每块拼图上单独监听触摸事件，而不是在Board上统一监听。原因是拼图块判定拖拽是否命中比较简单，事件就带出了tile实例，不用再做一次坐标反查。对应的隐患是每个节点多一份监听，但9个节点的监听开销可以忽略，如果将来做100块以上的拼图再改成事件委托。

private bindTileEvents(tile: PuzzleTile): void { tile.node.on(NodeEventType.TOUCH_START, (event: EventTouch) => { if (this.state !== GameState.Idle) return; this.state = GameState.Swapping; this.dragTile = tile; // 把节点抬到UI树的顶层，避免和其他块碰撞遮罩互相影响 tile.node.setSiblingIndex(this.boardNode.children.length - 1); }, this); tile.node.on(NodeEventType.TOUCH_MOVE, (event: EventTouch) => { if (this.dragTile !== tile) return; // 把世界坐标转换成Board的本地坐标 const worldPos = event.getUILocation(); const localPos = this.boardNode.getComponent(UITransform)! .convertToNodeSpaceAR(v3(worldPos.x, worldPos.y, 0)); // 偏移半块，让手指在拼图块中心 tile.node.position = new Vec3( localPos.x - this.tileSize / 2, localPos.y + this.tileSize / 2, 0 ); }, this); tile.node.on(NodeEventType.TOUCH_END, () => this.handleDrop(tile), this); tile.node.on(NodeEventType.TOUCH_CANCEL, () => this.handleDrop(tile), this); }

松手处理的逻辑是：根据手指最终所在位置判断它落在哪个格子里，如果落点所在格子与当前格子相邻，交换；否则原路滑回。

private handleDrop(tile: PuzzleTile): void { if (this.dragTile !== tile) return; // 手指当前位置转成格子坐标 const pos = tile.node.position; const c = Math.round(pos.x / this.tileSize + (this.cols - 1) / 2); const r = Math.round(-(pos.y / this.tileSize - (this.rows - 1) / 2)); const targetInBound = r >= 0 && r < this.rows && c >= 0 && c < this.cols; const targetTile = targetInBound ? this.grid[r][c] : null; const selfRow = tile.row, selfCol = tile.col; if (targetTile && isAdjacent(selfRow, selfCol, r, c)) { // 交换数据层 this.grid[selfRow][selfCol] = targetTile; this.grid[r][c] = tile; targetTile.row = selfRow; targetTile.col = selfCol; tile.row = r; tile.col = c; // 让两块同时滑到彼此的格子 const tileTarget = this.cellToWorldPos(r, c); const targetTileTarget = this.cellToWorldPos(selfRow, selfCol); this.playSwapAnimations(tile, tileTarget, targetTile, targetTileTarget); } else { // 无效操作：滑回原位置 tween(tile.node) .to(0.12, { position: this.cellToWorldPos(selfRow, selfCol) }, { easing: 'backOut' }) .call(() => { if (this.checkWin()) this.onWin(); }) .start(); } }

注意一个特别容易忽略的坑：交换动画完成之前，必须让游戏处于Swapping状态，所有触摸事件直接return。如果没有这个状态锁，玩家快速连点两块相邻拼图时，会出现"上一轮交换动画还没放完，下一轮拖拽已经拿到旧数据"的错乱。我个人建议在setTimeout或tween的回调里统一调用一个finishSwap()方法，把"动画结束"和"状态恢复"绑定在一起。

4.4 通关动画：让"完成了"三个字变成高光时刻

通关时我做了一个三段式动画：所有拼图块同时放大1.1倍再回弹，整个Board微微晃动一下，然后弹出一个"恭喜完成"的UI面板。这个UI面板是用一个普通节点加Label做的，在Canvas里初始隐藏，通关时淡入。

private onWin(): void { this.state = GameState.Win; // 拼图块整体庆祝 tween(this.boardNode) .to(0.06, { scale: v3(1.03, 1.03, 1) }) .to(0.12, { scale: v3(1, 1, 1) }) .start(); // 遮罩先淡入做视觉聚焦 this.winMask.active = true; tween(this.winMask) .to(0.2, { opacity: 120 }) .delay(0.3) .to(0.3, { opacity: 255 }) .call(() => { this.winPanel.active = true; }) .start(); }

这里有一个细节：遮罩用Sprite组件的话，它的透明度可以直接tween，但前提是Sprite本身的Color是白色不透明，并且节点上不能有UIOpacity组件抢控制权。我第一次就是忘了把Sprite颜色设置好，结果tween的opacity没有任何效果，排查了半天。Cocos里让节点透明有两套体系，Sprite.color和UIOpacity，选一套用到底，别混用。

5. 常见问题排查实录：我踩过的四个坑

5.1 触摸事件被其他UI挡住

第一版做完，我直接在浏览器里测试，发现拖拽拼图时偶尔会失灵。后来在真机预览发现更严重：从拼图块上方快速滑向左侧边缘时，触摸直接断掉，TOUCH_END没触发，拼图块卡在被拖到一半的位置。

原因有两个：一是Canvas上某些UI节点（比如计分板）默认参加了事件冒泡但尺寸覆盖到了拼图区域；二是当手指移出节点边界时，Cocos的触摸事件可能会发TOUCH_CANCEL而不是TOUCH_END，如果只在TOUCH_END里做收尾，就会漏。

解决方案：给拼图区域上面不相干的UI节点挂一个BlockInputEvents或者在代码里判断TOUCH_CANCEL也要处理收尾逻辑。我把TOUCH_CANCEL和TOUCH_END都指向了同一个handleDrop，这样即使手指划出边界，拼图也能正确回到原位，不会卡在半空。

5.2 tween被打断导致拼图卡死

另一个必现bug：玩家在交换动画播放中快速点击另一块拼图，动画链被新tween打断，前面的.call()回调没执行，游戏状态一直卡在Swapping，所有触摸都被无情return，页面看起来就像冻住了一样。

排查思路是先看状态机。我在handleDrop入口加了一条日志，发现进入时状态永远是Swapping。然后意识到是tween链覆盖问题。Cocos的tween(node)如果对同一个节点连续调用，默认会把之前的tween停掉，而停止不等于执行回调。

修复方案有两个：一是动画期间用状态锁彻底禁止所有交互，这是治本；二是在SWAPPING状态下，所有交换动画用tween(...).to().call()串成一条链，保证回调一定在动画结束后执行，并且给tween链加一个stop()兜底，在节点销毁或重置时清掉所有tween。

5.3 坐标转换：本地坐标和世界坐标的混用

每次写Cocos交互，坐标转换都是必踩的坑。拼图块监听触摸事件，event.getUILocation()拿到的是UI世界坐标（Canvas坐标系），而拼图块的位置是Board节点下的本地坐标。如果你不做转换直接把世界坐标赋给节点，拼图块就会飞到屏幕外的奇奇怪怪位置。

正确做法是boardNode.getComponent(UITransform).convertToNodeSpaceAR(worldPos)，把它从世界坐标系转成Board的本地坐标系。要注意的是convertToNodeSpaceAR是"锚点缩放"版本，它在转换时会考虑节点的缩放和锚点，适合用在UI节点下。如果你用的是普通节点，可能要用convertToNodeSpace（不带AR的版本），这两个方法在节点有缩放时结果不一样。我的Board节点没有缩放所以随便哪个都行，但你要是有放大缩小效果，记得选对版本。

5.4 性能：拼图块数量变多怎么办

我这个demo里只有9格，性能和节点数完全不是问题。但如果老板第二天说要做一个20x20的拼图，400个节点同时出现在场景里，每个节点还有贴图和阴影，某些低端安卓机上就会开始掉帧。

两个优化方向提前想好：第一，把拼图块的对象池化，不要在初始化时一次性实例化400个节点，而是只实例化可视区域的块，滑出屏幕的块回收进对象池重复利用；第二，把拖拽相关的监听从每个块绑一遍改成在Board上统一监听，通过坐标反查命中哪一块。这两条我现在没做是因为没必要，但代码的框架已经留好了接口——生成和回收方法单独抽出来，将来改起来不用重写。

6. 效果调优与交付技巧：demo怎么让老板眼前一亮

做demo本质上是一次"快速提案"，技术上能跑通只占一半，另一半是演示效果。我在实测过程中积累了几个特别出效果的小技巧。

先说出场顺序。我强烈建议在游戏启动时加一个延迟，让玩家先看到拼图碎片的"最终完整图"闪现0.5秒，再打乱显示碎片飞入。这个"先看答案再打乱"的细节能让玩家立刻理解玩法目标，比直接甩出一堆乱序碎片友好得多。实现只要在initPuzzle里先生成所有块并排列成正确答案，0.8秒后再执行打乱和飞入动画。

然后是操作手感。拖拽过程中我给被拖拽的拼图块加了一个0.05秒的放大动画，视觉效果是"这块被拎起来了"，叠加上层投影。松手后根据结果播放回弹或抖动。这个"拾起-放下"的手感在小游戏里非常管用，玩家会明显感觉到"我操作的东西是活的"。

最后是声音。虽然demo阶段没有配音素材，但我用Cocos的AudioSource组件挂了一个很短的"咔嗒"声，在拼图块归位时播放。这个声音用系统自带的一个点击音效改的，成本几乎为零，但现场演示时，音效一响，老板直接"哎哟不错"。声音对游戏完成度的提升往往是超预期的，千万别忽略。

还有交付环节的一个建议：导出H5后，把构建产物放到一个静态目录，手机扫码就能打开。第一次演示请在真机上进行，不要在浏览器里演示，因为触摸手感在鼠标和手指下差异很大，万一老板上手一滑觉得"不跟手"，前面的好感全没了。我通常会准备两个构建：一个竖版手机页面，一个横版桌面页面，因为客户很可能在不同设备上打开，而Cocos的多分辨率适配只需要在Canvas的Fit Width和Fit Height上做简单配置就能兼顾两种模式。

7. 复盘：这次"被逼出来的拼图"教会我什么

整个项目从接到需求到交付demo，实际花了三个多小时，其中调试触摸坐标和tween状态锁占了一半时间。如果让我重新做一次，我会把时间分配改成：花40分钟想清楚"会动"到底分层在哪，确认交互逻辑和动画需求；花一个小时搭建场景和预制体；剩下时间全部留给手感调试。

这次最大的收获是二八法则：一个让老板满意的"会动"的拼图，80%的卖点在于——飞入动画够炫、交换滑动够顺、成功反馈够响。这三件事都只需要基础tween就能实现。真正复杂的拼图算法（比如拼图块轮廓匹配、旋转检测）在这个需求里根本用不到，我也确实不会，但不需要用。老板说"用Cocos做个会动的拼图"，他想要的从来不是一个完整的3D拼图模拟器，而是"一个能拖、能滑、能看到效果的游戏"。

另外还想说一句：被需求逼着学东西其实是效率最高的学习方式。我这次虽然没碰3D，但为了处理拖拽坐标，我把Cocos的UITransform和坐标转换体系顺带摸清楚了；为了处理动画打断，我把tween底层的"链与回调"机制也理解透了。这些都是下次做更复杂项目时一定用得上的地基。

最后分享一个我实际用起来很顺手的建议：如果你也接到了一个看起来"越界"的需求，先别急着说不会，把需求里的动词拆出来——"会动"是哪些动作？"好看"是哪些反馈？大部分时候，老板提的是"效果词"，你真正要做的是把效果翻译成具体的交互和动画，这才是游戏开发日常最有意思的部分。