/assign @liyuanqiang

/assign @liyuanqiang

感谢提出错误码分类整改建议。您描述的核心问题是：E*9*** 同时用于用户输入、Host/Tiling 和框架资源等不同场景，难以据此判断错误来源及处理方式。按错误原因细分类别，有助于减少排查歧义；但具体调用是否分类不当，还需要结合错误码定义和触发条件确认，不能仅凭错误发生在 Host/Tiling 阶段就认定为内部错误。

一个可行的方向是，先明确用户输入不合法、资源不足、内部异常等场景的分类规则，再调整对应的错误上报入口和调用点。现有片段中既有 err/ops_err.h 的引入，也有通过 log/log.h 使用 OP_LOGE 的路径，但这些片段尚不足以确定它们最终生成的错误码，不能直接据此统一替换。整改时还需区分日志错误码与接口返回值，避免分类调整意外改变接口行为；同时考虑依赖旧错误码的日志检索、告警规则和排障文档如何兼容。

为明确本次整改范围，请补充图片中涉及算子的文字清单，以及一条具有代表性的完整错误码和对应报错信息，便于对照具体调用点与分类规则，进一步评估调整范围。