一、概述1.1 案例介绍AI Shell 是智能 AI 命令行工具，以自然语言驱动终端操作，无需熟记复杂指令，大幅降低使用门槛，一站式完成华为云资源查询、操作、运维工作，让终端操作更高效、更智能。让华为云更好用、更易用。在个人开发者、小型团队和训练营学习场景中，云资源管理经常遇到一个很现实的问题：资源创建之后，如何持续确认它是否命名规范、标签完整、生命周期清晰、没有长期闲置或公开访问风险？如果每次都依赖人工进入控制台逐项查看，效率低，也容易遗漏。企业级云治理平台能力完整，但对于个人开发者或活动案例来说，又容易引入较多付费资源和配置成本。本案例使用华为云 AI Shell 辅助设计并生成一个“零成本云资源体检助手”。该工具通过 inventory.json 模拟资源清单，通过 rules.yaml 定义检查规则，使用 Python 完成命名规范、标签合规、过期时间、闲置资源和公开访问检查，最终输出 Markdown 与 JSON 两种报告。完成本地验证后，再部署到 FunctionGraph 事件函数中运行，形成一条完整的云端实践链路。本案例最终实现了以下目标：通过 AI Shell 自然语言交互完成方案设计、代码生成、项目修正和部署记录整理。使用 GitCode 托管完整项目，代码和配置可复现。使用 FunctionGraph 运行巡检逻辑，不购买服务器。使用本地模拟资源清单，不调用真实云 API，不配置 AK/SK。通过函数返回值和日志输出报告，不使用外部存储或消息服务。对公开仓库中的报告和资源清单提供脱敏版本，方便案例公开传播。1.2 适用对象企业个人开发者高校学生1.3 案例时间本案例总时长预计60分钟。1.4 资源总览资源名称规格单价（元）AI Shell体验版免费FunctionGraph函数每月前100万次调用免费免费华为云资源模拟免费二、AI Shell 使用指导2.1 获取访问秘钥AK 是Access Key（访问密钥）的缩写, 用于标识用户身份的唯一 ID, 通常公开传输。SK 是Secret Key（秘密密钥）的缩写，用于生成请求签名的保密密钥，仅用户和服务端持有。其核心功能是通过对称加密机制验证请求发送者的合法性，防止未授权访问。备注：如果已有访问密钥，本步骤可以忽略。2.2 登录进入 AI Shell 环境登录进入开发者空间官网，从侧边栏快捷入口一键拉起 AI Shell。同意华为云开发者服务协议、隐私声明及开发平台协议。同意将临时访问凭据(AK/SK)同步至 AI Shell 环境，免手动配置直接使用。进入 AI Shell。三、AI Shell 案例实战指导活动名称：【案例共创】【第12期】基于华为云AI Shell完成云资源管理、云服务运维和应用部署案例方向：云资源管理、云服务运维、应用部署代码仓库：https://gitcode.com/N9_xx/AIShell_CloudHealthChecker演示环境：华为云 AI Shell、GitCode、FunctionGraph 函数工作流成本说明：本案例严格采用零付费架构，仅使用 AI Shell 辅助生成、GitCode 代码托管、FunctionGraph 免费额度内运行、本地 JSON/YAML 配置文件和函数日志/返回值。不使用 OBS、SMN、API Gateway、ECS、RDS、AK/SK、云 API、公网带宽或任何需要购买的云资源。1. 场景痛点云资源治理并不只属于大型企业。个人开发者和小团队同样会遇到以下问题：痛点典型表现影响资源命名不统一demo、test-app-server 等名称缺少环境和业务语义后续定位资源和排障困难标签缺失没有 owner、environment、cost-center、project 等标签无法明确负责人、环境和成本归属临时资源长期保留测试资源没有过期时间或长期未使用容易产生配额占用和潜在费用风险运维检查依赖人工需要手动进入多个控制台页面查看效率低、不可复用、容易遗漏新手担心误用付费资源不清楚哪些服务会产生费用降低实践意愿因此，本案例的设计原则是：用最小资源完成可复现的云资源巡检闭环。即使不购买 ECS、RDS、OBS 等资源，也可以通过模拟清单和规则引擎，把云资源治理的关键方法跑通。2. 方案架构整体架构如下：flowchart LR A["开发者"] --> B["AI Shell"] B --> C["生成和修正项目代码"] C --> D["GitCode 仓库"] D --> E["FunctionGraph 事件函数"] E --> F["inventory.json 模拟资源清单"] E --> G["rules.yaml 检查规则"] E --> H["巡检引擎 inspector.py"] H --> I["命名/标签/过期/闲置/公开访问检查"] I --> J["Markdown/JSON 报告"] J --> K["函数返回值和日志输出"] 为了保证零付费，本案例在 AI Shell 中明确要求不使用 OBS、SMN、API Gateway、ECS、RDS、AK/SK 和云 API，最终方案仅保留本地文件、Python 逻辑、GitCode 和 FunctionGraph 免费额度。方案中各模块职责如下：模块作用AI Shell负责方案设计、项目结构生成、代码生成、部署步骤整理GitCode托管项目源码、配置文件、脱敏示例和 READMEFunctionGraph承载 Python 巡检逻辑，作为 Serverless 执行环境inventory.json模拟云资源清单，不调用真实云 APIrules.yaml定义命名、标签、过期、闲置、公开访问等检查规则src/checkers/具体检查器模块src/reporters/Markdown 和 JSON 报告生成模块函数返回值/日志输出巡检结果，不依赖外部存储和通知服务3. 技术选型技术或服务选择原因AI Shell支持自然语言描述需求，能够快速生成方案、代码和部署建议GitCode满足活动对代码仓库的要求，便于公开复现FunctionGraphServerless 运行环境，按需执行，免费额度足够覆盖本案例Python 3.9语法清晰，适合编写规则检查、报告生成等脚本JSON/YAMLJSON 适合描述资源清单，YAML 适合维护可读的检查规则Markdown/JSON 报告Markdown 便于阅读和投稿，JSON 便于后续自动化处理4. 前提条件已注册并完成实名认证的华为云账号。已进入华为云 AI Shell 云端作业环境。已创建 GitCode 仓库。已开通 FunctionGraph 函数工作流并能创建事件函数。本案例不需要购买 ECS、RDS、OBS、SMN、API Gateway、公网带宽等资源。5. AI Shell 生成项目我首先向 AI Shell 描述目标：设计一个零成本云资源体检助手，使用 AI Shell 辅助生成、GitCode 托管、FunctionGraph 运行，并要求不购买任何付费资源。请帮我设计一个零成本云资源体检助手。 要求： 1. 使用华为云 AI Shell 辅助生成方案和代码； 2. 使用 FunctionGraph 运行巡检任务； 3. 不购买 ECS、RDS、数据库、付费存储或公网带宽； 4. 使用 Python 实现； 5. 通过 inventory.json 模拟资源清单； 6. 通过 rules.yaml 定义命名、标签、过期时间、闲置和公开访问检查规则； 7. 输出 Markdown 和 JSON 两种报告； 8. 给出 GitCode 仓库目录结构。AI Shell 根据该约束生成项目目录和代码，并明确标注方案不使用付费服务。6. 项目结构AI Shell 最终生成的项目结构如下：cloud-health-checker/ ├── config/ │ ├── inventory.json # 模拟资源清单 │ ├── inventory.json.redacted # 公开投稿使用的脱敏清单 │ └── rules.yaml # 检查规则配置 ├── deploy/ │ └── functiongraph.yaml # FunctionGraph 部署说明 ├── output/ │ └── report.md.redacted # 脱敏版报告 ├── src/ │ ├── main.py # FunctionGraph 入口/本地运行入口 │ ├── inspector.py # 巡检引擎 │ ├── config_loader.py # 配置加载 │ ├── checkers/ │ │ ├── naming_checker.py # 命名规范检查 │ │ ├── tag_checker.py # 标签合规检查 │ │ ├── expiry_checker.py # 过期时间检查 │ │ ├── idle_checker.py # 闲置资源检查 │ │ └── public_access_checker.py# 公开访问检查 │ └── reporters/ │ ├── markdown_reporter.py # Markdown 报告 │ └── json_reporter.py # JSON 报告 ├── requirements.txt └── README.md进入项目目录后，AI Shell 给出了本地运行和查看报告的命令。7. 规则设计规则文件 config/rules.yaml 定义了五类检查：检查类型说明命名规范检查按资源类型匹配命名规则，例如 ECS 使用 env-project-service-index标签合规检查检查 owner、environment、cost-center、project 等标签过期时间检查检查资源是否已过期或即将到期闲置资源检查根据 CPU、网络流量、绑定状态等模拟字段判断闲置公开访问检查检查安全组、访问来源等公开暴露风险部分规则示例如下：naming: enabled: true severity: warning rules: ecs: pattern: "^(prod|test|dev|staging)-[a-z0-9-]+-[a-z0-9-]+-[0-9]+$" example: "prod-web-frontend-01" description: "ECS 命名格式: env-project-service-index" tags: enabled: true severity: warning required_tags: - key: "owner" description: "资源负责人" - key: "environment" description: "环境标识" allowed_values: ["production", "test", "development", "staging"] expiry: enabled: true severity: critical这套规则的优势是可配置。后续如果团队命名规范或标签规范变化，只需要修改 rules.yaml，不用改检查器代码。8. 模拟资源清单与脱敏处理本案例使用 config/inventory.json 作为模拟资源清单，不调用真实云 API。清单中包含 ECS、VPC、OBS、RDS、安全组、EIP、ELB 等资源类型的模拟字段，用于验证不同检查器的能力。由于案例需要公开投稿，AI Shell 同时检查了资源清单和报告中的敏感信息，并生成脱敏版本：文件说明config/inventory.json项目运行使用的模拟资源清单config/inventory.json.redacted公开展示使用的脱敏清单output/report.md.redacted公开展示使用的脱敏报告脱敏处理保留资源类型、风险类型、检查结果，不展示账号 ID、真实资源 ID、手机号、访问地址等敏感信息。9. 核心代码实现FunctionGraph 入口和本地运行入口都在 src/main.py。核心函数为 handler(event, context)，它会调用巡检引擎 run_inspection()，并将 Markdown 和 JSON 报告放入返回值。def handler(event=None, context=None): print("[INFO] FunctionGraph 函数开始执行") try: result = run_inspection() response = { "statusCode": 200, "body": { "message": "巡检完成", "duration_seconds": result["duration_seconds"], "reports": { "markdown": result["markdown"], "json": result["json"], }, }, } print("[INFO] FunctionGraph 函数执行成功") return response except Exception as e: print(f"[ERROR] 巡检执行失败: {e}") return { "statusCode": 500, "body": { "message": f"巡检执行失败: {e}", "error_type": type(e).__name__, }, } 各检查器被拆分到 src/checkers/ 目录中，报告生成器被拆分到 src/reporters/ 目录中。这样做的好处是：每类检查规则可以独立维护，未来可以继续扩展“配额风险检查”“配置漂移检查”“成本归属检查”等模块。10. 本地运行验证在 AI Shell 中进入项目目录后，执行：cd /root/cloud-health-checker python src/main.py巡检成功后，控制台输出检查摘要，并生成 output/report.md 和 output/report.json。本次模拟资源清单中共有 18 个资源对象。由于每个资源会被多类检查器检查，最终检查资源总数为 90，发现问题总数为 38，其中严重问题 3 个，警告问题 35 个。关键结果如下：指标数量检查资源总数90发现问题总数38Critical3Warning35命名规范问题8标签合规问题12过期时间问题10闲置资源问题8公开访问问题0其中公开访问检查 18/18 通过，说明示例清单没有公开访问风险；其他问题集中在命名、标签、过期时间和闲置资源上，符合资源治理场景中的常见问题分布。11. GitCode 托管本地运行成功后，我将项目推送到 GitCode 仓库：https://gitcode.com/N9_xx/AIShell_CloudHealthChecker仓库中包含源码、配置、部署说明、脱敏清单和脱敏报告，方便评审和开发者复现。推送后，AI Shell 输出的提交信息如下：项目内容提交 ID2a5c916分支main提交信息init zero-cost cloud health checker文件数22 个文件12. 部署到 FunctionGraph在 FunctionGraph 控制台中创建事件函数：配置项值函数名称cloud-health-checker区域华北-北京四 cn-north-4函数类型事件函数运行时Python 3.9委托未使用任何委托内存256 MB超时60 秒这里需要注意，函数名称和 Handler 不是同一个概念。函数名称使用 cloud-health-checker。Handler 根据实际上传包结构填写：本次 FunctionGraph 测试使用的入口为 main.handler，测试成功；如果保持仓库原始 src/ 目录结构上传，则入口可参考 deploy/functiongraph.yaml 中的 src.main.handler。本案例最终以手动测试方式验证函数，不配置定时触发器，避免引入额外资源操作。后续如需扩展为每日巡检，可在 FunctionGraph 中增加 TIMER 触发器。13. FunctionGraph 测试结果创建函数后，使用空 JSON 事件进行同步调用测试：{} 函数返回 statusCode: 200，返回体中包含 message: 巡检完成，并返回 Markdown 与 JSON 两种报告。本次 FunctionGraph 测试统计如下：指标数值检查资源90发现问题38严重问题3警告问题35执行耗时约 0.07 秒报告输出方式包括两种：函数返回值：Markdown 和 JSON 结构直接包含在响应 body.reports 中。控制台日志：巡检过程输出到 FunctionGraph 标准日志。14. 零成本架构验证本案例部署和测试过程中未使用以下资源：资源类型使用情况OBS 对象存储未使用，报告通过函数返回值和日志输出SMN 消息通知未使用，不发送告警通知API Gateway未使用，通过手动测试或 TIMER 触发ECS/RDS 等计算或数据库资源未使用，纯 Serverless 运行公网带宽/EIP未使用AK/SK 凭据未使用，不调用真实云 API云 API 调用未使用，基于本地模拟资源清单巡检巡检数据来自项目内置的 inventory.json 模拟资源清单，检查规则来自 rules.yaml。所有逻辑都在函数运行时内完成，不需要外部依赖服务来存储报告或转发通知。15. 案例效果本案例完成后，开发者可以获得一个可复现的云资源体检工具：修改 inventory.json 即可调整被检查资源。修改 rules.yaml 即可调整治理规则。本地执行 python src/main.py 可快速验证。上传到 FunctionGraph 后，可以通过手动测试验证函数运行。后续可配置 TIMER 触发器，实现周期性巡检。脱敏版报告摘要如下：# 云资源体检报告（脱敏版） ## 汇总信息 - 检查资源总数：90 - 发现问题总数：38 ### 问题分布（按严重程度） | 严重程度 | 数量 | |----------|------| | warning | 35 | | critical | 3 | ### 问题分布（按检查类型） | 检查类型 | 数量 | |----------|------| | naming | 8 | | tags | 12 | | expiry | 10 | | idle | 8 | 16. 遇到的问题与解决。16.1 FunctionGraph 函数名称和 Handler 容易混淆创建函数时，函数名称应填写 cloud-health-checker，不能填写 src.main.handler。Handler 是代码入口，需要在函数代码配置中填写。根据上传包结构不同，入口可能是 main.handler 或 src.main.handler。本次手动测试使用 main.handler 成功。16.2 公开投稿需要脱敏虽然本案例使用模拟资源清单，但其中仍可能包含类似账号 ID、资源 ID、IP、负责人等字段。投稿前使用 AI Shell 检查并生成脱敏版本，保留风险类型和检查结果，避免公开敏感信息。17. 扩展方向在保持低成本和安全边界的前提下，后续可以继续扩展：增加更多资源类型的规则，例如 CCE、DCS、LTS 等。增加资源配置漂移检查，比较当前清单和基线清单差异。增加团队级规则模板，不同项目使用不同 rules.yaml。在 FunctionGraph 中配置 TIMER 触发器，实现每天自动巡检。在不引入付费资源的前提下，将报告输出到函数日志，由人工或后续流程查看。如果用于真实生产环境，应优先使用只读权限，并在充分评估费用与安全边界后，再考虑接入真实云 API。18. 案例总结本案例基于 AI Shell、GitCode 和 FunctionGraph，完成了一个严格零付费的云资源体检助手。它不依赖真实云 API，不配置 AK/SK，不购买服务器和数据库，仅通过本地模拟清单和规则文件完成资源治理实践。从实践过程看，AI Shell 的价值不仅在于生成代码，也在于帮助开发者不断收敛方案边界：当初始方案包含可能引入计费或权限复杂度的服务时，可以通过明确约束，让 AI Shell 重新设计为更符合活动要求的架构。FunctionGraph 则提供了一个轻量的 Serverless 执行环境，使巡检逻辑可以从本地脚本进一步部署为云端函数。最终，本案例形成了完整闭环：AI Shell 生成方案和代码，GitCode 托管项目，FunctionGraph 部署运行，函数返回值和日志输出报告。这条链路既满足活动对实践完整性的要求，也能为开发者提供一套可复用的云资源治理思路。19. 参考链接GitCode 项目仓库：https://gitcode.com/N9_xx/AIShell_CloudHealthChecker活动链接：https://bbs.huaweicloud.com/forum/thread-0212721816590407924-1-1.html【案例共创】【第12期】基于华为云AI Shell完成云资源管理、云服务运维和应用部署https://bbs.huaweicloud.com/forum/thread-0212721816590407924-1-1.html

