DocMe 是一个面向 Markdown 工作流的轻量级文档编辑、分享与交付工具。

它最初只是 Markdown Viewer 项目的本地部署：左侧编辑 Markdown，右侧实时预览。但随着 AI 越来越多地参与文档生成，一个新的问题逐渐出现：Markdown 很适合生成，却并不总适合交付。

AI 可以很容易地产出结构清晰的 Markdown，但接下来呢？

有时只需要给别人一个干净的网页链接；有时文档仍在修改，希望链接内容能够同步更新；有时需要把某个确定版本固定下来发送出去；而在更传统的办公环境中，对方真正需要的仍然可能是一份 Word 文档。

DocMe 没有选择做另一个在线协同的文档平台，而是围绕 Markdown 补齐了从生成、编辑、保存到分享和交付之间缺失的几步：

AI Agent → Markdown → DocMe → Web / DOCX / WebDAV

Markdown 是中间格式，DocMe 负责最后一公里。

一、核心理念：让 Markdown 更容易离开编辑器

Markdown 最大的优势，也是它在 AI 时代重新变得重要的原因之一：结构简单、语义明确，而且 Agent 极其擅长生成。

但 Markdown 的问题也同样明显。

你可以把 .md 文件发给别人，但不能假设每个人都有合适的阅读工具；你可以导出 PDF，但 PDF 更接近最终出版物，不适合继续修改；你可以直接分享网页，但如果文档内容被压缩编码进 URL，链接很快就会变得又长又难以传递。

DocMe 并不试图重新发明 Word、Notion 或 Google Docs，而是选择了一条更轻的路线：

Markdown 负责内容，DocMe 负责交付。

📝 Markdown 原生编辑与预览

DocMe 保留了最简单直接的 Markdown 工作方式：

• 左侧 Markdown 编辑；
• 右侧实时渲染；
• 支持标题、列表、代码块、表格、链接、图片等常用 Markdown 内容；
• 无需建立复杂的富文本内部数据结构。

这使得人工编辑和 Agent 生成的内容可以使用完全相同的输入格式。

对于 Agent 而言尤其如此：它不需要理解某个在线文档系统私有的 Block Schema，也不需要直接控制 Word 排版，只需要输出 Markdown 即可。

Markdown 在这里更像是一种文档 IR——Intermediate Representation。

二、文档交付：从 Markdown 到 Word

网页当然很好，但现实中的文档协作并不会因为 Markdown 出现就突然全部消失。

工作汇报、方案评审、操作指南以及正式材料中，Word 仍然是一种非常常见的交换格式。

因此 DocMe 集成了 MarkdownDocx 工具，可以直接将当前 Markdown 导出为排版完整的 DOCX 文档。

📄 DOCX 导出

相比简单的文本转换，DocMe 更希望得到的是一份可以直接交付的 Word 文档。

这形成了一条非常实用的工作流：

Agent 生成 Markdown → DocMe 检查和微调 → 导出 DOCX → 发送

过去让 Agent 直接“生成 Word”，往往意味着同时把内容组织和排版问题交给模型处理。

DocMe 则把两件事情拆开：

• Agent 负责内容和结构；
• MarkdownDocx 负责确定性的格式转换。

这样既保留了 Markdown 的生成效率，也兼容了传统办公环境。

三、分享模式：同一篇文档，不同的打开方式

最初的 Markdown Viewer 已经支持通过 URL 分享当前文档。

• 👁️ View only：以只读方式打开文档。编辑器被隐藏，只保留最终渲染结果，适合一般的文档阅读和分享。
• ✏️ Edit：保留 Markdown 编辑器和预览区域。适合把文档继续交给自己，或者交给知道 Markdown 工作方式的人继续修改。

DocMe 在此基础上扩展支持了纯净阅读模式，隐藏了页面中全部的工具栏和控制按钮，只展示文档本身。

这个模式看似只是少了一些按钮，但它解决的是另外一个问题：

工具界面和交付界面不应该是同一个界面。

当阅读者并不需要知道文档来自哪个 Markdown 编辑器时，页面就应该尽可能退到幕后。

因此 DocMe 可以从一个 Markdown 工具，变成一个干净的文档阅读页面。

四、短链接：不再把整篇文档塞进 URL

开源的 Markdown Viewer 项目有一个非常巧妙的优点：它不需要服务器。

Markdown 可以被压缩、编码，然后直接放入 URL：https://example.com/md/#share=<encoded-markdown>

打开链接即可还原文档。

这种设计非常适合轻量工具，因为服务器甚至不知道用户分享了什么，是一种很好的去中心化的文档分享模式实践。

但它也有一个明显的问题：文档越长，URL 越离谱。

复制、粘贴、即时通讯转发乃至一些浏览器和应用的 URL 长度限制，都开始成为问题。

因此 DocMe 使用阿里云边缘计算实现了一层非常轻量的短链接服务。

原本很长的文档 URL：

Markdown -> 压缩 / 编码 -> 完整分享 URL

现在可以进一步变成：

完整分享 URL -> ESA Function -> KV Store -> 短链接

用户传递的不再是整个文档，而只是一个简短的引用。

五、两种链接语义：快照与实时文档

DocMe 的短链接服务支持两种不同的访问方式。这并不仅仅是两个实现选项，它们对应了两种完全不同的文档分享语义。

🔒 302 跳转：分享一个确定的版本

302 模式保存当前完整分享地址，并在访问短链接时跳转至对应内容。

它更接近一个文档快照：

我分享的是“这一刻的内容”。

