本文へ移動
cccskills
無料GitHub で公開

dev-workflow

MindIE-SD 仓库开发总入口（侧轨）。当用户进行 MindIE-SD 的任何代码开发工作时使用此 skill—— 包括但不限于写 pattern、改测试、部署到昇腾、跑 benchmark、性能分析、多卡并行、复盘归档。 模型/三方框架自动优化类任务（非本仓代码改动）由 model-auto-optimization 入口承接， 本入口只在优化流程需要新增 pattern/算子/部署代码时承接其指向的开发子任务。 即使用户未明确提到"开发流程"，只要涉及 MindIE-SD 代码改动都应触发。

Ascend/MindIE-SD
インストール方法を見る

含まれるファイル（5）

  • SKILL.md16.4 KB
  • evals/evals.json5.4 KB
  • references/ascend-ops.md3.0 KB
  • references/cross-platform.md1.1 KB
  • references/rework-lessons.md18.1 KB

SKILL.md（原文）

インストールする前に、エージェントに与えられる指示の中身を確認できます。

MindIE-SD 开发工作流

0. 入口分流

  • 本入口是 MindIE-SD 仓库开发入口（侧轨）：改 pattern / 算子 / 图下发 / 测试 / 文档等本仓代码。
  • 对一个三方框架托管的模型做接入、无损/有损优化、并行调优或性能收益确认（不指向本仓代码改动） → 先读 model-auto-optimization/SKILL.md，按 S0–S6 流水线路由到 env-install、framework-integration、 profiling-collect、profiling-analyze、dit-perf-opt、dit-parallel-opt、vae-opt、host-opt、performance-optimization 等能力技能。
  • 优化流程需要新增 pattern / 算子 / 部署代码时，由 model-auto-optimization 指向本入口承接开发子任务。
  • 三方框架自身结构性缺口补齐（comm-stream / 缓存 / 稀疏/量化消费者等，经 model-auto-optimization §0 用户确认）→ 先加载 ../framework-integration/SKILL.md（框架差异/注入点/合入姿势）， 实现仍按本入口开发子任务执行（Test-First → 部署 → 验证 → 复盘）。

0.1 开发子任务路由（按代码落点定侧）

框架 × mindiesd 的合作界面随框架而异，开发与特性开发常有重叠区；分工按「改动文件在哪个仓库」 一刀切，路由如下：

改动落点路由流程/说明
mindiesd 本仓（pattern / kernel / 图下发 / 测试 / mindiesd/parallel 等）本入口 + pattern-dev / operator-dev / aclgraph-dev（按实现类型）本 SKILL 主流程：Test-First → 部署 → pytest → 复盘
三方框架仓（框架已有特性接线/开关/小修 → 分支 A；框架未支持的结构性开发 → 分支 B）framework-integration（先加载：差异表 / 注入点 / 合入姿势）分支 A = 使能回路验证（计数契约 + 三层证据）；分支 B 实现按本入口子任务执行
跨侧重叠（同一特性 mindiesd + 框架两侧都改）按文件拆两侧子任务：mindiesd 侧走本入口开发技能；框架侧按上两行路由对接点联调收口（输出一致 + 计数契约 + 三层证据）；接口差异记录 framework-support-matrix.md
环境 / 权重 / 部署env-install + remote-access非代码开发

判断口径：先问「要改的文件在哪个仓库」；同一 MR 跨两仓时先确认合入渠道（上游 PR / fork 钉版本）， 再拆子任务执行。

0.2 流程门禁（先验收后推进）

  • 每个功能点闭环（写测试 → 实现 → 部署 → pytest）的验证输出（命令 / 退出码 / 关键结果）随 实施记录留痕；缺失或与产物矛盾时不得宣称该功能点通过。
  • 复盘检查（§6.3）在本轮全部功能点收尾后执行；发现流程偏离（如计划并行实际串行）先在复盘 记录原因，再进入下一轮工作。
  • 被 model-auto-optimization 指向的模型优化子任务，遵守其 run-state 推进表与 model-auto-optimization/scripts/stage_gate.py 门禁（见 model-auto-optimization/references/run-state.md）， 本入口按 dev-workflow 复盘与提交流程承接代码改动侧。

0.3 交付件契约（L1 编排协议：开发任务必交）

