一文拆解 AzurLaneAutoScript碧藍航線全自動腳本的調度、識別與配置原理詳解【免費下載鏈接】AzurLaneAutoScriptAzur Lane bot (CN/EN/JP/TW) 碧藍航線腳本 | 無縫委托科研全自動大世界項目地址: https://gitcode.com/gh_mirrors/az/AzurLaneAutoScriptAzurLaneAutoScript以下簡稱 ALAS是一款支持 CN/EN/JP/TW 四服的碧藍航線自動化腳本覆蓋委托、科研、大世界、活動、基建等幾乎全部日常玩法。本文以它為什么能像人一樣連續掛機數小時不出錯為線索從任務調度、配置生成、圖像識別、異常自愈四條主線拆解其工程實現幫助中級開發者理解一套游戲外掛背后的軟件設計智慧并附常見問題排查方法。先問一個問題為什么一個游戲腳本看起來像個操作系統第一次打開 ALAS 源碼的人通常會在alas.py前愣住入口居然是一個永不退出的while循環外面包著任務隊列、服務器狀態檢查、失敗計數、配置熱重載——這分明是操作系統的調度器而不是一個截圖-點擊的玩具腳本。這種設計并非炫技而是被需求逼出來的。掛機腳本的本質矛盾在于游戲世界是持續變化的維護、卡死、網絡波動、活動刷新而腳本必須在這種不確定環境中持續自洽地運行。如果腳本只是一條直線執行的指令序列任何一次意外都會讓整條流水線崩潰。于是 ALAS 選擇了循環狀態機的結構每一輪循環只做取任務→執行→記錄結果→重新取任務這一件事把不確定性擋在循環之外。你會發現理解了這一個循環就理解了整個項目的骨架。從入口讀懂全局任務即函數調度即循環ALAS 的調度核心只有幾百行藏在alas.py的loop()與run()兩個方法里。loop()負責取任務、檢查服務器狀態、處理失敗重試run()則負責把任務名翻譯成一次真實的方法調用def run(self, command, skip_first_screenshotFalse): try: if not skip_first_screenshot: self.device.screenshot() self.__getattribute__(command)() return True except TaskEnd: return True except GameNotRunningError as e: logger.warning(e) self.config.task_call(Restart) return False # ... 其余異常分支 def loop(self): while 1: task self.get_next_task() success self.run(inflection.underscore(task)) # 失敗 3 次以上則請求人工接管并退出 if failed 3: logger.critical(Request human takeover) exit(1)這里的巧妙之處在于inflection.underscore(task)配置里寫著駝峰命名的任務名如OpsiDaemon、WarArchives運行時被統一轉成opsi_daemon、war_archives這樣的下劃線方法名再通過__getattribute__動態調用。也就是說新增一個玩法模塊只需要在類里寫一個同名方法調度器無需任何改動——這是典型的插件化擴展思路代價極低收益極大。注意run()的開頭先截一張圖再執行。這張預熱截圖不只是為了視覺反饋更是為了把游戲畫面狀態提前拉進內存讓后續的界面判斷可以復用首幀避免每次判斷都重新截圖造成的延遲。腳本的生物鐘時間驅動的任務隊列如何決定下一秒做什么如果只有循環腳本會像永動機一樣把所有任務刷到過熱。真正讓 ALAS 有節奏感的是時間驅動機制。在get_next_task()中每個任務都帶一個next_run時間戳未到點就進入等待if task.next_run datetime.now(): logger.info(fWait until {task.next_run} for task {task.command}) method self.config.Optimization_WhenTaskQueueEmpty if method close_game: self.device.app_stop() # 空檔期直接關游戲省資源 elif method goto_main: self.run(goto_main) # 或者回到主界面待命 # stay_there原地不動這段邏輯回答了一個很實際的問題任務間隙腳本到底該干嘛ALAS 把它做成了可配置項Optimization_WhenTaskQueueEmpty提供關游戲回主界面原地等待三種策略。這看起來是個小選項實際是資源策略的體現——有人掛機是為了省電有人是為了不間斷作戰一種策略不可能滿足所有人。而wait_until()里的config.should_reload()檢查更是點睛之筆等待期間如果用戶改了配置腳本立刻放棄等待、重新加載配置再調度而不是傻等到天亮。這種等待也可被打斷的設計讓長時間掛機的可控性上了一個臺階。配置即代碼一條從 YAML 到 Python 類的代碼生成流水線ALAS 的配置系統是另一個值得拆解的部分。先看它的數據源頭module/config/argument/下是一堆 YAML 文件argument.yaml、default.yaml、task.yaml、gui.yaml開發者在這里聲明每個配置項的類型、默認值、選項。然后config_updater.py里的ConfigGenerator負責把它們編譯成真正的代碼class ConfigGenerator: cached_property def argument(self): raw read_file(filepath_argument(argument)) for path, value in deep_iter(raw, depth2): arg { type: input, value: , } if not isinstance(value, dict): value {value: value} arg[type] data_to_type(value, argpath[1]) arg.update(value) deep_set(data, keyspath, valuearg)最終產物是自動生成的module/config/config_generated.py——一個巨大的GeneratedConfig類所有配置項都變成類屬性。而運行時的AzurLaneConfig通過多重繼承把ConfigUpdater讀寫 YAML/JSON、ManualConfig手工覆蓋項、GeneratedConfig自動生成項、ConfigWatcher變更監聽揉在一起。這套設計的價值在于單一事實來源開發者只需維護 YAML 聲明GUI 表單、代碼屬性、默認值全部自動派生永遠不會出現界面選項和代碼字段對不上的經典翻車事故。同時deep_get/deep_set這套工具函數讓嵌套配置的讀寫像操作字典一樣直觀。如果你寫過一個配置項散落在十幾個文件里的項目就會明白這種收斂有多么珍貴。改配置不用重啟熱重載背后的緩存失效設計很多人第一次用 ALAS 時會有個疑問在網頁 GUI 里改完設置腳本真的不需要重啟嗎答案是下一輪任務前自動生效。機制分兩步ConfigWatcher監聽配置文件的變化記錄should_reload狀態調度循環里則在關鍵節點執行del_cached_property(self, config)把緩存的配置對象強制丟棄下一輪循環重新實例化。if not self.wait_until(task.next_run): del_cached_property(self, config) # 緩存失效強制重載 continue這是典型的緩存失效即更新策略與其做精細的字段級 diff不如在安全的邊界點整體重建。代價是每次重載有少量開銷但換來的是邏輯極簡、絕不漏更新。同樣的思路也出現在wait_until的等待循環里——一旦檢測到配置變化立刻中斷等待。理解了這個模式你就能舉一反三任何熱更新需求都可以先問自己哪里是安全的失效點。腳本的眼睛模板匹配、OCR 與地圖透視三位一體如果說調度是 ALAS 的心臟那識別系統就是它的眼睛。它并不是單一技術而是三套各司其職的方案第一層是模板匹配。項目在assets/服務器/下存放了數千張游戲界面截圖如按鈕、標簽、關卡入口運行時通過module/base/template.py做像素級匹配。例如關卡選擇界面里的下一章箭頭按鈕這類圖片看似簡單但批量維護幾千張 1280x720 的模板、按服務器CN/EN/JP/TW分目錄管理本身就是一套完整的資產管線——連按鈕的微小偏移都可能讓匹配失敗這也是多服腳本最枯燥也最關鍵的工程。第二層是 OCR。部分信息如油料數量、活動 PT、艦船等級無法用固定模板覆蓋需要讀數字和文字。ALAS 在module/ocr/下封裝了基于 cnocr 的識別服務并用多進程隔離避免阻塞主循環。它甚至做了一項很摳的優化在ModuleBase里啟動一個后臺線程預加載 OCR 模型與首幀截圖并行執行——截圖是 IO 密集、模型導入是 CPU 密集兩者并行能省下啟動時寶貴的 0.5~5 秒def do_ocr_import(): while 1: if self.device.has_cached_image: break time.sleep(0.01) from module.ocr.al_ocr import AlOcr # 與截圖并行加載模型第三層是地圖透視。這是 ALAS 最驚艷的部分體現在module/map_detection/里homography.py做單應性變換、perspective.py處理透視矯正、grid_predictor.py推算格子坐標。它能把大世界那幅傾斜透視的航海圖拉平成一張可計算的網格棋盤從而規劃路線、避開暗區OCR 識別的對象同樣來自游戲內截圖例如大講堂的作戰模式標簽這類小字文本三者組合的結果是模板負責認東西OCR 負責讀數字透視負責算位置再疊加 UI 掩碼assets/mask/里那幾張黑白遮罩圖專門用來屏蔽無關區域、提升匹配置信度。這種分工再協作的識別架構比任何單一技術都更貼合游戲掛機的真實需求。把意外變成流程異常分級與自愈機制真實掛機場景里意外才是常態。ALAS 的可貴之處在于它把異常當成了一等公民來設計。看run()里的異常分支就明白了GameNotRunningError游戲沒開→ 自動拉起并重啟任務GameStuckError卡死→ 記錄錯誤、重啟游戲、等待 10 秒再戰GameBugError客戶端報錯→ 同樣自動重啟GamePageUnknownError頁面未知→ 先查服務器是否維護維護就等不維護才請求人工RequestHumanTakeover無法自愈→ 通知并退出。支撐這套自愈邏輯的還有兩個隱蔽組件點擊/卡死計數器stuck_record、click_record用來識別連點多次畫面無變化的死循環以及錯誤現場保存——save_error_log()會把崩潰前 60 張截圖和日志一起歸檔到log/error/時間戳/目錄并自動對截圖做敏感信息打碼處理。這一手事故黑匣子讓所有崩潰都能事后復盤極大降低了遠端排障成本。失敗的次數同樣被記錄在案同一任務連續失敗 3 次腳本會果斷停止并請求人工接管而不是陷入失敗-重試-再失敗的無底洞。這種有限重試、果斷放棄的哲學值得所有自動化系統的設計者借鑒。多語言與翻譯緩存一份配置四地通用ALAS 服務四服語言適配自然是剛需。它的做法很樸素在module/config/i18n/下放四份 JSONzh-CN、zh-TW、en-US、ja-JP翻譯鍵和配置項一一對應。實現上翻譯資源在進程啟動時一次性加載進內存并做鍵名索引后續查找都是內存字典操作速度極快——但代價是改了翻譯必須重啟后端才生效這既是緩存設計的必然結果也是新手容易踩的坑。值得一提的細節是回退機制某語言缺翻譯時界面會回退顯示鍵名本身而非空白保證 GUI 永遠可讀。這種最壞情況也能用的兜底思路在多語言產品里是性價比極高的做法。常見問題排查出問題時該去哪里找線索理解了上述架構排查問題就有了地圖。ALAS 的日志體系很規整運行日志按配置名寫入log/目錄崩潰現場在log/error/時間戳/含截圖*.png與log.txt。實際排查時建議按三步走看崩潰目錄log/error/下最近的文件夾先讀log.txt末尾的logger.hr分隔線定位是哪個任務、在哪個狀態機里崩的查異常類型若日志出現RequestHumanTakeover說明腳本已放棄自愈多半是配置或游戲側問題若只是GameStuckError通常是網絡或模擬器卡頓屬可自愈范疇驗證配置懷疑是配置問題比如 JSON/YAML 格式錯誤、鍵值越界檢查config/下的用戶配置文件或用重啟后端讓配置與翻譯緩存強制重建。另外若你在改代碼后啟動失敗優先確認config_generated.py是否已重新生成——它是自動化產物手動改動會被下次生成覆蓋這屬于本項目最經典的我改的怎么沒了事故。總結與延伸思考回看整條鏈路alas.py的循環調度負責什么時候做什么config_updater的代碼生成負責配置怎么被理解模板匹配、OCR、透視變換負責畫面怎么被看懂異常分級與自愈負責出錯后怎么活下來——四者咬合才支撐起無縫委托科研、全自動大世界這句項目簡介。它真正的工程價值不在于某個算法的精妙而在于把不確定性系統化地管理起來等待可被打斷、失敗有次數上限、崩潰有黑匣子、配置有單一事實來源。如果沿著這條思路繼續想有幾個延伸方向值得你親自去源碼里驗證翻譯系統的懶加載能否改成文件監聽熱更新從而去掉必須重啟的限制地圖透視的網格預測是否能進一步抽象出通用的任意傾斜視角 UI 標定工具save_error_log的截圖歸檔能否接上訓練集反哺模板匹配的自動化采集ALAS 留給你探索的遠比它已實現的更多。【免費下載鏈接】AzurLaneAutoScriptAzur Lane bot (CN/EN/JP/TW) 碧藍航線腳本 | 無縫委托科研全自動大世界項目地址: https://gitcode.com/gh_mirrors/az/AzurLaneAutoScript創作聲明：本文部分內容由AI輔助生成（AIGC），僅供參考 一文拆解 AzurLaneAutoScript：碧藍航線全自動腳本的調度、識別與配置原理詳解
一文拆解 AzurLaneAutoScript碧藍航線全自動腳本的調度、識別與配置原理詳解【免費下載鏈接】AzurLaneAutoScriptAzur Lane bot (CN/EN/JP/TW) 碧藍航線腳本 | 無縫委托科研全自動大世界項目地址: https://gitcode.com/gh_mirrors/az/AzurLaneAutoScriptAzurLaneAutoScript以下簡稱 ALAS是一款支持 CN/EN/JP/TW 四服的碧藍航線自動化腳本覆蓋委托、科研、大世界、活動、基建等幾乎全部日常玩法。本文以它為什么能像人一樣連續掛機數小時不出錯為線索從任務調度、配置生成、圖像識別、異常自愈四條主線拆解其工程實現幫助中級開發者理解一套游戲外掛背后的軟件設計智慧并附常見問題排查方法。先問一個問題為什么一個游戲腳本看起來像個操作系統第一次打開 ALAS 源碼的人通常會在alas.py前愣住入口居然是一個永不退出的while循環外面包著任務隊列、服務器狀態檢查、失敗計數、配置熱重載——這分明是操作系統的調度器而不是一個截圖-點擊的玩具腳本。這種設計并非炫技而是被需求逼出來的。掛機腳本的本質矛盾在于游戲世界是持續變化的維護、卡死、網絡波動、活動刷新而腳本必須在這種不確定環境中持續自洽地運行。如果腳本只是一條直線執行的指令序列任何一次意外都會讓整條流水線崩潰。于是 ALAS 選擇了循環狀態機的結構每一輪循環只做取任務→執行→記錄結果→重新取任務這一件事把不確定性擋在循環之外。你會發現理解了這一個循環就理解了整個項目的骨架。從入口讀懂全局任務即函數調度即循環ALAS 的調度核心只有幾百行藏在alas.py的loop()與run()兩個方法里。loop()負責取任務、檢查服務器狀態、處理失敗重試run()則負責把任務名翻譯成一次真實的方法調用def run(self, command, skip_first_screenshotFalse): try: if not skip_first_screenshot: self.device.screenshot() self.__getattribute__(command)() return True except TaskEnd: return True except GameNotRunningError as e: logger.warning(e) self.config.task_call(Restart) return False # ... 其余異常分支 def loop(self): while 1: task self.get_next_task() success self.run(inflection.underscore(task)) # 失敗 3 次以上則請求人工接管并退出 if failed 3: logger.critical(Request human takeover) exit(1)這里的巧妙之處在于inflection.underscore(task)配置里寫著駝峰命名的任務名如OpsiDaemon、WarArchives運行時被統一轉成opsi_daemon、war_archives這樣的下劃線方法名再通過__getattribute__動態調用。也就是說新增一個玩法模塊只需要在類里寫一個同名方法調度器無需任何改動——這是典型的插件化擴展思路代價極低收益極大。注意run()的開頭先截一張圖再執行。這張預熱截圖不只是為了視覺反饋更是為了把游戲畫面狀態提前拉進內存讓后續的界面判斷可以復用首幀避免每次判斷都重新截圖造成的延遲。腳本的生物鐘時間驅動的任務隊列如何決定下一秒做什么如果只有循環腳本會像永動機一樣把所有任務刷到過熱。真正讓 ALAS 有節奏感的是時間驅動機制。在get_next_task()中每個任務都帶一個next_run時間戳未到點就進入等待if task.next_run datetime.now(): logger.info(fWait until {task.next_run} for task {task.command}) method self.config.Optimization_WhenTaskQueueEmpty if method close_game: self.device.app_stop() # 空檔期直接關游戲省資源 elif method goto_main: self.run(goto_main) # 或者回到主界面待命 # stay_there原地不動這段邏輯回答了一個很實際的問題任務間隙腳本到底該干嘛ALAS 把它做成了可配置項Optimization_WhenTaskQueueEmpty提供關游戲回主界面原地等待三種策略。這看起來是個小選項實際是資源策略的體現——有人掛機是為了省電有人是為了不間斷作戰一種策略不可能滿足所有人。而wait_until()里的config.should_reload()檢查更是點睛之筆等待期間如果用戶改了配置腳本立刻放棄等待、重新加載配置再調度而不是傻等到天亮。這種等待也可被打斷的設計讓長時間掛機的可控性上了一個臺階。配置即代碼一條從 YAML 到 Python 類的代碼生成流水線ALAS 的配置系統是另一個值得拆解的部分。先看它的數據源頭module/config/argument/下是一堆 YAML 文件argument.yaml、default.yaml、task.yaml、gui.yaml開發者在這里聲明每個配置項的類型、默認值、選項。然后config_updater.py里的ConfigGenerator負責把它們編譯成真正的代碼class ConfigGenerator: cached_property def argument(self): raw read_file(filepath_argument(argument)) for path, value in deep_iter(raw, depth2): arg { type: input, value: , } if not isinstance(value, dict): value {value: value} arg[type] data_to_type(value, argpath[1]) arg.update(value) deep_set(data, keyspath, valuearg)最終產物是自動生成的module/config/config_generated.py——一個巨大的GeneratedConfig類所有配置項都變成類屬性。而運行時的AzurLaneConfig通過多重繼承把ConfigUpdater讀寫 YAML/JSON、ManualConfig手工覆蓋項、GeneratedConfig自動生成項、ConfigWatcher變更監聽揉在一起。這套設計的價值在于單一事實來源開發者只需維護 YAML 聲明GUI 表單、代碼屬性、默認值全部自動派生永遠不會出現界面選項和代碼字段對不上的經典翻車事故。同時deep_get/deep_set這套工具函數讓嵌套配置的讀寫像操作字典一樣直觀。如果你寫過一個配置項散落在十幾個文件里的項目就會明白這種收斂有多么珍貴。改配置不用重啟熱重載背后的緩存失效設計很多人第一次用 ALAS 時會有個疑問在網頁 GUI 里改完設置腳本真的不需要重啟嗎答案是下一輪任務前自動生效。機制分兩步ConfigWatcher監聽配置文件的變化記錄should_reload狀態調度循環里則在關鍵節點執行del_cached_property(self, config)把緩存的配置對象強制丟棄下一輪循環重新實例化。if not self.wait_until(task.next_run): del_cached_property(self, config) # 緩存失效強制重載 continue這是典型的緩存失效即更新策略與其做精細的字段級 diff不如在安全的邊界點整體重建。代價是每次重載有少量開銷但換來的是邏輯極簡、絕不漏更新。同樣的思路也出現在wait_until的等待循環里——一旦檢測到配置變化立刻中斷等待。理解了這個模式你就能舉一反三任何熱更新需求都可以先問自己哪里是安全的失效點。腳本的眼睛模板匹配、OCR 與地圖透視三位一體如果說調度是 ALAS 的心臟那識別系統就是它的眼睛。它并不是單一技術而是三套各司其職的方案第一層是模板匹配。項目在assets/服務器/下存放了數千張游戲界面截圖如按鈕、標簽、關卡入口運行時通過module/base/template.py做像素級匹配。例如關卡選擇界面里的下一章箭頭按鈕這類圖片看似簡單但批量維護幾千張 1280x720 的模板、按服務器CN/EN/JP/TW分目錄管理本身就是一套完整的資產管線——連按鈕的微小偏移都可能讓匹配失敗這也是多服腳本最枯燥也最關鍵的工程。第二層是 OCR。部分信息如油料數量、活動 PT、艦船等級無法用固定模板覆蓋需要讀數字和文字。ALAS 在module/ocr/下封裝了基于 cnocr 的識別服務并用多進程隔離避免阻塞主循環。它甚至做了一項很摳的優化在ModuleBase里啟動一個后臺線程預加載 OCR 模型與首幀截圖并行執行——截圖是 IO 密集、模型導入是 CPU 密集兩者并行能省下啟動時寶貴的 0.5~5 秒def do_ocr_import(): while 1: if self.device.has_cached_image: break time.sleep(0.01) from module.ocr.al_ocr import AlOcr # 與截圖并行加載模型第三層是地圖透視。這是 ALAS 最驚艷的部分體現在module/map_detection/里homography.py做單應性變換、perspective.py處理透視矯正、grid_predictor.py推算格子坐標。它能把大世界那幅傾斜透視的航海圖拉平成一張可計算的網格棋盤從而規劃路線、避開暗區OCR 識別的對象同樣來自游戲內截圖例如大講堂的作戰模式標簽這類小字文本三者組合的結果是模板負責認東西OCR 負責讀數字透視負責算位置再疊加 UI 掩碼assets/mask/里那幾張黑白遮罩圖專門用來屏蔽無關區域、提升匹配置信度。這種分工再協作的識別架構比任何單一技術都更貼合游戲掛機的真實需求。把意外變成流程異常分級與自愈機制真實掛機場景里意外才是常態。ALAS 的可貴之處在于它把異常當成了一等公民來設計。看run()里的異常分支就明白了GameNotRunningError游戲沒開→ 自動拉起并重啟任務GameStuckError卡死→ 記錄錯誤、重啟游戲、等待 10 秒再戰GameBugError客戶端報錯→ 同樣自動重啟GamePageUnknownError頁面未知→ 先查服務器是否維護維護就等不維護才請求人工RequestHumanTakeover無法自愈→ 通知并退出。支撐這套自愈邏輯的還有兩個隱蔽組件點擊/卡死計數器stuck_record、click_record用來識別連點多次畫面無變化的死循環以及錯誤現場保存——save_error_log()會把崩潰前 60 張截圖和日志一起歸檔到log/error/時間戳/目錄并自動對截圖做敏感信息打碼處理。這一手事故黑匣子讓所有崩潰都能事后復盤極大降低了遠端排障成本。失敗的次數同樣被記錄在案同一任務連續失敗 3 次腳本會果斷停止并請求人工接管而不是陷入失敗-重試-再失敗的無底洞。這種有限重試、果斷放棄的哲學值得所有自動化系統的設計者借鑒。多語言與翻譯緩存一份配置四地通用ALAS 服務四服語言適配自然是剛需。它的做法很樸素在module/config/i18n/下放四份 JSONzh-CN、zh-TW、en-US、ja-JP翻譯鍵和配置項一一對應。實現上翻譯資源在進程啟動時一次性加載進內存并做鍵名索引后續查找都是內存字典操作速度極快——但代價是改了翻譯必須重啟后端才生效這既是緩存設計的必然結果也是新手容易踩的坑。值得一提的細節是回退機制某語言缺翻譯時界面會回退顯示鍵名本身而非空白保證 GUI 永遠可讀。這種最壞情況也能用的兜底思路在多語言產品里是性價比極高的做法。常見問題排查出問題時該去哪里找線索理解了上述架構排查問題就有了地圖。ALAS 的日志體系很規整運行日志按配置名寫入log/目錄崩潰現場在log/error/時間戳/含截圖*.png與log.txt。實際排查時建議按三步走看崩潰目錄log/error/下最近的文件夾先讀log.txt末尾的logger.hr分隔線定位是哪個任務、在哪個狀態機里崩的查異常類型若日志出現RequestHumanTakeover說明腳本已放棄自愈多半是配置或游戲側問題若只是GameStuckError通常是網絡或模擬器卡頓屬可自愈范疇驗證配置懷疑是配置問題比如 JSON/YAML 格式錯誤、鍵值越界檢查config/下的用戶配置文件或用重啟后端讓配置與翻譯緩存強制重建。另外若你在改代碼后啟動失敗優先確認config_generated.py是否已重新生成——它是自動化產物手動改動會被下次生成覆蓋這屬于本項目最經典的我改的怎么沒了事故。總結與延伸思考回看整條鏈路alas.py的循環調度負責什么時候做什么config_updater的代碼生成負責配置怎么被理解模板匹配、OCR、透視變換負責畫面怎么被看懂異常分級與自愈負責出錯后怎么活下來——四者咬合才支撐起無縫委托科研、全自動大世界這句項目簡介。它真正的工程價值不在于某個算法的精妙而在于把不確定性系統化地管理起來等待可被打斷、失敗有次數上限、崩潰有黑匣子、配置有單一事實來源。如果沿著這條思路繼續想有幾個延伸方向值得你親自去源碼里驗證翻譯系統的懶加載能否改成文件監聽熱更新從而去掉必須重啟的限制地圖透視的網格預測是否能進一步抽象出通用的任意傾斜視角 UI 標定工具save_error_log的截圖歸檔能否接上訓練集反哺模板匹配的自動化采集ALAS 留給你探索的遠比它已實現的更多。【免費下載鏈接】AzurLaneAutoScriptAzur Lane bot (CN/EN/JP/TW) 碧藍航線腳本 | 無縫委托科研全自動大世界項目地址: https://gitcode.com/gh_mirrors/az/AzurLaneAutoScript創作聲明：本文部分內容由AI輔助生成（AIGC），僅供參考