一、项目背景

原文内容

一、项目背景

ZenReply 是我在 2026 年 3 月左右开发的一个桌面端 AI 沟通辅助工具。它的核心想法很简单：很多时候我们并不是“不知道要说什么”，而是“不知道怎样把想法说得更合适”。比如面对老师、同学、合作方、实习中的负责人，原始想法往往带有情绪、犹豫或者表达不清的问题。ZenReply 希望把用户临时写下的草稿，转换成更体面、清晰、可直接发送的回复。

这个项目不是一个普通网页应用，而是一个跨应用的桌面端工具。用户可以在微信、飞书、钉钉、浏览器等任意应用中选中文字，通过全局快捷键唤醒 ZenReply，由程序捕获当前文本并弹出面板，再调用用户自己配置的 AI 接口生成回复。生成结果不会自动代发，而是写入剪贴板，由用户自行决定是否发送。

项目采用 Tauri v2、Rust、React 19、TypeScript、Vite、Tailwind CSS v4、Framer Motion 等技术栈。前端负责交互、动效、状态管理和流式输出展示；Tauri/Rust 侧负责系统托盘、窗口控制、全局快捷键、文本捕获、剪贴板等桌面能力。

二、我为什么使用 AI 辅助开发

这个项目的复杂点不在于单个算法，而在于“很多细节必须同时成立”：

1. 桌面端窗口要能被全局快捷键唤醒；
2. 用户在其他应用里选中的文字要能被捕获；
3. 面板要快速出现，并且不能打断当前工作流；
4. AI 返回内容需要流式展示；
5. API Key、Base URL、模型名称等配置要本地保存；
6. 程序关闭后应该隐藏到系统托盘，而不是直接退出；
7. 整个流程最好以键盘为中心完成，减少鼠标操作。

如果完全靠自己从零查文档、试 API、排错，开发周期会被大量细碎问题拉长。因此我把 AI 作为一个“结对工程师”使用：我负责定义产品形态、判断技术取舍和最终验收；AI 负责快速生成候选实现、解释框架机制、定位报错原因、补齐重复性代码和帮助重构。

三、AI 在项目中的具体作用

1. 从需求描述到系统结构拆分

在最开始，我并不是先写代码，而是先用自然语言描述产品流程：

• 选中文字；
• 按快捷键唤醒；
• 自动捕获文本；
• 根据沟通对象选择回复策略；
• 调用 AI 接口流式生成；
• 确认后写入剪贴板；
• 面板关闭并回到原应用。

AI 帮我把这个流程拆成了几个模块：输入捕获模块、窗口管理模块、AI 请求模块、配置存储模块、前端交互状态机、系统托盘模块。这个拆分很有价值，因为它把一个“看起来只是一个小工具”的想法，转化成了可实现、可调试的工程结构。

2. 辅助完成 Tauri 与 React 的跨端协作

ZenReply 的一个核心难点是前端和系统能力之间的边界。React 适合做界面，但全局快捷键、系统托盘、剪贴板、窗口显示与隐藏等能力都需要 Tauri/Rust 侧参与。

AI 在这里主要帮我完成了两类工作：

• 解释 Tauri v2 中 command、plugin、window、tray 等机制的用法；
• 根据我的需求生成 Rust 侧和 TypeScript 侧的通信代码。

例如，当我需要“按 Alt+Space 后弹出窗口，并把捕获到的文字传给前端”时，AI 会给出一个初始方案。我再结合实际运行效果调整：哪些逻辑放在 Rust 侧，哪些逻辑放在前端；哪些状态需要持久化，哪些只需要保存在当前会话中。

这个过程中，AI 不是一次性生成完美代码，而是不断参与“小步试错”。我把报错、运行现象、预期行为告诉它，它再帮我定位可能的原因和下一步修改点。

3. 快速实现 AI 流式调用与 OpenAI 兼容接口配置

ZenReply 支持用户填写自己的 API Key、API Base URL 和模型名称，并且支持 OpenAI 兼容接口。这个设计让它可以接入不同服务商，而不绑定某一个固定平台。

这里 AI 主要帮助我完成了：

• SSE 流式响应的解析；
• 前端逐字渲染；
• 请求中断、错误提示、按钮状态恢复；
• API Key、本地配置和默认值处理；
• 测试连接逻辑。

这些代码本身并不一定很难，但细节多、容易写出边界问题。AI 的价值在于快速给出一个可运行版本，然后我根据真实交互继续修改。例如，网络错误时不能让按钮永久卡死；上一轮请求失败后，要在 Toast 消隐后恢复按钮状态；生成过程中再次按键要有明确反馈。

4. 辅助设计键盘优先的交互流程

我希望 ZenReply 是一个“低打断”的工具，而不是另一个需要频繁点鼠标的聊天窗口。因此它的交互设计尽量围绕键盘展开：

