AI 协作日志

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

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

学号：202312211503020　　　　姓名：陶依宁　　　　日期：2026/11/9

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

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

1. 我的问题和事先预测（M/V/P中谁变化？预期画面如何变化？）：
问题：在一个物体的场景里，怎样用控制变量区分“移动物体（M）”与“移动相机（V）”，以及“正交（P）”与“透视（P）”？
预测：
只改 M（转物体）时，模型世界中心数值变、相机参数不变；
只改 V（环绕相机）时，相机 eye 变、模型世界中心数值不变；
只改 P（正交↔透视）时，M、V 都不变，仅“近大远小”表现与 FOV 效果不同。
2. 我实际输入给AI的提示词：
在 WebGL2 右手坐标系、列向量和 P·V·M 顺序下，我想比较移动物体与移动相机、正交与透视投影。请给我三组能区分原因的控制变量实验，指出应改变 M/V/P 中的哪项，说明可以打印哪些坐标数值进行核验，不要直接生成整套代码
3. AI建议摘要（包括关键数学依据）：
依据 p_clip = P·V·M·N·p_local：M 决定物体在世界中的位姿，V 由 eye/target/up 决定，P 由 ortho/perspective 及 near/far/fov 决定，三者互相独立。
三组控制变量：
固定 V、P，只改 M 的 ry：打印 CG.point(M, center)应变化，eye/target 不变。
固定 M、P，只改 V 的 eye：打印世界中心应不变，相机 eye 变。
固定 M、V，只切换 mode（ortho/perspective）：两个等尺寸、不同深度的立方体在正交下表观尺寸基本相同，透视下近大远小；改 fov 只影响透视。
建议打印：模型世界中心、eye/target、当前 P 的关键参数
4. 我的判断和采纳/拒绝理由：
采纳三组控制变量与打印项，因为它们直接对应 #stat-world、#stat-camera、#stat-projection，可用页面状态栏取证
拒绝“直接生成整套代码”，按要求自己实现 view/projection，AI 只给排查思路
5. 我的测试参数、测试操作与结果（附截图/数值）：
B 页：模型茶壶，M 不变（tx=ty=tz=0, rx=ry=0, scale=1），P 默认透视 50°。切预设 正面(0,0,8)→侧面(8,0,0)→顶部(0,8,0)→斜上(6,4,7)，再回到正面。
结果：stat-camera 随 eye 变；stat-world 始终为同一值；顶部无黑屏/NaN。截图：实验5_TaskB.png。
C 页：开启“显示近/远等尺寸立方体”，near=0.1、far=100、fov=50。
正交：两立方体表观尺寸基本相同；切透视：右侧（更远，z=-3）明显更小。
fov 50→80：透视下物体占比减小；切正交改 fov 画面不变。
near 推进到接近模型：部分几何被近裁剪面裁掉，stat-model、Model 参数不变。截图：实验5_TaskC.png。
6. AI是否正确？我最终修正了什么认识？
AI 正确。修正的认识：FOV 变化只改 P，不等同于 Model 缩放；透视近大远小的根源是透视除法除以与深度相关的 w。画面相似不等于矩阵机制相同，必须以 M/V/P 状态数值为证据

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

1. 真实错误现象和我起初怀疑的原因：
现象：切到透视后拖动/缩放感觉形状“被拉伸”，Shift+左拖方向与画面不一致；另外 Console 曾报 task-d.js 中 clamp 相关错误、相机基向量处 let f=... 报错。
起初怀疑：投影宽高比不对或拖动时用错了矩阵
2. 向AI提出的诊断问题：
我的 OBJ 能显示，但切换透视投影后形状被拉伸/裁剪或者鼠标拖动方向异常。请从宽高比、裁剪面、矩阵顺序和观察基向量中提出至少三种假设，分别给一项最小测试，先帮助排查，不要直接重写完整程序
3. AI建议的至少两个可区分原因及测试：
假设1 宽高比：P 的 aspect 与 Canvas 实际 width/height 不符 → 测试：打印 aspect 与 canvas.width/canvas.height 对比。
假设2 裁剪面：near≤0 或 far≤near → 测试：把 near 设为 0 或 far 设为 0.05，看是否报“需要 0<near<far”。
假设3 观察基向量：Shift 平移未用相机 right/up，或 up 与视线平行 → 测试：切顶部视角看是否黑屏/NaN；切侧面后再 Shift 拖动看方向是否仍沿画面右/上
另指出语法类：同一脚本重复引入导致 clamp/f 重复声明，或箭头函数/展开语法在该环境不兼容
4. 我实际逐项测试了什么？各自结果如何？
aspect：scene.resize() 返回 w/h，与 P 使用一致，排除。
near/far：设 near=0 与 far=0.05，页面显示“参数错误：需要 0<near<far”，C1 校验生效，排除。
基向量：切顶部视角正常（up 自动用 (0,0,-1)）；切侧面后 Shift 拖动仍沿画面右/上，D2 基向量实现正确，排除。
语法：确认 task-d.js 被 HTML 引入了两次导致 Identifier 'clamp' has already been declared；另将 const clamp=... 改为 function clamp(...)，把相机基向量里的 let f 改为局部 var/不同变量名，消除重复声明与老环境不兼容
5. 最终根因、修复处及修复后结果：
根因一：task-d.js 在 HTML 中重复引入，造成 const 重复声明报错。
根因二：clamp 用 const 箭头函数，存在重复声明/环境兼容风险；相机基向量 let f 重名。
修复：删除重复 <script src="js/task-d.js">；clamp 改为函数声明；基向量改用不重名的局部变量；保留 near/far 与 aspect 校验。
结果：拖动、Shift 平移、滚轮、键盘均正常，Console 无报错；滚轮放大表观尺寸时 stat-transform 中 scale 保持 1。截图：实验5_TaskD.png

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

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

