AI 写代码 — 但它不可能发明 Expo Router

Source: Dev.to

Introduction

大多数 React Native 开发者都曾有过这样的感受：

React Navigation 功能强大，但常常让人感觉…不自然。

这并不是因为它设计得不好——它并没有——而是因为使用它需要一次性在脑中记住大量的 导航仪式：

• 堆栈和嵌套导航器
• 屏幕注册
• 样板代码包装器
• 与 UI 分离的导航状态

你总是在 思考 导航，而不是直接 看到应用的结构。正是这种摩擦，使得它成为讨论 AI 能帮什么、不能帮什么 时的一个极佳例子。

The real problem wasn’t code

如果今天让 AI 工具去使用 React Navigation 搭建导航，它会做得非常出色：

• 生成堆栈导航器
• 注册屏幕
• 绑定参数
• 添加提供者和容器

这不是问题所在！问题在于 这些都没有解决导航一开始为何让人感到思维负担沉重。困难并不是：

“我不知道怎么写这段代码。”

而是：

“为什么我必须思考这么多才能理解我的应用结构？”

The abstraction shift: configuration → structure

这就是 基于文件的路由 在进入 React Native 生态时让人感到如释重负的原因。

使用 Expo Router，模型发生了变化：

• 文件夹变成了路由
• Layout 文件吸收了样板代码
• 屏幕被自动发现，而不是手动注册
• 导航结构 一眼即可看见

不再是 声明 应用结构，而是 表达 它。这不仅省去了代码行数——更是消除了整类思考方式。

This is the part AI didn’t do

AI 在 系统内部 工作得非常好：

• 填充样板代码
• 应用已知模式
• 优化已有实现

但这次的改变需要不同的东西：

• 从 API 中抽身
• 发现开发者的摩擦点
• 在工作流层面重新构思问题

AI 并没有某天醒来就决定：

“导航不应该是配置的——它应该是推断的。”

是人类做出了这个决定。这里的人类是 Evan Bacon，他通过一个看似简单的问题把更高层次的思维模型带入了 React Native：

“如果导航正好匹配开发者已有的思考方式会怎样？”

Why this matters in the age of AI

这个例子之所以有价值，是因为它很具体。AI 可以：

• 立即生成 React Navigation 代码
• 修复 bug
• 从文档中迁移模式

但它没有：

• 识别出导航是错误的抽象边界
• 通过重新设计思维模型来消除样板代码
• 决定 结构 应该取代 配置

随着 AI 降低了实现的成本，品味和抽象能力 变得更为重要，而不是更不重要。

A takeaway for developers

这并不是要害怕 AI 或者与之竞争，而是要认识到人类判断仍然最关键的地方：

• 发现大家已经习以为常的摩擦点
• 问 “为什么这很难？” 而不是 “我该怎么写代码？”
• 设计能够消除复杂性的系统，而不是仅仅管理它

基于文件的路由之所以成功，并不是因为它聪明，而是因为 当你看到它时，它显得理所当然。这种工作发生在 代码之上。

如果你今天已经在使用 AI 生成导航代码，那很好——应该这么做。

但像 Expo Router 这样的例子提醒我们，最有价值的工程工作往往发生在 写下第一行代码之前。