先说结论：AI 画出来的二维码，看起来完整不等于能扫。海报里的二维码要能扫，码本身必须是真实编码出来的，而不是画出来的。## 1. 先分清：码是“画”出来的，还是“编”出来的AI 生图是按像素猜样子，它不知道二维码的黑白方块代表什么数据。画出来的码经常有这几个问题：三个定位方框（左上、右上、左下三个大方块）形状不对、中间的定位点错位、数据区方块多一个少一个。肉眼看不出来，扫码枪一扫就知道对不上。判断方法很直接：拿手机扫一下，扫不出来就别修图，直接重做。修图修不好一个编码错误的码。## 2. 正确做法：用编码工具生成，再贴到海报上二维码用专门的编码工具生成，内容就是你要跳转的链接。比如用 Python 的 qrcode 库：```bashpip install qrcodeqr "https://example.com/你的落地页" > poster-qr.png```生成后先别急着贴海报，单独扫一次：手机自带相机、微信扫一扫都试一遍，能跳到正确页面才算这一步过了。## 3. 贴到海报上，别犯这几个错- **不要拉伸**。二维码拉变形了，方块不再是正方形，扫码成功率直接掉下来。等比缩放，只改大小不改比例。- **留足静区**。码的四周要留至少 4 个方块宽度的白边，别让海报底色、花纹、文字贴着码边。- **别遮定位方框**。中间可以放小 logo，但别盖住三个角的大方块，也别盖住码中间的定位点。- **别过度压缩**。海报导出成 JPG 时压缩率太高，方块边缘会糊。能用 PNG 就用 PNG，必须用 JPG 就把质量拉高。## 4. 做好之后，在真实尺寸下实测最后一步不能省：把海报按最终展示的尺寸打开（手机上看、打印出来、投到大屏上，分别测），在正常距离扫一遍。只在电脑上放大看是没用的，实际尺寸下每个方块至少要有 2 到 3 个像素，太小了手机摄像头对不上焦。按这个顺序走一遍：编码工具生成 → 单独扫码验证 → 等比贴上海报 → 留静区、不遮定位框 → 真实尺寸实测。哪一步出问题就停在哪一步，别直接重画整张海报。

先说结论：别在提交页里继续找删除键了，我亲手走过的另一套华为云提交流程里也没有这个按钮——下面先说我那次的真实经过，再说你现在最该做的三件事。还有一句先说清楚：我没走过大赛的提交流程，下面关于大赛的部分是按我走过的展览馆提交流程类比的，不是大赛官方说明，以大赛官网和官方回复为准。## 1. 我亲手走过的一次：展览馆提交也没有自助删除2026 年 11 月 4 日，我把一个作品提交到华为云开发者作品展览馆，流程是：公开 GitCode 仓 → 在 AI DevSpace 的 AI Shell 里用 Skill 发布 → 选“可投稿”活动 → 提交，作品 ID 007aac5bc4400000，14:48:06 提交成功。整个流程里我没有看到任何“删除作品”或“撤回提交”的自助入口。提交之后我还特意确认过规则：同一个作品每月只能申领一次积分，重复提交同一作品不会重复给分，想换作品要走替换流程，而且替换不发积分。也就是说，在这套流程里，提交之后想改，靠的不是自己点删除，而是走官方的替换或后台处理。大赛和展览馆不是同一套系统，入口、规则都不一样，我不能说大赛也一定是这样。但“提交页不给参赛者开放自助删除”这一点，在我走过的这套流程里是真实的，你在提交页里找不到删除键，很可能不是你找漏了，而是本来就没有。## 2. 先分清：误交的是哪一份你标题说“草稿和最终版都提交了”，这两份的风险不一样，先去“我的作品/提交记录”里核对，不要凭印象处理：1. 看提交记录里，误交的那份现在是什么状态：显示的是“草稿”还是“最终提交”。2. 再看正确作品那份的状态：有没有成功提交、显示的是草稿还是最终提交。3. 如果误交的只是草稿、最终提交那份是对的，风险相对小，重点是让官方确认评审以最终提交那份为准。4. 如果误交的那份本身就是“最终提交”，那才是要尽快处理的那份，拖到评审开始就不好改了。这一步不用联系任何人，自己打开提交记录就能核对，截图把两份的状态、作品名、提交时间都留下来，后面联系官方时直接发过去，比口头描述清楚。## 3. 联系官方时，一次把信息给全你另一个同题帖里已经有人给了核心路径：通过大赛官网的“联系我们/在线客服/技术支持”，或在“华为开发者大赛”板块说明情况，申请后台撤回或删除。我不重复那套，只补一个点：联系时一次把信息给全，别分几轮问答，越临近截止时间越耗不起。建议直接按下面这个清单发过去：- 大赛名称和赛道- 报名手机号或团队名- 误提交的作品名和提交时间- 正确作品的作品名和提交时间（如果已经提交了）- 希望的处理：请后台撤回误提交的那一份，并确认评审以哪一份为准- 附上第 2 节那两张提交记录截图另外多问官方一句再动手：如果你正确作品还没提交，先问清楚重新提交是会覆盖上一份，还是会变成第二条记录。这一点我没有大赛的实测，不同系统做法不一样，问清楚再提交，比交完再发现多了一条记录强。还有一个时间点要盯住：以你所报赛道的官方提交截止时间为准，尽量在截止和评审开始前联系上。截止之后再想改，余地就很小了。## 不确定的地方，直接说清楚- 我没走过大赛的提交流程，上面第 1 节是展览馆提交的真实经过，只用来说明“提交页可能本来就没有自助删除”，不是大赛的官方规则，大赛以官网说明和官方回复为准。- “评审只取最终提交那份”这个说法来自你另一个帖子里其他人的回复，我没有核对过大赛的评审规则，不要把它当成定论，联系官方时请对方确认。- 如果官方回复说误交的记录无法撤回，那就按官方给的口径办，不要自己反复提交新版本去“覆盖”，多交几份反而可能让评审拿不准以哪份为准。

