2024移动应用开发赛项02卷拆解：八个任务背后的真实行业需求

简介：2024年全国职业院校技能大赛移动应用开发赛题全面解析，是一份面向职业院校参赛选手、指导教师及移动应用开发学习者的PDF文档。资源围绕移动应用设计与开发赛项，系统拆解了产品原型设计、移动应用开发、应用部署测试三大模块，分别对应25分、50分、25分，合计8小时100分。产品原型设计模块要求针对车主手机App、中控大屏移动终端、智能充电家用版App和商用版小程序等场景，编制需求规格说明书并绘制高保真原型；移动应用开发模块侧重跨平台编码实现，强调设计规范、交互功能与稳定性；应用部署测试模块则要求提交经过测试优化的成品，包括代码、文档、需求规格说明书及原型设计文件，并完成服务器部署与可靠性验证。文档还详细列出了界面尺寸、分辨率、命名规范、成果物提交方式及竞赛注意事项，覆盖了从需求分析到部署测试的全周期流程，尤其是中控大屏仪表盘、360度全景影像等具体任务细节，能帮助选手提前熟悉真实赛题难度。资源包为1个PDF文件，大小仅528KB，内容精炼且重点突出。目前已有1790人学习下载，适合备赛冲刺、赛项讲解或移动应用开发课程实训使用，可快速掌握赛题结构、评分要点和易错细节。

1. 为什么 2024 移动应用开发赛项值得按 02 卷拆一遍:八个任务背后的真实行业需求

全国职业院校技能大赛移动应用开发赛项，表面看是 8 小时、100 分的比赛，实际拆完 02 卷你会发现，它几乎是当前车载与充电场景移动应用开发岗位的完整能力画像。整卷围绕「车主手机 App + 中控大屏(仪表/主屏/副屏)+ 智能充电家用版 + 商用小程序」四个端展开，涵盖了产品原型设计、跨端应用开发、部署测试三个模块，25 + 50 + 25 的分值分配决定了备考策略不能只堆代码。这份资源能帮你解决三个问题:第一，8 小时的时间如何分配到三个模块而不翻车;第二，每个任务背后考察的到底是原型能力、编码能力还是测试思维;第三，从需求文档到可交付 Apk/Hap 再到 Postman 自动化脚本，完整流程里最容易丢分的细节在哪里。适合正在备赛的选手、带赛的指导老师，以及想用赛题当练手项目的移动开发者。

2. 模块一其实考的是「需求理解 + 高保真表达」:原型设计怎么规划才能拿满 25 分

2.1 需求规格说明书:不只是写文档,是给开发模块铺路

模块一的前 2 小时要求选手基于给定的「需求规格说明书(模板).docx」完成需求分析,并绘制用例图、流程图/活动图、时序图和模块概要设计说明。很多选手容易把这段时间全砸在画原型上,导致文档草草了事。实际上,模块二的 8 个开发任务完全对应模块一的 6 个原型任务,文档里定义的页面结构、交互流程、状态切换,直接决定后面 4 小时写代码时脑子里有没有一张清晰的页面状态图。

用例图建议按角色拆:车主、充电用户、后台管理员分别对应哪些用例;时序图重点画「充电枪插入 → 车辆 P 档 → 开始充电 → 数据同步」这条主链路,因为它是模块二任务 6 的核心;流程图则要把「车辆档位切换」和「360 度全景 App 自动退出」这类异常分支画进去,这是评分时容易被忽略的隐藏考点。

2.2 原型尺寸与画板规范:四套分辨率背后的适配逻辑

02 卷给出了非常具体的尺寸表,这不是随意写的,它直接对应模块二开发时的适配要求。需要注意,中控大屏一套系统要同时适配 1920×720 和 1920×1080 两种分辨率,这要求原型阶段就必须考虑不同屏幕比例下的布局伸缩。

原型阶段如果画板尺寸不按这个标准建,评审第一眼就会觉得不专业。另一个容易扣分的点是滚动区域——内容超出高度时必须明确设置滚动区域,而不是把内容硬塞进一屏。这个要求在模块一任务 2 中反复出现,尤其是车辆信息 7 个卡片模块,信息量很大,必须滚动。画板对齐和样式复用同样要重视、「一种功能两种样式」在评分表里属于明显的交互设计缺陷。

2.3 六大原型任务的交互设计要点:从静态图到动态交互

