AI 协作日志

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

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

学号：202412211401026　　　　姓名：吴家盛　　　　日期：2026-11-09

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

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

1. **我的问题和事先预测（M/V/P中谁变化？预期画面如何变化？）：**
   我预测：只改Model（如按D让`tx`增加）时，模型世界中心数值改变、画面位置改变；只改View（切换正面→侧面eye）时，世界中心数值不变、画面方向改变；只改Projection（正交↔透视）时，M、V与世界中心都不变，但透视出现近大远小、正交下两个等尺寸不同深度物体表观高度相同。我还预测FOV增大后物体在画面中变小，而不是世界尺寸改变。

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

3. **AI建议摘要（包括关键数学依据）：**
   AI建议分别做三组单变量实验：①固定V、P只改M，打印`CG5.point(M,[0,0,0])`，应看到世界中心随M变化；②固定M、P只改eye/target，打印同一世界中心与屏幕画面，应看到世界中心数值不变而画面方向变化；③固定M、V只切换P，打印投影矩阵与同一对等尺寸物体的NDC高度，正交高度应相等，透视应满足近大远小。数学依据为`p_clip=P·V·M·N·p_local`，从右往左作用：N先归一化，M改世界位姿，V把世界坐标送入相机坐标，P再生成裁剪坐标；FOV属于P，不改变模型世界尺度。AI还提醒顶部视图必须把up换成`(0,0,-1)`，避免与观察方向共线。

4. **我的判断和采纳/拒绝理由：**
   我采纳三组单变量实验和“打印世界中心/NDC高度”的做法，因为它能区分“画面相似”与“机制相同”。我拒绝AI顺带提出的增加光照和纹理以增强对比的建议，因为本实验不考查Phong光照和纹理，会增加无关变量。我也拒绝用修改Model来模拟相机移动，因为那会破坏M/V的可区分性。

5. **我的测试参数、测试操作与结果（附截图/数值）：**
   - Task B：target固定`(0,0,0)`，依次点击正面`(0,0,8)`、侧面`(8,0,0)`、顶部`(0,8,0)`、斜上方`(6,4,7)`。四次“模型世界中心”均为`(0.00, 0.00, 0.00)`；顶部画面正常、无NaN。Canvas非空白，见`截图/task-b.png`。
   - Task C：eye`(0,1.8,8.5)`、aspect≈1.60、near/far`0.1/100`、FOV`50°`、正交高度`5.5`。两个0.78边长立方体分别位于世界`z=0`（近）与`z=-3`（远）。数值核验：正交投影两者NDC高度均为`0.2775`；透视投影近处`0.1884`、远处`0.1424`，近/远比`1.323`。FOV从50°改为80°，同一物体NDC高度由`0.1884`降为`0.1047`（`0.556×`）。见`截图/task-c.png`。
   - Task D：按D一次，`T-X`由`0.00`变为`0.10`，相机eye仍为`(0.00, 1.80, 8.50)`，证明是M而非V。

6. **AI是否正确？我最终修正了什么认识？**
   AI的三组控制变量方向正确，数值与我的预测一致。我修正的认识是：FOV不是“缩放模型”，它只改变视锥的张开角；正交投影没有FOV效果，远近物体表观尺寸相同；移动相机只改V，模型世界坐标保持`(0,0,0)`。另外顶部视图的up必须特殊处理，否则lookAt退化。

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

1. **真实错误现象和我起初怀疑的原因：**
   现象：Task D中左键拖动、滚轮和重置都正常，但按D键后“Model参数”没有变化。起初我怀疑`js/task-d.js`的键盘处理没有执行，或`ex.key`没有更新`state`导致渲染不刷新；也怀疑按键被输入框截获。

2. **向AI提出的诊断问题：**
   > 我的Task D页面鼠标和滚轮正常，但按D时模型X坐标不变。请从Canvas焦点、键盘事件绑定、状态同步和按键映射四个方面提出至少三种可区分假设，每种给一个最小测试，不要重写完整程序。Console目前没有报错。

