用途：当 Bug 难以捉摸、静态读代码已不够时，用定向日志建立可观测性，通过一次带日志的执行缩小排查范围。适用于应用 Bug、后端处理、UI 流程、序列化问题、异步顺序问题、重复副作用、状态机 Bug 等，不绑定具体语言、框架或仓库。
主要能力：决定埋点位置；添加高信号日志；指导用户重跑并回传日志；按顺序重建执行路径，找出首个偏离预期的位置与所属层，判断是重复、数据缺失、边界判断错误、状态过期还是顺序/竞态问题；必要时要求补充最小范围的下一轮日志；最后给出与日志证据直接对应的修复建议。
使用方式：优先使用用户提供或仓库既有的日志前缀；若都没有，选一个在当前代码库中唯一、简短、可搜索的前缀并告知用户收集该前缀。埋点应围绕入口点、状态转换、序列化或转换边界、异步交接点、最终出站效果（发送、保存、渲染、请求、回调）。每条日志包含共享前缀、时间戳、子系统或阶段短标签，以及比较预期与实际所需的最小字段。推荐行格式如 [<PREFIX>][2026-03-28T13:45:27.870+08:00][Serializer] contentList=[0] mention | [1] text，字符串中的换行需转义以保持单行。埋点后明确告知用户：重新构建或重跑、复现一次、收集含该前缀的日志并回传，建议用 rg "[<PREFIX>]" <log-file> 或等价搜索过滤。
分析阶段：不要直接跳到修复，先按顺序读日志，回答首个确认事件、哪些状态被证明正确、第一处现实与预期偏离的行、该偏离属于哪一层、根因类型。指出 Bug 开始的确切转换点，而非仅可见位置。若日志证明当前埋点不足，只要求最小补充集，不要大范围二次采集。输出应简洁且具因果性：日志证明了什么、根因从哪开始、什么不是根因、下一步应改哪段代码。
限制：仅在用户要求日志、已提供日志或静态诊断停滞时使用；避免巨型对象转储、模糊消息和过量日志；时间戳视为标准格式的一部分。具体字段依 Bug 而定，资料未提供固定字段清单。