前面三樓把「一張表、一個動作、逐項驗收」和 dolly、zoom 的區分講得很全了，我補一個樓上沒有展開、但實際最省返工的做法：先把提示詞當成可版本管理的「鏡頭規格」，再用對照試驗定位問題，而不是每次重寫一整段提示詞。 一、提示詞要寫成規格，不要寫成散文 我現在的做法是把每個鏡頭固定寫成六行，順序不變：主體與參考、起始景別、相機動作、速度時長、終止畫面、不要出現的東西。順序固定有一個好處：出問題時一眼就能看到哪一行寫錯了。例如「不要出現的東西」這一欄專門寫「背景不要旋轉、主體不要變形、不要切換景別」，這些否定條件寫在正文裡容易被工具忽略，單獨列出來命中率明顯更高。 二、先靜態後動態，驗證分兩步走 直接生成帶運鏡的視頻，失敗了很難知道是構圖錯還是運鏡錯。我的順序是：第一步先生成靜態的首幀和尾幀，只確認構圖、主體占比和文字是否可讀；第二步再在確認過的首尾幀之間加運鏡。這樣一旦出現漂移，可以確定是運鏡那一步的問題，不用回頭懷疑構圖。對講解視頻來說，這一步尤其值錢：首尾幀確認一次，後面十幾個鏡頭都可以沿用同一套構圖。 三、出問題用對照試驗，一次只改一個變量 出現主體漂移或背景反向時，不要同時改速度、角度和景別。我的排查順序是：先把運鏡全部刪掉，只留推近，看主體是否穩定；穩定了再加環繞；還穩定，再把兩段合成一鏡。每一步只改一個變量，改完生成一次，問題出在哪一段立刻就能定位。反過來，三個變量一起改，就算這次好了，也不知道是哪一個改對了，下次換個設備還會再翻車。 四、給講解視頻補一句：旁白與鏡頭要對齊 貫文智能體講解視頻的場景裡，鏡頭不只是好看，還要跟旁白同步：口播一句、鏡頭完成一個動作。做法是在分鏡腳本裡給每一行旁白標上對應的鏡頭編號，旁白講到哪個部件，鏡頭就推到哪個部件；講連接關係時用切鏡加靜態標註，不要用一個長環繞鏡頭硬撐。這樣即使某個鏡頭生成失敗，也只需要重做那一個鏡頭，不用整段重來。 一句話總結：拆法之外，再加一層管理——提示詞寫成固定格式的規格、先靜態驗證再加運鏡、出問題一次只改一個變量，鏡頭拆得開，也修得回。

楼上几位把计算、合成、实验三关和证据卡讲得很全了，我补一个交接角度：AI 团队把候选交给实验团队时，到底该交出什么，才算“可判断”。很多候选卡住，不是因为结论不对，而是交接时缺关键信息，实验方只能从头猜。一、交接时必须附一张“候选交付清单”，缺一项就退回补齐。清单至少包括：结构文件（CIF）与生成条件、模型名称版本与训练数据范围、预测值与不确定度（或多模型投票结果）、稳定性复核结果（Ehull、声子谱）、建议的合成路线与备选路线、最可能出现的杂相清单、前驱体清单与安全提示。没有这张清单，实验方无法判断该先试哪条路，也无法复算。二、首轮实验按“单变量筛选矩阵”设计，不要一次只试最优条件。固定前驱体与配比，先扫温度（如 700/800/900℃ 三档）与保温时间两档，做 6 组小试，目标只是确认“能不能成相”：XRD 对上主要衍射峰就继续，杂相占主导就停下来调条件。24–48 小时拿到成相信号，比花两周做全套表征更划算；首轮不设性能目标，只设“成相/不成相、主相/杂相”两个结论。三、用已有实验数据给模型做一次“回测”。在正式投入新候选前，拿实验室已有的几十条已知结果（哪些做出来了、哪些没做出来）让模型重新排序，看它能不能把已合成的排在前面、把失败的排在后面。如果回测命中率不高，说明模型在该化学体系里并不可靠，新候选的优先级要整体下调，而不是照单全收。一句话：判断能否合成，既要看候选本身的三关证据，也要看交接是否完整、首轮实验是否设计得能快速证伪、模型是否通过了回测。三件事都齐了，再进实验室，资源才不会浪费在“猜”上。

