1. 为什么 AI 生成的设计稿总是“看起来能用，改起来崩溃”

先说一个我踩过的坑。早几年做运营物料，用文生图工具出了一张活动海报，视觉上挺唬人，丢进设计软件准备改个标题字号，结果整张图就是一块位图，文字是像素、形状是像素、连背景渐变都是像素。想改？只能重新生成，或者拿钢笔工具一点点抠。这种流程适合做灵感草图，但一旦进入正式项目，设计师要的是可选择的文字、可编辑的矢量形状、分层的图层结构，而不是一张“死图”。

这就是 Codex 搭配 Affinity 这套组合想解决的核心问题。Codex 负责理解自然语言指令、编排脚本、校验结果；Affinity 负责真正把文字、形状、图层落到文档里，产出可继续编辑的原生对象。中间靠 MCP（Model 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_source=taotoken_aicg_blog_end ，API 地址是 https://taotoken.net/api ，注意 API 这条不带 UTM 参数，配置里填干净的地址就行。

先说清楚三个必须对齐的字段，这是后面所有配置的基础，缺一个都会报错：

获取 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/completions，TaoToken 的网关会自己路由，你多写一段反而 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 指向 node，args 指向代理脚本的绝对路径，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 。