三层定位：本 SKILL 是 L1 编排入口——负责分流/路由、顺序契约（Test-First、并行、 复盘时机）与交付件契约；单任务的"最佳实现路径/回退"（pattern 生命周期、算子 DSL 选择、 mismatch 回退）由 L3 能力自身工作流纪律承载（pattern-dev / operator-dev / …）； L2 为内联轻量（本节即 L1 契约，暂不拆独立 workflow 文件）。

顺序契约（引用）：功能点走 §1 Test-First（先测试后实现）；独立模块按 §3 并行、共享文件后 合并；复盘在 §6 收尾执行。

交付件契约（开发任务必交，缺一不宣称完成/不进入提交）：

  • 功能点证据行：测试预期 FAIL → 实现 → 部署编译 → pytest PASS 的命令/退出码/关键结果留痕 （与 §0.2 门禁一致）；
  • pytest 通过输出（或明确注明未跑原因）；
  • 复盘记录：§6.3 复盘清单执行结果；发现流程偏离先记原因；
  • 回填与同步：可复用经验按 §6.4/.agents/README.md §7 回填（rework-lessons / case / skill 刷新），涉及公共流程面同步 README；
  • 提交规范：按 mindie-sd-community-governance（commit/PR 格式、模板四区块）；
  • 被 model-auto-optimization 指向的子任务：遵守宿主 run-state 推进表/迭代表 + stage_gate 门禁， 本入口只承接代码改动侧并按上述契约收口。

为 dev 拆独立 L2（workflow 文件）的信号：出现跨多个能力、多阶段、有顺序门禁与逐阶段 确认点的开发线（如端到端融合算子合入链）时，为该线新增 workflows/{line}.md，机制复用 L1 协议（迭代表/证据行/stage_gate），并把本节契约改为引用。

1. Test-First 流程

每个功能点必须遵循「先测试，后实现」的闭环：

写测试（预期 FAIL） → 实现功能 → 远端部署编译 → 远端 pytest 验证 → 进入下一阶段
  • 测试必须覆盖：输出正确性 + 耗时验证
  • 新功能的测试应先写，确认 FAIL 后再写实现
  • 编码过程中遵循 code-standards 规范（Ruff lint、pre-commit 钩子、代码风格约定）
  • Markdown 文件的格式检查由 markdown-lint 规范覆盖，提交前需通过 pre-commit run markdownlint 检查

1.1 Pattern 开发专项

若任务是新增或调试 MindIE-SD compilation pattern（RMSNorm / RoPE / AdaLayerNorm / GELU 融合）， 路由到 pattern-dev skill 获取全生命周期指导：模型代码分析 → pattern 创建 → 注册 → 单元测试 → mismatch 调试 → 集成验证 → Copy 消减。 算子本体（triton kernel 编写/调优）→ operator-dev；批量下发（aclgraph）→ aclgraph-dev。

2. 模型验证

写实现前，在 NPU 上用 dummy-run 的 Dummy Run 方法快速验证模型架构兼容性， 不必下载完整权重。如果已通过验证则跳过。 部署完成后，使用 framework-integration 验证已部署模型在框架侧的推理正确性（1 步推理/特性开关）。

3. 并行开发策略

无代码依赖的独立模块并行推进，共享文件最后合并：

  • 每个模块走独立闭环：写测试 → 实现 → 部署 → 各自 pytest
  • 多卡验证时通过 env-install + remote-access 部署到不同 NPU 卡隔离运行
  • 共享文件（如 patterns/__init__.py、passes/__init__.py）的修改在最后统一合并
  • 部署时一次性推送所有文件到远端，验证阶段使用不同卡 ID 并行运行

