AI DApp 日志诊断：链上失败和前端错误要一起看

2026/7/5 7:16:05

AI DApp 日志诊断：链上失败和前端错误要一起看

一、DApp 故障经常跨越多层

DApp 用户遇到失败时，可能看到的是前端弹窗、钱包拒绝、RPC 超时、合约 revert 或链上确认失败。单看前端日志，很难判断问题根因。AI 日志诊断的价值，是把多层日志串起来，帮助研发快速定位。

但诊断输入必须完整。没有交易哈希、链 ID、钱包状态、RPC 响应和合约错误，模型只能猜。跨层系统越复杂，越需要结构化证据。

实际情况往往更棘手：用户过来反馈时只说"交易失败了"，不记得有没有交易哈希，也分不清是钱包拒签还是合约 revert。诊断系统在这一刻要做的第一件事不是下结论，而是引导用户补充关键信息：是否看到了钱包弹窗、是否点了确认、交易哈希是否存在。这个信息补全过程本身就是诊断链路的一部分，AI 可以在这里生成针对性的追问，而非返回模糊的"请重试"。

二、诊断链路要统一 trace

flowchart TD A[用户操作] --> B[前端事件] B --> C[钱包签名] C --> D[RPC 请求] D --> E[链上交易] E --> F[合约事件] B --> G[统一 Trace] C --> G D --> G E --> G

每次用户操作都应该生成 traceId，并贯穿前端、后端、RPC 代理和链上事件索引。链上交易哈希可以作为重要关联键，但在签名前还没有交易哈希，所以前端 traceId 仍然必要。

错误分类也要统一。钱包拒签不是系统失败，RPC 超时不一定代表交易失败，合约 revert 需要解析原因。分类越细，AI 诊断越有价值。

三、日志字段要为诊断服务

type DappTraceEvent = { traceId: string chainId: number wallet: string action: string txHash?: string rpcProvider?: string errorCode?: string revertReason?: string }

隐私字段要谨慎处理。钱包地址可以哈希化或只展示短地址，用户输入和资产明细不应无差别进入日志。诊断系统不是数据仓库，收集足够证据即可。

dapp_diagnosis: collect_revert_reason: true collect_rpc_latency: true mask_wallet_address: true retain_days: 14

保留周期也要控制。调试需要日志，但长期保留敏感操作轨迹会带来隐私风险。

四、AI 输出要给排查路径

好的诊断结果不只是“可能是 RPC 问题”，而应该给下一步：换 RPC 复测、检查合约事件、确认用户是否拒签、查看区块确认状态。每条建议都应对应可执行动作。

对于高频故障，可以把诊断结果沉淀为规则。比如某个 RPC 节点在特定链上频繁超时，就自动切换备用节点，而不是每次都让模型重新分析。

诊断系统还要保留用户可见的解释。研发日志可以很细，但用户只需要知道交易是否还在等待、是否需要重试、资金是否已经离开钱包。AI 诊断可以生成面向用户的短提示，但必须基于确认状态，不要在链上结果未定时给确定结论。

dapp_user_message: pending_tx: "交易已提交，正在等待链上确认" user_rejected: "签名已取消，资产未发生变化" rpc_timeout: "网络节点响应超时，请稍后刷新状态"

高价值操作还要有人工排查入口。用户资产相关问题不能只靠自动诊断，系统应能把 trace、交易哈希和错误分类打包给客服或研发，减少来回询问。

复盘时要把诊断结论和最终根因对比。模型判断错了，就把样本加入评测集；规则命中了，就把它固化为自动化检查。诊断系统只有持续回收真实案例，才会越用越准。

还有一个场景值得单独设计：Gas 价格异常导致的失败。用户以过低 Gas 发起交易，交易在 mempool 挂了很久最终被丢弃，但链上没有任何失败记录——因为交易根本没上链。这种场景下，前端超时、RPC 无返回、链上查不到都是正常现象，AI 诊断却很容易判断为"未知错误"。系统需要对比发起时的 Gas 建议和当前网络 Gas 均值，在诊断结果里加入"交易可能因 Gas 过低未被包含，当前网络建议 Gas 为 X"这类提示。