一个应用从单页扩展到多个页面后，导航和参数传递很快就会成为维护重点。以物品列表和详情页为例，点击某条记录后，详情页需要知道当前物品的 ID，再加载对应数据。如果只让 AI 写一个跳转动作，常常会忽略参数约定、返回行为和无效 ID 的处理。

我会先明确页面之间传递什么。通常只传递稳定的业务标识，例如 itemId，而不是把整个对象都塞进路由参数。这样详情页可以根据 ID 获取最新数据，也减少对象结构变化带来的耦合。

下面用伪代码表达路由思路。实际项目中应按当前 HarmonyOS SDK 和工程采用的路由方案替换对应 API。

代码示例

// 列表项点击时：传递稳定的业务 ID

function openItemDetail(itemId: string) {

 // 使用项目当前采用的路由 API 发起跳转

 // 路由参数示例：{ itemId: itemId }

}

// 详情页加载时：读取并校验参数

function loadDetail(itemId: string | undefined) {

 if (!itemId || itemId.trim().length === 0) {

   // 展示“信息不存在”状态，并提供返回入口

   return

 }

 // 根据 itemId 查询详情数据

}

AI 生成路由代码时，我会让它先确认项目正在使用哪一种导航机制，避免混用不同版本或不同方案的 API。随后重点检查参数类型、页面返回后列表状态是否保留，以及记录被删除后详情页如何处理。

这类功能适合采用“先定契约，再生成实现”的方式：列表页负责提供 ID，详情页负责验证参数和加载数据，数据层负责查询记录。只要边界清楚，后续增加编辑页、收藏页或分享入口时，就不必把所有逻辑重新写一遍。

在代码评审中，我也会检查跳转目标是否明确、参数是否经过校验，以及页面退出时是否存在多余的请求或状态残留。路由不是单纯的页面切换，它也是页面之间的业务契约。