鸿蒙存量功能迁移AI交付流程：行为基线与分层验证实践

鸿蒙专家

在好看视频鸿蒙端的实践中，存量功能迁移是当前工作量最集中的部分。这类功能经过长期迭代，调用链路深、隐性逻辑多，AI Coding 虽然提升了编码效率，但从需求到交付仍有识别全部行为、确认与源端一致、验证功能表现等环节依赖人工。其核心难点不是“生成代码”，而是输入基线不清晰：预期行为没有文档，需要从源端代码中自己找、自己界定、自己证明。为此，团队把一次迁移拆成“迁什么、怎么迁、怎么证明迁得对、怎么持续迁移”四个问题，并提炼出完整、正确、可验证、可持续四条标准，在 AI Coding 之上落地为一套研发交付流程。

一、先界定迁移范围：行为基线不是代码清单

迁移首先要识别需要在鸿蒙端还原的全部源端行为。主功能容易识别，遗漏多出现在分支路径、边界条件、异常处理、状态流转、数据链路和埋点等隐性行为上。源码理解时，先定位承载行为的代码，再顺着入口注册、埋点上报等与命名无关的线索反查补漏；代码找齐后，从触发条件、异常处理等方面逐条还原行为。这里对齐的是行为，不是逐行对齐代码；关键数据和埋点要逐字对齐。时序、并发、AB 实验线上命中哪条分支，静态分析确定不了的，标为“待真机验证”，不计为已覆盖。梳理出的源端行为逐条登记进需求矩阵，基线内缺一条就过不了验收门禁；基线之外的遗漏，则靠多角度交叉核查和真机验证兜底。

二、需求矩阵与全链路对账：解决漏、浅、虚

实践中典型问题有三类：源端行为没有进入基线，是“漏”；验证深度低于应有要求，是“浅”；用成本最低的验证代替应做的验证，是“虚”。做法是为每次交付建一张需求矩阵，每条需求拆成行为点，逐条对应任务、实现和验证记录。验收按固定顺序从三个角度核查：是否有行为没有进入矩阵，验证深度是否与行为重要程度相符，每条结论是否有真实运行证据。对账通过后，每个行为点必须落到三种结论之一：行为等价，即已实现并逐点对照源端核对过，按需求有意与源端不一致的，差异和依据记录在案；主动排除，即平台特有或需求明确不做，写清原因，平台特有的同时写明鸿蒙侧替代方案；显式放弃，即无法迁移或收益抵不过风险，写清理由并经用户逐条确认。只要有一条没有结论，验收就被阻塞并退回执行。需求矩阵因此成为整个流程的底账，也是增量重迁的起点。

三、语义映射与多设备适配

迁移不能逐行把源端符号替换成 ArkTS。鸿蒙、安卓、iOS 的差别不只在语言，UI 范式、生命周期、组件复用和系统能力组织方式都不同。显式逻辑要按统一原则翻译机制：源端的回调、观察、并发等写法换成鸿蒙原生等价机制，并对齐目标工程既有约定；每个行为点落地后回写源端与鸿蒙的对应关系，作为行为等价核对和增量重迁依据。隐性差异往往编译和单测都通过、只在真机暴露，例如源端框架会自动清理订阅，鸿蒙需要手动移除；生命周期与复用机制差异会导致视图复用后仍绑定旧数据。这类问题靠经验沉淀提前规避，跨需求反复出现的固化为平台规则。

多设备适配方面，同一套代码要在直板机、折叠屏、三折叠、平板和 2in1 / PC 上运行，还要处理折叠切换、悬停分屏、折痕避让和屏幕旋转。布局遵循三条原则：只依据窗口尺寸和断点，不依据设备类型，因为折叠、分屏、自由窗口会让设备类型失真；折叠状态和屏幕方向只用于悬停分屏、折痕避让、开合状态延续等特性分支，不参与布局决策；所有系统尺寸运行时动态获取，不写死。需求澄清时先确定覆盖哪些形态、每种形态怎样算通过；验收时按预览器、模拟器、真机由轻到重逐形态核验，任一形态不通过就退回修复。

四、质量门禁与分层测试：用证据替代主观判断

