序
从 Hermes Desktop Lite 出发，复盘我是怎么和AI一起开发的
| 首页 | 多语言 |
|---|---|
最近 Hermes 的讨论度很高，我自己也一直在用。它很强，但高频使用时，总觉得少一个更顺手的入口。
终端、浏览器、编辑器来回切换久了，想着还是不如做一个放在 Dock 里、点开就能用的极简桌面客户端，于是就有了我做Hermes Desktop Lite这么个事儿......
这个事情最大的收获，并不是我做出这客户端。而是我做的过程中，摸清了我应该怎么使用AI一起开发。
这篇文章不想聊什么技术栈、前端框架什么的，当然也聊不明白这么深奥的东西。我更想复盘一件事：当AI真正进入开发流程后，我负责什么，AI负责什么，以及我是怎么一步步把这种配合走顺的。
1.本质·我的AI开发练习场
说实话，这个项目，本质上是我的AI开发练习场，一开始并不是冲着“认认真真做一款桌面工具”去的。
我真正想弄明白的是：到底该怎么让AI进入到开发任务中，并且不会把程序搞得一团糟
Hermes Desktop Lite 刚好很适合拿来练这件事。有界面、有状态、有本地文件和工作区，也有真实的交互链路，复杂度够用，但又没有大到完全失控。
所以对我来说，这个应用更像一块试验田。 我一边做这个桌面客户端，一边在里面反复练几件事：
- 怎么提需求给 AI
- 怎么把问题切小
- 怎么控制输出不要跑偏
- 怎么判断哪些地方适合交给 AI
- 哪些地方必须自己抓住
做到后面我才发现，这个项目真正有意思的，从来不在于选用了什么技术栈、用了什么框架，而是：真正耐人琢磨的，是把 AI 深度融入实际开发流程的整个摸索过程。
| 模型配置 | 日志管理 |
|---|---|
2. 我的工作模式变化
AI进开发流程后，我参与的内容没有变少，只是模式变了
很多人会觉得，使用AI以后，应该能少做很多事。
但我真正做下来后的感受刚好相反：
AI并没有替我省掉“理解项目”这件事，反而要求我更快理解问题。
以前更多是自己想办法实现。现在更多是自己去判断、定位、约束、验收。
换句话说，我的工作内容没有消失，只是从写代码，解决bug，变成了更快看清问题、把任务说准、把结果盯住。
2.1 还得自己跟踪、定位问题
测试应用的时候，一个功能不对，AI不会天然知道问题在哪。我还是得先判断，这到底是：
- UI问题
- 状态问题
- API问题
- 桌面程序逻辑问题
- 还是浏览器模式和桌面模式行为不一致
如果这一层判断错了，AI很容易在错误方向上越修越远。
所以很多时候，第一步不是“让AI改代码”，而是先把问题钉住。
2.2 还得自己定位元素，精准告诉AI要改什么
这一点感受特别深。
AI很吃“目标是否明确”。改界面的时候，不能只说“这里改一下”或者“这个不太对”。更有效的说法通常是：
- 改哪个页面
- 哪个组件
- 哪个区域
- 哪个元素
- 现在的问题是什么
- 想改成什么样
- 哪些地方不要动（!!!约束非常重要，否则AI可能会发散，导致不相关的文件被改乱）
一旦能快速定位到元素，AI的执行质量就会上来很多。如果自己都说不清楚，AI基本就只能猜。
2.3 还得把模糊需求压缩成明确任务
这是我学到的一个很重要的能力。
很多需求一开始在脑子里其实都是模糊的，比如：
- 这里体验不顺
- 这个页面有点乱
- 这个状态不太对
- 这个交互不够自然
但AI没法直接处理这种模糊感觉。必须先把它翻译成明确任务，比如：
- 把设置页拆成左右两栏
- 工作区切换后刷新会话列表和文件区
- 文件管理页增加创建、删除和预览
- 聊天流式输出结束后收掉 loading 状态
我发现，AI协作开发很大一部分能力，其实不是“会不会写prompt”，而是：能不能把模糊问题翻译成清楚任务。
2.4 还得自己补上下文
AI最怕的不是复杂问题，而是缺上下文的问题。
很多时候，为了让它输出稳定，我都得主动把上下文补齐：
- 复现步骤
- 报错信息
- 涉及的文件
- 当前行为
- 预期行为
上下文一清楚，AI很像一个效率很高的搭档。上下文一模糊，它就特别容易开始脑补。
2.5 最后还是我自己验收
这个边界很清楚：AI可以帮我出成果，但不能替我做最后验收。
尤其是这些地方：
- 状态是不是干净
- 交互是不是顺
- 功能点有没有漏
- 功能是真的修好了，还是只是“看起来正常了”，这一点在关键链路上尤其明显。
3. 这个项目里，AI最能帮到我的三个场景
不是所有事情都适合交给AI。但在Hermes Desktop Lite的开发过程里，有三类场景我觉得特别好用。
场景一：我先定结构，AI帮我铺第一版
这个项目里，我很早就决定前端要支持两种运行方式：
- 浏览器模式：专门调试UI，尤其是跟踪API调用状态和返回错误信息的时候
- Tauri 模式：接真实桌面能力
选择这个架构是因为我知道，如果每次改界面都要重新拉起桌面环境或者debug，开发节奏会很慢。
等边界定下来以后，AI 在这里就特别顺手。它很适合帮我快速补这些东西：
- API壳子
- 浏览器分支和桌面分支
- mock数据
- 一些重复的状态读写逻辑
这种时候最明显的感受是：AI不是替我做架构，而是在替我把明确方案快速铺成代码。
| 工作区 | 切换工作区 |
|---|---|
场景二：规则我来定，页面和CRUD让AI来做
这个项目里像工作区管理、设置页、文件管理、会话列表、终端模拟这种页面，其实都很适合 AI 参与。
因为这些页面真正重要的是规则，而不是代码本身。
比如工作区管理，我会先自己想清楚：
- 工作区最少需要什么字段
- 切换以后哪些区域要联动
- 删除当前工作区时要限制什么
- 当前工作区和历史数据是什么关系
这些规则一旦明确，AI 就能很快帮我完成：
- 弹窗结构
- 表单状态
- 列表渲染
- 基础校验
- toast提示
- 空状态和报错状态
这类工作自己写当然也行，但让AI来做，效率会高很多。
场景三：关键链路让AI起跑，但我自己一定要坚守最后一关
最典型的例子就是聊天流式输出。
表面上看，这只是“把流接起来”。但真正做起来以后，问题全在边界上：
- 结束事件会不会重复触发
- 历史对话与当前会话session会不会冲突
- 旧会话续写时上下文会不会断
- 工具事件顺序是不是稳定
AI在这里当然也有帮助。它可以很快帮我把第一版骨架搭起来，比如：
- 流式处理结构
- 前后端事件桥接
- 监听逻辑
- 基础状态流转
但这类代码最容易出现一种错觉：它看起来像是完成了，其实还远没有。
因为关键链路的问题，很多只有自己跑起来才知道。
所以我后来给自己定了一条很明确的原则：AI负责干粗活，我负责验收。
| 对话工具调用信息 | 终端 |
|---|---|
4. 哪些事情我现在依然不会交给AI去做
做到后面，我对边界越来越清楚。有三类事情，我现在基本不会交给AI来决定：
4.1 方向
这个应用到底是聊天壳子，还是日常使用的桌面工作台，这件事只能我自己定。
因为它决定后面所有东西的优先级。
4.2 核心交互
像工作区是不是核心概念，切换工作区要不要联动运行状态，这种事情也不会交给AI拍板。
它可以给建议，但不能替我做落地判断。
4.3 技术取舍
哪些能力自己做，哪些能力直接复用Hermes Agent已有接口，这也是我自己决定的。
因为这背后不是代码问题，而是时间成本、维护成本和学习目标的问题。
而且这个项目本来就是我在学习AI开发时的一块真实练习场。
5. 这次我真正学到的，不是某个框架，而是一种节奏
如果现在回头总结，这次最大的收获，真的不是我做出了Hermes Desktop Lite。
而是我终于知道，怎么和AI一起开发，才不会失控。
我现在更稳定的一套做法是：
- 先把问题切小
- 先把边界讲清楚
- 先由我定义规则
- 再让AI去完成明确局部
- 最后由我自己整合和验收
一旦这么合作，AI就不再是一个“给我写代码的工具”，而更像一个真正能提速的搭档。
它不能替我做判断。但它可以极大缩短我拿到第一版的时间。
而开发里最珍贵的，很多时候不是“少敲了多少代码”，而是：更快拿到一个可以继续判断、继续修正、继续推进的版本。
| 文件管理 | 快捷指令 |
|---|---|
写在最后
Hermes Desktop Lite只是一个结果。
真正更重要的，是我终于通过这个项目，把“怎么和AI一起开发”这件事，练成了一套自己能复用的方法。
我现在越来越相信一件事：AI最适合的角色，不是自动生成整个项目，而是成为一个高响应速度的实现搭档。
前提是你自己得足够清楚：
- 你到底要做什么。
- 哪些地方必须自己判断
- 哪些地方适合交给AI提速
- 哪些地方最后必须自己验收
- 如果这些问题你自己心里有数，AI确实能把开发效率往前推很多。
- 但如果这些问题你自己都没想清楚，那AI往往只会把项目越带越散。
- 希望这些踩坑经验和协作节奏，能给你带来一些参考。
- 我们都在探索怎么更好地和AI一起工作，路上共勉。
