2026年11月8日 18:39–19:55 做「云容器快速搭建网站」实验（90 分钟，免费名额），VPC、RDS、CCE、WordPress、弹性伸缩均已建成，实验正常结束，但实验平台只显示 50% 完成：步骤 1–3 的 VPC、RDS 未被检测到，尽管相应资源实际存在；WordPress 安装页在沙箱浏览器里也打不开。建议方案：建议平台修正实验步骤的检测逻辑，或在检测不到时明确说明是哪一步、什么原因，让用户知道实验到底算不算完成，而不是建好了资源还显示一半。

云硬盘已经删干净了，但还是在扣钱。

场景描述：我昨天明明通过了两道题但是今天只记录了一个题的分数，两个题都到达了100还有就是我有一道题是在第三次完成的但是也显示完成了测试但是之后第二天就显示我把这个机会用完了然后三次都没过我不知道为啥，明明都显示成功了退出之后不给计分   建议方案：  

场景描述：今天首次体验华为云 AI DevSpace 体验版。进入前弹出协议确认框，其中「同意将临时访问凭据（AK/SK）同步至 AI Shell 环境」一项：只勾选服务协议时，「进入」按钮一直是灰色、无法进入，只有同时勾选该项按钮才可用。弹窗里既没有说明该项是进入的必要条件，也没有说明同步的是平台自动生成的临时凭据、而不是用户自己的 AK/SK，容易让人误以为要交出自己的密钥而卡住。 建议方1）在该选项旁增加一行说明，写明同步的是平台自动生成的临时凭据、且为进入环境的必要步骤；2）或在按钮置灰时给出明确提示，告诉用户还需勾选哪一项。这样新用户第一次进入时就不会困惑。案：

场景描述：微认证的错题考完不能看吗？   建议方案： 开通能查看通道。

一、问题现状在创建沙箱时，如果当前区域或所选规格没有可用供给，页面只会给出统一提示：「资源异常：当前后台资源不足，请稍后重试」。这句话无法支撑用户做决策，具体表现为三点：失败原因无法区分。 节点池不足、系统盘或云硬盘售罄、GPU 资源排队等完全不同的情况，返回的是同一句「后台资源不足」，用户无从判断真正卡在哪里。失败位置与阶段缺失。 提示中没有说明失败发生在哪个区域、可用区，也没有说明是在规格校验、资源分配还是节点调度阶段失败。没有给出可执行的下一步。 用户只能自行推测是该换区域、换规格、换模板，还是继续等待。由此造成的实际体验是：同一时段、同一区域下，AI Shell 模板创建失败，而 DevStation 的 Base 模板却能正常拉起。用户无法从提示中看出差异，只能在各个模板和区域之间反复试错，排查成本高且容易放弃。二、建议方案1. 提示中明确失败位置，并提供一键重试入口在失败提示中标注具体区域与可用区（例如 ap-southeast-1 / 可用区A），同时给出「切换其他可用区重试」的一键操作，避免用户手工退出再重新进入。2. 按资源类型与具体原因分类提示用精确原因替代笼统表述，例如：「GPU 节点池不足」「SYS1 系统盘售罄」「Data 云硬盘规格不支持」让用户一眼看出瓶颈属于计算、系统盘还是数据盘。3. 给出可执行的后续动作若为规格售罄：列出当前区域仍可成功创建的替代规格或模板；若为排队中：在原页面展示排队位置与预计等待时间，而不是让用户盲目重试。4. 在失败页集中展示各模板的供给状态标注 AI Shell、DevStation 等各模板当前的排队或售罄状态，让用户在选择模板前就能看到差异，避免在模板之间盲目试错。三、期望效果用户在看到失败提示的当下，就能判断出「是哪个区域、哪个环节、因为什么资源不够、下一步该点哪里」，把原本需要多轮试错才能得到的结论，直接呈现在一次失败的结果页上，显著降低排查成本并提升创建成功率。

场景：在开发者活动列表页（developer.huaweicloud.cn/events）浏览报名中的活动时，列表卡片只显示活动名称、时间、类型和「报名进行中」标签，不显示本人是否已报名。我需要逐个点进活动详情页才能确认是否已经报过名，今天在为活动任务挑选活动时连续点开了三个活动详情页，发现其中有的已经在往期报过名，只能返回列表再换一个，来回跳转比较浪费时间。 期望效果： 1. 在活动列表卡片右上角或报名状态旁增加「已报名」角标，已报名的活动一眼可辨； 2. 若支持筛选更好：列表页提供「仅看未报名」的过滤选项，方便做任务或找新活动的开发者快速定位； 3. 已报名活动在列表页点击后仍进入详情页，但详情页报名按钮区可同步展示报名时间和渠道信息。 这样可以减少重复跳转确认的成本，也能让报名数据更透明，避免用户对同一活动重复报名。场景描述：    建议方案：  

