流梭刚更新了 v0.4.2 版本。这次我没有像往常一样发更新海报，而是想借这篇短文，聊一个真实的开发小插曲：当 AI 在代码里反复“鬼打墙”、死活做不出你要的效果时，我究竟是怎么处理的。
事情的起因是上个版本加的托盘功能。当用户关闭窗口时，流梭会缩小成托盘图标，右键可唤出菜单退出。为了追求质感，这里的 UI 我参考了微信的设计，做了一个自定义小窗。但版本上线后，我发现了一个刺眼的瑕疵：右键点击时，菜单总要神经质地连闪几下，才会安稳出现。虽然完全不影响功能，但对于在意体验的人来说犹如芒刺在背，于是我铁了心要在 v0.4.2 里干掉它。
起初，我按常规套路，让 AI 顺着现有方案去缝缝补补。结果直接演变成了“打地鼠”游戏：它刚治好了菜单弹出的延迟，窗口的显示层级又乱了；这头刚把闪烁减轻，那头菜单又可能被系统托盘挡得严严实实；等层级终于正常了，焦点切换时又开始闪；甚至还有一版，鼠标刚挪过去，菜单就凭空消失了。
来回折腾了十几轮，全在原地打转，一直达不到我想要的效果。眼看要陷入死胡同，我搬出了遇到这类问题时最管用的一个 Prompt：
“请从第一性原理出发，查找这个问题的根因。”
为什么这句有用？因为在连轴转的时候，AI 特别容易陷入“路径依赖”，顺着上一轮的错误方案继续叠甲，改个参数或者强行补一层逻辑。这句指令的作用，就是强行把它从无脑试错的泥潭里拽出来，重新审视前几轮失败的原因。让它回归最基本的事实：屏幕上到底发生了什么？哪些是系统控制的，哪些是我们代码的问题？哪怕暂时找不到解药，至少心里清楚下一步该去验证什么。
这招确实管用。AI 终于跳出了菜单颜色、圆角、动画这些表层细节，揪出了真凶：问题就出在我们那个为了还原微信外观的“自定义小窗口”上。右键唤出时，Windows 系统自己的托盘界面还没完全稳定，我们的小窗口就急吼吼地去抢位置、算层级、夺焦点。两边一“打架”，肉眼看自然就是闪烁。
查明真相后，AI 像个无奈的工程师，给我抛出了一个“二选一”的方案：
- 方案 A（求稳）：换用 Electron 原生菜单。系统级支持，绝对稳，绝对不闪。
- 方案 B（求美）：想继续保留微信那种外观，就得忍受目前的闪烁。
我反问它：“那微信为什么不用做这种二选一？”
AI 猜测，微信可能用了更贴近系统原生能力的自绘菜单。如果我们照搬，开发成本和长期的兼容维护成本都会直线上升。妥协之下，我决定先看看那个“绝对稳”的原生菜单到底长什么样。
结果确实完全不闪了，但我没法接受。系统固定的菜单极宽，哪怕里面只有一个孤零零的“退出”选项，也硬生生撑出一大块面积。就像个比例失调的“胖头娃娃”，跟流梭原本克制、精致的界面放在一起，违和感直接拉满。
当时 AI 甚至还试图劝我：如果把文案从“退出流梭”改成“退出”，还能省下几十个像素，继续在外观上死磕的收益已经不大了。 从纯技术逻辑来看，它的判断很有道理；但从产品体验的角度，我坚决不买账。
用户永远不会知道我们背后取舍了什么渲染技术，他们只会相信眼睛看到的——这个弹出的菜单，到底是不是流梭的一部分。只要圆角差了一点、边框粗了几像素，哪怕再微小，往那儿一摆，都会像是一块生硬的“补丁”，瞬间打破了流梭原本干干净净的界面默契。原生菜单是不闪了，可如果它看起来根本不像流梭，这怎么能叫解决了问题？
我没有因此吐槽 AI 能力不行，毕竟它已经精准定位了根因，还用原生菜单验证了系统稳定性。我要做的，是告诉它这个结果为什么过不了产品验收，然后拉着它顺着已知的根因继续往下挖。
既然闪烁源于菜单显示时的一连串变化，我们能不能玩个“障眼法”？让这些杂乱的变化先在用户看不见的地方提前演练完，等一切就绪了，再拉开幕布？
顺着这个思路，我们重新启用了自定义菜单，但彻底换了一种加载逻辑：菜单在软件启动时就悄悄就位，保持全透明状态。右键触发时，它在隐身状态下从容地调整位置、层级和焦点。等 Windows 托盘界面彻底稳定后，再一次性显示出来。至于点击外部关闭、按 Esc 退出等正常交互，也一并完美保留。
实机测试时，菜单终于如丝般顺滑，不再有任何闪动，也保住了那份属于流梭的精致外观。
这次经历让我挺有感触。面对 AI 的碰壁，我没有机械地重复“再改一次”，也没有因为它抛出技术取舍就抱怨它不够聪明。AI 是个极好的探路者，负责深挖根因、验证技术路径；而我负责守住产品最终呈现的体验底线。 它给出的“二选一”，只是当时那种实现方式下的局部最优解，绝不是产品经理必须低头接受的终局。
现在，流梭 v0.4.2 里那个平滑弹出的托盘菜单已经静静躺在那里了。下一次，如果 AI 再笃定地告诉我“这个需求只能这么做”，我依然会先问一句“为什么”，然后拉着它，继续往深处走。