前面几楼把对时方法、信号对齐、模型侧处理讲得很全了，我补充一个前面没展开的角度：把这件事按“设备—网关—平台—模型”四层分工落地，并给每一层定一个可验收的标准。很多团队的问题不是不知道要对时，而是每一层都以为对方在管，最后没人管。一、四层分工：每一层只管自己能管的设备层只负责“打时间戳的时刻要对”：采样中断里打戳，上电先对时再采样（5楼已讲）；做不到对时的设备，至少带一个单调递增的序列号，让后端能发现乱序。网关层只负责“统一授时和统一入口”：网关做 NTP 中继，传感器只对内网授时，避免公网 NTP 不可达时全员失同步；网关收到消息时补一个接收时间，并把设备时间戳、网关时间戳一起上送。网关还是唯一知道“这台设备上次成功对时是什么时候”的地方，超过周期没对上的设备，直接在网关侧打标。平台层只负责“脏数据不入库、异常看得见”：用物联网平台（比如 IoTDA）接入时，规则引擎先做时间戳校验，未来时间、1970年时间、同一设备时间倒退的，直接进异常表或死信，不进根因排序；再把 chrony 的偏移、漂移率、时钟层级接入监控，偏移超过业务阈值就告警。模型层只负责“在时间质量已知的前提下判断”：根因排序的输入不是裸时间戳，而是时间戳加质量分（距上次同步多久、估算漂移多少）；质量分低的样本降权，或者只做同一时间窗内的共现判断。二、一个小团队能照抄的落地顺序我建议按“先止血、再治本、最后上模型”的顺序做，不要一次全上。第一步止血，当天能做：平台侧规则引擎加时间戳校验，脏数据先隔离；双时间戳 event_time 和 receive_time 先存下来，哪怕暂时不用。第二步治本，一周内做完：网关做 NTP 中继并给未同步设备打标；chrony 的 tracking 信息接告警；设备上线检查清单里加授时配置这一项，固件升级后复查一次。第三步模型侧最后做：相对特征加顺序置信度；根因结论附上各路信号的时钟偏移估计值，误差大于事件间隔时只写“同时段异常”，不硬排先后。三、补一个容易漏的决策：什么时候不让 AI 判时钟不可信的时段，AI 不应该硬排先后。我的做法是给根因输出加一道闸：偏移没有超阈值，正常输出；偏移超阈值，或者某路设备断电重启后一直没同步上，只输出候选根因列表并标“顺序不确定”，同时触发人工复核。相当于给 AI 的先后判断加一个熔断机制，宁可不判，也不判错。这道闸的阈值要按业务定，比如电机振动异常到温升的间隔只有几秒，阈值就应该小于 1 秒。一句话总结：时钟问题按层分工修，每层只管自己能管的，脏数据先隔离；最后给 AI 的先后判断加一道熔断，不可信时宁可不判。