3. **AI建议的至少两个可区分原因及测试：**
   - 假设A（焦点）：键盘事件挂在window上，但`document.activeElement`可能是INPUT，输入框编辑时按键被有意忽略。最小测试：点击画布中心后打印`document.activeElement.tagName`。
   - 假设B（未绑定/异常）：`CG5Exercises.key`不存在或keydown提前抛出异常。最小测试：在Console检查`typeof CG5Exercises.key`并查看控制台红色报错。
   - 假设C（读取时机/对象错误）：状态已更新但读的是输入框而不是底部“Model参数”文本，或读值早于`sync()`。最小测试：按D后立即读取`stat-transform`文本，而不是读取number输入框。
   - 假设D（按键映射）：`e.key`大小写或字符与`switch`不匹配。最小测试：在keydown监听中打印`e.key`并核对是否进入`switch`分支。

4. **我实际逐项测试了什么？各自结果如何？**
   先复现：点击画布后按D，底部文本仍显示`T (0.00, 0.00, 0.00)`。随后按建议逐项排查：检查`typeof CG5Exercises.key`为`function`，排除假设B；控制台无异常；打印`e.key`为`d`，与`switch`的`case "d"`匹配，排除假设D。最后让画布显式获得焦点（点击画布中心），确认`document.activeElement`为`CANVAS`，再按D并立即读取底部“Model参数”文本，`T-X`变为`0.10`，模型在画面中右移，相机eye仍为`(0.00, 1.80, 8.50)`。

5. **最终根因、修复处及修复后结果：**
   根因是操作/读取问题：第一次测试时键盘焦点没有稳定落在Canvas上，且我读取的是number输入框而非状态文本，因此误判为“键盘无效”；键盘事件和`task-d.js`本身没有缺陷，无需改动代码。修复方式是先点击画布确保焦点，再按键并读`stat-transform`。修复后D键平移、Q/E旋转、+/-缩放均生效，且只改变Model，不改变eye；重置后恢复`T(0,0,0)`、`Rx/Ry 0°`、`S 1.00`、eye`(0,1.8,8.5)`。

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

1. **我准备完成的观察任务：**
   以茶壶为对象，在世界中固定一个参考点P，让橙色标记绕P公转，回答“改变绕点角度时标记是否真的绕P运动、子部件是否继承父部件的变换”。

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

3. **两种方案的功能、矩阵链、测试难度对比：**
   - 方案甲（绕点旋转＋父子继承标记）：新增参考点P与初始中心q，链为`M_orbit=T(P)·Ry(θ)·T(-P)·T(q)·S`；子部件为`M_child=M_orbit_parent·Ry(2θ)·T(0.26,0,0)·S(0.06)`。交互只需现有“标记绕Y旋转”参数，复用`ex.extra`返回对象列表，不改公共渲染循环。验证可用`CG5.point`直接算坐标，容易量化。
   - 方案乙（正交/透视双画布同步对照）：需要第二个Canvas、第二个WebGL2 Program或共享Program重设视口，并在同一`render`中同步绘制两套P。功能对比更直观，但矩阵链虽仍为同一个`P·V·M`，工程改动大、双缓冲/视口/深度清除容易出错，40分钟内回归风险高，验证还要逐像素比较。
   AI认为方案乙展示效果更强，但也指出方案甲的风险低、数学链清楚。

4. **最终采纳的方案与理由（谁决定）：**
   最终由我决定采纳方案甲。理由：能直接复用Task A—D的状态与`ex.extra`接口，不修改`engine.js/app.js/ui.js`的公共结构，不破坏前四个任务；其`T(P)·R·T(-P)`机制可被坐标数值严格验证。方案乙需要动渲染框架，超出本实验对“观察台”的核心要求，因此拒绝。

