Computing Life

使用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.

用好AI的第二步：先写Skill再执行

2026-05-26T14:10:00-07:00

在上一篇文章里，我们介绍了用好 AI 的第一步是停止使用聊天框（比如 ChatGPT 和豆包），而转用 Codex，Claude Code，Cursor 这样的本地 AI 工具。这篇文章发布以后，我们在社区和微信群里都得到了很多正面反馈。但同时也发现了两个问题。

第一是来自非技术背景的同学。他们在安装了 Claude Code和 Cursor 这些工具之后，觉得这明显是一个用来写代码的工具。很难想象怎么把这些工具用到自己的工作中去。所以稍微尝试了一下就放弃了。另一种是有技术背景的程序员们。他们觉得我每天都已经在用 Claude Code 了，所以这个文章的方法和他们无关，非代码的任务还是继续使用聊天框。

这两个问题表面上看起来关系不大，但其实反映了一个简单却深刻的工作方式的变化。这个变化就是先外化（externalize），再执行。这篇文章就想把这个思维方式讲解清楚：外化是手段，复用是目的，Skill是载体。写Skill是一个人人都能做的简单的方法，可以让AI越用越好用，有效集成到每天的工作里去。但注意这个Skill不是网上常见的怎么用搜索引擎或者怎么发小红书的Skill，而是更贴近工作场景的Skill，比如怎么做好特定领域的调研，怎么写出没有AI味的文章等等。

先外化，再执行

我们绝大多数时候工作的流程是这样的。拿到一个任务，复杂一些的可能会先在脑海中做个计划，简单的任务就直接上手做了。调研旅游攻略，买个火车票，做一道菜。没有人会先写个文档，介绍下面是我做西红柿炒鸡蛋的详细计划。我们就直接去切菜做菜了。大家唯一想着要外化或者说把怎么做这件事情写到文档里，是有分享需求的时候。比如这个城市特别好玩。我要把攻略写成一个帖子发在小红书上。或者我做的这道菜太牛逼了，我得把它写成菜谱发给朋友。

这是非常自然的一件事情。因为我们有记忆。下次再做的时候，自然而然就会想到之前的经历，以前踩过的坑。但像我们在上篇文章提到的，（绝大多数产品里）AI是没有记忆的。你每次点新建聊天按钮以后，它拿到的就是一张白纸，上面写着你的prompt，然后它开始答题。它在第一次调研的时候踩过一个坑，如果我们不记录下来写成文档的话，它下次还会踩同样一个坑。这个道理特别简单，但它是用好AI的关键。

换言之，外化是复用的前提。只有开始积累这些教训，积累好的方法，AI才能越来越聪明好用。这也是我们为什么说不要用云聊天框比如ChatGPT，而要用本地软件比如Codex的原因。本地才方便你把教训落盘成文档，下次跟AI说你先去读一下上次那个文件，它就不会犯同样的错了。这就是复用。

但这对我们大多数人来说是很难跨过的一个坎，因为这种先外化再执行的做事方法太奇怪了，和我们的生活完全不同。我买张火车票还得先做个计划？这不是脱裤子放屁嘛。但其实仔细想想，它很多时候反而是标准做法。比如我们雇一个家政来打扫卫生，我们会跟她仔细讲清楚。油烟机背后容易漏掉，要仔细擦。马桶内外都要刷干净。虽然没有写成白纸黑字的文档，但这本质上也是把评价标准和做事方法外化了。或者我们在工作中间带实习生的时候，也会手把手教很多实操的技巧和可能会踩的坑。这种时候我们已经潜移默化用上了先外化再执行的做事方法，只是没有把它落盘到一个严格的文档里而已。

程序员是一个更好的例子。他们每天的工作100%都是先外化再执行。这是因为程序员没办法越过电脑直接微操CPU上手做事，而只能通过程序来控制电脑干活。程序天然就是一种外化，用最清晰直接的语言向电脑介绍了你怎么完成一个特定的任务。也正因为如此可以直接复用。所以程序员们特别习惯先外化再执行的方法论，在AI时代从Mindset的角度占了一个重要优势。（但同时也带来了一个枷锁，下面我们再聊）

外化是为了积累复用，积累的载体是文档/Skill

所以回到我们最开始介绍的问题。尤其是对不做软件开发的同学，在 Claude Code 这样的工具里使用AI最关键的不是写程序。或者说写程序既不是我们的目标产出，也不是我们关注的重点。我们在用这些工具的时候，就应该像使用聊天框式的 app 一样，把同样的 prompt扔给它。比如“我明天想去西雅图玩。你帮我规划一下”，或者“这是我今天体检验血的报告，你帮我看看有没有什么问题”。为了完成我们的任务，AI可能会写一些代码，但它只是用来完成任务的一个手段或环节而已。（一个题外话是，Codex/Claude/Cursor这些app现在都有桌面版了，界面也都非常类似和友好，不用死磕命令行黑框框了）

但如果只是把同样的 prompt搬到 Claude Code 里面问，虽然会有更好的体验，比如 AI可以直接读到你本地的体检报告单，但仍然做不到质变。AI能力的质变发生在长期的积累和复用上。比如我今天花了半小时终于把 AI 和公司邮箱连起来了，下一次再用就不用从头再配置，而是可以直接跟它说。“你去看一下我的邮箱，然后去做XXX”。这些积累和复用就需要外化。

