1. 为什么 AI 生成的设计稿总是“看起来能用改起来崩溃”先说一个我踩过的坑。早几年做运营物料用文生图工具出了一张活动海报视觉上挺唬人丢进设计软件准备改个标题字号结果整张图就是一块位图文字是像素、形状是像素、连背景渐变都是像素。想改只能重新生成或者拿钢笔工具一点点抠。这种流程适合做灵感草图但一旦进入正式项目设计师要的是可选择的文字、可编辑的矢量形状、分层的图层结构而不是一张“死图”。这就是 Codex 搭配 Affinity 这套组合想解决的核心问题。Codex 负责理解自然语言指令、编排脚本、校验结果Affinity 负责真正把文字、形状、图层落到文档里产出可继续编辑的原生对象。中间靠 MCPModel Context Protocol把两边连起来。你描述“做一张 600×240 的横版店招主标题用思源黑体副标题小一号”Codex 不是去画一张图而是调用 Affinity 的脚本接口在文档里创建真实的文本对象和矩形图层最后渲染画布做视觉验收。适合谁三类人最值得试。第一类是独立设计师或小团队预算有限、不想背订阅制软件的成本Affinity 个人版可以直接用Codex 环境里也跑不了盗版 Adobe 那套合规平替是刚需。第二类是做批量物料的人比如电商详情页、门店海报、社媒封面需要同一套版式反复换文案换尺寸可编辑图层意味着改一个字段就能复用。第三类是愿意折腾工作流的开发者想把 AI 真正嵌进设计生产链路而不是停在“生成一张图”的玩具阶段。关键词先摆在这Codex 搭配 Affinity、Codex 平替 PS、不用 Photoshop 接入 Codex、Affinity 替代 Illustrator InDesign、Codex 禁止盗版软件、Affinity 免费版适配 Codex。这些不是堆词而是这套方案真实的检索入口。下面从架构、配置、验证到排错一步步给你能直接复制的操作。2. TaoToken 统一 Key 接入给 Codex 一条稳定的 API 通道Codex 要干活得先有模型能力。这里我用 TaoToken 做统一 Key 接入原因是它把模型调用收敛成一个 Base URL 加一个 Key配置一次Codex、Cline、Claude Code 这些工具都能复用不用每个工具单独去配一套凭证。官网入口在 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end API 地址是 https://taotoken.net/api 注意 API 这条不带 UTM 参数配置里填干净的地址就行。先说清楚三个必须对齐的字段这是后面所有配置的基础缺一个都会报错字段值说明Base URLhttps://taotoken.net/api所有请求的根地址不要带多余路径API Key在控制台生成形如 sk- 开头的一串只显示一次务必存好Model ID按需选择编码类任务选对应模型填错会 404获取 Key 的路径打开 https://taotoken.net/api-keys 登录后在控制台创建新的 API Key复制保存。这个 Key 就是你的通行证别贴到公开仓库里。如果你还没决定用哪个模型可以先去模型对话页面 https://taotoken.net/model-chat 试几句确认响应正常再写进配置。Codex 侧的配置核心是让它知道去哪里请求。以常见的 settings 风格配置为例路径和字段要对齐{ provider: taotoken, baseUrl: https://taotoken.net/api, apiKey: sk-你的Key粘贴在这里, model: 你的ModelID, timeout: 120000 }如果你用的是 Codex 的 auth.json 体系写法类似把 baseUrl、apiKey、model 三个字段填全{ baseUrl: https://taotoken.net/api, apiKey: sk-你的Key粘贴在这里, model: 你的ModelID }这里有个细节很多人忽略Base URL 结尾不要加/v1或/chat/completionsTaoToken 的网关会自己路由你多写一段反而 404。我实测下来把地址写干净、Key 写对、Model ID 写准这三件事做好90% 的接入问题都不会出现。配置完成后建议先用一次最小请求验证通道别急着上 MCP。你可以直接在 Codex 里发一句“回复 ok 两个字”如果模型正常返回说明 Key 和地址通了。这一步过了再去接 Affinity 的 MCP排错范围就小很多。长期做编码和 Agent 任务的话可以考虑 Coding Plan额度更稳适合高频调用场景入口在 https://taotoken.net/coding-plan 。3. Affinity Personal 插件与 MCP 配置把 Codex 接到本机 Affinity这一节是整套工作流的核心。Affinity 桌面应用启用 MCP Server 后会在本机开一个 SSE 服务默认地址是http://localhost:6767/sse。Codex 用的是标准输入输出stdio的 MCP 通信两边协议不一样所以需要一个代理层把 stdio 转成本机 SSE。这个代理就是 affinity-personal 插件它跑在 Codex 一侧负责连接、能力发现、重连、错误规范化和安全元数据。架构链路是这样的你在 Codex 里下指令Codex 通过 stdio 调 affinity-personal代理再通过本机 SSE 连到 Affinity 桌面应用的 MCP 服务最终由 Affinity 执行脚本、创建图层、渲染画布。要区分两层Affinity 内置的 MCP 服务属于桌面应用本身真正执行设计操作affinity-personal 是个人开发的 Codex 插件只做连接和管控不修改 Affinity 内部服务也不绕过它的许可和权限。插件源码目录我放在C:\Users\love\plugins\affinity-personal个人市场配置在C:\Users\love\.agents\plugins\marketplace.json。首次使用前按顺序做这几件事启动兼容版本的 Affinity打开 Affinity 设置启用 MCP Server在 Codex 的个人插件市场安装 affinity-personal新建一个 Codex 任务让插件和技能被完整加载。MCP 配置片段可以直接参考这个结构路径和字段按你本机实际情况对齐{ mcpServers: { affinity-personal: { command: node, args: [ C:\\Users\\love\\plugins\\affinity-personal\\scripts\\affinity-personal.mjs ], env: { AFFINITY_MCP_URL: http://localhost:6767/sse } } } }如果你用的是 TOML 风格的配置等价写法是[mcp_servers.affinity-personal] command node args [C:\\Users\\love\\plugins\\affinity-personal\\scripts\\affinity-personal.mjs] [mcp_servers.affinity-personal.env] AFFINITY_MCP_URL http://localhost:6767/sse配置里三个关键点command 指向 nodeargs 指向代理脚本的绝对路径env 里的 AFFINITY_MCP_URL 指向本机 SSE 地址。路径里的反斜杠在 JSON 里要转义成双反斜杠这是 Windows 下最常见的配置错误之一。装好后先别急着做设计任务用一句只读指令检查连接affinity-personal 检查当前 MCP 状态列出实时工具但不要修改文档。正常的话代理会返回连接地址、连接建立时间、SDK preamble 是否加载、重连次数、已转发调用次数以及 Affinity 当前暴露的工具清单。我实测下来一个健康的会话里能动态发现 11 个上游工具包括 execute_script、render_spread、render_selection、SDK 文档读取、脚本库读写等。如果工具列表是空的说明 SSE 没连上先回去检查 Affinity 的 MCP Server 有没有真的启用。4. 一次完整的设计稿生成与图层校验600×240 横版海报配置通了来跑一次真实任务。目标很明确在 Affinity 中创建一张 600×240 px 的横版海报横版和尺寸是硬性约束创建后要读取实际画布尺寸并验证宽度大于高度不符合就修正最后用 render_spread 渲染完整画布确认无遮挡再报告完成。指令可以这样写在 Affinity 中创建一张 600 × 240 px 的横版海报。 横版和尺寸是硬性约束。 创建后读取实际画布尺寸并验证宽度大于高度不符合就修正。 使用 render_spread 渲染完整画布确认内容无遮挡后再报告完成。 除非我明确确认不要覆盖已有文件。Codex 接到指令后会先读取 Affinity 的 SDK preamble确认当前版本的导入规则和参数范围然后调用 execute_script 执行脚本。这里有个关键细节Affinity SDK 的类不是默认全局变量必须显式导入。正确写法是这样const { Document } require(/document); const doc Document.current; console.log(JSON.stringify({ hasDocument: !!doc, sessionUuid: doc ? doc.sessionUuid : null }));脚本的结果要通过console.log()输出只在代码末尾写 return 并不是可靠的结果通道这是我早期调试时踩过的坑。创建文档后代理会重新读取实际尺寸做方向判断横版要求 actualWidth actualHeight竖版相反方形相等。对于 600×240最低验收条件是 actualWidth 等于 600、actualHeight 等于 240、且 actualWidth 大于 actualHeight三个条件同时满足才算过。验证通过后调用 render_spread 渲染完整画布。这一步很重要因为桌面截图可能被设置窗口、导出窗口或进度提示遮挡MCP 渲染拿到的是干净的文档内容更适合做最终视觉验收。桌面截图仍然有用但它主要用来判断有没有窗口遮挡、当前在哪个文档标签、Affinity 是否处于等待状态不能替代干净渲染。整个流程走完你得到的不是一张位图而是由 Affinity 原生对象组成的设计文字是可编辑的文本对象形状是矢量图层尺寸和方向都经过实际读取校验。这才是“AI 进入可编辑设计工作流”的真正含义。如果任务报告说“已创建横版画布”但 Affinity 里实际显示的是竖版那说明脚本虽然运行了但结果没被验证——这正是很多 AI 设计工具的通病把“执行过”当成“完成了”。5. 常见报错排查401、local proxy failed、reading choices、OAuth接入过程里最容易卡住的几个报错我按真实遇到的情况整理一下对照着查能省不少时间。401 Unauthorized几乎都是 Key 的问题。先确认 API Key 有没有复制完整sk- 开头那串有没有漏字符再确认 Base URL 是不是https://taotoken.net/api结尾有没有多加/v1。如果 Key 是在控制台刚生成的确认没有把旧 Key 填进去。还有一种情况是 Key 被撤销了去 https://taotoken.net/api-keys 重新生成一个换上。local proxy failed / 连接被拒绝这是 MCP 代理层的问题不是模型的问题。先确认 Affinity 桌面应用已经启动并且设置里 MCP Server 是启用状态再确认http://localhost:6767/sse这个地址在你本机能访问端口没被别的程序占用。如果 Affinity 重启过旧连接会失效用 affinity_personal_reconnect 主动释放旧连接并重新发现工具。代理本身也会在普通调用失败后做一次受控的自动重连短暂断线不至于让整个任务失败。reading choices / 响应解析异常这类报错通常出现在模型返回结构不符合预期时。检查 Model ID 有没有填错填了一个不存在的模型会直接 404 或返回异常结构。另外确认请求没有超时复杂脚本任务耗时较长timeout 设得太短会被截断。我一般把 timeout 设到 120000 毫秒给足执行时间。OAuth / 认证流程卡住如果你用的是需要 OAuth 的工具链确认回调地址和凭证配置一致。TaoToken 的 API Key 模式不需要走 OAuth直接填 Key 就行如果你在配置里混用了两套认证方式反而会冲突。把 OAuth 相关字段清掉只留 baseUrl、apiKey、model 三件套。ReferenceError: Document is not defined这是 Affinity 脚本层面的错误不是网络问题。原因就是前面说的SDK 类没有显式导入。检查脚本开头有没有const { Document } require(/document);。另外注意Affinity 上游有时会返回这类错误但 MCP 结果未必同时设置 isError: true如果代理只检查状态字段Codex 可能把失败脚本当成成功继续执行。affinity-personal 会识别 ReferenceError、TypeError、SyntaxError、RangeError、普通 Error 和 NOT_ALLOWED 这些失败信号把结果规范化为真正的 MCP 错误。遇到 NOT_ALLOWED通常意味着 Affinity 设置限制了文件、网络或 AI 权限尊重权限配置别想着绕过。排错时记住一个原则先分层再定位。模型层的问题看 401 和 Model ID代理层的问题看 local proxy failed 和端口脚本层的问题看 ReferenceError 和导入写法。三层分开查比一股脑改配置高效得多。接入文档在 https://taotoken.net/doc 遇到不确定的字段先去对一遍。6. 把 AI 真正嵌进设计流程从一次性生成到可复用脚本跑通一次任务只是开始这套工作流真正的价值在于可复用。Affinity 的脚本库支持列出本地脚本、读取已有脚本、在用户确认后保存新的可复用脚本。这意味着一次成功的设计操作可以被整理成长期使用的工具下次换文案换尺寸直接调脚本不用重新生成一遍。比如你做完那张 600×240 的店招可以把创建文档、设置尺寸、添加文本图层这套动作保存成脚本。下次要做 800×320 的版本改几个参数就行。Codex 侧的能力发现是动态的每次连接都从 Affinity 读取当前工具清单Affinity 更新工具后插件不依赖过期的硬编码列表这点比写死工具列表的方案省心。安全边界也要说清楚。affinity-personal 给工具补了行为分类只读本地操作包括读取 SDK 文档、列出和读取本地脚本、渲染画布、渲染选区、查询连接状态可能修改文档或本地状态的操作包括执行任意 Affinity 脚本、保存脚本到脚本库涉及外部系统的操作包括搜索共享 SDK 提示、添加共享提示、报告 SDK 问题。后两类会向本机以外发送信息除非你明确要求否则不应自动提交。这种分类帮 Codex 判断什么时候需要你确认避免它在你不注意的时候写入或外发。迭代插件时也有讲究。不要直接改个人市场配置来制造刷新正确流程是修改代理或技能说明检查 JavaScript 语法在 Affinity MCP 开启时运行能力审计验证 Codex 插件清单和技能清单用 cachebuster 更新脚本从个人市场刷新插件新建 Codex 任务测试。核心文件包括scripts/affinity-personal.mjs、scripts/smoke-test.mjs、scripts/capability-audit.mjs和skills/affinity-personal/SKILL.md。能力审计至少覆盖连接、工具发现、preamble、SDK 文档、脚本库读取、只读脚本执行、文档会话 UUID、完整画布渲染、选区渲染、主动重连、脚本错误规范化、插件与技能清单验证这些项。最后给一个实用建议测试时别为了图快就随意提交 SDK 问题、上传共享提示、覆盖用户文档或往脚本库写垃圾脚本。确认工具结构和实际执行写入操作是两件不同的事前者只读后者会改状态。把只读验证和写入操作分开做你的工作流会稳很多。需要长期跑编码和 Agent 任务的话Coding Plan 的额度更适合高频场景入口在 https://taotoken.net/coding-plan 模型对话验证在 https://taotoken.net/model-chat Key 管理在 https://taotoken.net/api-keys 接入文档在 https://taotoken.net/doc 。