前面几楼把适用场景列得很全了，2、4、5、6 楼基本是同一份清单（OBS 缩略图、APIG 胶水层、定时任务、AI 流水线一环），1、3、7 楼是同一份通用排障模板。我不重复列场景，只补三样前面没讲透的：第一，一张四问判定表，四个问题有一个不满足就要再看；第二，我自己真实踩过的一例——FunctionGraph 当 API 后端接 RDS，并发一扩就把连接数打爆；第三，帖子里没人讲的 VPC 这一层。## 1. 先过四问判定表5 楼给了四条判断标准，我把它收成一张表，每条只答是或不是：| 问题 | 答“是”说明什么 ||---|---|| 触发是否离散（事件来了才跑，平时没流量） | 是，适合；不是，常驻服务更合适 || 单次执行能不能在超时内完成 | 能，适合；不能，要拆任务或换形态 || 是否需要进程内常驻状态（内存缓存、本地磁盘、长连接） | 不需要，适合；需要，不适合 || 流量波动是否大、突发是否多 | 是，适合；一直平稳高并发，算算账再定 |四个都满足，FunctionGraph 通常合适；有一个不满足，就要再看。超时那条要先看数字：8 楼说默认 3 秒、可配到 900 秒，单次执行超过上限的长任务必须拆，不要硬塞。这张表的好处是：不用先想“它能干什么”，先排除“它干不了什么”。2、4、5、6、8 楼列的不适合清单都是一样的——长任务超超时上限、常驻内存缓存或本地磁盘状态、WebSocket 长连接、延迟极其敏感且持续高并发的核心链路、毫秒级稳定低延迟在线推理、超大内存或长时间运行、大批量离线 ETL，替代方案是 ECS、CCE 或容器、专门的批处理服务。## 2. 我真实踩过的一例：并发扩容把 RDS 连接打爆这是我自己在论坛回答过、还被采纳的一例，帖子是“FunctionGraph 并发扩容后 RDS 连接数反而被打爆，怎么解”。场景是 FunctionGraph 做后端，并发一扩，RDS 连接数先被打满，函数反而报错。机制是这样的，5、6 楼也点过，但我要把算账方式说具体：函数并发扩容时，每个实例都可能新建数据库连接，连接数大约等于并发实例数乘以每个实例的连接池大小。流量一突发，实例数上去，连接数跟着上去，RDS 的 max_connections 先到顶，函数拿不到连接就报错。这时候看函数日志只会看到连接失败，看 RDS 才会看到连接数打满，两边要一起看。处理方向按顺序是：1. 先限制函数并发上限，把扩容速度压住，别让它无限扩。2. 把每个实例的连接池调小，连接数按“并发上限 × 单实例池大小”重新算一遍，对照 RDS 的 max_connections。3. 突发流量改异步削峰：函数只负责接请求、写消息队列，后面再慢慢消费，别让函数直连 RDS 去扛尖峰。4. 再看是不是该把这条链路换形态：持续高并发的核心链路，本来就不适合用函数直连 RDS，ECS 或 CCE 加连接池更可控。这一点也是 8 楼那句“先看触发方式和执行时长”的另一面：触发离散、短时、突发流量，FunctionGraph 合适；但只要后端是 RDS，就要先把连接数这笔账算好再上量，不要等打爆了再回头。## 3. 帖子里没人讲的空白：VPC 这一层8 楼按触发源分得很系统，但有一层帖子里没人专门讲：VPC。1、3、7 楼模板里只泛泛提了“网络/安全组”排查，不构成 VPC 场景说明。我要先说清楚我的边界：下面这部分是我根据上面那例 RDS 问题的推断，不是官方文档原文，具体配置项以官方文档为准。- 函数要访问 VPC 里的 RDS，就要走 VPC 这一层，函数和数据库要在同一个 VPC、安全组要放行，函数这一侧也要配好 VPC 访问。只看触发器和超时，是看不出这层问题的。- 函数进 VPC 之后，冷启动会更重，初始化（建连接、加载模型）要放在函数初始化阶段，别放在每次请求里，这一点 6 楼也提过。- 如果函数还要访问公网（比如调第三方接口），进 VPC 之后要另外看出口怎么走，不要默认进 VPC 就什么都能通。所以选型时除了四问表，还要多问一句：后端在不在 VPC 里？在的话，先把 VPC、安全组、连接数这三项一起核对，再决定函数放不放这里。## 4. 落地顺序：先试点，再推广2、4、5、6 楼都建议先试点，我收拢成顺序：1. 先从一个非核心的定时或事件任务试点，比如每天凌晨跑报表、清理过期文件。2. 跑通监控、日志、超时和重试，再看冷启动和并发。3. 上 RDS 之前，先按第 2 节把连接数算好，限制并发上限，配好连接池。4. 跑稳了再推广到更多场景，不要一上来就把核心链路迁过来。配置和密钥放环境变量或凭据管理里，不要写死在代码里；一个函数只做一件事，方便单独排障。超时后平台可能重试，非幂等的操作（写库、发通知）要先做幂等，比如用对象名加时间戳做唯一键，重复触发时直接跳过，这一点 6 楼提过。## 不确定的地方，直接说清楚- 超时默认 3 秒、可配到 900 秒这个数值是 8 楼给的，我没有去官方文档逐字核对过，以官方文档为准。- VPC 这一节是根据我上面那例 RDS 问题的推断，不是官方文档原文，具体配置项以官方文档为准。- 你这篇帖子正文没有给具体业务、事件源、时延、并发、时长要求，所以上面这张表和这例 RDS 问题只能当选型方法，具体到你的业务，还要按四问表逐项对一遍。

