上一篇橫評里我留了 fireworks-tech-graph。這篇兌現(xiàn)承諾拿一個完整案例從一句大白話需求開始把評審要用的圖紙一張張畫出來。需求就一句話「跨境電商訂單履約買家下單→支付→風(fēng)控→海外倉發(fā)貨→清關(guān)→派送→簽收含退款分支。」不裝不是每張圖都一次成功。這篇文章的價值恰恰在翻車部分——我把每次報錯的原文和修法都留下來了你照著能少踩 80% 的坑。先說工作方式不是「生成即結(jié)束」這個 skill 和一般 AI 畫圖最大的區(qū)別它畫完會自己質(zhì)檢。布局交叉、間距不足、文字截斷直接報錯拒絕出圖而不是給你一張能看但經(jīng)不起評審的圖。所以真實工作回路是這樣的一句話需求 → 生成 → 幾何校驗報錯 → 按報錯修布局 → 再過 → 導(dǎo)出 PNG命令就一條主線render渲染 check校驗。下面每張圖我都走這個回路。圖一泳道流程圖——四輪報錯才過關(guān)主角圖五個角色五行泳道買家、電商平臺、海外倉、海關(guān)、物流。第一版直接被打回報錯原文EDGE_BEND_BUDGET:a342; EDGE_ROUTE_STRETCH:a31.9571.35翻譯成人話風(fēng)控審核→揀貨打包這條線拐了 4 個彎預(yù)算 2 個。原因是我把「訂單關(guān)閉」節(jié)點正好擺在它的垂直通道上線只能繞著走。修法把擋路的節(jié)點挪開。第二輪又報NODE_GAP:L1,L210.040.0兩個物流節(jié)點間距 10px最少 40px和BRIDGE_BUDGET:diagram20退款分支和主流程共用一個出口線壓線。第三輪把退款分支整體挪到右側(cè)、拉開間距最后第四輪全綠這張圖的教訓(xùn)沉淀成一條規(guī)律畫之前先給「回頭的線」留一條縱向空列。簽收確認(rèn)在買家泳道最右末端派送的箭頭從物流泳道筆直上行回去——這條上行通道上任何節(jié)點都不能有。知道這條一次通過率翻倍。圖二訂單狀態(tài)機——栽在箭頭標(biāo)簽上泳道圖講「誰在什么環(huán)節(jié)做什么」?fàn)顟B(tài)機講「訂單這個對象的一生」待支付→風(fēng)控審核中→待發(fā)貨→清關(guān)中→派送中→已簽收→已完成外加超時取消、審核拒絕、售后退款三條分支。這次的報錯是新品種no collision-free label position for 支付成功箭頭上的文字標(biāo)簽找不到不撞車的位置。我節(jié)點間距留了 55px不夠——帶文字標(biāo)簽的橫線間距要給到 90px翻了官方示例確認(rèn)的。畫布加寬到 1600px 后一次通過圖三ER 圖——報錯刷屏但錯不在我ER 圖給開發(fā)對接用訂單、訂單明細(xì)、物流單、支付單、商品五張表字段級PK/FK 標(biāo)清。渲染直接刷屏——五十多條NODE_GAP:ORD_r01,ORD_r020.040.0。表格行本來就是緊挨著的行間距 0px全撞了「節(jié)點間距 ≥40px」的規(guī)則。這次錯不在布局密集表格圖本來就不適用間距規(guī)則。解法是把質(zhì)量配置從showcase換成standard表格圖的正確打開方式之前在一個業(yè)務(wù)系統(tǒng)的字段級 ER 圖上驗證過一次通過圖四平臺對接架構(gòu)圖——唯一一次過的平臺核心四個服務(wù)訂單/支付網(wǎng)關(guān)/庫存/履約調(diào)度對外接支付渠道、海關(guān)單一窗口、海外倉 WMS、物流商 API。為什么它一次過回頭看它天然滿足所有約束三層容器從左到右箭頭全是直線沒有任何回退線。前面的坑讓我養(yǎng)成了「先想布局再動手」的習(xí)慣這張圖是紅利兌現(xiàn)。沉淀評審級圖紙的四條實操原則四張圖跑完加上之前給業(yè)務(wù)系統(tǒng)畫交接圖紙的經(jīng)驗沉淀四條異常分支必須畫全。退款、取消、清關(guān)失敗不是「特殊情況以后再說」是評審被問的第一批問題。泳道圖里的退款分支、狀態(tài)機里的三條異常流都是評審前畫好的給校驗器留余地。橫線帶標(biāo)簽留 90px、節(jié)點間距 ≥40px、回退線留縱向空列——這三條記住一次通過率翻倍表格/密集圖換 standard 配置。間距規(guī)則是為流程圖設(shè)計的ER 表別硬套待決方案也畫上標(biāo)注「待定」。之前一個業(yè)務(wù)系統(tǒng)有三條開放問題我直接畫成待決分支上會評審當(dāng)場拍板后在圖上標(biāo)注已定方案——圖紙不只是記錄決策可以推動決策效率賬四張評審級圖紙含所有翻車修正總共約一個半小時。以前手畫或用 Mermaid 反復(fù)調(diào)一張泳道圖就要這個數(shù)。更重要的是圖是結(jié)構(gòu)化 JSON 存的改需求改圖都是 diff 級別的小事跟需求文檔一起進(jìn) git 版本管理。下一篇是系列收尾這個 skill 一共能畫 14 種圖我整理了一張「圖型 × 產(chǎn)品經(jīng)理工作場景」對照表——什么場景該畫什么圖、什么圖別為難 AI一張表查完。如果這篇對你有用歡迎關(guān)注看「AI 工具人 PM 實戰(zhàn)」系列更新你畫評審圖時踩過最深的坑是什么評論聊聊覺得有用就收藏備用。