场景描述：用了两千积分配置的mcp还是用不了[图片][图片]  建议方案：  

场景描述： 再codeArts中使用智能问答，不管是用GLM-5.2, 还是礼包模型。都无法完成该任务。[图片][图片][图片] 建议方案：修复BUG  

问题描述 (Description) officeace 建议岗位身份选择的时候，增加供应链岗位 使用场景 (Usage Scenario) 在 officeace 选择岗位身份时 期望能力 (Expected Capability) 岗位身份选择中增加供应链岗位选项 声音来源 (Voice Source) 企业微信

问题描述 (Description) officeace 建议优化基础页面功能，增加自定义个性化技能或常用技能，技能中不要有五花八门的东西，就放置对大多数人有用的技能，比如清理电脑，定时任务，文件审核，生成视频，电脑杀毒，系统安装（安装系统中包含OA软件）等等常用技能。一定要找准用户需求和痛点，不要泛泛的开发 使用场景 (Usage Scenario) 在 officeace 技能页面筛选和使用技能时 期望能力 (Expected Capability) 优化基础页面功能，增加自定义个性化技能/常用技能，聚焦清理电脑、定时任务、文件审核、生成视频、电脑杀毒、系统安装（含OA软件）等大众刚需技能，找准用户需求和痛点 声音来源 (Voice Source) 企业微信

问题描述 (Description) officeace 建议在深度调研分析中断后，继续任务应该从失败的地方继续而不是重新开始 使用场景 (Usage Scenario) 深度调研分析任务中断需要继续时 期望能力 (Expected Capability) 深度调研分析中断后，继续任务从失败/中断点续跑，而不是重新开始 声音来源 (Voice Source) 企业微信

描述问题 (Description) 使用 OBS Python SDK 执行分片上传（multipart upload）时，上传到约 60% 因网络抖动中断。重新调用上传接口后，之前已上传的分片无法被识别和复用，导致从头重新上传，耗时翻倍且浪费带宽。 复现步骤 (To Reproduce) 开发环境通过 Python SDK 上传 5GB 数据集到 OBS，使用 CreateMultipartUpload + UploadPart 流程，上传至第 120 个分片时网络中断，恢复后重新执行上传，SDK 未自动检测已上传分片列表。 预期行为 (Expected behavior) SDK 应提供自动断点续传能力，或在文档中明确说明如何通过 ListParts + UploadPart 组合实现续传，而非默认从头重传。 声音来源 (Voice Source) OBS, huawei-cloud-vod-collector

场景描述：[图片]CodeArts构建索引一直卡4%    建议方案：  

