业务问题
前几天还在涨，现在开始回落，是正常退热还是哪里出了问题？
项目档案 08AI 判断工作流2026.07个人产品探索 · 模拟案例 Demo
流量诊断 Agent：先查清楚，再决定怎么处理
检查内容和账号的流量变化，给出排查依据和处理建议
我负责的部分
把内容与账号问题分成六类，设计要查的证据、四种结论、处理优先级和下一责任人。
项目重点
流量掉了不等于被限流。先核对数据和内容表现，再决定继续观察、加投或交给相关团队处理。
Traffic DiagnosisAgent WorkflowHypothesis CompetitionEvidence RoutingHuman in the LoopCross-team Handoff
流量诊断 Agent
先别急着说限流，把问题查清楚再处理。
这里用六个模拟案例展示掉量问题的排查与处理：先看证据，再给出关闭、加投、进入优化池或 Oncall 的处理建议。
查看现有 Lab六个常见的线上问题
六个模拟案例分别检查问题理解、证据选择和后续处理动作。
最后只做四个决定
输出处理建议、接手人和下一步需要做的事。
这是正常变化，解释清楚后关闭
先小步加投，边投边看效果
按 P0、P1、P2 交给对应的人处理
先别下结论，把数据和证据补齐
怎样用错误案例继续改进
独立 Demo 按下面的流程核对结论和动作、记录错误案例，再补充容易出错的场景。站内 Lab 展示固定样本，支持模拟交接和反馈记录。
- 01收到问题
把“是不是限流了”整理成可以复现的内容或账号 Case。
- 02Agent 先查
调用数据和工具，先确认是不是真的有异常。
- 03对照答案
用案例预设的真实原因，检查结论和处理动作对不对。
- 04看这次错在哪
把结论、证据、动作和表达分开评分。
- 05留下 Bad Case
记下失败和缺失的证据，方便后面集中补。
- 06安排下一轮
优先练最常错、影响最大的问题。
项目说明
方案和验证
这里记录了主要做法、评估依据，以及后续需要观察的情况。
主要做法
01流量掉了不等于被限流。先确认是不是真异常，再决定符合预期、值得放大、需要干预还是证据不足。
评估时注意
02当前只使用模拟案例，诊断效果还需要真实场景验证。模型训练和生产 Oncall 接入尚未完成。
证据来源
03用爆款退热、内容加投、单条掉量、推荐下降、账号多条内容一起掉和两个看板对不上六个模拟案例，检查关闭、加投、P2、P1、P0 和数据校验等处理动作。
后续观察
04接下来需要增加不同原因的案例，检查诊断和处理动作是否正确，再评估团队协作和 V2 模型训练。
Opening Judgment
补充说明
做了什么
这是一个个人流量诊断 Demo，面向运营、产品和算法的排查场景。站内 Lab 用六个模拟案例展示证据、结论和处理动作，支持模拟交接与反馈记录。当前未使用真实业务数据，效果尚待验证。
需要注意的情况
流量变化可能涉及内容表现、平台异常或数据口径，需要分别排查。
项目重点
流量掉了不等于被限流。先核对数据和内容表现，再决定继续观察、加投或交给相关团队处理。
AI 相关想法
核对诊断结果和处理动作
站内 Lab 展示固定模拟案例的证据和处理动作，并记录人工反馈；结果核对、分项评分和样本生成属于独立 Demo 的复盘流程，尚未完成模型训练。
NODE 01
收集内容与账号案例
NODE 02
验证结论和处理动作
NODE 03
用失败决定下一轮案例