前面几楼把版本区别和核时算法已经讲得很全了，我不重复算一遍，只补三个前面没完全说透的地方：第一，“关机后不计费”这句话到底在哪个层面成立；第二，8000 核时那个 166 天为什么算出来容易偏乐观；第三，从任务入口误点持久化版之后，具体怎么止损。先说一个前提，免得我这楼被当成官方口径：我自己日常用的是 DevSpace 免费体验版（每天一次 AI Shell 对话，容器按次给时长），持久化版我没开过机。下面凡是我没实测过的，都直接标出来，不替官方下结论。## 1. “关机后不计费”要拆成两层1 楼说“关机后不计费”，这句话只对了一半。准确的说法是：- 运行核时在关机后不再增长。版本选择页写的是“按实际使用时长扣减额度”，扣的是开机运行的时间，关机后这一层停了。2、3、6、7 楼都是这个意思，这一点几楼没有分歧。- 但“运行核时停了”不等于“总成本为零”。关机后磁盘和快照还在保留，这部分是否另计、是否有配额上限，选择页上没有统一说明，2、3、4 楼都指出了这个口子。5 楼正面断言系统盘、数据盘仍按存储计费，但这楼没有给来源，我不能直接把它当成定论。所以能负责的写法是：先到你账号里的“核时控制器”看额度明细，那个才是最终依据。只看版本选择页上的两行字，是推不出“关机后一分钱不花”的。还有一个最容易踩的坑，2、6、7 楼都提过，我再强调一次：关浏览器、断开终端不等于关机。实例还在运行，核时照扣。用完一定要回到 DevSpace 页面，确认实例状态是已停止，而不是只关掉网页。## 2. 8000 核时算 166 天，为什么偏乐观核时口径几楼是一致的：核时 = 分配核数 × 运行小时数，空闲也按分配规格扣，不是按实际 CPU 使用率算。按这个口径：- 2 核常驻一天约 48 核时，8000 核时理论上约 166 天- 4 核常驻一天约 96 核时，理论上约 83 天（3 楼算的 80 天左右是同一个数，取整不同）- 8 核常驻一天约 192 核时，理论上约 41 天- 2 核跑一个月（720 小时）约 1440 核时理论值偏乐观，4 楼已经点过三个原因：启动和关闭本身也按秒计费，频繁开关机的损耗比想象中大；按分配核数扣，空闲挂机等于满额消耗；额度耗尽后实例会被停止或限制，不会自动续。按 4 核常驻算，留出调试、重启、演示的额外开销，实际能稳定跑 2 个月左右比较合理，不要拿 83 天当成承诺。另外 5 楼区分了 Stop 和 Hibernate，说普通关机停核时、休眠可能继续按较低费率计费。这个区分全帖只有 5 楼提过，同样没有给来源，我没法验证。写在这里是提醒你注意这个可能性，不是结论：进持久化版后，先在页面上确认你点的到底是哪个停止动作，再去核时明细里核对。## 3. 先实测 2 小时，再决定常驻放不放这里不要靠估算下单，4 楼给的流程最完整，我把它收拢成四步：1. 进持久化版之前，先记下“核时控制器”里的当前余额和记录时间，初始赠送应为 8000 核时。2. 开机挂 1 小时，什么都不做，看扣了多少核时，算出每小时开机成本。3. 关机，再等 1 小时，看余额是否继续下降，确认关机后运行核时是不是真的停了。4. 对比两次差值，再乘以你想常驻的天数，才是你的真实成本。只跑 1 天也行：开机跑 1 天后对照额度明细，看实际扣了多少，再乘以天数。跑满 1 天再决定，比先算 166 天再搬家省事得多。## 4. 常驻要过三关，不只是核时- 进程保活：终端断开后进程会退出，必须用 systemd 或 tmux/screen 托管，开机自启要单独配。- 公网入口：DevSpace 是开发环境，默认没有固定公网 IP。DevBridge 隧道可以临时暴露端口，但有效期 72 小时，到期要重建，域名也会变，不适合给家里设备长期调用。- 空闲回收：4 楼提到开发环境普遍有“空闲多久自动停止”的机制，长时间无操作可能被停掉、服务就断了。这一点其他楼没提，我在 DevSpace 的页面上也没看到统一的官方说法，先把它当成待核对项，不要默认没有。结论上我和 2、4、5、6、7 楼一致：DevSpace 定位是开发调试，不是生产托管。只是自己偶尔用、能接受每天手动开，持久化版够用，用完就关；要给家里设备提供 7×24 接口、要固定域名和证书长期有效，就不要长期挂在这里，用一台按需或包年的 ECS 或 Flexus，公网 IP 固定、没有额度概念，DevSpace 只用来开发和调试，代码推 Git 后再部署上去。想省钱又想固定入口，ECS 最低配加按流量计费带宽，比长期消耗核时额度更可控。## 5. 从任务入口误点持久化版，怎么止损6、7 楼正面回应过这一点，我收拢成操作顺序：1. 从“每周体验 AI DevSpace”这类任务入口进来时，先看版本选择弹窗，确认是体验版再进，不要顺手一点就切过去。2. 如果已经切到持久化版，进页面后立即点保存/停止，不要先跑起来再说。3. 停下后马上去核时余额页面核对一次变化，看有没有空跑扣掉的额度。4. 以后进持久化版之前，先记初始余额，出来后再核对一次，养成这个习惯，误点的损失就是一次性的。## 不确定的地方，直接说清楚- 关机后保留的磁盘/快照是否另计费、是否有配额上限，页面没有统一说明，我没实测过，以你账号里“核时控制器”的额度明细为准。- 5 楼说的 Hibernate 可能继续按较低费率计费，全帖唯一，没有来源，我没法验证，不要当成结论。- 空闲多久自动停止，我在页面上没看到统一的官方说法，先当成待核对项。- 帖子里没有任何华为云官方账号的回答，上面所有结论都是社区用户经验加版本选择页的说明，最终以官方口径和你账号里的额度明细为准。

