经管之家App
让优质教育人人可得
立即打开
作者：徐子明，任阳
上一篇文章从控制论的理论视角出发，阐释了如何理解 AI Coding；本文则在此基础上进一步转向实践，通过具体的代码迁移场景，探讨如何对原始代码意图进行有效控制，来达到代码迁移的目标。首先，我们要从这个问题开始：从iOS/Android到鸿蒙，AI 迁移的到底是什么？表面上看，它迁移的是 Swift、ob jective-C、Kotlin、Java、C++ 等已有代码；再往下一层看，它迁移的是 UI 组件、生命周期、平台 API、工程结构和资源文件；但更深一层看，真正需要迁移的，是原应用背后的业务意图、平台语义、交互模型和工程约束。换句话说，AI 代码迁移的关键，不是把旧代码翻译成新代码，而是把旧平台中的“意图”逐层编译到鸿蒙与仓颉的目标实现中。
（第一篇链接：https://www.chaspark.com/#/hotspots/1266963661640949760）
这也是我想讨论的核心观点：AI Coding 并不是跳过编程，而是把程序员的表达层级从代码提升到了自然语言、需求描述、工程约束。软件开发的本质仍然没有改变，它依然是一个从高层意图逐步 lowering 到机器可执行系统的过程。只不过，在 AI Coding 时代，这个 lowering 的起点更高了，中间过程也更复杂了。从这个角度看，AI Coding 不是传统编程和编译体系的替代品，而更像是把“编译过程”向上延伸了一层。过去，编译器主要负责从源代码到目标代码的转换；未来，AI Coding 系统可能要负责从自然语言、业务意图、旧平台代码和工程约束，到目标平台可运行代码的转换。尤其在iOS/Android应用向鸿蒙仓颉迁移的场景中，这个视角非常关键。因为应用迁移不是简单的“代码翻译”，而是一场面向目标平台的信达雅“意图翻译”。
在苹果和安卓生态中，已经存在大量成熟应用。这些应用并不只是由若干代码文件组成，而是沉淀在特定平台上的完整工程系统。它们包含 UI 框架、生命周期模型、权限机制、资源管理方式、构建体系、第三方依赖、工程规范和用户体验习惯。如果我们要将这些应用迁移到鸿蒙仓颉，最表层的问题看起来是：如何把 Swift、ob jective-C、Kotlin、Java 或 C++ 代码转换成仓颉代码？但这只是问题的第一层。真正困难的地方并不是语法替换，而是语义迁移。
一个 Android 页面中的 Activity 生命周期，不只是几个方法名；它背后代表的是 Android 平台对页面创建、暂停、恢复和销毁的管理模型。一个 iOS 中的 UI 组件，也不只是某个类或函数调用；它背后包含了苹果平台的交互范式、状态管理方式和渲染逻辑。一个旧平台上的权限申请流程，也不只是某段 API 调用；它背后关联的是用户授权、安全边界和系统服务模型。如果迁移系统只做表面翻译，很容易生成“看起来像仓颉代码、实际上仍然保留旧平台思维”的代码。这样的代码也许可以局部编译通过，却未必符合鸿蒙平台的设计范式，也未必具备长期可维护性。因此，应用迁移的本质不是：旧语言代码到新语言代码，而是：旧平台上的业务意图和运行语义到新平台上等价业务意图的再表达这也是为什么 AI Coding 在迁移场景中不能只被理解为“代码生成助手”。它更应该被看作一个面向目标平台的迁移编译系统。
传统软件开发和编译过程大致可以理解为一条自上而下的链路：需求 → 架构设计 → 源代码 → 编译器中间表示 → 优化 → 目标代码 → 二进制执行。程序员过去直接编写 C++、Java、Kotlin、Swift 等源语言。源代码再经过词法分析、语法分析、语义分析、中间表示构建、优化、代码生成、链接等步骤，最终变成机器可以执行的形式。AI Coding 改变的是入口，而不是本质。
在 AI Coding 场景中，入口可能变成自然语言、需求文档、设计说明、接口约束、测试用例，或者一整个旧平台工程。例如：帮我把这个 Android 应用迁移到鸿蒙仓颉；帮我把这个 iOS 页面转换成鸿蒙实现；帮我把旧项目中的网络模块迁移到新的平台 API；帮我保持原有功能，但使用目标平台推荐的架构方式重写。这些输入不再是传统意义上的源代码，而是更高层、更混合的意图表达。于是，新的 pipeline 可能变成：迁移目标 → 任务理解 → 任务拆分 → 迁移意图 IR → 代码生成 → 编译测试 → 反馈修正 → 行为验证 → 可交付软件。这里最重要的变化是：AI Coding 把编译过程的起点从“源代码”上移到了“人类意图”和“已有工程语义”。
过去，编译器假设程序员已经把意图精确表达成了源代码。现在，AI Coding 系统需要帮助程序员把自然语言、旧代码和工程上下文逐步转化为目标平台代码。这意味着它不仅要生成代码，还要理解任务、拆分任务、注入知识、构造中间表示、进行优化，并通过反馈和验证保证结果可靠。因此，AI Coding 并不是一句 prompt 直接变成代码的魔法。它更像是一条新的 lowering pipeline：从人类意图开始，经过多层抽象表达和转换，最终落到可编译、可运行、可验证的软件系统。
在传统编译器中，中间表示，也就是 IR，是非常核心的概念。源语言可能有很多种，目标机器也可能有很多种。如果编译器直接从每一种源语言生成每一种目标代码，系统会非常复杂。因此，编译器通常会把源程序先 lowering 到一种或多种中间表示，再在中间表示上做分析和优化，最后生成目标代码。
这个思想对 AI Coding 尤其重要。在iOS/Android到鸿蒙仓颉的迁移中，如果我们直接做：Android/iOS 代码到仓颉代码，系统很容易退化成一个表面翻译器。它可能逐行转换语法，替换 API 名称，调整类和函数结构，但并没有真正理解原始代码的业务意图，也没有充分利用鸿蒙和仓颉的目标平台能力。更合理的方式应该是：Android/iOS 代码变换到迁移意图 IR，再到鸿蒙仓颉实现。这里的“迁移意图 IR”，也可以理解为标题中说的“编译意图”。它不一定是传统编译器中单一、固定的数据结构，而可以是一组结构化表达，用于描述原应用“想做什么”、当前代码“如何实现”、目标平台“应该如何承载”。例如，一个迁移意图 IR 可以包含以下信息：原代码的业务功能是什么；页面之间如何跳转；UI 状态如何变化；用户事件如何触发业务逻辑；原平台 API 的语义是什么；目标平台 API 应该如何映射；资源文件、权限、数据访问、网络请求如何组织；哪些行为必须保持一致；哪些实现可以根据目标平台范式进行重构；生成代码需要满足哪些编译、测试、性能和可维护性约束。迁移意图 IR 的价值在于，它把“代码长什么样”和“系统想做什么”解耦了。
如果 AI 只理解代码形态，它最多只能做翻译；如果 AI 能抽取迁移意图，它才有机会完成真正的平台迁移。也就是说，AI 迁移系统真正要编译的，不是旧代码文本本身，而是旧代码背后的意图、约束和语义。这也是 AI Coding 和传统代码转换工具之间的重要区别。传统规则工具通常擅长处理局部、确定、模式化的转换，例如 API 替换、语法改写、文件结构调整。但复杂应用迁移往往不是规则穷举可以解决的。它需要在理解原系统语义的基础上，结合目标平台知识，生成符合新生态范式的实现。迁移意图 IR 就是连接这两端的桥梁。它既要向上承接人类需求和旧平台语义，也要向下约束代码生成和验证过程。它让 AI Coding 从“直接生成”变成“有结构地转换”，从“不可解释的黑盒输出”变成“可观察、可审查、可修正的多阶段过程”。
但这里还有一个关键问题：迁移意图 IR 并不会自动出现。它不是简单从旧代码中抽取出来的语法树，也不是大模型凭上下文“猜”出来的一段解释。一个高质量的迁移意图 IR，需要同时理解源平台代码、目标平台能力、业务语义、工程约束和验证标准。换句话说，IR 是骨架，但知识是血肉。没有持续注入的平台知识、语言知识和工程知识，迁移意图 IR 就会停留在抽象描述层面，无法真正指导高质量的鸿蒙仓颉代码生成。因此，讲完 IR 之后，下一步必须讨论：这些知识如何进入迁移编译过程。
如果说迁移意图 IR 是 AI 迁移编译系统的中间表示，那么知识注入就是构造、丰富和校验这个中间表示的基础能力。在复杂应用迁移中，知识注入不应该被理解成 pipeline 中某一个单独阶段，而应该是贯穿任务理解、任务拆分、IR 构建、代码生成、反馈修正和结果验证的外挂能力。在任务理解阶段，系统需要注入迁移背景知识。例如，当前任务是简单语法转换，还是完整平台迁移？是迁移单个模块，还是迁移整个应用？目标是功能可运行，还是要符合鸿蒙仓颉的推荐实践？在任务拆分阶段，系统需要注入工程结构知识。一个应用可以被拆分成 UI、业务逻辑、数据访问、网络通信、权限处理、资源管理、测试等多个子任务。拆分方式是否合理，直接影响后续生成质量。
在迁移意图 IR 构建阶段，系统需要注入平台语义知识。比如旧平台生命周期和目标平台生命周期如何对应，旧平台 UI 状态模型如何映射到鸿蒙的实现方式，旧平台 API 在目标平台上是否存在直接等价物，哪些地方需要适配，哪些地方需要重构。在代码生成阶段，系统需要注入仓颉语言知识、鸿蒙 API 知识、团队代码规范和工程最佳实践。生成代码不能只是“能编译”，还要符合目标语言风格、目标平台范式和长期维护要求。在反馈修正阶段，系统需要注入错误诊断知识。编译错误、API 调用错误、类型不匹配、依赖缺失、运行时异常，不能只被视为“重新生成”的信号，而应该被定位到对应的抽象层：是任务拆分错了，IR 表达不完整，API 映射不准确，还是代码生成局部出错。在结果验证阶段，系统需要注入测试策略、行为一致性要求和性能标准。迁移后的代码是否保留原始功能？是否符合用户体验预期？是否存在平台 API 误用？是否满足性能和安全要求？这些都需要知识支撑。
这个过程很像传统编译器对目标架构信息的依赖。传统编译器不会只看源代码。它还需要知道目标架构、ABI、寄存器模型、内存模型、运行时约束和优化策略。没有这些知识，编译器就无法生成高质量目标代码。同样，AI 迁移系统也不能只依赖大模型参数中的通用知识。它需要持续注入目标平台、目标语言、工程规范、迁移策略和验证标准。否则，它生成的代码可能看似合理，但在真实工程中并不可靠。因此，知识注入不是一个“补充资料”的动作，而是 AI 迁移编译系统的基础设施。它决定了系统能否从通用代码生成，走向面向目标平台的高质量工程迁移。从这一点看，第三节和第四节其实是一体两面：IR 解决“AI 到底要表达什么”；知识注入解决“AI 如何正确表达它”。前者让迁移过程结构化，后者让结构化表达具备工程真实性。只有当迁移意图 IR 和知识注入结合起来，AI 迁移系统才不会停留在“看起来合理”的代码生成，而是能够逐步走向可信、可控、可验证的迁移编译。
有了迁移意图 IR，也有了贯穿全流程的知识注入，接下来的问题是：如何把这个 IR lowering 成更好的目标实现？这就对应到编译器中的另一个关键概念：优化。传统编译优化的目标通常是让程序更快、更小、更安全，同时保持程序语义不变。对于 AI Coding，特别是应用迁移来说，“优化”的含义会有所扩展。
第一类优化是语义保持优化。也就是说，迁移后的代码必须尽可能保持原应用行为不变。按钮点击、页面跳转、数据读写、权限申请、异常处理、异步回调、状态变化等，都不能因为迁移而出现语义偏差。这对应传统编译器中的 correctness-preserving transformation。无论中间经过多少次变换，最终程序的可观察行为都应该符合原始意图。在应用迁移中，语义保持尤其重要。用户并不关心代码是从 Android 迁移来的，还是从 iOS 迁移来的，也不关心底层用了什么生成策略。用户只关心功能是否正常、体验是否一致、数据是否安全、性能是否可接受。
第二类优化是平台适配优化。迁移不是把旧平台代码机械翻译成仓颉，而是要生成符合鸿蒙和仓颉范式的实现。好的迁移系统不应该把旧平台结构原封不动搬到新平台，而应该理解旧代码背后的意图，再选择目标平台上更自然、更推荐、更高效的表达方式。例如，某个旧平台 API 可能在鸿蒙中没有一对一对应关系。此时，系统不应简单寻找名字相近的 API，而应该回到迁移意图 IR，理解原 API 的真实目的，再选择合适的目标平台能力实现同样的功能。这就是平台适配优化的关键：不是逐行对应，而是意图对齐。好的 AI 代码迁移，不是生成“看起来像仓颉的旧平台代码”，而是生成“真正属于鸿蒙生态的仓颉代码”。
如果说 IR 解决“表达什么”，知识注入解决“如何正确表达”，编译优化解决“如何更好地 lowering”，那么反馈修正与结果验证要解决的就是最后一个问题：如何证明这个 lowering 过程是可信的？AI Coding 当前最大的挑战，并不是不能生成代码，而是生成过程经常不可解释，生成结果也不够稳定。 一个 prompt 生成一段代码，看起来很高效。但在复杂工程中，如果代码出错，我们往往很难判断问题出在哪里：是任务理解错了？是平台知识缺失？是 API 映射不对？是代码生成错误？还是测试覆盖不足？
编译器思想给我们提供了一种解决路径：把复杂过程拆成可观察、可检查、可回溯的多个阶段。每一层抽象都应该有明确表示。每一次转换都应该有清晰的输入和输出。每一个优化都应该有语义保持前提。每一段生成代码都应该能被编译、分析和测试。每一轮反馈都应该能定位到对应阶段，而不是简单要求模型“重新生成一次”。例如，如果迁移后的代码无法编译，问题可能发生在代码生成阶段；如果代码能编译但行为不一致，问题可能发生在迁移意图 IR 或平台 API 映射阶段；如果代码行为正确但不符合目标平台范式，问题可能发生在平台适配优化阶段；如果测试无法覆盖关键行为，问题可能发生在验证标准构建阶段。这种分层定位能力非常重要，它让 AI Coding 从黑盒生成变成工程系统。也让人类开发者可以参与到关键节点中：审查任务拆分，修正迁移意图 IR，补充平台知识，确认 API 映射，检查生成代码，设计验证用例。
未来可靠的 AI Coding 系统，不应该是一次性 prompt 到代码，而应该是可观测、可回溯、可验证的多阶段编译系统。在迁移场景中，验证不只是最后的验收环节，而应该反向驱动整个迁移编译过程。编译错误可以驱动代码生成修正，单元测试失败可以驱动局部 IR 修正，集成测试失败可以暴露平台语义映射问题，性能或体验问题则可能推动平台适配策略调整。这也是 AI Coding 和传统编译体系最值得结合的地方：大模型提供开放式生成能力，编译器思想提供分层、约束、优化和验证能力。二者结合，才能让 AI Coding 从“能生成”走向“可交付”。
如果沿着这个思路继续往前看，AI Coding 的下一阶段可能并不是单纯依赖更大的模型，而是模型、编译器和工具链的结合。大模型擅长理解自然语言、归纳上下文、生成候选代码、处理开放式问题。编译器擅长分层表示、静态分析、语义约束、确定性转换和优化验证。工程工具链擅长构建、测试、调试、集成和持续交付。
真正面向复杂软件迁移的系统，需要把这些能力结合起来。对于鸿蒙仓颉生态来说，应用迁移不应只被看作一个“代码生成”问题，而应被看作一个“迁移编译”问题。我们需要的也不只是一个能回答问题的 AI 助手，而是一个 AI-native 的迁移编译器。这个迁移编译器的输入，可以是旧平台代码、自然语言迁移目标、接口文档、平台知识库、测试用例和工程约束。它的中间过程，可以包含任务理解、任务拆分、知识注入、迁移意图 IR、代码生成、语义保持优化、平台适配优化、编译反馈和结果验证。它的输出，不只是若干代码片段，而是可运行、可维护、符合鸿蒙仓颉范式的目标工程。
在这个过程中，程序员的角色也会发生变化。过去，程序员的主要工作是逐行写代码。未来，程序员会更多地表达意图、提供约束、注入知识、审查中间表示、设计验证标准，并对最终系统质量负责。这不是程序员价值的降低，而是程序员工作层级的提升。当自然语言、旧代码和工程文档都成为新的“源语言”，编译思想并不会过时。相反，它会成为 AI Coding 走向工程可靠性的关键基础。
AI Coding 不是跳过编程，而是把编程和编译过程上移了一层。对于iOS/Android到鸿蒙仓颉的迁移来说，真正有价值的方向，不是让 AI 机械地翻译代码，而是构建一个能够理解迁移意图、注入平台知识、保持语义一致、完成平台适配并持续验证结果的 AI-native 迁移编译器。从这个意义上说，从iOS/Android到鸿蒙，AI 迁移的不是代码，而是“意图”。这或许也是 AI Coding 从“能用”走向“可信”、从“演示能力”走向“工程生产力”的关键一步。
扫码加好友，拉您进群
全部版块
我的主页
收藏