• Alt+Space 唤醒；
• Alt+1 切换到回复模式；
• Alt+2 切换到英文翻译模式；
• 数字键选择对象或风格；
• Enter 开始生成；
• 再次 Enter 确认并复制；
• Esc 关闭窗口或终止会话。

AI 帮我把这些交互整理成清晰的状态机：当前处于输入、选择、生成、结果确认、设置面板等状态时，同一个按键应该触发不同操作。这个过程让我意识到，AI 不只是在“写代码”，也可以辅助做交互逻辑的梳理。

5. 辅助排查工程化问题

项目从原型走向可发布版本时，出现了不少工程化问题。例如：

• 从 bun 迁移到 pnpm 后，构建命令没有同步，导致 Tauri 窗口无法正常显示；
• 不同桌面应用对文本捕获的响应速度不同，需要增加兜底轮询；
• 毛玻璃卡片和发光效果在某些场景下显示异常；
• GitHub Actions、版本号、release、安装包构建等流程需要整理。

这些问题很适合用 AI 辅助排查。我通常会把命令输出、报错日志、目录结构和相关配置贴给 AI，让它先给出假设，再逐一验证。AI 在这里像一个“有经验的工程助教”，可以迅速指出配置项之间的不一致，例如 package manager 迁移后脚本、lockfile、CI、Tauri 配置之间的同步问题。

四、我在开发中的工作方式

这次项目让我形成了一种比较有效的 AI 辅助开发流程：

1. 先让 AI 生成方案，而不是直接生成大段代码

我会先问 AI：这个需求应该拆成哪些模块？有哪些实现路线？哪些部分容易踩坑？确认方向后，再让它生成局部代码。这样可以避免一开始就得到一大段难以维护的实现。

2. 每次只让 AI 改一个明确问题

例如我不会直接说“帮我把整个项目写好”，而是会拆成：

• 帮我写一个设置面板；
• 帮我解析 OpenAI 兼容 SSE；
• 帮我处理系统托盘关闭逻辑；
• 帮我解释为什么 Tauri 窗口没有显示；
• 帮我把快捷键逻辑整理成状态机。

这种方式更容易检查结果，也更容易把 AI 输出纳入自己的工程判断。

3. 我负责验收真实运行效果

AI 生成的代码需要经过本地运行验证。尤其是桌面端项目，很多问题必须在真实系统环境下才能暴露，比如窗口焦点、快捷键冲突、不同应用的复制行为、系统托盘行为等。AI 可以提出方案，但最终是否可用，需要我自己在本机测试。

4. 用 AI 做文档和发布整理

除了代码，AI 还帮我整理 README、功能说明、快捷键表、FAQ、版本更新记录等文档。这个环节对项目很重要，因为一个小工具如果没有清楚的使用说明，别人很难快速理解它的价值。

五、项目成果

目前 ZenReply 已经实现了一个完整的可用闭环：

• 桌面端常驻系统托盘；
• 支持全局快捷键唤醒；
• 支持自动捕获选中文本；
• 支持中文角色化回复；
• 支持英文翻译模式；
• 支持 OpenAI 兼容接口；
• 支持 API Key、Base URL、模型名称本地配置；
• 支持 AI 流式生成；
• 支持生成结果写入剪贴板；
• 支持键盘优先操作；
• 已整理 README、CHANGELOG，并发布了初始版本。

从结果上看，AI 显著降低了我完成跨端桌面应用的门槛。它让我可以把更多精力放在产品流程、交互体验和工程判断上，而不是反复陷在文档检索和样板代码中。

六、我的收获

这次经历让我对 AI 辅助编程有了更具体的理解。AI 并不是简单替代程序员，也不是一次性生成完整项目的魔法工具。更准确地说，它改变了个人开发者组织工作的方式。

过去我写一个不熟悉技术栈的项目，往往需要经历很长的“查资料—复制示例—改错—再查资料”的过程。现在我可以直接用自然语言描述目标，让 AI 给出初始实现和解释，再通过本地运行反馈不断收敛。这个过程类似把一个人开发变成了“一个人 + 多个随时可调用的工程助手”。

同时，我也意识到 AI 输出必须经过人的判断。比如哪些功能真的必要、交互是否顺畅、代码结构是否可维护、用户数据是否安全，这些都不能完全交给 AI。AI 可以提高速度，但项目的方向、边界和质量仍然需要开发者负责。

七、总结

ZenReply 是我一次比较完整的 AI 辅助开发实践。从需求拆解、技术选型、Tauri 与 React 协作、流式 API 调用、快捷键交互、系统托盘、配置持久化，到 README 和版本发布，AI 都参与了开发过程。

这次经历说明，AI 对学生开发者的价值不仅是“帮我写几行代码”，而是帮助我们更快地把想法变成可运行、可展示、可迭代的系统。对于课程项目、个人工具、科研原型和工程实践来说，这种能力都非常有意义。 “”"