AI 协作日志

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

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

学号：202412211402019姓名：厉梦瑜 日期：2026‑11‑09

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

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

1. 我的问题和事先预测（M/V/P中谁变化？预期画面如何变化？）：
我修改透视投影的 near、far 参数，一开始预测 near/far 会改变物体大小，产生近大远小效果；认为修改near、far属于修改投影矩阵P，可以直接改变物体显示尺寸，预期调大near茶壶会被放大，调小far物体会整体缩小。

2. 我实际输入给AI的提示词：
> near和far怎么没用

3. AI建议摘要（包括关键数学依据）：
near、far属于投影矩阵P，定义相机空间的裁剪区间，仅保留`[near, far]`之间的片元进行绘制，**并不改变物体大小**；近大远小由fov视场角控制。只有物体落在near‑far区间之外才会消失。near必须大于0且满足near<far。当前相机到原点距离约8.75，初始near=3.71，far=95.02，物体全部落在裁剪区间内部，因此修改参数看不出明显效果。测试方法：near调到8以上可以裁切茶壶靠近相机部分；far改小到5可使物体整体消失。

4. 我的判断和采纳/拒绝理由：
采纳AI的解释。我之前混淆了fov视场角与near/far的作用，需要手动修改参数完成裁剪测试来验证该结论。

5. 我的测试参数、测试操作与结果（附截图/数值）：
- 原始参数：near=3.71，far=95.02；茶壶完整渲染，调整near/far滑块画面几乎无变化。
- 测试1：near=8.5，far=95.02；茶壶靠近相机的前部被近裁剪面裁掉，后半部分保留可见。
- 测试2：near=3.71，far=5；全部模型被远裁剪面剔除，物体消失。
- 测试3：修改fov视场角，物体大小发生明显变化，印证物体大小由视场角控制。

6. AI是否正确？我最终修正了什么认识？
AI回答正确。修正认识：near/far只负责空间裁剪，不控制物体视觉大小；近大远小效果来自fov视场角；near/far属于投影矩阵P，仅丢弃区间外像素，不会对模型做缩放变换。
## 协作二：程序故障诊断（Task C / D，4分）

1. 真实错误现象和我起初怀疑的原因：
现象：归一化相关计算代码全部写完，但模型依旧尺寸过大，跑出画布，没有被缩放到2单位，也没有移动到坐标原点。
起初怀疑缩放系数`2/L`计算错误、矩阵chain顺序颠倒、平移T(-c)符号写错，一开始没有怀疑return返回值这一行。

2. 向AI提出的诊断问题：
> 那我只想用原本的代码一样的返回 有事吗

3. AI建议的至少两个可区分原因及测试：
① 矩阵计算逻辑出错：包围盒中心、最长边L计算错误；列向量约定下chain(A,B)矩阵乘法顺序颠倒；平移分量符号错误。测试方案：打印输出矩阵N，查看平移、缩放分量数值是否合理。
② 计算完成但返回值依旧是单位矩阵：所有计算代码执行，但return没有输出计算结果N，依旧返回占位单位矩阵；语法不会报错，但归一化功能完全失效。测试方案：将返回值改为`return N`，对比渲染画面。

4. 我实际逐项测试了什么？各自结果如何？
- 测试①：控制台打印矩阵N，矩阵内部平移、缩放数值计算正确，排除计算公式本身错误。
- 测试②：保持`return CG5.mat4.create()`，模型依旧溢出画布，归一化不起作用。
- 测试③：修改为`return N`；模型立刻居中，最长边缩放至2单位，完整显示在画布中。

5. 最终根因、修复处及修复后结果：
根因：A1、A2数学计算已经完成，但return固定返回占位的单位矩阵，计算得到的N没有交给渲染框架使用。
修复：将`return CG5.mat4.create();`修改为`return N;`。
修复结果：模型归一化功能生效，不同OBJ模型均可居中显示，不会跑出视口。
> 若首次没有故障，可以备份后临时制造一处可恢复错误，完成排查后修复。

## 协作三：工作台方案比较（Task E，3分）
1. 我准备完成的观察任务：
实现Challenge3选做题【任意指定点旋转】，可输入三维点P作为旋转中心，可视化标记P，验证变换矩阵 $M_{orbit}=T(P)\cdot R_y(\theta)\cdot T(-P)\cdot T(q)\cdot S$；对比绕原点自转与绕外部定点公转。

2. 向AI询问的两种设计方案：
方案1：新建独立 challenge.html + challenge.js，手写一套WebGL初始化、渲染循环，独立运行Challenge。
方案2：直接复用task‑e页面，使用框架预留`CG5Exercises.extra(s)`钩子扩展，不新建页面，复用E已有的渲染、UI流水线。

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

| 方案 | 矩阵链 | 功能效果 | 测试难度 |
|---|---|---|---|
| 方案1 | $T(P)\cdot R_y(\theta)\cdot T(-P)\cdot T(q)\cdot S$ | 独立页面运行绕点旋转功能 | 高；本地file协议异步模型加载会卡住Promise，画布空白，需要完整重写WebGL初始化，容易出现环境兼容bug |
| 方案2 | $T(P)\cdot R_y(\theta)\cdot T(-P)\cdot T(q)\cdot S$ | 在Task‑E工作台内扩展，复用课程框架渲染；增加HTML输入框自定义P；标记由框架自动渲染 | 中等；只修改task‑e.html、task‑e.js，不改动A‑D，完全遵循指导书“在工作台基础上扩展”的要求 |

4. 最终采纳的方案与理由：
采纳方案2。理由：实验指导书说明Challenge是在E工作台基础上扩展，不要求独立页面；复用框架`extra(s)`接口，规避本地file协议异步加载带来的页面空白问题；A‑D必做任务不受任何影响。

5. 自己实现或修改的功能差异：
在AI给出的矩阵基础上，增加页面输入UI，支持实时修改旋转中心点P的Px/Py/Pz三维坐标；框架自动渲染黄色中心点标记、橙色公转演示方块。没有改动A/B/C/D任何文件。

6. 预测与实际结果对照，仍存在的局限：
预测：修改P坐标，黄色标记跳到对应空间位置；拖动orbit滑块，橙色方块绕黄色标记公转。
实际测试结果与预测一致。
局限：当前仅实现绕Y轴定点旋转，暂不支持任意旋转轴。

> Challenge选做题实现位置：集成于 task‑e.html / task‑e.js，**未新建独立challenge页面**。


## 全局诚信声明

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