AI 协作日志

学生 Web 实验作品平台
学号：202412211401021 · 来源：ai-log.md
# 实验五AI协作与核验记录

学号：202412211401021　　姓名：徐艳　　日期：2026-11-09

> 本文件记录**我自己的预测、原始问题、AI建议、我的判断与实际核验**。所有代码都在本机浏览器（Chromium + WebGL2）实际运行过，下列数值、截图和哈希都来自我自己的测试，不是AI给出的结论。

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

### 1. 我的问题和事先预测（M/V/P中谁变化？预期画面如何变化？）

我想搞清楚三件事，并先写下预测：

| 编号 | 我准备改的量 | 我的预测 |
|---|---|---|
| ① | 只把模型沿世界 X 平移（只改 M） | 状态栏的“模型世界中心”数值变大；相机 eye/target 数值完全不变 |
| ② | 只把相机 eye 从 (0,1.8,8.5) 改到 (8,0,0)（只改 V） | 画面从正面变成侧面；但“模型世界中心”仍然是 (0,0,0) |
| ③ | 同一 M、V，只把 P 从透视换成正交 | 两个等尺寸、不同深度的立方体：正交下表观尺寸相同，透视下近的大、远的小 |

我还预测：单个物体时，“模型自转”和“相机环绕”看起来很像，所以不能用“画面看起来差不多”来判断是谁变了。

### 2. 我实际输入给AI的提示词

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

### 3. AI建议摘要（包括关键数学依据）

- 第一组：只改 M 的 `tx`，保持 eye/target 不变；打印 `world = M·c_local`（`CG5.point(mm, stats.center)`）。依据：世界坐标由 M 决定，与 V 无关。
- 第二组：只改 V 的 eye，保持 M 不变；打印 `V·world`，eye 在观察坐标里应恒为 (0,0,0)，target 应落在 (0,0,-d)。依据：lookAt 把相机放到观察坐标原点，朝 -Z。
- 第三组：固定同一 M、V，只切换 P，并打印同一个世界点在两种 P 下的 NDC 坐标与 NDC 宽度；另外用“FOV 20°/50°/90°”与“模型 scale 变化”作对照，区分“视锥变大”和“物体变大”。
- AI 还提醒：判断投影不要只看物体在屏幕上的像素大小，因为 canvas 分辨率会变；应该看 NDC 宽度。

### 4. 我的判断和采纳/拒绝理由

- **采纳**“打印 NDC 宽度”和“打印世界中心”这两条，因为它们能给出数值而不是感觉。
- **采纳**“同 M/V 只切 P”的控制变量表。
- **拒绝** AI 顺带建议的“用两个不同颜色的物体判断相机是否移动”，因为本实验 C 页面已经自带近/远两个等尺寸立方体，再加物体反而引入新的变量。
- 我补充了一条 AI 没提的检验：把正面→侧面→正面各截一张 PNG，直接比较字节，用“完全一致”来证明“相机来回移动不改变世界坐标与最终成像”。

### 5. 我的测试参数、测试操作与结果（附截图/数值）

**B：四个预设 + 世界中心是否变化**

| 视角 | eye | target 在观察坐标 | 模型世界中心 |
|---|---|---|---|
| 正面 | (0,0,8) | (0,0,-8) | (0.00,0.00,0.00) |
| 侧面 | (8,0,0) | (0,0,-8) | (0.00,0.00,0.00) |
| 顶部 | (0,8,0)，up=(0,0,-1) | (0,0,-8) | (0.00,0.00,0.00) |
| 斜上方 | (6,4,7) | (0,0,-10.05) | (0.00,0.00,0.00) |

四个预设的 View 矩阵全部 `Number.isFinite`，顶部没有黑屏；eye=target 时抛出“eye and target coincide: lookAt is undefined.”。
正面→侧面→正面：两张正面 PNG 的 MD5 完全相同（`507a3598cf6349128155e0e8cca641de`），逐像素差为 0 个像素（截图 `B-front.png`、`B-side.png`）。

**C：同一 M/V 只切 P**

| 条件 | 近立方体 NDC 宽度 | 远立方体 NDC 宽度 | 比值 |
|---|---|---|---|
| 正交（orthoH=5.5，aspect=1.60） | 0.369 | 0.369 | **1.000** |
| 透视（FOV=50°，near/far=0.1/100） | 0.246 | 0.185 | **0.751** |

- 正交下把 FOV 从 50° 改成 90°，投影矩阵逐元素完全相同（差 < 1e-12），说明正交投影与 FOV 无关。
- 透视 FOV 50°→90°，物体在画面中的占比约变为 `tan25°/tan45° ≈ 0.466`，即“FOV 变大、物体变小”。
- near 从 0.1 推进到 9.2 时，茶壶和近处立方体被裁掉一部分（截图 `C-4-near-clipping.png`），但状态栏仍显示模型存在、“模型世界中心”仍是 (0,0,0) —— 这是裁剪，不是删除对象。
- near=0 报“near must be > 0”，near=10、far=5 报“far must be > near”；重置后回到 0.1/100。