每个行为点的交付结论不能靠模型主观判断，必须有客观可核查的证据。质量门禁从规划阶段就开始：生成方案时核对状态写入点、数据来源等关键前提，并把依据写进方案，在编码前排除方向性错误。验收阶段，编译与静态检查、需求绑定测试、需求覆盖核对按成本从低到高执行，迁移模式另加行为等价核对；任何一道不通过都退回执行，门禁跑不起来时标注原因，不计为通过。方案定稿和代码完成后各做一次独立审查，由与编写方上下文隔离的 Agent 只读执行，审查确认的问题也作为门禁项。门禁边界同样明确：只判定可客观验证的事实和审查确认的问题，复杂交互和主观体验仍由人工验收，门禁通过不等于功能没有问题。

测试按成本分层。底层逻辑测试成本低、结果稳定，每次验收都跑；越往上越接近真机，成本越高，只在最终收口或用户授权时执行。塔尖是不预设脚本的探索式验证：模型在真机上实时读取界面结构，自己决定下一步操作，覆盖设计用例时没想到的路径；探索有执行上限，跑通后的操作轨迹固化成确定性用例，之后直接回放。规划阶段把每条用例绑定到具体需求或行为点，用例失败与需求未实现同样阻塞验收；执行通过的用例沉淀为回归资产，未执行层级标注原因，不计入通过率。

五、可持续：状态落盘与迁移飞轮

迁移是长任务，常被会话中断、上下文压缩和验收返工打断。流程推进过程中，各阶段进度、产物位置和待确认事项实时写入状态文件，对话本身不承担记录进度职责。中断恢复按固定优先级进行：先处理中断前待用户确认的事项，再处理未通过审查的方案，最后继续未完成的执行。恢复前先校验状态文件，结构损坏、产物缺失等不可用状态直接停止并报出原因；写法不规范仅提示，不阻塞恢复；无法判定的一律请用户确认。

经验复用则按可信度分级。问题修复后先判断有没有沉淀价值，只有技术性问题进入经验库；新入库经验只作参考，经用户确认有效后才正式采用；在多个需求中重复出现且根因属于平台层约束的，固化为自动生效的平台规则；验收中证实与实际不符的降为参考，被推翻或被更优方案取代的标记废弃并保留记录。需求矩阵也会和当时对照的源端版本一起保留，下次迁移只比对该版本之后的源端变化，变化部分增量重迁，没变的行为点沿用已有结论。

六、端到端流程与随听频道案例

主流程依次经过项目探测、需求读取、需求澄清（含跨端参考）、规划、执行、验收、经验沉淀七个阶段。阶段先后由数据依赖决定，缺了上一步产物，下一步就没有输入，不能跳过或调换。方向性决策集中在需求澄清确认、方案确认和最终功能验收三处，由用户裁定；高成本手段授权、无法迁移项处理等确认按需发起，其余阶段由 Agent 默认自动推进；验收不通过就退回执行修复。

案例以 iOS 端源码实现为基线，将随听频道“听音乐 / 听军事”功能迁移到鸿蒙端。过程记录在一张需求流转单上：先确定 6 条需求，再对照 iOS 实现梳理出 52 个行为点和 17 条验收标准，覆盖正常流程、分支、边界和异常；按复杂度纵向拆分为 6 个可独立验收阶段、30 个任务。整个迁移跨多个会话、多次中断，每次都依据流转单和落盘状态从断点继续。最终 52 个行为点全部有明确结论：46 个行为等价，5 个注明理由后主动排除，1 个经用户确认后显式放弃。验证侧有 12 个设备套件、65 条用例，每条绑定具体需求、验收标准和行为点；纯逻辑层部分用例受测试环境限制未运行，折叠、平板等形态由人工确认，真机层由 Agent 驱动执行并留存截图和日志。分层验证拦截了单次跑通无法发现的问题：同一回调上的同类缺陷先后出现三次，分别由真机用例和独立审查发现并修复，最终沉淀为“同一时机触发的处理逻辑须收敛到一处统一执行”的经验；另有一个真机套件通过结果被证实取决于测试素材时长而非被测行为，随即下调可信度，不再计为可靠通过。最终 6 个阶段全部通过。

七、能力边界与落地启示

这套机制并不能排除基线之外的全部遗漏，只能靠交叉核查和真机验证尽量压低；时序、并发和线上实验实际命中的分支，静态分析判断不了，只能留给真机验证；功能好不好用、体验好不好，门禁也判断不了，要靠人工验收。对鸿蒙迁移团队更有价值的启示是：AI Coding 只解决编码产出，交付是否达标必须由流程判定。行为点逐条给出结论，结论逐条附运行证据；门禁未能执行的不计为通过，偶然通过的用例下调可信度。模型负责产出，判定交给流程。只要预期行为能逐条列出、结果能逐条核对，这套方法也可复用到其他端和其他类型的需求。