含子 agent 的并行（多 agent 场景）：并行单元 = 模块/特性 × 阶段 × 卡组。角色分工（主控 / 代码开发 / 结果分析 / 部署与资源分配）、交付件与指针链、交接单、资源租约与收口单点在 model-auto-optimization/references/agent-roles-and-handoff.md——派发前先过其 §1 扇出判据 （不满足即自执行）。本入口的三条落地约束：

  • 按工作性质拆分（先分类再谈并行）：纯算子开发（operator-dev，判据=逐位/数值门 + 算子级 微基准）、框架接入（注入点/图适配，判据=图真实命中 + kernel diff）、特性使能（开关 + 计数契约 + 同窗 A/B）是三类不同工作——技能面与验证口径不同，必须拆不同子 agent （混在一个 agent 里会串用判据：拿对拍口径判"使能生效"）。同类工作默认共用一个 agent 顺序推进；
  • 开发与部署分离：代码开发角色只改代码仓；卡组 / 容器与实验窗口由部署与资源分配角色 签发租约（一次一实验、卡组互斥、超时回收），开发不得自行占卡；
  • 交付靠文件：每个并行单元交回执（命令 + 退出码 + 证据路径）落 evidence/{task_id}/{stage}/{feature}/；结论须由未参与实施的实例复核后才允许进报表或宣称；
  • 合并时机：共享文件、git worktree / 分支、构建产物与编译缓存等冲突面在单元收敛后由主控 统一合并；合并后跑一次全量 pytest（合并本身是新变量，须重验）。
  • 性能对比与代码改动不得真并行（同环境污染口径）：同一环境里边改代码边跑多卡对比，量到的是 "改动 + 时间"的混合量，对照臂已失效 ⇒ 性能对比单元与代码改动单元串行，或代码冻结后再测； 确需并行时，两臂必须落在互不干扰的环境（独立容器/卡组 + 各自的冻结副本），否则该组读数作废 （口径纪律见 ../perf-gate/references/measurement-discipline.md）。

4. 远程部署

本地编码完成后用 env-install 的部署流程（remote-access 提供 SSH 工具）将代码推送到昇腾容器，编译验证。

→ 部署的 shell 脚本隔离、跨平台编码注意事项见 references/cross-platform.md。

5. 性能评估与优化

功能验证通过后，用 profiling-collect 采集真实 NPU 数据、profiling-analyze 分析并建立性能基线。 Benchmark 计时方法论（warmup / 同步 / 编译预热排除 / L2-flush 放计时区外 + warm·cold 双档 / 多场景对照）见 benchmark-dev/references/benchmark-guide.md。

采集完成后用 profiling-analyze 定位瓶颈，用 dit-perf-opt 选择优化方案（瓶颈未明时先走 model-auto-optimization 的分析）。 多卡场景参考 dit-parallel-opt 选择并行策略。

6. 复盘归档

每个 Phase 完成后按以下流程复盘：

  1. 回顾本阶段问题点和改进点
  2. 检查是否需要补充 references/rework-lessons.md
  3. 交叉检查各模块 skill 需不需要更新
  4. 同步刷新 .agents/README.md 的技能清单（§1/§2 表）与目录树（§6）——不写状态/进度： 过程记录与待办不入该文件；历史查 git log。

识别更新信号

出现以下情况时必须检查 skill 是否需要更新：

  • 同一类问题重复出现 ≥ 2 次
  • 开发流程偏离预期（如计划并行但实际串行）
  • 发现新的可用算子或确认算子不可用
  • 远端环境发生变化（torch/TorchNPU 版本更新）
  • 出现新的有效工作方法

6.3 复盘检查清单

复盘时逐一确认：

检查项说明
目标范围是否在第一步就确认了文件路径与影响面？
文件编码批量操作前是否验证了 UTF-8 含中文文件的编码安全性？
匹配覆盖正则/替换模式是否覆盖了所有变体（缩进围栏、嵌套代码块）？
工具一致性本地 markdownlint 版本与配置是否与 CI 一致？
动作的作用域启动与收尾都要审：这一步会不会自己产生副作用（如"推送即执行"把脚本跑起来）？清理是否只落在自己这一组（PGID / 端口），有没有按类名全机匹配的 pkill？——我们习惯只审启动（资源/配额/并发）而默认收尾安全（见 ../remote-access/references/arm-driver-traps.md §5）
计数口径用于"发生了几次"的 grep 是否锚在只有成功路径才打印的行上，并用同一份日志里另一个独立计数器交叉验？（见 ../perf-gate/references/evidence-toolbox.md §4.3）
总览/细分报表模型优化类闭环是否输出 overview_report.md 与 detail_report.md（总览：基线=TP 多卡未优化、三层级行组 + 每特性组合搜索数据；细分：融合算子逐项收益与剩余机会、并行候选与带宽、稀疏/量化(FA+线性层)/cache 与采样步数、组合矩阵）？

6.4 实验 → case 回填

