AI 协作日志

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

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

学号：202412211402013　　　　姓名：顾喆祺　　　　日期：2026.11.9

> 必须记录**自己的预测、原始问题、AI建议、自主判断与实际核验**。AI代码不能代替本人解释。可附完整对话链接/导出记录，避免只放聊天截图而无测试证据。

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

1. 我的问题和事先预测（M/V/P中谁变化？预期画面如何变化？）：
我想要区分移动模型（修改 M）、移动相机（修改 V）、切换投影（修改 P）三者效果。
预测：
修改 M（旋转模型）：模型世界坐标改变，状态栏模型世界中心改变；
修改 V（相机动，M 不变）：画面会旋转，但模型世界中心数值保持不变；
修改 P（正交 <--> 透视，M、V 完全不动）：物体世界位置不变；正交下远近物体表观尺寸一样，透视出现近大远小。
2. 我实际输入给AI的提示词：
在 WebGL2 右手坐标系、列向量和 P・V・M 的顺序下，我想比较移动物体与移动相机、正交与透视投影。请给我三组能区分原因的控制变量实验，指出应改变 M/V/P 中的哪项，说明可以打印哪些坐标数值进行核验，不要直接生成整套代码。
3. AI建议摘要（包括关键数学依据）：
实验 1（区分 M 与 V）：固定 P；
 实验组 A：修改 M 的 ry 旋转模型（改变模型矩阵 M）；核验：读取状态栏模型世界中心，数值发生改变。
 实验组 B：修改 V 的 eye 参数旋转相机（改变观察矩阵 V）；M 保持原样；核验模型世界中心数值不变，只是视觉转动。
实验 2（正交 vs 透视）：固定 M、V，仅修改 P；开启远近两个等大对照立方体；
  正交投影：远近立方体屏幕大小一致；透视投影近处大远处小。
实验 3（FOV 改变）：M、V 不变，修改透视 FOV；FOV 增大物体画面占比缩小，物体世界坐标完全不变，只改变投影矩阵。
核验依据：`P·V·M·N`变换流水线；V 仅把世界坐标转到相机空间，不会修改物体的世界坐标；只有 M 才修改物体世界位置。
4. 我的判断和采纳/拒绝理由：
全部采纳 AI 提出的三组控制变量思路；但矩阵代码由自己结合实验指导书手写，没有直接复制 AI 完整代码。关键点：判断 M/V 不要只看画面观感，要看状态栏输出的模型世界中心数值，肉眼画面相似不能当作等价。
5. 我的测试参数、测试操作与结果（附截图/数值）：
测试 1：Task‑B，点击侧面相机预设。M 参数全部不变；eye 变为`(8,0,0)`；状态栏模型世界中心保持`(0.00,0.00,0.00)`。画面视角切换，但物体世界坐标不动。
测试 2：Task‑C，M/V 固定；切换正交模式；两个对照立方体，近处与远处方块屏幕高度几乎相等；切回透视，远处方块明显变小。
测试 3：透视模式，增大 FOV 从 50°→90°，茶壶在画布中变小；模型世界中心仍然为原点。
6. AI是否正确？我最终修正了什么认识？
AI 给出的控制变量思路正确。
原先误区：以为画面转动就代表物体动了；现在明白：画面旋转有两种完全不同来源：物体 M 变换 / 相机 V 变换，必须看世界坐标数值区分，不能只靠肉眼。

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

1. 真实错误现象和我起初怀疑的原因：
现象：Shift + 左键向上拖动画布，物体向屏幕下方跑；切换侧面视角，拖动方向完全混乱，不跟随屏幕平面移动。
我一开始怀疑：是旋转灵敏度`sensitivityMove`数值设置过大，或者`drag`函数没有被框架调用。
2. 向AI提出的诊断问题：
我的 OBJ 能显示，但切换透视投影后形状被拉伸 / 裁剪或者鼠标拖动方向异常。请从宽高比、裁剪面、矩阵顺序和观察基向量中提出至少三种假设，分别给一项最小测试，先帮助排查，不要直接重写完整程序。
3. AI建议的至少两个可区分原因及测试：
假设①：dy 符号错误：浏览器`pointermove`中 dy 向下为正，屏幕向上移动需要`‑dy`做符号反转；测试：打印 dx、dy 观察正负。
假设②：直接使用`lookAt`输出矩阵求逆获取相机基向量；`lookAt`内部会自动修正 up 向量，得到的 right/camUp 向量是被篡改过的，不能拿来做屏幕平移；测试：手动手写叉积计算 forward、right、camUp，不和 lookAt 结果复用对比。
假设③：矩阵乘法顺序错误；测试：暂时把 shift 移动步长调大观察变化趋势。
4. 我实际逐项测试了什么？各自结果如何？
测试假设①：console 打印 dy；鼠标向上拖动，dy 输出正值，确认 dy 向下为正；原代码没有取负，符号颠倒，**该假设成立**。
测试假设②：原来代码调用`mat4.lookAt`再求逆矩阵拿相机轴；改为手写叉积计算相机 forward/right/camUp，不再复用 lookAt 矩阵；拖动方向错乱现象大幅改善，证明该假设成立。
测试假设③：放大移动灵敏度，现象只有移动幅度变化，方向错乱依旧存在，排除矩阵顺序问题。
5. 最终根因、修复处及修复后结果：
根因两点：
1）Shift 拖动直接复用`lookAt`生成 view 矩阵求逆获取相机基向量，lookAt 内部自动修正 up，得到错误相机轴；
2）浏览器鼠标 dy 向下为正，缺少负号，上下移动颠倒。
修复：手写叉积计算`forward‑right‑camUp`相机局部坐标系；移动 Y 分量使用`‑dy`。
修复结果：普通拖动旋转模型正常；Shift + 拖动物体严格跟随屏幕平面上下左右移动；切换侧面 / 顶部视角，物体依旧跟随屏幕方向移动。