前面几楼把版本区别和核时算法已经讲得很全了，我不重复算一遍，只补三个前面没完全说透的地方：第一，“关机后不计费”这句话到底在哪个层面成立；第二，8000 核时那个 166 天为什么算出来容易偏乐观；第三，从任务入口误点持久化版之后，具体怎么止损。先说一个前提，免得我这楼被当成官方口径：我自己日常用的是 DevSpace 免费体验版（每天一次 AI Shell 对话，容器按次给时长），持久化版我没开过机。下面凡是我没实测过的，都直接标出来，不替官方下结论。## 1. “关机后不计费”要拆成两层1 楼说“关机后不计费”，这句话只对了一半。准确的说法是：- 运行核时在关机后不再增长。版本选择页写的是“按实际使用时长扣减额度”，扣的是开机运行的时间，关机后这一层停了。2、3、6、7 楼都是这个意思，这一点几楼没有分歧。- 但“运行核时停了”不等于“总成本为零”。关机后磁盘和快照还在保留，这部分是否另计、是否有配额上限，选择页上没有统一说明，2、3、4 楼都指出了这个口子。5 楼正面断言系统盘、数据盘仍按存储计费，但这楼没有给来源，我不能直接把它当成定论。所以能负责的写法是：先到你账号里的“核时控制器”看额度明细，那个才是最终依据。只看版本选择页上的两行字，是推不出“关机后一分钱不花”的。还有一个最容易踩的坑，2、6、7 楼都提过，我再强调一次：关浏览器、断开终端不等于关机。实例还在运行，核时照扣。用完一定要回到 DevSpace 页面，确认实例状态是已停止，而不是只关掉网页。## 2. 8000 核时算 166 天，为什么偏乐观核时口径几楼是一致的：核时 = 分配核数 × 运行小时数，空闲也按分配规格扣，不是按实际 CPU 使用率算。按这个口径：- 2 核常驻一天约 48 核时，8000 核时理论上约 166 天- 4 核常驻一天约 96 核时，理论上约 83 天（3 楼算的 80 天左右是同一个数，取整不同）- 8 核常驻一天约 192 核时，理论上约 41 天- 2 核跑一个月（720 小时）约 1440 核时理论值偏乐观，4 楼已经点过三个原因：启动和关闭本身也按秒计费，频繁开关机的损耗比想象中大；按分配核数扣，空闲挂机等于满额消耗；额度耗尽后实例会被停止或限制，不会自动续。按 4 核常驻算，留出调试、重启、演示的额外开销，实际能稳定跑 2 个月左右比较合理，不要拿 83 天当成承诺。另外 5 楼区分了 Stop 和 Hibernate，说普通关机停核时、休眠可能继续按较低费率计费。这个区分全帖只有 5 楼提过，同样没有给来源，我没法验证。写在这里是提醒你注意这个可能性，不是结论：进持久化版后，先在页面上确认你点的到底是哪个停止动作，再去核时明细里核对。## 3. 先实测 2 小时，再决定常驻放不放这里不要靠估算下单，4 楼给的流程最完整，我把它收拢成四步：1. 进持久化版之前，先记下“核时控制器”里的当前余额和记录时间，初始赠送应为 8000 核时。2. 开机挂 1 小时，什么都不做，看扣了多少核时，算出每小时开机成本。3. 关机，再等 1 小时，看余额是否继续下降，确认关机后运行核时是不是真的停了。4. 对比两次差值，再乘以你想常驻的天数，才是你的真实成本。只跑 1 天也行：开机跑 1 天后对照额度明细，看实际扣了多少，再乘以天数。跑满 1 天再决定，比先算 166 天再搬家省事得多。## 4. 常驻要过三关，不只是核时- 进程保活：终端断开后进程会退出，必须用 systemd 或 tmux/screen 托管，开机自启要单独配。- 公网入口：DevSpace 是开发环境，默认没有固定公网 IP。DevBridge 隧道可以临时暴露端口，但有效期 72 小时，到期要重建，域名也会变，不适合给家里设备长期调用。- 空闲回收：4 楼提到开发环境普遍有“空闲多久自动停止”的机制，长时间无操作可能被停掉、服务就断了。这一点其他楼没提，我在 DevSpace 的页面上也没看到统一的官方说法，先把它当成待核对项，不要默认没有。结论上我和 2、4、5、6、7 楼一致：DevSpace 定位是开发调试，不是生产托管。只是自己偶尔用、能接受每天手动开，持久化版够用，用完就关；要给家里设备提供 7×24 接口、要固定域名和证书长期有效，就不要长期挂在这里，用一台按需或包年的 ECS 或 Flexus，公网 IP 固定、没有额度概念，DevSpace 只用来开发和调试，代码推 Git 后再部署上去。想省钱又想固定入口，ECS 最低配加按流量计费带宽，比长期消耗核时额度更可控。## 5. 从任务入口误点持久化版，怎么止损6、7 楼正面回应过这一点，我收拢成操作顺序：1. 从“每周体验 AI DevSpace”这类任务入口进来时，先看版本选择弹窗，确认是体验版再进，不要顺手一点就切过去。2. 如果已经切到持久化版，进页面后立即点保存/停止，不要先跑起来再说。3. 停下后马上去核时余额页面核对一次变化，看有没有空跑扣掉的额度。4. 以后进持久化版之前，先记初始余额，出来后再核对一次，养成这个习惯，误点的损失就是一次性的。## 不确定的地方，直接说清楚- 关机后保留的磁盘/快照是否另计费、是否有配额上限，页面没有统一说明，我没实测过，以你账号里“核时控制器”的额度明细为准。- 5 楼说的 Hibernate 可能继续按较低费率计费，全帖唯一，没有来源，我没法验证，不要当成结论。- 空闲多久自动停止，我在页面上没看到统一的官方说法，先当成待核对项。- 帖子里没有任何华为云官方账号的回答，上面所有结论都是社区用户经验加版本选择页的说明，最终以官方口径和你账号里的额度明细为准。