复盘确认新经验需沉淀为 case 时，按 .agents/README.md §7「case 回填规范」执行： 先做「经验 vs 探针」判定（临时方案/一次性补丁/诊断绕法 → 只作 [探针] 归档，不进 推荐姿势/经验槽位/宣称；发现的 durable 约束事实按经验沉淀并注明来源）→ 归属判定 → case 模板 → SKILL.md 接线（Reference Files + 加载时机）→ evals 增补 → 隐私清理 → 校验（markdownlint / JSON / ruff）。

Reference Files

  • ../pattern-dev/SKILL.md — 加载时机: 编写或修改 compilation pattern 时
  • ../aclgraph-dev/SKILL.md — 加载时机: 静态 shape 大 batch 需要批量下发时
  • ../operator-dev/SKILL.md — 加载时机: 算子本体开发/调优（复用 cannbot-skills）时
  • ../framework-integration/SKILL.md — 加载时机: 三方框架特性使能/验证（分支 A）或框架侧缺口补齐开发（分支 B）时
  • ../env-install/SKILL.md — 加载时机: 部署/编译安装、权重准备与远端环境就绪时
  • ../remote-access/SKILL.md — 加载时机: 需要在远端昇腾执行命令、选空闲卡或传文件时
  • ../dummy-run/SKILL.md — 加载时机: 实现前做模型架构/算子接入快验时
  • ../code-standards/SKILL.md — 加载时机: Python 编码与 lint 规范（Ruff / pre-commit）时
  • references/ascend-ops.md — 加载时机: 涉及 NPU 算子调用或环境诊断时
  • references/cross-platform.md — 加载时机: 跨平台部署或遇到 PowerShell/编码兼容问题时
  • references/rework-lessons.md — 加载时机: 每次复盘归档时，或遇到相似问题需查历史教训时
  • ../markdown-lint/SKILL.md — 加载时机: Markdown 文件格式检查（跨 skill 引用）

维护与更新

当开发流程发生偏离、出现新的返工模式、或模块间关系变更时更新本 skill。 各子模块 skill 的更新触发条件参见各自的"维护与更新"章节。

新增 Skill 规范

当需要新建 skill 时，遵循 Anthropic skill-creator 指南，以下为必检清单：

  • 目录结构: {skill-name}/SKILL.md + 可选 scripts/ references/ assets/ evals/
  • SKILL.md < 500 行，超限用 references/ 拆分（progressive disclosure）
  • frontmatter 必须含 compatibility：声明运行依赖（工具/环境/外部技能库）
  • description 要 pushy：明确写清触发条件（what + when-to-trigger），覆盖 near-miss 边界 （"看似相关但不应触发"的场景），避免 undertrigger 与误触发
  • 必须建 evals/evals.json：≥2 条真实用户 prompt（prompt / expected_output / expectations， 格式遵循外部 skill-creator 仓的 references/schemas.md）；新增或大改 skill 后必须同步增补
  • references 必须全部接线：在 SKILL.md 列出 Reference Files + 加载时机；>300 行的 reference 必须带目录
  • references 必须含"维护与更新"章节，写明更新触发条件
  • 单 skill 单职责：不同模块/领域的内容拆分为独立 skill
  • 模型/框架专属知识放 references/{variant}/ 子目录（如 dummy-run/references/minimax-h3-notes.md 是「模型底座」类，平铺也合法；新拆的模型子目录才用 references/models/<模型名>/），避免平铺
  • 命名：小写连字符，业界通用名（如 env-install、dummy-run）
  • 新 skill 必须包含"维护与更新"章节
  • 改动 skill 后跑两个校验器：本仓结构门禁 .agents/scripts/kb_lint.py（error=0 / warn=0 方可提交）
    • 外部 skill-creator 仓的 quick_validate.py <skill 目录>（校验 frontmatter 键、命名与长度上限）。 Windows 实测陷阱：外部校验器读 SKILL.md 时不指定编码，在中文文件上直接 UnicodeDecodeError（看起来像"技能文件坏了"，实为平台默认编码）—— 加 PYTHONUTF8=1 再跑即 Skill is valid!。两个校验器都过，才算改完（产物是新文件：references/scripts 还要过接线与自测）。

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

ログインしてレビューを書く

同じリポジトリのスキル

概要と使いどころ

accuracy-gate

無料

