别让动态流变成流水账：vibe 项目的活动动态实战

先说清楚：下面出现的所有产品名和人名都是虚构的，比如虚构产品“青禾协作”、虚构人物林小雨和陈默，都是为了讲明白道理编出来的例子，不是真实产品，也不是真实用户。本文只讲站内活动动态流本身怎么做，不讲提醒怎么触达用户，也不讲实时同屏协作、审计留痕和对外发版公告。

很多人打开产品的动态页，第一反应是：这都写了些什么，跟我有什么关系。动态流一旦变成流水账，用户很快就不看了。而动态流一旦没人看，团队协作里很多“谁动了什么”就只能靠口头问，效率反而更低。动态流的价值不在于记全，而在于让人一眼看懂发生了什么重要的事。

一、先分清三样东西：动态、通知、审计日志

动态、通知、审计日志听起来都是“记录发生了什么”，但它们的读者和目的完全不同，混在一起做，最后三样都做不好。

动态是给人看的进展。它回答的是“这个项目最近怎么样了”，读者是项目里的成员，语气要像人话。比如“林小雨把设计稿更新到了第三版”，一看就懂。动态不要求百分之百完整，重要的是挑出值得看的事。

通知是用来把人叫回来的。它回答的是“有件事需要你处理”，比如有人在评论里提到了你，有个任务到期了。通知讲究及时和精准，推多了就是打扰，推少了就会误事。通知可以指向一条动态，但通知本身不是动态。

审计日志是留给以后查的。它回答的是“出问题的时候到底是谁在什么时候干了什么”，读者可能是管理员，也可能是出了纠纷之后来查账的人。审计日志要求完整、不能改、不能漏，哪怕是再小的一次操作也要记下来。但它不需要好看，也不需要让人天天看。

所以分工要写死：动态给人看进展，通知把人叫回来，审计日志留着以后查。不要把审计日志直接搬到动态流里，用户不需要知道每一次字段修改；也不要把动态当成通知，指望用户天天主动打开动态页等消息。每一类记录都有自己的地方，越界就是给用户添乱。

判断方法也很简单。问一句：这条记录是写给谁看的？写给项目成员日常看的，进动态；写给某个人、需要他马上处理的，进通知；写给以后查账的，进审计日志。问第二句：如果这条记录丢了会怎么样？丢了会影响协作，进动态；丢了会误事，进通知；丢了会说不清责任，进审计日志。

二、聚合与分组：别让同一个人刷屏

动态流最常见的毛病就是刷屏。一个人连续改了十次文档，动态里就出现十条“林小雨编辑了文档”，翻一页全是同一个人，用户直接就不往下看了。

解决办法是聚合。同一人在短时间内对同一个对象做的连续动作，应该合并成一条。比如林小雨在十分钟里保存了八次，动态里只显示一条“林小雨编辑了《上线清单》，共保存八次”，点进去再看详情。聚合的时间窗口可以自己定，十分钟、半小时都行，关键是要定下来，并且让用户感觉自然。

另一种聚合是按对象聚合。比如一篇文档同时被三个人评论了，与其显示三条“某某评论了文档”，不如显示一条“林小雨、陈默等三人评论了《上线清单》”。按对象聚合的好处是，用户一眼就能看出来哪个东西最热闹，而不是被人名分散注意力。

聚合的时候要注意两件事。第一，聚合不能把重要信息藏没了。如果八次保存里有一次是把标题改了，那次改动就值得单独拎出来，而不是藏在“保存八次”里。第二，聚合之后的时间要写清楚，写“今天上午”比写一串精确到秒的时间更让人看得懂。动态是给人读的，不是给机器读的。

还有一个细节：聚合规则要稳定。今天按十分钟聚合，明天按一小时聚合，用户会觉得动态忽多忽少，摸不着规律。规则定下来就不要轻易改，改了也要告诉用户。

三、已读与未读：“新动态”锚点怎么做才不烦人

用户隔几天再打开产品，最想知道的是“我不在的时候发生了什么”。这时候就需要一个“新动态”锚点，也就是一条线，线上面是上次看过的内容，线下面是新内容。

锚点的做法有几种。最简单的是按时间记：记录用户上次打开动态页的时间，下次打开时把这个时间之后的内容标成新的。这种做法简单，但有个毛病：用户可能只是路过打开看了一眼，并没有真的看完，下次再来，锚点已经移过去了，中间的内容就被当成已读了。