### 6. AI是否正确？我最终修正了什么认识？

AI 的三组控制变量是对的，NDC 判据也确实能区分 M/V/P。但我修正了一个认识：**“画面变了”不等于 M 变了**。我原来习惯看画面，现在固定先读状态栏的“模型世界中心”：相机移动时这个数一直是 (0,0,0)，只有改 `tx/ty/tz/rx/ry/scale` 它才动。另外我确认了正交“没有近大远小”不是渲染问题，而是正交投影矩阵里没有 1/z 这一项。

---

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

### 1. 真实错误现象和我起初怀疑的原因

我在用数值脚本逐项检查 D 的拖动时发现两个真实问题：

1. **顶部视角 Shift 拖动方向相反**：eye=(0,8,0) 时，向右拖 100px 得到 `T=(-1.148,0,0)`，模型往画面左边跑；上下方向同样颠倒。
2. **E 的“绕 X 轴”不转**：把轴切成 X 后，θ 从 0° 到 120°，橙色标记一直停在 (1.900,-0.500,2.000)，只有圆环在原地。

我起初怀疑是“投影矩阵写错了导致鼠标映射不对”，也怀疑是“宽高比拿错，画面被拉伸所以方向看起来歪”。

### 2. 向AI提出的诊断问题

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

### 3. AI建议的至少两个可区分原因及测试

| 假设 | 最小测试 | 我的结果 |
|---|---|---|
| ① 宽高比用了 canvas 像素尺寸而不是 CSS 尺寸，导致图像拉伸 | 把窗口拉成正方形再切透视，看茶壶是否还被拉长 | 茶壶比例正常；`stat-projection` 里 aspect=1.60 与画布 `width/height` 一致 → **排除** |
| ② near/far 把模型切在视锥外，看起来像“消失” | 保持 near=0.1 不变，只把 near 慢慢推到 9.2 | 模型是被裁掉一部分、其余仍正确，说明裁剪面正常 → **排除** |
| ③ 矩阵乘法顺序写反（M·V·P 而不是 P·V·M） | 打印 V 对 eye/target 的映射：eye 应变成 (0,0,0)，target 应变成 (0,0,-8) | 实测正是 (0,0,0) 与 (0,0,-8) → 顺序正确，**排除** |
| ④ 观察基向量 right/up 与真实 up 不一致 | 打印顶部视角下 `f`、`right`、`up`，再与 `lookAt` 实际使用的 up 对比 | 发现：View 用 (0,0,-1)，而拖动用的基向量固定用 (0,0,1) → **命中** |

AI 没有直接给整套代码，只给了“打印基向量”这个最小测试，这一点我采纳了。

### 4. 我实际逐项测试了什么？各自结果如何

- 测试①：改窗口比例后重新截图，模型没有被拉伸；aspect 打印值与画布一致。
- 测试②：near 9.2 时截图 `C-4-near-clipping.png` 可见近处物体被切掉，远处立方体还在，说明是裁剪面而不是矩阵错。
- 测试③：打印 `V·eye=(0,0,0)`、`V·target=(0,0,-8)`，证明 View 的构造与乘法顺序都是对的。
- 测试④：顶部视角打印出 `forward=(0,-1,0)`，View 用的 up 是 (0,0,-1)，而我的拖动基向量用的是 (0,0,1)，叉乘出来的 right 符号相反，因此左右、上下都反。

### 5. 最终根因、修复处及修复后结果

- **根因 1（D）**：`js/task-d.js` 的 `cameraBasis()` 里，垂直视角统一取了 `up=(0,0,1)`，与 `js/task-b.js`、`lookAt` 使用的 `up=(0,0,-1)`（向下看时）不一致。屏幕 y 轴方向与世界的 up 对不上，平移就反了。
  **修复**：按 `f[1]` 的符号选择 up（向下看用 (0,0,-1)，向上看用 (0,0,1)），再叉乘得到 right 和 up。
  **修复后**：顶部视角向右拖 100px → `T=(1.148,0,0)`（与画面方向一致）；正面 (0,0,8)→(1.247,0,0)；侧面 (8,0,0)→(0,0,-1.148)。
- **根因 2（E）**：`js/task-e.js` 里标记初始点 q 固定放在 P 的 +X 方向。绕 X 轴旋转时，位于轴线上的点是不动点，所以标记不动——这不是渲染 bug，是初始条件的几何错误。
  **修复**：q 沿“与所选轴垂直”的方向放置（Y 轴用 +X，X 轴用 +Z，Z 轴用 +X）。
  **修复后**：P=(1.2,-0.6,0)、轴 X、r=1.1、θ=90° → 标记 (1.200,-1.700,0.000)，明显转动。
- 修复完成后五个页面在 Chromium 里重新跑完整链路，**Console 没有任何 exception 或 error**。