**精度验收标准**：凡是"改动不应改变结果"的场合（等价替换、算子/子模块融合、并行切分、 编译与图下发、拷贝消减），都按本标准判"合格 / 不合格"——等价分层（L1 逐位 / L2 数值门 / L3 有损门）+ 三级验收序（① 同配置重跑逐位 → ② 跨配置数值门 + 产物 md5 不变 → ③ 质量门）+ 判据不达标时的排障入口。当用户说"这个算子能不能换个写法/换个 kernel/等价实现/ 无损替换""替换后结果会不会变""怎么证明逐位一致""结果不对""花屏""尾部塌了" "CPU 跑对 NPU 跑不对"，或发现某个 hotspot 占了大头（例如某类算子在阶段里占 90% 以上）想动手时， 都应触发；即使用户只说"这样改有没有把结果改坏""能不能判它是无损的"也应触发。 覆盖：等价分层与判据、满足本标准的实现约定（per-shape 对拍写进实现，把索引/相位/顺序类重写 错误在首次调用抓住）、per-shape 条件性等价（同一改动在不同形状下结论可能不同）、 判据不达标 → `references/silent-failure-localization.md` 排障入口、否决案例的形态学 （换写法未换 kernel / 差异极小仍非逐位 / 等价但 OOM）、以及收益口径的归属（性能数字一律交 `perf-gate`）。 **近义分流**：选量化档 / 特性选档（要不要开量化、开哪一档）→ `dit-perf-opt`； 并行选型（USP / CP / TP 怎么切）→ `dit-parallel-opt`；本技能只判"结果是否被改变"， 不负责选档与选型。

日本語の概要は準備中です。原文の説明を表示しています。

Ascend/MindIE-SD152026年10月10日 更新

aclgraph-dev

無料

NPU 图批量下发能力（aclgraph / aclgraph_ex 家族）的开发与调优。覆盖 mindiesd 的 aclgraph_backend：NPUGraph 静态 capture、全局 graph pool、 lazy capture、专用 copy stream + event 管线、shape/dtype 校验、max_entries 驱逐。 当用户需要减少 host launch 开销、静态 shape 大 batch 场景加速、 或排查 NPUGraph replay 输入不匹配问题时使用此 skill。 即使用户只提"批量下发""graph capture""图捕获"而未说 aclgraph，也应触发； pattern/Inductor 融合（default 后端）见 pattern-dev，算子本体见 operator-dev， 本技能只覆盖图批量下发。由 dev-workflow 的编译开发阶段与 model-auto-optimization 的 图下发场景指引加载。

日本語の概要は準備中です。原文の説明を表示しています。

Ascend/MindIE-SD152026年10月10日 更新

benchmark-dev

無料

MindIE-SD 核心算子（FA/BSA/GMM/MM）性能基准工具链。使用：模型优化（model-auto-optimization 的 S1/S4 选型）中用 mindie_bench 对单算子做实现级实测，按 dtype/量化档/稀疏度/形态对比 选出最优配置（产物：选型证据；稀疏度-性能曲线供 S4 稀疏度选型）；开发：benchmarks/ 工具链扩展与新算子接入测试（供 operator-dev / pattern-dev 调用）。 当用户需要对比算子实现选型、新增或修改 benchmark 代码、排查 benchmark 数据异常、 给基准加算子/指标时使用；即使用户只说"benchmark 数据不对""给基准加个算子" "对比下这几个 FA 实现哪个快"也应触发；特性级方案选档请走 dit-perf-opt （本 skill 只做实现级实测）。 由 model-auto-optimization 的 S1/S4 选型场景与 operator-dev 的算子接入验证场景调用， 亦由 dev-workflow 在基准开发时指引加载。

日本語の概要は準備中です。原文の説明を表示しています。

Ascend/MindIE-SD152026年10月10日 更新

code-standards

無料

MindIE-SD Python 代码格式与 lint 规则。当编写、格式化、lint 检查或审查 MindIE-SD 项目的 Python 代码时使用此 skill。 即使用户只提到"提个MR"或"代码好像有 lint 问题"而未明确说格式化，也应触发；Markdown 格式问题见 markdown-lint，提交/PR 规范见 mindie-sd-community-governance。 通常由 dev-workflow 在编码阶段指引加载。

日本語の概要は準備中です。原文の説明を表示しています。

Ascend/MindIE-SD152026年10月10日 更新

