AI 协作日志

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

# 实验五AI协作与核验记录（学生填写）

学号：202412211401030　　姓名：张博　　　　日期：2026-11-09

> 记录自己的预测、原始问题、AI建议、自主判断与实际核验。AI代码不能代替本人解释。

## 协作一：观察与投影概念核验（Task B / C，3分）

1. **我的问题和事先预测**：在右手坐标、列向量与`P·V·M`顺序下，我预测移动物体只改变M、移动相机只改变V、切换投影只改变P；正交下两个等尺寸不同深度的物体表观大小相同，透视下近大远小，增大FOV后物体在画面中占比减小。

2. **实际输入给AI的提示词**：
   > 在WebGL2右手坐标系、列向量和P·V·M的顺序下，我想比较移动物体与移动相机、正交与透视投影。请给我三组能区分原因的控制变量实验，指出应改变M/V/P中的哪项，说明可以打印哪些坐标数值进行核验，不要直接生成整套代码。

3. **AI建议摘要**：保持V和P只改M平移；保持M和P只改eye/target；保持M和V只切换P并打开近/远立方体。核验数值包括模型世界中心、相机eye/target、投影矩阵的`P00`与NDC坐标；`lookAt`后eye应映射到相机原点，target应映射到`(0,0,-|eye-target|)`；透视`P00=f/aspect`，正交`P00=2/w`。

4. **我的判断和采纳/拒绝理由**：采纳“三组控制变量”的排查思路，但拒绝让AI直接改写代码，改为自己按A→C逐个补充函数，再逐项做数值核验，避免把“画面相似”误当成“数学机制相同”。

5. **测试参数、操作与结果**：
   - Task A：茶壶858顶点/1512三角面，球体551/1008，兔子1580/2728；测试包围盒`min=(-2,-1,-1)`、`max=(4,3,1)`时算得`c=(1,1,0)`、`L=6`、缩放`1/3`，中心经N后为`(0,0,0)`，最长边变为2。
   - Task B：依次点击正面/侧面/顶部/斜上方，eye变为`(0,0,8)/(8,0,0)/(0,8,0)/(6,4,7)`，target保持原点；世界位置始终为`(0,0,0)`；顶部视图改用`up=(0,0,-1)`后矩阵无NaN。
   - Task C：透视下近/远立方体的NDC横向尺寸比为`2.000`；正交下两者NDC横向坐标相同；FOV由50°增至80°时同一物体的NDC x减小；near设为0或far≤near时出现红色提示。

6. **AI是否正确、我修正了什么认识**：三组控制变量有效。我进一步确认“透视FOV变大物体看起来变小”是投影矩阵的横向缩放变化，而不是模型被缩放，Model参数全程不变。

## 协作二：程序故障诊断（Task C / D，4分）

1. **真实错误现象和起初怀疑的原因**：为检验宽高比的影响，我临时把透视投影的aspect固定为1（Canvas实际aspect≈1.58），预期画面水平方向被拉伸；起初怀疑是观察矩阵或模型缩放导致形状异常。

2. **向AI提出的诊断问题**：
   > 我的OBJ能显示，但切换透视投影后形状被拉伸/裁剪或者鼠标拖动方向异常。请从宽高比、裁剪面、矩阵顺序和观察基向量中提出至少三种假设，分别给一项最小测试，先帮助排查，不要直接重写完整程序。

3. **AI建议的可区分原因及测试**：①宽高比不等于Canvas实际比例→对比状态栏aspect与投影P00；②near/far非法→把near设为0观察提示；③矩阵顺序错误→打印世界中心与相机坐标；④观察基向量（up与视线平行）→切到顶部视角看是否出现NaN。

4. **我实际逐项测试**：状态栏aspect显示`1.58`，但`P00=f/aspect`按aspect=1计算为`2.14`，按1.58计算为`1.36`，水平方向被放大约1.58倍；near/far保持`0.1/100`时无裁剪提示；世界中心与相机坐标正常；顶部与侧面视角均无NaN，拖动方向也正常。由此排除②③④。

5. **最终根因、修复及结果**：根因是`task-c.js`透视分支把固定值1当作aspect传入，未使用`scene.resize()`返回的Canvas宽高比。改回`mat4.perspective(..., fov*RAD, aspect, near, far)`后，P00恢复为`1.36`，模型比例正常；随后自动化数值核验34项全部通过（`SUMMARY: ALL PASS (34/34)`）。

## 协作三：综合工作台方案比较（Task E，3分）

1. **我准备完成的观察任务**：在茶壶模型上观察“绕固定世界点P公转”与“模型绕自身中心自转”的差别，并用辅助标记显示公转半径。

2. **向AI询问的两种设计方案**：
   > 我已完成OBJ导入、观察视角、正交/透视以及鼠标键盘变换。请提供两个能在40分钟内复用已有WebGL2模块的观察台拓展设计，对比功能、矩阵链、交互参数和验证难度。不引入Three.js、光照、纹理或复杂模型编辑器。

3. **两种方案对比**：
   - 方案一（绕指定点公转＋轨迹环＋父子继承）：矩阵链`T(P)·Ry(θ)·T(-P)·T(q)·S`，复用现有立方体网格和`orbit`滑块；验证可直接用`CG5.point`比较标记坐标，难度低。
   - 方案二（正交/透视双画布同步对照，Challenge）：需要两个WebGL上下文或两次绘制，交互状态需同步，矩阵本身不复杂但工程改动和验证成本高。

4. **最终采纳的方案与理由**：采纳方案一。它能在现有`ex.extra()`接口内完成，矩阵链与指导书公式一致，且可用数值逐项验证；双画布对照暂列为Challenge备选，不纳入必做范围。

5. **自己实现或修改的功能差异**：①标记初始中心`q`取模型中心正上方1.15，并随模型平移联动，避免被茶壶网格遮挡；②增加24个小方块组成的公转轨迹环，直接显示半径`|P-q|`；③增加父子继承的紫色子标记，父变换为公转矩阵、子变换为局部偏移`T(0.34,0,0)`；④边界处理：`eye=target`、`near≤0`、`far≤near`、零跨度模型均给出可读错误。

6. **预测与实际结果对照、仍存在的局限**：预测orbit=0时橙色标记回到q、90°时绕P转90°、子标记随父标记同步运动；数值核验均通过，浏览器中标记随滑块移动。局限是标记不参与深度遮挡的透明处理，且未实现正交/透视同屏双画布（留作Challenge）。

## 全局诚信声明

- 我提交的代码均已本人运行并核验；无法解释的AI输出未直接作为完成结果。
- 我明确标注了使用AI辅助的功能和本人自主完成的关键判断。
- 数值证据：`_verify.html`自动化34项全部通过（核验后已删除临时文件）；浏览器实测A—E页面无JavaScript运行时错误。