AI 日志分析工具说某条请求“耗时很长”之前，应先确认开始和结束事件属于同一个请求。没有结束事件的请求不能用当前时间随便补成完整耗时。
准备让AI分析请求链日志的开发者。本文使用 Python 3.11 或以上版本的标准库，先验证一组人工构造的小样本。AI 负责提出实现或解释差异，结果由本地检查决定；这里没有把模型回答当成真实运行结果。
配对请求开始结束事件前，先定规则
教学日志使用同一进程单调时间轴的毫秒数，不混入跨服务器墙钟。request_id固定关联同一请求。
每个请求必须恰好一个start和一个end；多次同阶段可能是重复上报或ID复用，需要单独报告。
缺结束、缺开始和倒序分别列问题，不默认耗时0，也不把异常行混进平均值。
给 AI 的输入要包含什么
把下面这份输入说明和你的实际样本一起交给可用的 AI 编程助手。示例只含虚构数据；对真实材料先去除账号凭据和个人信息。
按request_id配对start/end，要求每阶段一个、end>=start。正常请求输出耗时；缺结束和倒序输出问题清单，不猜补时间，不改日志。要求模型保留检查条件，并把它认为缺少的业务定义列出来。若回答改变了输入字段、忽略异常分支或直接删除原材料，先要求修正，再运行。提示词的作用是缩小任务范围，验收仍以代码和数据为准。
保存并运行最小验证程序
下方程序把关键规则和验证用例放在同一个可复跑示例中，便于先理解输入如何变成输出，再用它检查 AI 给出的实现。
新建一个空目录，把下面代码保存为 check.py，在该目录打开终端，运行 python -X utf8 check.py。代码自带示例输入，不需要安装第三方库。
from collections import defaultdict
events=[('r1','end',145),('r2','start',200),('r1','start',100),('r3','start',300),('r3','end',290)]
groups=defaultdict(lambda:defaultdict(list))
for rid,stage,time in events: groups[rid][stage].append(time)
durations={};issues={}
for rid,stages in sorted(groups.items()):
if len(stages['start'])!=1 or len(stages['end'])!=1:
issues[rid]='阶段缺失或重复';continue
start=stages['start'][0];end=stages['end'][0]
if end<start: issues[rid]='时间倒序';continue
durations[rid]=end-start
assert durations=={'r1':45}
assert issues=={'r2':'阶段缺失或重复','r3':'时间倒序'}
print('valid_duration_ms',durations)
print('issues',issues)怎样判断结果符合要求
r1耗时45毫秒；r2缺结束、r3时间倒序只出现在issues，不伪造耗时。日志输入顺序不决定配对关系。
下方是这份最小示例在本地执行得到的输出。它验证示例程序与断言的关系，不代表任何 AI 模型一次就能生成同样代码，也不构成性能或生产可靠性结论。
valid_duration_ms {'r1': 45}
issues {'r2': '阶段缺失或重复', 'r3': '时间倒序'}缺结束可能由程序仍在执行、采集丢失或进程崩溃造成，仅凭日志不能确定根因。
同一ID重试多次时身份应增加attempt，不能把前次开始配上后次结束。
哪些失败必须停下来处理
跨机器墙钟可能偏移，应先统一事件定义和时钟策略，再算端到端耗时。
样本时间需为有限非负数，真实JSON输入应先做类型和范围校验。
接入自己的任务前再核对一次
向AI提供问题ID与原事件，让它提出可验证的排查方向，不要让它生成缺失日志。
统计耗时同时报告有效配对数与问题数，读者才能判断数据覆盖。
资料与适用范围
字典可按关联ID组织事件；相减前需验证阶段唯一与时间顺序。以下链接核对于 2026-10-03；运行环境及额外依赖按本文前述说明。
相关基础可阅读 MCP 服务怎么记录日志？把协议消息、诊断日志和业务审计分开保存。本文的重点是配对请求开始结束事件，可以把两项检查作为不同步骤保留。
Ai菜鸟网。发布者：AI小管家，转载请注明出处：https://www.alyyhw.com/33475.html
