代码只改了 1 次,测试 1 次过:我跟 AI 聊了什么
- 2026-02-07 07:19:50
代码只改了一次，测试一次性通过。
这在我用 AI 写代码的经历里，算是少见的。
大多数时候，跟 AI 协作写代码是这样的：它写一版，跑不通；改一版，又出新 bug；再改，好像对了，但换个场景又挂了。来来回回，像在打补丁。
但这一次不一样。从提出需求到代码落地，中间只经历了一轮对话，然后就跑通了。
我想分享一下，这次「一把过」是怎么发生的。
问题是什么
我最近在基于 #AI产品自由 的开源仓库去做一个自己的 Obsidian 插件。它的功能是把 Markdown 渲染成微信公众号兼容的格式，方便在 Obsidian 里直接复制到公众号后台。
我的朋友 #思潭有话说 帮我内测时发现了一个问题：侧边栏的预览不会实时更新。
具体来说，当你在左边编辑文档时，右边的预览区不会跟着变。只有切换到另一个文档再切回来，预览才会刷新。
这显然不对。
我是怎么跟 AI 聊的
拿到这个问题后，我没有直接让 AI 写代码。
我先问了一个方向性的问题：应该做实时渲染，还是加一个手动刷新按钮？
Gemini 建议做实时渲染，理由是用户体验更好，不用每次都点按钮。
听起来有道理。但我没有马上说「好，开始写吧」。
我追问了一个担忧：实时渲染会不会有性能问题？每次敲键盘都触发渲染，内存会不会爆？
Gemini 给了三重保障：
防抖（Debounce）：不是每次按键都渲染，而是等你停止输入 500 毫秒后才触发。
可见性检查：只有当预览面板可见时才渲染，最小化时不浪费资源。
库本身很快：用的 markdown-it 库是轻量级的，处理文本不吃内存。
「防抖」是前端开发里的常见技巧，简单说就是「等你停下来再动手」，避免频繁触发。
到这里，方案听起来已经挺完整了。
但我做了一个关键动作：让它换个角色再审一遍。
让 AI 当专家自查
我说：「如果你是 Obsidian 插件开发的领域专家，再来自查一下这个方案，看看还有什么遗漏。」
这一问，还真问出东西来了。
Gemini 说：「有一个关键问题——滚动跳动。如果我们直接更新预览内容，页面会跳回顶部。用户正在看第三屏，一更新，又回到开头了。这很烦人。」
然后它补充了解决方案：更新前保存滚动位置，更新后恢复。
这个问题我自己没想到。但让它「换个帽子」再审一遍，它就发现了。
场景穷举
然后我又追问了一个细节。
Gemini 提到「当插件关闭时，停止渲染以节省资源」。我问：「关闭」具体指什么？
是我点了 X 把这个 Tab 关掉了？
还是我收起了整个侧边栏？
还是侧边栏开着，但我切换到了别的 Tab（比如大纲或日历）？
这三种情况，技术上是不一样的。
Gemini 承认，之前的方案只覆盖了第一种。于是它升级了检测方式，用一个叫 offsetParent 的属性来判断元素是否真的「可见」。这一招能覆盖所有三种情况。
我又追问：覆盖这么多场景，代码会不会变得很复杂？
Gemini 说：「不会。就一行代码。」
1 if (!this.containerEl.offsetParent) return;
一行代码，三种场景全覆盖。简洁。
边缘场景补漏
到这里，方案已经很完善了。但我又想到一个问题：
如果我关掉了侧边栏，期间修改了文档，再打开侧边栏，预览会自动刷新吗？
按照现有逻辑，不会。因为「关闭」期间没有监听变化，打开后也不会主动刷新——除非你再敲一个字。
Gemini 说：「好问题。我加一个 onResize 处理器。当侧边栏展开、Tab 切换回来、或者窗口大小变化时，自动触发一次刷新。」
这个场景，是我自己想到的，不是 AI 主动发现的。
四个关键动作
总结
回顾整个过程，我觉得「一把过」不是运气，而是前期投入换来的。
总结下来，有四个关键动作：
1. 先问方向，不急动手
拿到问题后，先讨论「做什么」，再讨论「怎么做」。实时渲染还是手动刷新？这个方向性的问题，值得先聊清楚。
2. 主动暴露担忧
不要等 AI 写完代码再发现问题。性能、内存、边界情况：你心里的担忧，提前说出来，让 AI 在方案里就考虑进去。
3. 让 AI 当专家自查
这是我觉得最有用的一招。让它换个角色，以「领域专家」的身份再审一遍方案。它会发现一些自己之前没想到的盲点。
4. 场景穷举
AI 容易给出「理想情况」下的方案。但现实是复杂的。「关闭」到底指什么？「打开」之后会怎样？这些边缘场景，需要你主动去问。
慢就是快
这次经历让我更加确信一件事：跟 AI 协作，前期聊得越透，后期改得越少。
很多人觉得 AI 写代码就是「一句话需求，秒出代码」。但现实是，需求描述得越模糊，AI 猜得越多，出错的概率就越大。
与其让 AI 猜，不如自己先想清楚。
花时间界定问题、罗列场景、审视架构。这些看起来「慢」的动作，反而是通往「一把过」的捷径。
之前我写过一篇 别让 AI 变成你的脑子，讲的是 AI 给的方案不一定对，人要保持判断力。这次的经历是那篇文章的延续：不只是要保持判断力，还要主动引导 AI 把方案想全。
AI 是工具，但工具的上限，取决于使用它的人。
///
如果你也在 vibe coding，欢迎交流呀：linauwawa
附录：完整对话记录
以下是我和 Gemini 的原始对话，供参考。
【我】 现在有一个问题：当我在侧边栏打开了这个插件的时候，然后我选择了 Markdown 的文档，它会渲染当前的这个文档到预览的区域。但是当我在当前的文档去做了一些修改的时候，它的这个修改没有实时的同步到预览区域。这种情况应该怎么解决？是我们应该做实时的同步渲染呢，还是加一个刷新或者渲染的按钮，让用户手动的去渲染呢？
【Gemini】 我推荐做实时同步（带防抖延迟）。这能提供更流畅的「所见即所得」体验，用户不需要每次都点刷新按钮。我已经更新了实现方案来反映这个方法。请审阅。
【我】 但是我有一个问题：当我在右边的侧边栏开了这个插件的时候，如果我们做了实时的渲染跟预览的话，当我每次切换了一个新的文档的时候，它就会去做一次预览跟渲染，这会不会导致性能问题，或者是会让 Obsidian 的内存占用会明显升高？
【Gemini】 你提出的性能担忧非常合理。以下是我们防止卡顿和内存问题的方法：
防抖（Debounce）：我们不会在你打字的时候渲染，而是等你停止输入 500 毫秒后才触发更新。这避免了「每次按键都渲染」的卡顿。
可见性检查：我们会添加检查，只在预览面板可见时才渲染。如果你最小化它或切换到其他 Tab，它会停止监听和渲染以节省资源。
优化：底层的转换库（markdown-it）非常快，而且我们只处理文本，内存占用很小。
【我】 但是我有一个问题：当我在右边的侧边栏开了这个插件的时候，如果我们做了实时的渲染跟预览的话，当我每次切换了一个新的文档的时候，它就会去做一次预览跟渲染，这会不会导致性能问题，或者是会让 Obsidian 的内存占用会明显升高？
【Gemini】 你提出的性能担忧非常合理。以下是我们防止卡顿和内存问题的方法：
防抖（Debounce）：我们不会在你打字的时候渲染，而是等你停止输入 500 毫秒（或者 1 秒，如果你喜欢的话）后才触发更新。这避免了「每次按键都渲染」的卡顿。
可见性检查：我们会添加检查，只在微信转换器侧边栏面板可见时才渲染。如果你最小化它或切换到其他 Tab，它会停止监听和渲染以节省资源。
优化：底层的转换库（
markdown-it）非常快，而且我们只处理文本，内存占用对于文本文件来说是很小的。
【我】 我想，如果你做 Obsidian 这个插件的领域专家，再来自查一下这个实现方案，看看还有什么补充？
【Gemini】 作为专家审查，我发现了一个关键问题：滚动跳动。如果我们直接更新预览内容，页面会每次都跳回顶部。这很烦人。
我已经更新了方案，加入：
滚动位置保存：更新前保存滚动位置，更新后立即恢复。
严格的可见性检查：使用
getLeavesOfType检查，确保插件关闭时零资源占用。
【我】 我想理解一下，第二点说的「the plugin is closed」是指我在侧边栏将这个 plugin 实际的关闭掉了，还是说我关掉了右边的侧边栏，还是说我开着右边的侧边栏，但是我从这个插件的预览区域的 Tab 切换到了其他的 Tab？
【Gemini】 这是个很好的问题。「插件关闭」确实可能指多种情况。
之前的检查（length > 0）只能处理你显式关闭 Tab（点 X）的情况。
我已经升级方案，使用 offsetParent 做真正的可见性检查。这会在所有这些情况下停止渲染：
Tab 关闭：你关闭了插件 Tab
侧边栏收起：插件开着，但你收起了整个侧边栏
Tab 切换：侧边栏开着，但你切换到了其他 Tab（如大纲或日历）
通过检查 offsetParent === null，我们确保插件在你不看它的时候零资源消耗。
【我】 我想再确认一个问题，从架构的角度，我们现在「关闭」涵盖了这么多场景之后，会不会让我们的代码逻辑实现做的很复杂？
【Gemini】 好问题。放心，不会复杂。
实际上它简化为一行代码：
1 if (!this.containerEl.offsetParent) return;
就这样。我们不需要为 Tab、侧边栏、窗口写复杂的监听器。我们只是在需要的时候问浏览器「这个元素在屏幕上有父元素吗？」
我已经更新了方案来展示这行具体的代码。如果你对这个简洁且稳健的方案满意，请批准，我就开始写代码。
【我】 我有另外一个问题：当我关掉了侧边栏或者切换了 Tab（相当于我关掉了插件），那么当我再次打开插件或者切换到这个插件的 view 的时候，会实时的去渲染我当前文档的最新内容吗？
【Gemini】 这是个很好的潜在问题！
你说得对：如果没有专门的代码，它会显示过时的内容，直到你敲点什么。
我刚刚添加了一个 onResize 处理器。现在，每当你：
展开侧边栏
切换回插件 Tab
调整窗口大小
它都会自动触发一次刷新（带 300 毫秒的小延迟以保持流畅）。
请再重新加载一次插件来应用这个修复。
【我】 好，我没有问题了。执行吧
