干過版圖或 PCB 設計的人大概都經歷過那種“人肉重復勞動”的崩潰時刻幾千個符號要改屬性、上百個封裝要核對位號、導出 BOM 的時候格式不對又得從頭再來。Cadence 家的 Virtuoso、Allegro、IC251 這些工具圖形界面能幫你干八成的事但剩下那兩成最耗時的批量操作恰恰是 SKILL 語言的絕對主場。SKILL 是 Cadence 內置的腳本語言和 Lisp 有血緣關系你在菜單里點到的幾乎所有功能底層都對應著一組 SKILL 函數(shù)把函數(shù)按邏輯串起來就是能代替你熬夜的自動化腳本。這篇指南不打算從語言史講起而是直接按“環(huán)境準備 → 函數(shù)清單 → 實戰(zhàn)腳本 → 工程化 → 避坑”的順序把我自己在實際項目里驗證過的東西一次說透。適合正在用 Cadence 做模擬版圖、數(shù)字后端或 PCB 設計又不想繼續(xù)在重復操作里耗時間的工程師。讀完后你會拿到可以直接抄的腳本骨架也會知道哪些坑是文檔里不會寫的。1. 為什么你的 Cadence 工作流里缺一個 SKILL 腳本1.1 我最早被 SKILL 震撼到的場景入門 SKILL 之前我在 Virtuoso 里做過一次非常痛苦的版圖整理兩千多個 instance 需要在指定層上加標識文本并且要根據(jù) cellName 自動生成內容。用界面一個個加做得我想把鼠標摔了。后來旁邊一位老工程師看不過去在我 CIW 窗口敲了幾行命令一段循環(huán)跑完不到一分鐘全部搞定。就是從那一刻起我意識到同樣的時間會 SKILL 的人已經在喝咖啡了不會的人還在點鼠標。那次經歷之后我開始系統(tǒng)查函數(shù)列表、看官方文檔、拿真實項目練手越深入越覺得這東西才是 Cadence 工具鏈里最被低估的生產力工具。1.2 SKILL 到底是一門怎樣的語言很多人一聽“腳本語言”就以為是 Python 那種風格但實際上 SKILL 的語法非常特別。它有兩種寫法一種是 Lisp 風格的括號形式比如(plus 1 2)另一種是代數(shù)形式比如1 2。兩種寫法在交互環(huán)境下都能被解釋器接受。這門語言從 1980 年代末就出現(xiàn)在 Cadence 工具里了幾十年積累下來形成了一座非常龐大的函數(shù)庫。粗略分一下SKILL 函數(shù)大致覆蓋這幾類通用編程列表操作、字符串處理、流程控制、數(shù)學計算文件 I/O讀文件、寫文件、目錄掃描數(shù)據(jù)庫操作訪問當前設計、遍歷元件/Instance/Shape、創(chuàng)建和修改對象、設置屬性圖形界面創(chuàng)建 Form、彈出提示框、注冊菜單命令回調與控制用戶觸發(fā)器、快捷鍵綁定、命令注冊也就是說SKILL 不只是一個“宏錄制工具”它是一門能完成復雜業(yè)務邏輯的完整語言。提示SKILL 腳本文件常見的擴展名是.il系統(tǒng)和用戶自定義的函數(shù)都可以存放在這類文本文件里加載后即可調用。命名時盡量別用check、skill這類容易被工具內部命令沖突的單詞。1.3 這篇實戰(zhàn)指南的目標讀者如果你滿足下面任一條件這篇文章就是寫給你的你在用 Virtuoso / Allegro / IC251 做設計每天有大量重復性操作你是 CAD 或 EDA 支持工程師經常需要幫團隊批量修數(shù)據(jù)你想把團隊里的“老師傅經驗”沉淀成可復用的工具你暫時還沒寫過 SKILL但希望有一條不那么陡峭的學習路徑這篇文章不會停留在語法層面我會盡量把“函數(shù)列表怎么查、腳本怎么搭、坑怎么躲”講清楚。2. 跑通環(huán)境與第一個腳本從 CIW 到 Skill Debugger2.1 不用安裝任何額外環(huán)境先找這些入口SKILL 的運行時就在 Cadence 工具里面不需要你單獨安裝。根據(jù)你用的工具不同入口略有區(qū)別工具入口交互窗口Virtuoso / IC251CIW 窗口下方的命令行直接輸入 SKILL 表達式Allegro / OrCAD PCB Editor命令窗口輸入skill進入支持逐行輸入和腳本加載批量環(huán)境在 shell 里啟動工具時附加腳本參數(shù)以-replay或腳本方式運行以 Virtuoso 為例啟動后你會在 Command Interpreter WindowCIW底部看到一行輸入框那就是 SKILL 解釋器。你輸入11回車它會立刻返回2。Allegro 稍微繞一點默認命令窗口接收的是 Allegro 自身的命令要先輸入skill進入 SKILL 模式才能寫 SKILL 表達式。不想手動切換的話也可以把調試內容直接寫在.il文件里用load加載。2.2 編輯器選型VSCode、Vim 還是自帶 IDESKILL 腳本本質是純文本用系統(tǒng)自帶的文本編輯器就能寫。但實際開發(fā)中沒有語法高亮和括號匹配腳本稍微長一點就非常痛苦。我自己的組合是VSCode SKILL 擴展 系統(tǒng)終端。VSCode 里搜索 SKILL 插件可以讓.il文件獲得基礎高亮和括號匹配還能在文件側邊欄快速看到函數(shù)定義列表。這個“函數(shù)列表”能力對腳本開展特別重要尤其當你的腳本積累到幾百行時能一眼跳到某個 procedure 所在位置效率完全不一樣。如果你習慣在終端環(huán)境下工作Vim 配合syntax on也能勝任。Cadence 工具鏈自帶的 SKILL IDE在部分版本中可用雖然集成度更高但啟動稍重我自己用得反而不多。2.3 加載腳本的基本命令SKILL 里加載一個腳本文件最常用的命令就是loadload(~/skill_scripts/demo.il)路徑可以寫絕對路徑也可以寫相對于當前工作目錄的路徑。加載成功后解釋器通常不會有特別顯眼的提示但腳本里定義的函數(shù)和變量就已經可用了。如果你只是臨時想試一段代碼不想寫文件可以直接在交互窗口粘貼表達式回車即執(zhí)行。在 Allegro 的 SKILL 模式下也是同理。2.4 用一個最小腳本驗證環(huán)境新建一個文件命名為hello.il內容如下procedure( helloWorld( ) printf(Hello SKILL!\n) ) helloWorld()然后在工具的交互窗口里執(zhí)行l(wèi)oad(hello.il)如果看到Hello SKILL!的輸出說明環(huán)境已經通了。別小看這個流程很多人的第一個坑是路徑問題load不支持~展開到某些工作目錄或者腳本文件的權限不對。我建議路徑里優(yōu)先用絕對路徑少用相對路徑能省掉很多低級報錯。3. 函數(shù)清單不是背出來的按用途分類吃透核心 API3.1 列表與字符串處理SKILL 的 Lisp 基因SKILL 里的核心數(shù)據(jù)結構是列表list它同時扮演了數(shù)組、隊列、棧等多種角色。最開始寫腳本時你不需要精通所有列表函數(shù)但這幾個一定會頻繁用到函數(shù)作用示例list/()構造列表list(1 2 3)或(1 2 3)car/cdr取首元素 / 去掉首元素car((1 2 3))1nth按下標取元素下標從 0 開始nth(1 (10 20 30))20append合并列表append((1 2) (3 4))cons在頭部插入元素cons(0 (1 2))(0 1 2)length取長度length((a b c))3member判斷元素是否存在member(b (a b c))foreach遍歷列表foreach(x (1 2 3) printf(%d\n x))mapcar對每個元素執(zhí)行函數(shù)mapcar(lambda((x) x*x) (1 2 3))setof按條件篩選列表setof(x (1 2 3 4) x2)(3 4)這里面最常用也最好用的是foreach和setof。setof相當于 Python 里的列表推導式比如你想找出當前設計里所有 cellName 為INV的 instance可以直接寫setof(inst cellView~instances inst~cellName INV)字符串方面重點掌握三個strcat字符串拼接strcat(a b)返回absprintf格式化生成字符串用于拼報告非常方便parseString/buildString字符串拆成列表 / 列表拼成字符串strList parseString(a,b,c ,) ; 返回 (a b c) newStr buildString(strList -) ; 返回 a-b-c3.2 對象與數(shù)據(jù)庫操作和設計數(shù)據(jù)對話如果說列表函數(shù)負責“處理數(shù)據(jù)”那么數(shù)據(jù)庫操作函數(shù)才是 SKILL 真正發(fā)光發(fā)熱的地方。這類函數(shù)通常以db、ge、axl等前綴開頭不同工具覆蓋不同領域。在 Virtuoso 的版圖環(huán)境里最常用的幾個函數(shù)作用geGetEditCellView()獲取當前正在編輯的 cellViewdbOpen/dbClose打開/關閉數(shù)據(jù)庫dbGetq查詢對象屬性dbCreateRect創(chuàng)建矩形dbCreatePath創(chuàng)建路徑dbCreateInstance創(chuàng)建 instancedbGet按條件搜索并返回對象列表dbCommit提交對數(shù)據(jù)庫的修改實際使用中你經常會看到類似這樣的代碼cellView geGetEditCellView() foreach(inst cellView~instances printf(Instance %s, cellName %s\n inst~name inst~cellName) )在 Allegro/PCB Editor 環(huán)境下函數(shù)前綴通常是axldesign axlDBGetDesign() foreach(comp design~components printf(位號 %s\n comp~refdes) )這里的~是 SKILL 里的屬性訪問符類似 C 語言的.。先通過~取出對象屬性再通過函數(shù)修改對象幾乎就是數(shù)據(jù)庫操作的全部套路。注意不同版本中元件的“封裝名”字段可能是package也可能是symbol。第一次在陌生版本上寫腳本時建議先用類似comp~?的方式查看對象可用屬性再確定字段名。這樣能避免絕大多數(shù)“函數(shù)名或屬性名寫錯”的冤案。3.3 用戶交互與回顯讓腳本更可用寫腳本時如果所有結果都只在終端里輸出別人用起來會很不友好。SKILL 提供了一系列交互函數(shù)能讓腳本具備簡單的“界面感”。最基礎的是回顯函數(shù)printf格式化輸出到當前窗口println輸出一行自動加換行hiDisplayMessage在圖形界面彈出一段提示更進一步你可以用axlUIPopupAllegro或hiDisplayFormVirtuoso創(chuàng)建簡單的彈窗。對于大多數(shù)內部自動化腳本我不建議一上來就設計龐大的圖形界面先用一個彈窗提示結果就夠了后面有需要再迭代。菜單注冊也是交互增強的關鍵。Allegro 里可以通過axlCmdRegister把 SKILL 函數(shù)注冊成命令這樣用戶在命令欄輸入一個自定義單詞就能執(zhí)行腳本procedure( myCheck( ) printf(運行檢查...\n) ) axlCmdRegister(myCheck myCheck)注冊之后在 Allegro 命令窗口直接輸入myCheck就等價于調用這個函數(shù)。Virtuoso 則可以通過hiRegMenu往菜單欄掛按鈕方式雖不同思路一致。3.4 如何高效查閱官方函數(shù)參考Cadence 自帶的 SKILL 函數(shù)參考文檔非常厚重第一次看的人容易懵。我的經驗是遇到不確定的函數(shù)時在 SKILL 交互窗口使用在線幫助函數(shù)比翻 PDF 快得多。常見的幫助函數(shù)包括describe(axlDBGetDesign)查看函數(shù)說明? axlDBGetDesign查看屬性幫助部分環(huán)境支持getSkillPath()查看搜索路徑搜索資料時要留一個心眼網絡上的 SKILL 代碼風格差異很大有些老腳本用了不少已經被替代的舊函數(shù)跑起來會報 deprecated 警告。優(yōu)先以你實際安裝版本的官方文檔為準網上的代碼只做參考思路不要無腦照抄。4. 實戰(zhàn)拆解用 80 行腳本完成元件位號與封裝體檢4.1 先別寫代碼先拆需求很多初學者拿到需求就開寫結果寫到一半發(fā)現(xiàn)邏輯漏洞百出。正確的做法是先快速拆解任務邊界。我以一個真實場景為例PCB 設計交付前需要檢查所有元件是否有位號、封裝是否缺失、坐標是否超出板框范圍。這個任務如果靠人工翻版圖看屬性幾千個元件看到懷疑人生用 SKILL 做邏輯其實很清晰獲取當前設計對象遍歷所有元件逐個讀取位號、封裝、坐標屬性按規(guī)則判斷是否異常把異常信息收集到列表里生成報告文件并用彈窗提示摘要這五步不涉及任何復雜的算法核心就是對“元件對象列表”的一次過濾和統(tǒng)計。我刻意選擇這個例子是想說明一個最重要的觀點任何自動化腳本的第一產出物不是代碼而是邏輯流程圖。你先把步驟畫出來在紙上或文檔里再動手會順利很多。4.2 獲取設計數(shù)據(jù)和元件清單在 Allegro 環(huán)境下當前打開的設計可以通過axlDBGetDesign()獲取。拿到 design 對象后再通過design~components就能得到元件列表。design axlDBGetDesign() components design~components printf(當前設計共 %d 個元件\n length(components))如果你的環(huán)境里components字段名不一致用design~?查看一下當前設計對象有哪些可訪問屬性再替換即可。4.3 遍歷元件并執(zhí)行三項檢查位號檢查最直接判斷comp~refdes是否為空即可。封裝檢查要稍微小心因為有的元件比如測試點、安裝孔可能本身就不需要封裝這時需要額外的排除規(guī)則。坐標檢查則要和板框范圍比較。下面是一段核心遍歷代碼foreach(comp components when( comp~refdes nil problems cons(發(fā)現(xiàn)無位號元件 problems) ) when( comp~package nil problems cons(sprintf(nil 元件 %s 缺少封裝 comp~refdes) problems) ) when( comp~x 0 || comp~x boardWidth problems cons(sprintf(nil 元件 %s 超出板框 X 范圍 comp~refdes) problems) ) )這里我用cons把問題字符串不斷加到列表頭部。之所以用cons而不是append是因為cons是 O(1) 操作append在循環(huán)里反復調用會不斷創(chuàng)建新列表性能差一個數(shù)量級。遍歷結束后再用reverse把列表翻回來保證報告里的順序和元件順序一致。提示sprintf(nil 格式串 arg...)這種寫法會把格式化結果作為返回值直接交給變量或列表在需要拼接報告行時非常常用。注意sprintf的第一個參數(shù)傳nil在大多數(shù) SKILL 版本里返回生成的字符串但個別版本行為略有差異遇到問題就改成先聲明一個變量再接收。4.4 生成報告文件并彈窗提示問題收集完接下來是落盤和提示。文件操作在 SKILL 里非常直觀用outfile打開一個輸出流用fprintf寫入內容最后close關閉。outPort outfile(reportFile) fprintf(outPort 元件體檢報告\n) fprintf(outPort 檢查時間%s\n getCurrentTime()) fprintf(outPort 共檢查 %d 個元件發(fā)現(xiàn)問題 %d 項\n\n length(components) length(problems)) foreach(prob problems fprintf(outPort %s\n prob) ) close(outPort)這一步有幾個容易忽略的細節(jié)輸出路徑所在目錄要存在否則outfile會失敗寫完一定要close否則文件內容可能沒有真正刷新到磁盤報告里最好帶時間戳和統(tǒng)計總數(shù)這在多人協(xié)作時能快速確認數(shù)據(jù)是否最新最后用axlUIPopup彈一個摘要提示用戶體驗立刻提升if( problems then axlUIPopup(sprintf(nil 發(fā)現(xiàn) %d 個問題詳見 %s length(problems) reportFile)) else axlUIPopup(檢查通過未發(fā)現(xiàn)問題) )4.5 完整腳本示例與注冊命令把所有片段拼起來加上頭注釋和命令注冊就是一個完整可用的工具腳本; 元件體檢腳本 ; 適用Allegro / PCB Editor ; 用法load 本文件后在命令窗口輸入 ckdesign procedure( ckDesign( optional (reportFile /tmp/design_check.txt) ) let( (design components problems outPort total) problems nil design axlDBGetDesign() when( design nil error(未獲取到當前設計對象請先打開PCB設計\n) ) components design~components total length(components) ; 逐項檢查 foreach(comp components when( comp~refdes nil problems cons(發(fā)現(xiàn)無位號元件 problems) ) when( comp~package nil problems cons(sprintf(nil 元件 %s 缺少封裝 comp~refdes) problems) ) when( comp~x 0 || comp~x 1000 || comp~y 0 || comp~y 1000 problems cons(sprintf(nil 元件 %s 坐標超出預設范圍(%.2f, %.2f) comp~refdes comp~x comp~y) problems) ) ) problems reverse(problems) ; 寫報告 outPort outfile(reportFile) fprintf(outPort 元件體檢報告\n) fprintf(outPort 檢查對象%s\n design~name) fprintf(outPort 共檢查 %d 個元件發(fā)現(xiàn)問題 %d 項\n total length(problems)) foreach(prob problems fprintf(outPort %s\n prob) ) close(outPort) ; 彈窗提示 if( length(problems) 0 then axlUIPopup(sprintf(nil 發(fā)現(xiàn) %d 個問題詳見 %s length(problems) reportFile)) else axlUIPopup(sprintf(nil %d 個元件檢查通過 total)) ) ) ) axlCmdRegister(ckdesign ckDesign)從“函數(shù)列表”到“自動化腳本”本質上就是這一步先確定你要操作的對象類型然后去函數(shù)清單里找對應的訪問函數(shù)和屬性再按業(yè)務邏輯用列表函數(shù)把它們組織起來。這個腳本雖然不算長但已經具備了一個生產級工具的基本要素參數(shù)默認值、錯誤檢查、日志輸出、用戶反饋、命令注冊。5. 從“能干”到“高效”腳本工程化改造5.1 把腳本從一次性“臨時文件”變成復用工具剛學會 SKILL 時很多人寫的腳本是“一次性”的需求來了臨時寫一個幾十行的tmp1.il跑完就扔。這種方式的痛點是三個月后同樣的需求再來你發(fā)現(xiàn)自己完全不記得當初的邏輯只能重新寫一遍。我建議從第一次寫正式腳本時就做一個動作把常用功能封裝成procedure并把文件名、函數(shù)名、用途都寫清楚。前面的ckDesign就是一個例子。你甚至可以往這個函數(shù)里加一個optional參數(shù)讓它可以支持不同的板框范圍或報告路徑這樣它就能在不同項目中復用。5.2 參數(shù)化設計與默認值處理SKILL 的procedure支持三種參數(shù)必選參數(shù)、可選參數(shù)optional、關鍵字參數(shù)key。設計一個可復用函數(shù)時優(yōu)先考慮哪些值應該暴露成參數(shù)。例如procedure( ckDesign( key (boardWidth 1000) (boardHeight 1000) (reportFile /tmp/design_check.txt) ) let( (...) ... ) )調用時的寫法會變成ckDesign(?boardWidth 2000 ?reportFile ./report.txt)key參數(shù)的優(yōu)點在于調用時不需要記住參數(shù)順序代碼可讀性也更好。別把默認值寫死在業(yè)務邏輯里這是腳本工程化的第一課。5.3 注重性能減少重復查詢和路徑遍歷SKILL 腳本處理幾百個對象時性能根本不是問題但一旦碰到上萬級的 instance 或 shape寫法和寫法之間的差距就會非常明顯。我踩過的最典型的性能坑是在循環(huán)里反復調用dbOpen或反復訪問同一個對象屬性導致每次循環(huán)都觸發(fā)一次數(shù)據(jù)查詢最終把一個本該幾秒完成的腳本拖成幾分鐘。優(yōu)化策略其實就三條循環(huán)外緩存對象引用能在foreach外面取到的對象絕不在循環(huán)里重復取避免頻繁拼接大字符串反復用strcat拼接一個幾千行的報告性能極差改用列表收集最后一次性buildString或逐行fprintf能用setof遍歷就用setof篩選邏輯優(yōu)先用聲明式寫法而不是手寫foreachwhen再加cons下面這段對比很直觀; 低效寫法每次判斷都查一次屬性鏈 foreach(inst cellView~instances when( inst~cellName INV invList cons(inst invList) ) ) ; 高效寫法聲明式篩選語義也更清晰 invList setof(inst cellView~instances inst~cellName INV)5.4 錯誤恢復與事務提交還有個容易被忽視的問題腳本運行到一半報錯設計數(shù)據(jù)庫可能處于“半改動”狀態(tài)。在 Virtuoso 里很多dbCreate*操作必須顯式調用dbCommit或依賴特定的事務機制在 Allegro 里修改數(shù)據(jù)庫后要確保設計被正確保存。我寫腳本的習慣是所有可能失敗的輸入先用when或if做保護判斷對“只讀類”的檢查腳本不修改數(shù)據(jù)庫從源頭規(guī)避風險對“寫操作類”腳本跑完立刻驗證關鍵對象是否存在再決定是否保存關鍵步驟之間加printf日志這樣即使中途掛了也能定位到在哪一步掛的6. 翻車記錄與經驗補丁SKILL 開發(fā)的真實代價6.1 改了數(shù)據(jù)庫卻沒生效事務和保存的坑我在 Virtuoso 里寫第一個自動創(chuàng)建圖形的腳本時跑完沒有任何報錯對象卻始終看不到。查了半天才發(fā)現(xiàn)創(chuàng)建的對象停在內存里沒有提交到數(shù)據(jù)庫。類似的問題在 Allegro 里也會出現(xiàn)修改了元件屬性replay 結束一看界面還是老樣子。建議寫寫操作腳本時把“提交/保存”步驟當成一個獨立的驗證節(jié)點。完成操作后主動執(zhí)行保存或同步操作并確認這一步真的在腳本流程里被執(zhí)行到了。另外有些版本的 Allegro 在命令行模式下操作完需要手動刷新視圖腳本里也可以主動執(zhí)行redraw或類似命令讓界面同步。6.2 整數(shù)與浮點數(shù)混用的隱性錯誤SKILL 對數(shù)字類型的處理相對寬松但并不是沒有坑。尤其是坐標計算如果兩個整數(shù)相除被當作浮點某個版本的語義可能和你的預期不一致坐標精確到小數(shù)點后幾位時用整數(shù)計算和用浮點計算的結果可能完全不同。我的建議是涉及坐標、長度、角度等物理量的運算一開始就把所有數(shù)值顯式轉換成浮點x float(comp~x)。不要依賴 SKILL 的自動類型提升顯式轉換能讓行為可預期。6.3 全局變量污染與作用域泄漏SKILL 的變量作用域設計很自由自由到容易出事。如果你在腳本頂層寫了一個problems nil然后在某個procedure里又直接用了problems這個變量就會在全局空間里被共享。多個腳本加載時很容易出現(xiàn)“這個腳本改了那個腳本的變量”的詭異問題。最安全的做法是所有臨時變量都放進let或prog的局部作用域里。procedure的參數(shù)本身就是局部的函數(shù)內部再套一個let包住中間變量基本就能杜絕變量污染。我在前面示例代碼里已經用了let包裹這不是炫技是真的被坑怕了。6.4 異常處理不夠健壯導致半途崩潰SKILL 有errset和error機制可以捕獲運行時異常errset( ; 可能出錯的代碼 load(/path/to/some.il) )errset在代碼出錯時不會中斷整個腳本而是把錯誤信息返回。這在批量處理多個文件時很有用一個文件壞了跳過它繼續(xù)處理下一個。我自己在寫批量腳本時幾乎必用errset它能把腳本的“單點失敗”變成“單點告警”。6.5 命令行注冊沖突用axlCmdRegister注冊自定義命令時一定要確認命令名沒有和工具內置命令沖突。我遇到過注冊一個叫update的命令結果某個操作觸發(fā)了內置同名命令行為完全不可控。自定義命令最好加一個獨特的前綴比如公司縮寫或你的名字縮寫像qaUpdate、ckdesign這樣。6.6 交付給別人的腳本要留“逃生艙”最后一條建議和語法無關但很重要如果你寫的腳本要交給團隊里其他人用一定要讓腳本在最開始、最容易出錯的地方給出明確提示。比如判斷當前有沒有打開設計、文件路徑是否存在、對象列表是否為空。別讓同事拿到腳本后面對一個莫名其妙的nil報錯還要反過來找你排查。我通常會在腳本頭部加一段環(huán)境自檢when( axlDBGetDesign() nil error(請先打開需要檢查的 PCB 設計文件\n) )這一句看似多余實際能節(jié)省所有使用者的理解成本。7. 最后分享一點個人體會從函數(shù)列表到自動化腳本真正質變的節(jié)點不是“記住了多少函數(shù)”而是“看到需求后能穩(wěn)定地拆出數(shù)據(jù)流”。我剛入門時總喜歡到處收集別人的腳本代碼后來發(fā)現(xiàn)最有用的還是自己翻官方文檔、在交互窗口里一個個試函數(shù)、拿真實設計練手。SKILL 的學習曲線初期稍陡但只要過了“列表操作 屬性訪問 流程控制”這三關你就能應付絕大多數(shù)日常自動化需求。我自己現(xiàn)在的工作習慣是任何操作如果在界面上需要重復超過三次就停下來想想能不能用 SKILL 解決。哪怕第一次寫腳本花的時間比手動操作還久但它的價值會在第二次、第三次使用時迅速體現(xiàn)出來。工具鏈里最有價值的不是某個菜單項而是你能不能把幾個函數(shù)列表里的碎片拼成你自己的“時間機器”。希望你讀完這篇文章后也能動手寫一個屬于自己的.il腳本然后把省下來的時間花在真正需要設計師判斷力的事情上。