1. 項(xiàng)目緣起與核心定位1.1 一個(gè)被名字耽誤的效率工具第一次看到“impeccable”這個(gè)詞很多人會(huì)愣一下——這到底是個(gè)什么項(xiàng)目名字本身是“無可挑剔、完美無瑕”的意思聽起來像某個(gè)設(shè)計(jì)獎(jiǎng)或者高端品牌但它實(shí)際上是一個(gè)面向 AI coding agents 的前端設(shè)計(jì)增強(qiáng)工具。說白了它解決的是一個(gè)非常具體的痛點(diǎn)當(dāng)你用 Codex CLI、Claude Code 這類命令行 AI 編程助手生成前端代碼時(shí)出來的界面往往能用但不好看布局湊合、間距隨意、配色缺乏層次。impeccable 就是在這個(gè)環(huán)節(jié)介入把“能跑”的代碼提升到“能看”的水平。我最初接觸它是因?yàn)樵谟?codex cli 做快速原型時(shí)每次生成的前端頁面都需要手動(dòng)調(diào)整大量 CSS。一個(gè)登錄頁改半小時(shí)效率極低。impeccable 的出現(xiàn)讓我可以把精力放在業(yè)務(wù)邏輯上視覺層面的打磨交給它來處理。它不是一個(gè)獨(dú)立的編輯器也不是一個(gè)完整的 IDE 插件而是一個(gè)輕量級(jí)的 CLI 工具加瀏覽器擴(kuò)展的組合專門服務(wù)于 AI 編程工作流中的前端設(shè)計(jì)環(huán)節(jié)。1.2 它到底解決什么問題要理解 impeccable 的價(jià)值得先看清楚當(dāng)前 AI coding agents 在前端領(lǐng)域的短板。無論是 codex cli、zcode cli 還是其他命令行助手它們的強(qiáng)項(xiàng)在于邏輯生成、API 調(diào)用、數(shù)據(jù)結(jié)構(gòu)設(shè)計(jì)但前端設(shè)計(jì)涉及大量主觀審美判斷——留白多少合適、字體層級(jí)怎么分、顏色對(duì)比度夠不夠、響應(yīng)式斷點(diǎn)設(shè)在哪里。這些決策對(duì) AI 來說很難一次到位因?yàn)橛?xùn)練數(shù)據(jù)里的設(shè)計(jì)模式太分散了沒有一個(gè)統(tǒng)一的“好設(shè)計(jì)”標(biāo)準(zhǔn)。impeccable 的思路很直接它內(nèi)置了一套經(jīng)過驗(yàn)證的設(shè)計(jì)系統(tǒng)規(guī)則當(dāng) AI 生成前端代碼后impeccable 會(huì)掃描代碼中的樣式部分識(shí)別出常見的“AI 味”問題——比如所有元素都用默認(rèn)的 16px 字體、間距全是 8px 的倍數(shù)但缺乏節(jié)奏變化、顏色只用黑白灰、按鈕沒有 hover 狀態(tài)等。然后它給出具體的修改建議甚至直接生成補(bǔ)丁。你可以把它理解為一個(gè)專門針對(duì) AI 生成代碼的“設(shè)計(jì) lint 工具”但比傳統(tǒng) lint 更懂設(shè)計(jì)原則。1.3 適合誰用不適合誰用這個(gè)工具最適合兩類人一是用 codex cli 或類似工具做快速原型開發(fā)的獨(dú)立開發(fā)者你不需要精通 CSS 但希望產(chǎn)出看起來專業(yè)的界面二是前端團(tuán)隊(duì)里負(fù)責(zé)搭建 AI 輔助工作流的技術(shù)負(fù)責(zé)人你可以把 impeccable 集成到 CI 流程里確保 AI 生成的代碼在合并前經(jīng)過設(shè)計(jì)規(guī)范檢查。不適合的人群也很明確如果你本身就是資深前端設(shè)計(jì)師對(duì)每個(gè)像素都有精確控制欲impeccable 的建議可能會(huì)顯得多余甚至干擾你的判斷。另外如果你的項(xiàng)目已經(jīng)有成熟的設(shè)計(jì)系統(tǒng)比如 Ant Design、Material UI 的深度定制impeccable 的通用規(guī)則可能和你的品牌規(guī)范沖突這時(shí)候需要謹(jǐn)慎配置或者干脆不用。2. 核心機(jī)制與設(shè)計(jì)哲學(xué)拆解2.1 為什么選擇 CLI 瀏覽器擴(kuò)展的組合impeccable 的產(chǎn)品形態(tài)很有意思它沒有做成一個(gè)完整的 GUI 應(yīng)用而是拆成了 CLI 和瀏覽器擴(kuò)展兩個(gè)部分。這個(gè)選擇背后有很實(shí)際的考量。CLI 部分負(fù)責(zé)代碼層面的分析和修改它可以直接讀取你的項(xiàng)目文件理解組件結(jié)構(gòu)生成精確的代碼補(bǔ)丁。瀏覽器擴(kuò)展部分則負(fù)責(zé)運(yùn)行時(shí)驗(yàn)證——當(dāng)你在本地啟動(dòng)開發(fā)服務(wù)器后擴(kuò)展可以實(shí)時(shí)檢查渲染出來的頁面捕捉那些靜態(tài)分析發(fā)現(xiàn)不了的問題比如實(shí)際渲染后的對(duì)比度、元素重疊、響應(yīng)式斷點(diǎn)下的布局錯(cuò)亂。這種分工的好處是各司其職。CLI 不需要處理瀏覽器渲染的復(fù)雜性擴(kuò)展不需要理解代碼的抽象語法樹。兩者通過一個(gè)共享的配置文件通常是項(xiàng)目根目錄下的.impeccable.json來同步規(guī)則和狀態(tài)。我實(shí)測(cè)下來這種架構(gòu)比那些試圖把所有功能塞進(jìn)一個(gè)工具的方案要穩(wěn)定得多尤其是在大型項(xiàng)目里CLI 的掃描速度明顯快于純?yōu)g覽器方案。2.2 設(shè)計(jì)規(guī)則的來源與優(yōu)先級(jí)impeccable 內(nèi)置的設(shè)計(jì)規(guī)則不是拍腦袋想出來的它參考了幾個(gè)成熟的設(shè)計(jì)系統(tǒng)原則間距采用 4px 基準(zhǔn)網(wǎng)格但允許 8px 的節(jié)奏變化字體大小遵循 1.25 或 1.333 的模數(shù)比例顏色對(duì)比度至少滿足 WCAG AA 標(biāo)準(zhǔn)4.5:1 對(duì)于正文3:1 對(duì)于大文本。這些規(guī)則在配置文件里都有對(duì)應(yīng)的開關(guān)和閾值你可以根據(jù)項(xiàng)目需求調(diào)整。規(guī)則的優(yōu)先級(jí)設(shè)計(jì)也很講究。最高優(yōu)先級(jí)的是可訪問性問題比如對(duì)比度不足、缺少焦點(diǎn)狀態(tài)、觸摸目標(biāo)太小這些是硬性錯(cuò)誤必須修復(fù)。中等優(yōu)先級(jí)的是視覺一致性問題比如間距不統(tǒng)一、字體層級(jí)混亂、顏色使用過多。最低優(yōu)先級(jí)的是風(fēng)格建議比如“考慮使用更柔和的陰影”或“可以嘗試更大的圓角”這些只是提示不強(qiáng)制修改。這種分級(jí)讓工具在嚴(yán)格和靈活之間找到了平衡點(diǎn)不會(huì)因?yàn)檫^度干預(yù)而讓人煩躁。2.3 與 AI coding agents 的協(xié)作模式impeccable 和 codex cli 這類工具的協(xié)作方式有兩種。第一種是“事后檢查”模式你先用 codex cli 生成代碼然后運(yùn)行impeccable check命令它會(huì)輸出一份問題報(bào)告你根據(jù)報(bào)告手動(dòng)修改或者讓 AI 重新生成。第二種是“實(shí)時(shí)反饋”模式在 codex cli 的會(huì)話中你可以通過特定的命令調(diào)用 impeccable 的分析能力比如輸入/impeccable后跟文件路徑它會(huì)即時(shí)返回該文件的設(shè)計(jì)問題摘要你可以在同一個(gè)會(huì)話里讓 AI 直接修復(fù)。第二種模式效率更高但需要 codex cli 支持自定義命令擴(kuò)展。目前社區(qū)里已經(jīng)有人做了這樣的集成腳本原理是利用 codex cli 的插件機(jī)制把 impeccable 包裝成一個(gè)可調(diào)用的工具。如果你用的是其他 CLI 比如 zcode cli 或 minimax cli可能需要自己寫適配層但核心思路是一樣的把 impeccable 的分析結(jié)果作為上下文喂給 AI讓它基于具體問題來修改代碼。3. 從零開始的完整實(shí)操流程3.1 環(huán)境準(zhǔn)備與安裝避坑安裝 impeccable 本身不復(fù)雜但有幾個(gè)前置條件容易卡住人。首先你需要 Node.js 環(huán)境版本建議 18 以上因?yàn)?impeccable 用了一些較新的 ES 模塊特性。如果你之前裝過 codex cli 并且覺得“node安裝codex cli很慢”那大概率是網(wǎng)絡(luò)源的問題換用國(guó)內(nèi)鏡像源可以顯著提速。具體操作是在終端里執(zhí)行npm config set registry https://registry.npmmirror.com然后再安裝。impeccable 的安裝命令是npm install -g impeccable-cli全局安裝后你就可以在任何項(xiàng)目目錄下使用impeccable命令了。瀏覽器擴(kuò)展的安裝稍微麻煩一點(diǎn)因?yàn)樗壳皼]有上架 Chrome 應(yīng)用商店需要手動(dòng)加載。你需要在 impeccable 的 GitHub Releases 頁面下載最新的.crx文件然后在 Chrome 的擴(kuò)展管理頁面開啟“開發(fā)者模式”把.crx文件拖進(jìn)去。這個(gè)過程和安裝其他未上架擴(kuò)展是一樣的但要注意每次 Chrome 更新后可能需要重新加載。注意如果你在公司網(wǎng)絡(luò)環(huán)境下瀏覽器擴(kuò)展的下載可能會(huì)被攔截。建議提前把.crx文件下載到本地或者讓團(tuán)隊(duì)里的網(wǎng)絡(luò)管理員把相關(guān)域名加入白名單。3.2 項(xiàng)目初始化與配置詳解安裝完成后在你的項(xiàng)目根目錄下運(yùn)行impeccable init。這個(gè)命令會(huì)做三件事創(chuàng)建一個(gè).impeccable.json配置文件、在package.json里添加幾個(gè) npm scripts、生成一個(gè).impeccableignore文件類似.gitignore用來排除不需要檢查的目錄。配置文件是核心我拿一個(gè)實(shí)際項(xiàng)目的配置來舉例說明每個(gè)字段的含義{ rules: { accessibility: { contrastRatio: 4.5, focusVisible: true, touchTargetSize: 44 }, spacing: { baseUnit: 4, allowOddMultiples: false, maxScale: 12 }, typography: { scaleRatio: 1.25, maxFontSizes: 6, lineHeightMin: 1.4 }, color: { maxPaletteSize: 8, requireSemanticNames: true } }, ignore: [node_modules, dist, *.test.*], severity: { accessibility: error, spacing: warning, typography: warning, color: info } }contrastRatio設(shè)成 4.5 是 WCAG AA 的標(biāo)準(zhǔn)如果你面向的是對(duì)可訪問性要求更高的場(chǎng)景比如政府項(xiàng)目可以調(diào)到 7。baseUnit是間距的基準(zhǔn)單位4px 是比較通用的選擇但如果你用的是 Tailwind 的默認(rèn)配置可以改成 2 來對(duì)齊。maxPaletteSize限制顏色數(shù)量超過 8 種顏色就會(huì)報(bào)警這個(gè)閾值可以根據(jù)品牌規(guī)范調(diào)整。3.3 第一次運(yùn)行檢查與結(jié)果解讀配置好后運(yùn)行impeccable check ./src來掃描你的源代碼目錄。第一次運(yùn)行可能會(huì)輸出大量問題別慌這是正常的。輸出格式默認(rèn)是表格包含文件路徑、行號(hào)、問題類型、嚴(yán)重程度和具體描述。我建議第一次運(yùn)行時(shí)加上--summary參數(shù)只看匯總統(tǒng)計(jì)了解問題的分布情況。impeccable check ./src --summary輸出大概長(zhǎng)這樣Scanning 47 files... Accessibility: 12 errors, 8 warnings Spacing: 3 errors, 24 warnings Typography: 0 errors, 15 warnings Color: 2 errors, 6 warnings Top issues: 1. Insufficient contrast ratio (12 occurrences) 2. Inconsistent spacing multiples (18 occurrences) 3. Missing focus states (8 occurrences)從這份匯總里你能快速判斷項(xiàng)目的設(shè)計(jì)健康度。如果可訪問性錯(cuò)誤超過 10 個(gè)說明基礎(chǔ)問題比較多建議優(yōu)先修復(fù)。間距警告多通常是因?yàn)?AI 生成的代碼里混用了不同的間距值比如有的地方用 12px 有的用 14px雖然視覺上差別不大但累積起來會(huì)讓界面顯得不精致。3.4 與 codex cli 的聯(lián)動(dòng)實(shí)操這是 impeccable 最有價(jià)值的使用場(chǎng)景。假設(shè)你用 codex cli 生成了一個(gè) React 組件文件路徑是src/components/UserCard.tsx。在 codex cli 的交互會(huì)話中你可以這樣操作首先讓 codex cli 讀取 impeccable 的分析結(jié)果/impeccable analyze src/components/UserCard.tsx這個(gè)命令會(huì)觸發(fā) impeccable 對(duì)該文件的分析并把結(jié)果注入到當(dāng)前會(huì)話的上下文中。然后你可以直接對(duì) AI 說“根據(jù)上面的設(shè)計(jì)問題幫我修復(fù)這個(gè)組件。” codex cli 會(huì)結(jié)合 impeccable 的具體建議來修改代碼而不是盲目地重寫。我實(shí)測(cè)下來這種聯(lián)動(dòng)方式比讓 AI 自由發(fā)揮要精準(zhǔn)得多。比如 impeccable 指出“按鈕的 hover 狀態(tài)對(duì)比度只有 2.8:1低于 4.5:1 的標(biāo)準(zhǔn)”codex cli 就會(huì)針對(duì)性地調(diào)整 hover 顏色而不是把整個(gè)按鈕樣式推翻重來。修改后的代碼質(zhì)量明顯更高返工率大幅降低。提示如果你用的是 codex cli 的/compact命令來壓縮上下文注意 impeccable 的分析結(jié)果可能會(huì)被壓縮掉。建議在修復(fù)完一個(gè)問題后立即驗(yàn)證不要攢著一起改。4. 高頻問題排查與實(shí)戰(zhàn)經(jīng)驗(yàn)4.1 安裝與運(yùn)行階段的典型故障問題一impeccable命令找不到。這通常是因?yàn)?npm 全局安裝路徑?jīng)]有加到系統(tǒng)的 PATH 環(huán)境變量里。在 macOS 或 Linux 上你可以運(yùn)行npm config get prefix查看全局安裝路徑然后把這個(gè)路徑加到.bashrc或.zshrc里。Windows 用戶如果用的是 PowerShell需要檢查$env:PATH是否包含 npm 的全局目錄。問題二瀏覽器擴(kuò)展加載后不生效。先確認(rèn)擴(kuò)展圖標(biāo)是否出現(xiàn)在工具欄上如果出現(xiàn)了但點(diǎn)擊沒反應(yīng)可能是擴(kuò)展和 CLI 的版本不匹配。impeccable 的 CLI 和擴(kuò)展通過 WebSocket 通信版本差異會(huì)導(dǎo)致握手失敗。解決辦法是確保兩者都更新到最新版本或者查看擴(kuò)展的“背景頁”控制臺(tái)有沒有報(bào)錯(cuò)信息。問題三掃描速度極慢。如果你的項(xiàng)目有幾千個(gè)文件默認(rèn)的全量掃描會(huì)很耗時(shí)。這時(shí)候可以用--changed參數(shù)只掃描 Git 有變更的文件或者用--since指定時(shí)間范圍。另外.impeccableignore文件一定要配置好把node_modules、dist、coverage這些目錄排除掉能省下大量時(shí)間。4.2 設(shè)計(jì)規(guī)則沖突的處理策略實(shí)際項(xiàng)目里最常見的問題是 impeccable 的規(guī)則和現(xiàn)有設(shè)計(jì)系統(tǒng)沖突。比如你的項(xiàng)目用的是 Ant Design它的默認(rèn)間距是 8px 的倍數(shù)但 impeccable 的baseUnit設(shè)的是 4就會(huì)產(chǎn)生大量“間距不是 4 的倍數(shù)”的警告。這時(shí)候你有兩個(gè)選擇要么把baseUnit改成 8 來對(duì)齊 Ant Design要么在配置里把spacing的嚴(yán)重程度降到info讓它只提示不報(bào)錯(cuò)。另一個(gè)沖突場(chǎng)景是顏色。很多品牌有自己的一套色板可能包含 12 種以上的顏色但 impeccable 默認(rèn)的maxPaletteSize是 8。這時(shí)候不要硬改品牌色板而是把maxPaletteSize調(diào)大同時(shí)在配置里用colorAliases字段把品牌色映射到語義名稱上比如把#1E88E5映射為primary這樣 impeccable 就能理解你的顏色體系了。4.3 常見問題速查表問題現(xiàn)象可能原因排查步驟解決方案命令執(zhí)行后無輸出配置文件缺失或格式錯(cuò)誤檢查.impeccable.json是否存在且為合法 JSON運(yùn)行impeccable init重新生成擴(kuò)展連接超時(shí)端口被占用或防火墻攔截查看 CLI 啟動(dòng)時(shí)的端口號(hào)用lsof -i:端口檢查更換端口或關(guān)閉沖突進(jìn)程誤報(bào)大量間距問題項(xiàng)目使用了非 4px 基準(zhǔn)的設(shè)計(jì)系統(tǒng)查看警告詳情確認(rèn)實(shí)際間距值調(diào)整baseUnit或降低嚴(yán)重程度修復(fù)建議不生效AI 未正確讀取分析結(jié)果檢查 codex cli 會(huì)話中是否包含 impeccable 輸出重新執(zhí)行/impeccable analyze命令掃描時(shí)內(nèi)存溢出項(xiàng)目文件過多或存在大文件查看掃描日志定位大文件在.impeccableignore中排除大文件4.4 幾個(gè)讓我少走彎路的實(shí)操心得第一個(gè)心得是關(guān)于配置文件的版本管理。.impeccable.json應(yīng)該提交到 Git 倉庫里但每個(gè)人的本地環(huán)境可能不同比如有人用 4px 基準(zhǔn)有人用 8px。我的做法是在倉庫里放一個(gè)基礎(chǔ)配置然后在.gitignore里加上.impeccable.local.json允許每個(gè)人覆蓋部分規(guī)則。impeccable 會(huì)自動(dòng)合并這兩個(gè)文件本地配置優(yōu)先級(jí)更高。第二個(gè)心得是關(guān)于修復(fù)順序。不要試圖一次性修復(fù)所有問題那樣很容易改出新的問題。我的策略是按嚴(yán)重程度分批處理先修所有error級(jí)別的問題跑一遍測(cè)試確保功能沒壞再修warning級(jí)別里影響最大的幾類比如間距和字體層級(jí)最后有空再處理info級(jí)別的建議。這樣每批修改的范圍可控出問題也容易定位。第三個(gè)心得是關(guān)于和 AI 的協(xié)作節(jié)奏。用 codex cli 修復(fù) impeccable 問題時(shí)一次只讓它改一個(gè)文件或者一類問題。我試過讓 AI 一次性修復(fù)整個(gè)目錄的設(shè)計(jì)問題結(jié)果它改著改著就“放飛自我”了把一些原本沒問題的組件也重寫了。后來我改成每次只處理一個(gè)文件修完驗(yàn)證通過再處理下一個(gè)雖然慢一點(diǎn)但質(zhì)量穩(wěn)定得多。5. 進(jìn)階用法與工作流集成5.1 在 CI 流程中自動(dòng)檢查設(shè)計(jì)規(guī)范如果你帶團(tuán)隊(duì)可以把 impeccable 集成到 CI 流程里確保合并到主分支的代碼都符合設(shè)計(jì)規(guī)范。具體做法是在package.json里加一個(gè) script{ scripts: { design:check: impeccable check ./src --severity error --exit-code } }--exit-code參數(shù)讓 impeccable 在有 error 級(jí)別問題時(shí)返回非零退出碼這樣 CI 就會(huì)失敗。然后在 GitHub Actions 或 GitLab CI 的配置文件里加上這個(gè)步驟。注意只檢查error級(jí)別的問題warning和info不要阻塞流程否則開發(fā)者會(huì)瘋掉。5.2 自定義規(guī)則擴(kuò)展impeccable 支持通過插件機(jī)制添加自定義規(guī)則。比如你的團(tuán)隊(duì)規(guī)定所有卡片的圓角必須是 8px就可以寫一個(gè)簡(jiǎn)單的規(guī)則插件// impeccable-plugin-card-radius.js module.exports { name: card-radius, rules: [ { selector: .card, property: border-radius, expected: 8px, severity: warning, message: 卡片圓角應(yīng)為 8px當(dāng)前為 {{actual}} } ] };然后在配置文件里引用這個(gè)插件plugins: [./impeccable-plugin-card-radius.js]。這個(gè)機(jī)制讓 impeccable 可以適配各種團(tuán)隊(duì)規(guī)范而不局限于內(nèi)置的通用規(guī)則。5.3 與設(shè)計(jì)稿對(duì)比的工作流一個(gè)比較高級(jí)的用法是把 impeccable 和設(shè)計(jì)稿對(duì)比工具結(jié)合起來。比如你的設(shè)計(jì)師用 Figma 出了稿你可以導(dǎo)出設(shè)計(jì)稿的樣式數(shù)據(jù)間距、顏色、字體然后寫一個(gè)腳本把這些數(shù)據(jù)轉(zhuǎn)換成 impeccable 的自定義規(guī)則。這樣 impeccable 檢查代碼時(shí)實(shí)際上是在和設(shè)計(jì)稿做比對(duì)偏差超過閾值就報(bào)警。這個(gè)工作流我目前在兩個(gè)項(xiàng)目里試過效果很好尤其是設(shè)計(jì)稿頻繁更新的階段能快速發(fā)現(xiàn)代碼和設(shè)計(jì)脫節(jié)的地方。注意設(shè)計(jì)稿導(dǎo)出的數(shù)據(jù)格式各平臺(tái)不同F(xiàn)igma 可以用它的 REST API 獲取Sketch 需要借助第三方工具。轉(zhuǎn)換腳本需要根據(jù)你的設(shè)計(jì)工具來定制沒有通用方案。5.4 性能優(yōu)化與大型項(xiàng)目適配當(dāng)項(xiàng)目規(guī)模超過 500 個(gè)組件時(shí)impeccable 的全量掃描可能需要幾分鐘。除了前面提到的--changed參數(shù)還可以用--cache開啟緩存。impeccable 會(huì)把每個(gè)文件的掃描結(jié)果緩存到.impeccable-cache目錄里下次掃描時(shí)如果文件內(nèi)容沒變就直接用緩存。實(shí)測(cè)下來第二次掃描的速度能提升 80% 以上。另外如果你的項(xiàng)目是 monorepo 結(jié)構(gòu)建議在每個(gè)子包里單獨(dú)運(yùn)行 impeccable而不是在根目錄掃描整個(gè)倉庫。這樣可以并行執(zhí)行而且每個(gè)子包可以有獨(dú)立的配置。我試過在一個(gè)包含 6 個(gè)子包的 monorepo 里用這種方式總掃描時(shí)間從 4 分鐘降到了 50 秒左右。6. 我對(duì)這個(gè)工具的真實(shí)看法用了幾個(gè)月 impeccable 之后我的感受是它確實(shí)填補(bǔ)了一個(gè)空白但也不是銀彈。它最大的價(jià)值在于把“設(shè)計(jì)規(guī)范檢查”這件事從人工 review 里解放出來讓 AI 生成的代碼在合并前就經(jīng)過一輪自動(dòng)化篩選。尤其是對(duì)于獨(dú)立開發(fā)者和小團(tuán)隊(duì)沒有專職設(shè)計(jì)師的情況下impeccable 能幫你守住基本的設(shè)計(jì)底線。但它也有明顯的局限。首先它只能檢查可量化的設(shè)計(jì)問題比如間距、對(duì)比度、字體大小對(duì)于“這個(gè)布局是否合理”“這個(gè)交互是否流暢”這類需要整體判斷的問題它無能為力。其次它的規(guī)則是通用的如果你的項(xiàng)目有非常獨(dú)特的設(shè)計(jì)語言可能需要大量自定義配置才能讓它不誤報(bào)。最后它目前對(duì) Vue 和 Svelte 的支持不如 React 完善如果你用的是這兩個(gè)框架可能會(huì)遇到一些解析問題。我現(xiàn)在的用法是把它當(dāng)作一個(gè)“設(shè)計(jì)預(yù)檢”工具在 codex cli 生成代碼后跑一遍把明顯的低級(jí)問題修掉然后再人工過一遍整體效果。這樣既保證了效率又不會(huì)完全依賴工具的判斷。如果你也在用 AI 編程助手做前端開發(fā)我建議至少試一下 impeccable哪怕只是用它來發(fā)現(xiàn)那些你平時(shí)注意不到的細(xì)節(jié)問題也能讓你的產(chǎn)出質(zhì)量上一個(gè)臺(tái)階。