核心要点速览

  • Shopify配合回归Swift与Kotlin原生开发,构建了可供智能体验证应用行为的Reflex
  • 不使用真机也不使用模拟器,用同一套测试套件保持iOS与Android同步
  • 核心是ViewModel、Introspection Kit,以及通过Transport强制实现零网络

回到“智能体理所当然地写代码”这一前提的设计

Shopify Engineering于2026年11月5日在官方博客中解读了Reflex。起因是智能体可以在数分钟内写完界面,但证明这些界面确实能正确运行的环节却成了瓶颈。在推进原生回归的过程中,他们从根本上重新追问:应用究竟应该如何被构建。

Reflex把智能体查看应用状态、执行操作、验证结果的整条流程纳入架构。作者Thiago Magalhaes将其定位为与Helix并列的一项工作——Helix通过细小的检查点与严格的关卡推进界面重构。

共享的是测试而非代码:ViewModel与Introspection Kit的分工

Reflex的基础,是一份把UI移出方程式的契约。界面一侧只负责把action交给ViewModel,并绘制返回的state,业务逻辑不依赖UI。智能体可以透过这份契约来操作应用。

从外部观察ViewModel的是Introspection Kit。应用状态以树的形式表达,由Transport负责读写传输。即便不启动UI,智能体也能沿着结构化状态进行验证。

强制零网络、让失败可读的测试奖杯

Reflex把测试层级整理为测试奖杯,并在完全排除网络的状态下运行。因为没有外部因素混入,失败原因可以作为结构被读出来。测试不是操作的罗列,而是像用户的一段旅程那样来描述。

博客FAQ进一步讨论了不验证UI的测试有何价值、与XCUITest和Espresso如何并用、与Appium这类设备自动化有何不同,以及开源的可能性。

Shopify Reflex如何改变移动开发:原站入口在新标签页查看原始页面的完整内容
打开《Shopify Reflex》官方页面及相关链接 ↗

X(推特)首发原帖

可在 X 上直接查看创作者发布的原帖与互动详情。

常见问题

不测试UI的测试有价值吗

Reflex把ViewModel和状态树作为契约来验证。由于不依赖界面绘制,它比UI测试更不容易损坏,失败原因也更容易读懂——这是其立场。

它能替代XCUITest、Espresso和Appium吗

官方将其说明为角色不同,而不是替代关系。面对在设备上操作用户界面的工具,Reflex承担的是无需模拟器即可验证行为与状态的那一层。

参考链接与官方出处

  1. Shopify Reflex 関連ソース (1)x.com
  2. Shopify Reflex 関連ソース (2)shopify.engineering