5. **自己实现或修改的功能差异：**
   在`js/task-e.js`中实现：黄色立方体标记固定参考点`P=(1.5,0.35,0)`；橙色立方体按`M_orbit`绕P公转；另外自主增加一个蓝色子部件，链为父矩阵`·Ry(2θ)·T(0.26,0,0)·S(0.06)`，它既继承父部件的公转，又绕自身局部Y轴以两倍角速度自转。该项是教师示范之外的功能差异，用于验证父子矩阵连乘的继承关系。

6. **预测与实际结果对照，仍存在的局限：**
   预测：θ=0°时橙色标记中心在`(2.40,0.35,0.00)`，θ=90°时在`(1.50,0.35,-0.90)`；蓝色子部件相应为`(2.66,0.35,0.00)`与`(1.50,0.35,-0.64)`。实际在页面把“标记绕Y旋转”由35°改到90°，黄色标记不动、橙色与蓝色标记绕P移动到P后方，方向与数值预测一致；浏览器验证通过。局限：参考点P目前固定，不能输入任意P；子部件只是简单立方体，不涉及骨骼或光照；公转与自转的遮挡关系受深度缓冲影响，极小标记在远距离时辨识度有限。

## 附：Task A—E 数值与截图核验（人工记录）

| 任务 | 测试参数/操作 | 实测数值 | 证据 |
|---|---|---|---|
| A | 内置茶壶默认加载 | `min≈(-1.7903,-0.85,-1.02)`，`max≈(1.77,1.04,1.02)`，`c=(-0.0102,0.0950,0)`，`L=3.5603`，缩放`2/L=0.5617`，`N·c≈(0,0,0)` | `截图/task-a.png`；状态栏“原始中心(-0.01,0.10,0.00)；最长边3.560；缩放0.562” |
| A | 球体/兔子切换 | 球体`c=(0,0,0)`、`L=2`、缩放`1`；兔子`c=(0.03,0.42,-0.0151)`、`L=2.66`、缩放`0.7519`；两者`N·c≈(0,0,0)`，顶点数551/1580、三角面1008/2728 | 浏览器状态栏核验 |
| A | 数学检查用例 | `min=(-2,-1,-1)`、`max=(4,3,1)` → `c=(1,1,0)`、`L=6`、缩放`1/3`、`N·c≈(0,0,0)` | 计算复核 |
| B | 正面/侧面/顶部/斜上方 | eye依次`(0,0,8)`、`(8,0,0)`、`(0,8,0)`、`(6,4,7)`；世界中心四次均`(0.00,0.00,0.00)`；顶部up=`(0,0,-1)`，无NaN/黑屏 | `截图/task-b.png` |
| C | 透视/正交对照 | 同一M/V、两个0.78立方体`z=0`与`z=-3`：正交NDC高度均`0.2775`；透视`0.1884`/`0.1424`，比值`1.323`；FOV50→80高度比`0.556`；near=0或far<near出现“near必须大于0/ far必须大于near”提示 | `截图/task-c.png`；浏览器警告信息 |
| D | 拖动/键盘/滚轮/重置 | 左拖仅Rx/Ry变化、eye不变；按D后T-X`0.00→0.10`、eye仍`(0,1.8,8.5)`；滚轮eye改变而S保持`1.00`；重置后`T(0,0,0)`、`Rx/Ry=0°`、`S=1.00`、eye`(0,1.8,8.5)` | `截图/task-d.png`；浏览器状态核验 |
| E | 绕点角度35°→90° | P=`(1.5,0.35,0)`、q=`(2.4,0.35,0)`；θ=0/90°橙色标记`(2.40,0.35,0)`→`(1.50,0.35,-0.90)`；蓝色子件`(2.66,0.35,0)`→`(1.50,0.35,-0.64)`；黄色参考点固定 | `截图/task-e.png`；浏览器验证 |

## 全局诚信声明

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