Computing Life

GPT-6 Astra 3D建模能力的一些实验：爆炸视图，绑骨动捕，和视频生成

2026-09-05T22:00:00-07:00

GPT-6 Astra 发布之后，网上出现了很多惊艳的 demo。我看了之后深受启发，也因此做了一些有意思的小实验，想探索一下在这种新的 3D 建模的能力的支持下，我们到底能发掘出怎样有意思的应用场景。

我做的第一个小实验是让它做一个相对简单的建模，具体地说，让它去做东方Project里面博丽神社的模型。工具上我选用的是Blender这个建模工具。我用的prompt也贴在下面。这个是在餐厅里面对着语音识别说的，可以看到有很多错误。但现在AI都可以很轻松地理解背后的含义。

嗯，我们去试试看哦，就是首先用 Blender 建一个伯利神社，就是东方project 里面的伯利明神社。你得先上网调研一下，它这个神社大概要长什么样，有哪些基本元素，然后你用 Blender 就把它建一下，然后渲渲出一个环视的动画

这里面我并没有给它一个参考图像，而是让它自己上网调研。在工作了半小时左右，它给出了下面的模型。注意这是一个真实的3D模型，下面只是一个视角的渲染图。

我觉得这个质量还是相当惊艳的。虽然可以看见里面有很多近似，比如每棵树的面数都比较低，但是整体的风格和布置都是蛮可爱和符合角色身份的。

在解决了建模本身之后，基于这个我们能做哪些很酷的事情呢？由于我平时比较喜欢看方猫的视频，里面的爆炸视图特别厉害，所以我又给了GPT一个相对详细的prompt，让它来生成一个爆炸视图的视频。也就是先展示这个神社内部有什么结构，然后把它组装起来，最后在沙盘上把树木和石头也加进来，形成一个展示。在几十分钟之后，GPT也非常优秀地完成了这个任务。下面是结果。

在完成了这件事情之后，我对它的信心大增。考虑到AI写代码的能力已经非常厉害了，下一步我就让它把这个场景移植到浏览器里，加入第一人称渲染和碰撞检测，让用户在这个场景里可以自由探索和行走。它也非常顺利地完成了这个任务。一个有意思的地方是，在写代码的时候，它似乎是有点不耐烦，直接调用了Grok来写，它自己进行视觉验证。我不知道这是偶然现象还是训练的结果，但最终在时间和质量上取得了比较好的平衡。我们也把结果部署到了网站上，大家感兴趣的话可以在这里玩一玩。里面有三个Tab，分别可以在虚拟世界里面行走，观察整个沙盘，以及查看上面的爆炸视图。

我也尝试了让它做其他类型的建模。感觉人物上的建模还是有比较大的改进空间的。出来的形象和原作一般相去甚远。GPT擅长的主要是建筑和场景。对于人物，不是说绝对做不了，就是需要花很多的精力去微操。也许这个问题可以在下一个版本的模型中改进。

在做完了这样的尝试之后，我又在想有没有可能把它推向更复杂的应用。于是我又尝试了两个场景。第一个是动作捕捉。看B站直播的小伙伴可能知道有一位东西叫VTuber。它指的是一种特殊的直播形式。主播在整个过程中不会真人出镜，而是面向摄像头，通过电脑端运行的动作捕捉算法来驱动屏幕上的虚拟形象和观众进行互动。这是一个蛮大的市场，也牵扯到一个非常复杂的技术链条。

一般来说，主播需要先和某些公司签约，由公司为他定制一套三维模型，然后对这个模型进行所谓的骨骼绑定。也就是像人类一样，给这个模型特定的位置埋设关节。通过改变这些关节的位置就可以让模型做出逼真自然的动作。在绑骨之后，就可以结合动捕算法来驱动。具体来说需要对摄像头捕捉到的主播的真人画像进行视觉分析，找到人类的关节位置，再经过一些算法去对动作进行适配，从而让虚拟形象做出和真人一样的动作。

即使不深究里面的技术细节，整个流程也是高度复杂的链条，每一个环节都有一定技术门槛。一般来说，会由不同的人员进行分工。有的负责立绘，有的负责建模/绑骨，有的负责动捕。整个公司再把成品进行交付。为了看AI能不能完整走完整个链条，我让 AI首先针对可达鸭做了一个三维模型，在这个基础上进行绑骨，然后又写了一个浏览器 Web App，进行动作捕捉和模型渲染。当我在浏览器里做出什么动作的时候，屏幕中的可达鸭会跟着我做出一样的动作。大家感兴趣的话可以在这里试试。它非常顺利地完成了整个流程。我录了一段截屏，效果如下所示。

我感觉质量还是挺好的。当然它和真正的人工精雕细琢出来的结果还是有差距，但是考虑到交付的时间和成本比人力的公司好了一两个数量级，我觉得已经蛮惊艳了。在后期加入更多优化以后，可能会更好。

我验证的第二个场景是基于3D建模的AI视频生成。比如我们可以用一两句话就给娃生成一段一两分钟的科普视频。这里用的例子是瓷器烧制的过程。我给了一个相对详细的prompt，让GPT首先调研瓷器烧制的流程是什么样子，然后思考怎么分镜、怎么配旁白、怎么建模。

AI首先进行了调研和分镜，有了分镜之后对相关的形象进行blender建模和关键帧的绘制。这些出来的中间结果保证了成片的物理和形象都是正确合理的。在此之上，它调用了一个挺一般的视频生成模型，我这里用的是Grok Imagine，因为可以嫖SuperGrok的订阅，不用额外花钱。大约过了几小时以后，它生成出来了一个带音效、带旁白的科普视频。如下所示。

考虑到现在AI视频的市场和技术都已经相对成熟，我的这个工作流是没办法和商业工作流竞争的。但是一个很有意思的地方是，它探索了一条道路，把高质量的Blender建模渲染和AI视频生成结合了起来，这个可能可以让视频里面形象和物理上的一致性更好。

在整个过程中，我反复被GPT-6 Astra三维建模的能力惊艳。其实以前我也折腾过这几个东西，包括用OpenSCAD和Blender去建模，但是都还很坎坷。现在同样的场景用GPT-6 Astro，很快很顺利就搞出来了。当然也不是说我们无脑给Prompt就可以拿到很棒的结果。里面有一些思路，尤其是让 AI 能够自我迭代的思路，还有Blender 方面细节的经验教训还是很重要的。我把这些经验教训和方法论都总结了一下，写成了一个 Skill，大家直接用这个 Skill 就可以 reproduce 类似的结果。它已经开源在 GitHub 上，希望对大家有用。

Exploring GPT-6 Astra's 3D Modeling: Exploded Views, Rigging, Motion Capture, and Video Generation

2026-09-05T21:00:00-07:00

Following the release of GPT-6 Astra, plenty of stunning demos started popping up online. Inspired by what I saw, I decided to run a few hands-on experiments to see what compelling use cases this new 3D modeling capability genuinely unlocks.

For my first experiment, I started with a relatively straightforward modeling task: recreating the Hakurei Shrine from Touhou Project in Blender. Here is the exact prompt I used. I dictated it via speech-to-text while sitting in a restaurant, so you will notice several transcription errors. Fortunately, modern AI parses the underlying intent without breaking a sweat:

嗯，我们去试试看哦，就是首先用 Blender 建一个伯利神社，就是东方project 里面的伯利明神社。你得先上网调研一下，它这个神社大概要长什么样，有哪些基本元素，然后你用 Blender 就把它建一下，然后渲渲出一个环视的动画

I did not provide any reference imagery—I simply asked the model to research the shrine online on its own. After roughly half an hour of autonomous work, it generated the model below. Keep in mind that this is a fully realized 3D asset; the image below is just a render from a single perspective.

The output was genuinely impressive. While there are obvious geometric approximations—such as the noticeably low-poly trees—the overall aesthetic, layout, and atmosphere feel charming and faithful to the source material.

With the basic 3D model in place, what cool things could we build on top of it? I am a big fan of a YouTuber whose exploded-view videos are amazing, so I gave GPT a more detailed prompt to generate an exploded-view animation. The plan was to reveal the shrine's internal structural components first, assemble them step by step, and finally populate the diorama base with trees and rocks for a complete showcase. A few dozen minutes later, GPT delivered an excellent result. Here is the video:

That success gave me a serious confidence boost. Given how capable AI has become at coding, my next step was to port the scene into the browser with first-person rendering and collision detection, letting visitors explore and walk through the space freely. The model executed the migration smoothly. An amusing detail along the way: while writing code, the model seemed almost impatient—it called out to Grok to write the code while handling visual verification itself. Whether that was an emergent quirk or deliberate training, the division of labor struck an effective balance between speed and quality. We deployed the result live; if you are interested, you can play with it here. It features three tabs: exploring the virtual scene in first-person, inspecting the entire diorama, and viewing the exploded assembly.

I also tested other categories of 3D modeling. Character modeling, in particular, still leaves plenty of room for improvement, as generated figures tend to stray considerably from the original designs. GPT clearly shines when working on architecture and environmental scenes. Characters are not impossible, but getting them right requires an exhausting amount of manual micro-management. Hopefully, future model iterations will address this gap.

With those initial tests completed, I wondered whether we could push this workflow into more demanding applications. That led to two further experiments. The first was real-time motion capture. Anyone familiar with modern live-streaming has likely run into VTubers—streamers who interact with their audience through digital avatars driven by motion capture instead of appearing on camera in person. It is a massive market backed by an intricate technical pipeline.

Typically, a streamer signs with an agency that commissions a custom 3D model, followed by rigging—embedding virtual bones and joints into the mesh so it can articulate naturally like a human body. Once rigged, motion capture algorithms take over: computer vision analyzes live video from the streamer's webcam, identifies skeletal joint positions, and retargets those movements onto the virtual avatar in real time.

Even without diving into technical minutiae, this workflow is inherently complex, with steep technical hurdles across every phase. Tasks are usually split across specialized roles—concept illustrators, 3D modelers, riggers, and MoCap engineers—before the studio delivers a finished package. To test whether AI could handle this entire chain end-to-end, I had it create a 3D model of Psyduck, rig its skeleton, and build a browser-based web app for real-time motion capture and rendering. Whenever I move in front of my webcam, the on-screen Psyduck mirrors my movements. If you want to try it out, you can test it here. The model pulled off the entire workflow remarkably well. Here is a screen recording of the result:

The quality turned out solid. Naturally, it lacks the hand-crafted polish of an experienced human team, but when you consider that delivery time and production costs dropped by one or two orders of magnitude, it is genuinely remarkable. With further refinements, the results could be even better.

The second scenario I explored was using 3D modeling to drive AI video generation—for instance, turning a sentence or two of prompt into a one- or two-minute educational clip for kids. For this test, I used the porcelain firing process as an example. I gave GPT a detailed prompt asking it to research how porcelain is fired, outline a storyboard, draft narration, and build the required 3D models.

The AI began with research and storyboard planning, then created the corresponding models in Blender and set up keyframes. These structured 3D intermediate assets ensured that physical interactions and visual forms remained coherent throughout the scene. On top of that foundation, it fed the renders into a fairly standard video generation model—I used Grok Imagine here without paying extra, since it's included with my existing SuperGrok subscription. A few hours later, it produced a complete educational video with sound effects and narration. Here is the result:

Given how mature commercial AI video tools have become, this experimental pipeline cannot compete directly with commercial production suites. What makes it interesting, though, is how it charts a path combining grounded Blender modeling and rendering with generative AI video, achieving significantly better visual and physical consistency across shots.

Throughout this process, I was repeatedly blown away by GPT-6 Astra's 3D modeling prowess. In the past, whenever I experimented with OpenSCAD or Blender for programmatic modeling, the experience was filled with friction. With GPT-6 Astra, those same workflows came together quickly and smoothly. That does not mean blindly tossing prompts at the model will produce great results. The underlying methodology—especially structuring autonomous self-iteration loops and managing Blender-specific nuances—remains essential. I compiled these practical lessons and methodologies into a reusable Skill so anyone can reproduce similar outcomes. It is open-sourced on GitHub, and I hope you find it useful.

10小时攻关，半小时Dev Time：在指甲盖大小的单片机上跑神经网络识别车库门

2026-08-01T23:00:00-07:00

分享一个最近的项目。今天午饭的时候我突然想到一个问题，就是家里的车库门是没有装磁控传感器的。之前出现过几次晚上忘关门的事情。因为没有传感器，所以我家安防系统也没有报警。车库门就这么开了一晚上，非常不安全。

我手头正好有一个拇指指甲盖大小的单片机ESP32-CAM（图一），带Wifi，带摄像头，又有一定程度的算力，所以我就在想有没有可能就把这个单片机做成一个传感器。它通过拍照+片上深度神经网络的方式判断车库门是开着的还是关着的。我给它发一个HTTP请求，它就告诉我现在车库门关没关。