---

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

### 1. 我准备完成的观察任务

主题定为“茶壶壶嘴/把手方向观察 + 绕点旋转标记”：固定一个参考点 P，让一个小方块绕 P 转，用来回答“绕点旋转 T(P)·R·T(-P) 和模型自转有什么不同”。

### 2. 向AI询问的两种设计方案

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

AI 给了两个方案：

**方案 A：指定点 + 多轴绕点旋转 + 轨道参考环（单画布）**

- 矩阵链：`M_orbit = T(P)·R(axis,θ)·T(-P)·T(q)·S`，整帧仍是 `P_proj·V·M_model`，辅助对象单独一条链。
- 交互参数：P 的 x/y/z、旋转轴（X/Y/Z）、半径 r、角度 θ。
- 验证难度：低。可以直接打印 `orbitPoint()`，检查“到 P 的距离恒等于 r”“P 自己不动”。

**方案 B：正交/透视双画布同步对照**

- 矩阵链：两个画布共用同一 M、V，只有 P 不同；需要两个 WebGL2 context 或两次 `viewport` 绘制。
- 交互参数：拖动/滚轮同时驱动两套绘制。
- 验证难度：中高。要保证两画布同步、两套 canvas 的 aspect 各自正确、截图要拼两张。

### 3. 两种方案的功能、矩阵链、测试难度对比

| 维度 | 方案 A（绕点/多轴/参考环） | 方案 B（双画布投影对照） |
|---|---|---|
| 功能差异 | 能验证 T(P)R T(-P)，可换轴、改半径 | 能同屏对照两种投影 |
| 矩阵链 | 1 条附加链，挂在现有 extra() 上 | 需要第二套渲染入口 |
| 交互参数 | 6 个（P×3、轴、r、θ） | 0 个新参数，但要共享状态 |
| 验证难度 | 低（数值可判） | 中高（同步与截图） |
| 复用成本 | 复用 `ex.extra`、`CG5.chain`，改 UI 一处 | 要改 render 循环 |

### 4. 最终采纳的方案与理由

**最终是我决定采用方案 A**，不是 AI 决定的。理由：

1. 40 分钟内能做完并留出测试时间；方案 B 要改渲染入口，容易把 A—D 的共用渲染循环弄坏。
2. 指导书 E7 要求“至少一处实质性功能设计”，方案 A 正好补上“旋转中心可输入、轴可切换、半径可调、带预测环”这四项差异。
3. 方案 B 本质上就是 Challenge 1（双画布同步对照），如果后面有时间，我会把它作为加分项单独做，而不是塞进 E 里。

### 5. 自己实现或修改的功能差异

- `task-e.js`：新增 `orbitConfig()`（读 P、轴、半径，按轴决定 q 的垂直方向）、`orbitMatrix()`、`orbitPoint()`；`extra()` 返回 26 个对象（1 个 P 标记 + 24 个轨道参考点 + 1 个运动标记）。
- `ui.js` 第 05 面板：增加 P 的 x/y/z、旋转轴下拉、轨道半径输入。
- `app.js`：`defaults` 增加 `px/py/pz/orbitR/orbitAxis`；E 页初始相机改为斜上方 (6,4,7)，否则水平轨道环正好被看成一条线，看不清；重置按钮同步使用这份 E 专用默认值。
- 这三处修改都保留了原有接口（`ex.extra` 的返回格式不变），A—D 页面未受影响（每页都单独跑过）。

### 6. 预测与实际结果对照，仍存在的局限

| 参数 | 预测位置 | 实测位置 |
|---|---|---|
| P=(0,0,0)，Y 轴，r=1.6，θ=0° | (1.6,0,0) | (1.600,0.000,0.000) |
| θ=90° | (0,0,-1.6) | (0.000,0.000,-1.600) |
| θ=180° | (-1.6,0,0) | (-1.600,0.000,0.000) |
| θ=270° | (0,0,1.6) | (0.000,0.000,1.600) |

四个角度到 P 的距离都是 1.600，说明旋转矩阵没有引入缩放；把 P 移到 (1,-0.5,2) 后，`T(P)R T(-P)` 作用在 P 上仍得 (1.000,-0.500,2.000)，证明 P 是不动点。

**局限性**：轨道环用 24 段离散点近似，放大看是点列；标记是立方体而不是导入的模型，不能体现“部件父子关系”；没有轨迹拖尾；没有做光照。

---

## 全局诚信声明

- 我提交的代码均已本人运行并核验；无法解释的AI输出未直接作为完成结果。
- 上述所有坐标、NDC 宽度、MD5、界面数值均来自本机 Chromium（WebGL2）实测，截图在本包 `screenshots/` 目录中。
- 我明确标注了使用AI辅助的功能（概念对照表、故障假设清单、方案对比）和本人自主完成的关键判断（采用哪种交互映射、最终选定方案 A、修复 up 基向量与 q 初始方向）。