手机横放，两个人隔着屏幕下棋；平板放到桌上，棋盘和工具各就各位；来到电脑前，双人24点又有了各自的键盘操作区。同一款《拼棋派对》，终于开始适应不同设备上的玩法。

这次让我印象最深的，是HarmonyOS开发助手能把这些具体想法接到已有工程里：读相关代码、找布局分支、提出改法，再沿着反馈继续实现。对一个已经有15种玩法的项目，这种连续协作很实用。需求越接近玩家的真实动作，助手越容易把它变成可落地的代码。

先看一个最直接的变化：同一台电脑、同一个默认窗口，棋盘终于和双方状态、操作按钮组成了一张完整的游戏桌。

优化后：棋盘右侧集中展示双方信息与等大的工具按钮。

我参考官网多设备适配案例的组织方式，把每次改动放回具体设备和页面：哪一块被挤走了，怎样向助手描述，改后能完成什么操作。下面会依次走过安装、真实对话、折叠屏修复和三端使用体验。

我选择了双人象棋和双人24点作为代表：一个关注棋盘、工具和对局连续性，一个关注触控与双人键盘。围绕这两种玩法使用“一多适配”，让我更直观地感受到开发助手的价值——它可以进入现有项目，把一个体验问题拆成具体修改，再跟着实际反馈逐步完善。

整个过程围绕九个阶段持续推进：先分析已有工程，再限定页面修改，把设备上发现的新问题带回同一工程上下文，继续修正。接下来，从安装助手开始，看看几次关键反馈如何改变实际体验。

在DevEco里接上助手，从一个真实问题开始

本次环境是DevEco Studio 26.0.0.621、HarmonyOS Dev Assistant 0.1.70，所选模型为DeepSeek V4 Pro。手机、三折叠、平板和PC使用API26模拟器；工程在插件介入前已迁移到target API26。

安装过程可以直接照着走。我先按官方安装指南打开插件市场，下载插件ZIP，在DevEco的“设置→插件→齿轮→从磁盘安装”中选中文件。活动使用的是独立的HarmonyOS Dev Assistant，插件ID为com.harmonybot.ide.deveco，安装时核对名称就容易找到。

实际安装界面。本机完成工程信任后加载插件，随后进入右侧助手面板。

登录华为账号后，还需要完成模型配置。我在“插件设置→模型”中配置并启用模型，再回到输入框选择“一多适配”和DeepSeek V4 Pro。模型设置可参考官方配置指南。

模型配置完成

发送第一条“一多适配”任务

从模型配置到第一次输入，都在开发环境内完成。

官网给出的输入方式很实用：把适配范围、适配项目、目标设备一起说清楚，可以覆盖整个工程，也可以只指定页面或目录。复杂调整还可先要求高保真预览，再检查方案和Diff。对已有项目，我更喜欢先圈定页面和必须保留的交互。

第一条任务，我先交代项目和使用场景，再约定如何验证。下面是实际输入的压缩摘录：

请先分析现有工程，不修改代码。重点看三折叠单屏、双屏、三屏和平板横竖屏的棋盘尺寸、操作区、文字和热区。折叠或旋转只调整排版，保留对局、分数、计时和已选棋子。按问题、对应代码、影响窗口、建议修改和验收步骤给出结果。

助手分析了修改范围、相关组件与验收步骤。

我先选大厅标签残影打通流程。助手定位到CategoryLabel的透明背景，修改后重新构建、安装并检查点击。这个小起点很有帮助：问题、代码和验证被串了起来，后面的棋盘适配就可以沿用同样的方法，不必每轮重新介绍整个项目。

我继续限定第一步 · 原文节选

这一轮先验证“不再透出旧字”，不把“改成不透明”直接等同于“色块边界完全消失”，后者由截图复核。

助手交回可核对的改动 · 原文节选

本轮只交付“覆盖层已不透明、不再透出底图旧字”这一前提，不把“改成不透明”等同于“色块边界完全消失”。

第一轮没有急着铺开所有页面。让助手先改一处、跑一次构建，再回设备确认，后面的长任务就有了共同的验收尺度。

让“不大不小”的折叠窗口，也能完整下一盘棋

多端适配的细节，常常藏在中间尺寸里。三折叠双屏既不像窄手机，也不是充分展开的大屏。这个项目在双屏下仍上下排布，却让棋盘按宽度扩张，底部状态和工具便没有足够位置。

