AI 协作日志

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

# 实验二 AI协作记录

> 使用工具：Trae AI 编程助手（对话式代码助手）。以下提示词与测试结果均为本轮实际记录；所有采纳的代码都在浏览器中逐项运行验证。

## AI协作1 · Koch算法
### 我的目标与初步判断
初始三角形 `[-0.82,-0.43] → [0.82,-0.43] → [0,0.99]` 是逆时针绕行，因此我判断：沿边 `A→B` 前进时，轮廓外侧应在右手边，`Q-P` 需要顺时针旋转 60°（即 −60°），再与 `P` 相加得到凸起点 `R`。同时我先预测线段数：每条边每层变为 4 段，初始 3 条边，所以 Level n 为 `3×4^n`，Level 3 应为 192 段。

### 关键提示词（原文）
“等边三角形顶点按逆时针排列，对边 A→B 取三等分点 P、Q。要让凸起朝轮廓外侧，向量 Q-P 应旋转 +60° 还是 -60°？请给出判断依据，不要直接给完整 Koch 程序。另外为什么 Level 3 应有 192 条线段？用 LINE_LOOP 绘制时顶点数是否也等于线段数？”

### AI关键建议摘要
1. 用多边形绕行方向判断外侧：逆时针多边形的外侧在前进方向右侧，故对 `Q-P` 作 −60° 旋转；建议先用一段水平线单独验证凸起在下方（外侧）。
2. 线段数递推为 `4^n` 倍，初始 3 条边，所以是 `3×4^n`；Level 3 = 3×64 = 192。
3. `LINE_LOOP` 把每个顶点当作一段的起点，GPU 自动连接末点与首点，因此只需上传 `3×4^n` 个顶点（每段只存起点），不必重复存终点。

### 我的测试方法与结果
- 用 Node 直接调用 `buildKoch(n)` 打印点数：Level 0—4 依次为 **3 / 12 / 48 / 192 / 768**，与 `3×4^n` 一致。
- 打印 Level 1 第一条底边的四个点：`(-0.82,-0.43)`、`(-0.273,-0.43)`、`(0,-0.9034)`、`(0.273,-0.43)`；凸点 y = −0.9034 位于底边下方，确认朝外。
- 遍历 Level 4 全部顶点，x 范围 [−0.82, 0.82]，y 范围 [−0.9034, 0.99]，未超出 NDC 可见范围。
- 浏览器截图确认图形封闭、无自交、尖角朝外。

### 采纳情况及修正结论
采纳 −60° 旋转与 `LINE_LOOP` 每段存起点的组织方式。实现写成 `r=[p.x+dx*c+dy*s, p.y−dx*s+dy*c]`（`dx,dy` 为 `Q-P`，`c=0.5, s=√3/2`）。AI 未给出完整程序，递归的四段顺序 `A→P→R→Q→B` 与终止条件由我自己编写并逐层核对。

## AI协作2 · 绘图板调试
### 具体错误现象（如一次成功，可先人为注入并恢复一个小错误）
为验证 Y 轴处理，我临时把 `pointerToNDC` 中的 `yNDC = 1 - 2*yCanvas/canvas.height` 改成不翻转的 `yNDC = 2*yCanvas/canvas.height - 1`。此时点击 Canvas 左上角，图形出现在左下角，整个画面上下镜像；恢复翻转后同名位置绘制正确。

### 我的初步排查
按“元素位置 → CSS 缩放 → 像素坐标 → NDC”的顺序逐项怀疑：① 是否漏减 `rect.left/rect.top`；② Canvas 显示尺寸被 CSS 缩放后是否仍按 `canvas.width` 直接换算；③ Y 轴是否漏翻转。我先用四角点击法定位问题：左上点跑到左下，说明是第③项。

### 关键提示词（原文）
“Canvas 的 CSS 显示尺寸和 `canvas.width` 不一致时，`getBoundingClientRect()` 得到的 left/top 与宽高该怎么参与换算？为什么 `clientY` 转 NDC 必须翻转 Y 轴？请给出可用于四角测试的检查步骤。”

