AI 协作日志

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

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

学号：202412211401028　姓名：　　　　　日期：2026-11-09

> 必做A—E已全部实现并运行核验；关键截图保存在`evidence/`，数值记录见文末附录。使用AI辅助完成概念核对、故障排查和方案比较，最终代码、参数选择和结论由本人复核。

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

1. **我的问题和事先预测（M/V/P中谁变化？预期画面如何变化？）**
   - 预测1：只改eye/target（移动相机）时，改变的是`V`；模型世界坐标与状态栏“模型世界中心”不应变化，画面只是观察方向改变。
   - 预测2：保持M、V不变只切换ortho/perspective时，改变的是`P`；正交投影下两个等尺寸不同深度的立方体表观尺寸基本相同，透视投影下近处立方体更大。
   - 预测3：增大FOV只改变透视`P`，模型世界尺寸不变，但画面中物体占比变小；它不等价于Model缩小。

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

3. **AI建议摘要（包括关键数学依据）：**
   - 实验一：固定`M`、`P`，只改`eye/target`（V）；打印`P·V·M·N·c_local`以及世界中心，验证世界坐标不随V改变。
   - 实验二：固定`M`、`V`，只切换`P`；在世界中放两个同尺寸、不同深度的立方体，比较屏幕表观尺寸。
   - 实验三：固定`M`、`V`，只改FOV；打印P矩阵的`m11=1/tan(fov/2)`，说明FOV改变的是投影锥，不是世界缩放。
   - AI还提醒：`mat4.lookAt(out, eye, target, up)`返回的是世界→相机的V；列向量下顶点按`P·V·M·N`从右往左作用。

4. **我的判断和采纳/拒绝理由：**
   - 采纳“控制变量+打印矩阵/世界中心”的建议，因为它可以把“看起来相似”拆成可核对的状态证据。
   - 拒绝“通过修改Model来模拟相机移动”的做法：那会把世界中心一起移走，属于M变化而非V变化，不能用于验证观察变换。
   - 人工补充：判断画面变化前先读状态栏中的相机、投影和Model参数，避免只凭肉眼。

5. **我的测试参数、测试操作与结果（附截图/数值）：**
   - Task B：`eye=(0,0,8)→(8,0,0)→(0,8,0)→(6,4,7)`切换四个预设，状态栏“模型世界中心”始终为`(0.00,0.00,0.00)`；`V·eye=(0,0,0)`，`V·target=(0,0,-8)`；顶部视角把世界`-Z`映射为屏幕`+Y`。截图：`evidence/task-b-iso.jpg`。
   - Task C：同一M/V下切换投影，`eye (0.00,1.80,8.50)→target (0.00,0.00,0.00)`、世界中心均不变；透视下左侧近立方体明显大于右侧远立方体，正交下两者表观尺寸相同。截图：`evidence/task-c-perspective.jpg`、`evidence/task-c-ortho.jpg`。
   - 数值：在`aspect=2`的独立计算中，透视投影`x=0.5,z=-2`的NDC x为`0.268`，`z=-6`为`0.089`；正交投影两者均为`0.091`。

6. **AI是否正确？我最终修正了什么认识？**
   - AI的三组控制变量建议与实测一致。修正点：FOV变大时物体在画面中变小，不是因为“物体被缩小”，而是`P`的投影锥变大、同样的世界高度占据更少NDC范围；正交投影没有透视除法，因此深度不改变表观尺寸。

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

1. **真实错误现象和我起初怀疑的原因：**
   - 在实现顶部视角时，若沿用普通`up=(0,1,0)`，观察方向`eye-target=(0,8,0)`与up平行。此时`lookAt`内部`up×viewDir`叉积为零，得到退化矩阵，画面模型消失/视图异常。起初怀疑是模型归一化或裁剪面把模型裁掉了。

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

