本文由 Claude 通过 Gridea Pro MCP 服务全自动撰写并发布。
最近,我为 Gridea Pro 开发了一个全新的功能模块——MCP 服务。如果你关注 AI 原生应用(AI-Native App)的发展,一定会对这个协议感兴趣。
今天,我想聊聊为什么要这么做,这一路踩过的坑,以及刚刚发生的一个差点让我弃坑的“幽灵 Bug”。
什么是 MCP?为什么要在桌面应用里加这个?
MCP (Model Context Protocol) 是 Anthropic 提出的开放标准,旨在解决 AI 模型与外部数据连接的问题。
对于 Gridea Pro 这样一个拥有丰富本地数据(文章、配置、分类、标签)的桌面应用来说,MCP 简直是完美的补全:
- 以前:你需要点十几次鼠标才能把一条闪念变成一篇草稿。
- 现在:你只需要对 Claude 说:“把最近那条关于 Go 并发的闪念扩写成一篇技术博客,要幽默风趣”,然后——Poof,草稿就躺在你的列表里了。
这不仅是操作效率的提升,更是交互范式的变革。应用不再是被动等待点击的工具,而是可以直接被 AI 调用的能力集合。
架构实战:复用与解耦的平衡艺术
为了实现这个功能,我做了一个重要的架构决策:不修改 Gridea Pro 现有的 Service 层业务逻辑,只通过 Facade 模式暴露给 MCP。
Gridea Pro 是基于 Wails 框架的 Go + Vue 应用。通常情况下,Service 层通过 Wails 直接暴露给前端。而在 MCP 模式下,我们需要一个无头(Headless)环境。
我们编写了一个独立的二进制工具 gridea-mcp,它做了三件事:
- 复用代码:直接引入
backend/internal/service等核心逻辑。 - 依赖注入:在没有 Wails DI 容器的情况下,手动组装 Repository、Service 和 Renderer。
- 协议适配:使用
mark3labs/mcp-goSDK 将业务函数包装成 MCP Tools。
这样的好处是显而易见的:所有的业务规则(如 slug 生成逻辑、文件命名规范)在 GUI 和 MCP 中保持绝对一致。
踩坑实录:Markdown 也就是那个“幽灵 Bug”
开发过程并非一帆风顺。就在刚才,我遇到了一个极其诡异的 Bug。
现象:
通过 MCP 创建的文章,内容看似完美。但在 Gridea Pro 前端点击“编辑”再通过“返回”退出时,应用由于 Frontend Error 瞬间白屏,控制台赫然写着:Unhandled Promise Rejection: Error: Unexpected usage。
为什么诡异?
- 手动创建的文章完全正常。
- MCP 创建的文章在文件系统里看起来没有任何问题(Markdown 格式正确)。
- 即使把 MCP 创建的文章内容清空,问题依旧!
排查过程(这是一场典型的“二分法”侦探游戏):
- 怀疑 Frontmatter:是不是
tag_ids字段格式不对?- 尝试:清空 tag_ids,问题依旧。
- 怀疑文件名:是不是包含了特殊字符?
- 尝试:重命名为
test.md,问题依旧。
- 尝试:重命名为
- 怀疑隐形字符:是不是 Go 在写入文件时带入了 UTF-8 BOM 或其他不可见控制符?
- 尝试:用
cat -v查看,一切正常。
- 尝试:用
- 怀疑内容本身:
- 我把正文删到只剩一行:正常了!
- 我加回代码块:崩溃。
- 我删掉代码块:正常。
- 重点来了:我把正文中的分割线
---删掉,正常了!
真相大白:
Gridea Pro 的前端编辑器(Monaco Editor)或其 Markdown 解析器在处理正文中的 ---(Horizontal Rule)时,可能将其错误地识别为 Frontmatter 的结束符,导致内部状态机紊乱。
而手动创建的文章里,我习惯用 *** 或空行来分割,恰好避开了这个问题。
解决方案:
在写入文件前,扫描内容,将作为分割线的 --- 替换为 ***。一个字符的改动,挽救了整个编辑器的稳定性。
这也提醒我们:在 AI 生成内容时,永远不要假设它的输出是完全“安全”的,特别是在涉及结构化数据解析的场景下。
写在最后
现在的 Gridea Pro,不仅有了 GUI,也有了“大脑接口”。
你可以试着对它说:
- “检查我的博客有哪些标签很久没用了”
- “把所有未发布的草稿列出来”
- “帮我把这篇中文文章翻译成英文并发布”
这就是我心目中软件进化的方向——不仅为人服务,也为 AI 服务。
本文使用的 MCP 工具列表:\n* mcp_gridea-pro_create_post (你猜对了,就是用它发的)\n* mcp_gridea-pro_write_content (虽然实际是 AI 写的)
评论