dit-parallel-opt

無料

分布式并行策略选型与实测（USP / CP 通信掩盖 / CFG / TP/RSP/PP 概览；含拓扑相关选型 （按实测拓扑分域条件化：域内 bulk vs 跨域 head-parallel 翻转）与 AlltoAllV 缺陷绕过）。在 model-auto-optimization 中承担 S3：优先 USP、结合拓扑带宽差异选 CP，少量 step + 多 rank 验证特性开启与掩盖（产物：并行方案 + 多 rank 证据）。当用户需要多卡并行 策略选择、**序列并行形态抉择**（纯 Ulysses vs 复合 AllGather-KV×Ulysses：按 GQA / 跨域带宽 / 形态 plumbing 条件化定胜负）、**并行 × 稀疏叠加**（seam 契约：先汇聚后稀疏、 窗口偏移、块对齐、per-head 掩码；含「稀疏看似生效实则未生效」判定）、通信掩盖调优 （含**掩盖率上限**：1-1/n 何时成立、c/f 决定的真实上限、没生效的排查）、**并行方案 差异归因**（阶段 Δ 分解 / 集合通信按 communicator 归属 / 4→8 卡线性度），或排查多卡 跑不动 / 通信暴露大 / 换卡组 / 端口 bind / HCCL 带宽验证问题时使用；**并收编原并行作用域诊断**： 改了 SP/CP/Ulysses/AllGather-KV 后**不报错但结果没变/性能没变**、或小规模能跑大规模崩 （如 Ascend EE1003 coreDim 超限）时，用本技能证明"改动到底有没有生效"（判别量逐层收窄 + 两侧对照 + 日志≠生效，见 `references/scope-effectiveness-check.md`）； 即使用户只说 "多卡跑不动""通信暴露大""为什么没达到 6/7 的掩盖率""CP 和 USP 该选哪个""CP 叠稀疏 怎么不生效"而未说并行，也应触发。特性档位/接口事实见 `docs/zh/features/parallelism.md` /`usp.md`（仓内真源），框架侧开启见 framework-integration； 本技能承载选型决策、monkey-patch 掩盖与多卡诊断实测。 由 dev-workflow 多卡场景触发，亦由 model-auto-optimization 的 S3 阶段触发。

日本語の概要は準備中です。原文の説明を表示しています。

Ascend/MindIE-SD152026年10月10日 更新

dit-perf-opt

無料

DiT 计算模块（L3）：把**已定位的 DiT 计算瓶颈**落成特性级选档与实施—— 量化档（W8A16 / W4A16 / W8A8 系列 / W4A4 / MXFP8 / FA 量化）、稀疏（rf_v2 / ada_bsa）、 缓存（DiTCache / AttentionCache / 时间步优化）、编译启用（MindieSDBackend / Pattern 融合 / ACLGraph） 的**开不开、开哪一档、怎么开、怎么复验**；依据是 `docs/zh/features/*`（特性真源）+ framework-integration/references/framework-support-matrix.md（支持状态）。 即使用户只说"这个模型怎么加速""量化/稀疏/Cache 怎么选怎么开""要不要开量化、开哪一档""这个档位开了有没有效果" 而未提 profiling，也应触发。 **入口条件**：瓶颈点已明确（用户带一句实测锚点，或编排层交付标签）时由域入口 `performance-optimization` 按标签分发到本技能；**瓶颈未明（"怎么加速 / 跑通 / 采 profile"）先走 `model-auto-optimization` 定位**，不在本技能内做占比分析。 near-miss：多卡并行形态 / 通信掩盖 / TP·offload 选型 → `dit-parallel-opt`；VAE 解码段与 host 固定开销 → 各自模块（VAE / host）；单算子实现级实测选型（mindie_bench）→ `benchmark-dev`； 需要新增 pattern / 算子才能落地本档 → `pattern-dev` / `operator-dev`；框架侧开关与使能验证 → `framework-integration`；量化器位级契约与精度对齐（编码公式 / 舍入 / scale 粒度）→ `quantization-dev`；精度验收判据 → `accuracy-gate`；数字入库口径 → `perf-gate`。

日本語の概要は準備中です。原文の説明を表示しています。

Ascend/MindIE-SD152026年10月10日 更新

Ascend のスキルをすべて見る

このスキルの問題を報告する