LobeHub 可观测性评审实践Debug 日志、产品分析与性能监控的三道关卡【免费下载链接】lobehub LobeHub is your Chief Agent Operator, organizing your agents into 7×24 operations by hiring, scheduling, and reporting on your entire AI team.项目地址: https://gitcode.com/GitHub_Trending/lo/lobehub本文基于 LobeHub 仓库中的深度评审deep-review技能参考文档 observability.md系统讲解该仓库如何把「可观测性」拆分为 Debug、Product产品分析、Performance性能监控三个子维度来做代码评审。读完本文你能掌握这套评审维度的判定标准、仓库中对应的日志命名规范、analytics?.track()埋点体系和 OpenTelemetry 后端埋点实现并学会用文档中的检查清单与rg检索命令对一次 diff 做完整的可观测性审查。维度定位deep-review 技能中的 Observability 参考该文档是 LobeHub Agent 技能体系.agents/skills/deep-review/中一个评审维度的参考规范其 front matter 声明了维度的元信息--- id_prefix: obs verify: true skip_when: no error handling, async flow, server code, new user-facing capability, or perf-sensitive path touched ---id_prefix: obs该维度产出的评审发现finding统一以obs作为前缀编号verify: true发现需要进一步验证后才成立skip_when明确跳过条件——如果本次改动没有触及错误处理、异步流程、服务端代码、新的用户可见能力或性能敏感路径则整个维度可以直接跳过不产生噪音。维度开篇用三个问题定义了「可观测性」的边界核心是**「这次改动上线后我们能看见什么」**Debug六个月后这段代码出问题时排障的人甚至可能是 Agent能否看出发生了什么、以及代码为什么是这样写的Product我们能否知道这个功能是否被使用数据能否告诉我们下一步该做什么Performance如果它在真实流量下变慢或变贵有没有任何东西会注意到文档特别强调第 2、3 问的门槛故意设得很窄——大多数改动两者都不需要。泛泛的「应该加点埋点」建议是噪音而不是发现只有满足各节中的判定条件qualifying criteria时缺失的埋点才算真正的评审发现。Debug 维度让代码在六个月后仍然可读检查清单文档给出的 Debug 侧检查项全部围绕「冷静状态下读日志能否定位问题」展开Bug fix 没有注释解释为什么尤其是非显而易见的 workaround未来的读者会把它「简化」回 bug如果存在相关 issue/PR 应附上链接。Hacky 或令人意外的代码没有注释说明约束来源workaround 来自上游 issue 或 SO 回答时应附参考链接。吞掉错误的catch块没有日志、没有 rethrow、没有用户反馈——静默失败是最贵的一种。关键路径在决策点没有日志支付类流程、数据迁移、鉴权状态切换、跨系统调用成功路径和错误路径同样重要。新日志使用debug包并带规范的lobe-*命名空间而不是散落的console.*。日志行在「冷读」时无用缺少标识符哪个用户哪个实体或者整个对象 dump 而不挑出有区分度的字段。仓库中的日志规范debug包与lobe-*命名空间文档要求「新日志必须走debug包」仓库中对应的完整规范见 debug-package 技能文档。其核心约定如下命名空间约定格式为lobe-[module]:[submodule]运行环境命名空间前缀桌面端Electronlobe-desktop:[module]服务端lobe-server:[module]客户端浏览器lobe-client:[module]路由层lobe-[type]-router:[module]格式说明符%O—— 对象展开复杂对象推荐%o—— 对象%s—— 字符串%d—— 数字启用 debug 输出的方式按环境区分// 浏览器 localStorage.debug lobe-*;# Node.js DEBUGlobe-* npm run dev DEBUGlobe-* pnpm dev// Electron process.env.DEBUG lobe-*;文档中还给出了一个真实示例来自apps/server/src/routers/edge/market/index.tsimport debug from debug; const log debug(lobe-edge-router:market); log(getAgent input: %O, input);这套「命名空间 格式说明符」的约定正是 Debug 维度检查项「新日志使用debug包并带lobe-*命名空间」的判定依据——评审时可以据此检查 diff 中新增的日志是否遵循了统一约定而不是随手写console.log。Product 维度产品分析的判定标准是「有没有决策在等这份数据」这是整个维度中最反直觉的部分。文档明确指出检验标准不是「我们是否记录了用户做了某件事」而是——「是否有决策在等待这份数据」埋点应当加在「数据能形成产品闭环」的地方只会产出一个没人行动的数字的地方不加。五种「应当埋点」的形态当新能力落入以下任一类形状时缺少analytics?.track()调用即为评审发现用户自供的查询User-supplied queries搜索、过滤器、命令面板、任何自由文本输入。「未命中」比「命中」更有价值——一次返回空结果的搜索是产品缺少什么的最强信号。要求捕获的是查询的形状而非文本结果数量0 才是真正的事件、当时生效的过滤器/范围、输入长度、延迟。把原始查询文本记下来的提案直接越界见「Not violations」中的 PII 条目——miss 率已经足以回答产品问题。新的入口点或能力没有采用率数据日后就无法判断该继续投入还是删除而这个问题迟早会到来。多步骤流程注册、结账、onboarding、任何向导。逐步事件才是把「转化率不行」变成「第 3 步不行」的关键。曾有争议或可回退的决策当 PR/issue 记录了分歧或明确的「先试试看」事件就是日后裁决的依据。回退或降级路径回退触发的频率决定了主路径是否值得修复。未被度量的回退会静默地变成永久状态。事件质量要求当确实要加事件时需要稳定的事件名以及可以让事件被切片的属性哪个 surface、哪个 variant、什么结果。没有属性的事件只是一个计数器而计数器很少能回答下一个问题。仓库中的埋点体系src/components/Analytics/文档在「Rule sources」一节指定评审前应查阅src/components/Analytics/中已有的analytics?.track()provider 与事件形状「先对齐既有约定再发明新事件名」。从仓库源码看该目录维护了一个多 provider 的分析栈Analytics 入口组件 根据环境开关条件挂载各分析脚本Vercel Speed Insights、Google AnalyticsGA4、X Ads Pixel、Plausible、Umami、Clarity、React Scan Monitor以及桌面端专用的Desktop组件。例如 Plausible 需要domain与scriptBaseUrlUmami 需要websiteId与scriptUrl全部由analyticsEnv见src/envs/analytics中的环境变量驱动。LobeAnalyticsProvider 封装了基于lobehub/analytics的单例客户端通过createSingletonAnalytics创建 GA4、PostHog、X Ads 三个 provider并用模块级变量analyticsInstance保证 StrictMode/多挂载下只创建一次初始化成功后会调用setGlobalContext({ platform: isDesktop ? desktop : web })把平台维度作为全局上下文注入所有后续事件——这正是「事件要有可切片属性」这一条在实现层的体现。评审时对照这些既有约定可以判断新事件的命名与属性是否与已有 provider 能力匹配。Performance 维度成本可见性而不是到处加计时器五种「应当有成本可见性」的路径新增或改动的代码若落在以下任一路径应当随附「看到它成本」的手段高频交互命令面板、输入即搜、任何按按键或按列表渲染触发一次的东西。高流量入口首页、落地页、登录后第一屏。分母极大一个小回归会被放大成大回归而且最不可能被人工注意到。轮询或定时任务总请求数 用户数 × 频率 × 会话时长所以它先是成本问题再是延迟问题——成本除非有人在某处度量请求量否则不可见。轮询循环本身是否会退避、停止、可调是performance维度的职责不是本维度的。向同步或阻塞路径新增的网络调用尤其是模型/LLM 调用或延迟不受控的第三方 API。对无界数据的渲染规模随真实使用量增长的列表或计算。「看到成本」具体指什么文档给出了非常具体的定义延迟要看百分位不要看平均值——平均值会掩盖用户真实感受到的长尾需要错误/超时率轮询类需要请求量。并且明确划定了技术边界后端路径走packages/observability-otel的 OTEL 埋点前端页面级成本已由 Vercel Speed Insights 覆盖为页面加载再加一个自研计时器通常是冗余的——评审时应当直接说明而不是提这种建议。仓库中的 OTEL 实现packages/observability-otel文档指定该包是后端 tracing/metrics 的埋点入口。从源码看node.tsregister()函数构建了一个开箱即用的NodeSDK资源属性attributesCommon()固定service.name lobehub每个 Node.js 进程生成一个service.instance.id注释解释了原因单个不透明 ID 对应 Vercel 实例生命周期包括 Fluid Compute 在并发调用间的复用并自动携带 Vercel 部署属性vercel.region、vercel.deployment_id、service.version等与 Node 环境属性node.env、node.ci自动插桩默认注册PgInstrumentation、HttpInstrumentation与getNodeAutoInstrumentations()可通过autoInstrumentations: false关闭指标导出PeriodicExportingMetricReaderOTLPMetricExporter导出间隔默认 1000ms可用环境变量OTEL_METRICS_EXPORTER_INTERVAL覆盖解析失败时保留默认值Tracing 导出BatchSpanProcessorOTLPTraceExporter支持通过RegisterOptions注入自定义spanProcessors、sampler与histogramViews显式桶边界直方图诊断日志OTEL_JS_LOBEHUB_DIAG环境变量可把 SDK 内部诊断日志级别设为none/error/warn/info/debug/verbose/all优雅关停shutdownSafely()保证 exporter 关停失败只写诊断日志不改变调用方的业务结果或退出状态——这本身就是文档 Debug 清单「关键路径在决策点有可观察行为」的一个实现范例。api.ts 则统一对外重导出opentelemetry/api的核心符号context、diag、metrics、propagation、trace、SpanKind、SpanStatusCode等让业务代码只依赖本包的类型不直接耦合 OTEL 的具体实现版本。Rule Sourcesdeep 模式下评审前必读的四个来源文档列出了该维度在「deep 模式」下评审前必须通读的规则来源均位于本仓库内debug-package 技能文档 —— 命名空间约定与格式说明符规范仓库的CLAUDE.md/AGENTS.md中的注释规则 —— 强制注释场景复杂逻辑、取舍权衡、参考链接src/components/Analytics/ ——analytics?.track()provider 与已有事件形状先对齐再发明packages/observability-otel/ —— 后端 tracing/metrics 埋点。How to Check可复现的五步审查流程文档给出了针对一次 diff 的可操作检查流程其中两条依赖rgripgrep检索可直接复制执行rg catch changed files—— 逐一阅读本次 diff 新增/修改的每个 catch 块归类为已记录 / 已 rethrow / 已上抛给用户 / 被吞掉四类对 diff 中的每个修复检查同一 hunk 内是否存在解释性注释且注释解释的是为什么why而不是做什么what沿新服务端流程的主执行路径走一遍数一数有多少个可观察检查点对任何新的用户可见能力与上文「五种应当埋点形态」逐一比对若命中用rg analytics\?\.track在功能周边检索是否已埋点。提案新事件时必须指名事件名和属性并说明这份数据支撑哪个决策——如果说不出那个决策就不要上报对任何落在「性能判定形态」上的改动找到间隔/频率/调用点写出算术每按键一次每用户每分钟一次× 多少用户然后确认该流量与延迟在上线后是否落在某个有人能读到的地方。Violations 与 Not Violations明确划界避免评审噪音构成违规Violations本次 diff 引入的被吞掉的错误、无注释的 hack、无解释的修复一个新的多步骤流程其失败仅凭日志将无法诊断一个命中判定形态的新能力上线时没有任何分析事件而某个具名的决策依赖这份数据——最典型的是搜索/查询界面不记录未命中一条落在高流量或高频路径含轮询上的新调用上线后没有任何手段看到它的延迟或请求量。不构成违规Not violations平凡纯函数或结果可见的纯 UI 处理函数缺少日志注释/日志密度与同等既有流程持平校准原则——但静默 catch 永远是发现不享受此豁免明确声明了忽略原因的有意忽略// ignore: reason未命中任何判定形态的场景缺少分析视觉/样式改动、内部工具、脚本、Agent 技能、无行为变化的重构。「多一点埋点就好了」不是发现会与服务端日志或数据库已记录数据重复的事件——数据已存在查一下即可会捕获用户内容、超出既有约定标识符或任何 PII 形态的分析提案——不要提这类提案如果 diff 里已经这么做了那属于security维度的发现不是本维度为 Speed Insights 或既有 OTEL span 已覆盖的对象加自研计时器要求为冷路径、管理界面或一次性脚本做性能埋点。小结窄门槛 校准原则的可观测性评审这套 Observability 维度规范 的设计精髓在于双向防噪用「五种判定形态」抬高 Debug 之外的门槛避免「应该加点埋点」式的噪音发现用「Not violations」清单压低误报让静默 catch 这类问题被单独拎出来永不被豁免。而它并非悬空的标准——每一条检查项在 LobeHub 仓库中都有落点debug包的lobe-*命名空间规范debug-package/SKILL.md、多 provider 分析栈src/components/Analytics/、以及带 Vercel 资源属性与 OTLP 导出的 OTEL SDK 封装packages/observability-otel/。对贡献者而言按「How to check」五步流程自检一次 diff再对照 Violations/Not Violations 划界就能在提交前回答文档开头的三个问题六个月后能不能 debug、数据能不能驱动下一个决策、变慢变贵时有没有人会发现。【免费下载链接】lobehub LobeHub is your Chief Agent Operator, organizing your agents into 7×24 operations by hiring, scheduling, and reporting on your entire AI team.项目地址: https://gitcode.com/GitHub_Trending/lo/lobehub创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 LobeHub 可观测性评审实践：Debug 日志、产品分析与性能监控的三道关卡
LobeHub 可观测性评审实践Debug 日志、产品分析与性能监控的三道关卡【免费下载链接】lobehub LobeHub is your Chief Agent Operator, organizing your agents into 7×24 operations by hiring, scheduling, and reporting on your entire AI team.项目地址: https://gitcode.com/GitHub_Trending/lo/lobehub本文基于 LobeHub 仓库中的深度评审deep-review技能参考文档 observability.md系统讲解该仓库如何把「可观测性」拆分为 Debug、Product产品分析、Performance性能监控三个子维度来做代码评审。读完本文你能掌握这套评审维度的判定标准、仓库中对应的日志命名规范、analytics?.track()埋点体系和 OpenTelemetry 后端埋点实现并学会用文档中的检查清单与rg检索命令对一次 diff 做完整的可观测性审查。维度定位deep-review 技能中的 Observability 参考该文档是 LobeHub Agent 技能体系.agents/skills/deep-review/中一个评审维度的参考规范其 front matter 声明了维度的元信息--- id_prefix: obs verify: true skip_when: no error handling, async flow, server code, new user-facing capability, or perf-sensitive path touched ---id_prefix: obs该维度产出的评审发现finding统一以obs作为前缀编号verify: true发现需要进一步验证后才成立skip_when明确跳过条件——如果本次改动没有触及错误处理、异步流程、服务端代码、新的用户可见能力或性能敏感路径则整个维度可以直接跳过不产生噪音。维度开篇用三个问题定义了「可观测性」的边界核心是**「这次改动上线后我们能看见什么」**Debug六个月后这段代码出问题时排障的人甚至可能是 Agent能否看出发生了什么、以及代码为什么是这样写的Product我们能否知道这个功能是否被使用数据能否告诉我们下一步该做什么Performance如果它在真实流量下变慢或变贵有没有任何东西会注意到文档特别强调第 2、3 问的门槛故意设得很窄——大多数改动两者都不需要。泛泛的「应该加点埋点」建议是噪音而不是发现只有满足各节中的判定条件qualifying criteria时缺失的埋点才算真正的评审发现。Debug 维度让代码在六个月后仍然可读检查清单文档给出的 Debug 侧检查项全部围绕「冷静状态下读日志能否定位问题」展开Bug fix 没有注释解释为什么尤其是非显而易见的 workaround未来的读者会把它「简化」回 bug如果存在相关 issue/PR 应附上链接。Hacky 或令人意外的代码没有注释说明约束来源workaround 来自上游 issue 或 SO 回答时应附参考链接。吞掉错误的catch块没有日志、没有 rethrow、没有用户反馈——静默失败是最贵的一种。关键路径在决策点没有日志支付类流程、数据迁移、鉴权状态切换、跨系统调用成功路径和错误路径同样重要。新日志使用debug包并带规范的lobe-*命名空间而不是散落的console.*。日志行在「冷读」时无用缺少标识符哪个用户哪个实体或者整个对象 dump 而不挑出有区分度的字段。仓库中的日志规范debug包与lobe-*命名空间文档要求「新日志必须走debug包」仓库中对应的完整规范见 debug-package 技能文档。其核心约定如下命名空间约定格式为lobe-[module]:[submodule]运行环境命名空间前缀桌面端Electronlobe-desktop:[module]服务端lobe-server:[module]客户端浏览器lobe-client:[module]路由层lobe-[type]-router:[module]格式说明符%O—— 对象展开复杂对象推荐%o—— 对象%s—— 字符串%d—— 数字启用 debug 输出的方式按环境区分// 浏览器 localStorage.debug lobe-*;# Node.js DEBUGlobe-* npm run dev DEBUGlobe-* pnpm dev// Electron process.env.DEBUG lobe-*;文档中还给出了一个真实示例来自apps/server/src/routers/edge/market/index.tsimport debug from debug; const log debug(lobe-edge-router:market); log(getAgent input: %O, input);这套「命名空间 格式说明符」的约定正是 Debug 维度检查项「新日志使用debug包并带lobe-*命名空间」的判定依据——评审时可以据此检查 diff 中新增的日志是否遵循了统一约定而不是随手写console.log。Product 维度产品分析的判定标准是「有没有决策在等这份数据」这是整个维度中最反直觉的部分。文档明确指出检验标准不是「我们是否记录了用户做了某件事」而是——「是否有决策在等待这份数据」埋点应当加在「数据能形成产品闭环」的地方只会产出一个没人行动的数字的地方不加。五种「应当埋点」的形态当新能力落入以下任一类形状时缺少analytics?.track()调用即为评审发现用户自供的查询User-supplied queries搜索、过滤器、命令面板、任何自由文本输入。「未命中」比「命中」更有价值——一次返回空结果的搜索是产品缺少什么的最强信号。要求捕获的是查询的形状而非文本结果数量0 才是真正的事件、当时生效的过滤器/范围、输入长度、延迟。把原始查询文本记下来的提案直接越界见「Not violations」中的 PII 条目——miss 率已经足以回答产品问题。新的入口点或能力没有采用率数据日后就无法判断该继续投入还是删除而这个问题迟早会到来。多步骤流程注册、结账、onboarding、任何向导。逐步事件才是把「转化率不行」变成「第 3 步不行」的关键。曾有争议或可回退的决策当 PR/issue 记录了分歧或明确的「先试试看」事件就是日后裁决的依据。回退或降级路径回退触发的频率决定了主路径是否值得修复。未被度量的回退会静默地变成永久状态。事件质量要求当确实要加事件时需要稳定的事件名以及可以让事件被切片的属性哪个 surface、哪个 variant、什么结果。没有属性的事件只是一个计数器而计数器很少能回答下一个问题。仓库中的埋点体系src/components/Analytics/文档在「Rule sources」一节指定评审前应查阅src/components/Analytics/中已有的analytics?.track()provider 与事件形状「先对齐既有约定再发明新事件名」。从仓库源码看该目录维护了一个多 provider 的分析栈Analytics 入口组件 根据环境开关条件挂载各分析脚本Vercel Speed Insights、Google AnalyticsGA4、X Ads Pixel、Plausible、Umami、Clarity、React Scan Monitor以及桌面端专用的Desktop组件。例如 Plausible 需要domain与scriptBaseUrlUmami 需要websiteId与scriptUrl全部由analyticsEnv见src/envs/analytics中的环境变量驱动。LobeAnalyticsProvider 封装了基于lobehub/analytics的单例客户端通过createSingletonAnalytics创建 GA4、PostHog、X Ads 三个 provider并用模块级变量analyticsInstance保证 StrictMode/多挂载下只创建一次初始化成功后会调用setGlobalContext({ platform: isDesktop ? desktop : web })把平台维度作为全局上下文注入所有后续事件——这正是「事件要有可切片属性」这一条在实现层的体现。评审时对照这些既有约定可以判断新事件的命名与属性是否与已有 provider 能力匹配。Performance 维度成本可见性而不是到处加计时器五种「应当有成本可见性」的路径新增或改动的代码若落在以下任一路径应当随附「看到它成本」的手段高频交互命令面板、输入即搜、任何按按键或按列表渲染触发一次的东西。高流量入口首页、落地页、登录后第一屏。分母极大一个小回归会被放大成大回归而且最不可能被人工注意到。轮询或定时任务总请求数 用户数 × 频率 × 会话时长所以它先是成本问题再是延迟问题——成本除非有人在某处度量请求量否则不可见。轮询循环本身是否会退避、停止、可调是performance维度的职责不是本维度的。向同步或阻塞路径新增的网络调用尤其是模型/LLM 调用或延迟不受控的第三方 API。对无界数据的渲染规模随真实使用量增长的列表或计算。「看到成本」具体指什么文档给出了非常具体的定义延迟要看百分位不要看平均值——平均值会掩盖用户真实感受到的长尾需要错误/超时率轮询类需要请求量。并且明确划定了技术边界后端路径走packages/observability-otel的 OTEL 埋点前端页面级成本已由 Vercel Speed Insights 覆盖为页面加载再加一个自研计时器通常是冗余的——评审时应当直接说明而不是提这种建议。仓库中的 OTEL 实现packages/observability-otel文档指定该包是后端 tracing/metrics 的埋点入口。从源码看node.tsregister()函数构建了一个开箱即用的NodeSDK资源属性attributesCommon()固定service.name lobehub每个 Node.js 进程生成一个service.instance.id注释解释了原因单个不透明 ID 对应 Vercel 实例生命周期包括 Fluid Compute 在并发调用间的复用并自动携带 Vercel 部署属性vercel.region、vercel.deployment_id、service.version等与 Node 环境属性node.env、node.ci自动插桩默认注册PgInstrumentation、HttpInstrumentation与getNodeAutoInstrumentations()可通过autoInstrumentations: false关闭指标导出PeriodicExportingMetricReaderOTLPMetricExporter导出间隔默认 1000ms可用环境变量OTEL_METRICS_EXPORTER_INTERVAL覆盖解析失败时保留默认值Tracing 导出BatchSpanProcessorOTLPTraceExporter支持通过RegisterOptions注入自定义spanProcessors、sampler与histogramViews显式桶边界直方图诊断日志OTEL_JS_LOBEHUB_DIAG环境变量可把 SDK 内部诊断日志级别设为none/error/warn/info/debug/verbose/all优雅关停shutdownSafely()保证 exporter 关停失败只写诊断日志不改变调用方的业务结果或退出状态——这本身就是文档 Debug 清单「关键路径在决策点有可观察行为」的一个实现范例。api.ts 则统一对外重导出opentelemetry/api的核心符号context、diag、metrics、propagation、trace、SpanKind、SpanStatusCode等让业务代码只依赖本包的类型不直接耦合 OTEL 的具体实现版本。Rule Sourcesdeep 模式下评审前必读的四个来源文档列出了该维度在「deep 模式」下评审前必须通读的规则来源均位于本仓库内debug-package 技能文档 —— 命名空间约定与格式说明符规范仓库的CLAUDE.md/AGENTS.md中的注释规则 —— 强制注释场景复杂逻辑、取舍权衡、参考链接src/components/Analytics/ ——analytics?.track()provider 与已有事件形状先对齐再发明packages/observability-otel/ —— 后端 tracing/metrics 埋点。How to Check可复现的五步审查流程文档给出了针对一次 diff 的可操作检查流程其中两条依赖rgripgrep检索可直接复制执行rg catch changed files—— 逐一阅读本次 diff 新增/修改的每个 catch 块归类为已记录 / 已 rethrow / 已上抛给用户 / 被吞掉四类对 diff 中的每个修复检查同一 hunk 内是否存在解释性注释且注释解释的是为什么why而不是做什么what沿新服务端流程的主执行路径走一遍数一数有多少个可观察检查点对任何新的用户可见能力与上文「五种应当埋点形态」逐一比对若命中用rg analytics\?\.track在功能周边检索是否已埋点。提案新事件时必须指名事件名和属性并说明这份数据支撑哪个决策——如果说不出那个决策就不要上报对任何落在「性能判定形态」上的改动找到间隔/频率/调用点写出算术每按键一次每用户每分钟一次× 多少用户然后确认该流量与延迟在上线后是否落在某个有人能读到的地方。Violations 与 Not Violations明确划界避免评审噪音构成违规Violations本次 diff 引入的被吞掉的错误、无注释的 hack、无解释的修复一个新的多步骤流程其失败仅凭日志将无法诊断一个命中判定形态的新能力上线时没有任何分析事件而某个具名的决策依赖这份数据——最典型的是搜索/查询界面不记录未命中一条落在高流量或高频路径含轮询上的新调用上线后没有任何手段看到它的延迟或请求量。不构成违规Not violations平凡纯函数或结果可见的纯 UI 处理函数缺少日志注释/日志密度与同等既有流程持平校准原则——但静默 catch 永远是发现不享受此豁免明确声明了忽略原因的有意忽略// ignore: reason未命中任何判定形态的场景缺少分析视觉/样式改动、内部工具、脚本、Agent 技能、无行为变化的重构。「多一点埋点就好了」不是发现会与服务端日志或数据库已记录数据重复的事件——数据已存在查一下即可会捕获用户内容、超出既有约定标识符或任何 PII 形态的分析提案——不要提这类提案如果 diff 里已经这么做了那属于security维度的发现不是本维度为 Speed Insights 或既有 OTEL span 已覆盖的对象加自研计时器要求为冷路径、管理界面或一次性脚本做性能埋点。小结窄门槛 校准原则的可观测性评审这套 Observability 维度规范 的设计精髓在于双向防噪用「五种判定形态」抬高 Debug 之外的门槛避免「应该加点埋点」式的噪音发现用「Not violations」清单压低误报让静默 catch 这类问题被单独拎出来永不被豁免。而它并非悬空的标准——每一条检查项在 LobeHub 仓库中都有落点debug包的lobe-*命名空间规范debug-package/SKILL.md、多 provider 分析栈src/components/Analytics/、以及带 Vercel 资源属性与 OTLP 导出的 OTEL SDK 封装packages/observability-otel/。对贡献者而言按「How to check」五步流程自检一次 diff再对照 Violations/Not Violations 划界就能在提交前回答文档开头的三个问题六个月后能不能 debug、数据能不能驱动下一个决策、变慢变贵时有没有人会发现。【免费下载链接】lobehub LobeHub is your Chief Agent Operator, organizing your agents into 7×24 operations by hiring, scheduling, and reporting on your entire AI team.项目地址: https://gitcode.com/GitHub_Trending/lo/lobehub创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考