如果用普通的思路来看“把 AI 和公司邮箱连起来”这件事，它的结果就是 AI 下载了收件箱里的邮件。邮件下载完毕，这件事就结束了。但如果用外化和复用的角度来看，这件事的产出远不止于这一次下载到的几封邮件。我们可以积累一个指南性质的文档，下次AI只要看了这个文档就可以顺利地从公司邮箱中下载邮件。比如这个文档可能会说：“我们要用Outlook，不要用Mac默认客户端，我们先给它这个用户名，然后手机会弹窗，我们打开app刷一下脸。就可以下载邮件了。” 当我们有了这个文档以后，我们给AI的prompt 就可以变成：“你去看一下connect_mail.md这个文档。然后同步一下邮件。“ 在阅读文档以后，AI就知道去遵循这些指令，跳过所有的陷阱，顺利完成任务。这里第一次探索如何连接邮箱并且写文档的过程就是外化，而AI第二次用这个文档来完成任务的过程就是复用。

注意上面这个例子里，我们积累和复用的载体不是代码，而是知识或者说文档。这个文档可以是技术性的，比如怎么连接Outlook，更多的时候是非技术的。比如调研的方法（用google用中英文双语关键字多搜搜），思考的方式（写完以后开一个杠精AI来找逻辑漏洞），写文章的惯例（会议简报要控制在一页以内），甚至老板的喜好（配色用浅蓝色，不要出现绝对化的用词）。当这些抽象的东西都可以复用以后，我们可以想象一个长期调教后的AI可以组合完成非常复杂的任务。比如从公司的 wiki 里做调研，结合网络搜索，来完成邮箱里老板布置的任务，最终写一个符合公司规范的 PPT。我们就专心做最后的审核和方向上的指点就好。这种能力是原生豆包/ChatGPT无法比拟的。但一切的前提都是，我们用AI执行任务，不仅要抓执行结果，而且要把它怎么做这样的任务的心得/知识沉淀到文档里。

这里就要提一下技术人员/程序员很容易陷入的一个陷阱，就是认为只有代码才是积累和复用的载体。这和他们对”先外化再执行“的熟练程度是一脉相承的。在软件工程师每天的工作里，虽然他们的工作都需要先把思路外化成程序再让电脑执行，但这同时也带来了一种肌肉记忆，就是如果我们要复用一个东西，这个东西首先得变成代码的形式，构成了“AI就是用来写代码的”这种错误印象。所以在面对代码以外的知识资产的积累和复用上，程序员和非程序员其实站在同一个起跑线上。甚至他们受到固有经验的影响，接受文档复用比代码复用更重要这一点反而更难。

总之，使用 Claude code 这样的工具写代码确实很有用，但如果只用它写代码，就暴殄天物了。它更大的潜力是做一个通用的 AI 工具，在软件开发的领域之外用外化和积累自动化各种智能任务。只是 Claude code恰好也擅长写代码而已。这是程序员尤其需要注意克服的思维盲区。

怎么用，写和组织Skill

在上面的讨论里，我们一直用文档做例子来描述用 AI 过程中沉淀下来的知识。但在实际应用里，它可以以更丰富多样的形式出现。这个形式和目前网上流行的 Skill 很类似。我们这里也沿用Skill这个现成的概念。或者说，使用AI积累的关键，就是写好Skill。

但有一点要注意，很多厂商比如 Anthropic 和 OpenAI 在设计具体产品的时候，一大目标是把我们锁定在他们的平台上。比如它会要求我们用特定的格式（YAML文件）来写 Skill。但实际上，AI 是非常灵活和强大的。Skill 的核心不是格式本身，而是内容。一个写得很烂的 Skill，哪怕用 Anthropic 特定的格式写出来，它在Claude上也不会work。关键还是我们用自然语言向 AI 描述我们想要什么结果、要注意哪些东西。只要这个内容写到了，哪怕我们不用特定的格式，不走专门的步骤来安装 Skill，甚至它不叫 Skill 这个名字，我们仍然能够自如顺利地使用 AI。

具体地说，一个好的 Skill 需要包含三个关键要素。第一，我们需要向 AI 交代最终想要的东西，要满足什么条件，换言之就是成功标准。注意，这里面最关键的是对最终状态的描述，而不是给 AI 一个事无巨细的 SOP 让它跟着做。这个和我们向下属交代任务也非常类似。比如我们跟家政阿姨说怎么打扫的时候，只会让她知道油烟机不论正面反面油污要擦干净。而不会给她列个单子第一步用什么清洁剂怎么用力，第二步用什么顺序擦哪里。这样微操又累效果又不好。AI 也是一样。很多时候给AI如何做的细节反而是一种阻碍。更好的方法是告诉它我想要什么，至于怎么做，是它自己去搞清楚。这种写提示词的方法叫 prompt for enablement。

第二个要素是，在这个过程中会踩什么坑、犯什么错误。这个是积累经验中最直接能看到改进的地方。在家政阿姨的例子里，就是油烟机别只看正面，背面也有很多油污别忘了擦。在AI里，比如 Claude 写作的时候老用破折号，我们就可以在这里加一句：写作的时候注意不要用破折号。或者我在调研的过程中发现，Tavily 这个搜索引擎的质量比 Google 还好，我就会在这里加一句：你做搜索的时候优先使用 Tavily。注意在写作过程中，我们要只把 AI真正犯过错的东西放进来，而不要事先去猜 AI可能会犯什么错。这是因为现在的 AI 都非常聪明了。犯错的概率其实不高。如果我们在这里写一大堆它可能犯，但实际上并不会犯的错误，反而是一种干扰。

