应用场景
如何用 AI 结合代码和截图排查渲染错误
EvoLink Team
产品团队
2026年10月16日
8 分钟阅读
对象显示在错误位置，着色器却编译通过。截图能看到现象，代码里又有好几个可疑点。没有相机、矩阵值和预期结果，只让AI“把图修对”，容易得到一个听起来合理的猜测。
提供能复现的场景，每次检验一个明确假设。 截图和运行状态来自同一版代码，再用数值或渲染检查判断补丁是否解决了具体缺陷。
准备渲染问题证据包
包含渲染器/API、相关着色阶段、uniform值、几何数据、viewport、相机、预期和实际画面，以及复现动作。错误、编译和链接诊断保留实际观察，不只写“都正常”。
| 证据 | 有用内容 | 单张截图不能证明的事 |
|---|---|---|
| 预期及实际画面 | 同相机和分辨率，标记问题区域 | 哪个变换或状态造成差异 |
| 着色器及uniform | 准确版本、矩阵约定及数值 | 宿主是否上传了预期值 |
| 绘制设置 | 几何、属性布局、深度/剔除/混合 | 实际画了哪些对象 |
| 复现过程 | 最小场景和动作 | 补丁是否对另一场景有效 |
缺贴图和灯光错误在缩略图上可能很像。条件允许时给清楚的局部图，不在前后对照间移动相机。
用可计算结果检查矩阵顺序
以下虚构场景使用列向量。位置依次经过模型、视图和投影变换，表达式应为
projection * view * model * position，最右侧先作用。假设着色器写成：
gl_Position = uProjection * uModel * uView * vec4(position, 1.0);给定约定为：模型沿x平移2，视图绕z旋转90度，投影把x、y缩放至0.2。局部点
(1,0,0,1)应得到裁剪坐标(0,0.6,0,1)：Model: (1,0) -> (3,0)
View: (3,0) -> (0,3)
Projection: (0,3) -> (0,0.6)
Wrong order: View (1,0)->(0,1), Model ->(2,1), Projection ->(0.4,0.2)数值能够检验该假设，不依赖画面是否漂亮。Khronos的顶点变换说明介绍了这些坐标阶段。宿主内存布局和乘法约定仍需单独核查，不能把改乘法顺序当作所有渲染器的通用修复。
要求假设、复现与最小补丁
请排查提供的渲染差异。
使用着色器、宿主状态、预期行为、实际截图和版本。
图像作为现象证据，不直接当作某一根因的证明。
返回：
1. 观察到的现象及依据；
2. 排序后的假设，每项带可区分的检查；
3. 首要假设的最小验证；
4. 检查支持后才给补丁；
5. 阻止判断的uniform、状态或上下文缺口。
遵守给定矩阵和向量约定。
不重写渲染器，不靠改变相机隐藏问题。
只提出测试时，不声称已执行。
输入：证据包和要求的变换约定。本例候选补丁为：
gl_Position = uProjection * uView * uModel * vec4(position, 1.0);在 EvoLink Gemini 4 页面选择Agent或API路径复核代码，真实截图按文档规定的图片格式附上。也可以通过统一网关用相同证据比较另一模型，但多个模型赞同不替代测试。
第一轮提交已说明的矩阵约定和错误着色器，请它给一个假设与最小补丁。先用数值例子分清(0,0.6)和(0.4,0.2)，再到实际渲染里检查，别把补丁建议当作验证结果。
先做最小数值检查，再看画面
下面的JavaScript对应本例变换的二维部分：
const model = ([x, y]) => [x + 2, y];
const view = ([x, y]) => [-y, x];
const projection = ([x, y]) => [x * 0.2, y * 0.2];
const correct = projection(view(model([1, 0])));
const wrong = projection(model(view([1, 0])));
if (Math.abs(correct[0]) > 1e-9 || Math.abs(correct[1] - 0.6) > 1e-9) {
throw new Error("Unexpected reference transform");
}
if (Math.abs(wrong[0] - correct[0]) < 1e-9 &&
Math.abs(wrong[1] - correct[1]) < 1e-9) {
throw new Error("Fixture does not distinguish transform order");
}这能验证计算，不代表GPU上传和交付画面已通过。WebGL还要对照矩阵uniform接口检查上传与布局要求。再固定相机、分辨率和状态渲染最小场景，比较修复前后的测试点及对象位置。
相同画面也可能来自其他问题
| 现象 | 区分检查 |
|---|---|
| 随相机移动位置异常 | 用已知点核对变换及上传值 |
| 某一侧看不见对象 | 检查绕序、剔除和视图方向 |
| 位置正确但遮挡错 | 检查深度附件、清空和比较状态 |
| 贴图拉伸或翻转 | 检查UV、图像方向与采样数据 |
| 只在高像素密度屏幕异常 | 对照drawing buffer、viewport及CSS尺寸 |
每次只改变一个条件。关闭剔除能让几何出现，但不证明最终应该关闭它。实验过程和对结果的解释分别记录。
给修复保留回归场景
保留平移与旋转不能交换的例子，全部单位矩阵会隐藏本例错误。最小用例通过后，再加入正常相机运动和代表性几何。使用同一场景版本比较，其他残留图形问题单独记录。
若争议在于审查发现是否成立，可参考代码审查核验流程。本文负责视觉复现与渲染状态排查，不重复整套PR审查。
常见问题
截图能直接定位根因吗？
通常只能给出现象与位置，需要代码、状态和复现过程区分原因。
着色器编译成功，数学就正确吗？
不是。合法表达式也可能采用错误变换顺序。
多个补丁要一起试吗？
一次验证一个假设，结果才有可解释的原因。
JavaScript检查验证了GPU吗？
只检查给定计算，渲染和宿主状态需要另外验证。
要把整个仓库交给模型吗？
从复现差异所需的场景和相关状态开始，假设需要其他依赖时再补。
最终问题记录包含什么？
版本、输入、预期与实际行为、实验、接受的补丁、回归检查及剩余不确定项。
参考资料
- Khronos顶点变换：坐标阶段。
- MDN矩阵uniform：WebGL上传要求。
