1. 為什么 AI 生成的設(shè)計(jì)稿總是“看起來能用改起來崩潰”先說一個(gè)我踩過的坑。早幾年做運(yùn)營物料用文生圖工具出了一張活動(dòng)海報(bào)視覺上挺唬人丟進(jìn)設(shè)計(jì)軟件準(zhǔn)備改個(gè)標(biāo)題字號(hào)結(jié)果整張圖就是一塊位圖文字是像素、形狀是像素、連背景漸變都是像素。想改只能重新生成或者拿鋼筆工具一點(diǎn)點(diǎn)摳。這種流程適合做靈感草圖但一旦進(jìn)入正式項(xiàng)目設(shè)計(jì)師要的是可選擇的文字、可編輯的矢量形狀、分層的圖層結(jié)構(gòu)而不是一張“死圖”。這就是 Codex 搭配 Affinity 這套組合想解決的核心問題。Codex 負(fù)責(zé)理解自然語言指令、編排腳本、校驗(yàn)結(jié)果Affinity 負(fù)責(zé)真正把文字、形狀、圖層落到文檔里產(chǎn)出可繼續(xù)編輯的原生對象。中間靠 MCPModel Context Protocol把兩邊連起來。你描述“做一張 600×240 的橫版店招主標(biāo)題用思源黑體副標(biāo)題小一號(hào)”Codex 不是去畫一張圖而是調(diào)用 Affinity 的腳本接口在文檔里創(chuàng)建真實(shí)的文本對象和矩形圖層最后渲染畫布做視覺驗(yàn)收。適合誰三類人最值得試。第一類是獨(dú)立設(shè)計(jì)師或小團(tuán)隊(duì)預(yù)算有限、不想背訂閱制軟件的成本Affinity 個(gè)人版可以直接用Codex 環(huán)境里也跑不了盜版 Adobe 那套合規(guī)平替是剛需。第二類是做批量物料的人比如電商詳情頁、門店海報(bào)、社媒封面需要同一套版式反復(fù)換文案換尺寸可編輯圖層意味著改一個(gè)字段就能復(fù)用。第三類是愿意折騰工作流的開發(fā)者想把 AI 真正嵌進(jìn)設(shè)計(jì)生產(chǎn)鏈路而不是停在“生成一張圖”的玩具階段。關(guān)鍵詞先擺在這Codex 搭配 Affinity、Codex 平替 PS、不用 Photoshop 接入 Codex、Affinity 替代 Illustrator InDesign、Codex 禁止盜版軟件、Affinity 免費(fèi)版適配 Codex。這些不是堆詞而是這套方案真實(shí)的檢索入口。下面從架構(gòu)、配置、驗(yàn)證到排錯(cuò)一步步給你能直接復(fù)制的操作。2. TaoToken 統(tǒng)一 Key 接入給 Codex 一條穩(wěn)定的 API 通道Codex 要干活得先有模型能力。這里我用 TaoToken 做統(tǒng)一 Key 接入原因是它把模型調(diào)用收斂成一個(gè) Base URL 加一個(gè) Key配置一次Codex、Cline、Claude Code 這些工具都能復(fù)用不用每個(gè)工具單獨(dú)去配一套憑證。官網(wǎng)入口在 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end API 地址是 https://taotoken.net/api 注意 API 這條不帶 UTM 參數(shù)配置里填干凈的地址就行。先說清楚三個(gè)必須對齊的字段這是后面所有配置的基礎(chǔ)缺一個(gè)都會(huì)報(bào)錯(cuò)字段值說明Base URLhttps://taotoken.net/api所有請求的根地址不要帶多余路徑API Key在控制臺(tái)生成形如 sk- 開頭的一串只顯示一次務(wù)必存好Model ID按需選擇編碼類任務(wù)選對應(yīng)模型填錯(cuò)會(huì) 404獲取 Key 的路徑打開 https://taotoken.net/api-keys 登錄后在控制臺(tái)創(chuàng)建新的 API Key復(fù)制保存。這個(gè) Key 就是你的通行證別貼到公開倉庫里。如果你還沒決定用哪個(gè)模型可以先去模型對話頁面 https://taotoken.net/model-chat 試幾句確認(rèn)響應(yīng)正常再寫進(jìn)配置。Codex 側(cè)的配置核心是讓它知道去哪里請求。以常見的 settings 風(fēng)格配置為例路徑和字段要對齊{ provider: taotoken, baseUrl: https://taotoken.net/api, apiKey: sk-你的Key粘貼在這里, model: 你的ModelID, timeout: 120000 }如果你用的是 Codex 的 auth.json 體系寫法類似把 baseUrl、apiKey、model 三個(gè)字段填全{ baseUrl: https://taotoken.net/api, apiKey: sk-你的Key粘貼在這里, model: 你的ModelID }這里有個(gè)細(xì)節(jié)很多人忽略Base URL 結(jié)尾不要加/v1或/chat/completionsTaoToken 的網(wǎng)關(guān)會(huì)自己路由你多寫一段反而 404。我實(shí)測下來把地址寫干凈、Key 寫對、Model ID 寫準(zhǔn)這三件事做好90% 的接入問題都不會(huì)出現(xiàn)。配置完成后建議先用一次最小請求驗(yàn)證通道別急著上 MCP。你可以直接在 Codex 里發(fā)一句“回復(fù) ok 兩個(gè)字”如果模型正常返回說明 Key 和地址通了。這一步過了再去接 Affinity 的 MCP排錯(cuò)范圍就小很多。長期做編碼和 Agent 任務(wù)的話可以考慮 Coding Plan額度更穩(wěn)適合高頻調(diào)用場景入口在 https://taotoken.net/coding-plan 。3. Affinity Personal 插件與 MCP 配置把 Codex 接到本機(jī) Affinity這一節(jié)是整套工作流的核心。Affinity 桌面應(yīng)用啟用 MCP Server 后會(huì)在本機(jī)開一個(gè) SSE 服務(wù)默認(rèn)地址是http://localhost:6767/sse。Codex 用的是標(biāo)準(zhǔn)輸入輸出stdio的 MCP 通信兩邊協(xié)議不一樣所以需要一個(gè)代理層把 stdio 轉(zhuǎn)成本機(jī) SSE。這個(gè)代理就是 affinity-personal 插件它跑在 Codex 一側(cè)負(fù)責(zé)連接、能力發(fā)現(xiàn)、重連、錯(cuò)誤規(guī)范化和安全元數(shù)據(jù)。架構(gòu)鏈路是這樣的你在 Codex 里下指令Codex 通過 stdio 調(diào) affinity-personal代理再通過本機(jī) SSE 連到 Affinity 桌面應(yīng)用的 MCP 服務(wù)最終由 Affinity 執(zhí)行腳本、創(chuàng)建圖層、渲染畫布。要區(qū)分兩層Affinity 內(nèi)置的 MCP 服務(wù)屬于桌面應(yīng)用本身真正執(zhí)行設(shè)計(jì)操作affinity-personal 是個(gè)人開發(fā)的 Codex 插件只做連接和管控不修改 Affinity 內(nèi)部服務(wù)也不繞過它的許可和權(quán)限。插件源碼目錄我放在C:\Users\love\plugins\affinity-personal個(gè)人市場配置在C:\Users\love\.agents\plugins\marketplace.json。首次使用前按順序做這幾件事啟動(dòng)兼容版本的 Affinity打開 Affinity 設(shè)置啟用 MCP Server在 Codex 的個(gè)人插件市場安裝 affinity-personal新建一個(gè) Codex 任務(wù)讓插件和技能被完整加載。MCP 配置片段可以直接參考這個(gè)結(jié)構(gòu)路徑和字段按你本機(jī)實(shí)際情況對齊{ 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 風(fēng)格的配置等價(jià)寫法是[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配置里三個(gè)關(guān)鍵點(diǎn)command 指向 nodeargs 指向代理腳本的絕對路徑env 里的 AFFINITY_MCP_URL 指向本機(jī) SSE 地址。路徑里的反斜杠在 JSON 里要轉(zhuǎn)義成雙反斜杠這是 Windows 下最常見的配置錯(cuò)誤之一。裝好后先別急著做設(shè)計(jì)任務(wù)用一句只讀指令檢查連接affinity-personal 檢查當(dāng)前 MCP 狀態(tài)列出實(shí)時(shí)工具但不要修改文檔。正常的話代理會(huì)返回連接地址、連接建立時(shí)間、SDK preamble 是否加載、重連次數(shù)、已轉(zhuǎn)發(fā)調(diào)用次數(shù)以及 Affinity 當(dāng)前暴露的工具清單。我實(shí)測下來一個(gè)健康的會(huì)話里能動(dòng)態(tài)發(fā)現(xiàn) 11 個(gè)上游工具包括 execute_script、render_spread、render_selection、SDK 文檔讀取、腳本庫讀寫等。如果工具列表是空的說明 SSE 沒連上先回去檢查 Affinity 的 MCP Server 有沒有真的啟用。4. 一次完整的設(shè)計(jì)稿生成與圖層校驗(yàn)600×240 橫版海報(bào)配置通了來跑一次真實(shí)任務(wù)。目標(biāo)很明確在 Affinity 中創(chuàng)建一張 600×240 px 的橫版海報(bào)橫版和尺寸是硬性約束創(chuàng)建后要讀取實(shí)際畫布尺寸并驗(yàn)證寬度大于高度不符合就修正最后用 render_spread 渲染完整畫布確認(rèn)無遮擋再報(bào)告完成。指令可以這樣寫在 Affinity 中創(chuàng)建一張 600 × 240 px 的橫版海報(bào)。 橫版和尺寸是硬性約束。 創(chuàng)建后讀取實(shí)際畫布尺寸并驗(yàn)證寬度大于高度不符合就修正。 使用 render_spread 渲染完整畫布確認(rèn)內(nèi)容無遮擋后再報(bào)告完成。 除非我明確確認(rèn)不要覆蓋已有文件。Codex 接到指令后會(huì)先讀取 Affinity 的 SDK preamble確認(rèn)當(dāng)前版本的導(dǎo)入規(guī)則和參數(shù)范圍然后調(diào)用 execute_script 執(zhí)行腳本。這里有個(gè)關(guān)鍵細(xì)節(jié)Affinity SDK 的類不是默認(rèn)全局變量必須顯式導(dǎo)入。正確寫法是這樣const { Document } require(/document); const doc Document.current; console.log(JSON.stringify({ hasDocument: !!doc, sessionUuid: doc ? doc.sessionUuid : null }));腳本的結(jié)果要通過console.log()輸出只在代碼末尾寫 return 并不是可靠的結(jié)果通道這是我早期調(diào)試時(shí)踩過的坑。創(chuàng)建文檔后代理會(huì)重新讀取實(shí)際尺寸做方向判斷橫版要求 actualWidth actualHeight豎版相反方形相等。對于 600×240最低驗(yàn)收條件是 actualWidth 等于 600、actualHeight 等于 240、且 actualWidth 大于 actualHeight三個(gè)條件同時(shí)滿足才算過。驗(yàn)證通過后調(diào)用 render_spread 渲染完整畫布。這一步很重要因?yàn)樽烂娼貓D可能被設(shè)置窗口、導(dǎo)出窗口或進(jìn)度提示遮擋MCP 渲染拿到的是干凈的文檔內(nèi)容更適合做最終視覺驗(yàn)收。桌面截圖仍然有用但它主要用來判斷有沒有窗口遮擋、當(dāng)前在哪個(gè)文檔標(biāo)簽、Affinity 是否處于等待狀態(tài)不能替代干凈渲染。整個(gè)流程走完你得到的不是一張位圖而是由 Affinity 原生對象組成的設(shè)計(jì)文字是可編輯的文本對象形狀是矢量圖層尺寸和方向都經(jīng)過實(shí)際讀取校驗(yàn)。這才是“AI 進(jìn)入可編輯設(shè)計(jì)工作流”的真正含義。如果任務(wù)報(bào)告說“已創(chuàng)建橫版畫布”但 Affinity 里實(shí)際顯示的是豎版那說明腳本雖然運(yùn)行了但結(jié)果沒被驗(yàn)證——這正是很多 AI 設(shè)計(jì)工具的通病把“執(zhí)行過”當(dāng)成“完成了”。5. 常見報(bào)錯(cuò)排查401、local proxy failed、reading choices、OAuth接入過程里最容易卡住的幾個(gè)報(bào)錯(cuò)我按真實(shí)遇到的情況整理一下對照著查能省不少時(shí)間。401 Unauthorized幾乎都是 Key 的問題。先確認(rèn) API Key 有沒有復(fù)制完整sk- 開頭那串有沒有漏字符再確認(rèn) Base URL 是不是https://taotoken.net/api結(jié)尾有沒有多加/v1。如果 Key 是在控制臺(tái)剛生成的確認(rèn)沒有把舊 Key 填進(jìn)去。還有一種情況是 Key 被撤銷了去 https://taotoken.net/api-keys 重新生成一個(gè)換上。local proxy failed / 連接被拒絕這是 MCP 代理層的問題不是模型的問題。先確認(rèn) Affinity 桌面應(yīng)用已經(jīng)啟動(dòng)并且設(shè)置里 MCP Server 是啟用狀態(tài)再確認(rèn)http://localhost:6767/sse這個(gè)地址在你本機(jī)能訪問端口沒被別的程序占用。如果 Affinity 重啟過舊連接會(huì)失效用 affinity_personal_reconnect 主動(dòng)釋放舊連接并重新發(fā)現(xiàn)工具。代理本身也會(huì)在普通調(diào)用失敗后做一次受控的自動(dòng)重連短暫斷線不至于讓整個(gè)任務(wù)失敗。reading choices / 響應(yīng)解析異常這類報(bào)錯(cuò)通常出現(xiàn)在模型返回結(jié)構(gòu)不符合預(yù)期時(shí)。檢查 Model ID 有沒有填錯(cuò)填了一個(gè)不存在的模型會(huì)直接 404 或返回異常結(jié)構(gòu)。另外確認(rèn)請求沒有超時(shí)復(fù)雜腳本任務(wù)耗時(shí)較長timeout 設(shè)得太短會(huì)被截?cái)?。我一般?timeout 設(shè)到 120000 毫秒給足執(zhí)行時(shí)間。OAuth / 認(rèn)證流程卡住如果你用的是需要 OAuth 的工具鏈確認(rèn)回調(diào)地址和憑證配置一致。TaoToken 的 API Key 模式不需要走 OAuth直接填 Key 就行如果你在配置里混用了兩套認(rèn)證方式反而會(huì)沖突。把 OAuth 相關(guān)字段清掉只留 baseUrl、apiKey、model 三件套。ReferenceError: Document is not defined這是 Affinity 腳本層面的錯(cuò)誤不是網(wǎng)絡(luò)問題。原因就是前面說的SDK 類沒有顯式導(dǎo)入。檢查腳本開頭有沒有const { Document } require(/document);。另外注意Affinity 上游有時(shí)會(huì)返回這類錯(cuò)誤但 MCP 結(jié)果未必同時(shí)設(shè)置 isError: true如果代理只檢查狀態(tài)字段Codex 可能把失敗腳本當(dāng)成成功繼續(xù)執(zhí)行。affinity-personal 會(huì)識(shí)別 ReferenceError、TypeError、SyntaxError、RangeError、普通 Error 和 NOT_ALLOWED 這些失敗信號(hào)把結(jié)果規(guī)范化為真正的 MCP 錯(cuò)誤。遇到 NOT_ALLOWED通常意味著 Affinity 設(shè)置限制了文件、網(wǎng)絡(luò)或 AI 權(quán)限尊重權(quán)限配置別想著繞過。排錯(cuò)時(shí)記住一個(gè)原則先分層再定位。模型層的問題看 401 和 Model ID代理層的問題看 local proxy failed 和端口腳本層的問題看 ReferenceError 和導(dǎo)入寫法。三層分開查比一股腦改配置高效得多。接入文檔在 https://taotoken.net/doc 遇到不確定的字段先去對一遍。6. 把 AI 真正嵌進(jìn)設(shè)計(jì)流程從一次性生成到可復(fù)用腳本跑通一次任務(wù)只是開始這套工作流真正的價(jià)值在于可復(fù)用。Affinity 的腳本庫支持列出本地腳本、讀取已有腳本、在用戶確認(rèn)后保存新的可復(fù)用腳本。這意味著一次成功的設(shè)計(jì)操作可以被整理成長期使用的工具下次換文案換尺寸直接調(diào)腳本不用重新生成一遍。比如你做完那張 600×240 的店招可以把創(chuàng)建文檔、設(shè)置尺寸、添加文本圖層這套動(dòng)作保存成腳本。下次要做 800×320 的版本改幾個(gè)參數(shù)就行。Codex 側(cè)的能力發(fā)現(xiàn)是動(dòng)態(tài)的每次連接都從 Affinity 讀取當(dāng)前工具清單Affinity 更新工具后插件不依賴過期的硬編碼列表這點(diǎn)比寫死工具列表的方案省心。安全邊界也要說清楚。affinity-personal 給工具補(bǔ)了行為分類只讀本地操作包括讀取 SDK 文檔、列出和讀取本地腳本、渲染畫布、渲染選區(qū)、查詢連接狀態(tài)可能修改文檔或本地狀態(tài)的操作包括執(zhí)行任意 Affinity 腳本、保存腳本到腳本庫涉及外部系統(tǒng)的操作包括搜索共享 SDK 提示、添加共享提示、報(bào)告 SDK 問題。后兩類會(huì)向本機(jī)以外發(fā)送信息除非你明確要求否則不應(yīng)自動(dòng)提交。這種分類幫 Codex 判斷什么時(shí)候需要你確認(rèn)避免它在你不注意的時(shí)候?qū)懭牖蛲獍l(fā)。迭代插件時(shí)也有講究。不要直接改個(gè)人市場配置來制造刷新正確流程是修改代理或技能說明檢查 JavaScript 語法在 Affinity MCP 開啟時(shí)運(yùn)行能力審計(jì)驗(yàn)證 Codex 插件清單和技能清單用 cachebuster 更新腳本從個(gè)人市場刷新插件新建 Codex 任務(wù)測試。核心文件包括scripts/affinity-personal.mjs、scripts/smoke-test.mjs、scripts/capability-audit.mjs和skills/affinity-personal/SKILL.md。能力審計(jì)至少覆蓋連接、工具發(fā)現(xiàn)、preamble、SDK 文檔、腳本庫讀取、只讀腳本執(zhí)行、文檔會(huì)話 UUID、完整畫布渲染、選區(qū)渲染、主動(dòng)重連、腳本錯(cuò)誤規(guī)范化、插件與技能清單驗(yàn)證這些項(xiàng)。最后給一個(gè)實(shí)用建議測試時(shí)別為了圖快就隨意提交 SDK 問題、上傳共享提示、覆蓋用戶文檔或往腳本庫寫垃圾腳本。確認(rèn)工具結(jié)構(gòu)和實(shí)際執(zhí)行寫入操作是兩件不同的事前者只讀后者會(huì)改狀態(tài)。把只讀驗(yàn)證和寫入操作分開做你的工作流會(huì)穩(wěn)很多。需要長期跑編碼和 Agent 任務(wù)的話Coding Plan 的額度更適合高頻場景入口在 https://taotoken.net/coding-plan 模型對話驗(yàn)證在 https://taotoken.net/model-chat Key 管理在 https://taotoken.net/api-keys 接入文檔在 https://taotoken.net/doc 。