从一个博客 AI 增强实验，到 Mira 的前身。
GitHub: dangjingtao/ui-chat-view
项目简介#
UIChat 是 UIChat Mira 的上一代探索。
它最初并不是为了构建一个完整的 AI 产品。
最开始的想法很简单：
给上一代 Fresh 博客接入 AI 能力。
项目名称 ui-chat-view 也反映了最初定位：
一个浏览器里的 AI 聊天视图。
但随着 AI 技术快速发展，以及对 AI 应用形态的不断探索，UIChat 逐渐超出了最初设计范围。
它最终成为一个基于浏览器的 AI 智能体应用。
正如项目 README 中最初的描述：
原本是想写一个内嵌服务的。不小心写大了。
从博客增强到 AI 应用探索#
2024 年，本地 AI 开始进入快速发展阶段。
当时的问题不再只是：
“如何调用一个 AI 接口？”
而是：
如果 AI 能力逐渐属于个人，它应该如何进入真实应用？
UIChat 最初希望让博客拥有 AI 能力。
但随着探索深入，关注点开始变化：
- AI 能否理解更多上下文？
- AI 能否执行更多任务？
- AI 是否应该只是聊天窗口？
于是，一个内容系统增强功能，逐渐演变成了一个 AI 应用探索。
浏览器作为 AI 客户端#
UIChat 早期有一个重要判断：
浏览器可能是世界上最广泛使用的客户端。
因此，当时希望：
- 利用浏览器作为入口；
- 使用 Serverless 架构降低部署成本；
- 让 AI 能力直接进入用户环境。
这个方向在当时具有吸引力。
Web 的普及性和 Serverless 的发展，让它看起来像是一条自然路线。
因此 UIChat 开始不断扩展。
写大了#
UIChat 后续不断增加能力。
原本简单的聊天视图，逐渐涉及：
- AI 智能体；
- 能力扩展；
- 多模型支持；
- 应用增强。
这个过程持续了大量迭代。
最终项目经历了约 50 个版本。
但这并不是简单的功能增长。
更像是一场持续验证：
AI 应用到底应该是什么形态？
古法编程时代#
UIChat 的开发方式，与现在 AI 辅助开发方式不同。
整个过程：
- 手写代码；
- 查阅资料；
- 自己设计；
- 自己验证。
这是一次典型的“古法编程”探索。
在那个阶段，很多架构判断和工程习惯，也是通过这样的方式逐渐形成。
一次重要的方向修正#
UIChat 最终燃尽，并不是因为项目没有价值。
而是两个变化重新改变了判断：
AI 写代码能力快速提升#
软件生产方式开始变化。
过去需要大量人工投入构建的能力，逐渐可以通过 AI 辅助快速完成。
这改变了：
什么值得投入大量时间去构建。
MCP 改变了客户端与服务端关系#
UIChat 早期最大的假设：
一切都可以从浏览器完成。
后来发现，这个判断并不准确。
客户端优先，并不意味着服务端应该消失。
更合理的方向可能是：
- 客户端负责体验；
- 服务端提供能力；
- 通过标准协议连接。
MCP 的出现，让这个认识发生改变。
错误的方向，也能留下资产#
UIChat 最终推翻了最初的一些判断。
但它并没有被浪费。
很多重要能力和思想，都延续到了 Mira：
本地优先#
AI 能力应该尽可能掌握在用户侧。
插件化能力配置#
AI 应用不应该只是固定功能集合。
能力应该可以扩展和组合。
多模型调度#
不同模型适合不同任务。
未来 AI 应用需要管理能力，而不是绑定单一模型。
UIChat 与 Mira#
UIChat 和 Mira 的差别很大。
它们不是简单的版本升级。
UIChat 更像：
探索 AI 应用可能性的实验。
Mira 则是在重新理解客户端、服务端、本地能力之后：
构建一个属于自己的个人 AI。
但两者之间存在连续性。
UIChat 留下的：
- 工程经验；
- 架构判断；
- 产品习惯；
- AI 应用探索；
成为了 Mira 的基础。
项目链接#
GitHub: dangjingtao/ui-chat-view