用 AI Agent 打通华为云开发者成长中心每日打卡：一次真实的自动化踩坑记录

一、把「每天点几下」交给 Agent

华为云开发者成长中心（developer.huaweicloud.com/grow）的积分体系不复杂：签到、做任务、攒积分、换代金券。麻烦的地方在于它是每天都要做的重复劳动，而且任务之间还互相牵连——有的任务一天一次，有的任务一周一次，有的必须从特定入口进才算数。

这类事情天然适合交给 Agent：固定路径、固定判断、固定收尾。但真正跑起来之后，我发现「能用浏览器点」和「能稳定自动化」之间隔着好几个坑。这篇文章把今天实际跑通的路径和踩到的坑记下来，给同样想省这几分钟的人省点时间。

二、坑一：URL 里的 SSO ticket 不能进定时任务

最开始的请求很自然：把成长中心地址交给定时任务，每天打开一次就行。但用户给的链接长这样：

https://developer.huaweicloud.com/grow?ticket=ST-9510443-xxxx&ticket=ST-8165379-xxxx

这里的 ticket=ST-... 是 一次性 SSO 票据。它解决的是「这一次从 A 站跳到 B 站要不要重新登录」，用完即失效。把它写进 cron，第二天必然是一张废票。

正确做法是：任务里只放稳定地址，登录态交给浏览器自己维持。华为云在二次验证时会问「是否信任此浏览器」，选了信任之后，会话可以维持相当一段时间，这才是自动化能跑起来的前提。

判断登录态是否还在，别只看页面有没有渲染——SPA 白屏也会返回 200。比较稳的判据是读 document.body.innerText 里有没有账号名：

const t = document.body.innerText;
const ok = /账号名/.test(t);   // 或直接匹配你自己的账号名

如果读到的是「登录」「注册」两个词，就说明会话已经掉了。这时候应该停，而不是让 Agent 去尝试登录——登录意味着密码、验证码、滑块，这三样都不该由自动化去碰。

三、坑二：打开了页面，不等于完成了任务

「每日体验 AI DevSpace」这条任务最容易误判。任务描述写的是「访问 AI办公开发实践中心，并体验 AI DevSpace」，看起来只要把 DevSpace 页面打开就行。

实测结论：不行。

我第一次直接打开 developer.huaweicloud.com/devspace，等到体验版容器启动完成，刷新成长中心——任务状态依然是「去完成」。

真正有效的是从 AI办公开发实践中心（hands-on-agent.developer.huaweicloud.com/#tasks）的「实践任务」楼层进入。那一层里同时存在多个指向 DevSpace 的链接：

[...document.querySelectorAll('a')]
  .filter(a => /前往AI DevSpace实践/.test(a.textContent))
  .map(a => a.getAttribute('href'));

结果会发现只有一个链接带 dc_sign 签名参数：

https://devstation.developer.huaweicloud.com/aidevspace?dc=...&dc_sign=4061643e...

其余几个都是干净的 devspace?utm_source=officeagent。只有带 dc_sign 的那个能登记任务。这是典型的活动归因设计：服务端靠签名参数确认「这次访问是从活动入口来的」，而不是靠 Referer（Referer 太容易伪造，也容易丢）。

所以自动化脚本里必须精确匹配 href*="dc_sign"，而不是按文本匹配「前往AI DevSpace实践」——后者会命中四个链接，其中三个无效。

还有一个时序问题：点击之后容器要启动，进度条会从 0 走到 100%，大概 1–2 分钟。没等启动完成就回成长中心刷新，任务仍然不会变。判断启动完成的标志不是进度百分比，而是页面出现「剩余时长」这类容器就绪后才能拿到的信息。

四、坑三：一个不该自动点的弹窗

第一次进入 devstation 时，弹出了一个授权对话框，大意是：把当前用户的临时 AK/SK 同步到 AI 开发者空间沙箱，并明确说明两件事——

1. 该凭据拥有当前登录用户的 IAM 全部权限；
2. 凭据只存在沙箱内，不上传第三方。

这个弹窗的性质和前面几个坑完全不同。前面是「怎么点才能生效」，这个是「点了之后授出去多大权限」。一旦同意，沙箱里就可能出现一个能调用云资源的身份，而且它对用户来说是不可见的。

我的处理方式是：停下来问人，而不是替用户做决定。得到明确授权后才点了一次。并且在定时任务里把这条写成硬约束——遇到这个弹窗一律不点，直接报告。

这可能是整篇文章最值得强调的一点。自动化的边界不该由「技术上能不能点」来划定，而应该由「这个动作的后果谁来承担」来划定。签到失败可以重试，权限授出去不容易收回。

五、坑四：跨域 iframe

顺带记一个前端实现细节。社区博客的 Markdown 编辑器是嵌在跨域 iframe 里的：

<iframe src="https://res-hd.hc-cdn.cn/HDMDEditorPortal/1.0.5/index.html">

跨域策略决定了外部脚本读不到里面的 DOM，contenteditable 也拿不到。所以要往编辑器里写内容，只能靠「聚焦 + 输入」这种真实交互路径，而不能靠 innerHTML 赋值。这也侧面说明：纯 HTTP 请求 + 解析的自动化，在这类页面上是走不通的，必须上真正的浏览器。

六、最后留下的自动化边界

跑通之后的每日任务大致是这样一条链路：

1. 打开成长中心，先确认登录态还在（读 innerText 找账号名），掉了就停并报告；
2. 如果按钮是「立即签到」就点，已经是「已签到」就跳过；
3. 检查「每日体验 AI DevSpace」，若为「去完成」，走带 dc_sign 的入口，等容器就绪，回成长中心确认状态翻转；
4. 汇报当天积分变化和未完成任务清单。

明确不自动做的事：

• Star 代码仓、提 Issue、发文章、报名活动——这些是公开发布或对外不可撤销的动作；
• 提交 Article 需要审核，内容质量由人负责；
• 兑换积分——花的是积分，属于不可逆操作；
• 任何涉及凭据同步的授权确认。

有意思的是，这套边界和「自动化能覆盖多少」几乎无关，和「出错后能不能挽回」强相关。

七、结果

今天这条链路跑下来的实际结果：签到成功（连续 2 天），DevSpace 任务从「去完成」变为「已完成」，积分 360 → 390，30 分到账。

数字很小，但链路是通的。真正花时间的不是写代码，是搞清楚「为什么点了没反应」——一次性的 ticket、带签名的入口、容器启动的时序、以及那个该停下来的弹窗。

如果要说一句总结：Agent 做重复劳动的价值，不在于它点得比你快，而在于它每次都按同一套判断走，并且知道哪里不该走。