做完《拼棋派对》的多设备适配后，我想继续试试 HarmonyOS 开发助手的另一项能力——元服务生成。这一次，我给它的目标很具体：打开手机就能做一道24点，选数、运算、撤销、提交，答对后接着玩。

原 App 已经有算法、题库和配色，这些都可以继续用。我希望验证的是：开发助手能否读懂已有项目，把这些基础组织成一个独立的元服务，并沿着真实的构建、签名和手机运行流程走到可交付的安装包。

第一阶段，这个手机元服务完成了单人24点的本地实现和模拟器代表流程验收：三档难度、18道固定题，支持四则运算、撤销、清空、提示、答对计分和六题后重新开始。随后，我又把原App的9种双人玩法同步到元服务。扩展版已完成九种双人玩法和单人24点的手机入口检查，并复测了象棋与双人24点的代表操作，并检查了浅、深系统模式下的页面显示。开发助手负责首个业务流程的分析与生成，后续再复用原App规则扩展玩法。

先看官方例子，再决定元服务要装下什么

开始前，我看了官网的一站式生成元服务指南。示例展示的是点餐元服务：把功能和页面要求交给助手，逐步生成工程和业务页面，再关联元服务、配置签名、构建运行。官网以 VS Code 为例，这次我在 DevEco Studio 里操作。

本次环境是 DevEco Studio 26.0.0.851、API26 SDK，HarmonyOS Dev Assistant 插件版本为0.1.70。我的插件已安装并登录；本轮没有重新安装。初次体验的开发者可以先按官方开发助手指南完成安装，在 IDE 的 HarmonyOS Dev Assistant 面板中选择“元服务生成”，再打开自己的工程。这里要区分“一多适配”和“元服务生成”：前一篇做多端适配，这一篇用的是后者。

实际操作时，我先在 DevEco 打开手机元服务工程，再进入右侧 HarmonyOS Dev Assistant 面板，新建会话，将输入框下方的模式选为“元服务生成”。发送前确认项目树是这次的元服务工程，随后把当前工程路径、原 App 的参考文件和本轮目标一起写进提示。截图中的模式选择、模板代码和提问区域，可以对应起来看：助手面对的是一个已有模板工程，需要在这个工程里继续完成业务。

我已经用模板建好了独立工程 D:\pinqipaidui。工程中的元服务身份保留不变，原 App 也继续保留。24点适合这个实验，是因为它的任务很短：四张牌、一组操作、一个结果，不需要先浏览一长串玩法，也没有必须登录才能开始的理由。

助手的价值从这里就开始体现了。它能围绕当前工程和现有源码给出拆分建议，帮助我确定哪些内容可以复用、哪些内容应当留下。首版带入元服务的是必要算法、18道题和原有品牌配色。后续扩展双人玩法时，再按实际需要迁入规则和资源；首轮对话没有承担全部玩法的重写。

第一轮对话：先读工程，让复用有依据

我给助手的第一个任务是读工程。这样做有一个直接的好处：先让它找到已有规则和依赖，后面的实现要求就能落到具体文件。下面按原始提问摘出三个部分，分别交代工程、目标和需要回答的问题：

请先仅做只读分析，不创建或修改业务代码、不输出设计稿、不改版本、不签名、不接受旧会话修改。

用户已创建元服务工程D:/pinqipaidui，当前打开的就是它。……我们要通过“元服务生成”实操开发拼棋派对的独立轻量24点挑战：出题、选四个数与运算符、撤销、清空、提交判断、结果、再来一题。目标是本地无需登录、无需支付和联网的完整小流程。

请分析当前工程并提出：可复用的24点算法、需要剥离的依赖、模板登录如何移除、最小页面/状态/资源结构、题目有解和重复数字处理、除零/精度/四数必须各用一次等验证策略、构建与签名的后续步骤。

提交以后，助手先核对了工程中的元服务声明、手机设备类型和免安装标志，再检查模板里的账号登录，以及原 App 的算法、题库和配色。它的回复中有两处，直接影响了我接下来的实现方式：

当前 pages/Index.ets 是 Hello World + 华为账号静默登录模板；EntryAbility.ets 是标准模板，不含登录逻辑，无需改动。

