Direct Light App 复盘.

    我不是导演，不是摄影师，不是灯光师，更不是程序员。

    我在软件公司做高管，管过团队，干的活说白了就是让一群聪明人朝同一个方向使劲，然后保证这群人不要在半路上互相掐死。我对技术的理解大概停留在"知道这事儿大概需要几个人干多久"的层面，让我自己写一行代码？你不如让我用筷子夹水。

    后来机缘巧合去了个剧组帮忙。注意，这里的"帮忙"不是那种体面的帮忙，不是什么副导演、场记之类有头有脸的角色。我就是个后勤，打杂的，满打满算待了不到一个月。

    但就这不到一个月，有一个场景像钉子一样扎进了我脑子里，到今天都没拔出来。

调灯。

    剧组调灯的时候，简直像一场大型玄学仪式。灯师把灯架摇上去，导演和摄影指导盯着监视器，皱眉，然后开始比划。"往左一点""高一点""感觉有点硬"。灯师爬上去拧，下来看，不对，再爬上去。演员在旁边站着等，场务在旁边站着等，制片人在旁边站着看表，全组人都在等一盏灯找到它命中注定的位置。有时候一个光位能磨大半个小时。演员走位也是，导演说"你往左半步"，演员一动，灯光关系全变了，又得从头调。

    我当时站在一旁搬东西，脑子里就冒出一个特别朴素的想法：这帮人为什么不能提前在电脑上模拟一下？

    不需要多精确。就是一个白棚，一个人，一盏灯，地上有影子。灯往左挪，影子会跟着变化。灯要是抬高了，影子就趴下去了。导演和摄影指导在电脑上先把大方向定了，到了现场直接按方案来。你知道这能省多少时间？多少钱？而且现在不光是传统拍电影了，AI短剧也在起来，很多团队就几个人，节奏快预算紧，更需要在开拍前把灯光方案沟通清楚。甚至在找演员之前就可以先拿这个工具聊："你看，这个场景大概是这种光，人站这个位置，你觉得怎么样？"

    这个念头在我脑子里赖了很久，赖到我终于忍不住了。

    但有念头归有念头，我非常清楚自己几斤几两。我是一个看到代码编辑器就会产生轻微眩晕感的人，我对编程的全部认知来自于以前在软件公司开会时假装听懂工程师说的话。你让我做一个3D灯光模拟软件？你不如让我用意念控制天气。

    但2026年了嘛。

    我之前做过一个游戏，具体见什么？！我只靠对话就做了一款游戏出来！，也是完全不会写代码，纯靠跟AI聊出来的。那次经历给了我一个极其危险的认知：原来真的可以这样。这个认知之所以危险，是因为一旦你尝过这种甜头，你就再也刹不住了。你脑子里每冒出一个"要是有这么个工具就好了"的念头，你都会想"我是不是又可以……"，就和路径依赖一样。

    于是我又可以了。

    不过这次跟做游戏很不一样。做游戏的时候我基本上是跟一个AI聊到底，像两个人在深夜的对话框里吵架吵出一个作品，浑身上下充满了一种不管不顾的莽劲儿。做Direct Light，我用了一套完全不同的方法。

    我用的是管团队的方式。

    这不是比喻，我是真的在管团队。我写了需求文档，写了渲染规格，写了代码架构规范，写了协作记录，写了路线图。每一个功能上线之前，先出规格文档，写清楚要做什么、不做什么、验收标准是什么、谁负责哪块。做完了我来验收，不过的打回去，过了记进版本记录，推进下一个任务。版本号从v0.0.1一路走到v0.7.1，每一个小数点背后都有一份规格、一次验收、一条明确的记录。

    我的"团队成员"是AI。

    Codex相当于产品经理兼视觉总监，我跟它一起定方向、定参数、定画面该长什么样。"默认构图要不要多留点地面""彩色灯是不是太艳了""这个功能对导演有没有沟通价值"，这些判断我拍板，它帮我把模糊的直觉翻译成规格文档里的具体数字。ClaudeCode相当于主力工程师，所有大块功能，3D场景搭建、状态管理、A/B对比、多人物、道具系统、姿态骨架、摄影机控制，基本都是它落到代码里的。Hermes相当于实习生，只做被明确点名的小任务，起草一个数据文件、写一小段界面，做完了交给Claude或者Codex审核，不能自己拍板任何事。还有一些"外包"，有些不太核心的代码模块我会让其他AI模型起草初稿，Claude逐行审核，Codex从产品角度过一遍。就像你把一些活外包给外面的人，但核心架构和产品判断永远攥在自己手里。

    我在协作文件里写了几条规矩。第一条：不能写"Claude/Hermes实现"这种模糊归属，谁的活就是谁的活。管过团队的人都知道，模糊归属是项目失控的前兆。你不能说"这个功能团队实现了"，你得说清楚谁写的代码、谁审的核、谁拍的板。AI也一样。第二条：Hermes最好的状态不是逞强把所有事做完，是在不确定的地方停住。有一次Hermes按规格起草灯具预设文件，碰到一个灯的类型不在系统认的列表里。它没有自作聪明地瞎改，而是停下来报错。查完发现是类型定义文件落后了一步，不是预设写错了。如果它当时"聪明地"绕过去了，这个bug可能会藏得很深，后面排查起来能让人想砸电脑。好的执行者知道自己的边界在哪里，不管这个执行者是人还是AI。就像片场的场务，你让他搬灯他搬，但他发现接线好像不对的时候，他不会自己偷偷换，他会过来问你。

    后来这个团队还出现过一次临时换手。Codex额度见了底，有几轮验收我就授权Claude代它做视觉把关。但账还是记清楚的，谁的活写谁，代验收就记成Claude做的，不冒认成Codex。这个临时换手本身说明一件事：三个"人"已经磨合到可以互相顶一下，而不会乱。

    用这套方法做出来的第一版，画面朴素得令人心酸。白色地面，白色墙面，一个人形模型像根电线杆一样杵在中间，头顶一盏灯。整个软件看起来就像一个建筑学大一学生在期中考试前四十分钟赶出来的作业。而且为什么起这个名字我也得提一嘴，本来我是想大Director‘s但是当时手快就安利回车，现在一看还挺顺眼就用了。

    但它能跑。

    灯往左挪，人物身上的光会变。切到俯视图，一眼看清人物、灯、摄影机之间的位置关系。这些基本的东西是对的。后来我调了一个极其微小的参数，把默认摄影机稍微往后拉了一点点，目标点往下降了一点点。就这么一个微调，画面一下子就"对味儿"了。因为导演看画面不是只看人脸，他还要看脚下那一圈地面，看阴影有没有进画面，看人物周围有没有空间能呼吸。这种"差一点点就别扭，动一点点就舒服了"的感觉，后来在这个项目里反复出现。每次碰到的时候我都觉得，这大概就是所谓的产品直觉。它不是什么玄学，就是你对"这个东西是给谁用的"这件事想得足够多以后，自然就会有的判断力。

    说到第一版，其实一开始我也膨胀过。我想着反正AI写代码快嘛，一口气把功能全堆上去不就完了？灯光、人物、道具、姿态、摄影机、A/B对比、灯具库，全塞进去，一步到位，多爽。

    但我以前管过软件团队。

    我太知道那种"一口气全堆上去"之后会发生什么了。代码会变成一坨没有人愿意碰的东西。你想改一个小功能，得先在一万行的文件里翻来翻去找到那段逻辑，改完以后另一个八竿子打不着的地方突然就崩了。你想加一个新功能，发现它跟三个旧功能纠缠在一起，拆都拆不开。然后所有人都开始害怕改代码，每次动一行都得提心吊胆地祈祷其他地方不要爆炸。

    这种东西有个名字，叫屎山。

    屎山的可怕之处在于，它不是一天堆成的。它是每一次"反正先这样吧，下次再整理"慢慢积攒出来的。每一次你都觉得"就多加这么一点，应该没事"，等你回过神来，整个项目已经变成了一坨谁都不想碰、谁都改不动、谁都看不懂的东西。我见过太多项目死在屎山上了。因为代码烂到所有人都跑不了，改不动了。

    所以我从一开始就做了一个决定：与其后面花十倍的力气去收拾屎山，不如一开始就分门别类放好。

    入口文件要薄，就是一个路标，告诉你东西在哪。规格数据放一个地方，白棚多大、灯多亮、默认站位在哪里，全部集中管理，不要散落在各个角落。3D场景放一个地方，只管画画面。状态逻辑放一个地方，只管记住"现在什么是什么"。UI面板放一个地方，只管用户看到什么、能点什么。业务计算放一个地方，只管算数。每一类东西都有自己的位置，谁也不要越界。

    我还写了一份调试指南：画面灯光不对先查哪个文件，参数调了没反应先看哪个模块，保存方案出问题去哪里找。以前这种文档是给新入职的工程师写的入职手册，现在是给AI写的。你说荒不荒诞。但它管用，AI跟人一样，你给它的上下文越清楚，它犯糊涂的概率就越低。但是比较省我腱鞘的好处就是这玩意也能让AI来写。

    事实证明这个决定救了我好几次。后来每一个新功能，A/B对比、多人物、道具、姿态、摄影机控制、灯具库，都是在这个干净的结构上长出来的。每次加新东西的时候我都知道它该放在哪里，它会影响什么，它不应该碰什么。如果一开始图快全堆在一起，到了这个阶段项目早就改不动了。

    当然，说"一开始就分门别类"也不是说后面就不用整理了。软件长到一定程度以后，即使你已经很注意了，有些地方还是会开始变胖。状态管理的文件涨到了685行，什么逻辑都在往里塞。控制面板一个文件管五种完全不同的面板。3D场景的文件同时负责相机、拖拽、标签和场景组合，像一个实习生被分配了五个部门的活还没人给他加工资。

    还没乱，但我闻到了那个味道。管过团队的人都认识那个味道。它是"再往前走一步就要出问题了"的味道。

    所以我喊了暂停。不加新功能，先收拾。把面板拆成五个独立文件，把3D场景拆成几块独立模块，把685行的状态管理文件拆成一个38行的入口加八组各自独立的逻辑。这个过程极其无聊，没有新画面上线，没有任何激动人心的东西可以截图发朋友圈。但我知道这是整个项目里最重要的决定之一。先收拾干净，再继续往前走。这道理管团队的时候就刻进了骨头里，管AI一模一样。

    后来项目上线后我数了一下，发现我写的规格文档、架构文档、协作记录、路线图加在一起的行数，比整个软件的代码行数还多。一个不会写代码的人，产出最多的东西居然是文档。但也正是这些文档，让每一个AI都知道自己该干什么、不该碰什么，让这个项目从头到尾没有长成一座屎山。

    A/B对比功能做出来的那一刻，这个项目的性质变了。

    之前它就是一个"调调灯看看画面"的玩具。你调完了觉得好像还行，但跟之前比好在哪？嘴上说不清，心里也说不清。有了A/B以后，画面左边是你正在调的方案A，右边是冻结住的方案B。你随便折腾A，B纹丝不动，两个方案肩并肩摆在那里，差别一目了然。

    这个功能听上去就是把画面劈成两半嘛，有什么了不起的。但它让Direct Light从一个人自嗨的调参玩具，变成了一个可以拿去跟别人沟通的工具。你跟摄影指导开会，不用再比划了，两个方案一摆："你看，灯抬高半米之前是这样，之后是这样，你选。"对比的时候画面下方还会蹦出一行彩色标签，告诉你两个方案在灯光、人物位置、道具、姿态、摄影机、白棚这六个维度上哪些一样哪些不一样。一样的灰色，不一样的紫色高亮。导演扫一眼就知道这次对比在看什么。

    当然A/B也给我贡献了第一个想把键盘掰成两半的bug。对比完切回其他视角，黑屏。人物蒸发了，白棚蒸发了，什么都蒸发了。你花十分钟精心调好的方案，切一下视角，全没了，唯一的出路是刷新页面从头再来。后来修好了，原因也简单，就是切换模式的时候有些该常驻的东西被误杀了。修完以后我坐在那里发了会儿呆。这种bug修起来毫无成就感，就像把一扇老是卡死的门重新装回门框里。没人会为此鼓掌，但门卡死的时候你连房间都进不去。

    多人物进来以后，画面终于不再像一个人在一间空荡荡的白房间里罚站了。A站中间，B在左后方，C在右前方。服装用低饱和的深色，不是为了时尚，是为了让你分得清谁是谁的同时不让衣服颜色抢了灯光的戏。人跟人之间会互相挡光，影子会叠在一起，俯视图里能看到一个完整的站位布局。开始有点像一个真正的片场预演了。

    这时候碰到一件很有意思的事。我把人物从画面中间拖到右边，总觉得灯好像跟着人走了。拖回来，灯好像又跟回来了。这种感觉非常微妙，微妙到你说不清到底是灯动了还是没动。仔细一查，灯根本没动。是人走进了灯的照射范围，光的角度变了，给你一种"灯追过来了"的错觉。人的坐标从0移到了2，灯到人的距离从3.69米变成了2.53米，但灯的绝对位置一丝一毫都没变过。这种"感觉上的错误"在片场也经常发生，Direct Light能用具体的数字把它拆清楚。你不用再靠"感觉"了，数据不会骗你。

    做道具系统的时候我被一个词坑了。"人台"。我在需求文档里写了这两个字，当时没多想，后来才发现中文里"人台"有两个完全不同的意思：一个是服装店的半身模特，一个是拍直播时人站上去的小圆台。这区别在灯光面前是天壤之别。半身模特，你判断的是灯打在衣服和人形上的效果。小圆台，你判断的是一个活人被抬高了三十厘米以后，脸上的光变没变，腿上的影子对不对，跟背景的关系变没变。三十厘米，灯光面前就是两个世界。后来我把这两个概念彻底拆开了。这件事教了我一个道理：含糊的词在产品里是定时炸弹。你以为大家说的是同一个东西，其实各怀鬼胎。管AI也一样，你的需求写得越含糊，交出来的东西就越可能让你血压飙升。

    桌子、椅子、凳子、沙发、台座、背景板陆续搬进白棚以后，它终于不再是一个空荡荡的白盒子了。开始像片场沟通会上的临时场地，灯打过去，地上和墙上都开始热闹了。这也是Direct Light的定位真正清楚的时候。它不去替代专业的3D灯光软件，不去追功能齐全的摄影棚模拟器。它就是一个轻量灯光沙盘，不做百科全书，但让"这儿会不会挡光""这灯会不会打脏""人站高了画面有没有问题"先变成一个看得见的画面。

    人物多了，道具也多了，人还可能站到桌面上、小舞台上。灯应该对准哪儿？以前灯就是个傻子，你让它对哪它就对哪，人物抬高了三十厘米它还傻乎乎地打在原来的位置。所以我做了灯光目标模式：手动指定、锁定某一个人物、自动看向所有人的中心。人物抬高了，灯跟着抬。人物走位了，灯跟着走。这一步做完以后我突然理解了一件以前在剧组完全没理解过的事，道具在灯光面前不只是"占了一块地方"。一张桌子搬进来，一个小舞台放进去，它们改变的是整个灯光关系。这个认知是做这个软件的过程中一点一点长出来的。说实话，做Direct Light最赚的地方可能就在这里，做工具的过程本身就是学习的过程。我现在对灯光的理解比我在剧组那不到一个月学到的多了不知道多少倍。一个不到一个月后勤经历的人，通过做一个灯光软件，学到了比在片场更多的灯光知识。这事儿本身就够荒诞的。

    之前的人物模型就是一根电线杆杵在那里，毫无生命力。后来加了骨架系统，躯干能转身前倾，头能左右转上下点，手臂拆成上臂和前臂，肩膀和肘都能活动。预设了9个姿态。关键是姿态直接影响灯光判断：抬手多一块手臂投影，前倾改变脸的受光面积，侧身改变轮廓光勾出来的边缘线条。在片场导演说"你稍微侧一下身"，灯光就得跟着调，在这个软件里也一样。后来又做了坐姿，人物可以坐到椅子、沙发、凳子上，也可以站到台座和小舞台上，承载物一移动绑在上面的人也跟着走。这里最折磨人的全是鸡毛蒜皮的边界情况：换了个姿态但位置没变，系统不能以为你把人拖走了；人站在小舞台上旋转舞台，人的朝向也得跟着转。这种小问题就像片场地上贴的胶带标记，小小一条谁都看不见，但没有它演员走位就全乱了。

    旧版本保存的方案也得能在新版本里打开。早期版本哪有什么姿态数据、道具数据，直接加载到新版本里就是一个响亮的崩溃。所以做了个迁移模块，旧方案加载时自动把缺的东西补上。就像给老照片配个新相框，照片还是那张照片，但终于能挂到新墙上了。

    之前软件里就一个自由视角，鼠标随便转，摆东西够用，但导演要的不是"随便看看"，导演要知道最终镜头里画面长什么样。所以我把自由视角和摄影机视角拆开了。自由视角拿来摆东西绕场看结构，摄影机视角模拟最终构图，有方位角、距离、高度，还有几个预设：正面全身、45度侧前、高机位、低机位、俯拍。最爽的是一个按钮叫"从自由视角取景"。你在自由视角里绕来绕去找到一个觉得不错的角度，按一下，它就成了摄影机的位置。特别像在片场端着取景器走来走去，找到好位置跟摄影师说"就这儿，架这儿"。还做了棚内约束，以前随便拉摄影机一不小心拉到墙外面去了，画面变成一大片白什么都看不见宛如灵魂出窍，现在摄影机到了墙边就贴墙滑动，不会穿出去了。这里还修了个特别鬼畜的bug，自由视角里调"看向高度"，整个场景像桌布一样被拽起来，人物和白棚全跟着往上飘。搞了半天发现是自由视角的控制跟摄影机的参数绑得太紧了，动了一个另一个也跟着抽搐。改完以后世界终于安静了。

    以前选灯就三个选项：硬光、柔光、面光。这种抽象程度大约等于你去饭店点菜，菜单上只写了"好吃的""还行的""凑合吃的"。做过片场的人听到"硬光"会追问：什么硬光？COB？菲涅尔？多大功率？所以我给灯加了更像片场的名字，600WCOB白光、600WCOB双色温、NanluxEvoke600C、LED面板、RGB灯管、菲涅尔、小型RGB效果灯、暖色实景灯。它们不是精确复刻真实灯具的光度曲线，那是另一个量级的工程，现在不是干这个的时候。它们是先把摄影现场的语言落到可以调的参数上，让用Direct Light的人说出来的话跟片场的人说出来的话是同一种话。白棚也补了一波，地面到后墙变成一体弧面，就是真实白棚里那种cyclorama；柔光和面光在画面里有了可见的灯体；地面反射也进了计算。还有个小交互，灯体本身要能被点击和拖拽。不然你在画面里看到一块大大的柔光面，却只能去抓旁边一个针尖大的小圆点来移动它。这种不顺手的地方，对用户来说比什么参数精不精确刺眼一百倍。

    然后就是控光附件。柔光箱、蜂巢、反光罩、旗板、黑旗、反光板、柔光布。摄影现场的词一下子涌上来，每个都重要，每个都能改变画面。

    但做到这个阶段我已经学乖了，不能一口气全上。它们压根不是同一种东西。有些装在灯上，比如柔光箱和蜂巢；有些摆在棚里，比如旗板和反光板。混在一个版本里，项目会很快变成一个又厚又钝的面板。

    所以我一点一点地分拆成好几个小版本。

    第一步只做灯上附件：中号柔光箱、蜂巢、标准反光罩、柔光布。它们没有去改动原始的灯光参数，而是挂了一个附件标记，在有效光质里算账。同一盏灯，A/B对比里你能看出"裸灯"和"加了柔光箱"的差别，亮度滑杆没动，画面却柔了下来。第二步给这些附件做了可见的形体，又在镜头视角的角落加了一行导演简介。画面上读得出"KeyLight·NanluxEvoke600C·中号柔光箱"的时候，它就不只是软件了，更像一张能递给摄影和客户一起看的纸条。

    第三步和第四步做棚内的控光物件。黑旗、反光板、柔光布框，本可以另起一套新系统，最后被做成了现有道具系统里的一个新类别。一个新的几何体类型，复用已经写好的添加、拖拽、旋转、保存、A/B。新加的东西很少，因为前面"先分门别类放好"省下来的那只手，这时候正好伸了出来。

    光学效果没有去做物理遮挡。黑旗不靠真实的模型阴影来挡光，它在运行时从场景里算：哪盏灯被它挡在路上，就把那盏灯的有效亮度、光束和溢光降低一个常数。反光板不是真的在反射光线，它是一盏不投影、不占灯位上限的虚拟补光，给人物暗部弱弱地垫一点。柔光布框夹在灯和人之间时，只让有效光更软更暗。

    这背后是一个很导演的判断：他要的是"看懂这块黑旗会吃掉哪边的光"，不是一次物理正确的光线追踪。把光学做成从场景纯算，而不是再开一个新的状态仓库，Direct Light才没有在收尾阶段又长出一身赘肉。

    做到某个阶段的时候，我对AI脱口说了一句很欠揍的话。

    "我感觉我就是开发天才。"

    我知道，这话说出来打雷都劈不下这么大的脸。但让我描述一下当时的场景。

    那时候项目已经有了白棚、多人物、A/B对比、道具系统、小舞台、灯光自动对齐、人物姿态和坐姿、摄影机控制、灯具器械库、控光附件。我坐在电脑前，看着这个活生生在跑的3D灯光沙盘，有灯光有阴影有调度有对比有真实灯具名字有柔光箱有黑旗，然后回头想了想做这个东西的人是谁。一个看到代码就头晕的前软件公司高管。在剧组打了不到一个月杂的后勤人员。

    以前在公司的时候，做一个这种量级的东西你得有什么？前端、后端、3D工程师、产品经理、设计师，可能还得有个技术总监拍架构。你得排期，得开会，得协调，得等人。从需求到上线，几个月算快的。现在我一个人。写需求文档，分配任务，审核代码，验收产品，推版本。AI是我的整个团队，我是这个团队的CEO加PM加QA加那个半夜还在盯进度的项目经理。

    从第一份需求文档到开源上线，不到一周。

    放在以前，一周你连需求评审会都没开完。

    所以那句"开发天才"，说的不是我会写代码，我一行都不会写。说的是我突然意识到，游戏规则彻底变了。以前"能不能做出来"取决于你有没有一个团队。现在取决于你知不知道自己想要什么，以及你会不会管理执行者。执行者是人还是AI，已经不重要了。重要的是你脑子里那团东西。你对问题的理解，你对产品的判断，你对"这东西到底是给谁用的"这件事的执念。这些东西AI给不了你，也替代不了你。但只要你有，AI就能帮你把它做出来。

    然后就到了收口以及开源的时候。

    "终于到最后收口的时候了。来吧，这次你来主导。"这是我对Claude Code说的原话。

    这句话和之前那句"我感觉我就是开发天才"隔着大半个项目遥遥相对。那时候是站在一个刚能跑的软件面前发现自己抓住了方向，这一次是站在一个功能齐全的软件面前，决定让它走出去。

    收口做的是把一个一直在本地长大的东西变成"别人下载下来就能看懂、能跑、能改"的样子。补一份MIT许可证，把README翻成一个开源门面，这是什么、怎么跑、有哪些已知限制、许可证在哪，原来那份完整需求文档原封压在下面。然后git init，第一个公开提交。

    早先那句"想开源"，到这一刻才真的兑现成一个地址。不急着商业化的好处，这时候又显出来了一次。开源第一版不必等多语言，不必等更多光源，把当前这套已经能解释拍摄问题的东西干净地放出去，就够了。

    桌面版用的是Tauri。本机没装Rust也没关系，编译这件事推给了GitHub的云端构建，打一个版本标签，不到五分钟就吐出来一个6.6MB的安装包。只有6.6MB，因为Tauri用系统自带的浏览器内核，不像Electron自带一整个Chromium。代价是没签名，朋友第一次打开会被macOS拦一道，得去系统设置里点"仍要打开"。这句话被一并写进了发布说明，省得日后一个个去解释。

    网页demo也配好了自动部署。代码推一次，一两分钟后线上就是最新版，用户永远看到的都是最新的状态。桌面版不一样，它是打一个标签才构建一次，下载了就是那个版本，不会自动更新。三种形态，三个节奏，各走各的路。

    最后是图标。在这之前桌面版顶着框架默认的占位logo，丑得光明正大。换上了一张自己的图：白棚，一束硬光从左上斜下来，打在一个站着的人身上，地上拖出影子，底下是一圈正在收拢的紫色光圈。

    现在三个方法都到齐了。源码在GitHub上开着源，网页demo随时能打开，桌面版躺在Releases里等人下载。一个当初只是拍摄现场里冒出来的念头，白棚、一个人、一盏灯、地上有影子，现在能下载、能分享、能改，还有了一张自己的脸。

    上次做游戏的时候，我说过一句话：时代的那扇大门，第一次真正为我这种除了想法一无所有的人敞开了，而我只是大摇大摆地走了进去。

    做Direct Light让我确认了一件事。那扇门不是偶然开了一次。它就是一直开着的。

    而且这一次我走得比上次更深。做游戏的时候我更多是在跟一个AI对话框里吵出一个作品，浑身充满不管不顾的莽劲儿。做完整的应用，我建立了一整套协作体系，需求文档、规格先行、分工明确、版本管理、审核验收。我是在用年管团队的经验，去管理一个由AI组成的团队。这两种方式都能做出东西。但后者让我意识到，那些年的管理经验不是白费的。它们在这个新世界里找到了一个全新的、荒诞但真实的用武之地。

    我也真的觉得，每个人心里都有一个自己的"Direct Light"。不一定是灯光沙盘，可能是别的什么工具、什么产品、什么你一直觉得"要是有就好了"的东西。以前你可能觉得那只是想想而已。自己不是程序员，没有团队，没有钱。想想就算了。

    但如果你脑子里有东西，你真的、具体的、清楚的知道你想要什么，那么在2026年，你就真的可以把它做出来。你需要的仅仅是想清楚，然后开始。

    后面还有不少事想做。更多光源、多语言、用户自定义上传灯光参数，这些都在计划里。但我一个人加一群AI，节奏就是这个节奏，急不来。各位请等着更新。如果实在等不及，那也欢迎你自己来，反正都是开源的，代码在那儿，文档比代码还多，看完你就知道东西该往哪放。

    所以，如果你正好懂代码，或者你也懂怎么“管AI”，去GitHub上把它Fork走吧。完整的需求文档、架构规范我都坦荡荡地压在仓库底下了。你想加个ARRI的灯具预设？想做个日文版？或者觉得哪个逻辑拆得不够优雅？直接提Issue骂我，或者干脆提PR拿代码砸我。

    如果你和我一样不懂代码，那也去下载个桌面版，或者点开网页Demo玩玩。把你想要的灯、你想要的道具、你在片场遇到的那些气死人的打光死角告诉我。这扇门既然开了，就别只在门口站着，进来一起折腾吧。

最后放上我的程序的地址：

下载版：https://github.com/oukeming64-tech/direct-light/releases/tag/v0.7.1（版本号会持续更新，记得下载最新版）

在线版：https://oukeming64-tech.github.io/direct-light/

开源仓库：https://github.com/oukeming64-tech/direct-light