先把三个报错拆开看，它们不是同一个问题，混在一起修会越修越乱：- 401 是过期凭证的正常结果，不是脚本坏了。你本地用过期 STS 凭证调接口，返回 `401 GALLERY.AUTH.UNAUTHORIZED` 是预期的，先把 401 排除，再谈 400。- Step 8 的 `Publish FAILED! 缺少必填参数` 是 Step 5 拿不到 trainingCampId 的下游结果，不是独立 bug。Step 5 没拿到 ID，Step 8 自然缺参数，单独去修 Step 8 没有意义。- 真正要定位的是 Step 5 的 400：它到底是入参错了，还是这道赛题本来就不在“训练营活动列表”这个接口的返回范围里。## 1. 先排除 401，再重跑一次并留完整报文前面几位已经提过这个顺序，我这里只强调一个执行细节：重跑前先换未过期的 STS 凭证，用新鲜凭证完整重跑一次官方脚本，不要用过期凭证反复测 401，那样每次都会 401，测不出 400 的真相。重跑时留住 Step 5 的完整请求和返回体，至少包括：- 完整 URL、请求方法、请求头和 payload（把敏感凭证打码）- 完整响应体，特别是 error_code、message、缺失参数名那几个字段- requestId 和报错时间你原帖里只给了 `Camps: #status=400 Bad Request` 这一行，没有完整返回体。没有完整返回体，别人没法判断是入参里的活动类型、赛道、年份、区域哪一项对不上，还是接口本身就不返回这道赛题的活动。这个信息缺了，后面任何“手动提交”的建议都是猜。## 2. 核对三处账号是不是同一个人在重跑之前，先核对这三处是不是同一个账号：- 报名 ICT 大赛云赛道的账号- 执行发布脚本时登录的华为云账号- GitCode 仓库 `gcw_l5mUh6bx/task-kanban` 的归属账号如果这三处不一致，活动列表里看不到这道赛题、或者提交后归属对不上，都是可能的。仓库还要确认是公开可读、分支正确，私仓或分支错了，服务端拉不到代码，后面也会卡住。这一点前面也有人提过，我再补一句：不要拿列表里高校训练营的 ID 去凑数。列表里只有高校训练营，恰恰说明这个列表不一定就是你要的赛题活动列表，凑一个学校 ID 提交上去，归属和赛题都对不上，后面官方核查时反而更难解释。## 3. 先回官方赛题指引，确认这道题到底要哪种 ID这是前面回答里已经有人点出来、但楼主还没回应的关键问题：这道赛题要的到底是训练营 ID、大赛活动 ID，还是作品 ID？我最近刚走通一次展览馆 Skill 发布，过程里有一个对照经验可以参考，但要先说清楚它的边界：我那次是在 AI 对话里选活动，AI 列出的是“可投稿”活动列表，里面大多数也是绑定学校的，排掉之后才选到一个通用活动，提交后拿到了作品 ID 和详情链接。那个流程里没有用到 trainingCampId，走的是 AI Skill 的活动选择，不是脚本 Step 5 的训练营列表。所以这里要区分两条路：- 脚本 Step 5 的训练营列表：如果赛题指引明确要求 trainingCampId，那就必须在这个接口里拿到它，拿不到就要按第 1 步的完整返回体去走官方渠道核查，不要绕。- 展览馆正常发布入口：如果赛题指引允许用展览馆作品链接作为提交证据，那可以先按正常 Skill 流程发布到一个“可投稿”活动，拿到作品 ID 和详情链接，再把这份证据连同完整日志一起交给官方核查。我不能替你断定这道赛题属于哪一条，因为赛题指引原文帖子里没有贴出来。这一点必须以官方赛题指引为准，论坛回答给不出这个判定。## 4. 关于你问的两个问题，直接回答你问的第一个问题：能不能手动把 GitCode 仓库提交到展览馆？技术上，展览馆本身有正常发布入口，公开仓是可以按 Skill 流程提交的，提交后会有作品 ID 和详情链接。但这一步不等于完成 ICT 赛题，也不等于拿到 200 积分。赛题完成与否要看赛题指引里认不认这个提交方式，以及活动归属对不对，论坛回答无法替官方判定。你问的第二个问题：能不能直接根据提交 ID 2062 后台判定完成？不能在论坛里直接判定。200 积分的后台判定只能官方根据提交记录和活动归属确认，前面几位也都说了这一点。能做的，是把证据包整理齐了走官方渠道：Step 1–8 完整日志、Step 5 完整请求与返回体、requestId、凭证状态说明（是不是过期 STS）、三处账号的对应关系、仓库链接、提交 ID 2062、赛题名称、报错时间。证据越齐，官方核查越快；只给一个提交 ID，官方没法核对活动归属。## 5. 不要做的四件事- 不要用高校训练营的 ID 凑数提交。- 不要用过期凭证反复测 401。- 不要换多个 ID 反复发布，重复提交不会让判定变快，反而会让归属更乱。- 不要在没有拿到 Step 5 完整返回体之前就改脚本参数，那样改完也不知道改对了没有。## 不确定的地方，直接说清楚- 我不知道这道赛题到底要求 trainingCampId 还是别的 ID，帖子里没有赛题指引原文，这个问题必须以官方指引为准。- 我不知道 Step 5 的 400 完整错误字段是什么，帖子里没有贴出来，没有这个信息，无法判断是入参错还是接口范围问题。- 我不能保证手动提交到展览馆就能拿到这道赛题的 200 积分，赛题判定只能官方做。- 版主 9 楼提到的活动已结束、赛事资源不足这类原因，我也没有办法从帖子信息里验证，只能作为走官方渠道时一并核查的可能性，不能当成结论。如果你能把第 1 步的 Step 5 完整返回体、脚本来源和版本、赛题指引里关于 ID 的那一段原文贴出来，下一步就清楚了：是入参错就改入参，是接口范围问题就走官方核查，是赛题认作品链接就按正常发布入口提交证据。

