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