原文内容

用 AI 辅助开发浏览器插件：压缩长上下文 AI 聊天页面

我平时重度使用 AI 聊天助手写代码、读论文、整理思路。用得多了就发现一个很烦的问题：当聊天历史越来越长，页面会变得越来越卡，尤其是一次性贴入大段代码或长文档的时候，浏览器标签页经常卡到没法操作。

第一步：确定做什么

我最初的想法是"能不能把历史消息压缩一下"。但具体用什么方案？我给了 AI 几个方向：按消息数量触发压缩、按 DOM 节点数触发、或者手动压缩。AI 帮我分析了每个方案的优缺点——按数量最简单直观，按 DOM 更精确但实现复杂，手动压缩则增加用户负担。最后我选了按消息数量触发的方案，因为对我来说够用就行，不需要过度设计。

第二步：拆解功能点

有了方向后，我让 AI 帮我列出实现这个插件需要哪些模块。AI 给出了很清晰的划分：内容脚本（负责监听 DOM 变化和做压缩）、弹出面板（配置页面）、后台脚本（存储设置）。AI 还提醒了我几个容易被忽略的点——压缩后要保留滚动位置、展开旧消息时要保持页面不跳转、配置项要持久化存储。这些如果不是 AI 提醒，我可能做到一半才发现，回头改代码就更麻烦。

第三步：写代码过程中的决策

写代码过程中我遇到不少需要做选择的地方：

• 用什么技术：我让 AI 对比了 Manifest V2 和 V3 的区别。V3 更安全、是 Google 推的方向，所以选了 V3，虽然当时我还不熟它的 API。
• 压缩策略怎么定：AI 给了我几个选项——直接隐藏 DOM 节点、把内容替换成摘要文本、用 Shadow DOM 隔离。我选了最简单的「替换成摘要文本」，因为其他方案引入的复杂度对我来说不值得。
• 摘要怎么生成：我让 AI 对比了截取前 N 个字符、提取关键词、调用 AI 接口生成摘要这三种方式。我选了截取前 N 个字符，因为不需要额外 API 调用，本地就能完成，够快。
• UI 风格：我给了 AI 几个参考截图，它生成了对应的 CSS，我挑了最顺眼的一个微调了一下。

第四步：调试和修 Bug

插件写完后跑起来，第一版就有问题——压缩后页面高度突变，滚动位置跑飞了。我跟 AI 描述了现象，它很快定位到问题根源：我是在 scroll 事件里做压缩的，触发了滚动位置的连锁变化。AI 建议改用 MutationObserver 监听消息增删，压缩时先记下滚动位置、压缩完再恢复。这个方案一次就调好了。

还有一个问题：展开压缩消息时，原本的代码高亮丢失了。AI 帮我分析了原因是展开时重新插入的 HTML 没有经过页面原有的高亮处理流程。解决方式是在展开后手动触发一次代码高亮渲染。

AI 编程的好处总结

整个插件从想法到能用的版本大概花了两天时间。如果纯靠自己查文档、写代码、调试，估计至少要一周。AI 在这个过程中帮我省掉的大头不是"写代码"，而是：

1. 快速给出选项：遇到决策点时，AI 能立刻列出几种可行方案和各自的权衡，不用自己到处查资料凑齐信息再做判断。
2. 覆盖盲区：很多细节（Manifest V3 的限制、滚动位置的坑、DOM 压缩的边界情况）AI 提前提醒了，避免了我做到一半才发现翻车。
3. 写框架代码：插件的脚手架、消息通信、存储读写这些模板化代码 AI 一次性生成，我只需要确认逻辑没问题就行。
4. 精准定位 Bug：描述现象给 AI，它通常能直接指出根因和修复方向，比自己一行行排查快很多。
5. 迭代效率高：改需求时不用从头写，告诉 AI"这里改成 X，那里改成 Y"，它直接产出修改后的代码，我验收即可。

对我来说，AI 辅助编程最大的价值不是替代我写代码，而是让我把精力集中在做选择和判断上——选择做什么方案、判断什么策略最合适——而不是耗在写模板代码和排查低级 Bug 上。