先说一个思路上的转变：别只找“大文件”，要先把 df 和 du 的数在同一个口径下对上账，再去找藏起来的那部分。我在线上遇到这类问题，一般按下面这个顺序查，十分钟左右就能定位。第一步，先对账，不要凭感觉比较。df 和 du 默认单位和统计范围不一样，直接比两个数容易误判：df -B1 --output=target,used,avail /datasudo du -x -B1 -s /data注意两点：du 要加 -x 限定在同一个文件系统，并且用 root 跑，权限不足被跳过的目录不会报错提示，只会悄悄漏掉，这是最常见的漏统计。把 df 的 Used 和 du 的总数一减，差额就是要找的东西；如果差额很小，只是统计口径导致的，那就不是“藏起来了”，而是之前比较的姿势不对。第二步，查“文件个个不大，但加起来很大”的情况。很多人只用 find -size +1G 找大文件，漏掉了一种情况：几十万个几 KB 的小文件（会话文件、缓存碎片、轮转失败的旧日志）单个都不大，加起来却有几十 GB，du 逐层看目录大小时反而容易被忽略。用 inode 视角再查一次：sudo du --inodes -d1 /data 2>/dev/null | sort -rn | headsudo du -x -h --max-depth=1 /data 2>/dev/null | sort -rh | head文件数多的目录优先往下钻，里面往往是日志切割没配好、或者某个缓存目录长期没清理。如果是 inode 先满了，df -i 能看到，那又是另一回事，需要清的是小文件数量而不是字节数。第三步，查“逻辑大小和实际占用对不上的文件”。数据库、虚拟机镜像、大模型检查点这类文件，有时会预分配空间、或者写成稀疏文件：ls -lh 看到的逻辑大小和 du 统计的实际块占用可能差几倍。对比着看：ls -lhs /data/可疑文件du -h /data/可疑文件如果 du 的数远大于文件内容该有的数，先看是不是预分配、是不是日志文件正在被持续追加写；如果 ls 显示很大而 du 很小，那是稀疏文件，它不是凶手，方向要换。第四步，查正在被写的文件，而不只是已经落盘的。除了 lsof +L1 找 deleted，我还会扫一遍所有进程的 fd，看哪些正在写入的文件已经涨得很大：sudo lsof -nP +aL1 /datasudo find /proc/[0-9]*/fd -lname '* (deleted)' 2>/dev/null | head如果确认是某个服务正在写的日志，处理时不一定要杀进程，先用 : > /proc//fd/ 截断，空间马上释放；再给日志加上轮转，copytruncate 能避免以后再用 rm 删正在写的文件。最后一点提醒：先定位再清理。清理前确认那部分空间的归属——到底是业务日志、缓存，还是误删后要恢复的数据。清理之后再跑一次第一步的对账，df 的 Used 和 du 的总数对得上了，才算这件事真正闭环。

这个问题可以分三步走：先定义好一次任务要什么，再用接口提交任务拿到 job_id，最后按 job_id 拉结果、做成训练用的对齐数据。第一，接口怎么给。按帖子里说的 Media Data API，任务用 POST /dca/trigger_hp 提交，请求里要带：视频来源（YouTube、Vimeo、TikTok、Bilibili 的链接）、要哪些模态（完整视频含默认音轨，或只取视频流；音频取默认音轨或一次取全部音轨，比如多语言版本）、字幕格式（VTT、SRT、JSON3 三选一）。画质用 min_height、max_height 限定区间，比如 720p 到 1440p，再选画面方向和画质优先级；如果训练只需要文本，还可以只取字幕和缩略图，跳过媒体下载省存储。一次任务一个 job_id，之后用它查状态、拉结果。第二，拿到结果后怎么对齐成训练数据。视频按时间切帧、音频转成统一采样率的波形、字幕按时间戳对齐，三者用同一个时间轴拼成样本：一段视频加对应音频加对应字幕文本，就是一条多模态样本。Storyboard 和缩略图可以用来快速筛选，先抽掉黑场、静音段再进训练集，能省不少清洗时间。第三，合规这条线别省。只用有授权或平台允许使用的内容，检查目标平台的服务条款和版权要求；接口返回的数据也要留存来源记录，方便后续溯源。这个流程跑通后，一次任务就能批量拿到可直接进训练的视频、音频、字幕三件套。

