AI 协作日志

学号：202412211401023 · 来源：ai-log.md

# 实验一 AI协作记录

> 记录本人真实的AI协作过程：不仅记录AI给出的结果，更体现我自己的判断、动手测试与核验。

## AI协作1：理解数据流

### 我的目标
在动手写代码前，先弄清楚 WebGL 一条完整的渲染链路：一组写在 JS 里的顶点数组，究竟经过哪些步骤才变成屏幕上的像素。我希望确认 Buffer、顶点属性、Shader、图元组装、光栅化之间的先后关系和各自职责，避免只是照着抄代码却不理解原理。

### 提示词
我把实验一的指导书上传给AI，要求它先归纳这份实验到底要考察什么，再按"数据流"的主线讲清顶点数据从 CPU 端走到屏幕的完整过程，并说明五个任务分别在这条链路上新增了哪个环节。

### AI关键回答摘要
AI 把整条链路总结为：顶点数据（Float32Array）→ 创建并绑定 Buffer → 上传 GPU（bufferData）→ 用 vertexAttribPointer 把 Buffer 与 Shader 的 in 变量建立联系 → drawArrays 触发图元组装 → 光栅化插值 → Fragment Shader 输出颜色 → 写入画布。它指出任务1跑通整条链路，任务2只新增"图元组装方式"这一环（TRIANGLE_STRIP），任务3新增"多对象、多次绘制与状态管理"，任务4新增"第二个顶点属性 vColor 与光栅化插值"，任务5只替换 draw mode 做控制变量。同时强调本实验强制 WebGL2 规范：Shader 用 #version 300 es、in/out、自定义 out vec4，禁用 attribute/varying/gl_FragColor。

### 我的判断
我认同这条主线，但有两点要自己确认而不是全信：一是 drawArrays 的第三个参数到底传"顶点个数"还是"float 个数"，这直接关系到后面几个任务的绘制结果；二是"上传数据"和"建立属性联系"是两件不同的事——bufferData 只是把数据放进 Buffer，真正让 Shader 读到数据的是 vertexAttribPointer + enableVertexAttribArray。我打算在写代码时重点盯这两处。

### 验证方法
按 AI 给的链路把 task1.js 跑起来，只改顶点坐标不改其它逻辑，看是否仅形状变化；再把 drawArrays 的第三个参数故意从 3 改成 6，观察是否报 GL_INVALID_OPERATION 或画不出来，以此确认参数含义。

### 验证结果
只改顶点坐标时画面形状正确变化，颜色不变，证明"数据→绘制"链路是通的。把 drawArrays 第三个参数改成 6 后浏览器控制台报错、三角形不显示，确认该参数是"顶点个数"而非"float 个数"，与 AI 解释一致。

### 修正后的结论
数据流模型成立，但我自己补了一条易错点：drawArrays 第三参数为顶点数；以及"上传数据(bufferData)"与"建立属性联系(vertexAttribPointer)"必须分两步，缺一不可。这两条写进了我的实验笔记，后面几个任务反复用到。

---

## AI协作2：程序调试

### 现象
做任务3（同一画布上先画三角形再画四边形）时，两个图形都画出来了，但四边形和三角形重叠在了同一个位置，而且四边形颜色没有变成我设置的第二种颜色，看起来像"第二个图形根本没生效"。

### 我的初步判断
我先怀疑是顶点坐标写错、两个图形坐标恰好重叠，或者颜色 uniform 没拿到位置。但也隐约觉得和"换了一个 Buffer 之后没重新设置属性"有关，只是不确定具体是哪一步漏了。

### 给AI的提示词
我描述了现象：两次绘制，第一次三角形正常、第二次四边形叠在第一次的位置且颜色没变；贴出了任务3的代码骨架和 Shader，问 AI 问题可能出在哪、应该按什么顺序排查。

