AI 接入 Photoshop
批量改图导出与单张图的对话式精修
- 当前状态
- 可直接使用
- 使用技术
- Python · MCP · COM · Photoshop 2023
- 适用场景
- 批量改图导出与单张图的对话式精修
01
问题
想让 AI 做哪两类活
- 批量处理:一次处理一批图,统一改尺寸、转格式、压缩、加水印、批量导出。
- 对话式精修:对单张图调色、动图层、加文字、做排版,边聊边改。
这两类活有一个共同前提——AI 得真的能操作软件,而不是输出一份「你先点这里再点那里」的说明书。网上大部分所谓「AI 做设计」,做到的都是后一件事。
动手前撞上的四道关卡
| 序号 | 问题 | 具体表现 |
|---|---|---|
| 1 | 没有官方通道 | Adobe 没有面向 AI 的通用接口,插件市场里也搜不到「接管本机 Photoshop」的连接器,返回的全是 AI 生图工具。 |
| 2 | 版本门槛 | 主流社区方案基于 UXP 插件桥接,而 UXP 新版清单要求 Photoshop 23.3(2022)以上;本机原装的是 2021(v22.0)。 |
| 3 | 安全策略拦截 | 用 PowerShell 直接实例化 COM 对象被运行环境的安全层拦下,提权也不放行。 |
| 4 | 方案虚标 | 调研到一个颇有名气的 MCP Server 项目,文档写着支持「UXP 后端」,实测其发行版本底层只是 COM 封装,并不存在真正的插件桥接。 |
问题本质
这是一个双重门槛:版本门槛(旧版软件不支持新协议)叠上协议门槛(没有标准接口暴露软件能力)。只解决其中一层都不成立——升了版本没接口照样接不上,有接口但版本不够也只能退回老路。
02
方案
三条路线的取舍
| 路线 | 优势与代价 | 结论 |
|---|---|---|
| UXP 插件桥接 | 功能最全、支持双向实时通信,最接近原生自动化;但硬性要求新版软件,依赖链长(服务进程 + 插件加载 + 版本匹配),任一环节不符就失败。 | 暂不采用 |
| 纯 COM 脚本 | 零额外依赖、全版本兼容、最稳定;但协议不标准,换一个 AI 客户端就得重写一遍。 | 作为底座 |
| MCP 协议层 + COM 底层 | 协议标准化,任何支持 MCP 的客户端都能接入;底层沿用已经被验证过的稳定通道。代价是多维护一层进程。 | 采用 |
最终架构
┌─────────────┐ MCP 协议 ┌──────────────────┐ COM 调用 ┌────────────────┐
│ AI 客户端 │ ────────────→ │ photoshop-mcp- │ ───────────→ │ Photoshop 2023 │
│ (对话/Agent)│ (stdio) │ server 0.1.11 │ (pywin32) │ v24.0.0.59 │
└─────────────┘ └──────────────────┘ └────────────────┘
│
└─ 复杂图形、批量逻辑走 ExtendScript 兜底
这个设计只有一个判断:协议层与执行层分离。MCP 负责「让 AI 能调用」,COM 负责「让调用真正生效」。将来换 AI 客户端、换对话界面,底层执行逻辑一行都不用重写。
关键技术选型
| 组件 | 选型 | 说明 |
|---|---|---|
| Photoshop | 2023(v24.0.0.59) | 由 2021 升级而来。既满足项目的版本要求,也为将来切换到 UXP 方案跨过了版本线。 |
| COM 驱动 | pywin32 | 绕开 PowerShell 的 COM 拦截,是 Windows 自动化的标准做法。 |
| MCP Server | photoshop-mcp-server 0.1.11 | Python 实现、纯 stdio 传输,不需要 Node 环境;安装必须走官方源(国内镜像缺这个包)。 |
| 图形补充 | ExtendScript | 原生工具覆盖不到的画圆、渐变、图层顺序调整,走脚本兜底。 |
| 运行环境 | Python 3.13 虚拟环境 | 依赖不外溢,不污染系统环境。 |
一个必须说清楚的区别
这里的 MCP 不等于 UXP 插件桥接。真正的 UXP 桥接要求更新版本的 Photoshop,本机的 2023 仍然不够。本项目用的是「MCP 协议外壳 + COM 执行内核」,这也正好解释了它为什么能同时做到协议标准化和旧版本兼容。
这条区别不是咬文嚼字。市面上有项目把 COM 封装包装成「UXP 后端」对外宣传,照着它的架构图做方案会直接踩空。
03
运行过程
整个过程分六个阶段,每个阶段都有明确的验证结果,前一个不通过就不进下一个。
阶段一 环境探测
先确认本机实际条件,避免基于假设做设计。
| 探测项 | 结果 |
|---|---|
| Photoshop 版本 | 2021(v22.0),后升级到 2023(v24.0.0.59) |
| COM 注册 | Photoshop.Application 已注册,全套 ProgID 可用 |
| UXP 目录 | 存在,Required\UXP 下有官方内置插件 |
| Node.js | v22.22.2,本轮方案未依赖 |
阶段二 COM 通道验证
这是整条链路的地基,必须先证明「能不能驱动」,再谈别的。
连接版本:24.0.0
文档创建:COM-Test (200×200) → 成功
文档关闭:成功
进程退出:成功
结论:这套安装包没有阉割 COM 接口,建文档、关文档、退出全部可用。地基成立。
阶段三 装 MCP Server
pip install photoshop-mcp-server # 官方源成功,国内镜像没有这个包
→ photoshop-mcp-server 0.1.11
→ 附带 mcp 1.30.0、photoshop-python-api 0.24.2
启动后注册成功 8 个工具,覆盖文档、图层、会话三大类。
阶段四 客户端配置
在客户端配置里注册一个 stdio 类型的服务条目:
{
"mcpServers": {
"photoshop": {
"command": "<python环境路径>\\Scripts\\photoshop-mcp-server.exe",
"args": []
}
}
}
两个配置要点:args 留空,因为这个服务启动即进入协议,没有子命令;不需要环境变量,底层会自动连当前注册的 Photoshop 实例。
阶段五 冒烟测试
验证协议层真的通了,而不是仅仅「进程起来了」。
| 测试项 | 结果 |
|---|---|
| MCP 握手 | 成功,协议版本 2024-11-05 |
| 工具注册数量 | 8 个 |
| 会话查询 | 返回 is_running: true、版本 24.0.0、构建号 24.0 (20221013.r.59) |
| 新建文档 | 成功创建 800×600 文档 |
| 新建文字层 | 成功 |
阶段六 端到端实战
拿一张 A4 苹果风格产品海报做真实业务验证:竖版 2480×3508(300 DPI),深色极简,要有背景、主视觉图形、标题文字和辅助信息。
| 环节 | 执行方式 | 结果 |
|---|---|---|
| 新建 A4 画布 | MCP 新建文档 | 成功 |
| 三个标题文字层 | MCP 新建文字层 | 成功 |
| 深色背景 + 双同心圆 | ExtendScript 兜底 | 成功 |
| 标签、卖点、版权文字 | ExtendScript 兜底 | 成功 |
| 导出 PNG | 带格式参数的保存 | 成功 |
成品做了像素级抽样,不是「看起来像那么回事」:
| 验证项 | 实测值 |
|---|---|
| 画布尺寸 | 2480 × 3508,符合 A4@300DPI |
| 背景色 | RGB(5, 5, 7) 深空黑 |
| 主视觉圆环 | 靛蓝色正常渲染 |
| 白色标题区 | 采样到 7 万余个白色像素点 |
| 灰色辅助文字 | 采样到 8000 多个灰色像素点 |
结论:全链路打通。AI 可以独立完成从建画布到导出成品的完整流程,中间不需要人回到 Photoshop 界面里补操作。
04
演示
目前没有录屏。这条链路的效果是「一句话之后,Photoshop 里自己多出几个图层」,录屏反而比截图更难说明发生了什么。
能拿出来的证据是那张 A4 海报本身:尺寸、配色、文字层级都是上面阶段六的实测数据产出的。等我把成品图和过程截图整理出来,会补在这一节。
还欠的演示:
- 批量处理:一次改一批图的尺寸和格式,这一块能力已经跑通,但没有做成可公开的样例。
- 对话式精修:边聊边改单张图,过程记录比结果更值得看。
- 一段完整录屏:从一句需求到导出文件,不加剪辑。
05
开发日志
下面这些是实际踩到的坑,按发现的顺序排。绝大多数不是「技术不会」,是环境和文档在骗人。
| # | 现象 | 根因 | 处置 |
|---|---|---|---|
| 1 | PowerShell 报「无法创建 COM 对象」 | 运行环境的安全层禁止实例化可执行任意代码的 COM 对象,提权也无效 | 改用 Python + pywin32,效果等同且更稳 |
| 2 | 装包时提示找不到 | 国内镜像源没有同步这个包 | 显式指定官方源 |
| 3 | 脚本报「doc 未定义」 | 原生调用不会自动注入 doc 变量,那是某个封装库的便利 | 改用显式的活动文档引用 |
| 4 | 报错码 -2147212704(命令不可用) | 混用了不兼容的调用封装 | 统一改回原生调用 |
| 5 | 导出文件后缀是 .png,实际却是 PSD | 保存时没指定格式,软件按默认的 PSD 存了 | 显式传入格式参数 |
| 6 | MCP 创建的文字层「消失」 | 后加的背景层压在图层栈顶,把文字盖住了 | 调用图层移动接口,把文字层提到背景之上 |
| 7 | 椭圆选区命令在旧版报错 | 旧版本不支持该指令 | 用 64 边形逼近正圆,视觉上无差别 |
| 8 | 段落文本满宽时不渲染 | 旧版在文本框贴满画布时存在渲染缺陷 | 改用点文本,再按图层包围盒手动算居中 |
| 9 | 读取文字包围盒返回空值 | 旧版该属性不可用 | 改读图层像素包围盒 |
| 10 | 命令行测试时响应丢失 | 单次喂数据后进程就退出了,响应被截断 | 属测试方式问题,改用常驻连接验证 |
四条值得记下来的认知
- 协议层与执行层必须解耦。MCP 解决「能否被统一调用」,COM 解决「调用能否落地」。把两者绑死,升级时会付出高昂代价。
- 不要轻信项目文档的架构描述。有项目宣称支持 UXP 后端,发行版实际是 COM 封装。判断依据应该是读源码,不是读 README。
- 版本升级要看「解锁了什么」。从 2021 升到 2023,价值不只是性能,而是跨过了一条版本线——它决定了将来能不能切到功能更完整的官方桥接。
- 工具的能力边界要提前摸清。8 个工具能建文档、加图层、写文字,但画圆、渐变、批量修图都没有对应工具。必须提前规划兜底路径,否则会在任务中途卡死。
最终成果
| 成果 | 内容 |
|---|---|
| 可用链路 | AI 对话 → MCP → COM → Photoshop 2023,全流程验证通过 |
| 工具能力 | 8 个标准化工具,覆盖文档、图层、会话查询 |
| 标准化程度 | 任何支持 MCP 协议的客户端都能接入 |
| 实战验证 | 完成 A4 商业海报全流程制作,像素级校验通过 |
| 可复用资产 | 完整接入指令文档、故障排查手册 |