### AI建议与逐项测试
AI 建议：先 `(clientX-rect.left)*canvas.width/rect.width` 得到 Canvas 像素 x，y 同理；再 `xNDC=2*xCanvas/canvas.width-1`、`yNDC=1-2*yCanvas/canvas.height`（Y 翻转）；用四角与中心点核对。我逐项测试：
- 左上角 client(100,50)、rect 在 (100,50) → NDC **(-1, 1)**；
- 右下角 client(820,670) → **(1, -1)**；
- 中心 client(460,360) → **(0, 0)**；
- 把 rect 宽高改为 360×310（模拟 CSS 缩放一半）后点击 client(280,205) → 仍为 **(0,0)**；
- 取消 Y 翻转的错误版本下，左上角返回 **(-1,-1)**，证实镜像来源。
另外用事件模拟测试两次点击状态：第一次点击后 `firstPoint` 有值、objects=0、状态“等待第二次点击（线段）”；第二次点击后 `firstPoint=null`、objects=1；切换工具后 `firstPoint=null`，旧的第一点不会被复用。

### 最终原因及修复证据
原因是 Y 轴未翻转（以及缩放系数未参与换算）。恢复公式后四角/中心测试全部正确；浏览器中先画点、再画线、最后画矩形，三种对象同时保留，计数依次为 1→2→3，切换工具时状态回到“等待点击”，点“清空”后对象数归零。不翻转的错误版本只在临时测试脚本中运行，提交的 `js/task-d.js` 中未保留错误代码。

## AI协作3 · 主题整合
### 主题及预期效果
主题定为“生长”：Koch 雪花作为“生长纹理”，阿基米德螺旋作为“年轮”，12 条枝条连接外环节点，点击画布在该处长出一个新的芽，形成“纹理—年轮—枝条—新芽”的生长层次。预期复用 B 的 Koch、C 的旋转、D 的鼠标坐标转换，并新增至少两个由 WebGL 绘制的几何组成和一条新的交互规则。

### 两个方案的AI提示词（原文）
“请针对同一主题提出两种只用 WebGL 基本图元实现的方案，并比较图元数量、交互难度、可解释性：(A) 以 Koch 边界 + 外环 + 放射线 + 节点为主，点击移动图案中心；(B) 以 Koch 纹理 + 参数螺旋 + 枝条节点为主，点击位置新增芽点。不要给完整代码，给出几何构成与状态设计。”

### 方案比较、取舍理由
AI 给出：
- 方案A：图元少（Koch、圆环、线、点），交互只是平移中心，容易实现，但“点击移动中心”只改变 uniform 偏移，几何没有增加，和参考示例几乎相同。
- 方案B：新增螺旋（约 220 个顶点的参数曲线）与芽点对象数组，交互会让应用层对象增加，几何和状态都有实质变化；代价是顶点数更多、需要维护 `buds` 数组，但可解释性更强。

我选择方案B：它满足“至少两个新增几何组成”和“一条新增交互规则”，且螺旋有两个有效参数（圈数、半径范围），便于说明。拒绝方案A 的“仅移动中心”，因为它不改变几何，仅是变换参数。

### 实际实现、测试与结果
- 新增几何1：`makeSpiral(turns,count,r0,r1)` 生成阿基米德螺旋 `r=0.46→1.06`、3.4 圈、221 个点，用 `LINE_STRIP` 绘制，旋转角度为 `theta/2`。
- 新增几何2：12 条枝条（`LINES`）与外端节点（`POINTS`），与 Koch 纹理同角度旋转，表现“枝条—芽点”的连接。
- 新增交互：Canvas 点击经 `getBoundingClientRect` 换算为 NDC，向 `buds` 数组追加芽点对象，每个芽点用八角线框 `LINE_LOOP` 绘制，数量显示在状态栏；复位会清空芽点。
- 测试结果：初始画面显示 Koch、圆环、螺旋、枝条、节点；连续点击两次后状态栏由“芽点 0”变为“芽点 2”，画面出现两个新芽；点击“开始旋转”后按钮变为“暂停旋转”、状态变为“旋转中”；层数滑块 0—4 与尺度滑块均能即时改变图形，未出现裁切。

## 其他AI使用（若有）
本轮主要用 AI 做算法方向确认、坐标公式复核和方案比较，并由 AI 辅助生成实现骨架；采纳前我用节点测试与浏览器运行结果逐项核验（线段数、坐标四角、控件状态、点击新增芽点）。任务 A 的 Level 限制、颜色 uniform 更新与重置按实验要求实现，未额外咨询。