成长任务已操作却未计分：用当日流水核对登录与状态

在成长任务里，操作已经成功，并不等于积分已经入账。任务页上的“已完成”，也不一定等于当日流水里真有对应记录。本文记录一次真实核对过程：连续两天在指定案例仓库完成 Star 后未计分，随后用绑定信息、各相关页面的可见登录状态，以及当日积分流水交叉验证。目的是形成可复查的状态校验方法，而不是追求刷分，也不对后台根因作结论。

一、先把“已操作”和“已计分”分开

2026年11月10日和11月11日（北京时间，UTC+8），分别在 GitCode 为两个不同的指定案例仓库成功添加了 Star。仓库属于任务要求的指定范围，Star 状态可以在仓库页看到。但成长中心积分流水中，这两天都没有出现对应的每日 Star 奖励（各 30 分）。

这两件事需要分开记录：一是代码托管站点上的 Star 已成功；二是积分账户侧尚未见到入账。只要流水里没有对应记录，就不能把任务页或操作记忆当成“已经结算”。此时不宜取消 Star 再点一次，也不宜改点其他仓库来“补救”——这类操作可能破坏现场，且未必能补回积分。

二、绑定一致，只能排除一种常见假设

11月11日核对了账号绑定：华为云账号 A 绑定的 GitCode 账号为 B，当时 GitCode 实际登录的也是账号 B，二者一致。也就是说，至少在“绑定账号与当前登录账号是否为同一人”这一项上，没有发现矛盾。

绑定一致很重要，但作用有限。它只能说明，未计分不太像是点到了未绑定账号上；它不能证明成长中心、GitCode 以及相关实践站点的会话都仍然有效，更不能单独解释积分为什么没有入账。

三、任务页状态可能来自旧页面，要以当日流水为准

11月12日早晨，一次自动核对曾依据未经硬刷新的页面状态，把当日任务误报为已完成。硬刷新后，成长中心显示需要登录，说明当时并不能把该页上的任务状态当作有效结论。

恢复成长中心登录后，当时可见的账户状态是 760 分、连续签到 6 天，且当日签到尚未完成。这说明：前一时刻的“今日已完成”并不可靠。要判断某项任务是否已经计分，应回到当日积分流水，逐条核对时间、项目和分值。

四、相关页面的登录状态要分别查看

同一时期，鸿蒙实践中心的独立页面也显示“登录/注册”，可见该页当时并非已登录状态。当时不能用成长中心已登录，推断相关实践站点也已登录。

恢复该页登录后，11月12日已经 Star 过的指定案例仓库 word-check-in，在北京时间 09:36 自动记入 30 分。过程中没有取消 Star，也没有再次 Star。同日流水还可以核对到（均为北京时间）：09:35 签到 +10，09:39 AI DevSpace +30，09:42 浏览案例 +10。最终账户为 840 分，连续签到 7 天。

需要单独写明的是：此前两天未入账的各 30 分、合计 60 分，在这次恢复后并未补发。

上述时序只说明“恢复某页登录”与“当日已完成的 Star 随后出现在流水中”先后发生。它不能证明后台根因，也不能把前两天未计分归因于同一种会话问题，更不能推出“恢复登录后历史积分就会补发”。本次没有读取网络或服务端日志，也尚未向平台提交支持反馈，因此只能停留在可核验的观察，而不能写成机制结论。

五、可复用的核对清单

遇到“操作成功但未计分”时，建议按下面顺序做只读核对，而不是先反复操作：

1. 查看各相关站点的可见登录状态。 成长中心、GitCode，以及任务实际涉及的实践站点，都要单独确认页面是否已登录，不要用其中一页的状态代替其他页面。
2. 核对绑定账号与当前登录账号。 确认华为云侧绑定的 GitCode 账号，与当前 GitCode 登录账号一致。截图或对外说明时，用账号 A、账号 B 这类代称，不要公开完整用户名或账号标识。
3. 确认真实的 Star 状态。 到仓库页查看 Star 是否确实已存在，作为“已操作”的证据。
4. 核对项目范围与计分周期。 确认仓库属于指定组织或指定案例范围，并核对该项奖励是否按日计、是否仍在当日周期内。
5. 以当日积分流水为准。 对照时间、任务名称和分值，判断该项是否已经入账。任务页展示或自动核对结果，只能当作线索。
6. 不要取消或重复 Star。 在原因尚未查清前，取消再点或改点其他仓库，既可能让现场不可复查，也不能提高计分的确定性。

这次能够确认的是操作记录、绑定核查、登录状态变化，以及 11 月 12 日的入账流水；不能确认的是未计分的后台原因，以及历史 60 分是否会补发。把“已操作”“已登录”“已计分”分成三项来核对，并用当日流水做最终校验，比在结果未知时重复点击更稳妥。