更稳妥的做法是按位置记：记录用户滚动到了哪一条，下次打开时从那条之后开始标新。用户看到哪儿，锚点就停在哪儿，没看到的永远是新的。这种做法更准，但实现起来稍微麻烦一点。

不管用哪种做法，都要记住两条原则。第一，未读数不要造假。不要为了让用户点进来，把已经看过的内容也算成未读，骗一次点击，丢的是信任。第二，要给用户一个“一键标为已读”的出口。用户可能并不想一条一条看完，他只想清掉红点，这时候就让他清掉，不要逼着他把每条都点开。

还有一个容易被忽略的场景：用户在手机上看过动态，回到电脑上还要不要再标一次新？理想情况是已读状态跟着账号走，换设备也同步。如果做不到同步，至少不要在两个设备上各算各的未读数，那样用户会觉得产品连这么简单的事都做不好。

四、隐私边界：不是所有动作都适合进动态流

动态流是半公开的东西，项目里的人基本都能看到。所以写动态之前要先问一句：这个动作让所有人看到，合适吗？

最典型的敏感动作是权限变动。比如管理员把某个人的权限从编辑改成了只读，这件事要不要出现在动态里？如果出现在动态里，被降权限的人会觉得难堪，其他人也会多想。这类动作更适合只让相关的人知道，或者只进审计日志，不进动态流。

还有一类是私人动作。比如有人把一篇草稿从公开改回了私人，或者删掉了自己写的一段话，这些动作出现在动态里，对别人没有任何价值，反而可能暴露作者的犹豫和反复。动态流不是监控器，不需要把人的每一个小动作都广播出来。

另外要考虑可见范围。不是所有动态都应该全项目可见。有些动态只和某个小组有关，就只给那个小组看；有些动态涉及还没公开的内容，就要等到公开之后再出现在动态里。可见范围的规则要和内容的权限规则保持一致，内容看不到的人，动态也不应该看到。

定规则的时候可以列一张清单：哪些动作一定进动态，比如发布、提交、评论；哪些动作一定不进动态，比如权限调整、删除草稿、私人设置；哪些动作要看情况，比如编辑、改名。清单定下来，开发和产品就不用每次都现商量，也减少了事后扯皮。

五、分页与回溯上限：动态流要翻多久才算够

动态流理论上可以一直往前翻，翻到项目成立的第一天。但实际上没有人会翻那么远，而且无限回溯对性能和存储都是负担。

分页的做法建议用“加载更多”，而不是传统的页码。用户往下滚动，到底了就自动加载下一批，或者点一下“加载更多”再加载一批。页码适合搜索结果，不适合时间线，因为时间线是越往下越旧，用户很少会说“我要直接跳到第 37 页”。

回溯上限要定一个数，比如只保留最近三个月或者最近一年的动态，更早的动态归档起来，不在动态流里直接翻。定这个数的时候要看产品类型：项目周期短的产品，三个月可能就够了；项目周期长的产品，可能需要一年。没有定论，但一定要有个上限。

超过上限的动态怎么办？不要直接删掉，而是归档。归档的意思是用户如果真的需要，还能通过搜索或者找管理员要到，但平时不在动态流里占位置。这样既省了性能，又没有真的丢数据。

还有一个细节：分页加载的时候，已读锚点不能乱跳。用户正在往下翻旧动态，突然因为新动态进来了，列表一刷新，人就被顶回了顶部，这种体验非常差。正确的做法是新动态先在顶部提示“有三条新动态”，用户点了才刷新，而不是自动把人顶上去。

六、空动态与第一条动态：冷启动别让页面尴尬

新项目刚建好，动态页是空的。这时候如果只显示一句“暂无动态”，用户会觉得这个产品没人用，或者自己走错了地方。空状态是留住新用户的关键时刻，不能随便应付。

空动态页应该告诉用户三件事：这里以后会出现什么，第一步该做什么，以及做完之后会发生什么。比如写一句“这里会显示项目里的新进展，比如谁发布了新版本、谁评论了文档”，再给一个按钮“发布第一条进展”或者“邀请成员加入”。用户看完就知道这个页面是干什么的，也知道自己下一步该干什么。