任务 1「右转向视频显示」的核心是 360 度全景界面,影像区占 80% 高度、功能区占 20%,影像区左侧右转向视频加绿色辅助线,右侧是四方向摄像头拼接。做原型时「专注」按钮的上拉列表(前/后/左/右/360 度)必须能真实切换影像区域内容,这需要用到 Axure 的动态面板或 XD 的组件状态。

任务 2「车辆信息」是模块一里页面最多、状态最复杂的任务,仪表屏(转数表+时速表+中间车辆信息)和主屏的 7 个卡片模块(基本信息、电动机信息、电池信息、车身信息、底盘/转向、车轮/制动、胎压监测)都要逐一绘制。这里建议先做主界面卡片,再做每个卡片的二级页面,返回按钮的跳转逻辑要用交互连线在原型里真实连起来,只画静态图会丢交互分。

任务 3「多媒体播放器」的交互亮点在「选择主屏或副屏播放」这个弹窗,以及播放器工具栏的快进/快退/暂停/其他视频。原型阶段要模拟出「点击视频卡片 → 弹出选择框 → 选择后跳转播放页」的完整链路,其他视频的弹层列表也要可点击切换。

任务 4「天气」要求主屏和副屏联动,这是一个典型的跨组件通信场景。原型里城市切换要同时更新两块屏幕的数据,必须用全局变量或中继器来实现,这也是评审关注的重点交互。

任务 5「一键启动」和任务 6「智能充电」都涉及车辆 3D 模型的展示与手势交互,原型阶段用占位图模拟即可,重点是把车辆信息和功能按钮的布局层级做清楚,充电状态从「待充电」到「充电中」的切换要有明显的状态变化。

2.4 交付物命名与打包:这 5 分不能丢

模块一的交付物是「需求规格说明书.docx」和「产品原型.rp」或「产品原型.xd」,最后压缩成「产品原型设计.zip」提交。这里有一个隐藏红线:压缩包、文档、原型里都不能出现工位号、姓名、院校信息,否则该模块按零分处理。建议建立固定命名习惯,比如统一用「需求规格说明书.docx」「产品原型.rp」,不添加任何前后缀,从源头杜绝标记问题。

3. 模块二的技术实现:四个端八个任务,代码能力与跨端协作缺一不可

3.1 技术栈选型:从赛题措辞反推官方倾向

02 卷要求交付 CarOwners.apk、DIC.apk、IVIZTaskX.apk、IVIFTaskX.apk、Charge.hap 和 dist2 小程序目录。Android 端三个 Apk、鸿蒙一个 Hap、小程序一个目录,加上赛题描述里反复出现「移动跨平台应用开发生态系统」,可以判断出官方期望的是一套支持 Android、鸿蒙、小程序的跨端方案。

从赛题措辞看,Flutter 是比较稳妥的选择,因为:

• CarOwners.apk 和 DIC.apk 是 Android,Charge.hap 是鸿蒙,Flutter 3.x 的鸿蒙支持已经能直接构建 Hap 包
• 小程序端虽然 Flutter 不能直接输出,但代码逻辑可以复用,只需重写 UI 层
• 赛题所有界面都是标准卡片+列表结构,Flutter 的 Widget 组合能快速匹配

如果你所在的团队更熟悉 uni-app,同样可行,但要注意鸿蒙 Hap 的构建链是否配置完整,这直接关系到交付物能否编译通过。建议备赛阶段就把 Android SDK、鸿蒙 SDK、Flutter 版本锁定,不要在比赛当天升级依赖。

3.2 360 度全景与档位联动(任务 1):布局比例和状态机是考点

任务 1 要求中控大屏主屏在左转向时显示 360 度全景页面,影像区占 80% 高度、功能区占 10%,并且仪表盘要实时显示档位标识。影像区左侧是左摄像头视频流,右侧是四方向梯形拼接的全景。

布局实现的关键是比例控制,我一般会用 Column + Expanded flex 来做:

