华为云开发者成长任务为什么没打勾？扒了一遍 grow 系统的完成机制

刷华为云开发者成长计划（https://developer.huaweicloud.com?grow ）的同学多半遇到过这个困惑：任务明明做了——Issue 提了、作品发了——可任务卡片就是不亮、积分就是不到账。本文用浏览器抓包扒了一遍 grow 系统的任务完成机制，把"为什么没打勾"和"正确姿势"讲清楚，帮你少走弯路。

一、现象：做了任务，但没打勾

典型场景：

• 在 GitCode 仓库提了 Issue，回到 grow 任务中心，「给AI办公实践中心代码仓提 Issue」还是「去完成」；
• 用工具把 Skill 上传到了某个市场，「在开发者作品展览馆中发布作品」也没亮；
• Star 了仓库、体验了 DevSpace，任务照样灰着。

很多人第一反应是"有延迟"，刷新几次没用后就开始怀疑人生。其实大部分情况不是延迟，是任务完成判定机制没走对。

二、grow 任务系统的 API 长什么样

用浏览器打开%开发者成长中心，抓 XHR，核心就一个接口：

GET https://devdata.huaweicloud.com/.../growth/mission/query-mission-list-by-condition

返回的每个任务对象里，最关键的是这几个字段：

{
  "id": "6fd4aacc...",
  "title": "给AI办公实践中心代码仓提 Issue",
  "is_finish": 0,                    // 0=未完成, 1=已完成
  "url": "https://hands-on-agent.developer.huaweicloud.com/#tasks",  // "去完成"跳转地址
  "rule_list": [{
    "behavior_code": "6f6f12793b914e8ba586ca874f869b90",  // 行为码
    "bonus": 60,
    "mission_cycle_type": "DAILY"     // DAILY/WEEKLY/LIMIT
  }]
}
A

注意三件事：

1. is_finish 是后端给的，前端只读不能写——grow 前端 JS 里没有任何"标记完成"的 API，只有查询、签到、兑换这类读操作。
2. 每个任务带一个 behavior_code，这是完成判定的钥匙。
3. 每个任务有个 url（"去完成"跳转地址），指向另一个"实践中心/展览馆"等子系统，不是 grow 自己。

把这三点连起来，完成机制就清楚了。

三、任务完成的真实路径：behavior 上报

grow 自己不判定你有没有提 Issue、有没有发作品。判定发生在任务 url 指向的那个子系统后端，流程是：

你在「实践中心/展览馆」完成操作
        │
        ▼
该子系统后端检测到行为（提了 issue / 发了作品 / star 了）
        │
        ▼
后端拿 behavior_code 调 grow 的内部上报接口
        │
        ▼
grow 把对应任务的 is_finish 置 1，发积分

也就是说，grow 是"被通知"的一方，不是"主动检测"的一方。这就解释了所有"没打勾"的根因——你没让那个子系统后端去通知 grow。

四、三个最常见的坑

坑 1：技能市场 ≠ 开发者作品展览馆

「在开发者作品展览馆中发布作品」任务的 url 是 gallery.developer.huaweicloud.com/gallery/submit-guide，发布用的是 huawei-cloud-publish-work-to-gallery 这个 Skill。

而 uploadUserSkillToHuawei 工具上传的是 Skills 中心（skills.huaweicloud.com/community）——这是两套系统。你把作品传到技能市场，展览馆后端根本不知道，自然不会上报 behavior，任务不亮。

一句话：任务要的是"展览馆"，不是"技能市场"。看任务 url 指向哪，就往哪发。

坑 2：直接打 GitCode API 提 Issue，没经实践中心

「提 Issue」任务的 url 指向 hands-on-agent.developer.huaweicloud.com（AI办公实践中心）。正确流程是：在实践中心点「去提 Issue」→ 跳到 GitCode 仓库 → 提交 → 实践中心后端检测到并上报 behavior。

如果你拿 PAT 直接 curl 打 GitCode API 提了个 Issue（Issue 确实建好了），但没经过实践中心，后端没机会上报，grow 不知道，任务不亮。

Issue 是真的提了，grow 也是真的没记录——两件事不矛盾，因为"提 Issue"和"上报完成"是两个独立动作。

坑 3：一个 grow ticket 登不进所有子系统

有人想用自动化一把梭：拿到 grow 页面的 SSO ticket，再去登录实践中心/展览馆。不行。

grow 的 ticket 是 CAS 一次性票据，访问 grow 时被消费换成 grow 的 session。当你再拿它去实践中心，SSO 认证中心查不到有效的 TGC（Ticket Granting Cookie），直接跳 logout。一个 ticket 只能换一个子系统的 session，不能跨域通用。

要自动化跨子系统操作，得有华为云账号的持久登录态（浏览器 cookie / 各子系统各自的 ticket），不是一个 grow ticket 能搞定的。

五、正确姿势

把上面三个坑反过来就是正确做法：

1. 从任务卡片点「去完成」进入 —— 这会把你带到正确的子系统（实践中心/展览馆/学堂），并带上该子系统的登录上下文。
2. 在子系统里完成操作 —— 提 Issue 就在实践中心跳转的 GitCode 仓库里提；发作品就用展览馆指定的 Skill 发到展览馆；Star 就在实践中心引导的仓库点。
3. 让子系统后端上报 —— 完成操作后，子系统后端会拿 behavior_code 通知 grow，is_finish 置 1，积分到账（个别任务有 30 分钟延迟，但大多数很快）。

一句话总结：别绕过任务入口自己单干，要让"做动作"和"上报行为"发生在同一个子系统会话里。

六、附：DevSpace 跑 Agent 频繁 429 怎么办

顺带一个相关坑：在 AI 开发者空间跑多 Agent 任务时，经常撞到：

429 Too Many Requests
{"code":"ModelArts.81111","message":"The model TPM limit has been significantly exceeded..."}

这是 ModelArts 的 TPM（每分钟 Token 数）限流，不是故障。处理：

• 降并发：多 Agent 协同改串行，请求间加 2–5s 间隔；
• 缩上下文：精简 prompt、砍历史轮次、降 max_tokens，单次 token 数下来就不撞限；
• 指数退避：429 时等 2^n 秒重试，别硬循环；
• 提配额：ModelArts 控制台申请提高 TPM，或反馈给平台。

七、结语

grow 任务"没打勾"九成不是延迟，是完成行为没经正确的子系统后端上报。记住三件事：看任务 url 指向哪就往哪做、从任务入口进、别指望一个 ticket 走天下。把机制想明白，刷任务就不再靠玄学。

祝大家任务全亮、积分到手。

本文基于对 grow 系统前端接口的实际抓包分析整理，相关请求已脱敏。