问题现象鸿蒙实践中心（harmonybp）的每日任务「Star 鸿蒙开发实践中心案例仓」（+30 积分/天，evaluator 为 external_check）从 2026-11-06 起连续两天无法判定完成。任务接口返回：- today_status: todo，completed_at: null- git_bound: true- orgs: ["harmony-practice-center"]、match: "any"、repos_configured: true- repos: []已排除的原因（逐项实测）：一、绑定账号与浏览器登录账号不一致——排除。个人工作台页面显示当前登录账号，与任务接口返回的 git_login 完全一致。二、重复 star 或取消 star 导致状态异常——排除。另取一个从未 star 过的案例仓点星，星数从 406 变为 407，平台仍为 todo。三、star 没真正记到该账号名下——排除。直接查 GitCode 的 API，该账号的 starred 列表里已包含 harmony-practice-center 组织下多个仓（含当天操作的那一个）。也就是说：账号对了、组织对了、star 也确实记录了，唯独平台侧的 external_check 不认，completed_at 一直为 null。对照参考：同一个任务在 2026-11-04、11-05 是正常的，点星后几分钟内就从 todo 变成 done，积分也能到账。11-06 起开始失效。影响一、用户白做。任务说明是「绑定 GitCode 账户并 Star 指定案例仓」，用户完成了，平台不认，30 积分拿不到，而且页面上没有任何失败原因，用户只会反复重试。二、无法自查。用户看不到平台的核查时间点、核查结果、失败原因，只能凭猜。三、影响连续天数。因为每天都要做一次，核查链路一旦坏了，每天的 30 分都会丢。建议1. 修复或重启 external_check 的核查链路，并回补 2026-11-06 起受影响的积分。2. 任务卡片上展示核查状态与时间点，例如「最近核查：2026-11-07 15:00，结果：未通过」。3. 核查失败时给出可操作提示（例如「未检测到 star，请确认使用的是已绑定账号」），而不是静默保持未完成。4. 增加「重新核查」按钮，让用户不必等到第二天。补充说明这类外部核查任务最怕的就是「静默失败」：用户做了、平台没认、两边都没有回执。附上本次核查用的接口字段与对照过程，便于定位是核查任务未执行、还是查询条件（orgs / match / repos）配置导致命中判定为空。

问题现象进入 AI DevSpace 开发环境后，页面会显示一行配额信息「剩余核时 7748」。但页面上没有任何地方说明：这些核时会不会过期、什么时候过期、按什么速率消耗、用完之后的后果是什么。实测观察：该数值在环境页常驻显示，但不随会话结束而提示变化，也没有「本次会话已消耗 X 核时」的回执。影响一、无法规划使用节奏。用户看到 7748 这个数字，不知道它是「还有 7748 小时随便用」还是「这个月只剩这些，用完就没了」。前者可以放开用，后者需要省着用，两种判断带来的行为完全不同。二、到期风险不可见。如果核时是按月重置或按活动周期失效，用户在失效前一天才发现清零，损失无法挽回；反之如果永不过期，用户又可能因为担心而不敢用。三、与本任务的目的相冲突。DevSpace 是每日任务之一，设计目的就是让用户体验产品。用户如果因为不确定配额规则而不敢多用，等于削弱了任务本身的推广效果。建议1. 在「剩余核时」旁增加悬停说明或小字：到期时间、重置周期、消耗速率（例如每小时消耗 1 核时）。2. 会话结束时给一条消耗回执：本次使用 X 分钟，消耗 Y 核时，剩余 Z。3. 核时低于某个阈值（例如剩余 10%）时在环境页给醒目提示。4. 若核时存在过期时间，在接近到期时提前通知，而不是静默清零。补充说明配额类的数字，光有「剩余多少」是不够的，缺了「时间维度」，用户就只能靠猜。加一行到期说明的成本很低，但能直接决定用户敢不敢放心用。

场景描述：2026-11-07 在 AI Agent 开发实践中心（https://hands-on-agent.developer.huaweicloud.cn/）按「通用技能」目录选型时发现：目录把「通用-内容-小红书跨平台改写」列为可用技能，描述为「一份内容多平台改写分发」，链接指向 https://gitcode.com/agent-best-practices/xhs-cross-platform-rewrite 。 实测该仓库只有 1 个 README.md，全文仅一行标题「# 跨平台内容适配-小红书专属二次改写Skill」，没有 SKILL.md、没有脚本、没有模板和使用说明，clone 后无任何可用内容。逐仓核查组织主页 README（https://gitcode.com/agent-best-practices）列出的 19 个「通用技能」仓库：其余 18 个均含 SKILL.md（文件数 5~651），只有这 1 个是空壳；该仓库自身 Issue #1~#5 已有多位开发者反馈「仓库仅有标题、缺少技能实现」。 复现方式：git clone --depth 1 https://gitcode.com/agent-best-practices/xhs-cross-platform-rewrite.gitfind . -type f -not -path '*/.git/*' # 结果：仅 README.md对照：对 19 个通用技能仓执行同样检查，统计 SKILL.md 是否存在，18 有 / 1 无。 影响：项目目录是开发者选型的唯一入口。把占位仓库与 18 个可用技能并列、并给出完整功能描述，会让按「方式二：本地 clone 体验」「把 skills/xxx 放进 Agent 技能目录」操作的用户拿到一个不能用的技能；成长中心的去 Star、提 Issue 等实践任务也会把流量导向这里。目录目前靠人工维护，新增仓库时没有校验，后续还会出现同类脱节。 建议方案：1）在目录条目增加显式状态（如「规划中·暂无实现」），把未实现项单独归入「规划中」小节，不与可用技能混排，并注明预期交付物；2）补一个最小可用实现：SKILL.md + 一条输入/输出示例，让链接至少能跑通；3）增加组织级自检：CI 遍历目录中所有仓库链接，检查 SKILL.md（或各仓约定的入口文件）是否存在，缺失即告警；顺带校验 Star 数、License 等长期不同步的字段。从机制上避免「目录说有、仓库里没有」。 备注：同一现象已在组织仓库以 Issue 形式反馈（https://gitcode.com/agent-best-practices/Readme/issues/172）。本条是从平台目录维护机制角度提改进建议，两者互为佐证，不是重复提单。