一份机器人周报写“处理了很多问题”，信息太少；写“自动解决率92%”，却不说明什么算解决，信息也未必更多。先把事件、Issue和结果分开，数字才有可解释的分母。

10月14日Claude平台发布说明列出OpenTelemetry导出beta。官方文档还区分默认元数据导出与可选完整内容导出。观测能力有用，但采集更多内容不等于统计口径自然正确，更不意味着可以随意保存用户原文。

投递次数不是问题数量

一个Issue可能触发opened、edited和多次comment事件，同一次事件还可能重新投递。周报的入口应说明统计唯一投递、唯一Issue还是独立会话，不能把它们混在一起。

同一个问题先请求补充、再由人工接管，可能跨越多个状态。统计时选择期末状态或完整迁移次数，并写清规则。图中ANSWERED、HUMAN、NEED INFO是示例分类，不暗示真实项目已有这些成绩。

发出答案不等于问题解决

ANSWERED只表示回复已发出；解决需要额外证据，比如用户确认、复现通过或维护者关闭。没有确认时保留unknown，比把沉默用户都算成功更诚实。

误答需要独立记录。机器人可能很快回复，却给出了错误版本的命令；单看响应时间会奖励这种行为。保留抽样方法和误答纠正记录，才知道后续改动是否有帮助。

用小样本检查去重与状态口径

下面三次投递里，只有两个Issue。相同delivery id被忽略，同一个Issue采用最后一条已接受状态。所有记录都是测试夹具。

import assert from 'node:assert/strict';
function summarize(events) {
 const deliveries=new Set(),issues=new Map();
 for(const e of events){if(deliveries.has(e.delivery))continue;deliveries.add(e.delivery);issues.set(e.issue,e.status);}
 const counts={answered:0,human:0,need_info:0};
 for(const s of issues.values()){if(!Object.hasOwn(counts,s))throw Error('unknown_status');counts[s]++;}
 return {deliveries:deliveries.size,issues:issues.size,counts};
}
const out=summarize([{delivery:'a',issue:1,status:'need_info'},
 {delivery:'a',issue:1,status:'need_info'},{delivery:'b',issue:1,status:'human'},
 {delivery:'c',issue:2,status:'answered'}]);
assert.deepEqual(out,{deliveries:3,issues:2,counts:{answered:1,human:1,need_info:0}});
assert.throws(()=>summarize([{delivery:'x',issue:3,status:'constructor'}]),/unknown_status/);
console.log('weekly denominator: ok');

本地运行输出：

weekly denominator: ok

观测先收需要的最少字段

记录版本、状态、耗时和证据引用，通常已经能回答大量维护问题。确实需要完整内容时，再评估敏感信息、访问范围、保留周期与用户预期；不要仅仅因为导出开关存在就全部打开。

周报最后给一个下周动作：修复一条误答规则、补充一个缺失文档，或缩小机器人处理范围。指标应帮助判断优先级，而不是替项目制造增长故事。

适用范围与未测部分

本例只计算内存夹具，没有真实社区数据、OpenTelemetry导出和解答质量评测，不提供运营成功率。

参考资料

• OpenTelemetry tracing for the Claude API
• Claude Platform release notes（2026-10-22）
• GitHub Webhook best practices