開發(fā)者用Claude生成一張LinkedIn配圖，平均要經歷6個步驟、15分鐘、3個軟件切換。按每周15次計算，這是2.5小時的純機械勞動——而AI明明已經幫你寫好了完美的HTML。

這個痛點催生了Pixdom：一個能把任意HTML一鍵轉成平臺就緒圖片/動圖的CLI工具。作者用AI完成了全部開發(fā)，并公開了完整技術決策鏈。

從"截圖地獄"到一行命令

Claude生成的HTML往往帶著精致的CSS動畫和漸變，但開發(fā)者拿到后只能手動截圖、裁剪、轉格式。作者統(tǒng)計過自己的典型工作流：打開Chrome→啟動錄屏→等待動畫循環(huán)→停止錄制→導入Canva→修剪循環(huán)→導出GIF。6步，15分鐘，每次如此。

Pixdom的核心設計是消除這個斷層。pixdom convert --html "

Hello" --profile linkedin-post --output launch.jpg——單條命令完成渲染、裁剪、格式轉換全流程。

動圖處理更復雜。傳統(tǒng)工具要求用戶手動指定時長、幀率、分辨率，而Pixdom的--auto模式會解析CSS動畫本身：計算關鍵幀的最小公倍數(shù)確定循環(huán)周期，檢測緩動函數(shù)推斷幀率，最終輸出零冗余的GIF或MP4。

AI工程師的技術選型賬本

作者選擇Claude Code作為"主工程師"，但強調工具鏈的每個決策都經過刻意設計。渲染層用Playwright控制無頭瀏覽器，避免Puppeteer的內存泄漏問題；圖像處理棄用ImageMagick的臃腫依賴，改用Sharp的Node.js原生綁定；動畫捕獲不用FFmpeg的屏幕錄制方案，而是逐幀截圖合成，保證像素級精確。

最棘手的決策是MCP服務器架構。作者最初想做成純本地CLI，但發(fā)現(xiàn)Claude Desktop用戶更習慣通過MCP協(xié)議調用工具。最終采用雙模式設計：CLI保留完整功能，MCP服務器暴露精簡接口，兩者共享核心渲染引擎。

這個選擇帶來意外的維護成本。MCP協(xié)議當時仍在快速迭代，作者每周要跟進協(xié)議變更，同時保持CLI的向后兼容。「用AI寫代碼最大的幻覺是以為不用做架構決策了，」作者在復盤里寫道，「實際上你花更多時間在決策上，只是不寫實現(xiàn)細節(jié)而已?！?/p>

那些被AI埋掉的坑

開發(fā)日志里記錄了多次AI導致的方向性錯誤。Claude Code曾建議用Canvas API直接渲染HTML，省去瀏覽器開銷——作者花了4小時實現(xiàn)后才發(fā)現(xiàn)，Canvas不支持復雜的CSS動畫和字體回退，被迫回滾。

另一次，AI為MCP服務器生成了完美的TypeScript接口，卻忽略了stdio傳輸?shù)?4KB緩沖區(qū)限制。直到測試大體積HTML時才發(fā)現(xiàn)數(shù)據(jù)截斷，緊急改用流式分塊傳輸。

作者統(tǒng)計過：AI生成的代碼首次運行成功率約60%，但架構層面的建議需要人工驗證的比例超過80%。「它像一位語速極快、自信滿滿的初級工程師，你得學會在哪些問題上打斷它。」

產品化的最后1%

Pixdom的--profile系統(tǒng)預設了主流平臺的規(guī)格參數(shù)：LinkedIn文章的1200×627、Twitter卡片的800×418、Instagram方圖的1080×1080。作者發(fā)現(xiàn)這個設計來自自己的真實使用場景——每次手動查文檔找尺寸是另一種隱性摩擦。

但profile系統(tǒng)的實現(xiàn)曾讓AI陷入困境。Claude Code試圖用JSON Schema做配置驗證，代碼正確但用戶體驗糟糕：報錯信息指向Schema路徑而非人類可讀的平臺名稱。作者最終手工重寫了錯誤提示層，這是全項目少數(shù)完全手寫而非AI生成的模塊。

工具現(xiàn)已開源。作者在GitHub Issues里回復用戶提問時，會標注哪些回答來自AI生成、哪些經過人工編輯——這個習慣本身成了產品透明度的注腳。

當AI能完成從需求分析到部署上線的全流程，開發(fā)者的核心技能是否正在從"寫代碼"轉向"審代碼"？你最近一次完全信任AI的架構建議，結果如何？