修改前的双屏象棋：棋盘和其他区域没有共同分配可用高度。

修改后：完整棋盘、双方状态和悔棋／重开／提示／认输同时进入首屏。

我把实际窗口尺寸和现象交给助手，要求完整棋盘、双方状态与必要操作一起进入首屏。它在Index.ets中增加了中间尺寸判断：

private isBoardMidLayout(): boolean {
  return !this.isDesktopDevice() && this.isLargeScreen() && !this.isWide();
}

再将象棋尺寸改为先扣除其他区域所需高度、保持棋盘比例。首轮diff中的计算是：

const boardHeight = Math.max(280,
  Math.min(400, Math.floor(this.viewportHeight - 380)));
return Math.floor(boardHeight * 0.864);

这些数字属于当时的局部方案，后续又按玩家栏和短横屏调整。真正值得借鉴的是方法：先给操作和信息留位置，再把剩余空间交给棋盘。 助手把这一思路落实到具体分支，已有棋规和状态逻辑得以继续复用。

首轮把棋盘收进来了，但跳棋的6/8/10子入口消失了。我没有用“看起来不错”结束这一轮，而是把操作上的损失原样反馈回去：

我在设备检查后反馈 · 原文节选

不接受把CheckersLevelPanel当成非必要功能直接隐藏。请恢复6/8/10子切换且保持中间态首屏：可在isBoardMidLayout棋盘旁边复用既有CheckersLandscapeLevelPanel（纵列三档），其余高度和棋盘宽不变；双屏约680vp内容宽，354vp棋盘旁有空间放120~140vp侧列。

助手第二轮回复 · 原文节选

1. 新增 CheckersMidLevelColumn()（:2708）：132vp 侧列，标题 ${checkersPieceCount(level)}子 · ${checkersLevelLabel()}（当前棋子数 + 难度），内嵌既有 CheckersLandscapeLevelPanel()（纵列 6子入门/8子标准/10子进阶，选中态高亮）。

这一来一回，助手把原有难度组件放进了棋盘旁的空间，而五子棋工具栏另多留了16vp余量。最有用的地方是反馈可以精确追加：保留已通过的象棋，只处理这一轮暴露的两处问题。

第二轮修正：复用原有难度组件，重新分配棋盘与工具栏空间。

重新装到设备上，象棋可以走兵，跳棋能切换6/8/10子并落子，必要工具也回到首屏。对我来说，这正是“一多适配”适合已有项目的地方：围绕当前组件做有范围的修改，让已完成的功能继续发挥作用。

棋盘放下了，按钮和比分也要跟得上这一手

真正开始走棋，又出现了截图里不容易发现的事：上方已经轮到B，底部按钮却还写着A。收拢一次屏幕，文字才更新。多端适配如果只看初始页面，就会漏掉玩家真正使用时的这一层。

我描述操作顺序 · 原文节选

五子棋A确认落子后回合和两侧控件都变成B，但底部绿色主按钮仍“玩家A确认”；折叠重建才刷新。跳棋A落子后状态“第2手 · 6子 · 玩家B先选子”，底部仍“玩家A走棋”。

助手检查了按钮参数与状态的传递方式，把本项目中依赖动态状态的按钮改为直接读取对应状态，保留原有点击逻辑。大厅轮播的“开始”入口也一起处理，让显示名称与真正打开的玩法保持一致。

助手说明大厅入口的处理 · 原文节选

PixelLockedLobby.ets：新增 StartHitbox()（:178），Button 文字与 accessibilityText 均直接引用 this.carouselTitle（响应式）；:36 改为 this.StartHitbox()。其余 Hitbox 与轮播逻辑不变，未冻结轮播。

动态按钮与大厅入口名称一起更新。

设备回看时，五子棋A落子后按钮立即变为B，B落子后又回到A；认输、重开也能跟着变化。这让我更愿意把下一步交给它：不只是一个页面看起来正确，连同一问题在其他入口的表现也一起追查。

我继续追问共享状态 · 原文节选

请分析并实际修复这类相同原因，不再只补当前一个按钮。重点检查Index的PageTitle(title,subtitle)、MathScoreStrip内统计调用、StatStrip与其他共享统计/状态Builder、ToolButton的动态label/badge，以及其下游组件属性。归纳哪些调用是静态无需改，哪些依赖状态必须响应。

