📋 目录
- 📊 先看一组让人失去感觉的数字
- 🔬 Fengwu Sun 在硅谷 101 讲了什么
- ⭐ 一个刚刚发生的真实案例：2026 ED138
- 🔍 纠错：AI 在这件事上到底做了什么，没做什么
- 🧪 中国团队在同一条赛道上：西湖大学 DREAMS
- 💡 一个容易被忽略的转机：商业资本正在改变望远镜的研发节奏
- 🏗️ 与领码 SPARK 融合平台的关系：数据洪水时代的三个设计选择
- 📌 三条可以直接用的判断
- 💬 想听听你的判断
📊 先看一组让人失去感觉的数字
先说结论：天文学是当下最迫切需要 AI 的领域之一——不是因为 AI 更聪明，而是因为数据量已经彻底越过了人类的处理上限。
先把 Rubin 天文台的官方数字摆出来。这些数字来自 Rubin 官方与 NOIRLab，不是二手转述：
| 项目 | 数值 |
|---|---|
| 原始数据 | 每晚约 20 TB |
| 单张图像 | 3200 万像素，每 40 秒一张，每张8 GB |
| 事件警报 | 每晚最多约 1000 万条 |
| 实时警报延迟 | 60 秒 |
| 十年巡天原始数据 | 60 PB |
| 十年处理后数据总量 | 约 500 PB |
| 最终数据库（DR11） | 15 PB |
| 十年累计天体 | 约200 亿个星系、170 亿颗恒星、600 万条太阳系天体轨道 |
每晚 1000 万条警报是什么概念？就算把全世界所有天文学家和研究生加起来，每人每秒处理一条也追不上。而且每条警报都需要判断：这是真实天体、仪器瑕疵，还是已知目标的再次出现。
这台望远镜 2025 年 4 月首次成像，2026 年 6 月正式开跑十年巡天。换句话说，它刚刚开始生产数据，而数据管线的规模已经要靠 CERN 的软件来扛——Rubin 的数据目录系统直接借用了 ATLAS 实验的方案，因为两者面对的是同类问题：多站点、几十亿个对象、巨量数据。
全链路的自动化程度是这样的：
注意这条链上没有人在中间按按钮。7 秒传输、自动比对、自动发出警报、自动分类路由——人只在最后一步介入，而那一步已经是"从已经被筛过一遍的东西里挑出值得追的"。
对照企业里的现状：很多系统还在"数据进来 → 推给所有人 → 所有人自己筛"这一步上打转。Rubin 的做法是把"筛"这一步前置到算法层，人只在末端出现。
🔬 Fengwu Sun 在硅谷 101 讲了什么
在硅谷 2026 大会（Alignment 2026）上，西湖大学助理教授Fengwu Sun做了一场 Keynote，主题是 AI 如何改变天文学。他以詹姆斯·韦布空间望远镜（JWST）、Nancy Grace Roman 空间望远镜和 Vera Rubin 天文台为例，描述了一个共同困境：
新一代望远镜每天可能产生数 TB 乃至数十 TB 的数据，以及数百万条天文事件提醒，远远超出科学家人工处理的能力。
他给出的三个 AI 介入方向很具体：
| 方向 | AI 在做什么 | 解决的问题 |
|---|---|---|
| 识别引力透镜 | 从海量观测中识别透镜现象 | 透镜是寻找系外行星、测量暗能量的重要手段，但人工在千万级星系样本里找几千个高质量透镜几乎不可能 |
| 寻找超新星 | 在数据流中定位超新星等暂现源 | 超新星是关键的距离标尺，漏掉就少了一批数据 |
| 降低图像噪声 | 用自监督学习提亮图像 | 发现更微弱的天体信号 |
他还提到一个更远的方向：AI 未来可能进一步参与望远镜的自主观测与任务规划——不是只处理已经拍下来的数据，而是决定下一拍拍哪里。
而他最值得被转述的一个判断是：天文学既迫切需要 AI，也可能成为 AI 研究的重要试验场。
理由很扎实：宇宙每天都在产生海量、真实且未经标注的新数据。这对 AI 来说是最稀缺的东西——真实分布的数据、不需要人工标注、且能持续产生。
⭐ 一个刚刚发生的真实案例：2026 ED138
就在 10 月 27 日，IAU 小行星中心（IAU MPC）宣布了一个新发现：Rubin 天文台发现首个矮行星候选体 2026 ED138。
这个案例值得完整拆开，因为它把"AI 找天体"的真实分工展示得非常清楚。
| 项目 | 数值 |
|---|---|
| 发现者 | Matthew Holman（哈佛-史密森天体中心 CfA） |
| 发现方式 | 运行自己与 Kevin Napier 开发的搜索代码 |
| 关键日期 | 2026 年 10 月 13 日，在此前已收集的 Rubin 数据中跑出 |
| 观测跨度 | 3 月 4 日至 7 月 11 日，20 个夜晚，共 30 次观测 |
| 回溯数据 | DECam 归档图像经 Asteroid Institute 的 ADAM Precovery 服务回溯到2016 年 |
| 轨道拟合长度 | 超过 10 年 |
| 当前距离 | 约46 天文单位（冥王星平均约 40 au） |
| 估计尺寸 | 600 – 1500 公里（依据距离、亮度和估计反照率） |
| 轨道倾角 | 约 25°，属"热经典"型 TNO |
Holman 说：“我的第一反应是又兴奋又不敢相信。这类天体非常罕见，所以我马上开始检查是不是我或者代码出了什么错。”
这段自述是整件事里最有价值的一句。它准确描述了人机分工的真实状态：算法给出候选，人类的第一反应是怀疑。这跟 10 月 13 日一位 DeepMind 科学家说的"AI 写代码能验证、写科学不能"是同一个问题的两面——但今天这个案例给出了更具体的答案。
🔍 纠错：AI 在这件事上到底做了什么，没做什么
网上关于"AI 发现新天体"的表述越来越顺口，但按招股书式的严谨要求，得把边界划清楚。
| 说法 | 是否成立 | 说明 |
|---|---|---|
| “AI 发现了新天体” | ⚠️ 简化 | 算法做的是"从数十亿次探测中归并出属于同一物体的那些"；判断它是什么天体、是否够格叫矮行星，是人做的 |
| “AI 找到了前五颗矮行星之外的第六颗” | ❌ 不成立 | ED138 是候选，需红外观测进一步约束尺寸才能确认 |
| “Rubin 每天产生 20TB 数据” | ✅ | 官方口径，每晚约 20TB 原始图像 |
| “每晚 1000 万条警报” | ✅ | 官方"每晚约 1000 万条" |
| “数据传到美国需要 7 秒” | ✅ | 从智利山顶传到 SLAC 的美国数据设施 |
| “十年产生 500 PB 数据” | ✅ | 处理后总量（含模拟）；原始数据是 60 PB |
| “人类已经看不过来” | ✅ | 这是全部前提 |
两个特别值得说的技术细节：
第一，7 秒。每次曝光后 7 秒内，图像从智利山顶传到 SLAC 的美国数据设施，随即与参考图像比对、标出差异、发出警报。80 小时后，图像被镜像到法国和英国的数据设施。这是全链路自动化的——没有人在中间按按钮。
第二，那 30 次观测是怎么"攒"出来的。Holman 10 月 13 日跑代码时发现的，只是 Rubin 在 3 月到 7 月间拍到的一次。团队随后在 Rubin 的目录里翻出另外 20 次观测，又通过 DECam 的 2016 年归档图像把轨道追溯到十年以上。
这正是机器学习真正的价值所在：不是它"看懂了"一张图，而是它让"同一个物体在 30 个不同夜晚、30 张不同图像里出现"这件事能被自动归并出来。没有这个归并能力，人根本无从知道该去翻哪 30 张图。
🧪 中国团队在同一条赛道上：西湖大学 DREAMS
有意思的是，做这场演讲的西湖大学，恰好也在 10 月 27 日（同一天）发布了 DREAMS 巡天计划的首批数据。
| 项目 | 数值 |
|---|---|
| 覆盖范围 | 银河系中心附近约5 平方度 |
| 恒星数量 | 近6000 万颗 |
| 观测频率 | 分钟级（时间采样间隔约 1–2 分钟） |
| 数据总量 | 约2.5 TB，已通过国家天文科学数据中心免费开放 |
| 通道 | 近红外 z 波段约 80%，可见光 r 波段约 20% |
| 探测深度 | 单次曝光极限流量约为以往同类巡天的1/5 |
| 观测期 | 2025 年启动，计划持续至2028 年 |
| 首要科学目标 | 微引力透镜搜寻地球至火星质量级别的流浪行星 |
首发数据只用了约 0.4% 的天区做试点搜寻，就发现了一批全新的短周期变星、两个恒星耀发事件，以及一个此前未知的短时标微引力透镜事件。
0.4% 的天区。这是"数据开放"这件事最有力的证据——剩下 99.6% 还在那儿。
而且这个比例背后是一个可以复制的做法：先做小范围试点搜寻，把方法验证了，再开放全量数据。0.4% 的天区找出的那批新短周期变星、两个耀发事件、一个未知微引力透镜事件，本身就是方法有效性的证明——这比"我们放了很多数据出来"这种表态有力得多。
而在另一条线上，同济大学等团队用机器学习框架CIGaRS处理 Ia 型超新星，把暗能量参数约束能力比主流方法提升了约4 倍。他们自己说：这对 LSST 每周 TB 级数据量的节奏来说，“几乎是必不可少的技术储备”。
这两件事放在一起，指向一个共同结论：AI 在天文学里的角色不是"提出理论"，而是"把已经被拍下来的东西榨干"。望远镜拍到的每一个光子，早就躺在硬盘里了；真正的问题是没人来得及看。机器学习填的正是这个缺口。
💡 一个容易被忽略的转机：商业资本正在改变望远镜的研发节奏
Fengwu Sun 在演讲里还谈到了一个看起来不像是技术话题的变化，但它其实很关键：
随着商业资本进入太空观测领域，一些新望远镜项目开始借鉴科技创业公司的研发模式，希望通过更快的迭代和商业化供应链，降低天文观测的成本。
这件事为什么重要？因为它意味着望远镜本身正在变成一个可以迭代的产品，而不再是一个一次性的巨型工程。
传统大型天文台的建设周期是十年二十年，一旦建成，数据管线就是围绕"固定产出、固定处理方式"设计的。而如果新一代项目采用更快的迭代节奏，那么观测数据的多样性和格式变化频率都会上升——这会直接推高对灵活数据管线的要求。
| 传统模式 | 商业化迭代模式 | 对数据管线的影响 |
|---|---|---|
| 一次性建成，产出格式相对稳定 | 持续迭代，仪器与格式都可能变 | 接入层必须能容忍格式演进 |
| 数据量可预估 | 数据量与产出节奏都可能变 | 容量规划不能按固定配额 |
| 少数几个大型数据节点 | 分散 + 商业供应链多方参与 | 数据权利与协议复杂度上升 |
而这恰恰是本栏目的读者更熟悉的问题：当数据来源从"几个稳定的系统"变成"多个会变的供应商"，接入层的设计目标就要从"能接进来"变成"能接进来并且能一直接下去"。
🏗️ 与领码 SPARK 融合平台的关系：数据洪水时代的三个设计选择
这一节说领码 SPARK 融合平台在这件事上的设计选择。
边界先说清：平台能让数据可接、可分流、可追溯。哪一类数据值得人看、哪一类交给机器，这个判断只能由业务方做。
其一：iPaaS 接入层的第一课，是"数据来得比人处理得快"
Rubin 的管线有一个关键设计：先分类，再分发。每晚 1000 万条警报不直接推给科学家，而是先经过一层叫"broker"的专门软件——这层软件本身就是基于机器学习分类算法的——把警报分类、评分，然后才路由给全球各地的科学团队。
这和很多企业现在做的事正好相反：数据一进来就推给所有人，然后让人自己筛。
对照一下就有数了：
| 做法 | 结果 |
|---|---|
| 数据直接推给人，人自己筛 | 人成了瓶颈，且所有人重复劳动 |
| 先用算法分流，只把值得看的给人 | 人只处理有价值的部分 |
对应到企业：iPaaS 接入层要接进来的，不只是"数据源清单"，还有"分流规则"。一条新的业务数据进来时，系统应该知道它是"直接给业务方看"、“先聚合再给”、“还是先过一道算法评分再给”。
| 需要记录 | 为什么 |
|---|---|
| 数据来源与到达延迟 | 决定这条数据能不能进实时决策 |
| 分流等级与规则版本 | 决定谁在什么条件下会看到它 |
| 原始量与净量 | 区分"数据洪水"和"有效信息" |
| 丢弃/降采样策略 | 明确"什么被扔掉了"，避免不可追溯 |
判断标准：能不能回答"每一条到达的数据，最终被谁看到了、为什么是他"。
其二：治理中心要把"警报"当成一等公民指标
在 Rubin 那里，一个警报是一条待判断的候选。它有自己的生命周期：生成 → 分类 → 分配 → 观察 → 确认或否决。
企业里对应的是同一类东西，只是叫法不同——线索、异常、待办、风控告警。这类"候选"型数据的治理，比"记录"型数据难得多，因为它们数量巨大、且必须可追溯。
治理中心要管的：
| 需要记录 | 用途 |
|---|---|
| 候选产生时间与来源 | 复现一条告警的来龙去脉 |
| 评分与评分依据 | 判断分流规则是否合理 |
| 处置状态与处置人 | 区分"已确认"和"没人看" |
| 误报率与漏报率 | 误报太多 → 人会忽略全部告警 |
| 观察窗口与失效时间 | 错过窗口的候选要能被标记出来 |
判断标准：能不能回答"上周产生的一百万条告警里，有多少被人看过、被确认过、有多少是误报"。最后一个数字最关键——误报率过高时，人会形成"忽略告警"的习惯，此后真问题也一起被忽略。
其三：全域守卫要管住"数据权利的分层"
Rubin 有一整套数据权利制度：美国和智利本地的专业天文学家自动获得官方发布数据的权利，其他人需要通过贡献申请。数据平台 Rubin Science Platform 向获授权者开放。
这说明连"谁能看到原始数据"都是一个需要认真设计的治理问题，不是默认全开。
对应到企业，全域守卫该做的是：
- 按角色分层授予原始数据访问权（不是所有岗位都需要看到全部原始数据）
- 记录每一次数据访问的来源与用途
- 对高敏感数据集设置导出与二次分发的限制
- 让"谁能看"和"谁能改"是两套独立的权限
其四：与 Dify 的分工
平台层负责数据接入、分流、归集、审计；具体的分析工作流、多轮 Agent 编排、Prompt 管理留给 Dify 这类应用层框架。
理由很直接：Rubin 的 broker 做的是"分流"和"初筛"，不是"研究"。前者是平台该做的通用能力，后者是每个科学团队自己的方法论。把研究工作流塞进数据接入层，数据接入层就会被拖垮——这在处理每天 20TB 数据时是致命的。
📌 三条可以直接用的判断
| # | 判断 |
|---|---|
| 1 | 数据洪水场景下，先分类再分发比直接推给人是更优解——把人从"筛数据"里解放出来 |
| 2 | 告警类数据一定要监控误报率，误报多了等于没有告警 |
| 3 | AI 处理真实海量数据时，人的第一反应应该是怀疑而不是采纳——这个习惯要写进流程 |
⚠️ 需要说明的取舍：本文引用的每晚 20 TB、3200 万像素、每 40 秒一张、每张 8 GB、每晚约 1000 万条警报、60 秒警报延迟、60 PB 原始、约 500 PB 处理后、15 PB DR11、200 亿星系、170 亿恒星、600 万条太阳系轨道、7 秒传输、80 小时镜像、ATLAS/CERN 软件借鉴均已核对至 Rubin 官方与 NOIRLab 官方材料。ED138 相关数据（10 月 13 日发现、3 月 4 日至 7 月 11 日、20 个夜晚、30 次观测、2016 年 DECam 回溯、10 年以上轨道、约 46 au、600–1500 公里、约 25° 倾角）均核对至 IAU MPC 公告与 NOIRLab 新闻稿。西湖大学 DREAMS 数据（5 平方度、近 6000 万颗恒星、分钟级、约 2.5 TB、z/r 波段 80%/20%、极限流量约为同类 1/5、0.4% 天区试点发现）核对至科技日报 10 月 27 日报道；CIGaRS 提升约 4 倍核对至中国经济网报道。本文明确不引用：Fengwu Sun 演讲中"数 TB 乃至数十 TB"与"数百万条天文事件提醒"的笼统表述（本文改用 Rubin 官方可核对的精确值）；"AI 发现新天体"这类把发现归功于算法的表述（本文已作纠正）；ED138 的"矮行星"定性（目前仅为候选，需红外观测确认尺寸）；New Constructs 的"1500 亿美元公允价值"等与本文无关的估值结论。
💬 想听听你的判断
你们公司里，是不是也有一堆"告警"在每天产生？
请回答这个具体问题：上个月你们的系统产生了多少条告警，其中有多少条被人真正看过并处理了？如果这两个数字差得很远，评论区说说差多少——我猜误报率才是真正的问题所在，而不是告警不够多。