首先进入大家最喜欢的源码和成品环节

源码：

EmlogStudio-v0.4.3-source.zip

成品：

EmlogStudio-v0.4.3.apk

一直以来，我都用 Emlog 搭建个人博客。这套系统本身已经足够成熟，但日常使用中逐渐暴露出一个明显的问题：电脑端管理很方便，手机端临时创作却体验糟糕。

比如突然想到一个点子想发微语，或者人在外面需要修改文章，甚至只想让 AI 帮忙整理初稿——都得打开浏览器、登录后台，在专为 PC 设计的界面里艰难操作。

于是我干脆做了一款面向 Emlog 的 Android 客户端。

它并非要取代 Emlog 后台，而是把最常用的内容创作功能抽离出来，重新设计成更适合手机使用的 App。

一、产品定位：移动端的 Emlog 创作工具

这款 App 的核心定位很清晰：专门服务于 Emlog 的移动端写作与内容管理工具。

目前围绕三大场景展开：

• 文章管理：新建、编辑、删除
• 微语发布：快速记录短内容
• AI 辅助创作：结构化写作支持

目标不是把后台所有设置塞进手机，而是实现一套完整的内容发布闭环：

想到内容 → 打开 App → 写作 / AI 辅助 → 预览 → 发布

这才是它与「用手机浏览器进后台」的本质区别。

二、连接自有站点，数据完全自主

App 本身不是博客平台，也不会把文章存到第三方服务。它连接的就是你自己的 Emlog 网站。

配置站点信息后，客户端直接与 Emlog 通信。所有发布、修改、删除操作，最终都落回你自己的站点数据。换手机、重装客户端，网站数据不会受到任何影响。

网站始终是核心，App 只是增加了更适合手机的入口。

三、文章管理：从创建到发布的完整流程

文章功能是客户端目前最重要的模块，不只是放一个「发布文章」的输入框：

四、Markdown + 实时预览

我个人偏好 Markdown，但它在手机上有明显痛点：写的时候看到的是符号，不是最终排版。

## 标题
**加粗文字**
> 引用内容
- 列表 1
- 列表 2

长文编辑时很容易失去对排版的直观感知。因此 App 加入了实时预览功能，编辑时可随时查看渲染效果。

已支持的 Markdown 语法包括：标题、粗体、斜体、删除线、引用、有序/无序列表、链接、图片、代码、代码块、分割线等。

写作流程由此变为：

Markdown 编辑 → 实时预览 → 检查排版 → 发布到 Emlog

相比盲写，直观得多。

五、微语：接近社交 App 的发布体验

Emlog 的「微语」是我很喜欢的功能，适合一句话、一个想法、开发记录、学习笔记等碎片化内容。这类短内容恰恰最应该在手机上便捷发布。

客户端希望实现的体验是：

想到什么 → 打开 App → 写完直接发

而非：

打开浏览器 → 找后台 → 登录 → 找微语入口 → 开始输入

减少操作步骤，对短内容创作至关重要。

六、AI 辅助：工具，而非替代

项目中我很重视 AI 功能，但明确拒绝这种设计：「点一下按钮，自动生成一篇垃圾文章」。

我希望 AI 是写作工具，而非写作替代。比如只有一个模糊想法时，AI 可以帮忙：

• 整理文章结构
• 生成初稿
• 补充章节
• 润色表达
• 将零散想法系统化

生成内容会进入编辑器，最终由用户自己修改、增删、预览、决定是否发布。本质上是「辅助写作」，不是「AI 自动发博客」。

七、多模型支持，拒绝绑定单一厂商

国内大模型发展极快，今天性价比高的，明天可能就有更好的。因此 AI 模块采用独立 Provider 架构，不与任何单一厂商绑定。

重点适配的模型包括：

• DeepSeek
• 智谱 GLM
• Kimi
• 小米 MiMo

每个厂商独立保存 API 配置（API Key、地址、模型名），写作时自由选择。新增模型无需重构 AI 模块。

AI 服务
├── DeepSeek ── API Key / 地址 / 模型
├── GLM ────── API Key / 地址 / 模型
├── Kimi ───── API Key / 地址 / 模型
└── MiMo ───── API Key / 地址 / 模型

客户端提供能力，模型由用户自己选择。

八、为什么不做成网页版？

常见问题：Emlog 有后台，手机浏览器也能打开，何必专门做 App？

这是两个不同的问题：

传统 CMS 后台功能庞杂，界面天然复杂。但移动端最高频的操作其实非常集中。

所以我更希望它是 「Emlog Mobile Creator」，而非把 PC 后台硬塞进 6 英寸屏幕。

九、架构设计：模块化解耦

源码会完整开放，整体架构如下：

Emlog Android Client
│
├── 站点配置       # 管理 Emlog 站点连接信息
├── Emlog 通信层   # 客户端与站点的数据交互
├── 文章模块       # 列表、新建、编辑、删除
├── 微语模块       # 读取、发布、编辑
├── 编辑器         # Markdown 输入、实时预览
├── AI 模块        # Provider 管理、多模型适配
└── 本地配置       # 站点信息、AI 设置

Emlog 通信、编辑器、AI 三部分尽量解耦。未来新增 AI 模型或 Emlog 管理功能，无需推倒重写。

十、为什么开放源码？

一个重要原则：不要把 Emlog 这种开放生态，最后做成封闭的客户端。

除 APK 外，完整源码一并提供。有开发能力的用户可以：

• 自行编译 APK
• 修改界面与功能
• 接入新的 AI 模型
• 调整 Emlog 对接逻辑
• 研究 Android 与 Emlog 的通信方式

即使我个人停止维护，源码存在，项目就能被社区延续。

十一、当前状态：持续打磨中

项目仍在积极开发，最近集中解决真实使用中的体验问题：

• 手机输入时的页面跳动
• 新建与编辑文章的输入体验差异
• 微语编辑流畅度
• Markdown 预览兼容性
• AI 请求等待与异常处理
• 不同厂商接口差异
• Android 稳定性与闪退

越来越深的体会是：「能运行」的 App 很容易，「每天愿意打开」的 App 才是真正难做的。

很多体验问题，只有自己真的拿手机写几篇文章才会发现。

十二、后续规划：向「移动创作中心」演进

更完整的文章管理

分类、标签、草稿、封面、搜索、分页、发布状态等更多文章属性。

更强的 AI 编辑能力

从「生成整篇文章」进化到针对选中内容执行：续写、润色、缩写、扩写、总结、改标题、生成摘要/SEO 描述、修正 Markdown 等。

更好的编辑器

提升输入体验、光标稳定性、代码块与表格支持、编辑/预览切换流畅度。

更多 Emlog 管理能力

内容创作主线稳定后，逐步加入评论管理、分类/标签管理、媒体资源、多站点支持等。

原则：先把写作做好，再考虑扩展。

十三、写在最后

这款客户端是我近期 Emlog 改造系列的一部分。之前更多折腾前台主题、后台界面、Markdown 体验、微语、评论等，Android 客户端相当于把整个系统向移动端自然延伸。

目标不是重做博客 CMS，而是基于 Emlog 成熟的能力，把网站、移动端、AI 创作真正串联：

┌──────────────┐
│  AI 模型     │
│  DeepSeek 等 │
└──────┬───────┘
       │
       ↓
手机 → Emlog Android App → 编辑/预览 → Emlog 站点

• 网站数据属于自己
• AI 服务自行选择
• 客户端源码自己掌握

这或许更符合个人博客的本意：自己的内容，自己的服务器，自己的工具。

项目仍在完善。后续有稳定新版本，我会继续记录开发过程，同步更新 APK 与源码。