从 Paste 到 ClipVault：我与 AI 协作的 18 个小时

目录

周刘早上，我坐在电脑前，盯着屏幕上的报错信息发呆。

那是我在改造一个开源剪切板工具的第十几个小时。从最初的”试试看”，到后来跟各种诡异的 bug 死磕，再到最终把 PicGo 图床功能也集成进去——这段经历让我对 AI 编程助手有了更清醒的认识。

缘起：一个好用的剪切板工具

事情要从我换电脑说起。

之前用 MacBook 时，我一直在用 Paste 这个软件。界面好看，操作顺手，历史记录管理得井井有条。但它是订阅制——每年 29.99 美元，买断要 89.99 美元。

后来换了 Windows 笔记本，自带的剪切板功能虽然能用，但总觉得差点意思。去 GitHub 上搜了一圈替代品，没看到特别顺眼的。这时我发现了 EcoPaste——基于 Rust 开发，界面现代，功能齐全，但是样式不是我喜欢的那种。

本来，故事到这里就该结束了。毕竟 EcoPaste 是开源的，直接下载用就行。

但问题是我有一些自己的需求：想要集成 PicGo 图床功能，日常写文章时直接粘贴图片上传。而且这个 Rust 代码库，我想按自己的习惯改一改界面和交互。

换作以前，我可能就放弃了。Rust 语法我基本不会，为了一个剪切板工具去重新学一门语言，时间成本太高了。

但这次我想试试：如果让 AI 辅助，我能不能在不深入学习 Rust 的情况下，把这个项目改造成自己想要的样子？

项目架构

先了解一下改造前的项目结构。这是一个典型的 Tauri 应用，采用前后端分离的架构：

┌─────────────────────────────────────────────────────────────────┐
│                        ClipVault 架构                            │
├─────────────────────────────────────────────────────────────────┤
│                                                                  │
│  ┌──────────────────┐        ┌──────────────────────────────┐   │
│  │   前端 (React)    │◄──────►│      后端 (Rust/Tauri)        │   │
│  ├──────────────────┤  IPC   ├──────────────────────────────┤   │
│  │ • App.tsx        │        │ • lib.rs (主入口)            │   │
│  │ • Main 页面      │        │ • 窗口管理插件               │   │
│  │ • Preference 设置│        │ • 剪切板监听插件             │   │
│  │ • 数据库存储     │        │ • 图床上传插件               │   │
│  │ • 状态管理       │        │ • 数据同步插件               │   │
│  └──────────────────┘        │ • 自启动管理插件             │   │
│           │                  └──────────────────────────────┘   │
│           │                            │                        │
│           ▼                            ▼                        │
│  ┌──────────────────┐        ┌──────────────────────────────┐   │
│  │   SQLite 数据库   │        │   系统剪切板 API              │   │
│  │ • history 表     │        │ • Windows: Win32 API         │   │
│  │ • tag 标签表     │        │ • macOS: NSPasteboard        │   │
│  │ • historyTag 关联│        │ • Linux: xclip/xdotool       │   │
│  └──────────────────┘        └──────────────────────────────┘   │
│                                                                  │
│  ┌───────────────────────────────────────────────────────────┐  │
│  │                     图床提供商支持                          │  │
│  │  阿里云 OSS │ 七牛云 │ 腾讯云 │ 又拍云 │ AWS S3 │ GitHub  │  │
│  └───────────────────────────────────────────────────────────┘  │
│                                                                  │
└─────────────────────────────────────────────────────────────────┘

数据流向大概是：系统剪切板变更 → Rust 后端监听 → 存储到 SQLite → React 前端读取展示 → 用户操作 → 触发相应功能（如上传到图床）。

第一天：从”好像可以”到”全是坑”

周六早上五点多我就醒了，脑子里全是昨晚看的代码结构。干脆起床开干。

我先梳理了一下思路：

1. 保留 EcoPaste 的核心剪切板监听和存储逻辑
2. 调整界面布局，让它更符合我的使用习惯
3. 集成 PicGo 的图床上传功能