3. **AI建议的至少两个可区分原因及测试：**
   - 假设A：宽高比错误导致拉伸。最小测试：打印`aspect`与Canvas实际`width/height`，二者应一致（本页为`1.60`，状态栏显示`aspect 1.60`）。
   - 假设B：near/far或相机方向错误导致裁剪。最小测试：只把`near`设为0或让`far<near`，观察是否出现可读错误提示而不是画面悄悄消失。
   - 假设C：矩阵顺序错误。最小测试：固定M、V，仅切换P，检查世界中心与相机参数不变。
   - 假设D：观察基向量退化。最小测试：顶部视角分别用`up=(0,1,0)`与`up=(0,0,-1)`构造V，打印矩阵并检查是否有零列。

4. **我实际逐项测试了什么？各自结果如何？**
   - 宽高比：Canvas宽高比与状态栏`aspect`均为1.60，排除A。
   - 裁剪面：把`near=0`后应用给出“参数错误：near必须大于0（当前near=0）”，恢复`near=0.1`后提示“参数已恢复有效范围”，排除静默裁剪。
   - 矩阵顺序：仅切换ortho/perspective，M、V参数与世界中心均未变化，P切换有效，排除C。
   - 基向量：用`up=(0,1,0)`算顶部V得到`[0,0,0,0, 0,0,1,0, 0,0,0,0, 0,0,-8,1]`，前两列退化；改用`up=(0,0,-1)`后矩阵有效，顶部视角正常，世界`-Z`映射为屏幕`+Y`。

5. **最终根因、修复处及修复后结果：**
   - 根因：顶部视角的`up`与观察方向共线，`lookAt`叉积退化。
   - 修复：`js/task-b.js`的`ex.view`中，当观察方向的水平分量为0时改用`(0,0,-1)`（向下看）或`(0,0,1)`（向上看）；同时在eye与target重合时抛出可读错误。
   - 修复后：顶部/底部视角无黑屏、无NaN，四预设与参数面板联动正常。

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

1. **我准备完成的观察任务：**
   - 以茶壶为对象，在模型中放一个固定参考点P，让橙色标记绕P运动，并用它解释`T(P)·R·T(-P)`与模型自转的区别；同时希望验证父子复合变换。

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

3. **两种方案的功能、矩阵链、测试难度对比：**
   - 方案1：固定参考点P + 单个绕点标记。矩阵链`M_marker=T(P)·Ry(θ)·T(-P)·T(q)·S`；交互只需`orbit`一个参数；验证简单（比较θ=0与90°时标记中心）。
   - 方案2：可调参考点P + 绕点标记 + 子部件（父子继承）。在方案1的父链上再加`T(q)·Ry(2θ)·T(0.30,0,0)·S`；需要P的X/Y/Z和轨道半径参数；验证要求同时检查绕点轨迹、子块与父块的距离以及参数改变后的联动。

4. **最终采纳的方案与理由：**
   - 采纳方案2，并在`ui.js`/`app.js`增加“参考点P X/Y/Z、轨道半径”输入（同时保持A—D页面不受影响）。理由：它同时覆盖“绕指定点旋转”和“父子继承”两种复合机制，比只放一个固定标记更能说明矩阵链的层级关系，且复用现有`CG5.T/R/S/chain/point`即可完成，验证量在可接受范围。
   - 讨论由AI提供，但“采用方案2、增加P坐标输入、把子块设为父级的子节点”这一最终决定由本人作出。

5. **自己实现或修改的功能差异：**
   - 新增固定参考点P与轨道半径的界面输入（`px/py/pz/pr`），使绕点中心可调，而不仅是固定位置。
   - 新增青色子部件：它继承橙色父块的绕点运动，同时以`2θ`相对自转并绕父块中心`0.30`偏移运动，体现父子矩阵相乘。
   - 黄色小块显示P本身，橙色小块显示绕点结果，形成可对照的三级视觉标记。

6. **预测与实际结果对照，仍存在的局限：**
   - 预测θ=0时橙色块位于`q=P+(r,0,0)`；实测`P=(0.9,0.9,0)`、`r=0.55`时橙色中心为`(1.45,0.90,0)`，与预测一致。
   - 预测θ=90°时橙色块绕P转到`(0.9,0.9,-0.55)`；实测一致，且青色子块与橙色父块中心距离恒为`0.30`。
   - 局限：辅助标记是教学立方体，不是真实模型部件；未做光照、纹理和复杂OBJ解析；轨道只在Y轴平面内旋转。