原 applyTwentyFourOperation 只算值、不校验同牌/已用，这些必须在控制器补足。

第一处把改动范围缩到了入口页面：移除模板登录，让用户直接开始答题。第二处提醒我，计算出正确的数值还不够，必须保证每张牌只用一次。像首题里的两个“1”，需要用不同的槽位身份区分；点击同一张牌两次，不能当成用了两张牌。

题库部分，它找到了原 App 的18道固定题和对应解法，建议首版直接复用。状态部分，它把选择的牌、等待执行的运算符、撤销历史、难度、轮次和得分逐项列了出来，并建议使用 API26 的 V2 状态管理来观察牌数组。这轮对话带来的价值很具体：我已经知道哪些内容可以带过来、哪些状态需要补齐，也能据此写出下一轮的验收条件。

对已有项目的开发者，这种用法很适合起步：把原项目里的相关文件交给助手参考，先取得一次有源码依据的分析，再决定实现范围。助手在工程里读到的登录依赖、题库结构和状态问题，比重新口述一遍整套产品更容易落到代码上。

这让后续交流容易了许多。已有题库可以复用，基础测试可以提前准备，助手也不必在每一轮重新理解整套游戏。接着下一步，我为原App的18道固定题和6项边界情况准备基础验证，24项全部通过，再带入后续实现。

第二轮对话：把一句“做个24点”拆成能运行的流程

读完分析，我把范围收敛到“固定18题、手机离线单人24点”，然后在同一个会话里发送实现要求。提示除了玩法，还包含按钮、状态、构建和交付记录，实际内容包括：

固定18题、离线单人24点，删除模板登录。实现完整选数→运算→撤销/重置→提交结果→下一题闭环，三档难度，清楚的规则和提示。同牌/已用牌不可重复参与；除零不改变牌或历史；内部保留完整精度；成功后重复提交不能重复计分。

保留四牌、表达式/目标、运算符、动作区的层级，统一同类按钮大小，手机宽度不足时可合理换行/滚动，不能缩成难以点击的小字。

我还把已经处理好的签名状态写给它，避免工具链信息停留在第一轮的未签名基线上。原始提示中的这一段是：

签名进度纠正：我们已通过DevEco插件设置关联正确元服务，并使用控制器成功创建发布签名，release产品已签名构建通过；default产品仍无有效签名。因此正式构建使用product=release、buildMode=release。

发送后，插件先建立任务清单、检查可用的构建工具，然后创建四个业务文件并重写入口页面。它没有停在给出代码片段，而是在当前工程里完成文件修改和构建。生成结果可以按下面这张表核对：

插件首版生成的文件	在玩法中承担的工作
TwentyFourModels.ets	保存数字牌的身份、数值、表达式和是否可用，以及题目与撤销快照
TwentyFourLogic.ets	四则运算、合并、数字格式化和24点判定，便于独立验证
TwentyFourConfig.ets	放入原项目的18道题、三档难度和品牌配色
TwentyFourController.ets	组织选牌、选运算符、撤销、清空、提交、换题与提示
pages/Index.ets	将模板页替换为24点页面，移除账号登录逻辑

状态管理使用 @ComponentV2、@Local、@ObservedV2 和 @Trace。这些名字最终对应的是一个很直观的体验：点中数字要立刻亮起来，合并后原来的牌不能再用，顶部得分也要随提交一起更新。

这轮还有一个实际的工具选择过程。第一轮方案提到的 devecocli 在本机不可用，助手检查后改用 DevEco 自带的 hvigorw，并明确采用 product=release。它的可见答复记录了这个调整：

构建工具链已确认：devecocli 不在环境中，唯一可用的是 DevEco 自带的全局 hvigorw……我将用 hvigorw + product=release 构建。

随后执行的命令是：

hvigorw assembleHap --mode module -p product=release -p buildMode=release

助手报告 BUILD SUCCESSFUL，首版业务 HAP 为125,850字节。这是当时生成步骤的产物大小，后面的页面修复、图标制作和双人扩展都重新构建了对应版本。

拿到答复后，我对照插件面板中的五项已完成任务，检查项目里新增的文件、入口页和构建产物，再通过面板的“导出会话”保存分析与实现记录。面板中的任务清单和待审查文件，使每项要求都能对应到具体修改。