这次反馈来自平板上的十道真实算术题：题目已经往下走，页头仍停在第1题；再来一局后，上一局的5:5也还挂着。助手沿着共享组件检查调用点，处理动态页头、统计和工具状态。过程中第一次构建暴露了漏掉的复用调用，它补齐后重新构建通过。

助手补齐共享组件调用，修复页头、比分与题号的刷新。

随后平板十题的玩家、比分和题号逐项核对通过，重开回到0:0、第1题。换到电脑检查反应抢点时，计分卡还有一处遗漏，我再次补上具体证据：

我补充电脑上的新现象 · 原文节选

页头已是“入门关 · 第 2/8 轮”，notice为“玩家A 抢到第 1 轮”，两个计分卡仍为0分。全程未重进页面、未切屏。

助手针对遗漏继续修改 · 原文节选

1. 反应计分：新增 ReactionScoreCard(player, color)（:5993），value 直接引用 this.reactionScoreA/B；替换 ReactionTapPage 两处 SummaryCard（:3213/3214）。

复测终于对应上了：A抢到第一轮，卡片立即是1:0；双方交替完成八轮，结果为4:4；重开回到0:0。这样的多轮协作，比一句“已修复统计问题”更能体现助手的用途——我带回一个可复现现象，它继续定位到具体调用，再交回可以验证的变化。

手机对坐，电脑并肩：把玩家的姿势写进布局

屏幕同样是横的，使用方式却可能不同。手机和平板可以平放在两人之间，电脑通常立在面前。把这个区别讲清楚后，开发助手的任务也更明确了：设备决定默认就座方式，窗口决定排版，玩家选择决定朝向。

我先让它增加“设备默认、面对面、同向”设置，再针对象棋和双人24点细化：移动设备默认上下对坐，对侧区域旋转180°；PC保持同向阅读，24点A在左、B在右，和键盘区域一致。

新增设备默认、面对面与同向三种就座方式。

我把使用方式写成约束 · 原文节选

本批主要目标：设备身份决定默认就座、窗口宽高只决定排版、用户就座选择决定朝向。

助手补齐横向分支 · 原文节选

ChineseChessLandscapePlayerPanel 新增 .rotate({ angle: owner === 'B' && this.isFaceToFaceSeat() ? 180 : 0 })，与竖屏 ChineseChessPlayerPanel 的 inverted 分支一致；红方(A/R)与棋盘方向不变。

这里也经历了第二轮：有了设置开关，还要逐个核对横向、竖向组件是否都接入同一朝向规则。助手把实际生效区域列出来，便于继续对照设备检查；后续两个代表玩法再按手机对坐、电脑并肩细化。

同一个象棋初局，换到三种设备后，可以直接看到玩家区和操作区怎样重排。

手机·单屏横放

黑方条在棋盘上方、红方条在下方，说明与工具利用两侧空间。

平板·横屏对坐

黑方在上、红方在下；工具紧邻棋盘，对侧信息与棋子朝向对面的玩家。

PC·默认窗口

棋盘在左，双方状态与四个等大的工具集中在右侧，文字同向阅读。

同一象棋页面：手机和平板上下对坐，电脑同向操作。

第一版：位置改对，操作仍被挤走

最终版：上下玩家区与操作完整显示

同一手机短横屏的阶段版与R14：双方位置、标题与必要操作逐步安排完整。

短横屏的高度尤其宝贵。我把“从页面外壳一起计算高度、去掉重复标题、每个玩家内部牌面与操作并排”补充到同一会话，助手随后移除了重复标题、压紧操作行并调整棋盘预算。连续反馈的好处在这里很明显：已有需求仍在上下文中，下一轮可以直接讨论新增差异。

最终，两个触控玩家各有朝向自己的操作区域；来到电脑，两边内容又都正向显示。这种按使用姿势安排页面的变化，比单纯放大控件更能让人感受到多端适配。

手机横放·上下对坐

平板横屏·上下对坐

电脑·左右同向

同一个双人24点页面：手机与平板上下对坐，电脑左右同向。

让两个人真正用起来：触控之外，再接上两套键位

