如何替解讀工具寫有用的產品回饋
有用的產品回饋，會提供足夠資訊，讓維護者理解問題並決定下一步。對解讀工具來說，通常需要分清計算或介面問題，以及對詮釋的不認同。兩者都可能值得處理，但需要的證據不同。
先說明原本想完成什麼任務。「我想比較已完成抽牌的牌張與回答」，交代了一個操作流程；「解讀很糟」則讓人無法確定是缺少輸入、牌張順序錯誤，還是文字說服不了讀者。
只要可行，就用虛構資料重現問題。公開回饋不應要求揭露真人的出生資料、感情經歷或完整對話紀錄。
辨認問題類型
輸入問題涉及什麼資料進了系統，例如日期被更改、個人檔案缺少欄位，或牌序與提供的順序不同。顯示問題涉及介面呈現什麼；推理問題則涉及回答如何使用原本正確的輸入。
例如，一份假設的塔羅問題報告可能指出：抽牌結果把某張牌放在最後一個位置，回答卻在第一個位置討論它。維護者可以調查差異出自儲存結果、畫面呈現，還是 AI 回答。若直接稱為抽牌錯誤，就過早指定了原因。
功能請求需要換一種寫法。若想並排比較兩個回答，應說明目前如何操作，以及比較將支持哪個決定。不要把提議中的介面，描述成已經存在卻失靈的控制項。
建立最小重現步驟
在可丟棄的對話中，以合成內容重試問題。一次移除一項不相關的附件或背景資料，目標是留下仍能保留問題的簡短步驟。若拿掉某個元素後問題消失，這個觀察也應寫入報告。
已檢視的 Mystilink 桌面塔羅原始碼接受 one、three、five、cross、decision 等牌陣識別值，並記錄抽牌已完成或已略過的狀態。回報這條流程的問題時，應交代使用哪個牌陣，以及使用者完成了抽牌，還是關閉了詢問。這能給維護者一個具體的流程分支來檢查。
個人檔案有問題時，請指出受影響的欄位，並使用虛構的替代值。已檢視的出生資料 README 將身分欄位與命盤計算值分開。若差異涉及這些欄位，應交代兩者的標籤與觀察結果，不要為了示範區別而公開原始檔案。
記錄預期，不預先判定原因
寫明預期會發生什麼，以及為何有此預期。畫面上的標籤、文件段落，或先前成功的操作，都可以說明依據。接著準確記錄實際發生的情況。猜測的解釋另用一句話寫，例如：「可能涉及牌位對應，但我尚未確定原因。」
若能取得，請附上應用程式版本與作業系統。報告涉及模型行為時，附上所選模型及連線路徑，但不要提供憑證。已檢視的平台文件區分 Newton 閘道路徑與直接連至供應商的 BYOK，因此路徑資訊可能有助縮小請求行為問題的調查範圍。
避免貼上權杖、供應商金鑰或未遮蔽的請求標頭。若最小重現仍不足，維護者可以再要求較安全的診斷資料。錯誤訊息也應先檢查是否含有可識別身分的細節，才放入報告。
提供足以說明狀態變化的歷程
有些問題在更正或中斷之後才出現。請記錄相關順序：完成抽牌、送出更正、重新開啟對話，然後發現不一致。只有最後狀態的截圖，可能看不出觸發問題的步驟。
已檢視的對話文件說明了紀錄持久化，以及從紀錄延續對話的做法。若問題涉及恢復，請分清已完成的交流與尚待回應的詢問，也註明是在重開同一段對話，還是開始新對話時發生。這些差異可能比報告篇幅更有幫助。
使用簡短摘錄，並附上角色標籤。使用者訊息、工具結果與 AI 答案，是不同的證據。保留角色，才不會讓推測看起來像使用者已提供的輸入。
說明問題造成的負擔
解釋問題讓你無法再做什麼。例如，可能得手動重建牌陣、無法辨認使用了哪份個人檔案，或分享筆記前必須重新附上來源背景。這有助維護者評估實際影響，不必使用誇張措辭。
提出改進時，可以給一個成功行為的例子。若希望匯出內容包含原始問題，可以提供簡短的虛構提問，並說明它在目前流程的哪一步遺失。維護者便能考慮不同的解決方式。
報告結尾列出尚未釐清、但仍能安全提供的資訊。公開後續回覆應聚焦重現方式與結果。若較新版本解決問題，就記下測試版本與步驟。未來讀者因此能取得有用證據，也能避免支援討論串變成對產品每個版本都成立、卻沒有根據的主張。