Helix：应对大规模迁移的 LLM 工程化方案
Shopify 正在将其移动应用从 React Native 全面回归原生 Swift 和 Kotlin。这一战略转型已在 Shop App 上成功验证，团队仅用 12周 就完成了重建与发布。如今，这一经验被应用于 Shopify App——这是公司最大的应用，拥有超过 300个屏幕 的复杂规模。虽然大型语言模型（LLMs）具备强大的代码生成能力，但直接获取一致、高质量且可维护的结果极具挑战。为此，Shopify 构建了 Helix。
"Helix is a set of tools and skills that help LLMs migrate features and screens from the React Native app while following a highly opinionated architecture we designed for the new native apps."
Helix 并非试图一次性生成完整代码，而是采用了一种迭代式、基于反馈的学习机制。它不期望首次输出即完美，而是将工作分解为小步骤，随着每一步的正确执行，自动化程度逐步提高。其核心目标是在保持高质量的前提下，将工程师的生产力提升至前所未有的速度。Helix 构建了一个闭环：不完美的尝试无法推进，直到结果达到标准。
Checkpoints：以“小步快跑”实现精准审查
Helix 的迁移流程始于工程师指定目标屏幕，随后 Helix 读取 React Native 代码并提出一系列检查点（Checkpoints）。这些检查点是按顺序排列的小规模工作切片，工程师可在几分钟内完成审查与批准。
"Nobody can effectively review a wall of generated text. We'd rather give someone one decision they can make as opposed to ten pages they will skim."
检查点的设计遵循由简入繁的原则：首个检查点通常是屏幕骨架，后续检查点仅在早期决策通过审查后才逐步增加复杂度。这种小上下文窗口（Small Context Window）的设计至关重要，它允许代理直接读取参考代码的相关部分，而非依赖庞大的规格文件。测试用例由子代理生成，作为集成测试从用户视角描述功能，旨在挖掘非正常路径下的边缘案例。每个检查点必须通过行为测试、视觉审查和代码评审，反馈被记录并用于优化后续步骤。
四重审查门控：从行为到视觉的严格验证
Helix 通过四个严格的“门控（Gates）”确保质量，任何未通过的检查点都必须利用反馈修复并重试，代理无法自行覆盖失败结果。
- 行为门控（Behavior）：通过 CLI 暴露屏幕状态和操作，代理需复现参考应用的功能并通过行为测试。无需模拟器即可快速迭代。
- UI 视觉门控（The UI review gate）：这是实现 1:1 像素级还原的关键。由于不同框架无法生成字节相同的输出，传统像素对比失效。Helix 利用 Gemini 模型的空间感知能力作为“完美主义设计审查员”，检查结构、间距和对齐。Gemini 必须列出所有差异及其严重程度和位置，任何可代码修复的视觉偏差均被视为阻塞项。若状态不匹配（如订单履行状态不同），比较将被标记为无效并重新捕获。
- 对抗性代码评审门控（Adversarial reviews gate）：即使外观完美，底层代码仍可能存在问题。此门控旨在捕捉隐蔽的代码缺陷和架构违规。
自动化审查闭环与代码质量保障
Helix 的核心架构设计旨在降低 AI Agent 的实施难度，并通过详尽的文档使对抗性审查成为可执行的标准流程。系统引入了两个独立且上下文隔离的审查 Agent，它们负责将新代码与文档规范进行严格比对。这种机制不仅涵盖常规逻辑代码，还特别包括具有专属指南的 UI 界面代码。任何审查中发现的问题都必须被修复，且在修复后，受影响的测试用例会重新运行；如果 UI 发生可见变化，UI 审查关卡也会再次触发。这一过程形成一个强制性的迭代循环：只要两个审查 Agent 未同时批准，流程就不会终止。通过这种机制，Helix 确保代码在到达工程师手中之前已经过初步净化。当检查点（Checkpoint）最终呈现给人类工程师时，其状态已相当理想：UI 与参考设计几乎达到 1:1 的还原度，代码严格遵循指南规范，且行为已通过测试验证。这种“强制收敛”策略确保了交付物的基础质量。
工程师介入与记忆驱动的自主性演进
在自动化审查之后，进入“第4关”：工程师对代码和运行中的应用进行最终审视。这一环节不仅是简单的验收，更是系统进化的关键。工程师的反馈具有双重去向：一方面直接发送给 Agent 以修正问题并重新运行所有关卡；另一方面，Helix 会将这些反馈记录在记忆模块（Memory）中。这种记忆机制使得迁移过程中的自主性能够随时间增长：在早期检查点，由于不确定性高且缺乏已批准的工作样本作为学习依据，工程师需要投入较多注意力；但随着被批准的代码和反馈数据的积累，后续的检查点可以在更少的人工监督下运行。在某些情况下，如果工程师选择“自主模式”，部分检查点甚至可以跳过人工审批环节直接通过。每个检查点的最终结果都会生成一个 Git 提交（Commit），大多数工程师随后会基于此创建分支并发起拉取请求（PR）。这种设计将 Helix 从一次性工具转变为持续优化的协作伙伴。 > One-shot tools put all the work at the end: an engineer has to review one large, uncertain diff across product behavior, visual fidelity, two platforms, and architecture. Helix moves feedback to the earliest useful point.
自主运行模式与并行迁移能力
虽然默认设置要求工程师审批，但 Helix 支持灵活的自主运行模式。系统可以被指令一次性完成接下来的三个检查点，甚至完全跳过审批环节，持续工作数小时或通宵运行。值得注意的是，无人值守并不意味着审查标准的放松。每一个检查点仍然必须证明其行为正确、通过 UI 审查，并满足两个对抗性 Agent 的要求后，才能进入下一阶段。此外，Helix 具备并行处理能力，不受限于单一屏幕的迁移进度，多个界面可以同时推进并独立通过各自的审查关卡。在自主运行结束后，Helix 不会抛出一个巨大的、难以理解的差异包（Diff），而是提供一系列已提交的检查点供审查。每个检查点都附带完整的证据链，包括存档的 UI 审查结果、通过的测试报告以及 Agent 的最终裁决。这种设计极大地降低了工程师的认知负荷，使其能够专注于范围界定、产品判断和审美把控。 > The engineer can focus on scope, product judgment, and taste while steering small changes that have been validated before becoming the foundation for the next one.
通用化应用与可靠收敛的理念
Helix 的价值不仅限于迁移任务，其核心循环机制具有高度的通用性。对于新功能开发，Helix 可以将设计稿和产品文档作为参考基准，遵循相同的检查点与审查流程；对于架构迁移和重构任务，同样适用这一策略。如果是纯逻辑变更，系统则会自动跳过 UI 审查关卡。Helix 带来的真正启示在于思维模式的转变：团队不再追求“完美的一次性尝试”，而是致力于实现可靠的收敛（Reliable Convergence）。在这种模式下，错误是被允许的尝试过程的一部分，但系统绝不允许未达标的代码被发布。 > An attempt is allowed to be wrong. It is not allowed to ship until it isn't.
随着 Shopify 移动应用从 React Native 向原生架构的全面过渡，团队将持续分享在此过程中积累的经验。目前，Shopify 正在招聘移动工程师、基础设施工程师以及专注于 AI 与软件工程交叉领域的开发者，共同构建下一代移动应用体验。
结论
Helix 通过迭代式检查点与四重门控机制，成功证明了 LLM 在大规模原生迁移中可实现可靠收敛。其核心优势在于利用 Gemini 进行像素级视觉审查及对抗性 Agent 保障代码质量，使工程师从繁琐的代码比对中解放，专注于产品判断。该方案显著提升了 300+ 屏幕迁移的生产力与一致性。
然而，其有效性高度依赖严格的架构规范、完善的测试用例及初期的人工反馈积累。虽然支持自主模式，但系统并未降低审查标准，且目前主要验证于 Shopify 内部场景。其通用性虽被提及，但跨团队或无规范项目的实际落地效果及长期维护成本仍有待更多外部案例验证。