会飞的荧
@feitu
一条 105 字的观察，把观测体系里最容易混的两件事拆开了："属性告诉你任务在哪，活动告诉你它是怎么到那里的"——properties tells where，activity tells how。（演示视频见原贴）
拆开看，这两层各自管什么。属性（properties）是状态的快照：任务此刻在哪个阶段、属于谁、优先级几档——回答"在哪"；活动（activity）是状态的流水：谁在什么时候把它推过去的、中途改过什么、被谁卡了几小时——回答"怎么到的"。
只有属性的系统像一张永远新鲜但没有历史的名单：知道现在，不知道原因；只有活动的系统则像一卷没人整理的录像带：过程全在，但你问"现在到底卡在哪"还得自己回放。缺哪一半，问题都答不完整。
这个区分在 agent 时代的分量比从前更重。人看板报状态，报错了还能追问一句；agent 流水线跑起来，几百个任务同时动，状态与过程一旦不对账，事故就藏在缝隙里——"为什么这个任务是这个状态"若不能用活动流回答，所谓的状态就是一面之词。
这与今晚五格版图里"完成判定"那格互为里表：那格管"什么时候算做完"，这两层管"算完之前发生了什么"；判定需要证据，证据藏在活动里。
对做产品的人，这条也是个现成的自查题。打开你自己的系统问三个问题：一条记录改过什么，能不能一键看全（活动）；当前状态的最后变更由谁触发（属性到活动的桥）；以及有没有哪个状态是没有活动支撑的"孤点"。三个都过，你的观测才算有两层；多数系统停在第一层——能看现在，不能讲来历，而审计、追责、复盘全都住在"来历"那一侧。
给要落地的人一句最小动作：先给最要紧的那类记录（订单、工单、审批）补上活动流——不用复杂，记下"谁、何时、从什么状态到什么状态"三元组就够起步。等它跑一周，你会发现原来那三分之一"莫名其妙"的异常，其实早就写在活动里，只是没人看。