我很喜欢这次PC双人24点的改进。它原本已有左右按钮，但两位玩家共用一个鼠标，仍然要轮流操作。于是我把“各自有独立输入”交给助手，并把要求写到具体按键：

仅在PC双人24点启用。A用1/2/3/4选牌、Q/W/E/R运算，F提交、G撤销、T清空；B用7/8/9/0选牌、U/I/O/P运算，J提交、K撤销、Y清空。复用现有函数和计分规则，页面保留完整键位说明。

助手交回输入分流方案 · 原文节选

• 严格按 activeMode 分流：number2048 只认方向键/WASD，reactionTap 只认 F/J，duel24 仅在 isDesktopDevice() 下认 A/B 键位。

键盘接上以后，我没有只按一次提交就结束检查：双方实际完成六题打成3:3，反应抢点也补测F/J、组合键和长按。随后，“切到桌面再回来”这一步又带回了新的问题。

我继续提交复现步骤 · 原文节选

出现一个待诊断问题：PC反应抢点第3/8轮时按住F，进入第4轮；用HOME回桌面，在后台松F，再用aa start恢复EntryAbility，按F两次都仍停在第4轮。

助手依据布局树诊断 · 原文节选

恢复后根组件 focused:"false"（start 时是 true），键盘事件无法到达 onKeyEvent。同时后台松 F 时 KeyUp 丢失导致 heldKeyCodes 可能残留。修复分两层：窗口失焦/激活信号 + 焦点恢复。

它为窗口失焦与重新激活补上状态清理和焦点恢复，正式构建通过。后续模拟器复测中，按住F、回桌面、后台松键、再回应用后，按F能从第5轮推进第6轮。这里验证的是模拟器上的恢复路径，实体键盘并键能力仍另作边界。需求从“支持键盘”走到“切走再回来还能接着玩”，电脑适配才更接近完整体验。

R14实际键盘操作：A答对第一题，B答对第二题，比分来到1:1，进入第3题。每一步都检查了对手牌面保持不变。

手机和平板仍沿用各自的触控区域。下面分别展示手机A方和平板B方解题：

手机A方：选牌、运算得到24，再提交得分。

平板B方：在朝向对面的上方区域完成同样的操作。

通过这组过程，适配带来的变化就很具体了：手机和平板各点各的一侧，电脑各用各的键区。助手把明确的交互要求转成工程代码，再通过实际操作确认行为，形成了我愿意继续使用它的协作方式。

从适配代码到完整观感，把成果继续打磨好

最终观感之前，还经历过一轮短横屏追问。手机横放后，标题、玩家区、牌面与按钮都在竞争约350vp的高度。只压缩单个按钮，解决不了上层重复标题占位。我给助手的反馈写到了整页：

我反馈短横屏的实际问题 · 原文节选

须去掉此两玩法短横屏重复标题/减少外围占位，按钮紧凑分支改为单行图标+文字、表达式仅保留有效信息、每侧卡区与操作区横排，B上A下全部可点，别再只压字号。

这一轮代码修改和构建完成后，模型服务返回HTTP402，任务总结中断。我保留已完成的修改，接着检查设备效果，处理剩余尺寸问题，再进行视觉整理。

适配能力落地后，接着下一步，我又做了一轮视觉整理：沿用《拼棋派对》的配色，用image2生成方案，再完成R14界面的独立实现。布局、状态、键位和焦点处理打好基础后，再统一按钮尺寸与页面层级，操作区就更容易辨认。

平板竖屏优化前后：牌面与操作区重新分配空间，同类按钮尺寸一致。

象棋在电脑上把信息与工具集中到侧栏，平板横屏采用紧凑工具组，手机竖屏让必要操作等宽排列。24点则让电脑双方区域等宽、逐行对齐，移动端根据方向切换四牌单行或2×2牌面。同一布局内运算与动作按钮等高，深色表面上的文字、边框和禁用态也分别检查可读性。

手机竖屏：牌区随方向重排，上方玩家区朝向对面。

电脑最大化后，两位玩家仍有明确的区域和常驻键位说明。

我也特别在意“换了形态，这局还能不能继续”。先让中路红兵前进一步，再把手机转为竖屏、展开双屏和三屏，棋子位置、黑方回合和1手记录都保留下来。

单屏竖向

展开双屏

展开三屏

同一设备、同一局棋，变化的是排布。

