AI 协作日志

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

# 实验二 AI协作记录（请据实际情况填写）

## AI协作1 · Koch算法
### 我的目标与初步判断
Task B要求自己实现Koch雪花的线段替换规则。P和Q两个三等分点好算，卡住我的是突起点R的旋转方向：文档提示 "向量Q-P绕原点旋转±60度，与点P相加可得到候选点R"，但没说到底用正60还是负 60。我的初步判断是这和初始三角形的绕行方向有关：我的底边是从左往右走的，这时"外侧"在下方，旋转后的向量应该朝下。但我不确定旋转公式里正负号和顺逆时针的对应关系，也不敢保证自己的判断对。
### 关键提示词（原文）
我在实现Koch雪花的等边三角形突起点。已知线段上三等分点P和Q，文档说把向量Q-P旋转正负60度后加到P上得到候选点R。我的初始三角形三个顶点逆时针排列，底边从左往右走。请问我应该用正60度还是负60度才能让凸起朝三角形外面？请解释旋转公式的符号和顺逆时针的对应关系，并给我一个能用一条水平线段快速验证方向的方法，不要直接给我完整的Koch代码。
### AI关键建议摘要
AI的解释分三层：
1. 旋转公式：向量(x,y)旋转theta角后是(x乘cos theta减y乘sin theta，x乘sin theta加y乘cos theta)。theta为正时在数学坐标系里是逆时针，theta为负是顺时针。
2. AI特别提醒：不能只背角度符号的结论，因为Canvas的Y轴朝下而WebGL的NDC的Y轴朝上，很多教程把这两个坐标系搞混，得出的结论正好相反，要结合自己的坐标系实际测。
3. 验证方法：先用一条从左到右的水平线段做实验。水平线段的Q-P向右，旋转正60度后R的y分量是正的（在NDC里朝上），旋转负60度后R的y分量是负的（朝下）。我的底边外侧朝下，所以应该用负 60 度。
### 我的测试方法与结果
1. 水平线段测试：P取(-0.5, 0)，Q取(0.5, 0)，Q-P是(1, 0)。按旋转公式，负60度时s等于负的二分之根号三，算出R的y分量约等于负0.866，朝下。
2. 把这个方向写进subdivideSegment，先只画Level 1的底边，看突起是不是朝下。结果朝下，凸起在外面。
3. 再画完整的Level 1和Level 2，检查三条边都有突起、首尾相连没有断线。
4. 对照文档验收表打印线段数：Level 0是3，Level 1是12，Level 2是48，符合3乘4的n次方。
### 采纳情况及修正结论
采纳了AI的验证思路，最终用的是负60度（顺时针60度），代码里写成c等于0.5、s等于负的二分之根号三。三角形顶点逆时针排列，边沿逆时针方向行走时外凸采用右转60度。

