AI 协作日志

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

# 实验二 AI协作记录

> AI 工具：豆包（Doubao）
> 协作方式：使用 AI 解释算法原理、提供实现思路，本人实现后用 Node 数值测试或浏览器实测核验，未直接整段粘贴未核验代码。
> 说明：下文"我的初步判断/排查"按本人真实过程填写，浏览器实测部分以本人本地运行结果为准。

## AI协作1 · Koch算法（Task B）

### 我的目标与初步判断
目标：不照搬教材现成代码，独立实现 Koch 雪花的线段分割算法——三等分点 P、Q 和外凸等边三角形顶点 R。
初步判断：外凸顶点 R 的旋转方向（+60° 还是 −60°）应该与初始三角形的绕行顺序有关；我最初不确定具体符号，担心凸起会朝内，打算先实现再验证方向。

### 关键提示词（原文）
- "Koch 雪花的线段分割算法思路是什么？P、Q、R 三个点分别怎么求？"
- "怎么确认外凸顶点 R 的旋转方向（+60° 还是 −60°）能让凸起朝外？"
- "如何验证算法实现是否正确（顶点数量和方向）？"

### AI关键建议摘要
1. 三等分点：P = A + (B−A)/3，Q = A + 2(B−A)/3。
2. 外凸顶点：R = P + 将向量(Q−P) 旋转 −60°。旋转公式代入 cos(−60°)=0.5、sin(−60°)=−√3/2 得：R = (p.x + 0.5·dx + (√3/2)·dy, p.y − (√3/2)·dx + 0.5·dy)。
3. 方向判断依据：本实验初始三角形顶点为**逆时针**排列，沿边界逆时针行走时三角形内部在左手边，因此"右转 60°（即旋转 −60°）"的凸点必然在轮廓外侧；若三角形为顺时针，则应改用 +60°，不能只看截图朝向。
4. 递归与绘制：level=0 时只输出线段起点；采用 LINE_LOOP，顶点数 = 线段数 = 3×4ⁿ。

### 我的测试方法与结果
1. 用 Node 从实际文件提取算法函数，验证 Level 0~4 输出顶点数分别为 3、12、48、192、768，与 3×4ⁿ 完全一致。
2. 检查 Level 1 底边（左下→右下）外凸点：坐标为 (0, −0.903)，位于底边 y=−0.43 的**下方**，确认凸起朝外而非朝内。
3. 检查相邻顶点无重复、边界连续；检查所有层次包围盒均落在 NDC 的 [−1,1] 内，Level 4 不产生不合理裁切。

### 采纳情况及修正结论
采纳"逆时针 + 右转 60°"方案，验证数据证明方向正确（底边凸点在三角形外侧）、数量正确（3×4ⁿ）。修正后的结论：外凸方向不是固定值，而是由初始三角形的绕行方向决定；本次用"打印关键点坐标 + 对照包围盒"的验证方式有效确认了方向。

## AI协作2 · 绘图板调试（Task D）

### 具体错误现象（如一次成功，可先人为注入并恢复一个小错误）
Task D 第一次实现后各功能通过数值测试。为完整验证坐标映射，按实验要求人为注入一个小错误：**暂时取消 Y 轴翻转**（把 `yNDC=1-2*yCanvas/canvas.height` 改成 `yNDC=2*yCanvas/canvas.height-1`），预期点击位置会上下镜像。

### 我的初步排查
我猜想：如果点击画布上方、点却出现在下方，说明问题在 Y 轴转换；如果左右也偏移，则可能是 `getBoundingClientRect()` 或 CSS 缩放换算的问题，需要分别排查。

### 关键提示词（原文）
- "画布坐标转换的正确步骤是什么？为什么 clientX/clientY 不能直接当作 WebGL 坐标？"
- "为什么要翻转 Y 轴？有什么办法验证转换结果正确？"

### AI建议与逐项测试
AI 建议按"窗口坐标 → 画布像素 → NDC"三步转换，并逐项测试：
1. `xCanvas=(clientX-rect.left)*canvas.width/rect.width`：处理 CSS 缩放（画布 720px 被 CSS 缩成 360px 时仍换算准确）；
2. `yCanvas=(clientY-rect.top)*canvas.height/rect.height`：同上；
3. `xNDC=2*xCanvas/canvas.width-1`、`yNDC=1-2*yCanvas/canvas.height`：Y 翻转是因为屏幕坐标向下增大、而 WebGL NDC 向上增大。
逐项测试：用模拟窗口坐标验证 5 组点（中心、左上、右下、左中、下中），全部命中预期 NDC；人为注入 Y 翻转错误后，左上/右下结果上下互换（观察到镜像现象）；恢复正确实现后重新验证全部通过。