平板象棋：选兵、落子、悔棋、认输与重开；旋转后保留当前对局。

手机、平板和电脑都完成了象棋与双人24点的代表操作检查。从描述问题、修改工程到回设备体验，开发助手的协作最终落到了玩家看得见、点得到的改进上。

把同样的方法带到其他页面，让整款应用更一致

象棋与24点的变化让我确认了一件事：多端适配的价值，要在玩家伸手操作时才能体现。随后，我把“先保留操作、再分配棋盘空间”的方法继续用于其他玩法。接着下一步，我按照image2设计参考，继续整理其他页面的布局与操作区。

成语消消乐 · 同一电脑默认窗口，底部工具终于完整出现。

旧版把标题、分数、目标成语和字阵全部纵向堆叠；单看字阵似乎够大，真正要暂停或提示时，按钮却被窗口底边截住。

优化前：底部工具被窗口边缘截住。

优化后：字阵居左，分数、目标与四个等高工具集中在右侧。

这次没有继续缩小所有内容，而是把需要一起看的信息放到一起。棋盘尺寸同时受可用宽度和高度约束，工具先占好位置；短横屏再把四个工具合为一行。暂停、重开、提示、结束都能直接找到，字阵也保持完整。

同一个成语页面，手机竖屏和平板横屏各有自己的摆法。

手机竖屏：目标在上、字阵居中、工具在下，单手握持时更容易顺着阅读顺序操作。

平板横屏：字阵与目标、工具左右分区。

单人拼图 · 从六个挤在一起的入口，到两排等高工具。

改前：六个功能横挤一排，配置继续排在棋盘下方。

改后：提示、原图、设置在一排，重开、结束、开始在一排；配置独立展开，返回后继续看当前棋盘。配色和拼图玩法保持一致。

1024也沿用这套空间预算：宽屏让棋盘与方向区并排，手机竖屏改为上下排列。方向按钮保留明确的十字关系，重开独立放置，避免与一次普通移动混淆。

电脑默认窗口的1024：大棋盘与完整方向区同屏，鼠标按钮和WASD都可使用。

同一轮里，单人24点、算术对战、寻物挑战以及五子棋、跳棋、记忆、反应和双人拼图也完成了相应布局整理。大厅、目录、战绩、设置和诗词页一起检查，按实际问题处理标签、长行与空间分配。这样的收尾使玩家从一个玩法切到另一个玩法时，也能找到熟悉的操作位置。

手机横放时，诗词页也暴露了一个容易被忽略的问题：风景图仍占着竖屏的高度，答案和暂停被推到了屏幕外。于是我让状态、景图和工具留在左侧，把诗句与四个答案放到右侧；长题干可滚动，答案始终留在眼前。

手机横屏：题目、答案和暂停入口完整可见。

用得更顺手的经验，以及我期待的下一步

经过这次实践，我愿意推荐开发助手参与已有工程的多端适配。要让它发挥得更好，也有几条值得提前知道的经验。

首先，把必须保留的功能写清楚。双屏跳棋第一版曾为省空间隐藏难度入口，我反馈保留6/8/10子与当前选择后，助手在第二版复用原组件恢复了侧列。它能迅速执行布局调整，而功能优先级需要开发者给出明确约束。

第一版：功能少了一个

第二版：利用棋盘旁的空位

一次有价值的反馈：从缺少难度入口，到恢复侧列并实际选中10子。

其次，保留设备验证这一环。本次所选模型不能直接读图。接着下一步，我先查看截图，再将观察结果和UI树整理成文字反馈；中间也遇到过横向分支遗漏、标题与控件高度预算不完整。构建验证与操作验证结合，才容易发现这些差异。我最期待的功能，是助手能直接结合截图和布局树，联动多设备模拟器检查裁切、可读性与状态保持，并自动整理同页对比。

再次，留意模型服务与任务恢复。本次登录后还需单独配置模型；手表任务两次出现模型请求失败，后期一轮修改完成构建后又因模型服务HTTP402余额不足而未输出总结。我保留了代码、回复和构建记录继续工作，也希望插件将来能更清楚地显示模型状态、保存中断节点并接续任务。

