Stitch AI 的 remix 功能在共享项目上报 RPC 错误，换浏览器清缓存都没用

一个共享项目上的 remix 操作反复失败，控制台打印出 RPC failed: code=3 message= httpStatus=undefined，紧接着抛出 Error: ud3。用户换了 Chrome 和 Brave 两个浏览器、清了缓存、甚至单独开了一个 Google 账号隔离测试，错误依旧稳定复现。他自己项目的副本执行 duplicate 时同样报错，说明这不是某个项目的数据问题，而是 remix 这条调用链路本身卡住了。
错误堆栈指向 m=oxe1Cc 这个 bundle 文件里的一系列内部调用，从 _.AL 到 $Q 再到 b.Lm，最终在 MN.da 处抛出 RpcError。code=3 在 gRPC 语义里通常代表服务端内部错误，而 httpStatus=undefined 说明这个 RPC 调用压根没拿到一个明确的 HTTP 状态码——可能是连接层就没建立起来，或者服务端在返回响应之前异常中断了。ud3 这个错误标识符看起来像是服务端内部的某种编码，但官方文档里搜不到任何对应说明，只能等服务端日志配合排查。
用户已经做过的排查动作其实覆盖了最常见的前端因素：缓存污染、浏览器环境差异、账号权限。这些都排除了，问题大概率不出在客户端，而是出在 Stitch 后端处理 remix 请求的某个环节。共享项目的 remix 可能涉及权限校验、项目锁、资源复制等多个后端调用，任何一个节点超时或异常都可能表现为 code=3。
如果你正在踩这个坑，可以试试下面几个进一步的排查方向，比清缓存更接近问题根源。
确认是不是全网性故障
先别急着动自己的项目，找一下 Stitch 的状态页或者社区反馈渠道，看看是不是同时段有其他用户报同样的错误。如果是个例，那大概率和你当前项目的权限配置或数据状态有关；如果是一片报错，那就是 Stitch 后端有变更或者临时故障，等官方修复就行。
检查网络请求的实际往返
打开浏览器开发者工具，切到 Network 面板，勾选 "Preserve log"，然后重新执行一次 remix 操作。重点看发出的 RPC 请求的 URL、请求头和响应体。如果请求根本没发出去，问题在前端组装参数或路由阶段；如果请求发出去了但响应是空的或者被截断，那就是服务端的问题。另外留意一下有没有 CORS 错误或者 WebSocket 连接中断，remix 这类异步操作有时依赖长连接，网络中间件（比如公司防火墙、代理）可能悄悄断掉它。
复现时固定一个最小环境
用户已经试过单独浏览器和单独账号，但没有固定一个最小环境——也就是说，他用的项目是共享的，里面可能有其他协作者正在编辑。共享项目在 remix 时可能需要获取实时锁或最新版本，如果此时有别人在改同一个文件，服务端处理冲突时可能抛出未被捕获的异常，进而表现为 code=3。可以试试找一个没人编辑的时段，或者干脆复制一份私有项目再执行 remix，看报错是否消失。
抓取更完整的客户端日志
控制台报错的堆栈只到 MN.da，再往下的调用可能被压缩或者跨域了。如果 Stitch 支持开启 debug 日志（通常在设置或者 URL 后面加 ?debug=1 之类的参数），可以把日志级别调高，看看 ud3 是从哪个接口、传了什么参数的情况下抛出来的。拿到更完整的请求 ID 之后，联系官方支持时直接把 ID 给他们，后端能根据 ID 直接定位到具体哪台机器、哪个服务的日志，比口头描述 "RPC error" 有效得多。
临时绕过方案
如果 remix 报错但你又急需拿到 remix 后的 UI 结果，可以试试不通过 remix 按钮，而是手动复制当前项目为新项目，再在新项目里找找有没有 "AI generate" 或者类似的独立功能入口。有些工具的 remix 本质上是 "复制 + 触发 AI 生成" 的组合操作，拆开之后可能绕过那条有问题的 RPC 链路。
这个错误从现象上看，不像用户操作能直接修复的类型。反复尝试清缓存、换浏览器，其实是在等一个永远不会到来的客户端修复。把排查重心往后端转移——要么证明是服务端瞬时故障，要么拿到足够信息推动官方修底层逻辑——才是更有效的路径。