Column( children: [ Expanded( flex: 8, child: Row( children: [ Expanded(flex: 1, child: _LeftCameraView()), // 左侧摄像头 Expanded(flex: 1, child: _PanoramaView()), // 右侧360拼接 ], ), ), Expanded( flex: 1, child: _BottomToolbar(), // 专注 + 关闭 ), ], )

这里 flex 8:1 对应赛题「影像区占屏幕高度 80%,功能区分 10%」的硬性要求,剩下 10% 留给状态栏等系统元素。逻辑说明:_LeftCameraView 和 _PanoramaView 只是两个占位容器,实际开发时分别承载视频流 Widget 和 Canvas 绘制的拼接画面;参数说明:flex 比例必须写成 8:1,不能写成 4:1,否则高度比例不满足评分标准。

档位联动的核心是状态管理,推荐用 ChangeNotifier 或 Stream 监听车辆档位变化:

enum Gear { P, R, N, D, L } class GearService extends ChangeNotifier { Gear _currentGear = Gear.P; Gear get currentGear => _currentGear; void updateGear(Gear gear) { _currentGear = gear; notifyListeners(); } }

逻辑说明:当档位从非 D 档切回 D 档以外的其他档位时,360 度全景 App 要自动退出。可以用 addListener 监听 GearService,在回调里判断当前档位并执行 Navigator.pop;参数说明:档位枚举要和模拟器/CAN 通讯协议里的档位标识保持一致,否则会出现仪表盘显示和实际档位不一致的 bug。

仪表盘档位标识是任务 1 的第三个得分点,不要只做主屏的 360 度画面而忘记仪表屏的档位显示。仪表屏分辨率是 1920×720,宽扁布局,档位文字建议放大居中显示,使用高对比度配色。

3.3 车辆信息与保养卡片(任务 2):轮播图组件和数据驱动

任务 2 的难点在「仪表屏中间显示卡片式轮播图,自动切换」,卡片内容是保养信息(当前公里数、车辆图片、距下次保养剩余公里数、电池状态)。这里的关键是自动轮播 + 手动滑动的双模切换,Flutter 里用 PageView.builder + Timer 即可实现。

PageView.builder( controller: _pageController, itemCount: _cardList.length, onPageChanged: (index) => _currentIndex = index, itemBuilder: (context, index) { return _MaintenanceCard(data: _cardList[index]); }, ) Timer.periodic(Duration(seconds: 3), (timer) { if (_pageController.hasClients) { _pageController.nextPage( duration: Duration(milliseconds: 400), curve: Curves.easeInOut, ); } });

逻辑说明:轮播图每 3 秒自动滑到下一张,循环尾部时 need to 回到第一张,需要在 Timer 回调里判断当前页码并做取模或重置;参数说明:Duration(seconds: 3) 是轮播间隔,选手可以改但不要低于 2 秒,否则卡片文字还没读完就切走了。电池状态里「健康度大于 75% 显健康,小于 75% 显不健康」是一个典型的条件渲染,用三元表达式即可,但要注意 75% 这个阈值是硬性要求,不能自己改成 80%。

3.4 多媒体播放器(任务 3):双屏播放的架构考验

这个任务最考验架构设计,因为「主屏、副屏同时播放」和「仅副屏播放」涉及两个独立屏幕。中控大屏其实是三块物理屏幕(仪表屏、主屏、副屏),每块屏幕对应一个独立 Activity 或 Flutter 入口。主屏和副屏同时播放视频时,如果用两个独立的视频播放器实例,会出现声音冲突和进度不同步的问题。

常见做法是采用「一个播放引擎 + 两个渲染视图」的方案,比如使用 media_kit 或 video_player 的 MultiPlayer 模式:

final _videoPlayerController = VideoPlayerController.file(videoFile); // 主屏渲染 _playbackView = VideoPlayer(_videoPlayerController); // 副屏通过 Texture 共享同一 controller 的 textureId

逻辑说明:同一时间只有一个活跃的播放控制器,副屏渲染层通过监听主屏的 textureId 来同步画面;参数说明:「仅副屏播放」模式下主屏要退出播放器,这里需要将 controller 的 listener 解绑,避免主屏已经被别的页面覆盖时视频还在播放。

「上次看到 xx 分 xx 秒」的断点续播功能,需要在视频暂停或退出时写入本地存储,建议用 SharedPreferences 保存 map 结构:

void _savePlaybackProgress(String videoId, Duration position) { final prefs = await SharedPreferences.getInstance(); prefs.setInt('video_$videoId', position.inSeconds); }

逻辑说明:视频卡片列表的数据模型里加一个 lastPosition 字段,每次进入主页时读取;参数说明:视频列表建议放在 assets 目录下,用 FileSystem 遍历,不要硬编码路径。

3.5 天气分屏联动(任务 4):双屏数据同步的通信机制

主屏选择城市,副屏天气同步变化,这需要跨页面通信。两套入口在一个应用里,可以用全局状态管理来广播数据:

class WeatherStore extends ChangeNotifier { String _selectedCity = '北京'; WeatherData? _data; void selectCity(String city) { _selectedCity = city; notifyListeners(); // 订阅了此 store 的主屏和副屏都会收到通知 } }

主屏天气页和副屏天气页都依赖同一个 WeatherStore 实例,城市切换后两处 UI 同步刷新。这里要注意一个问题:副屏的分辨率也是 1920×1080,但它的布局是「顶部七天日期、中部温度范围、底部天气状态」三段式,不能直接复用主屏布局。

3.6 车主 App 远程控制(任务 5):多终端间的状态同步

任务 5 的逻辑链是中控大屏点「一键关机」→ 三屏熄灭 → 车主 App 点「启动」→ 三屏唤醒。这中间的核心是远程控制指令的传递。赛题环境里没有真实的云端服务器,常见做法是设备间用本地网络通信,比如通过 MQTT broker 或 WebSocket 广播指令。

void _sendCommand(String command) { final client = MqttClient('192.168.x.x', 'car_control'); client.connect(); client.publishMessage('car/display/power', MqttQos.exactlyOnce, command); }

逻辑说明:中控大屏和车主 App 连接到同一个局域网 MQTT 服务,车主 App 发布「启动」指令,中控大屏订阅后执行开机逻辑;参数说明:QoS 必须用 exactlyOnce,防止指令重发导致屏幕闪断。如果现场没有 MQTT broker,也可以用 WebSocket + JSON 消息模拟,但实时性会差一些。

3.7 智能充电家用版与数据同步(任务 6):CAN 通讯的模拟处理

任务 6 在充电桩插入时触发状态变化,涉及 CAN 通讯,比赛现场会有充电模拟器。开发者拿到的不是真实 CAN 帧,而是一个模拟数据源。处理方式一般有两种:模拟器提供 Socket 接口,选手写 TCP 客户端去读;模拟器通过串口发送数据,选手用串口库解析。

根据赛题的「基于 Can 通讯」描述,现场更可能是提供局域网接口:

# 伪代码,比赛中用 Dart/Java 实现同样的逻辑 import socket s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.connect(('192.168.1.100', 6000)) data = s.recv(1024) # data 中包含充电状态、电压、电流、SOC 等字段,按协议解析

参数说明:协议字段名要和赛题给定的一致,通常是 JSON 格式,字段类似 {"status": "charging", "power": 7.2, "soc": 56}。解析后同步给其他终端,也就是任务 6 的第 4 点要求——充电数据同步到车主手机 App、中控、后台管理系统。这本质是和任务 5 一样的跨端通信问题,但数据结构更复杂,需要确保四个端解析同一份 JSON 时字段对得上。

3.8 用户中心与数据分析(任务 7、8):登录流程和数据可视化的常规操作

任务 7 的登录四模块(免密/密码/忘记密码/注册)比较常规,但要注意验证码的逻辑——免密登录输手机号获取验证码,注册也输验证码,这两套验证码要区分开,否则评委检查时会认为逻辑混乱。

任务 8 是数据分析,要求柱状图展示 2023 年 2 月、6 月充电桩充电时长和耗电量,饼状图展示下半年收益。小程序端用 ECharts 的 ec-canvas 组件即可:

const option = { xAxis: { type: 'category', data: ['2月', '6月'] }, yAxis: { type: 'value', name: '每小时耗电量' }, series: [{ type: 'bar', data: [dataList.feb, dataList.jun] }] };

逻辑说明:数据要从后台 API 获取,赛题会给 mock 数据接口或者 Excel 数据导入;参数说明:横坐标日期、纵坐标每小时耗电量是硬性要求,不能改成「充电次数」之类。饼状图的「收益 = 订单收入总金额 - 耗电成本 - 服务费」要在代码里体现计算逻辑,而不是直接前端硬编码三个数值。

4. 模块三的 25 分里,测试用例和 Postman 自动化才是拉分关键

4.1 测试用例:15 条起的底线,不是凑数量

模块三任务 1 要求智能充电商用版小程序至少 15 个测试用例,家用版 App 至少 15 个,一共至少 30 条。评分不仅看数量,更看用例格式是否规范、是否覆盖主流程和异常流程。

一条用例省事的写法是把「操作步骤」写在一个单元格里用换行分隔,但扣分风险高,建议每条用例拆成多行步骤。覆盖率方面,充电桩列表、充电状态切换、订单支付、个人中心这四条主线务必覆盖,再补异常路径,比如弱网环境下充电状态不更新、重复点击开始充电按钮等。

4.2 缺陷分析:从「功能未开发」到「根因分析」的写法

赛题要求找出 10 个 Bug 填写缺陷分析,表 3 给的样例是「点击首页可查看附近充电桩列表,首页无列表显示」,原因写了「功能未开发」和「未连接网络导致数据请求失败」两条。这里有个容易被忽略的得分点:缺陷重现步骤必须写清楚前置条件和操作路径,不能只写「页面不显示」。另外一个更聪明的做法是,结合模块二开发时自己埋的雷,比如充电状态切换到「充电中」后,仪表盘数据没有同步——这种跨端 bug 在评分时更受认可,因为它体现了测试设计的全局观。

4.3 Postman API 自动化:集合变量可以替代手工填参

任务 2 要求用 Postman 做 API 自动化测试并导出 Api.json。Postman 自动化最常见的场景是登录接口拿 Token,然后携带 Token 去请求其他接口。这里的关键是使用集合变量,不要在每个请求里硬编码 Token:

{ "collection": { "info": { "name": "充电系统API测试", "schema": "https://schema.getpostman.com/json/collection/v2.1.0/collection.json" }, "variable": [ { "key": "baseUrl", "value": "http://192.168.1.100:8080" }, { "key": "token", "value": "" } ], "item": [ { "name": "用户登录", "request": { "url": "{{baseUrl}}/api/login", "method": "POST", "body": { "mode": "raw", "raw": "{\"phone\":\"13800000000\",\"code\":\"123456\"}" } }, "event": [ { "listen": "test", "script": { "exec": [ "const res = pm.response.json();", "pm.collectionVariables.set('token', res.data.token);" ] } } ] } ] } }

逻辑说明:登录接口的 Test 脚本把响应中的 token 写入集合变量,后续请求在 Headers 里引用 {{token}} 即可;参数说明:baseUrl 通过集合变量配置,好处是评委检查 Api.json 时能看到这是一个维护良好的脚本,而不是写死的 IP。注意导出时要选「Collection v2.1」格式,这是最通用的版本。

4.4 产品操作手册:三段式结构的得分技巧

产品操作手册是模块三的第三个交付物,规范明确要求写三部分:产品定位与核心功能点+运行环境、功能操作指导、常规注意事项。最难的是第二部分,要把每个功能的操作步骤写具体,「准确叙述用户操作行为」。常见的做法是配合截图,但比赛时间紧,可以用「步骤 + 预期反馈」的描述式写法,例如:「点击首页底部导航栏『数据分析』,进入数据分析页面,页面默认展示柱状图与饼状图」——这种描述比「查看数据分析」四个字得分高得多。

5. 避坑:四个最容易翻车的细节,赛前至少要排掉三条

5.1 交付物命名与个人信息泄漏

现象:提交的压缩包或文档内出现工位号、姓名、院校信息,模块判零分。

原因:选手习惯性地把文件命名为「张三_产品原型.rp」,或者往需求文档页眉加了院校模板。

解决:比赛一开始就建立「裸命名」习惯,所有文件一律按赛题要求命名,不添加任何前缀后缀;原型页面内的画板名称也不要用个人信息,建议统一用「01_首页」「02_车辆信息」这种编号。

5.2 鸿蒙 Hap 包构建失败,卡在最后提交节点

现象:Charge.hap 在编译阶段报错,折腾半个多小时无法生成交付物。

原因:鸿蒙 SDK 和 Flutter 鸿蒙分支的版本不匹配,或者 DevEco Studio 的签名配置没做好,常见的错误是 targetSdkVersion 不支持当前构建链。

解决:备赛阶段就把鸿蒙 SDK 和 Flutter 版本锁死,不要用最新版;同时提前在虚机上验证一次完整构建流程,确保 Charge.hap 能稳定产出。比赛开始后,开发环境不要做任何升级操作。

5.3 多屏视频播放不同步,被判定功能异常

现象:主屏和副屏同时播放时,画面延迟达 1 秒以上,评委判定「播放不同步」。

原因:两个播放器实例各自独立解码,走了两条视频处理链路。

解决:用单一播放引擎 + 多渲染视图的方案,或者退一步,副屏延迟初始化播放器,等待主屏缓冲完成后同步启动。比赛现场网络和虚拟设备性能不稳定,哪怕方案原理正确,也建议预留 15 分钟专门做同步调试。

5.4 充电状态同步到其他终端丢字段

现象:车主 App 能看到充电功率,但小程序端功率总是显示 0。

原因:各端解析 JSON 时字段名不一致,比如一处用 currentPower,另一处用 power。

解决:接口返回数据结构在开发前就定成一份共享 JSON Schema,四个端严格对照字段名解析;调试时打开网络代理查看原始报文,先确认字段存在,再查解析逻辑。

6. 把 02 卷从试题变成训练场:一周备赛的冲刺清单

6.1 性价比排序:先保模块一和模块三,再攻模块二难点

从分值结构看,原型设计 25 分 + 测试部署 25 分,这两块共占一半分数,且对编码能力要求相对低,是基础薄弱选手的保命地盘。建议前三天专门训练原型和文档编写,重点把 6 个原型任务全部练完,达到能在 2 小时内完成 4 个以上任务的水准;最后一天再专攻 Postman 脚本和测试用例模板。

模块二 50 分虽然权重最高,但 8 个任务全部做完几乎不可能,除非是全能型选手。务实的策略是:任务 1、2、4、8 是性价比最高的四个,布局和列表都是模板化工作,半天能出一个任务;任务 3 和任务 6 涉及多端通信,留到有余力时再做;任务 5 和任务 7 是纯逻辑,中等难度,放在中间时段处理。

6.2 快速验证的清单:三个命令在每轮模拟后强制跑一遍

模拟比赛结束时,我习惯把下面这套验证流程完整走一遍,确保交付物不会在最后时刻翻车:

# 1. 检查各端构建产物是否存在 ls -lh CarOwners.apk DIC.apk IVIZTaskX.apk IVIFTaskX.apk Charge.hap # 2. 确认压缩包结构完整,不包含个人信息 unzip -l 移动应用开发.zip # 3. 检查 dist2 小程序目录是否包含构建产物 find dist2 -name "*.js" | head -20

逻辑说明:第一条命令确认所有交付物已经编译完成,第二条检查压缩包内文件清单是否与赛题要求一致,第三条确认小程序目录已包含编译后的代码;参数说明:如果你用 Flutter 构建,Apk 输出目录是 build/app/outputs/flutter-apk/,鸿蒙是 build/hap/,小程序是 npm run build 后的 dist 目录。这里有一个很多人翻车的点——比赛结束后再补构建,时间根本不够,所以最后一小时只做验证和修正,不再写新功能。

6.3 用「文字稿原型」代替反复改图:一个节省时间的沟通技巧

原型设计阶段大量时间消耗在改图上,但比赛只有 2 小时。我在带队训练时总结了一个方法:动手画原型前,先用文字把每个页面的元素和跳转关系写出来,列成清单,确认无误再开画板。这种做法能把返工率降低一半以上,因为大多数改图是因为界面结构没想清楚,而不是画得不好。

举个例子,任务 3 多媒体播放器的页面关系如果用文字稿描述就是:

1. 主界面:视频卡片列表(预览图 + 视频名 + 上次看到进度)
2. 点击卡片 → 弹出选择框(主屏副屏同时播放 / 仅副屏播放)
3. 选择后 → 播放页(整屏视频,点击视频显示返回按钮)
4. 播放页工具栏:快进 / 快退 / 暂停 / 其他视频 → 弹层列表 → 切换视频

把这四行字写好,再打开 Axure 或 XD,头脑里已经有清晰的交互结构,画起来一气呵成。

6.4 最后 30 分钟的核对顺序

比赛结束前 30 分钟,我会按固定顺序核对三件事:第一是模块一的压缩包是否包含 docx 和 rp/xd 两个文件,文件名是否符合要求;第二是模块二四个端构建产物是否齐全,Apk、Hap、小程序 dist 目录是否真实存在;第三是模块三的四个交付物(测试用例.xlsx、缺陷分析.docx、Api.json、产品操作手册.docx)是否都塞进了压缩包。

这个核对顺序是基于 8 小时比赛的节奏设计的:原型和开发在时间压力下容易漏文件,测试文档由于是最后写的,反而是最容易补齐的。从第一次模拟赛到现在,我每次带队都强制走一遍这个流程,最深的教训是——压缩包里少一个文件,扣分远比「某个功能没做好」来得狠。希望这份拆解能帮你在备赛时把精力花在真正能拿分的地方,少走我走过的弯路。

本文还有配套的精品资源，点击获取