前半段还算顺利。借助 AI，我很快搞懂了项目结构，改了几个界面组件，把基本架子搭起来了。到中午的时候，一个能跑的基础版本已经成型。

但真正的折磨从下午开始。

我遇到了第一个诡异的问题：复制图片后，预览列表里一片空白。明明日志显示已经捕获到图片数据，但界面上死活不显示。

把问题抛给 AI，它给出了几种可能的原因和修复方案。我试了一遍——不行。

又试了第二遍、第三遍。每次 AI 都信心满满地说”这次应该解决了”，但跑起来还是老样子。

切换分类时界面卡死、图片预览尺寸异常、上传失败时没有提示……问题一个接一个冒出来。下午三点，我盯着屏幕，感觉像在打地鼠——修好一个，又冒出两个。

那天我一直干到晚上十一点。中途吃了两顿饭，其他时间基本都在跟 bug 死磕。最终，主要的问题都解决了，但我已经精疲力尽。

第二天：集成 PicGo，打通最后一公里

周日早上，我缓过劲来，开始琢磨集成 PicGo 图床。

这个功能对我很重要。平时写博客，截图后要手动打开 PicGo 上传，再复制链接回来插入。如果能直接在剪切板工具里完成，效率会高很多。

但这里有个坑：EcoPaste 原本的架构没有考虑外部 API 调用，我需要找到合适的切入点。而且 PicGo 的 API 规范、错误处理、回调通知，这些都要重新设计。

又是反复调试的一天。上传到阿里云 OSS 后怎么刷新界面、上传失败怎么提示用户、大图片怎么处理压缩……细节多得要命。

到晚上，我终于把整条链路跑通了。复制图片 → 自动/手动上传 → 获取 URL → 一键复制 Markdown 格式。Windows 上测试基本没问题。

项目开源在 ClipVault，目前支持 Windows、Linux、macOS 的 x86 和 ARM 架构。不过说实话，我只在 Windows 上深度测试过，其他平台不敢保证没问题。

冷静下来后的反思

做完这个项目，我最大的感受是：不必神话 AI。

现在各种营销号把 OpenAI、Claude 吹得神乎其神，好像有了 AI，不会编程的人也能做出复杂的软件。但我的真实体验是——AI 确实能帮上忙，但它的局限性非常明显。

AI 擅长什么

• 快速入门：我不懂 Rust，但通过 AI 的解释，我很快就理解了项目结构和关键代码的位置
• 生成样板代码：一些重复性的模板代码，AI 生成得又快又准
• 提供思路：遇到问题时，AI 能给出多种可能的解决方案，帮我打开思路

AI 不擅长什么

• 解决复杂 bug：那个图片不显示的问题，AI 来回给了四五个方案都没解决。最后是我自己通过打日志、断点调试，定位到一个异步数据同步的时序问题
• 上下文理解：当问题涉及多个模块的交互时，AI 往往会”顾头不顾尾”，修好了 A 却破坏了 B
• 验证假设：AI 会给出看似合理的解释，但不一定是正确的解释

最典型的是那个界面切换卡死的问题。AI 一开始说是状态管理的问题，让我改这改那，折腾了两个小时。后来我发现，其实是一个事件监听器的内存泄漏，监听器没正确移除，导致组件卸载后还在尝试更新已经销毁的界面。

一个熟练的 Rust 开发者，可能几分钟就能找出问题所在。但像我这样对 Rust 不熟悉的人，就算给一天时间加 AI 辅助，也不一定能定位到根本原因。

这就是我想说的：专业知识仍然很重要。

AI 幻觉：你以为的答案可能是错的

在查开源协议的时候，我还遇到了一个典型的 AI 幻觉案例。

上面这张图里，我问 AI 关于 Apache License 2.0 的具体条款，AI 给出的回答看似专业、有条理，但部分内容是不准确的。比如它提到的一些限制条件，实际上在 Apache 2.0 中并不存在，或者表述有误。

这就是 AI 幻觉（Hallucination）的典型表现——自信满满地给出错误答案，而且看起来还特别像那么回事。

