交易员.Coder1. 立项从「一个窗口」开始：WeClaw 要解决的问题和第一版形态
WeClaw 这个名字最早不是正儿八经的产品代号，是我在白板上随手画的一只丑猫。但立项理由非常朴素：我做技术咨询和独立开发，每天要在代码编辑器、浏览器、PDF 阅读器和聊天软件之间来回切换，光是「把问题描述清楚给 AI」这件事就消耗了大量精力。问代码要复制报错、问翻译要粘贴文本、问文档要手动把关键段落丢进去，上下文一换就全断。市面上已有不少 Chat 类网页、也有各种聚合客户端，但在「我本机上的文件、剪贴板、当前选中的代码」这个语境里，它们始终隔着一层。
所谓跨平台 AI 助手，在我这边的定义不是「把同一个聊天界面搬到 Windows、macOS 和 Linux」，而是让 AI 能力长在系统里：无论我在编辑器选中一段报错，在浏览器看到一段外文，还是在终端里遇到一条看不懂的日志，都能通过同一个快捷键唤起 WeClaw，让它带着当前上下文回答问题。这个目标决定了后面的架构演进方向。WeClaw 不管底层接的是云端大模型还是本地小模型，对用户来说应该只是一个可以随时呼出的系统级助手。
如果你正在做 AI 应用集成、桌面端工具，或者想把一个小工具慢慢做成长线产品，这篇文章会比较对味。我不会只讲最终架构图，而是把中间反复推翻、重写、留坑、填坑的过程一起讲出来，因为架构演进真正值钱的不是最后的漂亮分层，而是那些「当时为什么这么选」的判断。
1.1 需求收敛：五个高频场景，砍掉三个伪需求
第一版之前，我列了八个候选场景：代码问答、文档摘要、划词翻译、周报生成、会议记录整理、图片 OCR、情绪陪伴、像 Siri 一样闲聊。后来跟几个真实用户聊完，砍掉了一半。
留下来的是三个：
- 划词解释和翻译：在任何桌面应用里选中文本，按快捷键直接得到结果，不需要先把文本复制到网页。
- 终端/报错代码分析：把剪贴板里的一段报错丢给模型，结合对话历史判断修复方案。
- 本地文档问答：把 PDF、Markdown、TXT 放进一个目录，AI 能基于这些资料回答「我们架构文档里对权限是怎么设计的」。
被砍掉的情绪陪伴和闲聊，不是技术不能做，而是它们对延迟、上下文连续性和系统权限的要求完全不一样。如果一开始就做八爪鱼式的全能助手，架构八成会被需求拉扯到散架。这个收敛过程给整个项目定了基调：WeClaw 要做的是「帮助用户处理信息」，不是「陪用户聊天」。后面所有架构决策，都以「能不能更低延迟、更快拿到上下文、更可靠地执行工具」为标准来判断。
1.2 v0.1 架构选型：为什么先做网页应用而不是桌面程序
很多人听到「跨平台 AI 助手」会直接选 Electron 或者 Flutter，但我第一版反而做成了 Web 应用。原因非常现实：我不确定用户愿意在多大程度上接受一个需要常驻的桌面程序，先用浏览器验证需求最省钱。
v0.1 的架构非常简单：前端是 React + Vite 的单页应用，后端是 Python FastAPI，里面封装了对大模型服务的 HTTP 调用。用户打开浏览器，粘贴文本，点提问，后端转发请求，流式返回结果。这个版本把「能不能在一个页面里完成问答」验证通了，但也很快暴露出两个问题：
第一，浏览器里拿不到系统级的上下文。划词文本、剪贴板变化、当前前台应用，这些能力在浏览器里都受严格限制，很多需要通过本地代理或者浏览器插件才能实现，体验支离破碎。
第二，用户不愿意为了一个工具去记忆 URL、打开浏览器、找到书签。他们要的是「按一下快捷键，它就在那里」。Web 版本的用户留存率低得惊人，上线两周只有不到 10% 的人会第二次主动打开。
v0.1 的结论是：需求真实存在，但使用形态必须是桌面客户端，且最好支持全局快捷键。于是第一次架构转折开始了。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 第一次架构转折：从浏览器页面到可常驻的系统托盘程序
严格来说，WeClaw 真正从 0 到 1 是这一阶段开始的。网页版推倒之后，我花了一周时间做技术选型。当时摆在面前的是 Electron、Qt、Tauri、Flutter Desktop 四个方向，网上争论很多，但放到 WeClaw 的具体场景里，比较维度会变得非常清晰。
2.1 用户「挂后台」的需求出来后，Web 架构的短板立刻暴露
网页版验证期间，有个用户反馈让我印象深刻：「我希望能像输入法一样呼出它。」也就是不管当前在哪个应用里，按快捷键就能弹出一个悬浮输入框，输入问题后它变成一个小窗展示答案，再按一下 Esc 就消失。这个需求需要程序常驻后台、监听全局快捷键、能够在其他窗口之上绘制自己的 UI，同时保持很低的内存占用。
网页方案做这些事要么得靠浏览器插件，要么得再套一层本地代理，链路一长延迟和 bug 数量都会成倍增加。与此同时，AI 对话是典型的「高频短交互」，如果每次呼出要等 3 秒，用户会直接放弃。技术选型的核心矛盾变成：什么方案能在提供完整系统能力的同时，把启动路径和常驻成本降到最低？
2.2 Tauri、Electron、Qt、Flutter 的取舍
列一张当时做的对比表，可能对你也有参考价值。
| 方案 | 安装包体 | 常驻内存 | 系统能力 | 移动端覆盖 | 团队熟悉度 | 结论 |
| --- | --- | --- |