最后，按设备场景取舍，并说明成果边界。官方指南列出的适配设备覆盖直板及多种折叠手机和平板；PC和手表不在该页面列出的自动适配设备清单中。本项目的PC协作尝试与独立手表实现，不等于官方对这两个设备的自动适配承诺。接着下一步，我为手表独立实现了八轮图形快反；API迁移、部分PC基础修复与后续视觉整理在这一基础上继续完成。开发助手本次的直接贡献集中在中间尺寸布局、动态状态、玩家朝向、双人键盘、焦点处理与部分短横屏修正。

手表快反：完成八轮后，可直接重开。

最后我又在DevEco里补问了一次：能否只检查独立的watchentry，保留八轮图形快反，完成圆屏安全区、文字对比度和触控布局适配？这次模型服务正常，助手给出了明确答复：

“本插件的一多适配能力明确不覆盖穿戴设备（智能手表/圆屏）。”

它没有把手机界面缩小充当手表成果，而是说明本轮不修改代码，并提醒我单独验证圆屏四角、42vp选项、30vp重开入口及熄屏恢复。这次补测的价值，是把使用范围说清楚：手机和折叠屏可以继续沿着插件流程推进，手表仍需使用面向Wearable的规范和独立验收。已有八轮快反与独立手表包保留，真机触达和功耗还不能用模拟器结论替代。

本次以象棋和双人24点作为完整操作验证的代表，其余页面补做布局与相关流程检查。手机、平板与电脑使用API26模拟器，手表使用API23圆屏模拟器；真机触控、功耗和实体键盘并键仍需在实际设备上验证。

317次请求背后，是这样一段持续协作

回看这次实操，最有价值的并非一次漂亮的回复，而是后一次反馈能接住前一次修改。前面展示的是关键片段，完整工作还跨过了这些批次：

实操阶段	向助手提出的事情	为什么还会继续往返
工程分析与大厅	读取已有适配逻辑，先修一处标签残影	先分析，再限定实现，最后回设备核对
折叠中间尺寸	让象棋、五子棋、跳棋保留完整操作	首轮后补回跳棋难度入口、调整工具栏余量
动态按钮	走棋后按钮名称与大厅轮播入口同步	对照实际落子、认输、重开与入口路由
共享状态	页头、比分、题号和工具提示一起更新	构建补齐复用调用，再追查PC反应计分遗漏
就座方式	设备默认、面对面、同向与持久化	检查横向/竖向组件是否都接入朝向规则
手表可行性	尝试独立轻量玩法的插件任务	两次模型请求失败，未将独立实现归入插件
电脑输入	双人键位、长按去重、组合键与防串页	恢复中断任务，核对代码现状、工具链与构建
回前台继续玩	追查后台松键后键盘不再响应	区分按键残留与焦点丢失，补窗口生命周期处理
代表玩法细化	A左B右、上下对坐与短横屏高度预算	用真实窗口尺寸继续反馈，保留未通过的版本

本次开发助手实操的累计用量为 317次API请求、69,764,040 tokens，覆盖工程分析、布局调整、状态修复和操作验证等阶段。

一项需求在执行中会经过源码读取、工具调用、修改和构建重试，因此API请求数包含这些步骤，并非人工提问次数。统计未拆分输入、输出与缓存，也未包含该统计时点之后的新增工作。

我的效率感受落在更具体的地方：在同一工程上下文里追加“这个按钮还没变”“这个横向分支还没接上”，助手就能继续定位和修改，省下反复搬运代码、重新介绍项目的工作。与此同时，长上下文、重试和失败请求也可能增加消耗，使用插件并不自动保证更低的Token。此次没有同任务的无插件对照组，所以不宣称已经测得节省比例。

如果重新开始，我仍会选择这种协作方式：先圈定页面和设备，把必须保留的操作一次说清；每轮反馈带上操作顺序、实际窗口和可核对证据；确认通过的部分就收束，再进入下一批。这样既能利用助手持续理解工程的优势，也更容易减少无效往返。

如果你正在维护一个鸿蒙应用，想让它更好地适应三折叠和平板，我建议从一个真实页面试起：在DevEco里安装HarmonyOS开发助手，选择“一多适配”，把“哪台设备、怎样操作、哪里不顺手”交给它，再把实际体验带回下一轮对话。 从能放下一个棋盘，到双方看得懂、点得到、切回来还能继续，开发助手的价值就藏在这些可以验证的改进里。