当时判断
01流量诊断首先是决策产品：先确认异常是否成立，再比较原因，最后决定由谁做什么。
项目档案 08AI 判断工作流2026.07个人产品探索 · 可交互原型
流量诊断 Agent：把模糊投诉变成可验证决策
从“是不是被限流”出发，让 Agent 比较假设、调用证据并形成下一步
我的判断
流量诊断首先是决策产品：先确认异常是否成立，再比较原因，最后决定由谁做什么。
Traffic DiagnosisAgent WorkflowHypothesis CompetitionEvidence RoutingHuman in the LoopCross-team Handoff
决策记录
这次判断，怎么站住。
这不是项目总结，而是我愿意被追问的四个点：当时怎么判断、没有选什么、证据从哪来，以及什么情况会让我改判断。
没选什么
02没有继续堆指标输入项，也没有把一套固定规则包装成能够自动判断所有流量问题的智能体。
证据来源
03用疑似限流、平台异常和数据冲突三类模拟 Case，验证误判纠正、算法复核和数据阻断三条流转能否成立。
什么会推翻
04如果真实用户仍需要频繁手工补信息，或输出不能直接进入下一团队的工作队列，这套 Agent 流程就没有成立。
PRODUCT PROTOTYPE / 一页看懂
不再问用户填多少指标，先弄清楚他要做什么决定。
这个原型把“是不是被限流”视为一个待验证假设。Agent 自动拆出现象、比较原因、选择证据并组装下一步；人工只在治理边界、算法上线或高风险动作前确认关键部分。
打开交互原型 →3 个模拟 Case · 无真实线上数据
CASE 01疑似限流
是真的被系统限制，还是内容表现先变差？
纠正误判，把动作交给内容实验。
CASE 02平台异常
下降发生在单条内容，还是跨对象同步出现？
组装证据包，只让算法确认最后一块关键证据。
CASE 03数据冲突
指标方向都没对齐时，系统是否应该继续归因？
数据门禁阻断，自动流转到数据值班。
AGENT LOOP
Agent 程度更高，不是因为模型多说了几句话。
它承担的是完整判断链路中的重复劳动：读问题、选工具、找反证、组织结果和发起流转。人工只确认不可逆或高风险的部分。
01理解诉求
先识别用户真正想做的决策，而不是照抄“限流”这个原因假设。
02定义现象
比较对象、时间窗、基线、变化形态和影响范围，确认异常是否成立。
03比较假设
让内容、分发、治理、数据等原因同时竞争，并主动寻找反证。
04选择证据
按信息增益调用证据模块，避免把固定看板误当成诊断过程。
05形成流转
输出动作、成功标准、停止条件、下一责任人和唯一交付物。
产品假设
流量诊断首先是决策产品，其次才是数据展示产品。
验证方式
用三类模拟 Case 检查误判纠正、升级复核和数据阻断是否能走通。
当前边界
尚未接真实数据与模型，不宣称诊断准确率或业务收益。
Opening Judgment
开场判断
这件事本质上是什么
这不是一个让运营填完指标就吐结论的流量计算器，而是一套把模糊投诉变成可验证决策的判断工作流。
最容易被误判的地方
用户说“被限流”时，里面混着现象、原因假设和升级诉求。直接展示流量结构，反而容易让系统过早确认用户的猜测。
我的判断
我把产品重心从指标录入改成问题理解：Agent 负责比较假设、选择证据、组织流转，人工只确认高风险和不可逆动作。
AI 迁移方式
Agent 的价值，是缩小原因空间并推动下一步
流量结构只是证据模块之一。真正的 Agent 应该根据问题主动调用内容表现、影响范围、治理记录、数据质量和分发阶段等证据，再给出带成功标准的动作。
NODE 01
理解诉求并定义现象
NODE 02
比较假设并主动找反证
NODE 03
形成动作、停止条件和跨团队流转