大家好，我是 Voyager。
大约一个月前，我还不清楚 Manifest V3 是什么，也没写过 Service Worker，甚至连 content script 和 background script 的区别都分不清。
但就在过去的一周里，我借助 AI，从零写出了人生中第一个浏览器扩展：「DeepSeek 助手」。目前已开源，Edge 商店审核中。
这篇文章不是产品软广，而是想复盘一下：一个基本零编程基础的人，是怎么和 AI 协作完成一个完整产品的。我会把踩过的坑、走过的弯路、以及一些对“非程序员 + AI 编程”的真实思考都说清楚。
一、需求：从自己的痛点出发
我是 DeepSeek 网页版的重度用户，日常用它写作、查资料、分析问题。很快聊天记录就堆了上百条。
两个核心痛点：
- 历史对话找不着：左侧栏只能手动翻，没有搜索入口。
- 有价值的内容没法收藏：AI 给出好的代码片段或分析，只能手动复制到记事本，脱离上下文后很难回溯。
我开始想：为什么官方不做这些功能？等了几周没动静，我决定自己动手。
这里有一个关键判断：这个需求的前端可行性是高的。搜索对话列表、收藏消息、换肤——本质都是对现有 DOM 的操作和本地数据的存取，不需要后端服务。这一点在动手前就想清楚了，否则踩坑会更深。
二、技术选型：为什么选 Manifest V3 + 本地存储
决定做之后，我需要确定技术方案。
为什么是浏览器扩展？
- 比起写一个独立客户端，注入脚本到已有页面是成本最低的方案，不需要处理登录态、网络请求拦截这些复杂逻辑。
- DeepSeek 的核心能力都在网页端，我只需要“附着”在上面做增强。
为什么选 Manifest V3？
- V2 即将被废弃，V3 是唯一选择。
- V3 的 Service Worker 不再常驻，对资源管理更友好，但也带来了新的问题（后面会讲）。
为什么用 chrome.storage.local 而不是 IndexedDB？
- 我只需要存少量结构化数据（对话列表、收藏记录），不需要复杂查询。
chrome.storage.local的 API 足够简单，读写的异步处理也容易理解。对我这种小白来说，API 的简洁性比性能更重要。
架构大概是这样：
popup面板：主界面，处理用户交互。content script：注入到 DeepSeek 页面，操作 DOM、监听用户操作。Service Worker：处理快捷键、右键菜单等后台事件。chrome.storage.local：存收藏数据、主题配置。
三、开发流程：我是怎么和 AI 协作的
工具链
- AI 引擎：DeepSeek API
- 自动化工具：OpenClaw 配置好后，让 AI 直接操作文件系统和命令行
- 测试环境：Edge 开发者模式加载解压缩的扩展
协作流程
- 说需求：我描述想要的功能，比如“我想点击对话标题旁边的一个按钮，把这条对话收藏起来”。
- AI 出代码：AI 生成完整的代码文件，包括 manifest 配置、content script 逻辑、popup UI 等。
- 我测试：加载插件，在真实页面上操作，看效果。
- 遇到 Bug → 描述症状 → AI 分析修复：这是循环次数最多的环节。
这个流程看起来很顺畅，但真正踩坑的是第 4 步。
四、踩坑实录：这些才是一周里真正花时间的地方
坑 1：向 AI 描述 Bug 本身就是一种能力
这是我最深的一个感受。
我不会读代码，所以当一个功能不正常时，我只能像用户一样描述“现象”：“我点了这个收藏按钮，但它收藏的是左边栏另一个对话。”
这种描述对 AI 来说太模糊了。就像病人跟医生说“我不舒服”——可能性太多。AI 经常给我一个看似合理、实则无效的修复。而我因为没有读代码的能力，甚至看不出这个修复为什么无效，只能一遍遍试。
后来我摸索出来的经验：
- 不只描述现象，还要说清楚复现步骤。
- 把相关代码文件直接喂给 AI，让它自己对比分析，不要自己瞎猜根因。
- 如果来回 3 次还没解决，就换个角度重新描述问题。
坑 2：收藏功能的“张冠李戴”问题
这是整个开发中最折磨我的 Bug。
我想实现的效果是：点击某条对话的悬浮按钮 → 收藏这条对话。但早期版本里，不管你点哪个按钮，它收藏的一直是左侧栏里高亮的那条。
原因后来才搞清楚：我的收藏逻辑是通过读取侧边栏的 DOM 来获取对话 ID 的。但 DeepSeek 网页的侧边栏实现里，高亮状态和用户点击目标并不总是同步的。AI 写的第一版代码直接拿了“当前高亮项”的 ID，而不是“用户点击目标”的 ID。
这个问题来来回回改了七八次，就是因为我没有能力一眼看出根因。最后是 AI 提出了一个新思路：不要依赖侧边栏的高亮状态，而是从点击事件的目标元素往上找，找到离它最近的对话条目，再提取 ID。改了之后终于稳定了。
坑 3：状态管理的混乱
随着功能增多，收藏数据、主题配置、面板位置等都需要跨组件共享。早期我是直接把数据传来传去，代码很快就变成了意大利面条。
后来在 AI 的建议下，把收藏状态收拢到 chrome.storage.local 作为单一数据源，各组件只做读写，不互相传递。改完之后，新增功能时的改动量明显下降。
这个教训是：即使你完全不懂设计模式，当代码开始让你“感觉很难改”的时候，很可能就是状态管理出问题了。
坑 4：Service Worker 的“消失”
Manifest V3 的 Service Worker 不会一直运行，一段时间不活动就会被浏览器回收。有个 Bug 很奇怪：快捷键有时候能用，有时候不能用。
原因就是 Service Worker 被回收后，之前缓存的某些变量丢失了，但代码逻辑里依赖了这些缓存值。解决方案是：把需要持久化的状态都存进 chrome.storage，Service Worker 每次激活时重新读取。
这个坑暴露了 V3 迁移时的一个认知盲区：你以为全局变量是可靠的，但 Service Worker 的重启会让它们归零。
坑 5：虚拟滚动的限制（非代码层面）
这是唯一一个靠代码无法解决的问题。
DeepSeek 网页用了虚拟滚动，只有视口附近的消息才渲染在 DOM 里。我的“当前对话搜索”功能因此只能搜到 5-8 条消息，远处的搜不到。
我花了不少时间尝试绕过，最后确认这不是插件的 Bug，是网页架构层面的限制，只能接受。在现有条件下，想解决这个问题需要扩展通过 API 去获取数据，而不是依赖 DOM 抓取——这已经超出我当前的能力范围和项目定位了。
五、反思：非程序员 + AI 编程，我的几个真实感受
1. “产品思维”是小白最大的优势
我不会写代码，所以我完全从用户视角出发。我想的永远是“用户会怎么用这个功能”，而不是“这个技术方案优不优雅”。这种视角反而让产品更接地气。技术选型上，我也倾向用最简单的方案，避免过度设计——这恰好贴合了“先跑通再优化”的原则。
2. 调试能力比写代码能力更重要
AI 帮你解决了“写”的问题，但“改”的问题没人能替你。作为一个小白，我大概 70% 的时间都花在测试和让 AI 修改上。这个阶段需要的不是编程知识，而是耐心、细致、以及把 Bug 说清楚的能力。某种程度上，这是一个“翻译”工作——把你看到的现象翻译成 AI 能理解的指令。
3. 预期管理很重要
AI 写的代码，一次性跑通的概率不高。如果你预期 3 次修改就能搞定一个功能，一定会崩溃。我把默认预期调到“可能要改十几二十次”，心态反而稳了很多。
4. 做出来，比做完美更重要
这个插件还有很多不完善的地方，但重要的是它已经是一个可用的东西了。对于独立开发者来说，最好的状态不是一次做出完美的产品，而是快速发布一个能用的版本，然后持续迭代。我最初设了 v1.0.0 的 Milestone，就只收束了最核心的功能，其他都放到后续版本——这个策略是对的。
六、功能介绍（简版）
最后用技术视角简单列一下功能：
- 历史搜索：检索侧边栏对话列表，支持时间排序
- 当前对话搜索：DOM 文本匹配 + 滚动定位 + 高亮，自动过滤思考内容
- 对话收藏：右击/快捷键/按钮触发，数据存
chrome.storage.local，支持导出 JSON/TXT - 消息收藏：逐条收藏，卡片展示，带跳转定位
- 主题换肤：6 套预设 + 取色器，CSS 变量实现
- 面板拖拽：mousedown/mousemove/mouseup 实现
- 快捷键：Alt+K 呼出面板，Ctrl+Shift+X 收藏对话
所有数据纯本地存储，隐私零风险。
七、获取方式
- GitHub：项目地址，Star ⭐ 支持一下
- 国内网盘：123 云盘 1859466484.share.123865.com/123pan/5kQt…
- CSDN社区： download.csdn.net/download/Ap…
- Edge 商店：审核中，通过后更新链接
项目完全开源，MIT 协议。
最后
如果你也是一个不会写代码但心里藏着“自己做个小工具”念头的人，希望我的这段经历能给你一点参考。AI 时代，从想法到产品的那条路，已经比以前短了很多。最大的障碍从来不是技术，而是你敢不敢迈出第一步。
欢迎在评论区交流“非程序员 + AI 编程”的任何问题，一起探索这条新路。
以下是该产品的主要功能截图
一键检索全部对话，支持时间排序与关键词筛选
搜索页面已加载消息，结果自动滚动定位并红框高亮
对话与消息双重收藏，支持备注、排序与 JSON/TXT 导出备份
