Star 是幂等的：点过不等于任务完成，判据在别人的仓和一批批的核对里

案例仓在 GitCode 的 harmony-practice-center 组下，统共六个。任务规则是每天 Star 一个，于是第一版脚本写成「取今天推荐的案例，点 Star，看接口回 200 就算完成」。这个版本每天都能跑成 200，但卡片死活不翻。花了一天把三个层次分开才搞明白。

一、Star 接口是幂等的，所以它给不出「今天点过」的信息

POST /api/v2/projects/{id}/star 对已经点过的仓再发一次，返回的 star_count 不变。我拿 calculator 做过一次对照：11-03 那天它已经是点过的状态，再发一次，计数 41 变成 41。接口本身没错，问题是这个响应里没有任何字段能区分「我今天点的」和「我以前点过的」。有区分的是另一个字段——GET /api/v2/projects/{路径} 回的 starred（布尔）。

二、star_count 是全站共享的，一天里会因为别人而暴涨

今早 07:04 点 HarmonyOS-APPTMPL-Calendar 的时候读到 16 变 17；中午同一接口再读，已经是 39。bustravel 更夸张，昨天点的时候 110，今天中午 249。这张卡是新上的，大量参与者在点同一批六个仓，仓的计数涨得快慢跟「我做没做」毫无关系。所以任何拿 star_count 变化来判完成的做法，都会在第二天开始乱套。

反过来，starred 是按当前登录账号给的，六个仓现在读到三个 True、三个 False——三个 True 正好是我这两天点过的三个。这就是唯一可信的自证字段，脚本要点之前先读它。

三、卡片判定在外部，而且是批量核对

实践中心给的任务对象里，这张卡的元数据是这样（实测摘出来的关键字段）：

task_key     = gitcode-star
evaluator    = external_check
orgs         = ["harmony-practice-center"]
repos        = []            # 空，配合 match=any：组里任意仓都算
git_bound    = true
git_login    = gcw_nyevb1nn   # 绑定的 GitCode 账号
match        = any
today_status = todo           # 早上点过之后，中午仍读到 todo
points_hint  = 30

三条信息很值钱：其一 repos 是空数组加 match=any，意味着不必按当天的推荐顺序点，组里任何未点过的仓都能满足——这给脚本留了「挑没点过的」的余地；其二判定方是外部核对，它按批扫 GitCode，不当场翻，所以「点完立刻读卡片」必然读成 todo；其三核对绑的是 git_login 这个账号身份，也就是说 Cookie、Bearer、绑定关系三者必须同源于同一个 GitCode 账号，换错账号点了也不算。

四、脚本该怎么落地

把上面三条拼起来就是最终形态：候选列表 = 今天推荐的案例 + 组内其余案例仓；逐个读 starred，点第一个 False 的；点成功之后把「今天已经点过哪个仓」写进状态文件，同日再跑只播报不再点。对账不看卡片、不看 star_count，只看积分的日环比。另外 Star 撤不回，六个仓点完就没有新仓可点，这张卡会从「能做的任务」退化成「只能播报的状态」——这是可以预先算出来的：每天一个、共六个，第 7 天开始就没饭吃了，除非平台补新的案例仓。

这类任务共同的教训：幂等接口返回的状态码不属于你这趟操作，它描述的是世界，不是你的动作。要证明动作发生过，就得自己存状态，并且找到那个按主体区分的字段（这里是 starred）。