大佬们好，我是一个啥都不懂的大一学生，在我跟着直播课安装云码道后，我跟智能体对话发送消息，就显示会话创建失败，智能体什么反应都没有，一句话都不说，想问问这是为什么呀，感谢解答。

关于本次比赛赛题与评测机制的若干疑问与建议“通用的算法就会慢,而特化的算法就会快”,这是我对算法设计的理解.本次复赛训练赛数据集、得分规则设计敷衍, 与正式赛差距过大,导致许多参赛队伍浪费时间在错误的技术路线上.在我看来,训练赛的分数差异主要由算法运行效率带来, 而追求极致的运行速度就会导致丧失部分通用性,而正式赛又变成了重点考察算法在不同数据集上的通用性,分数差异的原因变成了是否能适应多个数据集. 这种变化导致了许多花费大量时间参与训练赛的队伍无缘决赛。1. 背景意义与工业价值本次赛题本质上更接近一个已经被充分研究的“两多边形分离”问题，整体建模较为理想化。我比较关心的是，这样一个问题早已困扰工业界许久.那么让计算几何初学者的同学们来研究是否合理?同学们是否真的能改进现有的算法?赛题组所构造的多边形和查询点是否过于奇特以至于真实世界几乎不可能出现?2. 评测波动对成绩的影响本次赛题的评分规则与程序运行时间直接相关，这导致得分会明显受到评测机时间抖动的影响。实际体验中，分数波动甚至可能接近 3 万分 量级。尽管赛题组声明“取历史最高分作为最终最好成绩”，但这并不能完全解决问题。选手提交一个真实有效但提升幅度较小的优化后，优化效果可能被评测机抖动掩盖。这样一来，选手就无法准确判断某次改动是否真的有效，最终只能通过线上、线下重复评测同一方案、观察平均表现来做判断。这会显著降低选手策略迭代的效率，也会让优化过程更像“刷波动”而不是“做优化”。3. 比赛周期与练习赛设计本次初赛、复赛以及对应练习赛的周期被拉长到将近一个月。对于投入较多时间的选手而言，这样的赛程成本较高，但从结果来看，很多练习阶段的优化并不能有效复用到正式赛中。初赛阶段初赛练习赛与正式赛的判分规则差异巨大；选手在练习阶段很难明确优化精度或者时间，以及精度的具体优化程度；大量选手在练习赛阶段几乎完全同分，区分度有限。复赛阶段复赛内容基本延续初赛正式赛，变化主要只有数据范围和预处理时间；整体内容创新少，出题数据疑似有误；这样的练习赛设计，是否值得选手投入长达一个月的时间去做专项优化？如果练习赛无法有效引导正式赛方向，那么它的训练价值会被明显削弱。4. 数据分布的合理性某个下发数据集经过可视化后如下图所示，其中红色部分为输入查询点：从图中看，5 万个查询点 几乎集中在同一狭窄区域内。这让我产生两个疑问：这个练习赛中的查询分布，与正式赛中的查询分布是否属于同一分布？如果其他未下发数据集也存在类似现象，那么练习赛下发的数据分布是否足够合理？此外，另一份下发数据集似乎也有类似问题，这里不再展开。如果练习赛数据本身带有明显的局部集中性，那么很多高性能优化实际上可能只是针对特定分布做特化，而不具备普适意义。5. 权重设置的参考意义练习赛 Checker 中的 omega 设计看起来极不平衡。据观察，练习赛存在 0.04、0.55、2.25 三个档次，但练习赛中似乎并没有 0.55 档次的数据。这会导致一个明显结果：2.25 档次数据的得分极高；0.55 档次的数据并未在练习赛出现；0.04 档次的数据得分极低，甚至没有优化这个档次分数的意义。但到了正式赛中，权重又被大幅调整，更偏向各数据集之间的平衡。这就使人怀疑：练习赛的判分结果，是否真的具有足够的参考意义？如果练习赛和正式赛的权重导向差异过大，那么练习赛阶段的优化策略就很可能是误导性的。6. 时间参数 T 的设置问题练习赛似乎对所有数据集统一设置了同一个参考时间 T。这会在不同规模的数据集上产生非常不均衡的性能分表现。例如：在 1 万查询 的数据集上，性能分可能只能拿到正确分的 20% 不到；而在 5 万查询 的数据集上，性能分却可能达到正确分的 50% 左右。这会直接导致：是否要追求时间分，很大程度上取决于数据集规模；某些数据集几乎可以只考虑正确率；而另一些数据集又必须为时间分做专门优化。这样一来，选手的优化目标并不统一，而是被数据集规模“绑架”。如果参考时间 T 的设定不能体现不同数据集的客观难度，那么评分机制就难以准确衡量算法本身的性能水平。7. 总体感受与核心问题整体来看，我认为：一场追求性能的比赛，不应该在练习赛和正式赛之间存在如此大的差异。否则，比赛很容易从“考察算法与工程优化能力”，变成“考察谁更擅长针对特定参数和特定分布做拟合”。数据集特征一旦发生变化，那些针对数据特化的方案运行速度自然也会出现明显波动。而正式赛不仅没有下发新的示例数据集，同时线上数据集数量又较多（大约 9 个左右），一次完整评测大约需要 7 分钟 才能返回结果。这意味着：练习赛无法拉开参赛选手的策略差距；正式赛无法在 3 小时 内让选手迅速适应如此庞大的数据分布变化；在这种情况下，正式赛成绩很大程度上依赖于选手是否“提前猜中”出题方向，而不是是否具备稳定、通用、可迁移的优化能力。个人认为, 今年的赛题组对赛题的态度十分敷衍,毁掉了前几年赛题组努力树立出来的口碑.应当给所有参赛选手道歉，下面是部分问题列举:初赛练习赛任务书错误频出, V1.0中提到“保证两个多边形都是凸多边形”, 而下发的数据集却存在凹多边形.赛题组的空中宣讲会照本宣科, 回复的问题都是稿子提前打好的,失去了宣讲会原本的意义赛题组在初赛训练赛阶段表示对选手的得分仅仅34w不满(来源于论坛其他帖子), 然而自己的交互器输入输出的方式竟然是cin,cout,直接导致了训练赛阶段90%以上的耗时都来源于交互器的IO赛题组的程序安全意识淡薄, 谁能想到线上运行平台的沙盒竟然没有禁止选手读写文件? 而赛题组的解决方式竟然是禁止使用多线程/进程? ?选手在论坛中积极提出问题以及反馈,而赛题组却装聋作哑,只回复简单的问题,其他的一概不回复赛题组宣称四月八日会下发判题器与详细得分说明,然而大家等到了晚上十一点多仍然没有等到赛题组宣称某日晚上八点公布晋级复赛名单,但是却让选手们又多等了接近一个小时赛题组宣称某日早上九点下发复赛训练赛赛题,然而到了九点半又说十二点发布,让选手白白浪费时间等待,而复赛所带来的修改竟然是预处理时间从10s变成2s, 严重怀疑赛题组是当日上午九点才开始复赛赛题相关的准备工作8. 希望赛题组回应的问题我比较希望赛题组能够明确回应以下问题：本题当前设定的工业落地价值是否充分？练习赛与正式赛在评分规则、权重设计、数据分布上的差异，是否经过充分论证？当前评测波动较大的情况下，是否有更合理的机制帮助选手判断优化是否真实有效？练习赛下发数据与正式赛数据是否属于同类分布？如果不是，练习赛的训练意义在哪里？统一参考时间 T 的做法是否合理？是否考虑过按数据规模或难度分层设计？当单次评测耗时较长、正式赛时间又有限时，如何保证比赛考察的是算法能力，而不是“参数拟合运气”？附注： 本帖核心观点内容由本人撰写，AI 协助进行内容润色与排版优化。

