我想搞个工具方便以后做Unity的Shader代码质量检查，例如效率~兼容性等问题，我担心之前…
2026-03-05
[ BACK ]
HUMAN HUMAN

我想搞个工具方便以后做Unity的Shader代码质量检查，例如效率~兼容性等问题，我担心之前的代码效率很糟糕。 该怎么做？你有好的建议吗？ 而且我希望你 OPUS4.6 能出一次方案，以后让稍微低一级的model，也能帮我良好地refresh可以吗？ 希望你能考虑得全面点。

claude-opus-4-6 AI

Unity Shader 质量检查方案

好的，我来给你一套完整且可复用的 Shader 质量检查体系，目标是：

  1. 你自己能快速跑检查（不依赖特定 AI 模型）
  2. 任何 AI 模型拿到检查清单都能执行（降低模型依赖）
  3. 覆盖效率、兼容性、可维护性三大维度

一、建议的工具形态：检查清单 + 提示词模板

不需要写一个独立软件。最实用的方式是：

  • 一份结构化检查清单（Markdown），列出所有检查项、严重等级、修复建议模板
  • 一个提示词模板，把 Shader 代码喂给任何 LLM 都能跑出格式化报告
  • 可选：一个简单的 Python/Shell 脚本做静态扫描（正则匹配明显问题）

这样的好处是：零依赖、版本可控、任何模型都能用。

二、检查维度与具体检查项

A. 效率（Performance）— 最关键

# 检查项 严重度 说明
P1 Fragment Shader 中的分支语句 🔴 高 if/else、switch 在 fragment shader 中会导致 warp divergence，移动端尤其致命。用 step()/lerp()/saturate() 替代
P2 纹理采样次数 🔴 高 每个 pass 的纹理采样数。移动端建议 ≤4 次/pass，PC 端 ≤8 次
P3 数学精度滥用 🟡 中 fragment shader 中用 float 而非 half/fixed。颜色、UV 用 half 足够，只有位置计算需要 float
P4 冗余计算未提到 vertex shader 🟡 中 逐像素做的计算是否可以移到 vertex shader（如光照方向归一化、UV 变换）
P5 未使用的 varying/interpolator 🟡 中 声明了但未使用的 varying 仍占 interpolator 槽位
P6 pow() / sin() / cos() 滥用 🟡 中 这些是昂贵操作，查看是否可用近似（如 x*x 替代 pow(x,2)）
P7 discard / clip() 使用 🟡 中 破坏 Early-Z，影响 GPU 的深度剔除优化。确认是否真的需要 alpha test
P8 多 Pass 渲染 🟡 中 每个额外 pass = 额外一次 drawcall + 状态切换。能合并就合并

B. 兼容性（Compatibility）

# 检查项 严重度 说明
C1 Shader Model 目标 🔴 高 #pragma target 设置是否与目标平台匹配。移动端不要超过 3.0
C2 平台相关宏 🟡 中 是否正确使用 UNITY_UV_STARTS_AT_TOP、UNITY_HALF_TEXEL_OFFSET 等
C3 Metal / Vulkan 兼容 🟡 中 避免 HLSL-only 语法，用 Unity 的跨平台宏（CBUFFER_START 等）
C4 Fallback 声明 🟢 低 是否有 Fallback "Diffuse" 或合理的降级方案
C5 SRP 兼容性 🟡 中 用的是 Built-in RP、URP 还是 HDRP？include 路径和宏是否匹配

C. 可维护性（Maintainability）

# 检查项 严重度 说明
M1 硬编码魔数 🟡 中 数字常量应提取为 #define 或 Properties 暴露
M2 命名规范 🟢 低 变量命名是否自解释，_MainTex 等是否遵循 Unity 惯例
M3 注释覆盖率 🟢 低 复杂算法是否有注释说明意图
M4 Properties 与实际使用一致 🟡 中 声明的 Properties 是否都在 shader 中使用了，有没有遗漏

三、提示词模板（喂给任何 LLM）

你是一个 Unity Shader 质量审计员。请按以下检查清单逐项审查下方的 Shader 代码，输出格式化报告。

## 输出格式

对每个检查项输出：
- ✅ 通过 / ⚠️ 警告 / ❌ 问题
- 问题所在行号
- 具体问题描述
- 修复建议（给出代码片段）

## 检查项

### 效率
- P1: Fragment 中的分支语句（if/else/switch）→ 建议用 step/lerp/saturate
- P2: 纹理采样次数（移动端 ≤4/pass，PC ≤8/pass）
- P3: 精度滥用（fragment 中 float 应改 half，仅位置用 float）
- P4: 可提到 vertex shader 的逐像素计算
- P5: 未使用的 varying/interpolator
- P6: 昂贵数学函数（pow/sin/cos）可否近似
- P7: discard/clip 使用及 Early-Z 影响
- P8: 多 Pass 是否可合并

### 兼容性
- C1: #pragma target 是否匹配目标平台
- C2: 平台相关宏使用
- C3: Metal/Vulkan 跨平台兼容
- C4: Fallback 声明
- C5: SRP 管线匹配

### 可维护性
- M1: 硬编码魔数
- M2: 命名规范
- M3: 注释覆盖
- M4: Properties 一致性

## 最后给出总评
- 总体评分（A/B/C/D）
- Top 3 最需修复的问题
- 预估修复工作量

---

待审查 Shader 代码：

[粘贴代码]

四、可选：静态扫描脚本

如果你想在不调用 LLM 的情况下快速扫一遍，可以写一个简单的 Python 脚本做正则匹配：

  • 扫描 if/else 在 frag 函数内的出现次数
  • 统计 tex2D/SAMPLE_TEXTURE2D 调用次数
  • 检查是否有 discard/clip
  • 检查 #pragma target 的值
  • 检查是否缺少 Fallback

这个脚本可以作为 CI 的一部分或 Unity Editor 菜单工具，一键扫描整个项目的所有 .shader 和 .cginc 文件。

五、落地建议

  1. 先用提示词模板，把你担心的那些 Shader 逐个喂进去做体检。这是最快能出结果的方式
  2. 把检查清单存到 viskem 的协议或探索中，这样以后任何 Agent 都能引用
  3. 如果发现反复出现同类问题，再考虑写静态脚本做自动化
  4. 对于 AI LIMIT 项目，重点关注移动端兼容（如果有移动端计划）和 效率（大场景渲染压力）

你觉得这个方向对吗？还是你更倾向于做一个 Unity Editor 内集成的工具（菜单按钮 → 扫描 → 生成报告）？两个方向我都可以展开。