提升桌面自動化可靠性：等待狀態，而非只等時間
Make desktop automations reliable: wait for state, not just time
桌面自動化要提升可靠性，應等待可觀察的介面狀態，而非依賴固定延遲。偽代碼示例以 10 seconds 設定截止時間、每 200 milliseconds 檢查一次；逾時時應清楚報錯或進入復原分支，可能造成重複效果的操作不應盲目重試。作者建議測試快速及刻意放慢的情況，並檢查元素缺失、視窗尺寸改變和顯示縮放不同時的表現；該示例並非經測試的實作。
Desktop automations often work perfectly on the developer’s machine, then fail on a slower computer, a busy browser, or a screen that loads in a different order.
A common cause is relying on fixed delays:
click “Continue”
wait 5 seconds
click “Save”
Five seconds may be wasteful when the page is ready in half a second—and still too short when the machine is busy. The workflow is waiting for a guess, not for the thing it actually needs.
Wait for a condition, with a deadline
Prefer an observable signal: a button becomes visible, a dialog closes, a window appears, or expected text is present. Keep a timeout so the automation cannot wait forever.
deadline = current_time + 10 seconds
while current_time < deadline:
if the expected button is visible:
click it
continue the workflow
wait 200 milliseconds
stop with a clear error: “The expected button did not appear”
This is pseudocode; the signal depends on the app and automation tool. Image matching, accessible controls, window state, and OCR each have different trade-offs. Use the most reliable signal available for that screen.
Make the failure path safe
A timeout is useful only if the next step is safe. Decide what happens when the condition never appears: stop and explain what was missing, capture diagnostic context if appropriate, or route to a recovery branch. Avoid blindly repeating actions that submit a form, send a message, delete data, or trigger a payment. A retry is safe only when repeating the action cannot create a duplicate or other unwanted effect.
Test both the fast path and the slow path
Run the workflow when the app is responsive and when it is deliberately slowed down. Also test a missing element, a changed window size, and a different display scale. A workflow that handles these cases is easier to trust and debug than one tuned to a single timing.
I’m building macro8n, a local-first desktop app for visual automation workflows. I’m interested in the small design choices that make automations dependable in real environments. What step in your desktop workflows is most likely to fail because timing or screen state changes?
AI disclosure: This draft was prepared with AI assistance. The example above is pseudocode, not a tested implementation.
來源：DEV Community · dev.to