Showcase Tuning：AI 辅助渲染代码的可视化调试工作流

Source: Dev.to

概览

渲染代码常常面临一种许多开发者默默接受的测试问题：看起来对。单元测试可以验证逻辑，但它们无法捕捉法线反向、精灵被裁剪等问题。为了解决这个问题，我创建了一套工作流，称为 Showcase Tuning，并将其打包以便轻松复用。

Showcase Tuning 循环

1. 编写 harness – 一个小的、独立的程序，用来调用你的实际渲染代码。
2. 运行它 – 生成输出图像。
3. 查看输出 – 检查视觉结果。
4. 修复渲染器 – 调整渲染代码，而不是 harness。
5. 重复 – 迭代，直到输出符合预期。

诚实循环的规则

• 确定性输入 – 使用固定种子和硬编码数据，使每次运行都可比较。
• 修复渲染器，而不是 harness – harness 仅是捕获机制；缺陷应出现在渲染代码中。
• 生成后再审查 – 永远不要猜测输出的样子；始终先生成图像。
• 一次只改动一个组件 – 将改动隔离，以保持反馈紧凑、结果明确。

示例会话：热气球渲染器

步骤 1 – 初始检查

Claude 第一次运行 harness。气球呈现为一个普通的椭圆。

步骤 2 – 第一轮修复

现在全部五种调色板都能渲染。篮子、装饰线和绳索出现了，但仍有一些几何形状不正确。

步骤 3‑4 – 诊断并重新设计形状

Claude 将问题追溯到 buildEnvelopePath，并重写了轮廓曲线。

步骤 5‑6 – 最终细化

• 调整了高度比例。
• 修正了篮子的位置（之前漂浮得离气球太远）。

整个过程——从一个破碎的椭圆到完整的气球——只用了几次迭代。

其他 Showcase

• 调整粒子系统。
• 在夜间展示瓦片地图渲染器。
• 演示带有全部动画帧的角色精灵。

平台支持

harness 可跨多个平台运行：

• Android / JVM
• Web / TypeScript
• Python

生成的图像会写入 Showcase/ 目录，该目录会自动加入 .gitignore。

仓库

仓库中包含一个 SKILL.md 文件，定义了用于 Showcase Tuning 的 Claude Code skill。

👉 GitHub:

skill 的行为全部位于 SKILL.md，便于阅读和扩展。

行动号召

你是否也遇到过类似的渲染代码问题？我很想听听大家是如何进行视觉调试的。