先补充两点 1 楼没展开的：中文 PDF 语料去哪找现成的，以及拿到之后怎么验货。一、中文 PDF 语料的现成渠道（按合规优先级）1. 官方公开库：国家图书馆、中国国家数字图书馆的开放资源，国务院及各部委网站的政策文件、年报、白皮书。这些 PDF 版式规整、许可清晰，适合做通用知识语料打底。2. 上市公司与行业报告：巨潮资讯、交易所披露的财报和公告 PDF，信通院等机构公开发布的行业报告。领域集中，适合做金融、通信等垂直方向的继续预训练。3. 裁判文书与标准文档：中国裁判文书网公开的文书、国家标准全文公开系统。量大且结构固定，但要注意使用条款里对批量下载和再分发的限制，别直接爬。4. 学术类：arXiv、PubMed Central 的开放获取子集，和 1 楼提到的一致，英文为主，适合做中英混合配比。二、楼主提到的亮数据 PDF 数据集怎么用它定位是预训练用的商业数据集，量级确实大（4.5 亿有效链接、900TB），但 TB 数不等于可用量。建议先通过官方渠道拿样本，用自己的抽取流程跑三项检查：抽取后正文占比、去重后剩余比例、随机抽 100 条人工读一遍看有没有乱码和广告页。三项都过再谈采购，别按标称体积付费。三、拿之前先算一笔账按经验粗算：1 个 token 约等于 0.75 个英文词、约 2 个汉字。一份 20 页的 PDF 正文大约 1.5 万到 2 万字，约合 1 万 token 左右。如果目标是 100 亿 token 的领域语料，大概要 100 万份这样的 PDF。先定目标 token 数，再决定要找多少源，顺序不能反，不然很容易囤了一堆用不上的数据。一句话总结：现成渠道够起步，中文 PDF 优先走官方公开库；商业数据集先验货再买；先算 token 账再动手囤数据。

我补充一个落地的判断方法：前面几楼把适合与不适合的场景分得很清楚了，这里给一个可以直接照着用的“三问 + 一条链”。一、三问自测，答完就知道适不适合第一问：触发这件事的事件源清不清楚？是 OBS 文件上传、定时器、APIG 请求、SMN 或 DMS 消息这种明确的事件，还是“需要一直跑着等用户”？前者适合，后者不适合。第二问：单次执行能不能在秒级到分钟级内完成？图片转码、数据清洗、订单校验、通知发送都可以；一次跑几十分钟的离线跑批不行，要拆成小任务或用批处理服务。第三问：执行过程需不需要常驻状态或长连接？函数实例用完就回收，本地磁盘是临时的，需要的状态必须放 RDS、Redis 或 OBS。需要 WebSocket 长连接、一直监听端口的服务，也不适合。二、一条真实的链路：图片上传处理流水线用户上传图片到 OBS，OBS 事件触发第一个函数生成三种尺寸的缩略图写回另一个桶；同一个函数把图片元数据写进 RDS；每天凌晨 Timer 再触发一个函数，清理超过 30 天的临时文件。整条链上没有一台常驻服务器，文件到了才花钱。落地时有三点要注意：内存和超时按实际耗时配，留出余量；并发起来后下游 RDS 的连接数会被打高，要配连接池或代理；依赖包别贪大，包越大冷启动越慢。三、成本怎么算按调用次数和运行时间计费，不调用就不花钱。请求量小、一天只有几百次调用，或者流量忽高忽低、半夜几乎为零的场景，比包月一台 ECS 划算。反过来，如果是 24 小时持续不断的高频流量，长期算下来可能比 ECS 或容器更贵。选型前先估一下每天的调用次数和单次运行时间，再跟 ECS 的包月价对比一次。一句话：能画出“事件到函数再到下游服务”这条链、且每一步都是短时无状态的，就适合用 FunctionGraph；画不出来、或者需要一直在线等着的，就用 ECS 或容器。

先定性再动手，这句话看起来只有一个原因，实际至少有两种可能，处理方法完全不同。一、先给请求“称一次重”在浏览器开发者工具的网络面板里找到被拦的那条请求，看请求负载到底有多大；如果是在 IDE 插件里触发，看插件日志里有没有记录请求体字节数。超过 1MB，就基本可以判定是请求体体积撞了网关上限；如果请求本身很小也报同一句，那就走权限方向。二、最快的一个对照实验：全新会话 + 一句短话新建一个空白会话，不带任何文件，只问一句很短的话。如果能通，就是上下文太大；如果照样报错，就是账号或网关侧的问题。注意一定要在全新会话里试——原会话的历史会被一起打包进请求体，短问句也可能照样超限，会误判。三、确认是体积问题，按这个顺序改1. 只引用正在改的那一个文件，不要全选工作区；生成物（dist、node_modules、lock 文件）不要放进上下文。2. 一次只做一个文件的改动，多文件重构拆成多次请求；对话超过十轮就开新会话。3. 文件内容不要用 base64 塞进请求体，改走对象存储直传，接口里只传引用。4. 批量操作先按几百 KB 切块再提交，并带幂等键防重复。四、如果要走申请提额，把材料一次给全报错原文与截图、请求入口的完整地址、触发时间（精确到分钟）、峰值请求体大小、为什么不能拆分、期望的有效期。只说“请开通 1M 权限”最容易被打回来。获批后先等权限缓存刷新、退出重登，再到每个使用入口（网页端、IDE 插件等）逐个验证。一句话总结：先称重、再定性，体积问题改请求、权限问题走申请，不要在没定性之前反复重试。