队友可以和队长换位置吗

当前鸿蒙PC上CodeArtsIDE的首要开发方向主要在开发语言的细节支持上，但是我们必须要承认的是，目前鸿蒙生态建设情况距离可以真正使用CodeArtsIDE进行开发还相去甚远，我在下载这个APP后一直想用，但基本没有使用机会。我想，对于开发者来说，大部分开发时间在Windows主机上，有时外出会携带笔记本电脑，那么IDE只需要支持远程开发功能，就可以完全弥补当前生态建设处于早起阶段的不可用问题，而且这个功能易于实现，大部分功能可以依托主力开发设备上的Windows，这样就不需要通过远程桌面的方式进行非常卡顿的开发操作，同时增加盘古大模型能力，实现这一功能将借助Windows后端极大提高鸿蒙PC的开发实用能力。

CodeArts中的jupyter中怎么找不到Restart

访问AICC作战平台https://scp.sd.huawei.com没有权限，需后台人员添加白名单

问题来源】【必填】    中国电信【问题简要】【必填】系统自动拨打用户电话，振铃期间，向用户播放视频名片，显示身份；目前振铃期间无法播放视频文件，只有摘机之后才能正常播放视频【问题类别】【必填】    ivr流程开发（多实例自启动流程）【AICC解决方案版本】【必填】SCEWIN_ICD_V300R008C25SPC016【期望解决时间】【选填】2024-11-13之前【问题现象描述】【必填】多媒体呼出cell执行成功以后，无法播放视频文件，只有摘机以后手机上才播放视频文件，从ivr_trace.log日志上来看，振铃期间是有调用《播放视频》的复合cell，但是手机上没有播放视频，只有接通以后，再播放振铃期间的视频文件