第三个要素则是一些确定性的工具。比如AI怎么跟 Google 通信，给它一个关键字，它返回搜索的结果。这个东西是定死的，不需要每次都重复去现场探索。而完全可以给 AI 一个现成的工具，说你就用这个工具去拿到搜索结果。这个具体工具可以有很多形式，比如飞书有 CLI，跟着它的指令让 Codex 能调用到它就可以。Tavily有 MCP，在 Codex 里面把它加入 MCP 的配置就好。Gmail有Connector，在 Codex 的 connector 页面启用并且连接 Gmail 邮箱就好。对于这些都不支持的工具，比如微信聊天记录的读取。我们可以让 AI 上网搜索，或者自己写一个 CLI或者 MCP 出来。这里面工具的具体形式都不重要。关键是它把一个不需要太多智能，但需要反复执行的动作。让 AI 可以可靠地直接调用，而不是每次都从头摸索怎么办。

因此，当我们用本地的 AI 工具完成任务的时候，沉淀的过程特别简单。就在已有的 prompt 之外额外加一句“你把它写成一个 Skill “就可以。你可能已经注意到了，上面的prompt并没有具体跟它描述一个 Skill 要包含哪三个要素，怎么去写。这是因为这本身就是一个现成的复用的例子。我已经帮你沉淀好了，写了一个如何写 Skill 的 Skill。你只要把这个网址贴给 AI，或者放在本地让它能读到，它就知道怎么去写 Skill。比如对前面连接邮箱的例子，我们的 prompt 就可以是：“帮我探索一下如何连上公司的邮箱，并且根据<替换成前面的网址>，在成功之后把它写成一个 Skill，方便我下次复用。” 这样当 AI 做完探索工作以后，它就会自主地总结经验教训，或者更新上次写好的文档，来让以后的 AI 可以完成这样的任务。

事实上，我正好也写了一个针对 Outlook 的 Skill，分享在 GitHub 上。大家也可以去看一下这个 Skill 的结构，看看我们是怎么向描述成功标准的，我们给它提供了什么工具，这些工具是怎么帮它完成一些确定性的任务的。

当我们开始积累 Skill 之后，很快我们就会遇到一个问题，就是怎么组织 Skill。这个也非常简单。Skill 的核心就是一系列的自然语言文档，只要让 AI 能读到那个文档和调用相关的工具，这个 Skill 就可以被 AI 用起来。

我组织的方式是这样：把所有的 Skill 放到一个单独的 Skills 文件夹下面，然后新建一个 index.md，描述什么情况下应该具体去看哪个 Skill。这里是一个例子。然后把这个文件的路径放到 AGENTs.md 或者 CLAUDE.md 里面就好。这两个文件比较特殊，Codex 每次新建一个对话的时候都会自动加载 AGENTs.md 里面的内容。比如我们给了个prompt，“帮我用Skill同步outlook邮件” Codex 首先根据我们的AGENTs.md 自动加载的内容找到并且去读取我们的 Skills/index.md，然后根据这个index.md的内容找到 Outlook 相关的 Skill，进一步读取Skill文件，再遵循Skill 文件的指示，去调用我们的命令行抓取邮件。整个流程说穿了就是AI像人一样一步步读文档，根据文档指示干活，没有复杂的代码和发现机制，也不用被各个厂商的特定格式绑架。

用好AI关键在Skill的积累

归根结底，Skill可以让 AI 能够有效地复用和积累它在工作过程中学到的知识。我们在实际工作的过程中要有一个新的意识：知识类的智能工作也是可以复用和自动化的。如果我们发现自己做某个任务做了两三次，或者预见未来会重复做这个任务的话，一个很好的方法就是先写 Skill，再让 AI 照着 Skill 去执行。而且这个写作的过程并不会拖慢我们的速度——我们完全可以在之前给 AI 的 prompt 后面加一句：“根据写 Skill 的 Skill，先写一个 Skill 出来，然后照着它做。做完了以后根据学到的知识更新 Skill 文档”，就可以了。

这种先外化再执行的习惯，会从根本上改变我们手上 AI 进化的效率，从而让我们可以把更多的事情交给AI做，我们专心做真正需要判断的脑力活。

PS：我也整理和开放了十几个我积累的Skill：[github]，大家可以直接使用，也可以做参考看看写Skill的基本方法。

Step Two to Using AI Well: Write the Skill Before You Execute

2026-05-26T13:10:00-07:00

In the previous post, we covered step one: stop using chat boxes (ChatGPT, Doubao, and the like) and switch to local AI tools such as Codex, Claude Code, and Cursor. That piece got strong feedback in our community and WeChat groups. It also surfaced two recurring reactions.

The first comes from people without a technical background. After installing Claude Code or Cursor, they conclude these are clearly tools for writing code. They cannot picture how to apply them to their own work, try briefly, and quit. The second comes from programmers who already use Claude Code every day. They assume the article does not apply to them and keep using chat boxes for non-coding tasks.

These two reactions look unrelated, but they point to the same shift in how work should run: externalize first, then execute. This post is about that mindset. Externalization is the means; reuse is the goal; the Skill is the container. Writing Skills is a simple habit anyone can adopt so AI gets better over time and actually fits daily work. The Skills here are not the viral how-to-search or how-to-post-on-Xiaohongshu templates. They are work Skills: how to run domain research, how to write without sounding like AI, and similar.

Externalize First, Then Execute

Most of the time we work like this: get a task, maybe plan in our head if it is complex, otherwise just start. Research a trip, buy a train ticket, cook a dish. Nobody writes a document first that says here is my detailed plan for tomato and egg stir-fry. We chop and cook. We only externalize, write down how something is done, when we want to share: this city is great, turn the guide into a Xiaohongshu post; this dish is excellent, write the recipe for a friend.