业务首版生成并构建后，我继续安装到手机，逐步检查选牌、撤销、提交和换题。这一步发现了计分刷新与控制器状态问题，也为后续布局调整提供了依据。

这一轮很适合体现开发助手的用途：它不仅返回一段代码，还能在工程里组织文件、沿着任务清单推进，并使用构建结果检查实现。首轮分析约154秒，第二轮实现约600秒，后续再进入手机操作检查与修复。

视觉部分也有一个实际限制：当时使用的模型不能解析我给出的 image2 参考图。助手明确说明了这一点，并转而参考原 App 的组件结构及文字约束。我将视觉要求改写成组件结构、按钮尺寸与布局层级，使助手继续沿用原App的配色和设计思路。

从能编译到能玩，我补了哪些检查

第一次生成后，代码能构建，但仍然发现了两个控制器问题：答对后清空再解可能重复得分，撤销后选择状态没有完全清理。接着下一步，我修复了成功态保护和撤销状态，再运行控制器用例，14项全部通过。

装到 API26 手机模拟器后，又出现了一个只有看运行画面才明显的问题：中间已经显示答对，顶部得分仍然是0。原因在状态栏的构建方式——动态值先作为参数传入了复用的 Builder。我把它调整为在 Builder 的文本中直接读取被观察的状态，重新构建、安装，得分才正确刷新成1。

修复前，同一题已答对，顶部仍显示0。

修复后：答对提示与得分1同步出现。

发现的问题	调整方式	验证结果
答对后可以通过清空再解重复计分	成功态保护覆盖选牌、撤销、清空及重复提交	控制器回归通过
撤销后残留选择或运算符	恢复牌面时同时清理选择和运算符	控制器与手机点击通过
答对提示变化，顶部得分不变	状态栏直接读取可观察状态	手机显示得分1，换题与提示次数正常刷新
模板名称与图标遗留	使用“拼棋派对”名称并复用原 App 图标	最终签名包重新构建、安装

这些检查也让我更清楚地看到了合适的协作方式：开发助手负责理解工程、生成业务结构和鸿蒙页面；我把已经可靠的能力准备好，再用测试和实际运行收紧边界。这样既能利用助手的效率，也能把交付责任落在可验证的结果上。

手机效果：看得清，也要点得顺

这一轮只做手机元服务。页面保持《拼棋派对》的黑底、荧光绿和蓝色强调，四张牌占据主要操作区域，表达式放在下面，四则运算和动作按钮各占一行。

收尾时，我把难度选择、运算符和动作按钮统一为48vp高，顶部为元服务胶囊预留空间。提示和完整表达式允许换行；当内容超出可用高度时，页面可以滚动。规则文案也改成了真实的操作顺序：“先选一张牌，再选运算符，最后选另一张牌”，答对后才进入下一题。

实际操作不只测试“1+1”这样的整数题。我在手机模拟器上走了 5 × (5 − 1 ÷ 5) 和 8 ÷ (3 − 8 ÷ 3)，两道题都能正确提交为24。显示可以做格式化，计算过程必须保留精度。除零时页面会提示“不能除以0”，不会悄悄消耗数字牌。

初级六道题也逐一通过了手机实际点击：第六题结束后出现完成提示，点击“再来一轮”恢复第一题。浅、深系统主题都检查了，页面使用显式配色。按实际透明度叠加背景后的颜色计算，检查项中的普通文字最低对比度为5.94:1，高于4.5:1要求；关键描边与状态也通过3:1要求。

元服务采用固定品牌背景与竖向布局。手机旋转后仍保持竖向页面；折叠手机展开时限制内容最大宽度，避免牌和按钮被横向拉得过长。

元服务图标要再走一步：用 Image Asset 构建

交付检查时，还补上了一个容易忽略的区别：直接复制普通 App 的图标，并不能代替元服务图标的制作流程。我在 DevEco 的 Image Asset 中导入《拼棋派对》已有的1024×1024品牌图，选择工具从原图提取的蓝色作为环形标识颜色，生成元服务图标。

