先别急着找删除键：多数赛事提交页本来就不开放参赛者自助删除，因为提交记录是评审和申诉的凭证。你现在最该做的是先核对、再联系官方、最后补救，顺序不要反。第一步，打开大赛官网的“我的作品/提交记录”，逐条核对两份记录的状态、作品名和提交时间：误交的那份到底是“草稿”还是“最终提交”，正确作品那份是否已经提交成功。把这个页面截图留存，后面联系官方时直接附图。第二步，通过大赛官网的在线客服或“华为开发者大赛”板块联系赛务，一次把信息给全：大赛名称和赛道、报名手机号或团队名、误提交作品名及提交时间、正确作品名及提交时间、希望的处理（请后台撤回误交的那份，并确认评审以哪一份为准）。第三步，动手前先问官方一句：如果正确作品还没提交，重新提交是覆盖上一份还是新增一条记录——不同系统做法不一样，问清楚再传，避免多出一条记录让评审拿不准。最后盯住你所报赛道的官方截止时间，尽量在截止和评审开始前处理完；截止后再想改，余地就很小了。如果官方回复说记录无法撤回，就按官方口径办，不要反复提交新版本去“覆盖”。

结合开发中实际调用 OBS 的经验，补充几个新手最容易踩、但文档里分散在不同章节的坑：1）Endpoint 和 Region 必须成对匹配。桶在哪个区域，访问域名就用哪个区域的 endpoint，代码里写死一个全局 endpoint 在跨区域调用时会报签名错误或直接连不上；建议把 endpoint 和 region 做成配置项，跟着桶走。2）AK/SK 不要硬编码进代码或前端。浏览器端、App 端绝对不要放永久 AK/SK，应该用临时安全凭证（STS）下发短期 token，前端直传时再配一个限制前缀和大小的桶策略或预签名 URL。3）签名报错先查时间。客户端系统时间偏差超过几分钟，预签名 URL 和 SDK 请求都会验签失败；服务器统一开 NTP 同步，遇到 SignatureDoesNotMatch 先对时间再查 AK/SK 是否带了空格、密钥是否被轮换。4）大文件一定要分段上传。单次 PUT 超过几百 MB 时弱网下极易中断，用 SDK 的分段上传（Multipart Upload）并设置合理的分段大小（常用 5-10MB），失败后用 ListParts 断点续传；上传完记得 CompleteMultipartUpload，否则分段一直占存储费。5）对象 Key 不是路径。OBS 里没有真正的目录，所谓文件夹只是 Key 前缀；删除“文件夹”要逐个删对象，列举时注意分页（Marker/NextMarker），一次 ListObjects 拿不全时要循环翻页。6）覆盖与版本控制。开启版本控制后删除对象只是打删除标记，存储费不会立刻降下来，需要配生命周期规则清理历史版本；不开启版本控制时同名覆盖会直接丢旧数据，重要桶建议开。7）CORS 和防盗链要提前配。Web 端直传/直读跨域报错，九成是桶的 CORS 规则没配（允许的 Origin、Methods、Headers 都要对上）；防盗链 Referer 白名单配错会导致正常图片裂图，上线前用无 Referer 和带 Referer 两种方式各测一次。8）费用三笔账分开看：存储容量、请求次数、流出流量。图片站流量大时流出费往往比存储费高得多，前面挂 CDN 回源可以大幅降流出成本，但回源请求次数和回源流量也要算进去。按这 8 条逐项自查，新手阶段 90% 的 OBS 问题都能在上线前排掉。

