Bug 報告怎麼寫提示詞：把「用不了了」整理成開發一看就能復現的缺陷單
測試、產品、客服或用戶反饋了問題，要提交到缺陷管理系統（Jira、禪道、飛書項目）時用：把零散的描述、截圖文字、聊天記錄整理成標準缺陷單，寫清復現步驟、期望與實際結果、環境和嚴重程度，並列出還缺的資訊。
通用大模型 對話模型通用
請把下面的問題反饋整理成一份規範的缺陷報告。讀者是負責修復的開發，目標是讓他不用再來回追問就能復現問題。 原始反饋（聊天記錄、用戶描述、截圖裏的文字都可以）： [粘貼原始反饋] 已知環境資訊：[已知環境資訊]（例：iOS 18 + App 3.2.1、Chrome 最新版、測試環境） 缺陷系統的字段要求：[缺陷系統的字段要求]（例：標題、模組、嚴重程度、優先級，沒有就寫預設） 缺陷單結構： 1. 標題：「在哪裏 + 做了什麼 + 出現了什麼問題」，30 字以內，例如「訂單詳情頁點擊申請退款後頁面白屏」。不要寫「有 Bug」「無法使用」這種籠統標題。 2. 環境：端、系統版本、瀏覽器或 App 版本、帳號類型或權限、測試環境還是生產環境、網絡情況。 3. 前置條件：復現需要的數據或狀態，如「帳號有一筆已發貨訂單」。 4. 復現步驟：編號列出，每步一個操作，具體到點擊哪個按鈕、輸入什麼值。 5. 期望結果與實際結果：分開寫；實際結果包括報錯文字、錯誤碼、頁面表現。 6. 復現頻率：必現、偶現（大約幾次中出現幾次）、只出現過一次。 7. 影響範圍與嚴重程度：按「致命 / 嚴重 / 一般 / 輕微」給出建議並說明理由（例如影響支付、是否有繞過辦法、影響多少用戶）。 8. 附加資訊：時間點（便於查日誌）、請求 ID、相關截圖或錄屏的說明。 9. 初步線索（可選）：如果反饋裏有能幫助定位的資訊（比如只有某個版本出現），單獨列出，但不要猜測代碼原因。 原始反饋中缺失、需要找反饋人補充的資訊，列在最後的「待補充」清單裏，寫成可以直接發給對方的問題。 手機號、地址等用戶個人資料在缺陷單裏打碼處理。
高亮處換成你自己的內容：[粘貼原始反饋]、[已知環境資訊]、[缺陷系統的字段要求]
ChatGPT Plus 充值
已被複製 0 次
使用說明
怎麼填變量：[原始反饋] 越原始越好，用戶的原話常常包含關鍵線索（比如「換了 WiFi 就好了」）。[已知環境資訊] 寫多少算多少，缺的部分 AI 會列進「待補充」。
常見坑：
- 復現步驟寫成「進入頁面，操作一下就出錯」，開發無法復現，只能來回追問。每一步都要具體到操作和輸入值。
- 期望和實際混在一起寫，開發不清楚「對的」應該是什麼樣。分開寫。
- AI 可能根據經驗「補全」復現步驟。模板要求缺失資訊列進待補充，提交前要核對步驟是否真實發生過。
追問技巧：開發回覆「無法復現」時，把他的回覆貼回來，問「為了復現，還需要向用戶收集哪些資訊，比如日誌、帳號狀態、操作時間」。
示例輸出
示例，僅供參考
標題：訂單詳情頁點擊「申請退款」後頁面白屏
| 字段 | 內容 |
|---|---|
| 環境 | iOS 18.0，App 3.2.1，生產環境，4G 網絡 |
| 前置條件 | 帳號有一筆「已發貨」狀態的訂單，訂單使用了優惠券 |
| 復現頻率 | 用戶稱連續 3 次都出現（待確認是否必現） |
| 嚴重程度建議 | 嚴重：用戶無法自助退款，但可以通過客服處理 |
復現步驟：
- 進入「我的訂單」，打開該訂單詳情；
- 點擊底部「申請退款」。
期望結果：進入退款申請頁。
實際結果：頁面白屏，約 5 秒後自動返回訂單列表。
待補充：
- 發生問題的大致時間（精確到分鐘），方便查日誌？
- 沒有使用優惠券的訂單是否也會這樣？
同款作品
用這條提示詞做出來的作品；原作者會因此獲得積分
還沒有同款，來做第一個。
0 條評論
還沒有評論，來搶沙發～