## AI协作2 · 绘图板调试
### 具体错误现象（如一次成功，可先人为注入并恢复一个小错误）
Task D一开始按文档的测试要求 "在Canvas四角附近创建点" 时发现：我点击Canvas上半部分，点却出现在下半部分；点右上角，点跑到右下角。左右是准的，上下完全颠倒了。
### 我的初步排查
我的第一反应是公式抄错了，把坐标转换那段逐行对了一遍文档给的公式，没发现差别。然后怀疑是getBoundingClientRect的问题，console.log了rect的left和top，数值看着也正常。上下颠倒而左右正常，我隐约觉得和Y轴方向有关，但我以为Canvas的Y轴本来就是朝上的，说不清问题在哪，于是让AI帮我把可能原因列全。
### 关键提示词（原文）
我在写WebGL2鼠标绘图板，把event.clientX和clientY转换成NDC坐标。现在的问题是我点击Canvas上方，图形画在下方，上下颠倒，左右位置是对的。我检查过转换公式和文档给的一样，rect的数值也正常。请不要直接帮我改代码，列出最可能的3个原因，并告诉我每个原因怎么验证。
### AI建议与逐项测试
原因1：Y轴没有翻转。浏览器事件的clientY从页面顶部往下算，Canvas像素坐标也是从上往下，但WebGL的NDC的Y轴朝上，所以必须做"1减2乘yCanvas除以高度"这个翻转。验证方法：检查yNDC那一行是不是写成了"2乘yCanvas除以高度再减1"，如果是就是没翻转。
原因2：CSS尺寸和Canvas像素尺寸不一致导致缩放偏移。验证方法：对比canvas.width和rect.width，如果不相等，公式里乘canvas.width除以rect.width 那两步就起作用。AI还说明这种问题的特征是上下左右一起偏，不会只颠倒上下。
原因3：rect取到了错误的元素。验证方法：打印rect的top和height，再打印clientY，手算一遍。
按顺序测试：
1. 检查我的yNDC，果然写成了"2乘yCanvas除以canvas.height再减1"，没有翻转。改成"1减2乘yCanvas除以canvas.height"后，点击位置立刻正确了。
2. 原因2顺带验证：打印canvas.width和rect.width，我页面里Canvas是固定尺寸，两者相等，所以缩放那两步暂时不起作用，但公式里保留着是对的，以后窗口缩放会用上。
3. 原因3不需要再查，rect数值早就打印过，正常。
### 最终原因及修复证据
最终原因：yNDC计算时没有做Y轴翻转。浏览器和Canvas像素坐标的Y轴朝下，WebGL的NDC的Y轴朝上，两套坐标系方向相反，必须翻转。
修复证据：修正后Canvas四角分别点击，点位置和鼠标一致；调整浏览器窗口大小后再点中心也准确。复现实验（故意取消Y翻转再恢复）完整对上了现象、原因和修复。
## AI协作3 · 主题整合
### 主题及预期效果
我选的主题是"绽放"。绽放的意象是：以Koch雪花作为花心，向外延伸出圆环、放射线条，模拟花朵向外舒展；点击Canvas可以把整个图案的中心移到点击位置。
### 两个方案的AI提示词（原文）
webgl2中主题 “绽放”，基于koch雪花，请给我两套不同实现方案，分别说明图元、交互、性能优缺点，不要直接写完整成品代码
### 方案比较、取舍理由
方案一：粒子系统，大量动态小粒子向外飞散模拟绽放效果。
优点：视觉效果华丽；
缺点：顶点数量巨大，层级高的时候性能压力大；粒子运动逻辑复杂，初学者调试难度高。
方案二：以Koch雪花作为花心；新增外围装饰圆环、放射线条以及端点圆点。交互：复用雪花旋转控制；新增交互，鼠标点击画布，整套图案移动到鼠标点击位置。
优点：全部使用基础图元LINE_LOOP、LINES、POINTS；顶点数量可控，调试简单；满足实验要求：复用B(Koch)、C(旋转动画)；两套新增几何，一个新增鼠标交互。
缺点：画面没有粒子那么炫，但全部硬性实验要求都可以达标。
我采纳方案二，拒绝方案一。理由三点：
1. 文档明确要求至少新增两个可辨识的WebGL几何部件，方案一粒子逻辑复杂，对于我现阶段调试成本太高。
2. 方案二：圆环作为新增几何1；放射线条+端点圆点作为新增几何2，完全满足任务E的新增几何要求。
3. 顶点数量可控，性能稳定；鼠标移动中心这个新增交互可以很好表现“绽放可以在画布任意位置发生”的主题。
### 实际实现、测试与结果
实际实现：
1. 复用Task B的buildKoch 递归生成花心Koch雪花，LINE_LOOP绘制。
2. 新增几何一：makeCircle生成外围装饰圆环，LINE_LOOP绘制。
3. 新增几何二：放射线条LINES，线条末端绘制POINTS端点圆点。
4. 交互一（复用Task‑C动画）：开始、暂停按钮控制图案整体旋转，requestAnimationFrame驱动动画。
5. 交互二（自己新增）：鼠标点击画布，复用D任务的坐标转换得到NDC，修改uOffset偏移，整套图案移动到点击位置。
6. 附加level滑块、缩放滑块、复位按钮，页面附带简短主题说明。
测试与结果：修改level，雪花分形复杂度变化；拖动scale可以缩放花朵；点击画布，整套绽放图案移动到点击处；暂停、复位全部功能正常，控制台没有报错。
## 其他AI使用（若有）
我使用豆包在Task D上多做了一步挑战功能：对象点选、改色和撤销。
其中"点击位置是否命中线段"用到了点到线段的最短距离公式，我让AI解释过它的几何含义：先算向量点积判断垂足投影落在线段的哪一侧，落在端点外侧就直接算到端点的距离，落在线段中间才算垂直距离。我的验证方法是故意把点击位置放在已画线段的中点附近、端点附近和远离线段的地方，观察选中提示是否只在接近线段时出现，实际表现和预期一致。
撤销功能保存objects数组的深拷贝快照，每次新增或改色前先saveSnapshot，撤销时弹出上一个快照整体恢复；测试连画三个对象再连撤三次，能逐步回到空画布。