为什么写这个

连续用了几周云开发平台的成长任务体系，把日、周、月三种周期的任务都跑了一遍。过程中积累了一些具体数字和观察，觉得对做类似产品的人有点参考价值——任务体系看着简单，做好很难。

这篇不谈怎么刷分，只谈这套机制是怎么设计的，以及哪里容易出问题。

一、三种周期的实际结构

从分值分布就能看出设计意图：

分值不是随便定的。日任务加起来一天约 100 分，周任务一周约 170 分，月任务单项 200 分。月任务的分值 ≈ 两天的日任务总和，这个比例在暗示：平台真正想要的是「作品」，不是「签到」。

二、日任务为什么要做得这么轻

签到 10 分，点一下就拿；发文 60 分，但要真的写出东西。这两个的分差说明了设计者的取舍：

• 签到是「召回」——成本几乎为零，作用是让用户每天打开一次 App
• 发文是「价值」——必须有实质内容，所以给高分

如果签到给 60 分，用户会每天来点一下就走，平台得不到任何内容；如果发文只给 10 分，没人愿意写。这个梯度是刻意的。

三、容易出问题的三个地方

1. 判定延迟，用户不知道自己做没做成

最常见的坑：操作完成了，任务状态不更新，积分也不到账。用户第一反应是「我是不是做错了」，然后反复重试。

我实测过一个任务，判定延迟从 7 分钟到 84 分钟不等。这种不确定性比「失败」更消耗信任——失败至少知道要重试，不确定只能干等。

改进方向：任务卡片上加「已提交，处理中」的中间态，或者直接显示预计到账时间。

2. 入口分散，任务和实际页面脱节

有些任务点「去完成」跳到的是活动首页，而不是具体操作位置。用户得自己在页面上找那个按钮。任务描述和实际入口不一致，是最容易被忽略的摩擦。

3. 某些环节必须人工介入

涉及第三方平台授权的任务（比如同步发布到另一个市场），流程里必然有扫码/登录环节。如果任务描述没提前说明，用户会卡在最后一步，前功尽弃。

改进方向：在任务详情页标注「此任务需要人工授权」，让人有心理准备。

四、给做任务体系的人三条建议

第一，进度要可见。「完成了 3/5」比「进行中」有用得多。用户需要知道自己离目标还有多远，而不是被动等待。

第二，判定要稳定。宁可延迟一点，也不要时快时慢。一个可以预期的「24 小时内到账」，比「有时 5 分钟有时 2 小时」体验好得多。

第三，周期要匹配产出节奏。日任务适合「点一下就完成」的动作，周任务适合「需要几次投入」的事情，月任务留给「真的要做个东西」的产出。错配的后果是：要么任务太轻没人重视，要么太重没人做。

五、作为使用者的一点体会

跑了三周，最大的感受是：能自动化的事情就该自动化，把精力留给真正需要创造力的部分。

签到这种动作，人工点一次十秒，但每天十秒 × 365 天就是一小时。而写一篇文章需要一两小时，那才是值得投入时间的地方。

分清「机械动作」和「创造动作」，是参与任何激励机制时最该先想清楚的事。

小结

任务体系本质是一套用确定的小奖励换取不确定的大产出的设计。做得好的体系，用户不会觉得被操纵，反而会觉得「顺手做了点有用的事」。

差别就在细节里：判定快不快、进度清不清楚、入口对不对得上。这些都不是技术难题，是产品用心程度的问题。