lanhu-mcp：把蓝湖设计稿和团队知识接进 AI 编程工具

它解决的是 AI 助手看不见蓝湖的问题

蓝湖是设计师和前端协作的平台，存放 Axure 原型和 UI 设计稿。但 AI 编程工具默认读不到这些内容，开发者只能手动截图、复制文字描述，再粘贴给 AI。lanhu-mcp 做的事情就是架一座桥：它实现了一个 Model Context Protocol 服务器，让 Cursor、Windsurf、Claude Code 等支持 MCP 的客户端，通过标准协议调用蓝湖的数据。README 里列了七八种客户端，包括通义灵码和 Trae，核心诉求是一致的，让 AI 直接访问设计资源，而不是靠人肉搬运。这个项目适合已经深度使用蓝湖、并且想让 AI 参与需求分析和 UI 还原的团队。它不是给个人开发者的小玩具，而是一个需要部署和配置的服务。

三条数据通路：需求、设计、留言板

从 README 的结构看，lanhu-mcp 暴露了三类能力。第一类是需求文档分析，它自动下载并解析 Axure 原型的所有页面，然后按开发、测试、探索三种视角生成分析结果。第二类是 UI 设计支持，它批量下载设计稿，提取尺寸、间距、颜色、字体等参数，还能把设计 Schema 转成 HTML 和 CSS 代码。第三类是团队留言板，这是一个数据存储层，让不同开发者的 AI 助手读写同一份知识库。留言板是项目自己定义的创新点，因为 MCP 协议本身不包含协作功能，lanhu-mcp 用服务端的持久化数据来模拟共享上下文。这三条通路共用同一个服务器进程，所以部署一次，所有客户端都能访问。

部署方式：Docker 优先，stdio 按需启动

README 给出了两种主要部署路径。Docker 方式适合长期运行：克隆仓库后执行 setup-env.sh 或 setup-env.bat 引导配置 Cookie，然后 docker-compose up -d 启动，服务监听在 http://localhost:8000/mcp。源码运行方式则更轻量，先跑 easy-install.sh 安装依赖，再设置环境变量 LANHU_COOKIE，最后 python lanhu_mcp_server.py 启动。对于本地客户端，项目还提供了 run-stdio.sh 和 run-stdio.bat，以 stdio 模式按需拉起服务，这样 Cursor 或 Claude Code 可以在配置文件里用 command 和 args 指定脚本路径，不用手动常驻进程。配置键不多，核心是 LANHU_COOKIE，可选的有 FEISHU_WEBHOOK_URL、SERVER_HOST、SERVER_PORT、DATA_DIR、HTTP_TIMEOUT 等。环境变量的命名很直白，没有复杂的嵌套配置。

缓存和增量更新：版本号驱动的性能设计

蓝湖上的文档和设计稿会频繁更新，如果每次 AI 请求都重新下载全部资源，效率很低。lanhu-mcp 的 README 提到两个性能手段：基于文档版本号的永久缓存，以及只下载变更资源的增量更新。这意味着服务器会记录每个文档的版本标识，请求时先比对版本，没有变化就直接用缓存，有变化才拉取新增部分。另外还支持并发处理，批量页面截图和资源下载可以并行。这个设计对使用体验影响很大，因为 AI 工具在分析需求时往往要遍历多个页面，没有缓存的话每次都要等网络请求。不过 README 没有给出具体的缓存失效策略或存储格式，实际效果需要部署后观察。

一个硬性前提：AI 模型必须能看图片

README 在快速开始部分用警告语气强调，必须使用支持视觉功能的 AI 模型，比如 Claude、GPT、Gemini、Kimi、Qwen、DeepSeek，明确不支持纯文本模型如 GPT-3.5 或 Claude Instant。这个限制是功能性的，因为设计稿分析需要读取图片像素信息，需求文档里的 Axure 原型也包含可视化元素。如果你用的模型只能处理文字，lanhu-mcp 的大部分功能会失效，只剩留言板可能还能用。另一个隐含的限制是蓝湖 Cookie 的获取，README 说要从浏览器开发者工具的请求头里复制，这意味着 Cookie 可能有过期时间，而且不同用户的权限范围不同。部署时如果 Cookie 失效，所有请求都会失败，这是一个需要运维关注的故障点。

与直接截图给 AI 相比，它多了什么

一个常见的替代方案是开发者手动截图蓝湖页面，然后粘贴给 AI 工具。这种做法零成本，但有两个问题：每次都要人工操作，且 AI 只能看到静态图片，拿不到结构化的设计参数。lanhu-mcp 的价值在于把设计稿解析成机器可读的数据，比如颜色值、字体大小、间距，这些参数可以直接用于代码生成。另一种替代方案是使用蓝湖官方提供的 API 或导出功能，但那样需要自己写脚本对接，而且蓝湖的接口未必暴露所有内部数据。lanhu-mcp 把解析逻辑封装好了，还加了语义化命名和 HTML 转换。区别在于，手动截图是给 AI 看一张图，lanhu-mcp 是给 AI 一份带结构的数据，后者更适合自动化生成代码。

维护成本与许可证：MIT 下的自由与责任

项目使用 MIT 许可证，这意味着你可以自由使用、修改、商用，甚至闭源发布衍生版本，只要保留版权声明。从仓库信息看，最近一次推送是 2026 年 7 月，版本号到了 v1.7.1，说明维护比较活跃。但维护成本要算清楚：你需要维护一个运行中的服务，包括 Docker 容器或 Python 进程的监控、蓝湖 Cookie 的定期更新、以及依赖库的升级。README 提供了 config.example.env 文件作为配置参考，但没有提到日志轮转、备份策略或升级脚本。如果蓝湖平台改了页面结构或接口，lanhu-mcp 的解析逻辑可能失效，需要等待上游修复或自己动手改。对于不想折腾基础设施的团队，这个维护负担可能比想象中重。

编辑结论

如果你所在团队同时使用蓝湖和 Cursor、Claude Code 这类支持 MCP 的 AI 工具，且愿意维护一个常驻服务，lanhu-mcp 值得尝试。它解决的问题很具体：AI 助手无法直接读取 Axure 原型和设计稿，以及各开发者 AI 之间上下文割裂。不适合的场景包括：团队没有蓝湖账号、AI 模型不支持视觉能力、或者你只想要一个单机小工具而不想部署 Docker 服务。落地前需要验证三件事：第一，确认你的 AI 模型支持图像识别，README 明确说不支持纯文本模型；第二，检查蓝湖 Cookie 的获取和有效期，这是所有功能的前提；第三，如果要用飞书通知，提前配置好 webhook 和用户映射。项目的 MIT 许可证意味着可以自由修改和商用，但维护节奏和长期兼容性取决于社区活跃度，建议先在小团队试点，观察一周内的实际使用频率再决定是否全面推广。

官方来源

1. Official README
2. Project repository
3. Release notes