第一条动态也很重要，它是整个动态流的调子。很多产品会用系统自动生成的第一条动态，比如“林小雨创建了项目《青禾协作》”。这条动态看起来不起眼，但它告诉所有人：这个项目从这一刻开始了。第一条动态要写得像人话，不要写成“系统于某年某月某日创建项目编号某某”，没人愿意读这种话。

还有一个冷启动的坑：不要为了让页面不空，就用假动态填充。有些产品会在空页面里塞几条示例动态，用户点进去才发现是假的，信任立刻就没了。宁可空着，也不要造假。空着是诚实，造假是欺骗。

如果项目已经有一段时间了，但某个用户是新加入的，他看到的动态页也可能是“对他来说是空的”，因为他加入之前的动态他看不到，或者看不懂。这时候可以给他看一份项目近况摘要，比如最近一周最重要的三件事，帮他快速跟上节奏，而不是让他从头翻几个月的流水账。

七、写扩散还是读聚合：用人话把取舍讲清楚

动态流在技术上有一个经典取舍，名字听起来很吓人，但道理其实很简单。所谓写扩散，就是有人做了一个动作，就立刻把这条动态抄送给所有相关的人，每个人打开动态页的时候直接就能看到，不用现算。好处是打开速度快，坏处是动作一多，抄送的量就很大，存的东西也多。

所谓读聚合，就是动作发生的时候只记一笔，等到用户打开动态页的时候，再现算他应该看到哪些动态。好处是存的东西少，动作再多也不怕，坏处是打开的时候要现算，人一多就可能慢。

对绝大多数 vibe 项目来说，不用一开始就纠结选哪个。用户少、动态少的时候，两种做法都够用，差别根本感觉不出来。真正要做决定的是用户量和动态量都上去了之后：打开动态页开始变慢，或者存储开始涨得很快，那时候再根据瓶颈选。

一个实用的折中办法是：热门项目和活跃用户走写扩散，保证打开速度；冷门项目和不常看动态的用户走读聚合，省存储。混合着用，比非此即彼更划算。但混合的前提是团队能把两条路都维护好，如果人手不够，宁可只选一条简单的先跑起来。

还有一点要提醒：不管选哪条路，动态内容本身的规则不能变。聚合、隐私、已读这些产品规则，和底层怎么存、怎么算是两回事。底层可以换，产品规则换了用户是能感觉到的。所以先把产品规则定下来，技术选型放在后面。

八、上线验收清单

动态流上线之前，对着这张清单一项一项过，缺一项都不要急着上线。

第一，动态、通知、审计日志的分工有没有写进文档，团队里每个人说法一致不一致，有没有把审计日志误搬进动态流的地方。第二，聚合规则定没定，同一人连续动作会不会刷屏，按对象聚合之后的信息丢没丢。第三，已读锚点用的是时间还是位置，换设备之后已读状态同不同步，有没有一键标为已读的出口。第四，隐私清单列没列，哪些动作不进动态流，动态的可见范围和内容权限对不对得上。第五，分页用的是加载更多还是页码，回溯上限定的是几个月，超期动态归档之后还能不能找回来。第六，空动态页有没有写清楚这里会出现什么、有没有下一步按钮，第一条动态是不是人话，有没有用假动态填充。第七，写扩散和读聚合选了哪条路，打开动态页的速度测没测，用户量上来之后瓶颈在哪里。第八，有没有拿一批真实协作场景做测试，比如三个人同时改同一篇文档、一个人连续保存十次、新成员第一天加入，这些场景下的动态看起来对不对。

九、几个常见的反模式，看到就绕开

第一个反模式是把动态流当成聊天室。有人在动态下面长篇大论地讨论，动态越写越长，真正的新进展反而被淹没了。讨论应该去评论区或者聊天工具，动态只负责说清楚发生了什么，点进去再看讨论。

第二个反模式是每条动态都带一堆按钮，点赞、转发、收藏、提醒全堆上去。动态页不是社交首页，按钮越多，用户越不知道该看什么。先把“看懂发生了什么”做好，再考虑加互动。

第三个反模式是动态文案写得像机器日志，比如“用户编号一百零三更新了实体二百七十一”。这种话只有开发自己看得懂，用户看了只会关掉页面。写动态的时候，先念一遍给不懂技术的朋友听，听不懂就重写。

最后说一句大实话：动态流做得好不好，不看它记了多少条，而看用户愿不愿意点开看。记全很容易，记到点子上才难。少记一点，挑重要的记，把每条都写成人话，动态流才有活下去的理由。