工具输出两份文件：512×512的工程图标和216×216的AGC上传图标。应用、入口和启动画面统一引用生成后的工程资源，旧的普通App图标引用移除。品牌图案沿用现有素材，由Image Asset生成符合元服务要求的图标资源。替换后重新构建并验签，更新交付包。

替换后的签名包安装到手机模拟器，打开元服务胶囊菜单，可以看到新的环形标识与“拼棋派对”名称。包内图片也与Image Asset生成文件逐字节一致，旧图标已移除。

签名与交付，开发助手帮我串起了最后一段流程

插件实操还有一段发生在设置面板里。首轮分析结束后，我进入 HarmonyOS Dev Assistant 的设置，在“关联元服务”中选择与当前工程一致的服务，然后进入“添加签名”，选择发布签名。创建成功后，界面显示签名“使用中”。接着下一步，我使用控制工具操作 DevEco 完成签名配置，再把结果补充给第二轮实现会话。

为了确认这条链路确实可用，我先对模板工程执行一次 release 构建，看到 SignHap 和 SignApp 实际执行，再用官方工具分别验证 APP 和独立 HAP。通过之后，业务实现继续使用这套配置。先验证签名通路，再生成业务，使后面的安装问题更容易定位。

这里有一个值得提前留意的细节：插件新增的是 release 产品及对应签名，而 default 产品没有有效配置。因此，第二轮提示里明确写入 product=release，后续构建也沿用它。对新手而言，设置里出现“使用中”之后，还应确认实际构建的是哪个产品。

本次正式构建采用：

hvigorw assembleApp -p product=release -p buildMode=release --no-daemon

第一阶段交付的是1.0.0版本，API26，仅声明 phone 设备，bundleType=atomicService、installationFree=true。外层 .app 和独立 .hap 都通过官方 hap-sign-tool 验签；玩法版本已完成首题、计分和换题复测，随后Image Asset图标修正版重新安装并启动成功。修正版签名 .app 为277,134字节，独立 .hap 为322,130字节，

第一阶段完成了业务生成、发布签名和手机模拟器运行，接下来继续扩展双人玩法。

接着把双人玩法带过来，真正的限制出现在构建和手机上

单人24点流程跑通以后，我把目标扩展到《拼棋派对》里全部9种双人玩法：双人拼图、双人五子棋、双人跳棋、双人记忆挑战、反应抢点、算术对战、双人24点、双人象棋，以及成语消消乐双人竞速。原来的单人24点仍保留为独立入口。

接着下一步，我复用原App已有源码，完成双人玩法的迁移与兼容调整。插件已经帮助分析独立元服务工程、实现首个业务流程并衔接签名链路，有了这块基础，后续才可以聚焦产品本身。

第一个实际问题是接口差异。原App的SoundPool音效接口和电脑键盘常量没有通过元服务的编译检查。我保留手机触控玩法，移除桌面专用快捷键，并将音效改用支持元服务的AVPlayer。它提醒我：能够在普通App里构建的代码，迁入元服务仍然要重新检查API支持范围。

第二个问题是体积。首次打包报告入口模块约4056KB，超过工具要求的2048KB。于是重新编码现有拼图图片与短音效：图片保留原主题和资源标识，按手机显示尺寸压缩为WebP，WAV音效转换为MP3。九种双人玩法完整保留，资源优化后正式签名构建通过。

第三个问题来自实际屏幕。元服务胶囊需要占用顶部空间，原App的双人24点布局直接迁入后，玩家A最下面的操作区被截断。修复时按照胶囊之外的可用高度判断是否将四张牌排成一行，保留上下两个玩家区和48vp操作按钮，最后再重新安装验证。

双人24点已经通过合并、撤销、得分和自动下一题的手机操作检查。双人象棋也验证了选择棋子、合法落子、换手和悔棋；迁移后的纯逻辑另有7组测试覆盖拼图、五子棋、跳棋、象棋、翻牌与24点规则。

把九种玩法逐项打开后，我又补了两处手机布局修正。成语竞速原来只为字阵估算高度，忽略了目标词条、状态栏和底部两排操作区，最后一排字块因此压到按钮。重新按整页可用高度分配后，字阵与四个操作按钮各有完整空间。战绩页则去掉窄屏卡片里的装饰图标，把旧的“拼图最佳”替换为“完成对局”，标题与数值不再挤在一起。