你已经做了一个关键验证：停用 CodeBuddy 后 CodeArts 恢复正常。但这一步本身还不能直接得出“CodeBuddy 改了配置”的结论，也还没回答你真正的问题：两个插件能不能同时用。先把两件事分开查：第一，`ide.browser.jcef.out-of-process.enabled=false` 在你这台机器上到底生没生效；第二，冲突是不是每次开 CodeBuddy 都会复现。只有第二步复现了，才值得去谈共存方案，不然很容易把一次性的缓存/进程残留当成插件冲突。## 1. 先确认参数真的生效了，再谈冲突前面几位已经提过一键修改和删缓存，我这里只补一个验证点，因为“改了没用”经常是改错文件或进程没退干净：1. 用 `Help > Edit Custom VM Options` 打开文件，确认里面有这一行，并且确认这是当前生效的文件（不要直接去改安装目录下的 vmoptions，那个不一定生效）：```-Dide.browser.jcef.out-of-process.enabled=false```2. 完全退出 IDEA 后再启动，启动前到任务管理器确认没有残留的 `idea64.exe` / `fsnotifier`，只关窗口不算退干净。3. 启动后到 `idea.log` 里搜 `JCEF`，确认 out-of-process 这一项确实是 false，而不是只在设置页看到“一键修改已生效”。如果这一步确认参数已生效、面板还是加载中，那问题就不在“参数没改上”，再往下做对照。## 2. 做一组对照，确认冲突可复现不要只做一次“停用就好”，按下面顺序各做一次完整退出再启动，记下每次 CodeArts 面板的结果：- 只开 CodeArts，关 CodeBuddy：面板是否正常- 只开 CodeBuddy，关 CodeArts：IDEA 自带的 JCEF 页面（比如 Settings > Plugins、.md 预览）是否正常- 两个都开：CodeArts 面板是否又变回加载中如果只有“两个都开”才出问题，冲突才算复现；如果单开 CodeArts 也时好时坏，那更可能是 JCEF 子进程/缓存/代理这类环境问题，不是两个插件互斥。## 3. 查 CodeBuddy 那边有没有单独的 webview 开关你日志里那两行 `com.tencent.code.intel.apibridge.extension.mainthread.webv` 目前都是截断的，单凭这个还不能定性。建议：1. 在 CodeBuddy 的设置里找找有没有单独控制 webview、内置浏览器或 AI 面板的选项，如果有，先只关它的 webview，保留它的代码能力，再看 CodeArts 是否恢复。2. 如果没有这种单独开关，就不要硬改它的内部配置，改完升级一覆盖又回去了。这一点我没有在你这个版本组合上复现过，所以只能说“去设置里找找看”，不能保证 CodeBuddy 一定有这个开关。## 4. 贴日志时贴完整片段，不要只贴截断行你原帖里的两行日志都被截断了，别人没法从截断行判断是谁在占用配置。反馈或继续排查时，建议贴出同一时间段内完整的、去掉敏感路径和账号信息的片段，至少包括：- 启用 CodeBuddy 前后，`idea.log` 里 `JCEF` 和 `com.tencent.code.intel.apibridge.extension` 的完整行- 你的 CodeBuddy 精确版本号（你只给了 CodeArts 26.10.2 和 IDEA 2025.1.2，CodeBuddy 的版本还没给）- 重新启用 CodeBuddy 后，问题是不是立刻复现，还是要重启几次才出现## 如果暂时无法共存，先别被面板卡住进度5 楼已经提过一个临时办法，我认同这个兜底思路：用插件设置里的“在外部浏览器打开”，或直接用浏览器完成当天的工作，等冲突原因查清了再回面板。这个办法是绕过，不是修好，不建议把它当成最终解法。## 不确定的地方，直接说清楚- 我不能保证两个插件一定能同时用，也不知道官方是否支持这种共存组合，这一点目前帖子里也没有定论。- 4 楼提到的 `-Dide.browser.jcef.sandbox.enable=false` 如果要用，只建议当作一次性的验证手段，确认是不是沙箱被拦，不建议长期关着沙箱用。- 回退旧版本（版主 3 楼的建议）可以当作临时恢复工作的办法，但它不解释冲突原因，升级后问题可能还会回来。如果你能按第 2 步把“单开 / 双开”的对照结果和第 4 步的完整日志贴出来，这个问题就从“停用一个能用”推进到“到底是谁在什么条件下冲突”，下一步才好判断是等插件方修、还是调设置就能共存。

