导读
鸿蒙端存量功能迁移，难就难在"输入基线不清晰"：预期行为没有文档，要从源端代码里自己找、自己界定、自己证明。本文将一次迁移拆成"迁什么、怎么迁、怎么证明迁得对、怎么持续迁移"四个问题，据此提炼出完整、正确、可验证、可持续四条标准，并在 AI Coding 之上落地为一套研发交付流程：从源码行为建模到需求矩阵对账，从语义映射、多设备适配到分层测试与质量门禁，配合状态落盘和"迁移飞轮"实现经验复用。文末以"随听频道"真实迁移（52 个行为点、65 条用例）完整验证了这套机制的可行性。
01 引言：为什么要建设鸿蒙端AI研发交付流程
鸿蒙端的研发工作目前分为两类：迁移Android/iOS 端的存量功能，以及开发鸿蒙端新功能。鸿蒙端整体建设周期相对较短，所以存量功能迁移是当前工作量最集中的部分。这些功能大多经过长期迭代，调用链路深、隐性逻辑多，迁移难度也比较大。
借助AI Coding编码效率有了很大提升，但从需求到交付仍有不少环节依赖人工，比如识别需要实现的全部行为、确认实现与源端或需求一致、验证功能表现等。这些环节受研发精力和对历史需求熟悉程度的限制，往往耗时长、容易出错。因此，我们需要一套覆盖研发全过程的鸿蒙端 AI 研发交付流程，在提升效率的同时，让交付质量由流程来保证，不再依赖研发的个人经验。
02 如何思考和衡量交付
迁移比生成要更复杂，复杂在其输入基线范围不清晰。生成的预期行为写在需求文档里；迁移则要从源端代码里自己理解目标、界定边界，还要自己证明结果与源端一致。在设计研发链路之前，要先想清楚一次迁移怎样才算做好。我们从如下四个方面进行了梳理与思考：迁什么、怎么迁、怎么证明迁得对、怎么持续迁移。
- 迁什么
迁移首先要界定范围，识别需要在鸿蒙端还原的全部源端行为。主功能容易识别，遗漏多出现在分支路径、边界条件、异常处理、状态流转、数据链路和埋点等隐性行为上。这类行为通常没有文档记录，在主流程和界面上也不明显，却直接影响两端表现是否一致。识别的对象是行为，源端代码只作为还原行为的依据。范围内的行为须逐条还原，范围外的不纳入。
- 怎么迁
迁移可以采用新的实现，但可观察行为须与源端等价。源端依赖的平台能力如果在鸿蒙没有对应机制，需要重新设计等价实现；折叠、平板、多窗口等鸿蒙特有形态也要一并适配。范围较大的需求按可独立验收的粒度纵向拆分，逐阶段实现和验收，控制单次改动的范围。
- 怎么证明迁得对
代码完成不等于迁移正确，结果要通过验证闭环来证明：以行为基线为依据核验鸿蒙实现，发现差异就修正，再重新验证。设计这条闭环时，要明确行为等价怎么判定，验证力度和成本怎么平衡。真机验证成本高，验证按成本分层调度。交付是否完成，以可追踪的验证结果为准。
- 怎么持续迁移
一次完整的迁移通常要跨多个阶段，中途难免中断和返工，流程要能从断点恢复。源端还会继续演进，再次迁移时只需处理变化的部分。每次迁移积累的平台约束、常见模式和失败案例，也要能在后续任务中复用，让效率和稳定性随迁移次数逐步提升，形成迁移飞轮。
这四个问题对新功能生成同样成立，纯新需求没有源端可参考，预期行为以需求文档为准：界定范围的依据从源端行为换成需求文档，实现的目标从行为等价换成满足需求，验证与持续推进的要求不变。归纳起来，衡量一次迁移或生成是否做好，有四条标准：完整、正确、可验证、可持续。
03 四条标准的工程化实现
将这四条标准作为工程化设计的要求和约束，落到理解、规划、实现、验证、修正、持续推进等各个环节的设计中，我们在AI Coding之上建设了一套研发提效流程，每条标准对应一组设计：
- 完整：源码理解与行为建模梳理出行为基线，需求矩阵与全链路对账逐条核对每个行为点；
- 正确：跨平台语义映射把源端语义转换为鸿蒙实现，多设备适配覆盖鸿蒙特有的设备形态；
- 可验证：质量门禁要求每个行为点都有客观证据，分层测试按成本组织验证，兼顾覆盖面和开销，验证从规划阶段就开始；
- 可持续：流程状态全程落盘，中断后可以从断点继续；迁移飞轮把每次任务沉淀的经验用到后续需求中。
这些设计共用同一个流程底座，其中多数同时对应多条标准，作用也跨越多个阶段。它们按研发顺序前后衔接，组成端到端的交付流程，由需求矩阵贯穿全程。
3.1 统一底座
统一底座的设计思路是让同一条流程可以同时承接不同类型、不同规模的需求。
迁移/生成模式判定
有可参考的源端实现时走迁移模式，以源端真实行为为基线；没有时走生成模式，以需求文档为基线。两种模式共用理解、规划、实现、验证、持续推进这条主干，也共用同一道验收门禁。迁移特有的行为基线梳理和行为等价核对嵌在既有阶段内部，只在迁移模式下启用。
模式由系统根据需求说明和参考源自动判定，依据不足时交给用户来确认。典型情况是需求正文提到"安卓已有此功能"：这通常只是背景说明，并不要求行为等价迁移。如果误判成迁移模式，流程会进入成本最高的源端行为梳理。遇到这类情况，系统会列出判定依据，由用户决定。
复杂度分档
迁移需求可能只涉及单个功能点，生成需求可能要从零搭一个多模块页面。为了让流程开销与需求规模匹配，系统还会按需求涉及的范围自动判定复杂度：改动集中、一次就能验收的走单轮流程，小改动不用承担多阶段开销；涉及面大的按可独立验收的粒度纵向拆分，逐阶段推进。阶段怎么拆也由系统先判定，存在取舍时交给用户。阶段越细，每次收口的固定开销占比越高；合并阶段会扩大单次审查的范围，审查精度会不会下降，目前还没有结论。在有结论之前，流程不自动合并阶段，只对偏小的阶段给出合并建议。
Dry Run模式
有些需求不涉及编码，只需要判断值不值得做、怎么做、成本多大，例如方案预研、工作量评估和范围圈定。这类需求走Dry Run模式：流程完成理解和规划，产出方案、范围、成本和验收标准，到这里就停下，不进入执行。流程状态照常落盘，中断后恢复也不会误入执行；决定落地时，从当前状态继续推进。
横切保障
需求对账、多设备适配、分层测试、迁移飞轮、状态落盘，以及交互纪律（方向性决策只在需求澄清、方案确认、最终验收三处由用户裁定）和成本护栏（高成本手段事前授权），都分布在多个阶段、各管一段，我们把它们统称为横切保障。它们遵循同一个节奏：前期确立标准，执行中持续对照，交付前逐项核验。这样设计，是因为在流程最后检查只能发现问题，不能预防问题：如果标准没有在前期确立，验收时也没基准依据作参考来判断缺失了什么。各项机制最终统一由验收门禁核验，如果没有通过验收就退回到执行环节修复。
3.2 完整：从行为基线到需求矩阵
源码理解与行为建模负责把该迁的行为找全，尤其是主流程之外的隐性逻辑，找全之后还要能逐条核对，才能确认交付没有遗漏，因此做了需求矩阵与全链路对账的设计。
源码理解与行为建模
源码理解的难点在于把该迁的行为找全。最容易漏的通常不是主流程功能，而是命名对不上、没有明显入口、靠开关或跳转才触发的代码，顺着功能名搜不到。第一步是先定位承载行为的代码，再顺着入口注册、埋点上报这类和命名无关的线索反查补漏，把名字对不上、但确实属于这个功能的代码找回来。代码找齐后，从触发条件、异常处理等方面逐条还原行为，并遵守两条约束：对齐的是行为，不是逐行对齐代码；关键数据和埋点逐字对齐。时序、并发、AB 实验在线上命中哪条分支，这类静态分析确定不了的逻辑标为"待真机验证"，不计为已覆盖。
梳理出的源端行为逐条整理成行为基线，登记进需求矩阵，哪些还没实现，在矩阵上逐条可查。不过，这只能保证基线内的行为不遗漏：基线内缺一条就过不了验收门禁；基线之外的遗漏，要靠多角度交叉核查和真机验证兜底。
需求矩阵与全链路对账
做这套机制之前，我们踩过一个典型的坑：一条本该跨视图联动的交互，只跑了一条成本最小的验证，就被记成已覆盖。表面上完成了，关键路径其实根本没验到。实践中遇到的问题主要有三种：源端行为没有进入基线（漏），验证深度低于应有的要求（浅），用成本最低的验证代替应做的验证（虚）。
我们的做法是为每次交付建一张需求矩阵。每条需求拆成行为点，逐条对应到任务、实现和验证记录。验收按固定顺序推进，行为登记后，从三个角度依次核查：是否有行为没有进入矩阵，验证深度是否与行为的重要程度相符，每条结论是否有真实的运行证据。三个角度分别对应漏、浅、虚三类问题，职责不重叠，也不互相补位，全部通过后由验收门禁放行。
对账通过后，每个行为点都必须落到以下三种结论之一：
- 行为等价：已经实现，并逐点对照源端核对过；按需求有意与源端不一致的，差异和依据记录在案，也计入此类；
- 主动排除：平台特有或需求明确不做，写清原因；平台特有的同时写明鸿蒙侧替代方案；
- 显式放弃：无法迁移，或者迁移的收益抵不过风险，写清理由，并经用户逐条确认。
只要有一条没有结论，验收就被阻塞、退回执行。需求矩阵因此成为整个流程的底账：完整、正确、可验证都在这本账上核对，增量重迁也以它为起点。
3.3 正确：语义映射与多设备适配
要保证迁移正确，首先要做到行为与源端等价：实现可以另起一套，但可观察的行为必须一致，并按需求矩阵逐条核对，这由语义映射机制来实现。其次还要能处理折叠、分屏、多窗口这些在鸿蒙端分量更重的多设备形态，迁过来的功能在这些形态上同样要正确展示、正确运行。
语义映射
鸿蒙、安卓、iOS 的差别不止在语言，UI范式、生命周期、组件复用和系统能力的组织方式都不一样。迁移不能逐行把源端符号替换成 ArkTS，要把源端的业务语义从界面、业务逻辑、数据流、状态流转、平台能力几个维度映射成鸿蒙实现。从实践看，映射对象分两类：一类是接口调用、页面结构、业务分支等显式逻辑，源码里写得明确，鸿蒙也有成熟的对应写法，可以按统一原则逐项落地；另一类是编译和单测都能通过、只在真机上暴露的隐性差异，例如源端框架会自动清理订阅，鸿蒙需要手动移除，又如生命周期与复用机制的差异，导致视图复用后仍绑定着旧数据等。
两类问题各用一套机制处理。显式逻辑按统一原则翻译：翻译的对象是机制，源端的回调、观察、并发等写法换成鸿蒙原生的等价机制，并对齐目标工程的既有约定；每个行为点落地后回写源端与鸿蒙的对应关系，作为行为等价核对和增量重迁的依据。隐性差异靠经验沉淀提前规避：踩过的问题逐级沉淀，跨需求反复出现的固化为平台规则，编码时默认规避。
多设备适配
除了语义映射，还要适配鸿蒙特有的多设备形态。同一套代码要在直板机、折叠屏、三折叠、平板和 2in1 / PC 上都能正常运行，还要处理折叠切换、悬停分屏、折痕避让和屏幕旋转。如果照着源端的单一形态写，多设备调试会又复杂又耗时。我们用三条原则约束布局的写法：
- 布局只依据窗口尺寸和断点，不依据设备类型，因为折叠、分屏、自由窗口都会让设备类型失真；
- 折叠状态和屏幕方向只用于悬停分屏、折痕避让、开合状态延续这类特性分支，不参与布局决策；
- 所有系统尺寸都在运行时动态获取，不写死。
这三条原则不只写进了规范，也落实到流程的每个阶段。需求澄清时，先确定要覆盖哪些形态、每种形态怎样算通过，并写进验收标准；执行时，三条原则是生成代码的默认约束；验收时，按预览器 → 模拟器 → 真机由轻到重逐个形态核验，任一形态不通过就退回修复。
3.4 可验证：质量门禁与分层测试
每个行为点的交付结论不能靠模型的主观判断，必须有客观且可核查的证据，这在流程里是通过质量门禁与独立审查机制来实现的。其次还要控制验证成本，不能在每个测试点都执行所有的测试手段，真机执行成本高，每次全量跑并不现实，分层测试让验证按成本由低到高逐层推进，把成本高的测试手段留到必要时才用。
质量门禁
问题发现得越晚，基于它的实现就会越多，返工成本就会越大。质量门禁从规划阶段就开始设置，一直持续到验收。规划阶段生成方案时会先核对方案依赖的关键前提，例如状态的写入点、数据来源，并把依据写进方案，在编码前排除方向性错误。验收阶段，编译与静态检查、需求绑定测试、需求覆盖核对按成本从低到高执行，迁移模式另加行为等价核对；任何一道不通过，都退回执行环节修复。门禁本身跑不起来时标注原因，不计为通过。
这些门禁检查的都是能客观判定的结果。方案思路是否合理、代码里有没有测试覆盖不到的分支和时序问题，要靠审查判断。方案定稿和代码完成后各做一次独立审查，由与编写方上下文隔离的 Agent 只读执行；方案审查同时核对前提依据是否齐全。审查确认的问题也作为门禁项，不解决就不放行。
当然，设计上，门禁的边界也很明确：它只判定可以客观验证的事实和审查确认的问题，复杂交互和主观体验仍由人工验收，门禁通过不等于功能没有问题。
分层测试
需求实现后要验证纯逻辑、多设备布局、真实交互、折叠形态和真机硬件几个维度，缺一不可，各维度的成本却相差很大。真机执行耗时长，通常还要人工值守，不可能每次验收都对每个行为点全量执行；只跑成本最低的逻辑测试，又发现不了布局错位、折叠重排、传感器异常这类问题。
我们按成本把自动化测试分成一座金字塔。底层成本低、结果稳定，每次验收都跑；越往上越接近真机，成本越高，只在最终收口或用户授权时执行。塔尖是不预设脚本的探索式验证：模型在真机上实时读取界面结构，自己决定下一步操作，用来覆盖设计用例时没想到的路径。探索有执行上限，跑通后的操作轨迹固化成确定性用例，之后直接回放。
在研发流程中，规划阶段将每条用例绑定到具体的需求或行为点，用例失败与需求未实现同样阻塞验收；验收阶段按成本由低到高逐层执行；执行通过的用例沉淀为回归资产，持续复用。未执行的层级标注原因，不计入通过率。
3.5 可持续
迁移是长任务，常被会话中断或验收返工打断，状态落盘让流程恢复后能从断点接着运行；每次迁移沉淀下来的经验与需求矩阵又会反哺后续需求，使任务越做越快，最终形成迁移飞轮。
状态落盘
复杂的迁移长任务中，会话中断、上下文压缩和验收返工都很常见。流程进度如果只保存在对话中，中断后只能依赖Agent回忆，容易续接错位置，也可能把已确认的结论当作新需求重做。因此，流程推进过程中，各阶段进度、产物的位置和待确认事项等都会实时写入状态文件，对话本身不承担记录进度的职责。
中断恢复按固定优先级进行：先处理中断前待用户确认的事项，再处理未通过审查的方案，最后继续未完成的执行。恢复前先校验状态文件本身：结构损坏、产物缺失这类不可用的状态直接停止恢复，报出原因交给用户；只是写法不规范的仅做提示，不阻塞恢复；无法判定的一律请用户确认，状态不明时不继续执行。
迁移飞轮
鸿蒙端的迁移与生成需求会持续出现，不同需求之间常常遇到同类问题；同一需求拆成多个阶段推进时，前序阶段解决过的问题也可能在后续阶段再次出现。如果经验不能沉淀和复用，这些问题就会被反复处理，成本始终降不下来。因此，流程中设计了迁移飞轮，让每次任务沉淀的经验、模式与解法，在后续需求和后续阶段中持续复用。
复用的前提是经验本身可信，错误的经验一旦被主动采用，会误导后续实现，危害比没有经验更大。因此，经验的入库与生效都按可信度分级管理。问题修复后，先判断它有没有沉淀价值，只有技术性问题才进入经验库。新入库的经验只作参考，经用户确认有效后才正式采用；在多个需求中重复出现且根因属于平台层约束的，固化为自动生效的平台规则。已有的经验也可以降级：验收中证实与实际不符的，降为参考，不再主动使用；被推翻或被更优方案取代的，标记为废弃，并保留记录供后续排查参考。
除经验外，需求矩阵本身也会保留下来，用于后续复用。源端功能持续演进，如果每次都做全量重迁判断，已经核对过的行为点就要重新梳理。因此，每次迁移完成后，需求矩阵会和当时对照的源端版本一起保留；下次迁移只比对这个版本之后的源端变化，变化的部分增量重迁，没变的行为点沿用已有结论。这样，需求矩阵就不只是单次交付的核对清单，也成了可以跨版本复用的长期资产。
04端到端交付与实践
第三章按四条标准分别介绍了各项能力，本章把它们放回一次交付的实际顺序里。主流程依次经过七个阶段：项目探测、需求读取、需求澄清（含跨端参考）、规划、执行、验收、经验沉淀。对应到第三章的环节，前三个阶段属于理解，规划（含方案审查）属于规划，执行属于实现，验收属于验证，经验沉淀服务于持续推进。
阶段的先后由数据依赖决定：需求澄清产出模式判定和基线来源，迁移模式下在此梳理出行为基线；规划把行为点分配到各个阶段，产出任务清单和需求矩阵；执行按任务清单落代码，同时记下源端与鸿蒙的对应关系，以及无法迁移的条目；验收再对照行为基线逐点核对。缺了上一步的产物，下一步就没有输入，所以阶段不能跳过，也不能调换顺序。
方向性决策集中在需求澄清确认、方案确认和最终功能验收三处，由用户裁定；高成本手段的授权、无法迁移项的处理等确认按需发起，其余阶段由Agent默认自动推进。验收不通过就退回执行修复，修复后重新验收，通过后才推进下一阶段。
4.1 案例：随听频道迁移
把这套机制放到一次迁移中检验：以iOS端的源码实现为基线，将随听频道「听音乐 / 听军事」功能迁移到鸿蒙端。整个过程记录在一张需求流转单上，从范围圈定、拆解、落地到最终验收，每一步都可回溯核对：
迁移首先确定本次要交付的6条需求，再对照iOS实现逐条梳理，得到52个行为点和17条验收标准，覆盖正常流程、分支、边界和异常情况。范围确定后，按复杂度纵向拆分为6个可独立验收的阶段、30个任务，逐个推进。整个迁移跨越多个会话，中途多次中断，每次都依据流转单和落盘状态从断点继续。
落地阶段，每个行为点都要对应到代码，并在流转单上注明与源端的关系。多数行为点与源端行为等价，只是实现路径不同；少数需求本身要求与iOS表现不一致，这类行为点按需求覆盖源端，依据记录在单上，不计为漏迁。鸿蒙缺失的能力另行设计等价实现，折叠屏、平板等形态同步适配。最终，52个行为点全部有明确结论：46个行为等价，5个注明理由后主动排除，1个经用户确认后显式放弃。这一结果由验收规则保证：任一行为点没有结论，验收即被阻塞并退回执行。
验证按成本分层推进。12个设备套件、65条用例，每条用例都绑定到具体的需求、验收标准和行为点；纯逻辑层有部分用例受测试环境限制没能运行，折叠、平板等形态由人工确认。下面是真机层的运行录屏，Agent 在真机上驱动用例执行，并留存截图和日志作为运行证据：
分层验证拦截了单次跑通无法发现的问题。同一回调上的同类缺陷先后出现三次，分别由真机用例和独立审查发现并修复，最终沉淀为一条经验：同一时机触发的处理逻辑须收敛到一处统一执行。 另有一个真机套件的通过结果被证实取决于测试素材的时长，而非被测行为，该套件随即被下调可信度，不再计为可靠通过。验收时，6个阶段全部通过，每条需求和验收标准都能对应到代码证据与运行结果；未完成的部分与通过项一并写入验收报告，前文介绍的行为基线、需求矩阵对账、分层测试和状态落盘等设计都来自类似的真实迁移：先在实践中发现问题，再逐步总结推理建设对应的机制，并在后续实践中进行验证。
4.2 能力边界
需要明确说明的是，基线之外的遗漏无法完全排除，只能靠交叉核查和真机验证尽量压低；时序、并发和线上实验实际命中的分支，静态分析判断不了，只能留给真机验证；功能好不好用、体验好不好，门禁判断不了，要靠人工验收。
05 结语
AI Coding时代，编码已不再是交付的瓶颈，但是交付是否达标却不能交由模型主观判定。为此，流程把这一判定拆成可客观检查的规则：行为点逐条给出结论，结论逐条附上运行证据；门禁未能执行的不计为通过，偶然通过的用例下调可信度。模型负责产出，判定交给流程。
这一思路不只适用于鸿蒙迁移，只要预期行为能逐条列出、结果能逐条核对，同样的做法也适用于其他端和其他类型的需求。