1、建立呼叫时会生成一个四字节的呼叫标志，用变量存储2、使用cell获取呼叫ID（十六进制），根据呼叫标志查询到呼叫id的十六进制字符串3、根据以下规则转换成呼叫id字符串select CONCAT(CONV(SUBSTRING('66E4FF9C0D240500',1,8),16,10),'-',CONV(concat(SUBSTRING('66E4FF9C0D240500',13,2),SUBSTRING('66E4FF9C0D240500',9,4)),16,10))

【问题来源】深圳容大【问题简要】CID参数变空的问题【问题类别】IVR(gsl)【AICC解决方案版本】ICD V300R008C20SPC002【问题现象描述】我通过读取INI文件给参数赋值，并且打印参数发现是有值的，但是在后续cell使用过程中发现有的参数变成空值了，请问是什么操作会出现这种情况，应该如何避免？

【问题来源】【必填】中信保诚人寿【问题简要】【必填】cms表t_cms_agent_opr_5min，字段current_skill_id这个“-1”是代表什么意思呢，技能队列没有这个id【问题类别】【必填】AICC【AICC解决方案版本】【必填】24.100【期望解决时间】【选填】尽快

【问题来源】【必填】中信保诚人寿【问题简要】【必填】签名算法demo生成的Authorization是唯一的吗，每个接口都要这样生成一个吗，如果有人新生成一个，之前的是不是就不能用了，还能有其他的生成方案吗【问题类别】【必填】AICC【AICC解决方案版本】【必填】24.100【期望解决时间】【选填】在线等

【问题来源】【必填】中信保诚人寿【问题简要】【必填】postman调用cms接口401【问题类别】【必填】AICC【AICC解决方案版本】【必填】24.100【期望解决时间】【选填】在线等【问题现象描述】【必填】使用8.15版本生成的Authorization调用cms接口报401，需要最新获取Authorization的方法

执行loader 报错，报Job commit from a prior MRAppMaster attempt is potentially in progress Preventing multiple commit executions如何解决

4.1以上版本发布了吗，在哪里可以下载