关于"做任务赢积分"任务拆解为分步完成、分步记录的建议一、场景描述1. 一个"任务"里藏着好几个动作，却只有一个开关。​ 社区发帖、开发者空间实操、云实验上机、任务中心活动——这些任务在实际操作中往往包含多个步骤：浏览资料、开通服务、完成调用、提交成果、发布内容。但页面只呈现"未完成 / 已完成"两种状态，做到第三步和一步没做，看起来完全一样。2. 一步没被识别，等于全部重做。​ 由于任务不可拆分，只要最终状态没点亮，用户无法判断是卡在哪一步，只能凭猜测从头再来。一个耗时 40 分钟的实验，可能因为最后"提交结果"这一步没被记录而被迫完整重做一遍——这是当前最消耗耐心的体验痛点。3. 跨板块数据分散，聚合结果不可信。​ 社区、开发者空间、云实验、任务中心分属不同系统，各自的完成口径与同步节奏不同。用户常常遇到"实验平台显示已完成，任务中心仍显示去完成"，客服也无法定位到底哪一个环节的数据没回来。4. 完成状态更新滞后且无回执。​ 动作做完之后页面静默，既没有"已完成待结算"的中间态，也没有更新时间和预计延迟说明。用户只能反复刷新、反复重做，最后在不确定中放弃。5. 只发"全完成"奖励，中途毫无正反馈。​ 写一篇技术博客、完成一次认证实验这类高投入任务，用户往往要做很久。过程中没有任何阶段性反馈与收益，一旦中途被打断，投入的时间完全沉没，下次再启动的心理门槛更高。6. 周期任务一旦断链，本期直接作废。​ 日/周任务中任意一步未记录，整个任务判为未完成，本期机会不可补回，长期累积的损失感会直接劝退用户。根因推测： 任务在数据模型上被简化为单一布尔标记，缺少子步骤粒度；完成判定由各业务方自行上报"最终是否完成"，任务中心只接收结果、不掌握过程事件；再叠加缓存与批处理延迟，导致过程既不可见、结果也不可靠。二、建议方案短期（体验层，改造成本可控，建议优先落地）​任务原子化拆解。​ 把每个任务拆成 2—5 个可独立判定的子步骤，每步用一句话写清判定条件。例如一个云实验任务拆为：浏览实验手册 → 创建实验环境 → 完成关键操作 → 提交实验成果。步骤粒度以"可在数分钟内完成"为宜。逐步点亮，进度可视。​ 卡片上展示 checklist 与"2/4 已完成"进度条，每完成一步立即打勾并给出明确回执："第 3 步已于 12:03 记录"，让用户随时知道做到哪、还差哪。分步发放积分。​ 每完成一个子步骤即发放对应积分（如总分的 20%/30%/30%/20%），全部完成再发满额。中途退出也已有部分收益，显著降低沉没成本与放弃率。断点续做。​ 已完成的子步骤在本周期内长期保留，用户回来只需补做剩余步骤，不必从头开始。这一条能直接解决"被迫重做"的核心痛点。每步可自查、可申诉。​ 未点亮的步骤显示具体缺口，如"尚未检测到有效调用记录（需在北京四区域）"，并提供单步刷新与申诉入口，携带步骤流水号。中期（能力层，治本）​统一子步骤事件契约。​ 定义标准的"步骤完成"事件，社区、开发者空间、云实验、活动系统按同一契约上报，任务中心只做规则匹配与聚合，从根上消除多口径。步骤级状态机与幂等。​ 每步独立维护"未开始 / 进行中 / 已完成"，重复上报幂等且不回退，避免重做反而把已点亮状态冲掉。分钟级增量 + 每日全量对账。​ 状态更新做到分钟级，每日跑一次全量差异扫描，自动补发遗漏的步骤状态与积分，并推送通知告知用户。判定规则可解释化。​ 规则引擎输出"未满足原因"而非仅返回布尔值，把黑盒判定变成用户可自查的清单。长期（体系层）​任务可视化编排。​ 运营配置任务时直接拖拽编排子步骤、依赖关系（串行 / 并行 / 可选）与判定条件，无需开发介入，让"拆解"成为任务设计的默认方式而非额外成本。路径化与关卡化。​ 把分步任务串成"新手—进阶—专家"成长路径，每完成一步即时给正反馈并推荐下一步，形成持续动力。逐步漏斗分析。​ 统计每个子步骤的完成率与流失点，识别高流失步骤并针对性拆分或降低门槛，用数据驱动任务迭代。三、风险与配套拆分后事件量会增加，需做好批量上报、限流与成本控制；内容类步骤（发帖、提交心得）应设质量校验与审核门槛，防止拆步骤刷分，且分步发放的积分需支持违规回收；判定规则变更须向后兼容，避免已完成步骤被追溯失效；跨系统事件采集遵循最小必要原则并做脱敏。结语： 用户的诉求并不是多拿积分，而是让付出的每一步都被看见、被记录、被确认。把任务拆成几步、逐步完成、逐步发分，既能让进度透明、减少无谓重做，也能用阶段性反馈把"心累"变成"想继续做下去"，这对任务完成率和社区活跃度的提升，远比单纯加积分更有效。  

场景描述：MaaS模型即服务的模型的消耗只能通过token消耗来反推金额计算，有时计算的金额与实际消耗的金额不一致，希望能看到独立详细的token与金额消耗   建议方案：希望MaaS模型即服务能看到各个apikey的具体token用量金额消耗 

场景描述：https://bbs.huaweicloud.cn/blogs如题，取消预览和开启全屏后，无论怎么滚动，画面的文字位置都一样，但是滚动条已经移动了。 [图片]建议方案： 修复滚动问题