### 最终原因及修复证据
确认坐标偏移的根源是"未做 Y 轴翻转 + 未处理 CSS 尺寸与画布像素尺寸换算"。修复后的公式与实验指导书课堂参考公式一致，四角与中心点击测试全部通过。人为注入的错误已恢复，最终代码通过全部数值测试。

## AI协作3 · 主题整合（Task E）

### 主题及预期效果
主题词：**节律**。预期效果：同心环如呼吸节律，Koch 雪花边界如生长的律动，放射线随鼠标左右移动起伏成三瓣波浪——整体体现"有节奏的运动"。

### 两个方案的AI提示词（原文）
- "用基本 WebGL 图元表达「节律」主题，给我两种方案，比较图元数量、交互难度和可解释性"
- "其中至少一种交互规则要自己新增并影响几何、变换或程序状态"

### 方案比较、取舍理由

| 维度 | 方案A「节律」 | 方案B「生长」 |
|---|---|---|
| 几何构成 | 4 层同心环 + 三瓣波形放射线 + 端点节点 | Koch 边界 + 年轮环 + 放射枝条 + 节点 |
| 复用能力 | Koch(B) + 旋转动画(C) + 鼠标定位(D) | 同左 |
| 新增交互 | 鼠标横向位置控制振幅（mousemove） | 点击画布让图案生长一步（尺度递增） |
| 图元数量 | 4×LINE_LOOP + LINE_LOOP + 12×LINES + 12×POINTS | 类似，枝条更多 |
| 交互难度 | 低：mousemove + 数值夹取 | 低-中：需维护生长步数状态 |
| 可解释性 | 高：波浪形状随鼠标变化直观可见 | 高：生长过程直观 |

取舍理由：采纳方案 A。理由：(1) 三瓣波浪随鼠标左右移动的振幅变化非常直观，验收时容易演示"操作后能清晰观察变化"；(2) 与教师示例「绽放」（单环 + 等长放射线）在几何上差异明显，不是仅改颜色；(3) 新增交互规则清晰（鼠标横向位置 → 振幅 0~1），实现简单可靠。拒绝方案 B 的理由：需要维护更多累计状态，"点击生长"与 Task D 的点击定位在语义上重叠，交互区分度不如 A。

### 实际实现、测试与结果
实现：`rings=[0.30,0.55,0.82,1.10]` 四层同心环；放射线长度 `rad=0.45+0.60*amp*(0.5+0.5*sin(3a))`，amp=0 时等长、amp=1 时成三瓣（sin(3a) 周期 2π/3，索引 0/4/8 长度相同）；mousemove 用 `amp=clamp((clientX-rect.left)/rect.width, 0, 1)`。
测试：Node 数值验证三瓣对称性、振幅边界 [0.45,1.05]、所有几何包围盒在可见范围内；设计说明 126 字（≤200）。浏览器实测：鼠标从画布左移到右，放射线从"短放射"逐渐张开成三瓣波浪；点击画布图案中心移动；开始/暂停按钮控制旋转；复位恢复默认。

## 其他AI使用（若有）
工具：豆包（Doubao）。提示词及关键修改记录：
1. **Task A 参数化**："Level 输入为空或越界时应该怎么处理？三角形数量 3ⁿ 怎么验证？"——核对 Level 夹取逻辑（空值/越界回退默认 2）与三角形数 3ⁿ，验证 Level 0~5 三角形数为 1/3/9/27/81/243。
2. **Task C 变量名 Bug Hunt（真实发生）**：现象——反向、速度、角度三个控件失灵，暂停/开始正常。初步排查怀疑事件绑定问题；按 AI 建议打开浏览器 Console，分别操作三个控件后依次出现 `ReferenceError: ection is not defined`、`peed is not defined`、`heta is not defined`，确认是变量名缺字母（应为 direction/speed/theta），赋值给了未声明变量导致事件处理函数中断。修复三处变量名后功能恢复正常。
3. **Task E 调试**："怎么多了个圆圈"——排查确认是设计中第 4 层同心环（半径 1.10）而非代码残留，通过检索 `makeCircle` 出现次数确认无重复绘制，保留该设计并在设计说明中解释其含义。
4. **Challenge 对象级编辑**："对象级编辑的对象数据结构和命中判断怎么设计？"——在 Task D 基础上新增选择/改色/撤销：对象数据结构 `{type,vertices,color}`，命中判断 hitTest（矩形轴对齐内部、线段点距 ≤0.03、点距 ≤0.03，后画的优先）；用 Node 数值验证矩形/线段/点命中、重叠区优先、撤销与改色逻辑全部通过。