案例一：全局滤镜毁掉相册

博客跑起来的第二天，文章页面的代码块在暗色模式下看不清，我让 AI 修。它在 global.css 里加了几行样式，问题解决了。

三天后，相册页面的图片在暗色模式下颜色变得很怪。把现象丢给 AI 让它分析，最后定位到就是三天前那几行 CSS：AI 用了一个全局选择器去改所有图片的滤镜，波及了相册页。（见 02 篇。）

案例二：播放器盖住”旅行足迹”

让 AI 加音乐播放器放页面底部，它加了 audio 标签放首页底部，把”旅行足迹”卡片区域完全覆盖。几天后我自己浏览才发现。回去问，它承认”修改了页脚布局，可能影响了原有的内容”，但没主动说。（见 03 篇。）

案例三：修暗色行号，顺手改了代码高亮

修暗色模式的行号颜色，不划定范围的话 AI 顺手改了 code-theme.css、CodeBlock.astro，不相关的文件被一起动。这类”顺手改”不看 git diff 根本发现不了。

案例四：ViewTransitions 下 JS 全挂

给博客启用 Astro 的 ViewTransitions 后，页面切换时搜索框、主题按钮、代码高亮、随机文章按钮全部失效。

根因是模块顶层缓存了 DOM 引用：

const searchInput = document.querySelector('#search-input'); // 顶层缓存

页面切换后 ViewTransitions 复用 DOM、不销毁旧 JS 变量，缓存引用指向旧元素，事件全挂。AI 用 astro:after-swap 重初始化也没解决引用缓存，sessionStorage 还有脏缓存。最后改成实时 getElementById，并给搜索索引加版本号（SEARCH_CACHE_KEY 从 v1 升到 v2）强制刷新才解决。

根因：局部最优，没有兜底

AI 是目标导向的：它完成”改这个”的任务，不做全局影响分析。前端没有编译器兜底、没有单测回归，改 A 坏 B 只在运行时暴露。

对比后端，就像改了一个共用 Service 的方法签名，却没检查所有调用方。在 Java 里 IDE 会立刻标红编译错误，前端 AI 编程里没有任何静态检查会提醒你。

再深一层：AI 为省事倾向”替换”而非”插入”，加上提示词无法覆盖所有约束（你根本不知道”加播放器”会碰 哪个模块），这个死循环会反复出现。

修复与习惯

  1. 让 AI 改代码前先圈定影响范围：改哪个文件、动哪些选择器。
  2. 改完用 git diff 逐行看它动了什么，多余改动当场追问。
  3. 把规则写进 CODEBUDDY.md：“所有修改必须先分析影响范围，不能悄悄改动不相关的模块”。
  4. ViewTransitions 这类框架魔法特性，用之前先懂原理和副作用，类比 @Transactional 和 Hibernate 懒加载：好处很大，但不知道边界就是埋雷。

教训

  1. AI 的修复默认是局部最优，全局副作用要自己查。
  2. 前端没有编译期检查，验证只能靠肉眼 + 多页面回归 + git diff。
  3. 用框架”魔法”特性前先查它的副作用，别等切换页面后 JS 全挂才回头。