1. 我准备完成的观察任务：
在茶壶/兔子模型上，观察一个标记绕“固定参考点 P”旋转，对比它与标记“自转”的差别，并验证 T(P)Ry(θ)T(−P) 的坐标效
2. 向AI询问的两种设计方案：
我已完成 OBJ 导入、观察视角、正交/透视以及鼠标键盘变换。请提供两个能在 40 分钟内复用已有 WebGL2 模块的观察台拓展设计，对比功能、矩阵链、交互参数和验证难度。不引入 Three.js、光照、纹理或复杂模型编辑器
3. 两种方案的功能、矩阵链、测试难度对比：
方案甲：固定参考点 + 绕点运动标记。矩阵链 M_orbit=T(P)Ry(θ)T(−P)T(q)S，交互参数用现有 orbit 滑块；验证：orbit=0/90 对比，橙块绕黄点转、红块不动，难度低
方案乙：父子继承（标记挂在父部件下）。矩阵链 M_child=M_parent·T(offset)·R(θ)·S，需额外维护父子层级与父矩阵传递；验证层级关系更复杂，难度中高
对比：甲复用现有 extra 与 orbit，40 分钟内可完成；乙功能更强但需改渲染与状态结构，时间风险大
4. 最终采纳的方案与理由：
采纳方案甲（绕点旋转标记），并在此基础上做自拟扩展：参考点 P 可由 URL 参数 ?px=&py=&pz= 输入，配合 orbit 滑块观察绕点运动。理由：复用已有模块、矩阵链与指导书公式一致、可测且时间可控
5. 自己实现或修改的功能差异：
在 ex.extra 中返回三个对象：黄块标参考点 P、红块标初始 q、橙块按 T(P)Ry(θ)T(−P)T(q)S 绕 P 运动
自拟功能：getPointP 读取 s.px/py/pz 或 URL 参数，改变旋转中心；这是“模型旋转中心输入”的实质功能，非改标题/颜色
6. 预测与实际结果对照，仍存在的局限：
预测：orbit=0 时橙块在 q；orbit=90 时橙块绕 P 转 90°，红/黄块不动；改变 P 后旋转中心随之改变
实际：与预测一致；与“只对橙块做 Ry(θ)”对比，后者位置不变，前者位置改变。截图：实验5_TaskE_orbit0.png、实验5_TaskE_orbit90.png、实验5_TaskE_P0.png
局限：标记用立方体近似，未画轨道线；参考点输入依赖 URL 参数，未加入 UI 控件；未做父子继承（作为后续可扩展项）

## 全局诚信声明

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


**思考：** 为什么归一化矩阵应最先作用于模型本地顶点？为什么不能对每个轴单独缩放到相同长度？
N 必须最先作用，因为中心和最长边都是在模型本地坐标里量的：先 T(−c) 居中、再按 2/L 等比缩放，之后 M、V、P 才作用在规范模型上；若先做 M，中心会偏移、L 失真，不同模型也无法比较。不能逐轴缩放到相同长度，因为各轴缩放比不同会改变三轴比例，把非等立方体模型拉长或压扁、破坏外形，旋转时还会变形，所以要用统一因子 2/L 做等比缩放，保证居中、尺寸合适且不变形

**思考：** 为什么在一个物体的场景里，转动物体与相机环绕有时看起来相似，在多个物体时却不等价？
单物体场景里，转物体和环绕相机之所以看起来相似，是因为两者都只改变了“物体与相机之间的相对位姿”，而画面只取决于这个相对关系，所以视觉上可能一样。但两者在数学上并不等价：转物体改的是 M，环绕相机改的是 V，物体的世界坐标并未改变。多物体场景下这种差别立刻显现——相机环绕会让所有物体一起改变观察角度、背景与参照物同步移动，而转动物体只改变被转的那个物体，其他物体和世界参照保持不动，遮挡关系、相对位置也不同，因此画面不再等价。

**思考：** 透视投影为什么产生近大远小？FOV变化为什么不能等同于Model缩放？
透视投影产生近大远小，是因为投影矩阵把顶点坐标除以了与深度成正比的 w 分量：同样大小的物体，离相机越近，w 越小，x、y 被除后越大，在画面上就越大；越远 w 越大，成像越小。FOV 变化不能等同于 Model 缩放，是因为 Model 缩放改的是物体自身在世界中的尺寸，物体与环境的相对大小、遮挡和深度关系都随之变化；而 FOV 只改投影矩阵 P 的视锥张角，物体世界尺寸和位置完全不变，只是成像到屏幕的比例和透视强度变了，背景、裁剪范围与近大远小的程度也会跟着变，所以二者数学机制不同

**思考：** 相机靠近与Model放大有什么本质区别？为什么Shift拖动的方向需要结合当前相机方向计算？
相机靠近改的是 V，物体世界尺寸不变，只是观察距离变小、透视上显得更大；Model 放大改的是 M，物体在世界中实际变大，相机不动，与环境、遮挡的相对关系随之改变。Shift 拖动要把屏幕二维位移换算成三维世界平移，必须借助相机当前的 right/up 基向量，这样切到侧面观察后拖动仍沿画面右/上方向移动