此后即使继续修改本地文档，已经发送出去的版本也不会发生变化。

适合：

• 阶段性方案；
• 评审材料；
• 操作记录；
• 某次问题处理方案；
• 希望内容确定后不再变化的文档。

🔄 iframe 嵌入：分享一个持续更新的位置

另一种方式则允许短链接持续指向最新内容。

它表达的是：

我分享的不是某一个版本，而是“这篇文档”。

因此只要内容更新，阅读者再次打开相同链接就可以看到新的版本。

这种方式更适合：

• 操作指南；
• 项目说明；
• 持续维护的技术文档；
• 经常修改但不希望反复发送新链接的内容。

从这里开始，DocMe 中实际上已经出现了两个不同的概念：Snapshot 与 Live Document。

一个强调版本，一个强调引用。

六、分享管理：链接也需要生命周期

当分享链接只有一两个时，把地址复制到聊天记录里并没有什么问题。

但随着链接逐渐增加，一个新的问题出现了：

我分享过什么？

因此 DocMe 在短链接跳转服务中提供了文档共享的管理能力。

在这里可以查看：

• 已分享文档；
• 文档更新时间；
• 分享有效期；
• 阅读入口；
• 原始链接；
• 短链接；
• 分享配置。

并可以集中创建和管理已经公开出去的文档。

这意味着 DocMe 的分享功能不再只是一次性的：

生成链接 → 复制 → 忘记

而开始具有一个简单的生命周期：

创建 → 分享 → 更新 → 到期 / 失效

七、WebDAV：不是所有文档都应该立刻分享

分享解决的是文档如何交给别人。

但还有另外一种情况：

文档还没有写完。

对于正在工作的草稿，最需要的并不是公开链接，而是一个简单可靠的私人存储位置。

因此 DocMe 同时接入了 WebDAV。

☁️ WebDAV 文档库

配置 WebDAV 地址和账号后，可以：

• 浏览服务器中的 Markdown 文件；
• 从 WebDAV 导入文档；
• 将当前文档保存到 WebDAV；
• 删除不再需要的远程文件。

WebDAV 在这里承担的不是“协作平台”的角色，而更像一个足够简单的个人文档仓库。

于是一个文档可以经历：

Agent 生成 -> DocMe 编辑 -> WebDAV 保存草稿 -> 继续修改 -> 创建实时分享 -> 内容确定 -> 生成固定快照 / 导出 DOCX

存储、编辑和发布因此不必绑定在同一个系统中。

八、工作流：Agent 生成，DocMe 交付

DocMe 最适合的场景，并不是替代大型在线文档系统。

它更像 Agent 与现实文档环境之间的一层薄薄的适配器。

1. Agent 生成内容

Agent 根据任务直接输出 Markdown：需求 -> Agent -> Markdown

Markdown 足够简单，因此几乎不存在额外格式适配成本。

2. 人进行最终判断

把 Markdown 放入 DocMe：

• 查看最终渲染效果；
• 修改标题和措辞；
• 调整代码块或表格；
• 删除模型生成中不必要的内容。

Agent 负责快速生成，人负责最后的判断。

3. 根据对象选择交付方式

面对不同接收者，不需要重新制作内容：

                          ┌─ Web 阅读器
                          │
Markdown Viewer ─ DocMe ──┼─ 实时链接分享
                          │
                          ├─ 固定快照分享
                          │
                          ├─ Word 交付（by MarkdownDocx)
                          │
                          └─ WebDAV 同步

同一份 Markdown，可以根据实际场景选择不同的出口。

九、技术实现：保持足够轻

DocMe 的目标始终不是构建一个庞大的文档平台。

因此很多能力都刻意选择了较薄的实现方式：

• Markdown 作为核心文档格式，避免维护复杂的富文本数据模型；
• MarkdownDocx 负责 DOCX 格式转换；
• 浏览器直接完成 Markdown 编辑与渲染；
• ESA Functions 提供轻量服务端逻辑；
• KV Store 保存短链接映射和共享状态；
• WebDAV 承担私人 Markdown 文件存储；
• 独立的共享管理页面负责已经发布文档的生命周期管理。

整个系统没有试图把编辑器、对象存储、协作平台、Office 套件和 CMS 全部重新做一遍。

恰恰相反，DocMe 更多是在已有标准之间建立连接。

十、实际应用价值

DocMe 解决的并不是“如何写文档”，而是一个更小、也更具体的问题：

Markdown 写完之后怎么办？

1. Agent 输出的最后一公里

Agent 天生适合输出 Markdown。

DocMe 让这些内容不必停留在聊天窗口中，而可以快速进入真正的文档工作流：

生成 → 检查 → 分享 → 交付

2. Web 与传统 Office 之间的桥梁

喜欢 Web 的人，可以直接打开链接。

习惯 Word 的人，可以收到 DOCX。

DocMe 不要求接收者改变已有习惯。

3. 快照与持续更新同时存在

有些文档需要“以后打开还是当时那一版”。

另一些文档则需要“以后打开永远是最新版”。

DocMe 将两者区分开来，而不是用一种分享机制勉强覆盖所有场景。

4. 私人工作态与公开分享态分离

WebDAV 保存的是仍在工作的文档。

Share 服务管理的是已经决定发布出去的内容。

文档不需要因为“需要跨设备保存”，就提前进入公开分享状态。

---

DocMe 并不希望成为另一个庞大的在线 Office。

它只是在 Markdown 和现实世界之间补上了一小段路。

Agent 负责生成，Markdown 负责承载，DocMe 负责把文档送到该去的地方。