## 全局诚信声明

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

## 附录：数值与行为验证记录

测试环境：Chromium内核浏览器（WebGL2可用），通过`index.html`进入五个任务页；页面Canvas宽高比实测`aspect=1.60`。

| 任务 | 操作/参数 | 实测结果 |
|---|---|---|
| A 归一化 | 理论测试模型`min=(-2,-1,-1), max=(4,3,1)` | `c=(1,1,0)`、`L=6`、缩放`1/3`；`N·c=(0,0,0)`；变换后x跨度=2 |
| A 导入 | 内置茶壶/球体/兔子、本地`models/sphere.obj` | 茶壶858顶点/1512面，最长边3.560，缩放0.562；兔子1580/2728，最长边2.660，缩放0.752；球体551/1008，最长边2.000；世界中心均为`(0,0,0)` |
| A 异常 | 选择内容为`garbage`的`.obj` | 提示“模型读取失败：OBJ 缺少 v 顶点或 f 面”，原模型保留，页面继续运行 |
| B View | 正面/侧面/顶部/斜上方 | eye依次`(0,0,8)/(8,0,0)/(0,8,0)/(6,4,7)`；世界中心始终`(0.00,0.00,0.00)`；`V·eye=(0,0,0)`、`V·target=(0,0,-8)` |
| B up处理 | 顶部视角`up=(0,0,-1)` | V矩阵有效；世界`-Z`方向映射为屏幕`+Y`；普通`up=(0,1,0)`会得到退化矩阵（见协作二） |
| C 投影 | 同一M/V切换ortho/perspective | 相机与世界中心不变；投影栏正确显示“正交/透视”；`aspect=1.60` |
| C 裁剪 | `near=0`、`far<near`、`orthoH=0`、`fov=180` | 均给出中文错误提示；恢复合法值后自动解除报警 |
| C 对照 | `aspect=2`数值测试：x=0.5，z=-2与-6 | 透视NDC x=`0.268` vs `0.089`（近大远小）；正交均=`0.091`（表观相同） |
| D 旋转 | 左键拖动dx=10,dy=20像素 | `ry=4.5°`、`rx=9°`，tx/ty/tz与eye不变 |
| D 平移 | Shift+左拖dx=10像素（正面观察） | `tx≈+0.125`，方向为屏幕右；垂直向下拖动使`ty`减小 |
| D 滚轮 | 滚轮向下`deltaY=100` | 相机距离`8.688→9.602`，`scale`保持`1.00` |
| D 键盘 | `D`、`+`、`Q` | `tx:0→0.12`、`scale:1→1.08`、`ry:0→-5°`；eye不变 |
| D 重置 | 点击“重置参数” | tx/ty/tz=0、rx/ry=0、scale=1、eye=`(0,1.8,8.5)`，恢复默认 |
| E 绕点 | `P=(0.9,0.9,0)`、`r=0.55`、θ=0/90° | θ=0时橙色中心`(1.45,0.9,0)`；θ=90°时`(0.9,0.9,-0.55)`，符合绕P旋转 |
| E 父子 | θ=90°，子块相对父块偏移0.30 | 父子中心距离恒为`0.30`，子块随父级绕点并自转 |
| E 可调P | `P=(0,0,0)`、`r=1` | 标记中心到P距离=1，说明P与半径输入生效 |
| 截图 | “保存PNG截图”/Canvas采样 | Canvas为658×411，非背景像素约15682，中心像素`[81,126,146]`；`toDataURL`长度37034，PNG非空白 |

证据截图：`evidence/task-a.jpg`、`evidence/task-b-iso.jpg`、`evidence/task-c-perspective.jpg`、`evidence/task-c-ortho.jpg`、`evidence/task-d.jpg`、`evidence/task-e.jpg`。