这个想法乍一看起来很疯狂。但它的难度比看起来要低。原因是我们要做的不是一个通用的分类器（比如hotdog or not hotdog）来处理各种各样的边界情况。我们在这里想做的是一个非常overfit的分类器。它只要解决我家车库的问题，别人家车库长得再稀奇古怪也没关系。它的位置一旦定下来之后就完全不动，车库门永远在一个地方。甚至它都不需要有太多的泛化智能，就把不同时间段车门开关的样子记下来就行了。我要的就是overfit。

因此我就把这个想法跟AI说了一下。让GPT-5.6 SOL去给我做一下这件事情，给了它我之前接近同机位的监控相机录的像。中间每过一两个小时看一下它的情况，花两到五分钟用语音识别给它下一步的建议。到了晚上我发现它做了这样的事情：

AI做了什么

它首先用自己标注了一组数据。然后发现一个问题：车库门绝大部分的时间是关着的。所以这个分类器要想训练好的核心在于找到足够多的车库门开着的例子。所以它就自己标注了一些初始数据（用的我本地有个Vision LLM，然后它自己用contact sheet复查，见图二。哇感慨一下现在摄影的是不是都不知道什么是contact sheet）。然后训练了一个初始的vision transformer。接着用这个神经网络过了我过去几天的几十万张监控视频帧。找到了更多的车库门没关的例子，再用新数据重新训练，这么来回几次，找到了足够的数据，构建了原始的训练和测试数据。

在这个基础上，它就开始去试着部署到单片机上了。因为单片机的算力极度有限。这里它选用了MobileNet V4，是一个大约九十万个参数的纯卷积神经网络。（想一想现在LLM动不动几百上千亿个参数。这样几十万个参数的模型真的好小巧。）它首先做了个opportunity sizing，用开放的权重测了一下，发现端到端推理要200毫秒左右（相比之下拍照这件事本身需要400毫秒）。温度上升的也不高，用来做零散的推理没问题。接着它就把刚才收集的的训练数据在这个MobileNet V4上进行微调，得到了一个新模型。

这个模型的效果特别好，但还不能直接在部署到单片机上。为了性能需要再进行int8量化。它量化完之后发现一个问题，就是效果下降了很多，甚至有30%以上的分类结果反转了。它觉得这个不能接受。所以在我的建议下用了quantization aware training（QAT）重新训练了一个模型（它选的是LSQ-based QAT）。这下quantization error小很多了AP只掉了八个点（图三）。

接着它又做了一个专门用来测试的固件，烧录到了单片机上，在面跑了一个HTTP server和我们量化好的模型。我们通过HTTP POST给它一个图像，单片机就会去做预处理、推理和后处理，把最终的结果给我们。在这个基础上我们进一步用几百张测试图实测验证了我们对精度、内存、速度和温度的要求都是满足的（一些示例分类结果见图四）。于是最后AI写了一个生产版的固件，每十分钟开一张照片做推理，然后打开WiFi把结果传到我的Mac上。

它还特别提醒我，因为中间单片机处于深度睡眠的状态，电流非常微小，有些充电宝可能会切断电流，单片机就挂了。所以还提醒我去不同的充电宝上测了一下。最终发现有一个充电宝是不会切断电流的。于是就先用这个做了一个临时部署，现在还在采集实际数据，做更多的精度测量。

所以回头想想从中午十二点到晚上十点这十个小时的时间AI干了哪些事情？这不是一个教科书的小demo。它最厉害的是发现这个问题有一些非常独特的挑战。然后真的攻关解决了。比如说数据特别不对称，训练数据很难拿，量化误差太大等等。当然我也不是谦虚，中央的决定也是很重要的。我在方向的把握上也做了一些微小的贡献。但其中任何一个问题对哪怕是senior scientist都是一个坎。事实上如果一个senior scientist可以在一个月里面把整套流程推完，从零开始真的在一个单片机上把神经网络跑起来，我都会觉得相当不错了。但是现在我现在手上就拿着一个真的能摄像能推理的单片机，10个小时，而且整个过程我基本上没干什么事，就是过一两个小时看一眼，给点指示。

我们做了什么

但我讲这些也不是说AI就要取代大家的工作了，或者随便一个人用AI都能做出这样的效果。我也介绍一下我在这里面做的两件最重要的事情是什么。

第一件事是非常强调给AI足够的环境让它能够自我迭代。比如一般的开发流程可能是AI写一个固件烧到单片机里。人去按一个按钮触发拍摄和推理。单片机把结果显示在某一个地方，比如屏幕上。人跟AI说结果怎么样，AI再做下一轮迭代。但在这种开发模式里人需要始终在电脑旁边。因此我在单片机开发skill里面反复和AI强调要尽最大努力打通自我开发的闭环。比如它写一个固件烧录到单片机里，接着从串口发一个指令过去。单片机就会做拍摄、做运算，接着把所有的信息包括温度、延时、计算的结果通过串口发回来。AI拿到这些数据又可以去改进程序，再一次烧录。就可以全自动地往前走了。费劲去写一个人用不上，只有AI能用上的特殊版固件，对于传统开发来说完全是浪费时间。但是对于AI自主开发来说，这是最关键的一点，让我可以用极大的杠杆率花五分钟的时间就撬动AI几个小时的干活。

第二件事是给AI技术指导。比如我会事先想好这里面有什么坑，而且跟它说怎么做。比如车库门分离器训练的难点在于不对称的训练数据。这个是我一开始就跟它讲好的。所以它就没有走弯路，直接从问题的核心开始着手解决。怎么解决也是我给它建议：用local LLM去做标注，你来做复核。QAT也是我看到quantization loss太大给它建议的。这里最关键的一点是，我百分之八九十的精力都花在这些最技术的事情上面，而不用天天想着influence without authority，作为IC跟小弟们开会，跟领导拍胸脯，align整个组去照我说的做。终于可以把时间花在自己又擅长又享受的事情上面。这是我觉得最开心的一点。

所以这几年我对AI时代人要怎么适应的判断从来没变过。就是我们码农就好像人力船上的划桨手一样。不论是学校训练还是公司升职用的标准都是看你划桨划得快不快。但AI像蒸汽机一样进来把桌子直接掀了。你划得再快，吃得再少也没有AI 24x7跑得快。但这并不意味着AI就不需要人类了。人跟人之间的差距从以前谁划桨划得快，变成了谁能让AI尽可能长时间地自主工作，而不用老停下来休整，被人拖累。但这是一个全新的技能，甚至和以前划桨划得好不好是相冲突的。因此，只有先尽快地忘却那些根深蒂固的肌肉记忆，积极去拥抱新时代的价值观，才有可能在速度上进行数量级的提升。当然在这个新前提下，往哪划可能比划得多快更重要。但怎么去提升认知，知道往哪划就是另一个故事了。

10 Hours of AI Collaboration, 30 Mins of Dev Time: Running a Neural Network on a Thumb-Sized Microcontroller for Garage Door Recognition

2026-08-01T22:00:00-07:00

Sharing a recent project. Today during lunch, I suddenly realized an issue: my home garage door doesn't have a magnetic contact sensor installed. We've had a few instances where we forgot to close the garage door at night. Because there was no sensor, our security system couldn't trigger an alarm, leaving the garage door open all night—which is extremely unsafe.

I happened to have a thumb-sized microcontroller on hand, an ESP32-CAM (Figure 1), equipped with Wi-Fi, a camera, and a decent amount of compute (dual-core 240 MHz). So I wondered: could I turn this microcontroller into a sensor itself? By using photo capture paired with an on-chip deep neural network, it could classify whether the garage door is open or closed. Whenever I send it an HTTP request, it tells me right away if the garage door is shut.

This idea might sound crazy at first glance, but the actual difficulty is lower than it seems. The reason is that we aren't trying to build a general-purpose classifier (like "hotdog or not hotdog") that needs to handle endless edge cases. What we want here is a hyper-overfitted classifier. It only needs to solve the problem for my specific garage; it doesn't matter how weird anyone else's garage looks. Once the device position is fixed, it never moves, and the garage door remains in the exact same spot. It doesn't even need high generalization intelligence—it just needs to memorize what the door looks like open vs. closed under different lighting conditions. Overfitting is precisely what I want.

So I explained this idea to AI and assigned the task to GPT-5.6 SOL, feeding it past security camera footage recorded from nearly the same angle as training data. Every hour or two, I checked in on its progress for two to five minutes, giving next-step guidance via voice recognition. By evening, I discovered it had accomplished the following workflow:

What AI Did

First, it annotated a batch of initial data on its own. Soon after, it identified and confirmed a core problem: the garage door is closed the vast majority of the time. To train an effective classifier, the key was finding enough positive examples where the garage door was open. So it annotated some initial samples (using a local Vision LLM, then double-checking them itself using a contact sheet, see Figure 2. On a side note: I wonder if many photographers today even know what a contact sheet is!). Next, it trained an initial Vision Transformer, then ran this neural network across hundreds of thousands of video frames from my past few days of security footage to mine more instances of open garage doors. It then retrained the model on the newly augmented data. Repeating this loop a few times, it gathered sufficient and balanced data to build a complete training and testing dataset.

