整理資訊再求助

求助前先整理

如果只說「不能動」或「不知道哪裡錯」，其他人通常也只能重新陪你從頭檢查。

• 使用的設備、軟體、版本與操作環境。
• 預期結果與實際現象。
• 已經查過的文件或關鍵字。
• 做過哪些測試，以及每次測試的結果。
• 目前無法判斷的具體位置。

錯誤案例：只傳一張圖片

有一次，別人傳了一張機械手臂的照片給我，只問了一句：「為什麼是斜的？」

我看到後，第一個反應是回一個問號，因為我不知道他到底想表達什麼。

對提問者來說，問題可能很明顯：機械手臂移動到某個點位後， 工具的角度和預期不一樣。但對收到訊息的人來說， 「斜的」可能有很多原因。

可能是拍攝角度、工具安裝、TCP 設定、User Frame 設定、點位姿態， 也可能是程式執行時使用了錯誤的 Tool Frame 或 User Frame。 我的腦中可以出現很多種可能，但這則訊息沒有提供任何資訊讓我聚焦。

我不是完全無法猜，而是不想先替提問者猜他做過哪些設定、 指的是哪個角度，以及原本預期看到什麼。

原本幾秒就能回答的問題

這個問題最後的原因是 User Frame 沒有設定正確。 如果對方一開始就把相關設定傳給我，我可能幾秒內就能判斷問題方向。

例如，我需要知道：

• 目前使用哪一組 Tool Frame，TCP 是如何設定的？
• 目前使用哪一組 User Frame，User Frame 是如何建立的？
• 程式實際使用的 UTOOL_NUM 與 UFRAME_NUM 是多少？
• 該點位的 X、Y、Z、W、P、R 數值是多少？
• 原本預期工具應該朝向哪個方向？
• 是只有這個點位異常，還是其他點位也有相同情況？

有這些資訊時，我可以快速把問題聚焦到 TCP、User Frame 或點位姿態； 沒有這些資訊時，我只能先回一個問號，再重新追問對方到底設定了什麼。

原本五秒可能就能回答的問題，會因為資訊不足，變成數次來回確認。 而當我必須先替對方整理問題時，我回答的意願也會降低。

整理本身也能幫助判斷

整理設備、設定、預期結果與測試紀錄，不只是方便別人回答， 也能迫使自己重新確認問題的條件。很多時候，原因會在整理過程中自己浮現。