如果你不具备相关专业知识，或者没有养成验证的习惯，很容易被带偏。就像学编程一样，如果直接把 AI 给的代码复制粘贴、不加测试，上线后可能会出大问题。

所以我的建议是：

• 重要信息一定要交叉验证，尤其是法律、安全相关的内容
• AI 给的代码一定要跑一遍，看看是否真的 work
• 保持怀疑精神，即使是 GPT-4、Claude 这种顶级模型也会犯错
• 建立基础认知框架，这样你才有能力判断 AI 的回答是否合理

AI 是个强大的助手，但它不是神。它也会犯错，而且犯起错来往往比人更隐蔽、更难察觉。

AI 是一个强大的工具，但它不能替代你对底层原理的理解。当你不知道该怎么描述问题、不知道该往哪个方向排查时，AI 也帮不了你。甚至在某些时候，AI 给出的错误方向还会浪费你更多时间。

给想尝试 AI 编程的朋友几点建议

1. AI 能降低入门门槛，但不能消除学习成本。如果你想认真做项目，还是要有一定的基础，至少要能判断 AI 给的建议是否合理

2. 复杂项目要做好心理准备。AI 辅助≠自动化，你仍然需要大量的调试和验证时间

3. 遇到卡壳的问题，不妨自己静下心来分析。有时候离开屏幕，拿张纸画一下数据流，比跟 AI 反复对话更有效

4. 小步快跑，及时验证。不要一次改太多东西，否则出问题后很难定位是 AI 的方案有问题，还是你的实现有问题

开源协议的选择

在决定把项目开源之前，我其实犹豫过。

毕竟这玩意儿是基于 EcoPaste 改的，而 EcoPaste 又继承自另一个开源项目。关于开源协议的问题，我之前其实一知半解——GPL、MIT、Apache 这些字母组合到底有什么区别？我改了别人的代码，能不能闭源商用？

干脆让 AI 给我补了一课。从 copyleft 到 permissive，从传染性到专利授权，花了一个晚上把整个开源协议体系梳理了一遍。

结果发现，EcoPaste 使用的是 Apache License 2.0——这是一种 permissive 协议，意味着我可以选择闭源商业化，只要保留版权声明就行。也就是说，即使我把 ClipVault 做成付费软件，法律上也没有任何障碍。

但我最终还是决定开源。

一方面是感谢 EcoPaste 和其他开源项目的贡献，另一方面也是觉得：既然站在了前人的肩膀上，就应该让后面的人也能站在我的肩膀上。 这段与 AI 协作、从零摸索 Rust 的经历，或许对其他想做类似尝试的人有点参考价值。

所以 ClipVault 完全开源，同样采用 Apache License 2.0。任何人都可以自由使用、修改、分发，甚至可以拿去商业化——只要保留版权声明、标注修改痕迹即可。如果你觉得有用，拿去用就是；如果你发现了 bug，欢迎提 PR；如果你想二次开发，完全没问题。

技术应该是开放的，知识应该是流动的。

写在最后

这次开发 ClipVault 的经历，本质上是一次”重复造轮子”的练习。市面上已经有不少优秀的剪切板工具，我这么做主要是为了练手，顺便满足自己的需求。

但这个过程让我对 AI 的能力边界有了更具体的认知。它确实改变了我写代码的方式，让我敢去尝试原本不敢碰的技术栈。但它没有、也不可能取代人的判断力和调试能力。

所以，如果你看到各种”AI 取代程序员”的焦虑文章，不必太当真。工具再强大，也还是要看用它的人是谁。

专业知识、问题拆解能力、调试经验——这些才是你的核心竞争力。

---

项目地址：ClipVault

如果你也有类似用 AI 辅助开发的经历，欢迎在评论区交流。踩过什么坑、有什么心得，都可以聊聊。

文章作者：阿文

文章链接： https://www.awen.me/post/4c45d2cf.html

版权声明：本博客所有文章除特别声明外，均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来自 阿文的博客！