选规格的核心是先用真实负载数据反推，再在规格族和计费方式上做成本优化，而不是先拍一个大规格。具体可以按这几步走：1）先看监控：用云监控 CES 拉最近 7-14 天的 CPU 使用率、内存使用率、磁盘 IOPS/吞吐、网络带宽的 P95/峰值，而不是只看平均值。平均值会掩盖尖峰，按峰值买又会长期闲置。2）按瓶颈选规格族：CPU 瓶颈选计算型（C 系列），内存瓶颈选内存型（M 系列），数据库/IO 瓶颈优先看本地 SSD 型或通用型里磁盘性能高的规格，突发流量大的 Web 服务可用突发性能型但要注意 CPU 积分耗尽后的限流。3）留合理余量：生产环境一般按 P95 负载预留 30%-50% 余量即可，核心服务再高一些；同时确认 vCPU 与内存配比是否匹配应用（比如 Java 堆内存大的应用，1:2 配比往往比 1:4 更合适）。4）降成本：稳定负载用包年包月或预留实例，波动负载用按量付费加定时伸缩，测试/开发环境用低配或按量并设置自动关机；带宽大但流量不稳定的场景用按流量计费，带宽稳定的场景用按带宽计费通常更省。5）上线后复盘：跑一周后对比实际利用率，CPU/内存长期低于 30% 就考虑降配，长期高于 70% 就升配或做水平扩展。一句话：用监控数据定规格，用规格族定性能上限，用计费方式和伸缩策略定成本下限。

从数据管理角度补一个容易落地的点：复现不出去，很多时候不是配方错了，而是实验记录没法对齐。建议给每个样品一个唯一编号，把原料批号与纯度、配比、升温程序、气氛、保温与降温方式、表征原始文件（哈希校验）、分析脚本版本和操作人绑在同一条记录里，成功和失败批次都入库。计算侧同样留痕：结构文件、模型与数据版本、关键参数和输入输出文件一起归档。这样换批次复现时，能逐项比对“这次和上次到底改了什么”，而不是凭记忆猜是原料、温度还是操作差异；写阶段报告时也能直接按样品编号追溯证据，避免把预测结构、单次样品和多批次复现混成同一个结论。数据量不大时，一张结构化表格加原始文件归档就够用，关键是字段统一、每批必填、失败不删除。

补充一个交付层面的做法：生成图只当背景素材，文字不要让模型画。流程上先把留白区和主体位置定下来，导出一张“无字底图”，再在排版软件里单独叠标题、说明和二维码，这样改文案不用重新生成整张图，也避免 AI 把文字画错字。印刷或大屏使用时还要加两项检查：一是安全区和出血，重要文字离画布边缘留出足够距离，主体不要贴边，防止裁切；二是多尺寸适配，同一张海报常要出竖版、横版和手机长图三版，不要直接拉伸缩放，主体和留白要按每版重新分区，并保留分层源文件（背景、主体、文字分层）和导出记录，后续改尺寸或换文案时能快速复用。最后按最终用途实测：打印样张看色彩和清晰度，手机端预览看小字是否可读，确认无误再批量导出。

再补一个生产上更省事的流程：先做“分镜脚本＋参考图”，再生成视频。把每个镜头写成一行脚本，至少包含：镜头编号、时长、画面主体、机位动作、旁白或字幕要点、终止画面；同一组镜头共用同一张主体参考图和统一的 seed 或风格描述，主体外观才不容易在切镜后变化。生成时一次只跑一个镜头，先出首帧图人工确认构图和留白，首帧不对就不要往下生成视频，避免整批素材报废。验收也建议量化：每个镜头按“主体是否变形、文字是否可读、运镜方向是否正确、首尾帧是否衔接”四项打分，低于阈值的镜头单独重生成，而不是整段返工。最后剪辑时用硬切或短转场衔接推近镜头与环绕镜头，旁白按镜头编号对齐录制，字幕在剪辑软件里后期添加、不要让生成模型直接画字，这样文字错误率会低很多。

补充三个容易被忽略的细节。第一是纠错级别和版本要一起选：海报上如果中间要嵌 logo、背景有纹理，纠错级别低了容易识别失败；但级别越高码越密，远距离扫码反而更吃力，所以不要一味拉满。先按最终展示尺寸算：打印或大屏展示时，保证单个模块在实际输出里有足够像素，码太小就放大码、减少跳转链接长度，而不是事后锐化。第二是静态码和动态码的区别：海报印出去就改不了目标地址，活动结束或页面迁移后码还在但落点失效；如果业务需要改落地页，优先用自己可控的短链或跳转服务，并提前演练“换目标不换码”。第三是批量核对：同一批海报如果用了多个码（报名、资料、客服各一个），生成后建一张对照表，逐个扫码核对落点、标题和统计口径，避免贴错位置。最后在交付文件里保留二维码源文件和目标地址清单，后续替换时不用重新生成整张海报。

