您好，感谢反馈！

问题分析

核查 cann/ops-math 固定提交 b19eaee4f58e5e1e3cb3b2ecbfed2d02c11c820a 后，确认 Pad README 的“仅包含 ACLNN 接口、欢迎贡献 AscendC 实现”与当前源码不一致。pad_apt.cpp 是有效的 pad kernel 入口，会按 tiling key 调用常量填充和切片处理分支；共享代码位于 conversion/pad_v3/op_kernel/arch35/，其中 pad_constant.h 包含具体 kernel 的启动逻辑，pad_slice.h 提供切片分发。host 侧也从 pad_tiling_arch35.cpp 创建共享的 PadACTiling 并执行 DoTiling()。因此这里需要准确补充实现入口和共享位置。

接口与资料还应区分层次：本目录 op_api/pad.cpp 定义的是内部 l0op::Pad 调度，CMake 使用 aclnn_exclude，现有 test_geir_pad.cpp 也是 GE IR 样例，不宜直接称为独立公开 ACLNN 接口及 ACLNN 样例。本目录确实没有 docs/；Pad 的输入、输出及约束可以先查看 pad_proto.h。若需要公开 ACLNN 常量填充用法，已有的相关资料是 PadV3 目录下的 aclnnConstantPadNd，其 pad/value 参数形式和产品支持表属于该接口，不能直接当作 GE Pad 的同名接口说明。

这次确认的是文档与源码交付内容之间的矛盾。Pad 的这套共享实现使用 arch35 路径，构建配置按 ascend950 等计算单元选择相应 tiling；仅凭存在入口不能推断所有产品、类型都走此实现，也不表示已完成设备验证。

处理方向

一个可行的调整是替换占位句，分别列出内部调度、GE 参数说明和样例、AscendC 入口及 PadV3 共享实现，并为相关 ACLNN 资料明确标注接口名称与适用范围，避免新增不存在的 conversion/pad/docs/ 链接或复制共享模块的全部能力声明。

CI 可以先针对“声称仅有接口，但存在有效 kernel 入口”的明确矛盾建立检查，结合入口调用、共享依赖和构建配置判断，排除 .gitkeep 与空壳；“本目录无独立 kernel”本身不应作为失败条件。具体识别规则和误报成本仍需评估。与 #3691 的清单同步，可在实际修订合入并核验链接后回填 Pad 的变更与结果；本条目前仍待文档修订落地。我们会继续跟踪这处资料入口与实际交付内容的一致性。