> 若首次没有故障，可以备份后临时制造一处可恢复错误，完成排查后修复。

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

1. 我准备完成的观察任务：
完成 E 综合工作台，在原有模型观察基础上实现物体绕世界任意指定参考点做 Y 轴旋转，绘制标记点可视化旋转中心，区分 “绕外部点旋转” 和物体自身自转。
2. 向AI询问的两种设计方案：
我已完成 OBJ 导入、观察视角、正交 / 透视以及鼠标键盘变换。请提供两个能在 40 分钟内复用已有 WebGL2 模块的观察台拓展设计，对比功能、矩阵链、交互参数和验证难度。不引入 Three.js、光照、纹理或复杂模型编辑器。
3. 两种方案的功能、矩阵链、测试难度对比：
方案 A：外部参考点绕 Y 旋转（本次选用）
功能：设置世界旋转中心点 P，使用小立方体标记 P 点；另一个方块物体围绕 P 点进行旋转；通过 UI 滑块控制旋转角度 theta，能够直观区分绕外部点公转和物体自身自转两种效果。
矩阵链：M_orbit = T (P)・Ry (θ)・T (−P)・T (q)・S
交互参数：依靠 UI 滑块里的 s.orbit 参数控制旋转角度；旋转中心点 P 固定为世界原点；q 代表运动方块的初始偏移位置。
测试难度：低。可以直接复用框架提供的 ex.extra 接口返回绘制物体列表，不需要修改框架事件代码；只需要核对标记方块的坐标即可完成验证，调试简单。
方案 B：相机轨道环绕模式
功能：鼠标拖拽画布直接环绕 target 目标点旋转相机 eye 位置，全程不修改模型矩阵 M，实现轨道式相机观察效果。
矩阵链：根据鼠标 dx、dy 更新球坐标 φ、θ；eye = target + R (φ,θ)・(0,0,−distance)
交互参数：鼠标拖动改变俯仰角与方位角；需要在 state 中额外保存球坐标状态，每次更新相机 eye 的坐标。
测试难度：较高。需要处理万向锁问题，必须新增状态变量；还要修改 drag 鼠标事件逻辑，会和 Task‑D 原本的模型拖动逻辑产生冲突，容易互相干扰。
4. 最终采纳的方案与理由：
采纳方案 A：绕世界参考点 Y 轴旋转可视化标记。
理由：
1）可以直接复用现有`ex.extra`接口，不用修改 app.js 框架代码，不会破坏前面 Task‑D 鼠标交互逻辑；
2）符合实验文档 E 给出的示例复合变换，便于完成 “\(T(P)RyT(-P)\)与自转区别” 的验证；
3）调试难度低，时间可控，适合 40 分钟完成；方案 B 轨道相机改动大，容易破坏 D 任务已有鼠标模型拖动功能，留作 challenge 拓展。
5. 自己实现或修改的功能差异：
在 AI 给出矩阵基础上我自主修改：
固定旋转参考点 P 为世界原点；
设置黄色方块标记旋转中心 P；橙色方块作为被旋转物体；
设置合理缩放 0.35，避免标记方块过大遮挡模型；
完全使用框架内置`cubeMesh`，不新增模型文件。
6. 预测与实际结果对照，仍存在的局限：
预测：滑动 orbit 滑块，橙色方块围绕黄色方块公转，而不是绕自身中心自转。
实际结果：现象符合预期。
局限：当前只能绕 Y 轴旋转；P 写死为世界原点，没有 UI 输入框自定义 P 坐标；如果要支持任意点旋转，需要额外增加 UI 输入参数（可作为 challenge）。

## 全局诚信声明

- 我提交的代码均已本人运行并核验；无法解释的AI输出未直接作为完成结果。
- 我明确标注了使用AI辅助的功能和本人自主完成的关键判断。