提示态也值得单独看一眼：字块变成黄色后，白字的对比度明显不够。我把提示态文字改为深色，黄色底上的文字对比度达到13.28:1。共用文字、控件以及成语字块的48项颜色检查通过，并在手机页面中核对显示效果。

最后，我用正式签名构建重新安装元服务，实际走了一遍两种不同的交互：双人24点从合并到提交得分，自动进入第二题；双人象棋从红方选兵到合法前进，轮到黑方，再悔棋回到红方。

截至本轮，手机元服务已具备九种双人玩法，以及保留的单人24点入口。九种双人玩法、单人24点、大厅、成语选关、设置和战绩共14个页面位置，在浅、深系统模式下分别检查并留图。页面沿用固定品牌深色，不提供应用内自定义背景。代表玩法通过，其他玩法完成入口和界面检查，并结合已有规则测试。

扩展版仍为1.0.0（1000000），API26，仅声明手机，保持atomicService与免安装声明。最新签名APP为1,859,892字节，独立HAP为2,753,744字节；两者分别通过官方验签，Image Asset图标与工程输出一致。本次验证覆盖手机模拟器中的页面与代表玩法；云端免安装分发及实体手机体验按发布流程另行验收。

用完元服务生成后，我最认可的是什么

这次让我最愿意继续使用 HarmonyOS 开发助手的，是它能够把工程上下文、业务代码和鸿蒙工具链放在同一个工作过程中：先分析复用边界，再生成页面与控制器，接着构建，并在插件设置里衔接元服务关联和签名。对手上已经有 App 的开发者，这条路径很实用——选出一个适合手机短时使用的功能，把已验证的基础交给助手，再集中精力检查真实体验。

从实际配合来看，先提供原项目的参考文件，再把需求补成可操作的验收条件，能够让助手持续围绕同一工程推进。已有算法继续复用，首版业务文件在插件中生成，构建和签名也接在这条流程中；开发者则能把更多注意力放在手机上实际玩起来是否顺畅。

预先提供可复用算法、明确功能边界与验收条件，减少了重复解释需求的工作。元服务这一轮未单独计量请求数和token，效率感受主要来自工程分析、业务生成与构建流程的连续衔接。

从一道24点开始，最后得到的是一个装下九种双人玩法、也保留单人练习的手机元服务。对我来说，开发助手最有帮助的地方，是让首个业务流程、鸿蒙页面与签名构建在同一工程里衔接起来；原App的规则复用省去了重复实现，后续手机验收则把按钮遮挡、状态刷新和提示可读性这些细节补齐。对应的源码、正式签名包、真实对话与操作证据都已整理，这次实操因此有了可以回看、可以继续发布的成果。

结合这次实操，我期待开发助手继续补齐的能力

这次体验让我愿意继续把已有项目交给开发助手：它能够围绕源码分析复用范围，把业务拆成可检查的文件，并在同一工程里衔接构建与签名。接下来，我更期待它把这些优势延伸到生成后的实际体验。

• 已有 App 转元服务的专项引导。 这次先抽取24点，再迁入双人玩法，需要逐步检查依赖与资源。希望助手能按功能给出可复用代码、元服务 API 支持情况和包体积构成，帮助开发者选择迁移范围。
• 生成后自动验证关键操作。 本次实际遇到得分不刷新、成功后重复计分和撤销状态残留。期待助手能在模拟器中执行选牌、合并、撤销、提交和换题，检查界面状态与业务状态是否一致，并留下真实截图。
• 更好地理解视觉参考并检查布局。 当时的模型无法解析参考图，后续验收又发现按钮遮挡与提示态对比度问题。希望支持设计图与运行截图对照，主动检查元服务胶囊、窄屏文字和控件状态。
• 更清楚的交付与用量记录。 期待面板同时显示当前构建产品、签名状态、包体积和验收进度，并按会话导出请求数、token用量、实际改动及构建结果，方便评估效率和整理实操文章。

这些期待都来自这次项目中实际走过的步骤。源码分析、业务生成和工具链衔接已经帮我完成了有价值的一段；如果运行验证与记录也能自然接上，已有 App 开发者就更容易把一次尝试做成可交付的元服务。