Building on this dataset, it moved on to training and deploying to the microcontroller. Given the extremely constrained compute on the chip, it selected MobileNetV4—a pure convolutional neural network with roughly 900,000 parameters. (Considering today's LLMs routinely reach tens or hundreds of billions of parameters, a model with a few hundred thousand parameters feels delightfully compact.) It first ran an opportunity sizing test using open weights, discovering that end-to-end inference took only ~200 milliseconds (compared to 400 milliseconds just to capture a photo). Thermal rise was minimal, making it completely viable for sporadic inference. It then fine-tuned MobileNetV4 on the newly collected training data to produce a custom model.

The fine-tuned model performed remarkably well, but it couldn't be deployed directly onto the microcontroller yet. For performance and memory efficiency, it needed to be quantized to int8. After quantizing, the AI noticed a major problem: model accuracy degraded significantly, with over 30% of classification outputs flipping incorrectly. Seeing this as unacceptable, it adopted Quantization-Aware Training (QAT) at my suggestion to retrain the model (specifically choosing LSQ-based QAT). This dramatically reduced quantization error, bringing the AP drop down to just 8 percentage points (Figure 3).

Next, it built a dedicated testing firmware, flashed it to the microcontroller, and ran an HTTP server alongside the quantized model on-chip. Whenever we sent an image via HTTP POST, the microcontroller handled preprocessing, inference, and postprocessing, returning the final verdict. Using this setup, we further validated hundreds of test images, confirming that accuracy, RAM usage, latency, and thermal limits all met our requirements (see Figure 4 for sample classification outputs). Finally, the AI wrote the production firmware: capturing a photo every 10 minutes for inference, then enabling Wi-Fi to push the result back to my Mac.

It also gave me a helpful heads-up: because the microcontroller spends most of its time in Deep Sleep where current draw is microscopic, some power banks with smart auto-off protection might misinterpret this low load and cut off power, bricking the device. So it suggested I test across different power banks. I eventually found one that doesn't auto-shut off and used it for a temporary deployment, which is currently collecting real-world data for long-term precision evaluation.

Looking back, what did AI actually accomplish during those 10 hours from noon to 10 PM? This was no textbook toy demo. Its impressive feat was identifying a set of distinct engineering challenges unique to this project and actually solving them—such as severe data imbalance, scarce negative samples, and severe quantization loss. Of course, not to be overly modest, leadership direction was also critical—I contributed a modest share in keeping the overall trajectory on track. But any single one of these hurdles would present a real bump for even a senior scientist. Honestly, if a senior scientist could complete this entire pipeline from scratch in a month—getting a neural network actually running on a chip—I'd consider that quite impressive. Yet today, I hold a camera-equipped, inference-capable microcontroller in my hand after just 10 hours, having spent virtually no manual labor beyond checking in every hour or two to offer high-level direction.

What We Did

In sharing this, I'm certainly not implying that AI is about to replace everyone's job, or that anyone can trivially achieve this result with AI. Let me highlight the two most important contributions I made in this process:

First, aggressively building an environment for AI that enables autonomous self-iteration. A conventional hardware workflow often looks like this: the AI writes firmware and flashes it, a human manually pushes a button to trigger capture and inference, the microcontroller outputs results to a display, and the human feeds observations back to the AI for the next iteration. In that model, the human remains tethered to the computer. That's why in my microcontroller development Skill, I repeatedly emphasize to the AI that it must close the loop for automated self-development. For instance, after flashing firmware, the AI sends a serial command; the chip automatically takes a picture and computes inference, returning complete telemetry—including temperature, latency, and prediction results—via serial. The AI ingests this telemetry, diagnoses issues, refines its code, and re-flashes autonomously. Going through the trouble to write a special version of firmware that humans don't need and only AI uses would be a total waste of time in traditional development. But for autonomous AI development, this is the single most critical point, allowing me to leverage five minutes of guidance to unlock hours of high-intensity AI execution.

Second, providing core technical guidance at critical decision nodes. I anticipated where the major pitfalls lay and gave the AI explicit strategies up front. For example, knowing that extreme data imbalance was the primary bottleneck for this garage classifier, I highlighted it right from the start so the AI didn't waste time going down dead ends. The solution strategy also came directly from me: use a local Vision LLM for initial labeling, then review the results itself. When quantization loss proved too severe, I immediately suggested switching to QAT. Crucially, 80% to 90% of my cognitive effort was focused purely on these high-leverage technical decisions—without spending days on "influence without authority," holding endless meetings as an IC, promising deliverables to leadership, or managing team alignment. Being able to spend my time entirely on technical work I'm both good at and enjoy is what brought me the most joy.

That's why over the past few years, my view on how humans should adapt in the AI era hasn't changed: programmers used to be like rowers on a human-powered boat—whether in university training or corporate promotions, the metric was always how fast you could paddle. But AI came in like a steam engine and completely flipped the table: no matter how fast you paddle or how little you eat, you can never outrun a machine operating 24x7. But this doesn't mean humans are obsolete. The gap between individuals has shifted from "who paddles faster" to "who can keep AI working autonomously for the longest stretches without constantly stopping or being slowed down by human intervention." This is an entirely new skill set, and one that often conflicts with old paddling muscle memory. Only by shedding ingrained habits and embracing new AI-native paradigms can we achieve order-of-magnitude leaps in delivery speed. In this new paradigm, "where to steer" matters far more than "how fast to paddle"—though how to build the intuition to know where to steer is a story for another day.

使用AI暴力模拟月全食的绿松石带

2026-06-22T22:00:00-07:00

在上一篇文章里，我们利用电脑模拟渲染出了以假乱真的星空图片。这种模拟给了我们很多实拍所没有的超能力，比如星空漫游、时间加速、模拟不同光污染和视觉敏感度下的银河与星空。在这篇文章里，我们用同样的思路来探索一下月全食时候的绿松石带。

熟悉天文的同学对这个应该不陌生。在月全食的时候，月面不是全黑，而是呈现非常暗的古铜色。但是当月亮逐渐变亮、复圆的时候，如果仔细拍摄地球本影的边缘，会发现它不是红色也不是白色，而是一层青蓝色，就好像绿松石的颜色一样，所以叫绿松石带。

如果你去搜索为什么有这样一条青绿色的窄带，往往会得到和臭氧层相关的答案：这个环带内的光主要来自经臭氧层折射的阳光，臭氧会强烈地吸收黄橙光，因此造就了绿松石带。但如果我们沿着这条思路仔细思考的话会发现有蛮多对不上的地方。比如为什么绿松石带这么窄？经臭氧层折射的光，角径应该和太阳在一个量级，也就是 32 角分左右，文献里却只有两角分左右？同时，如果我们真的去看臭氧的吸收光谱的话，会发现它对红橙光的吸收是蓝紫光的将近 100 倍，出来的颜色应该是饱和的蓝绿色。但是实际上绿松石带非常难拍，蓝绿的颜色非常淡。

这些问题让我觉得里面有很多机理我并没有理解透彻。就好像我们在上篇文章中，每一个翻过的车都指向了我们对一些司空见惯的现象其实并没有理解。比如为什么亮星看起来更大？为什么数值模拟显示我们应该在九级光污染的地区也能看见银河，但实际上看不见？这些模拟与现实的矛盾逼着我们去发现了新的知识。

对于绿松石带也是一样。在这篇文章里我们也会一步步用最简单的数值模拟：光的折射、散射、吸收、直线传播来真的把绿松石带的颜色和位置计算出来，并且和实际的观测与文献进行对比。这也是一个不断翻车的旅程，而每一次翻车都会教会我们新的知识。

从一个白圆盘开始

所以我们就回到起点。月亮是一个灰白的圆盘，上面有些月海的暗斑（这些纹理可以在 NASA 官网下载到）。太阳是点光源，光打在月亮上反射出来，于是我们得到了一轮满月。这没什么稀奇的。

图一：起点——有月面纹理的灰白圆盘，还没有任何大气物理

现在月食发生了：地球挡在太阳和月亮之间。如果地球只是一块不透光的石头，月亮上被挡住的那一半就是黑色，没挡住的一半是正常月光白，中间一条硬边。这就是图二。（图像经过了简单亮度后期来在普通显示器上正常显示，下同）

图二：加入几何遮挡——一半纯黑一半纯白，硬边，没有大气

但月食时月亮并不是全黑的。这是因为地球有大气。阳光擦过地球边缘的大气时会折射弯进来，照亮那些本该全黑的区域。这束光在大气里是擦着边缘掠过去的，所以穿透的大气厚度是垂直方向的几十倍。走这么长的路，光会被严重吸收和散射。

这里我们先把最基础的散射加进来：瑞利散射，就是让天空变蓝的那个机制。瑞利散射的强度和波长的四次方成正比，所以蓝光被散射得最厉害。当阳光斜穿几十倍厚的大气时，蓝光几乎被散尽，只剩红光穿透。于是暗部亮了起来，而且变成了古铜红色。血月出来了。

图三：加入瑞利散射——本影不再全黑，血月红出现

到这里还一切顺利，我们看到了熟悉的血月。但下一步就出问题了。现在，我们加入臭氧的吸收。臭氧有一个吸收带叫 Chappuis 带，波长大概在 500 到 700 纳米，正好吃掉橙红光。我们加入了这个吸收带，青绿色真的出来了，而且和文献/直觉预期的一样，是一条很浓的青带（图四）。红蓝比到了 0.53，青得发亮。

图四：加入臭氧 Chappuis 吸收——青带出现了，但比真实浓得多、宽得多

问题是，这条带太浓了。真实月食照片里的绿松石带是淡淡的、窄窄的一丝，需要HDR+大幅后期才能看出来。这么明显的蓝色条带一眼假，肯定有问题。然而，我们的计算在物理上好像没漏什么，散射有了、折射有了、臭氧吸收有了，但出来的结果就是和真实观测对不上。

近似藏在哪里

我在这里卡了很久。反复检查代码，检查数据，都没找到错。直到我发现问题不在物理上，而出在一个我根本没意识到它是个近似的近似上：我们把太阳当成了点光源。

真实太阳是一个有 32 角分角径的圆盘，不是无限远的点。当我们把太阳当点源算的时候，每个月面位置只被一条光线照亮，对应一个确定的擦边高度。擦边高度落在臭氧层附近时，出来的就是鲜艳的蓝色。但真实情况是，太阳圆盘上不同位置的点发出的光，擦过地球大气的位置是不一样的，照到同一个月面位置的光来自一束不同擦边高度的光线，有的来自臭氧层，但更多的不是。

这种情况下，学术界通用的做法是，先用点源近似推公式，最后再加一个几何补偿。比如2022年 Mallama 关于月食建模的综述，用的是"for a point source of light"的假设，用点源假设推导整套折射公式，然后最后加了个几何补偿比如模糊处理。但我跟着论文的方法适配到我们的场景里，结果怎么都不对（本影亮度不符合观测）。

直到最后我终于放弃了，又回到了上一篇文章以力破巧的思路，不做公式推导，不做几何补偿，而是针对太阳的所有点做多重积分。取很多很多点，模拟发出来的很多光线。然后对每条光线做追踪，计算折射散射吸收，终于看到了真实的亮度和颜色。这个多重积分一做，立刻把那条浓青带稀释了：原本点源算出来的最蓝处红蓝比 0.53，加入太阳圆盘之后变成了 0.71。青色变淡了，带变宽变软了，位置也往内移了。这才是真实月食看到的样子。

图五：加入太阳圆盘——浓青被糊成浅青软边，接近真实观测

这其实引出了一个更大的问题。天体物理这类科学计算，几十年来形成了一种工作方式，我称之为“近似的艺术”。一个现象解起来太难，就做一阶展开只看前两项。某处发散了，就加一个修正项。这个修正项又带来别的偏差，再加一层修正。每加一层近似都需要深刻的物理直觉和踩坑经验才能保证又简单又快又对。这套做法在超算机时按小时计费、一个博士的时间比算力还贵的年代，是非常合理的策略。会做近似在当年是真本事。

但近似有一个隐藏代价：每个近似都引入一个人为参数，这些人为参数会互相打架。一个近似在某处发散，加一个补丁去补；这个补丁在另一个地方带来其他偏差，再加一层。到最后误差来自物理还是来自某几个近似的相互作用，就分不清了。我们在月食这个项目里踩的就是这个坑。我们用了四五个相关的近似，每一个都是文献里有出处、看起来合理的近似。但叠在一起，本影中心的亮度算出来比真实偏亮了 6 档——也就是 250 倍。这种偏差很难定位是哪一层近似造成的，因为它们纠缠在一起了。

和 AI 搏斗

在AI时代之前，我就会止步于此了。因为我又不擅长物理，又不擅长计算。没有这样的物理直觉。实际上在一年前，我也试过用 AI 来做这样的事情，也是因为这个原因没有做出来：太多物理上的决策要做，每一个决策点我都得去理解前人为什么这么近似、这个近似在什么条件下成立、去掉它会发生什么。AI 会给我一段代码，但我连这段代码里的近似藏在哪里都看不出来。

但今年我突然意识到一个问题：反正现在代码都是 AI 写的，为什么我们还要做这些近似呢？为什么就不能从最原始的光线追踪出发，老老实实把太阳的每个像素、大气的每层高度、光谱的每个波长，到本影中心的每个距离都做一轮循环？我们就老老实实发很多光线出去，让它自己折射、吸收、散射、汇聚，不做任何高级的近似，就死算。这样一方面底层的物理原理非常清晰简单，犯错的概率小很多；另一方面，把这些东西写出来并且做性能优化，比如转成 GPU 上跑的代码，是 AI 非常擅长的东西。CPU 上跑一次，GPU 上跑一次，两边结果一样，就说明它肯定是正确的，也很容易测试验证。

那为什么我还犯了很多错呢？主要是因为 AI 物理太好了，它在做了文献调研之后，经常条件反射地跟随前人的脚步，用物理直觉去近似处理，结果又把我带坑里了。所以我大多数的时间其实是在跟 AI 搏斗，一层一层发现这里又藏了一个物理近似，那里又藏了一个物理近似，最终把它改成最简单最暴力的版本。

具体到这个项目，我们的最后一步是把一个近似 focusing 因子整个删掉。focusing 是指擦过地球边缘的光线被大气折射弯进来之后会在本影里汇聚，使本影中心比边缘亮。文献里的做法是用一个解析公式 1/r 来近似这个汇聚效果，再硬设一个 r_floor 下限去补它在中心的无穷大发散。我们一开始也用了这个公式。但问题是，focusing 本来就是光线追踪的自然产物：你撒出足够多的光线，让它们各自折射落点，落点的密度自然就是亮度，不需要任何公式。我们用了公式就是在用人为的闭式解去代替统计涌现，于是本影中心偏亮了。删掉 focusing 公式，改成纯撒光线落点分箱，本影中心从 −7.7 档直接暗到了 −13.1 档——和真实月食深食的 −14 到 −19 档已经在一个数量级上了。剩下的差距是真实大气里的气溶胶和云，不是数值问题。

图六：真·光线追踪 RTX ON ——focusing/落点/亮度全部从撒线涌现，零解析处方

两个反直觉问题的答案

算到这里，回头来看一开始那两个问题。

为什么绿松石带是一条窄带而不是一大片？答案在亮度上，不在颜色上。颜色（红蓝比）沿月盘其实是平滑渐变，跨了十几角分，没有突变。但最蓝的那一段恰好也是整条曲线上最暗的一段——亮度只有月盘最亮处的 4.5%。人眼看不见。它旁边紧贴着的是出本影的正常月光区，亮了整整 250 倍，白色的强烈月光又把青蓝色完全淹没了。我们看到的绿松石带不能太暗，不能太亮，还要够蓝，在视觉上就被压成了一道细带。

图七：亮度悬崖——最蓝处同时是最暗处，被旁边趋白区盖过，只剩一道细带

为什么全食最深的时候反而没有绿松石带？因为深食时月亮在本影正中心，照亮它的阳光擦边高度极低，瑞利散射把蓝光散尽只剩红，血月最红最暗。青色要出现在擦边高度升到平流层的那一段——那里瑞利散射退居次要，臭氧的 Chappuis 吸收开始主导，把橙红吸收留下青绿光。但平流层对应的是本影边缘，不是中心。所以绿松石带只在月亮往本影边缘移动、亮度悬崖开始出现的时候才看得见。全食最深的中心位置，整张月盘都在瑞利的红区里，臭氧的青根本没有投射过去。

暴力为什么现在可行

讲到这里，我想退一步说一个更一般的事情。

过去做这类科学计算，近似是美德。超算机时按小时计费，写程序的博士们技能点在物理直觉上而不在软件工程上，用物理近似换取更少更快的计算是理性的。但这个成本结构在 AI 时代倒挂了。AI 既懂物理又懂编程，推折射公式、写 GPU kernel 都是几分钟的事。同时个人电脑就能撒几百万条光线，运行时间也不再是瓶颈。所以这时候"近似的艺术"就从美德变成了阻碍。暴力的第一性原理方法现在又快又对，而且没有人为参数互相掩盖的问题，反而效果最好。

这不是说前人做错了。他们做的是在当时的约束下最优的选择。Mallama 2022 那篇综述的点源假设、闭式折射公式、1/r focusing，每一项都是算力预算下的合理近似。甚至 García Muñoz 和 DLR 的 2025 年工作，在算力已经不稀缺的年代仍然选半解析，是为了物理可解释性或者实时渲染。只是我们要警惕，近似的惯性不会自动消失。当约束解除之后，不近似是一种非常可行且假设更少的替代方案。

另外我想澄清一点，我们想推动的不是暴力计算万能论。人力有时而穷，如果坚持原教旨主义，不做任何近似，很快我们仍然会撞上算力这堵墙。我想强调的是，这不是一个非黑即白的问题。在AI能力强、电脑算力强的2026年，我们在做科学计算的时候，不妨多考虑一些跳过近似的技术途径。

月球人看到的日全食长什么样

和上一篇文章一样，模拟链路跑通之后，它可以做很多实拍做不到的事情，比如可以改参数去探索。

一方面我们可以算出来地球上看到的月球，但因为我们是完全暴力模拟的，换个积分的维度，我们自然也可以看到月球人的视角。因此我们做了一个视频，展示从月球看地球的样子。注意月食的时候，站在月亮上的人看到的是地球完全挡住太阳，也就是地球上的日全食。地球的黑夜面上一圈折射光点亮的大气环，颜色从内圈红到外圈青再到白，正好是日落剖面展开成一圈。随着月亮移出本影，太阳从地球边缘探出来，大气环一侧越来越亮，最后变成钻石环。这整段画面就是前面那套辐射传输的同一个物理，只是换个视角而已。

月食对偶视角视频：左月球（随月亮移出本影）| 中地球全景 | 右大气环特写

我们也做了光度曲线，把月面从本影中心到满月的亮度变化画出来。本影中心暗到 −15 档，然后一路缓升到本影边缘的亮度悬崖，再平滑爬升到满月的 0 档。这条曲线本身就是一张诊断图：如果你发现某个地方有跃变，那一定是物理上缺了一块。我们中间就发现出本影的地方有个假跃变，追下去是半影区的直射光没建模——太阳从地球边缘探头照过来的那部分光。老实把它 ray trace 进去，跃变就消失了。

图八：光度曲线——本影中心 −15 档到满月 0 档，亮度悬崖在 41 角分处

所有这些结果、代码、渲染脚本，我都放在了项目主页上，也欢迎大家自己玩玩。

最后

我们一路翻了很多次车，但每次翻车都纠正了一个不准确的理解。点源近似让我们误以为绿松石带很浓，focusing 公式让本影中心偏亮 250 倍。每一次"看着差不多"的诱惑，正解都是回到物理去查漏了什么。中间有好几次，我看到算出来的青色太浓，本影太亮，很想调一下臭氧浓度或者加个气溶胶让它暗起来。但每次都忍住了。最后算出来的那条淡青窄带，和 GOES-16 卫星的实测、Shu 2024 的遥感数据逐条对上的时候，我觉得忍住是对的。

Simulating the Lunar Eclipse Turquoise Band with Brute-Force AI

2026-06-22T22:00:00-07:00

In the previous article, we used computer simulation to render a photorealistic image of the night sky. That kind of simulation gives us superpowers that real photography cannot: sky roaming, time acceleration, and simulating the Milky Way and star fields under different light pollution and visual sensitivity. In this article, we apply the same approach to the turquoise band during a total lunar eclipse.

Anyone familiar with astronomy has probably heard of it. During a total lunar eclipse, the moon is not fully black; it turns a very dark bronze color. But as the moon gradually brightens and returns to full phase, if you carefully photograph the edge of Earth's umbra, you will find that it is neither red nor white, but a layer of cyan-blue — the color of turquoise, hence the name turquoise band.

If you search for why this narrow green-blue band exists, you will usually get an answer involving the ozone layer: the light in this ring mostly comes from sunlight refracted through the ozone layer, and ozone strongly absorbs yellow-orange light, which creates the turquoise band. But if you think carefully along this line of reasoning, quite a few things do not add up. For example, why is the turquoise band so narrow? Light refracted through the ozone layer should have an angular size on the same order as the Sun, about 32 arcminutes, yet the literature gives only about 2 arcminutes. Also, if you look at the ozone absorption spectrum, its absorption of red-orange light is nearly 100 times stronger than blue-violet light, so the color should be a saturated blue-green. In practice, the turquoise band is very hard to photograph, and the blue-green color is extremely faint.

These questions made me feel that I had not really understood the underlying mechanisms. Just as in the previous article, every failure pointed to something we take for granted but had never truly understood. Why do bright stars look larger? Why does numerical simulation say we should still see the Milky Way under Class 9 light pollution, yet we cannot in reality? The gap between simulation and observation forces us to discover new knowledge.

The turquoise band is the same. In this article we will step through the simplest numerical simulation — refraction, scattering, absorption, and straight-line propagation — to actually compute the color and position of the turquoise band, and compare the results with real observations and the literature. This, too, is a journey of repeated failures, and each failure teaches us something new.

Starting from a White Disk

So we go back to the beginning. The moon is a gray-white disk with some dark maria (these textures can be downloaded from NASA). The Sun is a point source. Light hits the moon and reflects back, giving us a full moon. Nothing surprising here.

Figure 1: Starting point — a gray-white disk with lunar texture, no atmospheric physics yet

Now a lunar eclipse happens: Earth blocks the Sun and the moon. If Earth were just an opaque rock, the blocked half of the moon would be pure black, the unblocked half normal moonlight white, with a hard edge between them. That is Figure 2. (The images have simple brightness processing so they display normally on ordinary monitors; same below.)

Figure 2: Geometric occlusion — half black, half white, hard edge, no atmosphere

But during a lunar eclipse the moon is not fully black, because Earth has an atmosphere. Sunlight grazing Earth's edge is refracted inward and illuminates regions that should be completely dark. This light travels tangentially through the atmosphere, so the path length through air is dozens of times longer than a vertical path. Over such a distance, light is heavily absorbed and scattered.

Here we add the most basic scattering first: Rayleigh scattering, the mechanism that makes the sky blue. Rayleigh scattering scales with the fourth power of wavelength, so blue light is scattered most strongly. When sunlight passes obliquely through dozens of times the atmospheric thickness, blue light is almost completely scattered away, leaving only red to penetrate. The dark region brightens and turns bronze-red. The blood moon appears.

Figure 3: Rayleigh scattering added — umbra no longer fully black, blood moon red appears

Up to here everything goes smoothly; we see the familiar blood moon. Then the next step goes wrong. We add ozone absorption. Ozone has an absorption band called the Chappuis band, roughly 500 to 700 nanometers, which eats orange-red light. After adding this band, green-blue really appears, and just as the literature and intuition would predict, it is a very strong cyan band (Figure 4). The red-to-blue ratio reaches 0.53 — dazzlingly cyan.

Figure 4: Chappuis ozone absorption added — cyan band appears, but much stronger and wider than reality

The problem is that this band is too strong. In real lunar eclipse photos, the turquoise band is a faint, narrow thread visible only with HDR and heavy post-processing. Such an obvious blue stripe looks fake at a glance; something must be wrong. Yet our calculation seems to miss nothing in physics: we have scattering, refraction, and ozone absorption, but the result still does not match real observation.

Where the Approximations Hide

I was stuck here for a long time. I checked the code and the data repeatedly and found nothing wrong. Eventually I realized the problem was not in the physics, but in an approximation I had not even recognized as an approximation: we treated the Sun as a point source.

The real Sun is a disk 32 arcminutes across, not a point at infinite distance. When we treat the Sun as a point source, each point on the lunar surface is lit by a single ray, corresponding to one definite grazing height. When that height falls near the ozone layer, the result is vivid blue. But in reality, different points on the solar disk send light that grazes Earth's atmosphere at different heights. Light reaching the same point on the moon comes from a bundle of rays at different grazing heights — some from the ozone layer, but most not.

The standard academic approach is to derive formulas with a point-source approximation first, then add a geometric correction at the end. For example, Mallama's 2022 review of lunar eclipse modeling uses a "for a point source of light" assumption to derive the full refraction formulas, then adds geometric corrections such as blurring. I adapted that approach to our scenario, but the results never worked (umbra brightness did not match observation).

In the end I gave up and returned to the brute-force approach from the previous article: no formula derivation, no geometric correction, but a full multi-dimensional integral over all points on the solar disk. Take many, many points, simulate many rays from each, trace each ray with refraction, scattering, and absorption, and finally see the true brightness and color. This integral immediately diluted that strong cyan band: the bluest point from the point-source calculation had a red-to-blue ratio of 0.53; after adding the solar disk it became 0.71. The cyan faded, the band widened and softened, and its position shifted inward. This is what a real lunar eclipse looks like.

Figure 5: Solar disk added — strong cyan smeared into soft pale cyan, close to real observation

This raises a bigger question. Scientific computing in astrophysics has, for decades, developed a working style I call "the art of approximation." A phenomenon is too hard to solve, so take a first-order expansion and keep only the first two terms. Something diverges, add a correction term. That correction introduces new bias somewhere else, so add another layer. Each approximation requires deep physical intuition and hard-won experience to stay simple, fast, and correct. When supercomputer time was billed by the hour and a PhD's time cost more than compute, this was a very rational strategy. Being good at approximation was a real skill back then.

But approximation has a hidden cost: each one introduces a free parameter, and those parameters fight each other. One approximation diverges somewhere; add a patch. The patch causes bias elsewhere; add another layer. In the end you cannot tell whether error comes from physics or from the interaction of several approximations. We hit exactly this trap in the lunar eclipse project. We used four or five related approximations, each with a citation in the literature and each looking reasonable on its own. Stacked together, the brightness at the center of the umbra came out 6 stops — 250 times — brighter than reality. It is very hard to locate which layer caused the bias, because they are entangled.

Wrestling with AI

Before the AI era, I would have stopped here. I am neither strong in physics nor in computation. I do not have that kind of physical intuition. A year ago I also tried to use AI for this kind of problem and failed for the same reason: too many physical decisions, and at each decision point I had to understand why predecessors approximated the way they did, under what conditions the approximation holds, and what happens if you remove it. AI would give me code, but I could not even see where the approximations were hiding.

This year I suddenly realized: if AI is writing the code anyway, why keep all these approximations? Why not start from raw ray tracing and honestly loop over every pixel on the Sun, every height layer in the atmosphere, every wavelength in the spectrum, and every distance to the center of the umbra? Send out many rays, let them refract, absorb, scatter, and converge on their own — no clever shortcuts, just brute force. The underlying physics stays clear and simple, so the chance of error is much smaller. And turning this into performant code, say GPU kernels, is something AI is very good at. Run once on CPU, once on GPU; if the results match, the implementation is almost certainly correct and easy to verify.

So why did I still make many mistakes? Mainly because AI knows physics too well. After literature review it reflexively follows predecessors' footsteps and applies physical intuition through approximations — and leads me into traps again. Most of my time went into wrestling with AI, discovering one hidden physical approximation after another, and finally rewriting everything into the simplest, most brute-force version.

In this project, the last cut was removing an approximate focusing factor entirely. Focusing means that rays grazing Earth's edge, refracted inward by the atmosphere, converge inside the umbra and make the center brighter than the edge. The literature approximates this with an analytic 1/r formula and a hard r_floor floor to patch its infinite divergence at the center. We used that formula at first. But focusing is a natural outcome of ray tracing: scatter enough rays, let each refract to its landing point, and the density of landing points is the brightness — no formula needed. Using a formula means replacing statistical emergence with a hand-built closed form, so the umbra center came out too bright. Remove the focusing formula and use pure ray landing bins instead, and the center drops from −7.7 stops to −13.1 stops — already in the same order of magnitude as real deep totality at −14 to −19 stops. The remaining gap is aerosols and clouds in the real atmosphere, not a numerical problem.

Figure 6: True forward ray tracing — focusing, landing points, and brightness all emerge from scattered rays, zero analytic prescriptions

Answers to Two Counterintuitive Questions

At this point, let us return to the two questions from the beginning.

Why is the turquoise band a narrow strip rather than a broad patch? The answer lies in brightness, not color. The color (red-to-blue ratio) varies smoothly across the lunar disk over more than ten arcminutes, with no sharp jump. But the bluest segment is also the darkest on the entire curve — only 4.5% as bright as the brightest part of the disk, too faint for the eye to see clearly. Right beside it is the normal moonlight region outside the umbra, 250 times brighter; intense white moonlight completely swamps the cyan-blue. The turquoise band we see must be neither too dark nor too bright, and blue enough — visually it is squeezed into a thin line.

Figure 7: Brightness cliff — the bluest region is also the darkest, overshadowed by the bright white zone next to it, leaving only a thin band

Why does the turquoise band disappear at deepest totality? During deep totality the moon sits at the center of the umbra. The sunlight reaching it grazes at very low height; Rayleigh scattering scatters away blue light and leaves only red — the blood moon is reddest and darkest. Cyan appears when grazing height rises into the stratosphere — where Rayleigh scattering becomes secondary and ozone Chappuis absorption dominates, eating orange-red and leaving blue-green. But the stratosphere corresponds to the edge of the umbra, not the center. So the turquoise band is visible only when the moon moves toward the umbra edge and the brightness cliff begins to appear. At the deepest center of totality, the entire disk sits in Rayleigh's red zone; ozone's cyan never gets a stage.

Why Brute Force Works Now

Stepping back, I want to say something more general.

In scientific computing of this kind, approximation used to be a virtue. Supercomputer time was billed by the hour; PhDs who wrote programs had their skill points in physical intuition rather than software engineering; trading physical approximation for less and faster computation was rational. But that cost structure has inverted in the AI era. AI knows both physics and programming; deriving refraction formulas and writing GPU kernels takes minutes. A personal computer can scatter millions of rays; runtime is no longer the bottleneck. So "the art of approximation" turns from virtue into obstacle. Brute-force first-principles methods are now fast, accurate, and free of mutually masking free parameters — often the best approach.

That does not mean predecessors were wrong. They made optimal choices under their constraints. Mallama 2022's point-source assumption, closed-form refraction, and 1/r focusing were each reasonable approximations under a compute budget. Even García Muñoz and DLR's 2025 work, in an era when compute is no longer scarce, still chose semi-analytic methods for physical interpretability or real-time rendering. We should stay alert: the inertia of approximation does not disappear on its own. When constraints lift, skipping approximation is a very feasible alternative with fewer assumptions.

One clarification: we are not pushing brute-force computing as a universal doctrine. Human effort has limits; if you insist on fundamentalism and refuse all approximation, you will hit the compute wall again soon. The point is that this is not black and white. In 2026, with strong AI and strong machines, it is worth considering technical paths that skip approximation when doing scientific computing.

What a Lunar Eclipse Looks Like from the Moon

As in the previous article, once the simulation pipeline works, it can do many things real photography cannot — for example, explore by changing parameters.

We can compute the moon as seen from Earth; because our simulation is fully brute-force, we can swap the integration dimension and see the view from the moon. So we made a video showing Earth as seen from the moon. During a lunar eclipse, someone standing on the moon sees Earth completely blocking the Sun — a total solar eclipse on Earth. A ring of refracted light lights up the atmosphere on Earth's night side, color running from red on the inner edge through cyan to white on the outer edge — a sunset profile wrapped into a circle. As the moon moves out of the umbra, the Sun peeks from Earth's edge, one side of the atmospheric ring brightens, and finally becomes a diamond ring. The whole sequence is the same radiative transfer physics as before, just a different viewpoint.

Dual-view eclipse video: left — moon (moving out of umbra) | center — Earth panorama | right — atmospheric ring close-up

We also plotted a photometric curve: lunar surface brightness from the center of the umbra to full moon. The center is at −15 stops, then rises gradually to the brightness cliff at the umbra edge, then smoothly climbs to 0 stops at full moon. This curve is itself a diagnostic: if you see a jump somewhere, a piece of physics is missing. We once found a spurious jump leaving the umbra; tracing it down, direct sunlight in the penumbra was not modeled — light from the Sun peeking around Earth's edge. Ray trace that honestly and the jump disappears.

Figure 8: Photometric curve — umbra center at −15 stops to full moon at 0 stops, brightness cliff at 41 arcminutes

All results, code, and rendering scripts are on the project homepage. Feel free to play with them.

In Closing

We failed many times along the way, but each failure corrected an inaccurate understanding. The point-source approximation made us think the turquoise band would be strong; the focusing formula made the umbra center 250 times too bright. Every temptation to say "close enough" was answered by going back to physics and finding what was missing. Several times I saw the computed cyan too strong or the umbra too bright and wanted to tweak ozone concentration or add aerosols to darken it. Each time I held back. When the final pale cyan narrow band matched GOES-16 measurements and Shu 2024 remote sensing data point by point, I felt holding back was right.

The biggest takeaway from this project is that AI has lowered the barrier to first-principles physical simulation. People like me could not do this before because too many physical decision points required expert judgment. Now AI handles both physics and programming; the one judgment I need to make is: brute force, not clever approximation. That may be the most counterintuitive point about scientific computing in the AI era: the stronger AI gets, the more humans need the judgment not to take shortcuts.

使用AI十倍提效，成了模范老黄牛，就能加薪升职了？

2026-06-20T11:00:00-07:00

熟悉我的朋友都知道，我对使用 AI 在实际工作中提效有巨大的热情和不错的成果。但是在经过一两年的实践以后，一方面我确实享受到了这种生产力提升带来的好处，一方面又在不知不觉中掉入了一个陷阱。这个陷阱在根本上限制了我的职业发展，同时让我不自觉又不懈地向着更容易被AI替代这个荒谬的目标努力。下面我就想分析一下这个非常讽刺的陷阱：为什么最擅长使用AI，真的在工作中提效的这帮人，反而最容易被AI伤害职业发展，以及我们怎么破解这种情况。

一个荒谬的职业故事

我先分享一下我的故事。作为一个中厂研发，表面上看我的AI提效非常成功。从24年底开始，我基本就没有古法手写过代码了，但我的产出和rating也一直是整个org最高之一（我的VP老板的评价是deliver in superhuman pace）。这让我在下面一年多的时间和 CEO/CPO/CTO （下面简称CXO）每两周有定期的 meeting。而且因为每两周都能稳定交付扎实的成果，同时用AI有针对性地打磨slides，所以我的presentation也是最顺利的之一。

然后我的升职失败了。然后第二次努力，又失败了。升职这种事情本来随机性就很强，真正的原因往往未必是说出来的官面原因。我的升职主要是C suite审核给意见，屡屡被毙就很奇怪了，我明明每次开会都很顺利啊。我和老板一起做了复盘，觉得可能是这样那样的原因。但后来我quit了，整件事情就搁置了。

直到最近我每天疯狂微操AI构建东西，突然反应过来一个问题，感觉可能是限制我职业发展的重要因素。这个问题就是，老板/C suite眼里我到底是他的手还是他的脑？

手指的是，CXO心里有个想法，想快速试一试，就把鸭哥叫过来说，嗟，你去试一下这个。然后我用AI哐哐一天干完别人一个星期的活，两周之后直接搞了个超牛逼的demo。CXO看了，说卧槽鸭哥牛逼，你再试一下这个。有时候这个新想法和旧想法是有关系的，有时候是没关系的，取决于公司近期最有价值的方向。在最完美的世界里，CXO应该记挂着鸭哥这个小IC的职业发展，给他的方向有一定的关联。但实际上，这个最有价值的方向未必是稳定甚至相关的。所以在客观上就造成了一个问题，我每两周deliver的东西确实都很多，但方向过一两个月就变一次，有时候是去救火，有时候去做新实验，最终反而很难讲清楚过去一年做成了啥。不论是我还是我老板（VP）其实都注意到了这个问题，但很难周旋，因为天命难违（不是）。

这里我觉得讽刺的地方在于，如果我干活没这么快，就不会被放到“手”的这个被动的位置上。因为我实在是太好用了，摩擦太低了，所以到后来CXO得出了跟我用AI一样的结论：打击比探测更便宜。有什么东西能不能做出来/能做多好，直接让鸭哥手搓一个看看就行了，比自己开会干想又快又准。失败了也没关系，反正他手快。更严重的是，这种快速迭代还会激发老板们微操的欲望，这就造成我的项目的破碎程度，失败率和周转率反而比别人高好多。到升职的时候讲故事很难讲圆，成了一个蛮大的被动因素。（叠甲：不是唯一原因）

所以说，我自己的手快，熟练，AI提效，反而让我在老板眼中主要承担执行角色，拿到的项目零散多变，从根本上造成了我处在职业发展的不利地位上。而且这个不是老板们的问题，事实上我觉得我的VP/CXO 都非常reasonable/insightful。所以这不是遇人不淑，换个老板就能解决的问题。这是一种理性选择。想想我们用AI也是一样，快的模型就让它有枣没枣先打一杆子，同时做得快的AI也容易被微操。而且有一点更荒谬的地方不知道大家注意到没有，我在自然地用AI类比这种情形了。这是因为我的这种执行角色和AI的处境非常类似，老板看我跟我看AI一个样。那猜猜老板眼中谁最容易被AI取代？换言之，我用AI用的好的这个事实，在客观上让我更多的承担执行类的工作，反而变得更容易被AI替代。

这是一个致命的陷阱，而且非常讽刺地，只有AI真的用的好的人才会掉进去。但凡你用AI提效不扎实，老板感觉不到这么好用，都不会有这种问题。

重要的工具和致命的陷阱：奖赏系统

要理解这个陷阱，得先讲清楚一个管理学的概念叫做incentive structure。说人话就是奖赏系统，什么情况下会得到奖励。比如我们前面说的升职加薪，就是一种incentive。公司用这个作为胡萝卜，来奖赏和鼓励某些行为，比如亚马逊有operating principles，facebook讲求impact，做到的人就加薪升职，这就是incentive structure。

这个东西其实非常常见。比如打游戏的时候我们经常听说什么兵种或者角色被削弱了，以前很有效的某种战术就不流行了。这就是因为奖赏系统变了，导致玩家的行为也变了。类似的，国家的法律和政策也是一种incentive structure，比如电车减免税费，大家就更倾向去买电车。甚至AI模型的训练也基于类似的机制。我们在训练的过程中不会手把手教模型，你的几百亿个参数要这么改，而是通过把控一个奖赏系统，告诉AI模型，你的得分是多少，gap在哪里，然后它自己去改进来拿更多的分数——是不是和职业发展很类似？

这个东西很重要是因为两点。第一它省时省力，就是high leverage。控制每个人的想法是很难的，比如一个org 100个人，一个个谈心劝他们bias for action得到猴年马月，费时费力。但给人/AI做一个奖赏系统，说能做到什么什么就有什么精神奖励+物质奖励（只要这些行为符合bias for action就行，甚至不用出现这个词），就可以四两拨千斤。人自己会代入做题家模式，想着去优化里面的分数。关键在于，这个优化目标很多时候是精心设计的，最终就等于他自己努力达到了我们想要的结果。而且很多人根本意识不到这个奖赏机制是人设计出来的，觉得这是很自然的，努力工作升职加薪嘛。这种隐蔽性是它很重要的第二个原因。因此，在一个组织里，经理的一个非常核心的职责就是设计和维护这种奖赏系统，让组员在不知不觉中主动实现公司想要的目标。

这个工具是纯理性的，我们已经无意识地利用它来套利了。当前IT公司主流的奖赏系统还是AI时代之前的，比如你交付的东西越多，拿到的奖励就越多。但AI把交付这个东西变得特别便宜，这种改变就带来了套利的机会。所以我的行为改变了，开始冲交付。但像上面说的，这种套利行为同时又造成了我们的困境。它的问题在于，不像我们前面的例子，只是上级影响下级，下级反过来也在影响上级。比如我们前面提到的“打击比探测更便宜”，就是因为AI时代以前，我们写代码很慢，代价高，所以系统客观上奖励谋定而后动这种行为。现在AI写代码很快了，你有三思而后行的时间，AI已经把几种可能的实现全都做出来了，你自己挑。是这种底层成本结构的变化，就是奖赏系统的改变。它反过来会影响最优策略——就是别想了，直接一把梭试试看再说。而且在这个过程中，AI是下属，我们是上级。我们的行为受到了下属的影响。

做自己的经理，设计老板的奖赏系统

回到我的故事，这里面发生的事情也是一样的。从老板的角度看，AI时代之前，给鸭哥派活跟其他人一样烦，要说服他这件事很重要，要画饼，要看着防止他阳奉阴违磨洋工。AI时代以后，鸭哥太好用了，不用说服，指哪打哪，做的还特别快。这种奖赏系统的变化，导致老板不自觉也在套利，在这个系统里优化到飞起：他会更多地把别人不愿意接的脏活累活扔给鸭哥。这里面每个决策都是理性的：老板在这里觉得他找到了一个好用的员工（手），物尽其用；鸭哥也觉得他在套利，用AI交付更多。但问题在，不论是老板还是鸭哥都只是被动地跟着这个客观（organic）的奖赏系统找到各自的最优策略。这反而造成了资源的浪费：老板没有拿满鸭哥的价值，鸭哥自己的职业发展也受阻了。

既然每个人的决策都是理性的，这个问题怎么破局呢？或者更广泛地思考，AI时代我们要怎么避免这种AI用的好的人反而更偏执行更容易被替代这个问题呢？答案很简单，做一个好经理，积极地管理周围的奖赏系统。

具体地说，我们在做决策的时候，不仅要单纯对周围的奖赏系统做出被动响应（reactive），比如系统鼓励我多交付，那我就用AI多交付；更要主动（proactive）设计你给别人的奖赏系统。当然我们没办法给老板加薪升职，我们的手段可以是交付的摩擦：无条件高质量交付，会给老板一种印象，给我派脏活很简单。那我就要先判断这个活是不是脏活，有没有必要做，没必要的就pushback。从局部上看，这个决策可能是反直觉的，甚至是有害的。比如我会更多的顶撞老板，老板肯定不爽。会议会不顺利，老板为了推动执行会批驳我的观点，甚至我们撕逼浪费的时间比我认输自己做还更长。但长期看，他的理性决策可能反而会偏向我们想要的双赢的结果。

注意我这里用了可能，这是因为管理这件事有很多内部的技巧。比如不是我随机反抗他就不给我派活了，这只会让老板觉得这个人又不可靠又龟毛。这里需要真的有判断力，pushback的确实都是不靠谱的想法，集中精力做靠谱的想法，才能让老板觉得这人有决断力有担当。这里面有很多变量和细节，暂时不具体讨论，主要是因为换成这个视角以后，我们根本就不在讨论新问题。这是个有千百年历史的现象：为什么老黄牛不受待见。不论有没有AI，当老黄牛（老板的手）都不如当老板的脑收益高。有了AI以后，能用AI快速交付的人多了，老黄牛的群体扩大了，就更不值钱了。能和老板对等讨论，pushback，发现他的思维盲点，构建共鸣的人就更少更值钱了。

所以，用AI套利的正确模式不是响应现有的奖赏系统，努力交付。这是饮鸩止渴，天然构建了一种我们和老板利益冲突的奖赏系统。老板在里面不自觉优化，反向套利，越优化我们越被动。不论我们或者老板有多努力，这是一场必输的战役。更好的方式是主动管理我们给别人的奖赏系统，让别人在这种系统里理性自发地把我们放到最重要的地位上去。什么是最重要的地位，这个就很主观了。比如是希望活少，还是钱多，还是升职快，很多是互相矛盾的。怎么找最喜欢的甜点区是每个人自己的选择。但不管目标是什么，指望自己用AI提效，努力交付就能实现这个目标是不切实际的。我们需要做一个好经理，主动设计和维护这个奖赏系统，然后让别人自己向我们的这个目标努力，这才是省时省力的方法。而这个系统的设计，也是可以通过AI提效的。相比于用AI卷代码输出，这种对判断力的打磨和系统的构建，是AI更高效的用法。

总之，用AI无脑输出代码是最省力的方法，用AI耗脑输出判断才是高杠杆有竞争力的职业手段。

AI 10x'd My Productivity. I Became a Model Workhorse. I Didn't Get Promoted.

2026-06-20T10:00:00-07:00

Friends who know me well are aware that I'm deeply passionate about using AI to boost real-world productivity — and I've had solid results. But after a year or two of practice, while I've genuinely enjoyed the productivity gains, I've also unwittingly fallen into a trap. This trap has fundamentally limited my career growth, all while pushing me — relentlessly and unconsciously — toward the absurd goal of making myself easier to replace with AI. What follows is an analysis of this deeply ironic trap: why the people who are best at using AI to actually get things done are the ones most vulnerable to AI damaging their careers. And how we can break out of it.

An Absurd Career Story

Let me share my story. As an engineer at a mid-sized company, my AI-driven productivity boost looked like a massive success on the surface. Since the end of 2024, I've basically stopped writing code by hand the old-fashioned way, yet my output and rating have consistently been among the highest in the org (my VP described my pace as "superhuman"). This earned me a biweekly meeting with the CEO, CPO, and CTO (CXO for short) for over a year. And because I could reliably deliver solid results every two weeks while using AI to polish my slides, my presentations were some of the smoothest in the org.

Then my promotion failed. I tried again — failed again. Promotions are inherently somewhat random, and the real reasons are rarely the official ones. My promotion required C-suite approval, and getting shot down repeatedly was baffling — every meeting had gone so smoothly. My manager and I did a retrospective and came up with some possible explanations. But then I quit, and the whole thing was shelved.

Recently, as I've been furiously micromanaging AI to build things every day, something suddenly clicked. I realized there's one question that may have been the key factor holding my career back: in the eyes of my boss and the C-suite, was I their hand or their brain?

Being a "hand" means this: a CXO has an idea they want to test quickly, so they call me over and say, "Hey, go try this." Then I use AI to crank out a week's worth of work in a day, and two weeks later I've built an insanely impressive demo. The CXO sees it and says, "Damn, Yage, you're amazing — now try this other thing." Sometimes the new idea is related to the old one, sometimes not, depending on whatever the company's most valuable direction happens to be at the moment. In a perfect world, the CXO would keep my career development as an IC in mind and give me work with some coherent thread. In reality, the "most valuable direction" is rarely stable or even connected. This created an objective problem: every two weeks I delivered a ton of stuff, but the direction shifted every month or two — sometimes firefighting, sometimes new experiments. In the end, it was nearly impossible to tell a coherent story about what I had accomplished over the year. Both my VP and I noticed this, but it was hard to push back against. The mandate of heaven is hard to defy (jk).

Here's the irony: if I weren't so fast, I wouldn't have been put in the passive position of being a "hand" in the first place. I was simply too useful, with too little friction. Eventually the CXO arrived at the same conclusion I had about using AI: strike is cheaper than probe. Instead of spending time in meetings thinking through whether something can be built or how good it would be, just have Yage hand-build a prototype — it's faster and more accurate than debating it in a room. If it fails, no big deal, the guy's fast. Worse still, this rapid iteration tempts bosses into micromanagement, which meant my projects were more fragmented, had higher failure rates, and churned faster than anyone else's. When promotion time came, telling a coherent story became nearly impossible — a major liability. (Caveat: not the only reason.)

So here's the thing: my speed, my skill, my AI-amplified productivity — all of it ended up slotting me into a pure execution role in my bosses' eyes. The projects I got were fragmented and ever-shifting, putting me at a fundamental disadvantage for career growth. And this wasn't a "bad boss" problem. My VP and CXOs were genuinely reasonable and insightful. This isn't something you solve by switching managers. It's rational behavior. Think about how we use AI: we throw the fast model at anything just to see what happens, and fast models are easy to micromanage. And here's the even more absurd part — did you catch that I'm naturally using AI as an analogy for my own situation? That's because my execution role is eerily similar to an AI's. My boss sees me the same way I see AI. Now guess who, in the boss's eyes, is the easiest to replace with AI? In other words, the very fact that I'm good at using AI objectively pushed me into more execution work, which made me easier to replace with AI.

This is a fatal trap. And the cruelest irony: only people who are genuinely good at using AI fall into it. If your AI productivity gains are mediocre and your boss doesn't notice how useful you are — you won't even have this problem.

A Powerful Tool and a Fatal Trap: Incentive Structures

To understand this trap, we need to talk about a management concept: incentive structure. In plain terms, it's the reward system — what gets rewarded and under what conditions. Promotions and raises, like the ones I was chasing, are incentives. Companies use them as carrots to encourage specific behaviors. Amazon has its Leadership Principles, Facebook emphasizes Impact — people who embody these get promoted. That's the incentive structure.

This is everywhere once you start noticing it. In games, a certain class or tactic gets "nerfed" and suddenly no one plays it anymore — the incentive structure changed, so player behavior changed. National laws and policies are incentive structures too: tax breaks for EVs push people toward electric cars. Even AI model training works this way. We don't teach models parameter by parameter. Instead, we design a reward system, give the model a score, tell it where the gap is, and let it optimize itself to get higher scores. Sound familiar? It's not so different from career progression.

Incentive structures matter for two reasons. First, they're high leverage — incredibly efficient. Controlling what a hundred people think one by one is impossible. Convincing them all to "bias for action" through individual heart-to-hearts would take forever. But set up a reward system — achieve X and get recognition plus material rewards — and you move mountains with a light touch. People naturally slip into test-taker mode, optimizing for the score. And the beauty is, if the optimization target is well-designed, people's self-interested efforts end up achieving exactly what you wanted — often without them even realizing it. Which brings us to the second reason: this system's invisibility. Most people never realize the incentive structure was deliberately designed. They think it's just natural — work hard, get promoted. That very stealth is what makes it so powerful. This is why a manager's core responsibility is designing and maintaining these incentive systems, so team members unconsciously but actively pursue the outcomes the company wants.

This tool is purely rational, and we've already been arbitraging it without realizing. The dominant incentive structure in tech companies was designed in the pre-AI era: the more you deliver, the more you're rewarded. But AI has made delivery dirt cheap, and that shift created an arbitrage opportunity. So I changed my behavior and went all-in on delivery. But as we've seen, this arbitrage also created our predicament. The problem is that, unlike the examples above where influence only flows downward from superior to subordinate, here subordinates influence superiors right back. Take "strike is cheaper than probe." In the pre-AI era, writing code was slow and expensive, so the system objectively rewarded thinking before acting. Now, AI writes code so fast that while you're still deliberating, AI has already built every plausible implementation for you to pick from. This shift in the underlying cost structure is a change in the incentive system, and it alters the optimal strategy — stop thinking, just go for it. And here, AI is the subordinate and we're the superior. Our behavior is being shaped by our subordinates.

Be Your Own Manager: Design Your Boss's Incentive Structure

Back to my story — the same dynamic was at play. From my bosses' perspective, in the pre-AI era, assigning work to me was as annoying as assigning it to anyone else. They had to convince me the task mattered, sell the vision, keep an eye out for slacking. In the AI era, I became frictionless. No convincing needed — point me at something and I'd crush it, fast. This shift in the incentive structure led my bosses to unconsciously arbitrage it too, optimizing relentlessly: they'd increasingly throw me the dirty, thankless work nobody else wanted. Every decision in this chain was rational. My boss found a highly useful pair of hands and put them to good use. I felt like I was arbitraging the system — using AI to deliver more. But here's the problem: both my boss and I were merely reacting passively to this organic incentive structure, each finding our own local optimum. The result was a waste of resources: my boss wasn't extracting my full value, and my career growth was stunted.

If everyone's decisions are rational, how do we break out of this? Or more broadly: in the AI era, how do we prevent skilled AI users from being pigeonholed into execution roles and becoming more replaceable? The answer is simple: be a good manager. Actively manage the incentive structures around you.

Concretely: when making decisions, don't just react passively to the incentive structures around you — "the system rewards more output, so I'll use AI to output more." Go proactive: design the incentive structures you present to others. Sure, we can't give our boss a raise or a promotion. Our lever is friction. Unconditionally high-quality delivery creates the impression that throwing grunt work at me is easy. So I need to first judge whether a task is grunt work, whether it's even worth doing, and push back when it's not. Locally, this might seem counterproductive — even harmful. I'd be contradicting my boss more, which would definitely annoy him. Meetings would get bumpy. My boss might push back against my pushback, and we might waste more time arguing than if I'd just shut up and done the work. But in the long run, his rational decision-making might actually tilt toward the win-win outcome we both want.

Notice I said "might." Management has many nuances. Randomly resisting won't stop the grunt work from coming — it'll just make your boss think you're unreliable and difficult. Pushback only works if you genuinely have good judgment: you need to push back on genuinely bad ideas and pour your energy into the good ones, so your boss comes to see you as decisive and accountable. There are many variables and subtleties here that I won't dive into, mainly because once we adopt this perspective, we're no longer discussing a new problem at all. This is a centuries-old phenomenon: why workhorses don't get ahead. AI or no AI, being a workhorse — being your boss's hands — will never pay as well as being your boss's brain. With AI, more people can deliver fast, the workhorse population has exploded, and workhorses have become even cheaper. People who can discuss things as equals with their boss, push back, spot blind spots, and build genuine alignment — those people are rarer and more valuable than ever.

So the right way to arbitrage with AI is not to react to the existing incentive structure by cranking out more output. That's drinking poison to quench thirst — it naturally creates an incentive structure where our interests and our boss's are in conflict. The boss will unconsciously optimize against us, and the more they optimize, the more passive we become. No matter how hard we or our boss try, this is a losing battle. The better path is to actively manage the incentive structures we present to others, so that in those systems, people rationally and spontaneously place us in the most important position. What counts as "most important" is subjective — less work, more money, faster promotion, often contradictory. Finding your sweet spot is a personal choice. But whatever your goal, expecting AI-boosted productivity and hard delivery to get you there is unrealistic. We need to be good managers: proactively design and maintain the incentive structure, then let others work toward our goals of their own accord. That's the high-leverage, low-effort approach. And designing this system is something AI can accelerate too. Compared to using AI to crank out more code, sharpening judgment and building systems around people — that's a far more efficient use of AI.

To sum it up: using AI to mindlessly output code is the path of least resistance. Using AI to think deeply and produce judgment — that's the high-leverage, competitive career move.

把18亿颗星星画在一张图上，能还原我们拍到的银河吗？

2026-06-14T22:00:00-07:00

这个问题的起点非常简单。欧空局2013年发射了一颗卫星，叫盖亚（Gaia）。它花了十几年的时间给全天的星星拍照和测光，截止到2022年公布了18亿颗星星的方位、星等、距离、光谱等等数据。在天天下雨的西雅图，一个很有意思的实验是：如果用这18亿颗星星的数据，我能不能渲染出一张以假乱真的银河图像，卷死你们这帮摄影党？当然，这里有一个巨大的局限是，盖亚星表只包括星星的数据，不包括星云，因此成图不会包括反射和发射型星云等深空天体。但我很好奇的地方是，也许银河的结构可以出来？

这件事情并不难。每颗星星的位置、亮度和颜色都有了，画在一张图上面不是行了？于是，我让AI用最直白，最不绕弯的方式，10分钟写了一个程序出来。这个程序确实接住了我，但我发现渲染出来的结果一点都不像我们看到的星空（见图一）。接下来就是连续一个星期的改程序，翻车，改程序，翻车。连续的翻车让我意识到整件事情背后的意义比我想象的要深刻很多，它最终的目标早就超越了“模拟出来一个以假乱真的照片让我在阴天也能键盘摄影”，而在于让我意识到：其实我（们）以前从来没有思考过为什么我们头顶的星空长这个样子。

这篇文章就想展现这个探索的过程和最终的结果。我们会从最简单的画图方式开始，一步步加入更关键的物理原理，从而看到越来越真实的模拟。通过这样的过程，我们就可以理解星空之所以长这样，背后到底有哪些最关键的原理。在这个基础上还可以做一些疯狂的实验，比如因为Gaia星表给了每颗恒星的方位和距离，就给了它们在三维空间中的位置。只要我们把模拟链路跑通，我们甚至可以站在银河系的上方回望银河系，看看它的盘状结构到底是什么样的。

在模拟翻车中学习

所以我们就回到起点，看看下面这个图：

图一：G<11 等恒星，每颗星一个像素，无任何后期处理

这幅图就是把盖亚星表里面11的以下的星星画出来的结果：每颗星星根据赤经赤纬算出来在图上哪个位置，然后根据颜色和亮度画一个点。它看起来其实有一点银河的影子，但很显然和我们平时印象里的星空非常不一样。其中最大的区别就是亮星没了。无论是目视还是摄影，看到一个夏季银河照片的时候，我们往往可以第一眼就能注意到夏季大三角（牛郎，织女，天津四），纬度低的地方还有心宿二。但这个图上啥都没有，因此看上去就非常奇怪。

这里面其实有两个原因。第一是盖亚这颗卫星装备的是非常灵敏的测光仪器，因此它在观测的时候有意避开了全天有名的那些亮星，避免仪器读数饱和（此处感谢仓鼠和六年之后的指正）。因此我们需要用其他星表手动加入这些知名的亮星。

另一个原因是，不论是目视还是摄影，我们往往会注意到亮星看起来比暗星要大一些（即使不用柔光镜等滤镜也是这样）。这个现象其实蛮反直觉的。因为星星离我们实在太远了，因此从光学系统的角度来说每个星星都是一个点光源。而点光源经过摄影镜头放大之后，只会变亮而不会变大，没办法解释我们实际的观察。这个理论是正确的，但漏考虑了一点：虽然星星是点光源，但是光学系统不是完美的，它会把星星变成一个有一定大小的模糊的光斑。当一颗星星更亮的时候，这颗光斑能被人看见的部分就更大了。用一个比喻来看，每颗星星都像是一座山，亮的星星高一点，暗的星星矮一点。一座更高的山，它的占地面积就比一小山要更大。同时不论是视网膜还是传感器，还有一些内部反射和衍射会带来额外的光晕，二者结合就是背后的原理。

在知道这一点之后，渲染上的处理就比较简单了。我们需要从物理出发，给所有星星一个模糊的操作（术语是引入 PSF，点扩散函数）。这样亮度更亮的星星天然就有一层自然的光晕扩散出去。于是我兴冲冲地把这个原理加进了程序，结果如图二所示。

图二：加入 PSF 和亮星补全后，亮星有了光晕，但银河仍然模糊

这里面可以很明显看到牛郎、织女和心宿二。从亮星的角度来说明显更像我们实际看到的星空了。但还是有一个很大的问题是：银河去哪了？我们已经渲染了11等以上（更亮）的几十万颗星星，但银河的影子仍然非常模糊。我们一开始以为是因为星星不够多，所以进一步把渲染的范围拓展到了13等以上的几百万颗星星上。但结果如下图所示，改变不大。

图三：扩展到 G<13 等，几百万颗星，银河仍然模糊

经过进一步的调研，我才学习到，原来银河为什么亮，主要不是因为亮星多，而是因为有很多很多的暗星。这些暗星在视觉上无法区别，连成一个整体，就共同构成了银心附近那层淡淡的辉光。对于我们的模拟来说，有一个很简单的取巧的办法，就是在光度上有一个经验性的公式。不同的星星有不同的星等，比如我们从8等星变到9等星，虽然每颗星星变暗了，但这个亮度的星星也变多了。巧合的是，在相当大的星等范围内，他们乘起来的总光量是差不多的。换言之，所有8等星发出的光的总量（光通量的积分）和9等星发出的光的总量，在我们看来都是差不多的。所以我们虽然不知道13等以下（更暗）的星星的具体情况，但可以用13等的星星来模拟他们发出的光。反正13等的星已经是百万级别，再区分空间位置已经没有意义。所以我们用13等的星星的亮度乘以一个系数，其实可以相当真实地模拟13等以下的所有星星的光度。结果如下图所示。

图四：用 13 等星乘增益代理更暗的星，银河乳光出现了，但颜色偏黄

银河果然就出来了！这个结果非常令人振奋。但很快我们又发现两个问题。第一个问题是颜色，我们实拍的银河往往不是这么黄不拉叽的。这个问题倒比较好解决。这张图的颜色是我们用一个非常简单的公式算出来的色值。如果我们引入真的物理过程，通过主序星标定估算恒星表面温度，再用黑体辐射公式算出来它的色温，就可以得到下面这张图，颜色看起来就正常多了。

图五：引入黑体辐射色温校准后，颜色正常了

更大的问题出在银河的形状上。这张图你仔细看，会觉得好像有点像银河又不太像银河，在银心的部分出现了很多实拍图上没有的纹理。比如它的中央裂缝在银心附近好像分成了两条岔，最终又合为一条，远看甚至像一个汉字“中”。这是一个非常奇怪的问题，意味着要不然是我们的数据，要不然是我们渲染的过程出了比较大的问题。

在这里我卡了蛮长时间。做了很多优化都没什么用，直到最后想起来把星等从13等扩展到了15等， 18等，甚至20等，把六亿颗恒星的光度精确地积分在一起，我们熟悉的银河大裂缝才会出来。如下图所示。

图六：扩展到 G<18 等，六亿颗星，大裂缝终于黑得干脆利落。点击图片可打开 4K 预览。

这两个图一对比，就会发现上一张图看起来不对的主要原因在于13等星和更暗的这些星星，它的空间位置还是不太一样。13等以下的星星更多地分布于裂缝两侧。虽然每颗星星的光度很弱，但是由于数量庞大，它们聚在一起产生了银心的淡淡辉光，同时让中央的裂缝变得更加明显。

这个模拟过程有点像是以力破巧，我们在上一步中引入了经验的光度公式，看起来高大上，节约了计算量，但这种近似也引入了一个很难破除的天花板。当我们有足够的数据以后，就完全不需要前面的技巧，用最朴素的公式渲染都可以得到很好的结果。在后面的文章我们还会用同样的思路计算模拟月食时候的绿松石带，那时候也会看到类似的心得。

光污染和星空漫游

到这里，我们的模拟本身就告一段落了。上面那个400亿像素的全分辨率银河可以在这里浏览：https://yage.ai/gaia_milky_way/

但是除了肉眼看起来像照片以外，还有什么方法能够定量地验证我们的模拟是正确的呢？有一种思路是引入光污染。一方面，光污染是一个可以定量测量的物理量。每一种波特尔暗夜等级都对应着某种强度范围（星等/平方角秒）的背景天光。这就让我们可以定量模拟不同的光污染条件下银河的观感。另一方面，不同波特尔等级下银河的观感大家也很熟悉。比如六级用眼角的旁光还可以隐隐约约看到一点点银河，7级和以上就没戏了。二者结合就很适合用来做验证。

所以我就验证了一下七级光污染下银河的观感。我的程序言之凿凿的说没问题，很清楚！如下图所示。

图七：七级光污染下，未加 Weber 阈值——银河居然还在

这就很奇怪了。说明我们的渲染流程还是有问题。在经过更多的调研之后，我发现这不是一个物理问题，而是一个生理学问题。人的眼睛有一个特性，它能不能看见一个东西不取决于这个东西的绝对亮度，而取决于它相对背景亮了多少。比如我们一般说人眼在暗夜中能看见六等的星星，这并不意味着人眼也能看见总星等六等的弥散星云/辉光。而当天光背景很亮的时候，弥散结构需要远远更亮才能看见。因此，我们需要用这个特性（术语叫 Weber 阈值）来计算银河的相对亮度。在引入这个生理学模拟之后，我们很快就得到了符合实际情况的模拟结果，比如下图是七级光污染下的银河模拟：

图八：加入 Weber 阈值后，七级光污染下银河消失，符合实际观测

我们一路翻了很多次车，但每次翻车都给了我们宝贵的经验教训，纠正了之前不准确的理解，带来了新的知识。我觉得这个历练本身和带来的知识比拿到最终的照片更有意义。诚然，我学过很多天文/物理知识，可以解释很多现象，甚至做很多题。但检验知识的唯一标准是到实践中去。我们用学到的东西搓了个模拟链路，它出来的结果不对，我们学的东西就是不完整/不正确的。在这个过程中不断地加入更多的因素，发现哪些有用、哪些没用，本身就是个特别好的学习机会。

模拟还有一大好处是它比实拍要多了无数种可能性。比如我们身处银河系内部，那我们是怎么知道银河系从外面看起来是什么样的呢？盖亚星表给了我们一条途径：如果我们知道每颗星星的赤经、赤纬和离我们的距离，它们在三维空间中的位置就确定了。因而我们完全可以做一个虚拟的相机从银河系的上方向下拍摄。这样是不是就能看见一个完美的螺旋或者棒旋结构呢？遗憾的是，我照这个思路做了模拟，结果如下图所示。

图九：从银河系上方俯视的模拟结果——看不到旋臂，因为 Gaia 视差测距只覆盖太阳附近几千光年

这并不意味着我们的银河系真的长这个样子，而是因为盖亚卫星测距的局限。它用的是视差测距，这个原理和我们用两个眼睛看东西，会有物体离我们多远的感觉一样。这种方法对近处的东西很有效，比如你可以很容易地分辨出离你一米远的东西和两米远的东西谁更远，但对很远的物体就没用了。比如我们仅凭肉眼很难分辨出100米和110米的物体谁更近。盖亚卫星也是这样，在离我们几百到几千光年内的范围内，测距还是比较准确的。但银河系的尺度是十万光年的量级，远大于这个范围。因此对于大多数恒星，我们对它距离的把握是非常粗略的，也自然看不到一个规整的螺旋形从数据中自己出现。同时因为银心的方向存在大量的尘埃遮挡，我们的数据也是不完整的。二者结合就形成了上面那幅看上去很杂乱的图。事实上，到目前为止，人类并没有任何一种途径实拍出银河系长什么样。我们在网上看到的俯视的银河结构都是间接观测推断+艺术家的想象图。我们也算是撞到了人类科技的边界上。

除此之外，我们也做了很多其他的实验。比如我们可以做个视频来演示，如何从一个广域照片用惊人的放大倍率一路推进到非常深的深空摄影。同时我们可以模拟你的相机在不同的曝光下，或者如果人类有着超人的眼睛，不同的光污染环境可以拍出怎样的银河。这些模拟的结果我们都放在这个项目的主页上了：https://grapeot.github.io/gaia_allsky/。所有代码也是开源的。我相信这个实现里面肯定还有很多可以改进的地方，也欢迎大家评论反馈。

从全景推进到银心核心 1:1 的连续放大，视频无声

Can 1.8 Billion Stars Recreate the Milky Way We Photograph?

2026-06-14T21:00:00-07:00

The premise was simple. The European Space Agency launched a satellite called Gaia in 2013. Over more than a decade, it photographed and measured the entire sky, and by its 2022 data release it had cataloged the positions, magnitudes, distances, spectra, and other measurements for 1.8 billion stars. In perpetually rainy Seattle, a very tempting experiment came to mind: if I used the data for all 1.8 billion stars, could I render a photorealistic Milky Way image and outcompete all you astrophotographers from my keyboard? Of course, there is one major limitation here: the Gaia catalog only contains stars, not nebulae, so the final image would not include reflection nebulae, emission nebulae, or other deep-sky objects. But the part I was curious about was this: maybe the structure of the Milky Way would still appear?

This did not seem hard. Every star already had a position, brightness, and color. Just draw them on an image, right? So I had AI write the most direct, least clever program possible in 10 minutes. The program did exactly what I asked, but the rendered result looked nothing like the night sky we see (Figure 1). What followed was a full week of modifying the program, failing, modifying it again, failing again. Those repeated failures made me realize that the whole exercise meant more than I had expected. Its real goal had moved beyond "simulate a photorealistic image so I can do keyboard astrophotography on cloudy days". It was making me realize that I, and probably we, had never really thought about why the sky above us looks the way it does.

This article is about that exploration and where it ended. We will start with the simplest possible rendering method, then gradually add the physical principles that matter, watching the simulation become more realistic step by step. Through that process, we can understand which mechanisms most strongly shape the sky we see. Once that simulation pipeline works, we can also try some unreasonable experiments. Since the Gaia catalog gives us each star's direction and distance, it also gives us their positions in three-dimensional space. If the pipeline is working, we can even place a virtual camera above the Milky Way and look back down at the galaxy to see what its disk structure looks like.

Learning from Failed Simulations

So let us go back to the beginning and look at this image:

Figure 1: G<11 stars, one pixel per star, no post-processing

This is what you get by plotting the stars brighter than magnitude 11 from the Gaia catalog. For each star, the program computes its position on the image from right ascension and declination, then draws a point using its color and brightness. The image has a faint hint of the Milky Way, but it clearly looks very different from the night sky we are used to. The biggest difference is that the bright stars are missing. Whether visually or in photographs, when we look at a summer Milky Way image, the first things we usually notice are the Summer Triangle, Altair, Vega, and Deneb, and at lower latitudes Antares. This image has none of them, which makes it look very strange.

There are two reasons for that. First, Gaia carries extremely sensitive photometric instruments, so during observation it intentionally avoided the famous bright stars across the sky to avoid damaging the instruments. Thanks here to Hamster and Liunian Zhihou for pointing this out. That means we need to manually add those well-known bright stars from other catalogs.

The second reason is that, whether we look with our eyes or with a camera, bright stars tend to appear larger than dim ones, even without diffusion filters. This is quite counterintuitive. Stars are so far away that, from the perspective of an optical system, each star is a point source. When a point source is magnified by a camera lens, it should become brighter, not larger, so that alone cannot explain what we actually observe. That theory is correct, but it misses one detail: although a star is a point source, the optical system is not perfect. It turns each star into a blurred spot with finite size. When a star is brighter, the visible portion of that spot becomes larger. As an analogy, each star is like a mountain: bright stars are taller, dim stars are shorter. A taller mountain occupies more ground area than a small hill. At the same time, both retinas and sensors introduce internal reflection and diffraction, which add extra halos. These effects together explain the visual appearance.

Once we know that, the rendering fix is straightforward. We need to start from physics and apply a blur operation to every star. The technical term is introducing a PSF, or point spread function. This way, brighter stars naturally spread into a halo. I excitedly added this principle to the program, and the result is shown in Figure 2.

Figure 2: After adding PSF and bright-star supplementation, bright stars have halos, but the Milky Way is still faint

Altair, Vega, and Antares are now easy to see. From the bright-star perspective, this is obviously closer to the sky we see in practice. But there is still one big problem: where did the Milky Way go? We had already rendered hundreds of thousands of stars brighter than magnitude 11, but the Milky Way itself remained very faint. At first, we assumed there simply were not enough stars, so we extended the rendering range to millions of stars brighter than magnitude 13. The result is shown below. It did not change much.

Figure 3: Extended to G<13, millions of stars, the Milky Way is still faint

After more research, I learned that the Milky Way is bright mainly not because there are many bright stars, but because there are many, many faint stars. These faint stars cannot be distinguished visually. They merge into a continuous whole and together form the soft glow around the galactic center. For our simulation, there is a simple shortcut: an empirical relationship in the luminosity distribution. Different stars have different magnitudes. For example, when we move from magnitude 8 to magnitude 9, each individual star becomes dimmer, but there are also more stars at that brightness. Coincidentally, across a fairly large magnitude range, the total amount of light works out to be roughly the same. In other words, the total light emitted by all magnitude 8 stars, meaning the integral of their flux, and the total light emitted by all magnitude 9 stars look about the same to us. So even though we do not know the exact details of stars fainter than magnitude 13, we can use magnitude 13 stars to approximate the light they emit. After all, there are already millions of magnitude 13 stars, so distinguishing their spatial positions more finely is no longer very meaningful. By multiplying the brightness of magnitude 13 stars by a coefficient, we can simulate the luminosity of all stars fainter than magnitude 13 quite realistically. The result is shown below.

Figure 4: Using magnitude 13 stars with a gain factor to stand in for fainter stars, the Milky Way glow appears, but the color is too yellow

The Milky Way finally appeared. That result was very exciting. But we quickly found two problems. The first was color. The Milky Way in real photographs is usually not this yellow. Fortunately, this problem was relatively easy to solve. The colors in this image were computed with a very simple formula. If we introduce the actual physical process, estimate stellar surface temperature by calibrating against main-sequence stars, and then compute color temperature using the black-body radiation formula, we get the image below. The color looks much more normal.

Figure 5: After black-body radiation color-temperature calibration, the colors look normal

The bigger problem was the shape of the Milky Way. If you look closely, the image feels somewhat like the Milky Way and somewhat unlike it. Around the galactic center, there are many textures that do not appear in real photographs. For example, the central rift seems to split into two branches near the galactic center and then merge back together. From a distance, it even looks like the Chinese character zhong. This was a very strange problem, which meant either our data or our rendering process had a serious issue.

I was stuck here for quite a while. Many optimizations did not help. Eventually, I thought to extend the magnitude limit from 13 to 15, then 18, and even 20. Only after precisely integrating the flux from 600 million stars did the familiar Great Rift finally appear, as shown below.

Figure 6: Extended to G<18, 600 million stars, the Great Rift finally becomes cleanly dark. Click the image to open the 4K preview.

Comparing these two images, the main reason the previous one looked wrong becomes clear: the spatial positions of magnitude 13 stars and fainter stars are still not quite the same. Stars fainter than magnitude 13 are more concentrated on both sides of the rift. Although each star is very dim, their enormous number produces the faint glow around the galactic center, while also making the central rift more distinct.

This part of the simulation felt like solving the problem through brute force rather than cleverness. In the previous step, we introduced an empirical luminosity formula. It looked sophisticated and saved computation, but the approximation also introduced a ceiling that was hard to break through. Once we had enough data, we no longer needed the earlier trick at all. The most direct rendering formula produced a very good result. In a later article, we will use the same idea to simulate the turquoise band during a lunar eclipse, and we will see a similar lesson there.

Light Pollution and Wandering the Sky

At this point, the simulation itself was basically complete. The full-resolution 40-gigapixel Milky Way can be browsed here: https://yage.ai/gaia_milky_way/

But beyond looking like a photograph to the naked eye, is there a way to quantitatively verify that the simulation is correct? One idea is to introduce light pollution. On one hand, light pollution is a physical quantity that can be measured. Each Bortle dark-sky class corresponds to a range of background sky brightness, in magnitudes per square arcsecond. That lets us quantitatively simulate how the Milky Way appears under different light-pollution conditions. On the other hand, people are also familiar with how the Milky Way looks under different Bortle classes. For example, under Bortle 6 skies, you may still faintly catch a bit of the Milky Way with averted vision. At Bortle 7 and above, it is basically gone. Putting these two together makes this a good validation test.

So I tested how the Milky Way should look under Bortle 7 light pollution. My program confidently said: no problem, it is very clear. The result is shown below.

Figure 7: Under Bortle 7 light pollution, without the Weber threshold, the Milky Way is somehow still visible

That was strange. It meant our rendering pipeline still had a problem. After more research, I found that this was not a physics problem, but a physiology problem. The human eye has an important property: whether you can see something does not depend on its absolute brightness, but on how much brighter it is than the background. For example, when we say the human eye can see magnitude 6 stars under dark skies, that does not mean the eye can also see a diffuse nebula or glow whose total integrated magnitude is 6. When the sky background is bright, diffuse structures need to be much brighter to become visible. Therefore, we needed to use this property, technically called the Weber threshold, to calculate the Milky Way's relative brightness. After adding this physiological model, we quickly obtained a simulation that matched reality. The image below is the Milky Way under Bortle 7 light pollution:

Figure 8: After adding the Weber threshold, the Milky Way disappears under Bortle 7 light pollution, matching real observations

We failed many times along the way, but each failure gave us a valuable lesson, corrected an inaccurate understanding, and brought new knowledge. I think that training process, and the knowledge it produced, is more meaningful than getting the final image. I have learned a lot of astronomy and physics. I can explain many phenomena and even solve many problems. But the only real test of knowledge is practice. We built a simulation pipeline from what we had learned, and when its output was wrong, that meant our understanding was incomplete or incorrect. Continuously adding more factors, discovering which ones mattered and which ones did not, became an excellent learning opportunity in itself.

Simulation also has a major advantage over real photography: it opens up countless possibilities. For example, we live inside the Milky Way, so how do we know what the Milky Way looks like from the outside? The Gaia catalog gives us one route. If we know each star's right ascension, declination, and distance from us, then its position in three-dimensional space is determined. So in principle, we can place a virtual camera above the Milky Way and photograph it from above. Would that reveal a perfect spiral or barred spiral structure? Unfortunately, I tried simulating exactly that, and the result is shown below.

Figure 9: Simulated view from above the Milky Way, with no spiral arms visible because Gaia parallax distances only cover a few thousand light-years around the Sun

This does not mean our Milky Way really looks like this. It is a limitation of Gaia's distance measurements. Gaia uses parallax, which is the same principle as our ability to sense how far away an object is using two eyes. This method works well for nearby objects. For example, you can easily tell whether something one meter away or two meters away is farther. But it becomes useless for very distant objects. With the naked eye, it is hard to tell whether something 100 meters away or 110 meters away is closer. Gaia has the same limitation. Within a few hundred to a few thousand light-years, its distance measurements are still fairly accurate. But the Milky Way is on the scale of 100,000 light-years, far larger than that range. Therefore, for most stars, our grasp of their distances is very rough, and a clean spiral shape naturally cannot emerge from the data. At the same time, the direction of the galactic center contains a large amount of dust extinction, so our data is incomplete there as well. Together, these two factors produce the messy-looking image above. In fact, so far humanity has no way to directly photograph what the Milky Way looks like. The face-on Milky Way structures we see online are all indirect observational inference plus artists' imagination. In a sense, we had run into the boundary of current human technology.

Beyond this, we also ran many other experiments. For example, we can make a video showing how to start from a wide-field image and zoom all the way into very deep-sky photography at an astonishing magnification. We can also simulate what kind of Milky Way your camera would capture under different exposures, or what the Milky Way would look like under different light-pollution environments if humans had superhuman eyes. All of these simulation results are on the project homepage: https://grapeot.github.io/gaia_allsky/. The full code is open source as well. I am sure there is still plenty to improve in this implementation, and comments and feedback are very welcome.

Continuous zoom from the full sky into the galactic center at 1:1 scale. No audio.