That is natural because we have memory. Next time we remember what worked and what traps we hit. As we said in the last post, in most products AI has no memory. Each new chat starts from a blank slate plus your prompt. If it falls into a trap on the first research pass and you do not record that trap in a document, it will fall into the same trap again. The idea is simple; it is also the key to using AI well.

Externalization is the prerequisite for reuse. Only by accumulating lessons and good methods does AI get smarter and more useful. That is also why we argue for local tools like Codex instead of cloud chat boxes like ChatGPT. Locally you can persist lessons as files and tell AI to read last time's file first, so it does not repeat the same mistake. That is reuse.

For most of us this is a hard habit to adopt because externalize-then-execute feels alien compared with normal life. Make a plan before buying a train ticket? That sounds like busywork. But it is often standard practice. When we hire a cleaner, we spell out expectations: do not miss grease behind the range hood; scrub inside and outside the toilet. We may not put it on paper, but we are externalizing standards and method. When we mentor an intern, we teach tricks and pitfalls by hand. We are already using externalize-then-execute; we just have not written it into a formal document.

Programmers are an even clearer example. Their work is externalize-then-execute all day. They cannot micromanage the CPU directly; they control the machine through programs. A program is externalization in a precise language that tells the computer how to complete a task, and therefore it can be reused directly. Programmers are used to this mindset, which gives them an advantage in the AI era. It also comes with a trap we discuss below.

Externalize to Accumulate Reuse; Documents and Skills Are the Container

Back to the opening problem. For people who are not building software, the point of using AI inside Claude Code is not writing programs. Code is neither the goal nor the focus. You can use these tools like a chat app and throw the same prompts at them: plan my day in Seattle tomorrow; here is today's blood test report, flag anything odd. AI may write code along the way, but code is only a step toward the outcome. Side note: Codex, Claude, and Cursor all have desktop apps now with friendly UIs; you do not have to live in a terminal.

Moving the same prompts into Claude Code improves the experience, for example AI can read your local lab report, but that alone is not a step change. The step change comes from long-term accumulation and reuse. You spend half an hour connecting AI to company email once; next time you say read my inbox and do X without redoing setup. That accumulation and reuse require externalization.

If you view connect AI to company email in ordinary terms, the outcome is downloaded mail and the task ends. From an externalize-and-reuse view, the output is not only this batch of messages. You also produce a guide document so the next run can fetch mail without rediscovering every trap. The doc might say: use Outlook, not the Mac default client; give this username; approve on the phone app; then download. Once the doc exists, your prompt becomes read connect_mail.md and sync mail. After reading, AI follows the instructions, skips traps, and finishes. The first pass, explore plus write the doc, is externalization. The second pass, follow the doc, is reuse.