先别重复重置密码：本机已经能登录，说明 root 密码本身是对的，问题在“业务应用那条连接”上。先看报错原文分两类，再按下面顺序查，查到哪一步通了就停：- `Access denied for user 'xxx'@'yyy'`：到了 MySQL、被账号或 Host 挡下来，重点查第 1、2 步；- `Connection refused` / 连接超时：根本没到 MySQL，重点查第 3、4 步。## 第 1 步：应用配置里的密码、账号、地址有没有同步这是最快的一步，先查它：1. 打开业务应用的数据库配置（配置文件或环境变量），核对三项：用户名、密码、地址/端口。重置后只改了 MySQL 侧、没改应用侧，是最常见的“本机通、业务不通”。2. 改完配置要重启应用或重载配置，否则应用可能还拿着旧密码的缓存连接在重试。3. 顺带核对应用连的是哪个地址：是 `127.0.0.1`、内网 IP，还是公网 IP？本机登录用 `localhost` 通，不代表用内网 IP 或公网 IP 也通，地址不同走的授权和网络路径也不同。## 第 2 步：MySQL 用户的 Host 授权本机登录通，应用连不上，第二常见的原因就是用户只授权给了 `localhost`。在 MySQL 服务器上登录后查：```sqlSELECT User, Host, plugin FROM mysql.user;SHOW GRANTS FOR '你的业务账号'@'应用的Host';```- 如果业务账号只有 `'root'@'localhost'` 或 `'业务账号'@'localhost'`，而应用是从另一台机器、另一个 IP 或容器里连过来的，就会被挡下来，报错就是 `Access denied`。- 处理办法是给业务账号加上应用实际来源的 Host，例如应用 IP，或者在确认安全的前提下用 `%`，然后刷新权限：```sqlCREATE USER '业务账号'@'应用IP' IDENTIFIED BY '新密码';GRANT ALL PRIVILEGES ON 业务库.* TO '业务账号'@'应用IP';FLUSH PRIVILEGES;```- 顺带说两点：一是业务应用尽量不要直接用 root 连，单独建一个业务账号，权限只给业务库；二是不要为了图省事把 root 改成 `'root'@'%'` 配弱密码再放通公网，那是把数据库暴露出去了。`plugin` 那一列也要看一眼：MySQL 8 默认是 `caching_sha2_password`，老客户端或老驱动可能不支持，会表现为连不上或认证失败；如果应用驱动确实老，解决办法是升级驱动，或者把业务账号改成 `mysql_native_password`，具体以你的 MySQL 版本和驱动版本为准，这里不直接替你选。## 第 3 步：MySQL 到底在监听哪个地址在 MySQL 服务器上查监听和 bind-address：```bashss -tlnp | grep 3306``````sqlSELECT @@bind_address, @@port;```- 如果 `bind_address` 是 `127.0.0.1`，MySQL 只接受本机连接，应用从别的机器连过来根本到不了 MySQL，跟密码对不对没关系。- 要改的话，改 MySQL 配置文件里的 `bind-address`（改成 `0.0.0.0` 或应用能访问的内网 IP），改完重启 MySQL 服务再生效。改成 `0.0.0.0` 的同时，第 4 步的安全组必须只放应用 IP，不能放 `0.0.0.0/0`。- 不确定的地方：配置文件路径和服务名不同发行版、不同安装方式不一样，可能是 `/etc/my.cnf`、`/etc/mysql/my.cnf` 或 `/etc/mysql/mysql.conf.d/mysqld.cnf`，服务名可能是 `mysqld` 或 `mysql`，以你机器上的实际文件和服务名为准。## 第 4 步：安全组和系统防火墙放没放 3306如果前面三步都没问题，再查网络层，分两层：1. 华为云 ECS 安全组：入方向有没有放行 3306，来源是不是应用服务器的 IP（或应用所在安全组），不是放通所有地址。2. 服务器本机防火墙：`firewalld`、`iptables` 或 `ufw` 有没有放行 3306，例如：```bashfirewall-cmd --list-portsss -tlnp | grep 3306```然后在应用服务器上直接测连通性，不要只在 MySQL 本机测：```bashmysql -h MySQL内网IP -P 3306 -u 业务账号 -p```- 本机 `mysql -u root -p` 通、应用服务器上这条命令不通，就是网络或监听的问题；- 应用服务器上这条命令通、业务应用还不通，就回到第 1 步查应用配置和驱动。## 按这个顺序查，最省时间1. 先看报错原文：`Access denied` 走账号/Host，`Connection refused`/超时走监听/网络；2. 应用配置密码、账号、地址有没有同步，改完有没有重启应用；3. `mysql.user` 里业务账号的 Host 是不是应用实际来源；4. `bind_address` 是不是只绑了 `127.0.0.1`；5. 安全组和本机防火墙有没有只放应用 IP 放行 3306。最后补一句：你帖子里没写 MySQL 版本、应用是不是和 MySQL 在同一台 ECS 上、报错原文到底是哪一句，如果按上面顺序查到某一步卡住了，把那一步的命令输出（账号和密码打码）和报错原文贴出来，能更快定位到是账号、监听还是网络那一层。