### AI给出的关键建议
AI 给出一条排错顺序，并指出最可能的根因：每次 bindBuffer 都会改变当前 ARRAY_BUFFER 的指向，属性记录的是"调用 vertexAttribPointer 那一刻所绑定的 Buffer"。如果第二次绘制换了新 Buffer 却没有重新调用 vertexAttribPointer，vPosition 仍然指向第一个三角形那个 Buffer，于是第二个图形读到的是三角形的顶点数据；同理颜色 uniform 要在每次绘制前重新 uniform4f。它还提醒排查顺序：先确认 WebGL2 上下文拿到 → initShaders 成功 → Buffer 绑定/上传 → 属性是否指向正确 Buffer → 是否每次绘制前更新 uniform → drawArrays 参数。

### 我实际进行的测试
我先在第二次绘制前补一句 gl.vertexAttribPointer(vPosition, 2, gl.FLOAT, false, 0, 0)，单独观察四边形位置；再单独在第二次绘制前补 gl.uniform4f(uColor, ...) 观察颜色；最后两处都补上一起运行。我还刻意只补一处、保留另一处错误，做对照。

### 测试结果
只补 vertexAttribPointer 后，四边形回到了右侧正确位置但颜色仍是旧色；只补 uniform4f 后颜色变了但仍叠在原位置；两处都补后，左侧橙色三角形与右侧紫蓝色四边形同时正确显示。对照结果完全印证了 AI 的判断。

### 最终原因
根因是任务3的两次绘制共用同一个 vPosition 属性，但第二次换了新 Buffer 却没重新建立属性与 Buffer 的联系，导致第二个图形读取了第一个 Buffer 的顶点；同时 uniform 是全局状态，不在每次绘制前重设就会沿用上一次的颜色。

### 是否采纳AI建议及理由
采纳。AI 给出的"属性绑定的是当时 Buffer、uniform 是需手动更新的全局状态"这一原理，被我的对照实验直接验证：单独修一处只解决一半，两处都修才完全正确。这不是照抄答案，而是先有自己的怀疑、再用测试锁定真因，最终把"换 Buffer 必重设 vertexAttribPointer、绘制前必重设 uniform"记为多对象绘制的固定检查项。

---

## AI协作3：顶点属性与颜色

### 我的目标
理解任务4为什么能让一个三角形内部出现连续的颜色渐变：第二个顶点属性 vColor 是怎么送进 Shader、渐变又是在管线的哪个阶段产生的；同时把任务2/任务5"同样顶点、不同图元"的对照讲清楚。

### 提示词
我请AI解释任务4的双属性结构：为什么位置用 vertexAttribPointer 读 2 个 float、颜色却要读 4 个 float，以及 vColor 经过 out/in aColor 传到 Fragment 后，三角形内部的过渡色到底是 Vertex Shader 算的还是 Fragment Shader 算的。

### AI关键回答摘要
AI 说明：每个顶点属性独立占用一个 Buffer，位置 Buffer 每顶点取 2 个 float（xy），颜色 Buffer 每顶点取 4 个 float（RGBA），所以两次 vertexAttribPointer 的 size 参数分别是 2 和 4，互不冲突。Vertex Shader 只把每个顶点自身的颜色通过 aColor 输出，三角形内部"介于顶点之间"的颜色并不是逐顶点计算的，而是光栅化阶段在各顶点间对 aColor 做线性插值，再交给 Fragment Shader 使用，所以才会看到红/绿/蓝三原色之间平滑过渡的渐变。

### 对照实验
为验证"渐变发生在光栅化"，我做了两组对照：一是把三个顶点颜色设为完全相同的颜色，看渐变是否消失；二是把任务2用 TRIANGLE_STRIP 画四边形的同一组 4 个顶点，在任务5原样复制，仅把 draw mode 从 TRIANGLE_STRIP 改为另一种，比较图元组装结果差异。