In that example the container for accumulation is not code but knowledge in document form. It can be technical, like how to connect Outlook, or non-technical: research habits (search in Chinese and English), review habits (run a devil's advocate pass on logic), writing norms (one-page meeting briefs), even manager preferences (light blue palette, avoid absolute wording). When these abstractions become reusable, a tuned AI can chain complex work: research the company wiki, search the web, execute the task from the boss's email, draft a deck that matches company style. You focus on review and direction. Native Doubao or ChatGPT cannot match that unless you also capture how the task was done, not only the deliverable.

Technicians and programmers often fall into a trap here: only code counts as something you can accumulate and reuse. That matches how practiced they are at externalize-then-execute in software. Daily work turns ideas into programs before the machine runs them, which trains a reflex: if we want reuse, it must become code. Hence AI is for coding. For knowledge outside code, programmers and non-programmers start on similar ground. Programmers may actually find it harder to accept that document reuse can matter more than code reuse.

Using Claude Code to write code is valuable. Using it only for code wastes most of its value. The larger opportunity is a general AI workspace that externalizes and automates knowledge work outside software development. It happens to be good at code too. That blind spot is worth correcting if you are a programmer.

How to Write and Organize Skills

Above we used documents as the example for knowledge captured while using AI. In practice the form can vary. It aligns with the popular Skill idea, and we keep that name here. The key to accumulation with AI is writing good Skills.

One caveat: vendors like Anthropic and OpenAI often design products to lock you in. They may require a specific YAML format for Skills. AI is flexible. The core of a Skill is content, not format. A poorly written Skill in the official YAML will not work on Claude. What matters is describing in natural language what outcome you want and what to watch for. If the content is there, you can skip vendor format, skip install steps, or even skip the word Skill and still use AI smoothly.

A good Skill has three elements.

First, success criteria. Tell AI what the end state should satisfy, not a step-by-step SOP. This mirrors delegating to a person. With a cleaner you say grease on the range hood must be gone front and back; you do not list which cleaner, pressure, and order for every surface. Micromanagement is tiring and weak. The same applies to AI. Detailed how-to often hurts. Better to state what you want and let AI figure out how. That style is called prompt for enablement.

Second, known pitfalls and mistakes. This is where accumulated experience shows up fastest. For the cleaner: do not only wipe the front of the hood; the back is greasy too. For AI: if Claude overuses em dashes in writing, add do not use em dashes. If Tavily beats Google in your research, add prefer Tavily for search. Only record mistakes AI actually made. Do not pre-list guesses about errors it might make. Modern models are strong; low error rates mean a long list of hypothetical failures becomes noise.

Third, deterministic tools. Example: call Google with a keyword and return results. That path is fixed; you should not rediscover it every session. Give AI a ready tool and say use this for search. Forms vary: Feishu CLI wired into Codex; Tavily via MCP in config; Gmail via Codex connectors. For unsupported cases, like WeChat chat history, AI can search the web or you build a CLI or MCP. The form matters less than making a low-intelligence, high-repeat action callable reliably instead of re-explored each time.

When you finish a task with a local AI tool, capturing a Skill is easy: add one line to your prompt, write this up as a Skill. You may notice we did not spell out the three elements in that prompt. That is intentional reuse. There is already a Skill for writing Skills. Give AI this link or a local copy. For the email example: explore how to connect company email, follow the guide at that URL, and after success write a Skill for next time. AI will summarize lessons and update the doc so future runs inherit them.

I also published an Outlook Skill on GitHub. You can inspect how success criteria are stated, which tools are provided, and how those tools handle deterministic steps.

Once Skills accumulate, organization is straightforward. Skills are natural-language documents. If AI can read the doc and call the tools, the Skill works.

My layout: put all Skills under one folder, add index.md that says which Skill to open in which situation. Example index. Point to that index from AGENTS.md or CLAUDE.md. Codex loads AGENTS.md on each new session. Prompt: sync Outlook mail using the Skill. Codex reads AGENTS.md, then Skills/index.md, then the Outlook Skill file, then runs the CLI to fetch mail. Under the hood AI reads docs step by step like a person. No heavy discovery layer and no need to obey a vendor-specific Skill format.

Skill Accumulation Is the Lever for Using AI Well

Skills let AI reuse and compound what it learns during work. Build a new reflex: knowledge work can be automated and reused. If you have done a task two or three times, or expect to repeat it, write the Skill first and let AI execute against it. That does not slow you down. Append to your prompt: using the Skill-writing Skill, draft a Skill first, follow it, then update the Skill with what you learned.

The externalize-then-execute habit changes how fast your AI stack improves. You hand off more execution and keep judgment work for yourself.

PS: I collected and open-sourced a dozen Skills [on GitHub]. Use them directly or as references for how to write Skills.

AI如何导致和修复了我的失眠问题

2026-05-11T17:00:00-07:00

三月底，我的睡眠出现了比较严重的问题。经常一整晚只能睡两三个小时。我一开始以为是工作压力过大。但后来即使在quit job以后，这种情况也没有好转。幸运的是，经过一些分析和实验，我迅速找到了原因。并且把每晚的平均睡眠时间往上提了一小时四十分钟。这篇文章主要想分享一下作为重度AI用户的我，如何用一种不同寻常的方式迅速找到那个失眠的原因（剧透：原因是晚上仍然用AI高强度多线程思考）。也反思了一下在整个过程中哪些环节是AI真的帮到了我的，哪些环节仍然必须靠自己。

非主流的失眠诊断

我先简单介绍一下整个问题是怎么发展和解决的。在失眠刚开始的时候，我做的事情检查也和大多数人一样，就是瞎猜：是不是咖啡/酒喝多了？是不是褪黑素吃少了？是不是晚上吃撑了？瞎试了两个星期之后并没有好转。所以我决定需要用一种更科学的方法去搞清楚睡眠不好的原因到底是什么。

具体地说，我花了5分钟让AI写了一个app。这个app会读取我的苹果手表和手机里的HealthKit的数据，导入到电脑里。这些数据包括了我平时摄入了多少咖啡因，多少酒精。每天晚上的入睡时间，睡眠情况（包括REM，深睡时间段等等），甚至包括血糖，血压，体重等等，总之就是可穿戴健康那坨东西。除此之外，我的电脑上还有一些其他数据。包括我每个小时做了什么事情等等。总之，我做的第一件事情不是去猜测具体的原因，而是从各个渠道搜集到繁杂琐碎但是全面的信息，来为下一步的分析提供弹药。

第二步是我把这些信息全部扔给AI，让它去做一个分析：根据我的这些原始数据，有没有什么因素可以会导致我晚上睡不好？AI选择的路线是去做一个多变量回归分析。看看有哪些变量和晚上的睡眠时间呈明显的负相关。具体建模啥的是他写程序来弄。最后的结果比较有意思：其中有一些变量是相关的，但是意义不是特别大。比如他发现如果我晚上入睡时间特别晚，一般来说睡眠时间就比较短。但这个是废话。我要是能睡着，我肯定早入睡啊。。还有一些变量是意外的不相关。比如喝咖啡不论是喝几杯还是几点钟喝，和当晚睡眠时间关系都不大。这可能是因为我反正都是在中午前喝。到晚上睡觉的时候已经代谢的差不多了。

那具体什么变量最相关呢？我们发现是我晚上最后一次使用AI的时间。换言之，如果我晚饭后仍然在使用AI，不管它是正经写代码，还是用AI来学习，还是写文章。只要用了AI，那一晚基本上都睡不好。用的越晚，睡得越不好。相反，如果我晚饭后不用AI，即使做一些不健康的事情，包括打游戏，刷视频，聊微信，那一晚睡得一般都会比较好。

所以下面的事情就比较简单了。我就开始晚上有意识地不用AI，宁愿刷刷短视频聊聊天。这样过了几个星期，发现平均睡眠时间比之前长了一小时四十分钟，到了一个比较健康的水平。而且这个过程中我也体会到了为什么使用AI会影响睡眠。这主要是因为AI帮我们把体力活都做完了，所以剩下的任务一般都是高强度的阅读和思考，很容易把人变得兴奋。同时我使用AI的时候一般懒得等，都是多线程操作，同时开好几个AI车轮战。这样完全没有休息的机会，人的大脑一直处于紧绷/高强度创新/高强度工作的状态。这种状态很容易一直持续下去，影响睡眠。

为什么非主流，AI帮到了我什么

这件事虽然本身没有什么波折，但我还是觉得它非常有意思。从结果上来看，虽然我们在确定了AI的使用会影响睡眠之后，看一切都很合理。但如果我们不做这种多变量分析，而是主要依赖搜索引擎和经验去拍脑袋想原因的话，这件事情其实并不好想。一方面，AI是一个相当新的东西。不论是文献还是网上的文章，都不太会把它和失眠联系起来。所以单纯搜索很难想到这一点。另一方面，直观想象，大家会把AI和打游戏、刷视频之类的行为归在一起。但我晚上确实没有刷视频、用手机，只是睡前在电脑上用AI做了一些学习。这个也很难意识到它会严重地影响睡眠。因此，如果我们没有一个科学系统的归因分析，只去单纯凭借印象或者搜索去做诊断的话，我相信会走一条很大的弯路。

从过程上看，我就算有了去做多变量回归做归因分析这样的想法，如果没有长时间AI使用的积累，这件事也很难变为现实。一方面是没有数据，一方面是摩擦太大。从数据的角度来说，关注过健康的人可能都知道苹果的HealthKit里面有非常多的信息。但是包括我在内，一开始都没有意识到这些信息是可以导出来的。毕竟苹果的Healthapp并没有提供原生的导出功能。但是我又确实看见过一些app，尤其是比如说Withings这些厂商的健康app可以和HealthKit接起来，拿到它的数据。所以我就去问AI，有没有可能我们就也写一个app，把它的数据导到电脑里。然后AI就把它写出来了。有了这些数据，我们才有可能去做有效的分析。毕竟，在几十天的数据上做多变量分析，比拍脑袋想一个假设，试几天，然后再想一个假设，再试几天，效率是数量级的差距。

另外我为什么选多变量归因分析这条路，一个很重要的原因也是我知道AI可以帮我写程序。如果要我自己去写Python，清理数据，做建模，调参数，写报告。不是说不可能，但不会把它放到很早的阶段去做。我可能会先走一段时间弯路，试一些可能不work的方法，然后再去试这些我确定它是最终正确的，但需要投入一段dev time去认真做的方法。就总之AI在整个过程中提供的是执行力的支持。它让我有足够的信心和comfort level去一开始就去做一个正确的方法。

其中还有一个决策我觉得应该拎出来讲一下。就是我（或者说AI）写的那个app，它的用户不是人，它的用户是AI。这和传统的软件开发思路是很不一样的。如果是传统的软件开发，写app是为人/用户写的。那这个app的架构应该是：我点一个按钮，它搜集HealthKit的数据，然后和服务器端的某个数据分析功能进行通信，做了建模等等之后，把结果拿回来，在这个app里进行可视化。比如告诉我你失眠的原因是一二三。

而我做失眠分析这件事，是完全反过来的。这个app的用户是AI，AI去调用这个app来拿到数据，然后去调用Python进行数据分析，把结果在他的对话界面（而不是我们用来导出数据的iOS app）里面呈现给我。换言之，我通过对话操纵AI，AI通过某些界面操纵软件。在整个过程中我们虽然写了软件，但是软件的用户都不是人类。就算由于iOS的限制，我需要点一下屏幕启动这个手机app，才能让它导出数据。但在这个过程里，我只是AI的工具人，如果他有手完全可以（而且应该）把我踢了自己点屏幕。

哪些事情还是得靠自己

AI在很多方面帮助到了我之外，我觉得还有一个同样有意思的侧面，是在这整个过程中，哪些事情我还是只能靠自己。其中我觉得有一个核心是comfort level，或者说对一个任务难度的判断。比如，如果我以前没有做过iOS开发，没有买过Mac，没有真的动手编译和部署AI写的iOS app的话，我很可能也不会选这条路。很多时候我们理性的知道编译部署一个iOS app应该不难。但当我们没有做过这件事的时候，心理上还是有道坎。它会让我们若有意若无意地绕开这个方向，即使我们理性地知道这个方向是最优解。

这就是我们以前在这篇文章里面曾经写过的成本结构决定最优策略。在那篇文章里，我们提到过，如果从第一性原理出发，debug的正确方法应该是通过打log把程序运行的内部状态暴露出来，然后从log出发分析bug在哪。但是短时间阅读上万行的log对人类而言是个不可能的任务，所以我们只能抛弃这条正确但是不切实际的道路，去凭经验猜测bug的位置。而且我们会把这种本来根本就不应该有，完全由人类弱鸡催生出来的需求叫做技术直觉，在各种场合极尽推崇。但是有了AI以后，读成千上万行的log并且找到哪里不对，是一个非常简单的事情。所以我们的成本结构变了，相应的debug的最优策略也应该改变。

我们的场景也是类似的，以前我们会觉得数据建模很麻烦/昂贵，写一个iOS app更是难如登天。这是为什么我们理性的选择了失眠要去网上做调研，要去自己猜原因，做实验。但是在2026年，尤其是我个人的情况里，我戴苹果手表，自然有了很多睡眠方向的方面的数据。我每天会记录喝了多少咖啡，多少酒，吃了几片褪黑素，这又进一步降低了数据方面的障碍。同时我又知道AI可以非常方便地进行数据建模。这三者一起让多变量归因分析这条路在这个场景下是一个低成本的选择，也指引着我走向了这个方向。

换言之，我们平时点的技能点，做过的project，已有的经验，对一件事潜意识里的comfort level，构建成了我们对整个世界的成本结构的理解。它会潜移默化地决定我们每个人面对一个问题时会如何思考，如何解决。AI可以在具体执行上客观地改变这样的成本结构。但是我们理性地知道和感性的认同是完全不同的两件事。只有我们真的去做过，体验过，才能把这种成本的变化，这种comfort level的变化内化贯彻到我们的决策过程中。这一步是AI没办法代劳的。只能我们自己不断去尝试，分析和总结。

而在面对很多事情的comfort level中，对AI的comfort level尤其重要。比如去写这个iOS app。如果是一两年前的我会选择正襟危坐在电脑前，打开cursor这样的app，把它当做一个软件工程项目来写。比如我先做设计，然后把它当做一个junior engineer，给它非常具体的指导，然后去做code review。最终可能两三个小时之后，写出来了这个app。我相信直到今日这都是AI编程的主流用法，而且相比于AI之前确实已经是很多倍的提效。但我们也可以想象，如果写这个app需要几个小时的话，我又不会选择这条路了。

我实际上选择的方法是，直接在手机上跟AI用语音一两分钟描述了一下我想要一个什么样的app，然后就去干其他事了。它就去写去测试，我等它写好了以后去Mac上点一下运行，出了个bug，我把log贴给它，它修好了。我抽查了一下传到电脑上的数据跟HealthKit里的数据一样，这件事就结束了。全程dev time大约五分钟。换言之，就算我们知道这个app应该让AI写而不是自己写，对AI独立完成整个任务的comfort level的差异，也会造成数量级上的效率差异，并且导致整个技术决策完全不同。

还有一个有意思的细节是，在决定写这个app之前，我也不确定能不能把HealthKit里的数据导出来。但因为我平时观察到了Withings这样的app可以读取HealthKit的数据，所以我决定去问一下AI。这种观察能力也是短时间内AI取代不了的。事实上很多时候我们问AI一个问题，它会给一个偏保守的回答，说做不了。这个时候如果你给它一个观察，比如那另一个app是怎么做出来的？它就可以做出更有针对性的调研，最终得出正确的技术方向。

结语

总的来说这是一个开心也不开心的故事。我很开心的一点是睡眠问题终于解决了，而且用的是一种principled方法，用正确的途径，简单地解决；而不是经历了没头苍蝇一样的尝试，瞎猫撞上死耗子试出来的。AI在这个过程中帮到我的不仅是执行，而且是重塑了我对很多东西的comfort level，让我可以在更广的场景下收敛到这种principled的方法。但坏消息是，如果没有AI的话，这个问题根本就不存在。我也不用去想失眠的问题😂。但总的来说毕竟是帮我想清楚了很多问题，还是挺有收获的。

How AI Caused and Fixed My Insomnia

2026-05-11T16:00:00-07:00

Around late March, my sleep took a serious hit. I would often get only two or three hours per night. At first I blamed work stress, but even after quitting my job, the problem persisted. Fortunately, after some analysis and experimentation, I quickly found the root cause and added back an average of one hour and forty minutes to my nightly sleep. This article shares how a heavy AI user like me took an unconventional approach to diagnose an unexpected insomnia trigger (spoiler: it was using AI for intense, multi-threaded thinking late at night), and reflects on which parts of the process AI genuinely helped with and which still depend on human judgment.

An Unconventional Insomnia Diagnosis

Let me walk through how the problem unfolded and got resolved. When the insomnia first started, I did what most people do: I guessed. Too much coffee or alcohol? Not enough melatonin? Eating too late? After two weeks of trial and error with no improvement, I decided to take a more scientific approach.

Specifically, I spent five minutes having AI write an app. It reads HealthKit data from my Apple Watch and iPhone and exports it to my computer—caffeine intake, alcohol consumption, bedtime, sleep stages (REM, deep sleep, etc.), even blood glucose, blood pressure, and weight—essentially everything my wearables track. On top of that, my computer had additional data like what I was doing hour by hour. The point is, my first move wasn't to guess the cause; it was to gather messy but comprehensive information from every available source to fuel the next step.

Step two was feeding all this data to AI and asking it to analyze whether any factors correlated with poor sleep. AI chose to run a multivariate regression, looking for variables with a significant negative correlation with sleep duration. The results were interesting. Some correlations were technically present but trivial—for instance, later bedtimes correlated with shorter sleep, which is a tautology: if I could fall asleep early, I would. Others were surprisingly absent, like caffeine. Neither the number of cups nor the time of day I had coffee showed any meaningful correlation with that night's sleep, probably because I always finish my coffee before noon and it's mostly metabolized by bedtime.

So what variable was most correlated? The time of my last AI usage that evening. If I used AI after dinner—whether for coding, learning, or writing—I almost always slept poorly. The later the usage, the worse the sleep. Conversely, if I avoided AI after dinner and did "unhealthy" things like gaming, watching videos, or chatting on WeChat, I generally slept fine.

The fix was straightforward. I consciously stopped using AI in the evenings, opting instead for mindless scrolling or chatting. After a few weeks, my average sleep increased by one hour and forty minutes, reaching a healthy level. Along the way, I also understood why AI affects sleep. AI handles the grunt work, so what's left for us is usually high-intensity reading and thinking that keeps the mind wired. And when I use AI, I rarely sit idle waiting—I run multiple AI sessions in parallel, cycling through them in a tag-team fashion. There's no downtime. My brain stays in a constant state of tension, high-intensity innovation, and high-intensity work. That state lingers and interferes with sleep.

Why the Non-Obvious Diagnosis, and Where AI Helped

This story may seem straightforward in hindsight, but it still fascinates me. If we had relied on search engines and intuition instead of multivariate analysis, we probably wouldn't have arrived at the right answer. For one, AI is still new enough that neither academic literature nor online articles connect it to insomnia—you wouldn't think to search for it. For another, intuition lumps AI with gaming and video watching. But I wasn't using my phone or watching videos before bed; I was studying with AI on my computer. It's hard to connect that with severe sleep disruption. Without a systematic causal analysis, relying purely on gut feeling or search would have led me down a very long detour.

Even if I had thought of multivariate regression as an approach, it wouldn't have been feasible without my long track record of using AI. Two reasons: data and friction. Health-conscious people know that Apple's HealthKit stores a wealth of information, but like most people, I didn't realize it could be exported—Apple's Health app has no built-in export feature. However, I noticed that third-party apps like Withings could read HealthKit data, so I asked AI whether we could write an app to extract that data to my computer. AI wrote it. With actual data in hand, running multivariate analysis across dozens of days becomes dramatically more efficient than guessing one hypothesis, testing it for a few days, guessing another, testing again—the difference is orders of magnitude.

Another reason I chose the multivariate route is that I knew AI could handle the coding. Writing Python from scratch to clean data, build models, tune parameters, and produce reports isn't impossible for me, but it wouldn't have risen to the top of my priority list early on. I would have tried several wrong approaches first before committing the dev time to the "correct but expensive" method. AI provided execution support that shifted my decision timeline.

One design decision worth calling out: the app I (or rather, AI) wrote isn't for human users—it's for AI. That's completely different from traditional software development. In a conventional app, the architecture would be: I tap a button, it gathers HealthKit data, communicates with a server-side analytics engine, processes the data, and visualizes the results in the app. It would tell me, "Here are the three reasons for your insomnia."

My insomnia analysis was the opposite. The app's user is AI. AI calls the app to fetch data, then runs Python for analysis, then presents the results in its chat interface (not in the iOS app that exported the data). In other words, I manipulate AI through conversation, and AI manipulates software through its interfaces. Throughout the entire process, while we wrote software, none of it had a human as its end user. Even though iOS requires me to tap the screen to start the export, I'm just AI's proxy—if it had hands, it could (and should) tap the screen itself.

What Still Depends on You

Beyond what AI helped with, there's an equally interesting side to this story: what still required human judgment. I think the core factor is comfort level—our intuitive sense of how hard a task is. If I had never done iOS development, never owned a Mac, never compiled and deployed an AI-written iOS app, I probably wouldn't have chosen this path. We rationally know that compiling and deploying an iOS app isn't that hard. But without having done it, there's a psychological barrier. It subtly nudges us away from a direction even when we know it's the optimal solution.

I've written about this before: cost structure determines optimal strategy. In that article, I argued that from first principles, the correct way to debug is to instrument your code with logs, expose internal state, and reason from those logs. But reading tens of thousands of lines of logs in a short time is impossible for a human, so we abandon the correct but impractical path and guess where the bug is instead. We even rebrand this necessity as "engineering intuition" and celebrate it. With AI, however, reading through thousands of lines of logs to find the anomaly is trivial. The cost structure shifts, and the optimal debugging strategy shifts with it.

The same logic applies here. In the past, data modeling felt like hard work and writing an iOS app felt like climbing a mountain. That's why we instinctively reach for web searches and guesswork when diagnosing insomnia. But in 2026, I happen to wear an Apple Watch, giving me a rich sleep dataset. I already track my coffee, alcohol, and melatonin intake daily. And I know AI can handle the modeling effortlessly. These three factors together make multivariate regression a low-cost option in this specific scenario, steering me toward it.

In other words, our accumulated skills, past projects, experiences, and subconscious comfort levels constitute our internal model of the world's cost structure. That model silently determines how we approach each problem and what solutions we consider. AI can objectively change this cost structure by making execution cheaper. But knowing something rationally and feeling it viscerally are completely different. Only by actually doing something, experiencing it firsthand, can we internalize this cost shift into our decision-making. That step AI cannot take for us. We have to iterate, analyze, and internalize it ourselves.

Among all the comfort levels we build, comfort with AI is especially important. Take building the iOS app. A year or two ago, I would have sat down at my computer, fired up Cursor, and treated it as a software engineering project. I'd write a design doc, treat AI like a junior engineer with very specific instructions, then code review its output. The whole thing would take two or three hours. I suspect this is still how most people use AI for coding—and it's certainly many times faster than before AI. But if writing the app takes hours, I wouldn't have gone down that path either.

What I actually did was describe the app I wanted to AI with my voice on my phone—about a minute or two of talking—then went about my day. AI wrote and tested it. When it was ready, I went to my Mac and clicked Run. There was a bug. I pasted the log back to AI. It fixed it. I spot-checked the exported data against HealthKit to confirm it was correct. Done. Total dev time: about five minutes. In other words, even when we know intellectually that AI should write the code, the difference in comfort level with letting AI work independently leads to orders of magnitude in efficiency and completely different technical decisions.

One more subtle detail: before writing the app, I wasn't sure whether HealthKit data could be exported. But I had observed that apps like Withings could read HealthKit, so I asked AI about it. That kind of observational ability is hard for AI to replace anytime soon. In practice, when you ask AI a question, it often gives a conservative answer: "can't be done." But if you provide an observation—"well, how does that other app do it?"—AI can research more effectively and arrive at the right technical direction.

Closing Thoughts

All in all, this is a story I'm both happy and unhappy about. I'm happy that the sleep issue is resolved and, more importantly, resolved through a principled approach—the right method applied cleanly—rather than random trial and error that happens to work. AI helped not just with execution but also with reshaping my comfort level across many domains, letting me converge on principled methods in more scenarios. The unhappy side? Without AI, this problem wouldn't have existed in the first place, and I wouldn't have needed to debug my insomnia at all😂. But on balance, it clarified a lot of things, so it was worth it.