## 先归因：是连接堆起来了，还是慢 SQL 占着不先分清这两类，后面限流还是加代理都会调错地方。直接看三个数，不用猜：```sqlSHOW STATUS LIKE 'Threads_connected';SHOW STATUS LIKE 'Threads_running';SHOW STATUS LIKE 'Max_used_connections';SHOW FULL PROCESSLIST;```- `Threads_connected` 是当前总连接数，`Threads_running` 是正在执行的线程数。- 如果 `Threads_connected` 暴涨，但 `Threads_running` 不高，`PROCESSLIST` 里大量是 `Sleep` 状态、Time 很长，那就是连接堆起来了、没及时释放，不是慢 SQL。- 如果 `Threads_running` 也跟着涨，`PROCESSLIST` 里很多正在执行、Time 很长、Info 里是同一类慢查询，那就是慢 SQL 占着连接，限流只能缓解，根因在 SQL 和索引。再往下归因到函数，要按 Host 和 User 分组看 `PROCESSLIST`：- Host：函数实例都在 VPC 的某个网段里，看 Host 是不是集中在函数网段，而不是应用服务器网段。- User：函数如果用独立的数据库账号连 RDS，按 User 过滤，一眼就能看出函数占了多少。- 时间对齐：把 FunctionGraph 实例数的时间曲线和 RDS 的 `Threads_connected` 曲线放在同一时间轴上对一下，峰值时间对得上，才是函数打爆的证据；只看总量对不上时间，可能是其他服务也在涨。## 函数侧怎么限：限的是实例数，不是请求数函数实例生命周期短，应用侧的连接池活不过实例本身，这是关键。每个函数实例就是一个独立进程，它的池子跟着实例生、跟着实例死，所以全局池化在这里不成立，真正起作用的是两层：1. 单实例并发数：对连库重的函数，单实例并发设成 1，一个实例同一时刻最多只处理一个请求、最多只占一个连接，账才算得清楚。单实例并发设高了，一个实例就能把多个连接占满，实例数还没涨，连接先爆了。2. 函数实例数上限：用可用连接数反推，不是按业务量正推。公式是：```实例上限 = (max_connections × 0.8 - 其他服务预留连接数) ÷ 单实例池上限```0.8 是留给管理、监控和其他服务的余量，其他服务预留要按实测填，不要填 0。举个例子只是算式演示，不是你的实际数：max_connections 1000，可用按 800 算，其他服务留 50，单实例池上限 2，那实例上限就是 (800 - 50) ÷ 2 = 375。单实例池上限如果设成 5，实例上限就只剩 150，池子设得越大，能放的实例越少。控制台里的字段名不同版本可能有差异，在函数配置的高级设置里找实例并发、最大实例数、预留实例这几项，找不到就按这个公式先算好数，再去对应字段填。## 代理怎么接：函数连代理端点，不是直接连 RDS前面几楼都提了 RDS 代理，这里补接法和坑：- 接法：函数里的数据库地址改成代理端点，函数实例连代理，代理再用一小池连接连 RDS。这样函数实例数涨，RDS 连接数不跟着等比涨，因为代理层把连接复用了。- 坑一：代理不是万能，慢 SQL 还是慢，代理层只会把排队从 RDS 移到代理，查询本身不加速。- 坑二：代理本身有连接上限和费用，按量计费口径以当前控制台和计价页为准，这里不报具体价，先用小流量灰度验证，别一上来全量切。- 坑三：代理账号权限要和原来函数账号一致，切之前先在测试环境连代理跑一遍，别直接改生产环境变量。- 灰度做法：先让一小部分函数实例走代理端点，对比 `Threads_connected` 和平均查询耗时，确认连接数下来了、耗时没明显涨，再全量切。## 应用侧池化在短生命周期下还有没有意义：有，但只能小池有意义的前提是池子设小、生命周期设短：- 单实例池上限设 1 到 2，不要设 10、20，否则实例一扩容连接就翻倍。- 池连接的最大存活时间要小于数据库的 `wait_timeout`，比如 `wait_timeout` 是 8 小时，池连接存活设 30 分钟，避免拿到已断开的旧连接。- 连接必须请求级复用：请求开始时拿连接，请求结束时在 finally 里归还，不要在冷启动时拿一个连接一直 hold 到实例销毁。如果做不到上面三条，应用侧池化在函数场景下基本等于没做，优先用代理。## 预留实例的代价：连接数更稳，但要花钱预留实例让一部分实例常驻，冷启动少了，连接数曲线更稳，池子也不会频繁新建销毁。但代价是预留的实例即使空闲也要计费，预留数还要算进实例上限里，不能预留数等于上限，否则高峰时没法再扩。预留数设成平时基线量就行，高峰靠按需扩容补。## 应急和长期，分两步走应急（先止血，不改代码）：先限函数实例数上限，再查 `PROCESSLIST` 里 Sleep 时间长的连接是不是函数没归还，最后才考虑临时扩 max_connections，而且扩只是争取时间，不是解法。长期（改结构）：代理端点 + 单实例并发 1 + 实例上限公式 + 两个告警：`Threads_connected` 超过 max_connections 的 80% 就告警，`Aborted_connects` 突增也告警，前者是快满了，后者是已经有连接被拒了。不确定的地方要明说：控制台字段名和代理计价以你当前控制台和计价页为准，这里没报具体价；如果你的函数不是用独立数据库账号，或者函数和应用混用同一个账号，`PROCESSLIST` 按 User 分组就分不出来，要先按 Host 网段分，再按时间曲线对齐。

先给结论，再讲怎么区分：按任务指南说的 30 分钟算，5 小时 18 分钟已经超出指南，不算“正常范围内”。但超出不等于丢了，至少有两类情况要先分开，否则下次还会误判：第一，明细里那笔 +50 的实际到账时间，和你看到它的时间，不一定是同一时刻。我这边就遇到过页面没刷新的情况：实验结束当天下午，页面上的余额和任务卡几个小时都没变，明细抽屉还打不开，看起来像没到账；后来明细打开了，才看到 +50 其实在实验结束 12 分钟后就已经到了，任务卡后来也变已完成。所以你先别只看“21:25 才看到”，去明细里看那笔 +50 后面写的时间戳，那个才是后端到账时间。第二，KooLabs 页面显示的 100%，不等于成长中心任务已完成。KooLabs 100% 只是实验平台的进度指示，成长中心认的是任务卡和积分余额。我这边也遇到过 KooLabs 显示 100% 并点了结束实验，但任务卡当时还是去完成，积分后来才到。所以 16:07 那个时间，只能算实验结束时间，不能直接当积分应该到账的起点去掐表，起点还是要以明细时间戳为准。## 下次遇到，先按这个顺序查，别急着重做1. 结束实验后先等 30 分钟，这是任务指南给的窗口。2. 30 分钟后，刷新成长中心页面，再点开积分明细抽屉，抽屉打不开就多点几次、换个时间再点，看明细里有没有那笔 +50，以及它的时间戳是什么时候。只看页面上的余额数字和任务卡，容易被没刷新误导。3. 如果明细里确实没有，再看任务卡是不是还是去完成。两者都还是没有，再等到当天晚上。我这边有过当天晚上 21 点多才到的先例，所以当天晚上之前，先别断定丢了。4. 当天晚上还没到，也别马上重做同一个实验。每周实践一个实验的积分每周只算一次，重做不会再给第二个 +50，还会把当天仅有一次的免费名额用掉。## 如果超过 24 小时还没到，再提的时候带上这几样- 实验名：10 分钟入门装载国产操作系统的 ECS- KooLabs 显示 100% 的时间、点结束实验的时间- 积分明细的截图（证明没有那笔 +50，不是只截余额数字）- 任务卡还是去完成的截图带上这四样，别人才能区分是后端同步没跑完，还是页面没刷新，还是实验完成状态本身没同步过去。不确定的地方要明说：指南只写了 30 分钟内到账，没写超过多久算异常，我没看到官方对 5 小时延迟的正式口径，所以上面说的“等到当天晚上、超过 24 小时再提”是我这边根据到账先例给的等待建议，不是官方承诺；如果你的明细时间戳确实就是 21:25，那这次就是后端同步延迟了 5 个多小时，不是你操作的问题。