### 实际现象
三顶点同色时三角形变成纯色、不再有渐变，证明颜色过渡确实依赖顶点间差异与插值。图元对照中：同样 4 个顶点，TRIANGLE_STRIP 自动组出 2 个三角形拼成完整四边形，而改用其它 mode 时组装方式不同（如 TRIANGLES 每 3 顶点组一个独立三角形、第 4 个顶点凑不满被丢弃）。这与顶点数据完全无关，只由 draw mode 决定。

### 我的解释
位置与颜色是两套独立的属性—Buffer 绑定，size 决定每个顶点取几个分量，这解释了为什么颜色要传 4。渐变不是着色器逐像素硬算出来的，而是光栅化把顶点属性插值到每个采样位置，所以"顶点颜色不同→内部连续过渡"。图元对照则说明图元组装是纯按顶点顺序和 mode 规则进行的：TRIANGLE_STRIP 复用前一条边所以 4 顶点能出 2 个三角形，TRIANGLES 不复用所以会丢弃多余顶点。

### 补充对照：vertexAttribPointer 的 size 由 4 改成 3
按指导书要求又做了一组对照：把任务4里读取颜色的 gl.vertexAttribPointer(vColor, 4, gl.FLOAT, false, 0, 0) 的 size 临时由 4 改成 3，运行后观察，再恢复为 4。

现象：size=4 时三角形是干净的红/绿/蓝三原色平滑渐变；把 4 改成 3 后，颜色明显错乱、出现异常的偏色与边缘发暗，渐变被打断。

我的解释：颜色 Buffer 里每顶点是连续 4 个 float（R、G、B、A）。GPU 是按 size 的顺序把这段连续内存切分给每个顶点的：size=4 时正好一个顶点对齐 4 个分量；改成 size=3 后，每顶点只取走 3 个 float，第 4 个分量（A）被错位当成了下一个顶点的 R 读取，整段数据的对齐方式全部错开，于是每个顶点拿到的 RGBA 都不是自己原本的颜色，透明度也被打乱，所以出现错色。这个现象直接印证了「属性是按 size 顺序连续切分 Buffer」的机制，也说明位置(2)与颜色(4)的 size 必须与该属性实际分量数严格一致。改回 4 后渐变恢复正常。

### 最终结论
1. 多个顶点属性各自绑定独立 Buffer，vertexAttribPointer 的 size 按该属性的分量数设置（位置2、颜色4）。
2. 顶点颜色插值发生在光栅化阶段，Vertex Shader 只负责传递顶点色，Fragment Shader 收到的是已插值好的颜色，因此需要顶点色不同才能看到渐变。
3. 图元类型决定组装方式：TRIANGLE_STRIP 通过共享相邻边用 4 顶点画出四边形，TRIANGLES 不复用顶点，同样的 4 顶点只会画出 1 个三角形、丢弃第 4 个顶点。这组对照实验同时验证了任务2、任务4、任务5三个任务的核心考点。

---

## AI协作4：图元类型对照实验记录（任务5）

### 我修改了什么
任务5要求与任务2控制变量：顶点数据（左上→左下→右上→右下 4 个顶点）、顶点顺序、颜色全部保持不变，只把 gl.drawArrays 的 draw mode 由任务2的 gl.TRIANGLE_STRIP 改成 gl.LINE_STRIP。

### 我原先的预测
预测它不会再是一个实心的填充四边形，而会变成只有线条、没有面片的图形，因为图元类型决定了这些顶点被怎样组装。

### 实际结果
画面上 4 个顶点按 v1→v2→v3→v4 的顺序首尾相连成一条折线（左上→左下→右上→右下，中间因交叉顺序而产生一条交叉边），整个三角形/四边形内部没有任何填充，与预测一致。

### 原因解释
TRIANGLE_STRIP 会把相邻顶点两两复用为三角形并对面片做填充，所以任务2里同样的 4 顶点得到实心四边形；而 LINE_STRIP 仅把相邻顶点依次用线段连接、根本不组装三角形，因此只能得到轮廓折线。结论：在顶点数据完全相同的前提下，仅改变 draw mode 就会改变图元的组装与填充结果——图元类型是决定最终图形形态的关键变量。