日志怎么打提示词：日志级别规范、结构化日志与敏感信息脱敏（附改写对照）
线上出问题翻日志却找不到有用信息、或者日志太多太乱时用：让 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 条评论
还没有评论，来抢沙发～