日誌怎麼打提示詞：日誌級別規範、結構化日誌與敏感資料脫敏（附改寫對照）
線上出問題翻日誌卻找不到有用資訊、或者日誌太多太亂時用：讓 AI 審查一段代碼的日誌寫法，按統一的級別規範和結構化格式改寫，補上排查必需的上下文字段，並去掉密碼、手機號等不該打的內容。
通用大模型 對話模型通用
請作為一名負責線上穩定性的工程師，審查並改進下面代碼中的日誌。 資訊： - 語言與日誌庫：[語言與日誌庫]（例：Java + SLF4J/Logback） - 日誌最終去向：[如 ELK、雲日誌服務、只在伺服器文件裏] - 團隊已有的日誌約定：[沒有就寫無] - 代碼： [粘貼代碼] 先給出一份適合我們的日誌規範（簡短，可以直接放進團隊文檔）： - 每個級別的使用標準：ERROR（需要人處理的失敗）、WARN（異常但已自動處理，如重試成功、降級）、INFO（關鍵業務節點，如訂單創建、狀態變化）、DEBUG（排查細節，線上預設關閉）； - 每條日誌必須帶的字段：時間、級別、服務名、trace id 或請求 id、關鍵業務 id； - 消息寫法：用固定的事件名加字段，不要把變量拼進句子裏； - 禁止記錄的內容：密碼、令牌、完整身份證號和銀行卡號、完整手機號，以及大段的請求體和響應體。 然後按規範審查代碼，逐條指出： 1. 級別用錯的（比如可預期的用戶輸入錯誤打成 ERROR，會觸發無意義的告警）； 2. 缺少上下文、出問題時無法定位的； 3. 吞掉異常、或者只打印異常消息丟了堆棧的； 4. 同一個錯誤在多層重複打印的； 5. 在循環裏打日誌、可能刷屏的； 6. 包含敏感資料的，給出脫敏寫法。 最後輸出改寫後的代碼，並給出一個「改寫前 / 改寫後」的日誌輸出對照示例。
高亮處換成你自己的內容：[語言與日誌庫]、[如 ELK、雲日誌服務、只在伺服器文件裏]、[沒有就寫無]、[粘貼代碼]
ChatGPT Plus 充值
已被複製 0 次
使用說明
怎麼填變量：[日誌最終去向] 會影響建議：進了 ELK 這類日誌平台，就應該輸出 JSON 結構化日誌方便按字段檢索；只看伺服器文件的，可讀性更重要。[團隊已有的日誌約定] 有就貼上，AI 會在現有約定上補充而不是推翻。
常見坑：
- 把用戶輸錯密碼、參數校驗失敗這類正常情況打成 ERROR，告警響個不停，真正的故障反而被淹沒。
- 異常只打印
e.getMessage()，丟掉了堆棧；或者在每一層都 catch 打印一遍再拋出，同一個錯誤出現五次。原則是：要麼處理並記錄，要麼往上拋，不要兩樣都做。 - 「先打出來再說」地記錄整個請求體，很容易把手機號、地址甚至密碼寫進日誌，日誌系統通常比數據庫的權限管控更松。
追問技巧：追問「把我們最常見的三類故障（如支付失敗、接口超時、庫存不足）各寫一條理想的日誌，說明排查時會用哪些字段過濾」。
示例輸出
示例，僅供參考（改寫對照）
改寫前：
ERROR 下單失敗 用戶13812345678 token=eyJhbGciOi... 錯誤: 庫存不足改寫後（JSON 結構化，庫存不足屬於可預期的業務拒絕，降為 WARN）：
json
{"level":"WARN","event":"order_create_rejected","reason":"out_of_stock","order_id":"O20261003001","user_id":10086,"phone":"138****5678","trace_id":"7f3a9c2e"}| 問題 | 位置 | 修改 |
|---|---|---|
| 打印完整 token | 第 22 行 | 刪除，不記錄任何令牌 |
| 只打印異常消息 | 第 40 行 | 把異常對象作為最後一個參數傳給日誌方法，保留堆棧 |
同款作品
用這條提示詞做出來的作品；原作者會因此獲得積分
還沒有同款，來做第一個。
0 條評論
還沒有評論，來搶沙發～