可以按“先扩词、再限证据、最后留痕”的顺序处理。第一步把原问题拆成三组词：对象词（设备/材料/工艺名称）、过程词（合成、检测、应用场景）、限定词（年份、标准号、地区、语言），每组分别加入中文别称、英文术语和上位概念重新检索，并记录每次改词后结果变化，避免把相邻行业的参数直接搬过来。第二步要求模型只基于你提供的检索结果回答：让它逐条标注“来源标题、原文片段、支持的结论”，来源里没有的数字、机构名和结论一律写“暂无公开依据”，不要让它补齐章节。第三步对关键事实做交叉核对：同一结论至少要能在两个独立来源中对上，标准类信息优先查标准编号和发布机构原文，论文类信息核对题名、作者和发表年份。第四步把检索日志留下来，包括用过的关键词、数据库或站点范围、命中条数和排除理由；找不到时就按“公开资料有限，结论待内部资料确认”表述，而不是写成“国内外没有同类技术”。这样扩大的是线索面，不是编造面。

前面几楼把建桶、上传、权限、计费讲得很全了，这里补一个新手最容易忽视的角度：数据安全与可恢复性。OBS 本身很可靠，但这不等于里面的数据丢不了。 一、先分清责任：对象存储保障的是服务可用性和数据持久性，但误删、误覆盖、密钥泄露、账号被盗这些人为操作，不在平台兜底范围内。重要数据不能只放一个桶就不管了。 二、防误删要做三层：第一层开版本控制，覆盖和删除都有历史版本可回滚；第二层对核心数据做跨区域复制，单区域出问题还有副本；第三层对关键对象用对象锁定或合规保留，防止在保留期内被删改。这三层配齐之前，生产桶里的删除操作都要走双人确认。 三、访问要留痕：开桶的访问日志和云审计，异常下载、批量删除、权限变更都能查到是谁、什么时候、从哪里做的。只配权限不看日志，等于装了锁却不看监控。 四、密钥要轮换：应用用的 AK/SK 定期轮换，泄露过的立刻作废；前端和代码仓库里出现过的密钥一律当作已泄露处理。敏感数据再叠加服务端加密，密钥用 KMS 管理，不要自己在代码里拼密钥。 五、恢复要演练过才算数：每季度在测试桶做一次恢复演练，验证版本回滚和跨区域副本真的能把数据恢复回来。只配不练，等到真丢数据才发现复制规则配错了前缀，就晚了。 一句话：上传成功只是第一步，删不掉、改不了、找得回，才算真正用好了对象存储。

前面几楼把单机选型、压测和计费算得很细了，这里补一个角度：别只在单台机器的核数上纠结，很多时候架构调一下，比升一档规格便宜得多。 一、先拆再升：单机升配有天花板。Web 和数据库跑在同一台机器上时，瓶颈经常互相拖累：数据库吃内存、Web 吃 CPU，升哪边都不划算。先把数据库独立出来，再给高频读加一层缓存，单机压力下来了，规格自然不用买大。 二、峰值用弹性扛，不用常驻规格扛：业务有明显波峰波谷时，基线规格按日常负载买，波峰靠弹性伸缩组临时加机器，低峰再缩回去。按量部分的机器只在高峰期花钱，比常年为峰值买一台大规格便宜。 三、非生产环境定时启停：测试、演示、预发布环境晚上和周末没人用，按量计费的机器在这些时段关机就是纯省钱。生产环境不要这么做，但非生产环境值得做。 四、计费组合着买：核心长期跑的机器用包年包月锁定成本，弹性扩容的部分用按量；不要全包年包月，也不要全按量。 五、升降配的操作注意：改配前先做快照或镜像，低峰时段操作，改完跑一轮核心接口回归再放量；降配前留一个回退窗口，万一监控告警能立刻升回去。 一句话：先看架构能不能拆、峰值能不能弹性扛，实在扛不住再谈升配，账算下来往往更省。