前面两楼把凭据类型、排查顺序和轮换流程讲得很全了，我补充一个在小团队里最实用的做法：凭据到期这件事，不能只靠人记，要把它变成一张台账加一次预检。 我现在的做法是这样的。 第一，给每组流水线凭据建一行台账，只记五项：凭据名、用途、负责项目、创建日期、预计到期日。到期日不知道就写“创建日起三个月后复核”，先有一个复核点，再慢慢补准确日期。台账放在团队共享文档里，轮换时顺手改一行，下次出问题不用先翻三个月前的聊天记录。 第二，预检步骤只探状态码，不碰凭据原文。前面楼里给的 curl 预检我也在用，但我会再加两点：用 -I 只发 HEAD 请求，不下载整个包；判断时只认 200 和 401/403，别的都算“说不清”，直接让构建停下来报“预检未通过”，不要让它继续跑到下载步骤才失败。预检用的变量只在流水线里以凭据引用方式传入，不要在脚本里写死，也不要 echo 出来。 第三，交接时写清“谁能改什么”。你现在只有编辑流水线的权限，大概率改不了项目 B 那边的仓库授权和凭据本身。提申请时直接写三行：需要项目 B 管理员开“目标 release 仓库只读，精确到制品路径前缀”；需要本项目管理员在凭据管理里新增一份只读服务账号凭据；验证通过后再撤销旧凭据。权限申请越具体，批得越快。 内网还是公网那一点，我的经验是同一区域内构建机访问制品仓库一般走内网，不用单独算流量；跨区域才会慢、才有公网费用，判断方法是在构建机上看解析结果是不是内网地址，拿不准就先按跨区域来估。 最后补一句：凭据修好之后先手动跑一次完整流水线再收工，自动触发失败时拿不到实时日志，排查成本反而更高。

这个取舍其实不用先看产品参数，先看你们团队的三件事：有没有人值班、数据丢了能不能接受、以后要不要做深度定制。 1、没有专职 DBA 或运维值班，直接选 RDS。RDS 自带主备切换、自动备份、时间点恢复、慢 SQL 监控和告警，这些自建都要自己搭：主从复制、备份脚本、巡检、半夜被告警叫起来，都是隐性成本。个人项目和小团队尤其明显，省下的不是实例费，是出问题时的人。 2、看成本要把账算全。RDS 的账面价是实例费 + 存储 + 备份空间；自建的账面价是 ECS + 云盘，看起来便宜，但要加上人力、备份存储、监控和故障恢复的时间。小库、业务量不大时，包年包月的 RDS 通常更划算；只有库很大、规格常年拉满，算下来自建才可能便宜，建议按实际规格把两边 1 年总价列出来再比。 3、需要深度定制时再考虑自建。比如要改数据库内核参数、用 RDS 不支持的插件或特定版本、要跨云迁移、合规要求数据必须落在自有加密体系里，这些 RDS 满足不了，就自建。 4、合规和审计先确认。等保、审计日志、数据保留期限这些要求，先查 RDS 的对应能力是否覆盖，覆盖不了再谈自建。 我的建议：个人项目和小团队先上 RDS，把精力放业务上；等业务大到出现 RDS 满足不了的点（特殊插件、深度调优、成本拐点）时，再用 DRS 做不停机迁移到自建。先跑起来，再谈优化，别一上来就为自建搭一整套运维。