800 流明的灯为什么照到 1.6 米就只剩 25 勒克斯一键开通华为云码道 CodeArts 代码智能体 https://developer.huaweicloud.com/codeartsco.html?sourcedmzntgwatomgit1sourceaddmzntgwatomgithd先说这东西是什么一个零依赖的单页网页。填四个数灯泡总光通量、灯到桌面的距离、光线入射角、你想要的照度。它告诉你桌面实际有多少勒克斯、离目标差多少、这盏灯能均匀照亮多大一块圆、以及按光效折算这大概是几瓦的灯。仓库在 atomgit.com/yl4928/desk-luxMIT双击 index.html 就能跑。为什么做这个我给我家书桌换过一次灯。买的时候盯着瓦数看觉得 9 瓦 LED 挺亮装上去一照桌面还是暗。后来才搞明白我看错了两个东西一瓦数是耗电不是亮度。同样 9 瓦光效 60 lm/W 和 110 lm/W 差将近一倍。二就算看流明也没用。流明是灯泡往外发的总量桌面收到多少是另一回事中间隔着距离、角度和受光面积。阅读要 300 勒克斯这句话从来没人和自己家那盏灯对上过。所以我把这个换算做成了一个能填数字的页面。四条式子就把事情说完了均匀照明 E Φ / A 照度 光通量 / 受光面积 点光源强度 I Φ / (4π) 各向同性假设下 点光源照度 E I · cosθ / r² θ 是光线与桌面法线的夹角 反推需求 Φ E · A单位Φ 流明(lm)、I 坎德拉(cd)、E 勒克斯(lx)、A 平方米(m²)、r 米。把 800 流明代进去看看它随距离怎么塌800 lm 各向同性点光源垂直入射 0.2 m - 1591.5 lx 亮到刺眼 0.3 m - 707.4 lx 0.5 m - 254.6 lx ← 台灯典型高度还差一点到 300 0.8 m - 99.5 lx 1.2 m - 44.2 lx 1.6 m - 24.9 lx ← 吊灯挂在这个高度桌面就是能看见级别这张表解释了一件很常见的事为什么吊灯亮堂堂、书桌却暗。灯到地面的高度是 2.4 米你干活的地方在 1.6 米以下同一盏灯到你眼睛前面那本书记的照度只有到地面的一半不到——而人的直觉是房间挺亮。角度那一栏也值得看同一盏灯同样的距离光线斜 45 度入射照度直接乘 cos45° 0.707。白色系这一批三篇统一白色系。这一篇的强调色是琥珀 #a86a12灯光的暖调警示色 #b3261e 只在差多少 lx那句和不达标的进度条上出现。全部内联、零外部资源、file:// 双击可跑观感目标是一张打印出来的检测记录单。提示词钉到函数级这一篇的规格我写得比上一批更克制——因为上一批学到规格越重码道越容易空转。1) illuminance(flux, area) E flux / areaarea 0 时 throw RangeError 2) luminousIntensity(flux) I flux / (4π) 3) pointIlluminance(I, dist, cosT) E I × cosθ / dist²dist 0 时 throw RangeError 8) diskIlluminance(luminance, R, h, n) 数值积分同心环面元第 k 环半径 r_k (k-0.5)R/n环面积 dA 2π·r_k·(R/n) 斜距平方 d² h² r_k²两侧入射角余弦同为 h/√d²每环贡献 dE L·dA·cosθ·cosθ/d² 注意dA 必须是 2πr·dr不能写成 R²/n 或 πR²/n——上一版有人在这里丢了一个 π。最后那句不能写成 R²/n不是随手写的是我在自己的差分脚本里真丢过一次 π才知道这个坑有多好踩。最硬的一条对拍圆盘照度有解析解点光源是理想化。真实台灯灯罩是个发光的曲面所以我在引擎里放了一个有解析解可对照的数值积分半径 R、亮度 L 的均匀发光朗伯圆盘在轴线上距盘 h 处的照度教科书答案是E π·L·R² / (R² h²)推导很短取同心环 dA 2πr·dr斜距 d² h² r²两侧余弦都是 h/d于是dE L · dA · (h/d)² / d² 2πL·h²·r·dr / (h² r²)² ∫₀ᴿ 2πL·h² · [ R² / (2(h²R²)) ] πL·R²/(R²h²)引擎里的diskIlluminance用环带数值积分实现我的参考实现用 30 位定点整数算同一个积分两边都跟解析解比L1000, R0.1, h0.3解析值 314.159265359 n200 误差 3.738e-4 n2000 误差 3.738e-6 n20000 误差 3.738e-8 n200000 误差 3.738e-10网格每加密 10 倍误差正好降 100 倍——这是 O(h²) 中矩形法则该有的样子而且四位有效数字一点没飘。这条对拍比两个数相等有力得多因为它验的是收敛行为写错面元面积、写错余弦、漏掉 π全都活不过这一关。护城河连 π 都是自己算的上一批我把可信度押在国标全文上结果取不到一手文本只能写公开转载。这一批三个项目统一改成锚点放在纯数学上标准值只当可修改的输入。所以参考实现里我不允许自己用Math.PIπ 16·arctan(1/5) − 4·arctan(1/239) Machin 公式arctan 用整数级数 ln(x) 先用 2 的幂把 x 归一到 [0.5, 2]再用 2·artanh((x−1)/(x1)) exp(x) 参数约化到 |y| ≤ 1 做泰勒再连乘还原 √x 定点牛顿迭代 全程 BigInt比例尺 10³⁰只有整数运算先自检常数再判引擎pi 3.141592653590 与 Math.PI 一致 ln2 0.693147180560 sqrt(2) 1.414213562373然后跑差分8585 次跨实现断言0 分歧。脚本就在evidence/diff.mjs一条命令可重放。测试里我还专门留了一条防丢 π的断言// T7 面元面积不能丢 π// 闭式在 L1、R1、h0.05 处是 πR²/(R²h²) π/1.0025 3.133753...assert.ok(Math.abs(eng.diskIlluminance(1,1,0.05,200000)-Math.PI/1.0025)1e-4);如果实现把 dA 写成R²/n丢了 2πr 也丢了 π这条会差出好几个数量级。300 勒克斯这个数我把它降级成了输入界面默认目标照度填 300 lx来源是 GB 50034《建筑照明设计标准》里住宅书写阅读档的公开转载值。这台机器上我取不到该标准可访问的一手全文。上一批我在 README 里写标准规定评审直接指出这是替标准说话。这次我改了三件事一300 做成可修改输入不做常量二页脚和 README 都明写未取到一手全文取自公开转载仅作默认输入参考三把点光源近似这个更大的假设写在最前面——真实灯具的配光曲线不均匀本工具算出来的是理想化下限估计也就是最多这么暗实际可能更暗或更亮。工具最容易骗人的地方不是算错是把一个近似说成结论。这一轮我自己踩的坑规格写太重界面轮空转。第一版 UI 提示词我写了 2.7 KB把每个像素和每条禁令都展开了。码道跑到正文 10.5 万字、贴了 62 个代码块就是不落盘。停掉压到 1.8 KB只保留 id、公式、色值清单和禁止项一次过。给 AI 的规格不是越详细越好是越能一次做完越好。上下文涨到 12 万字之后什么都变慢。README 那轮在一个跑了七八个回合的老会话里正文 11.8 万字、结束但没提交。我新开一个会话重发同一条提示词60 秒落地。会话用久了要换新别指望它自己瘦下来。合并脚本时撞了标识符。我想把数学库和差分驱动合并成一个自包含文件提交进仓库结果库里已有const PI、const pow2驱动里也各有一个直接 SyntaxError。修法是合并时剔除库里那两个由驱动自定义的顶层声明。这类看起来只是复制粘贴的活恰恰最容易翻车。够不够那一列我一开始写死了目标值。界面表格第三列原本是照 300 lx 判的把目标改成 100 lx 之后表格还在说差 200 lx。改成随 target 动态判定才对。提效数据轮次交付结果R1src/engine.js 8 个函数 12 条锚点一次过R2package.json 7 个测试一次过本地 npm test 7/7R3index.html2.7 KB 规格空转停R4index.html1.8 KB 规格一次过控制台干净R5README LICENSE老会话结束但未提交R6README LICENSE新会话60 秒落地R7evidence/diff.mjs 入库一次过仓库内跑出 8585 断言 0 分歧已知边界不粉饰各向同性点光源近似。灯到桌面的距离小于灯具自身尺寸时比如台灯灯罩几乎贴着桌面误差很大。不含墙面、天花的反射光也不含灯具效率同样的灯珠罩子吃掉 20~40%所以算出来的照度普遍偏低于实测。未计维护系数灯用久了会衰减 20~30%。多盏灯需要逐盏算完再线性相加界面只算单灯。300 lx 这类参考值不替代专业照明设计真正要设计得看 GB 50034 原文和照度计实测。把瓦数思维换成流明-距离思维同一张桌子上我把几个常见组合用仓库里的引擎算了一遍数值就是页面算出来的灯光通量到桌面距离桌面照度够不够 300 lx60 W 白炽的 LED 替换泡806 lm0.45 m316.7 lx够客厅吸顶灯1500 lm1.6 m46.6 lx差 253.4 lx小台灯400 lm0.35 m259.8 lx差 40.2 lx台灯800 lm0.4 m397.9 lx够结论很反直觉一盏 1500 流明的主灯在你读书的位置上比不上一盏 400 流明的台灯。因为距离是平方反比而流明只是总量。1500 lm 1.6 m - 46.6 lx 400 lm 0.35 m - 259.8 lx 800 lm 0.4 m - 397.9 lx客厅那 100 勒克斯呢把目标改成 100 lx客厅一般活动的公开转载参考值一只 1600 流明的吸顶灯挂在 2.4 米1600 lm 2.4 m - 22.1 lx 连 100 lx 都差 77.9也就是说客厅很亮和客厅够亮是两回事——人眼对数响应加上天花板反射会让你觉得亮但桌面照度计不会同意。这张截图想说的是达标与否完全取决于你把哪个面当受光面同一个房间里沙发区够亮和书桌够亮是两件事。交付回执与仓库差分脚本入库后我重新 clone 验证过在仓库目录里直接跑$nodeevidence/diff.mjs 跨实现断言8585次分歧0条把数学库和驱动合并成自包含文件时两边都有const PI、const pow2直接撞出 SyntaxError。不在仓库目录里跑一遍这种问题根本发现不了。为什么用 4π以及它什么时候不成立各向同性点光源是个假得不能再假的模型——真实灯泡上方有灯头遮挡、台灯有灯罩、吸顶灯是面光源。我还是用了它理由有两个一它有一个可以手算的解析对照。圆盘那个例子里数值积分和 πLR²/(R²h²) 必须收敛到同一个数这能验出实现层面的错。二它是下限估计把光均匀撒到整个球面上任何方向的实际照度都不会比总量守恒地摊开更乐观地偏离太多。但它有明确的失效区我在 README 的已知边界里写了这里说得更具体当 观察距离 灯具自身尺寸 时点光源假设崩 例灯罩直径 20 cm桌面离灯罩 15 cm —— 此时 r 比灯具还小 点光源公式会给出偏高的照度因为把整个灯罩当成一个点 正确做法把灯罩面拆成多个面元逐个叠加本工具的 diskIlluminance 就是这条路也就是说界面里那个理想化下限估计的说法对台灯贴得极近的场景其实偏乐观。这是我愿意承认的模型边界而不是藏起来。这个工具不管的三件事买灯还有三个维度比照度更影响体验本工具一概不算免得让人误以为算出来够亮就行均匀度 桌面中心 500 lx、边缘 50 lx 也很难受本工具只算单点 眩光 灯珠裸露、遮光角小照度够但刺眼需要看 UGR 与灯具配光 显色性 Ra/Rg 与色温决定看着舒不舒服与流明无关上一批我做过台灯色温那篇那管处理光谱这管处理几何。两者不冲突也不互相替代。复用同一份数学库意味着什么这一批三篇共用同一个 30 位定点库π 用 Machin、ln 用 atanh 级数、exp 用泰勒、开方用牛顿迭代。复用的代价是我在合并成自包含文件时踩了标识符冲突两边都有 const PI好处是同一个 bug 只可能出现在一处被查到一次就三篇都干净。分贝篇要 log10照度篇要 π 和开方咖啡因篇要 ln2 和 exp——三个项目对数学库的覆盖面不一样合起来才算把这份库真正压过一遍。不打开网页时的三步心算工具是给较真用的日常判断有个粗糙版就够第一步 估强度 I ≈ Φ / 12.6 4π ≈ 12.566取 12.6 好算 第二步 除距离方 E ≈ I / r² r0.5 - 除 0.25即乘 4 第三步 比目标 阅读 300 lx、厨房操作 300 lx、客厅活动 100 lx 例一 800 lm 台灯灯头离桌面 0.4 m I ≈ 800/12.6 ≈ 63 cd E ≈ 63/0.16 ≈ 398 lx - 够读 例二 1500 lm 吸顶灯挂 2.2 m人坐桌前 r ≈ 1.45 m I ≈ 119 cd E ≈ 119/2.10 ≈ 57 lx - 差得远加台灯第二步最容易错的是距离要算灯到桌面不是灯到地面。坐着时桌面高约 0.75 m吸顶灯挂 2.22.4 mr 只有 1.451.65 m。这套心算和页面的精确值差在 5% 以内因为我把 4π 圆成了 12.6。页面上是精确数心算用来在建材市场做判断——两者对得上说明我没有把工具当成权威。怎么自己验一次这个换算我不要求你信页面。手上有一台带照度计 App 的手机多数安卓的 lux API 精度有限iOS 需要外接传感器可以做一次粗验证1. 关灯把手机放在桌面固定位置记录本底照度 E0通常 5 lx 2. 只开这一盏灯同一位置记录 E1 3. 量出灯发光中心到传感器平面的垂直距离 r以及光线与法线的夹角 θ 4. 查灯泡包装上的标称流明 Φ 5. 比对页面算的 Φ·cosθ/(4πr²) 与实测 (E1 - E0)差多少算正常我的经验判断是 20~40%来源有三个手机传感器余弦响应不好斜射光记不满、灯具不是各向同性灯罩把光往下压实测会高于页面值、房间反射也会偏高。所以如果实测明显低于页面值大概率是距离量错了或者灯泡实际流明虚标——这恰恰是页面能帮你发现的问题。这一段没有对应的自动化测试因为它是现实。工具能验的是算术验不了世界。为什么值得为够不够亮单独做一个工具照度是这一批三个项目里最看不见的量分贝你听得见咖啡因你有体感而勒克斯没有直接感觉——人眼会自动适应整体亮度你能判断这屋比那屋亮但判断不出300 还是 150。这恰恰是它需要被算的原因。买灯时包装上写流明、商家说瓦数、装修图上标照度三套单位互相不认。把它们串起来只需要两条式子I Φ/4π、E I·cosθ/r²但没人会在建材市场掏笔算。所以这个工具的价值不在算法在于把两条式子做成一个输入框。它也算不了全部均匀度、眩光、显色性都还得看别的前面那节写了我不算什么。至少你从此不会因为买了 1500 流明的灯而以为书桌一定够亮真要说够得把灯到桌面的距离量出来让平方反比替你说话。本地怎么跑gitclone https://atomgit.com/yl4928/desk-lux.gitcddesk-luxnpmtest# 零依赖7 个用例nodeevidence/diff.mjs# 定点参考实现 vs 引擎8585 次跨实现断言# 界面双击 index.html写在最后这一篇最让我满意的是那条圆盘对拍。它不是我算了一遍你也算了一遍结果一样而是一个用积分算、一个用解析解算中间把网格加密十倍误差必须老老实实降一百倍。这种验证不会因为改错一行代码而侥幸通过——它验的是形状不是点。至于 300 勒克斯该不该是 300那是标准的事我把它做成输入框灯到底够不够亮你自己填三个数就能算出来。本工具用于理解光通量与照度的关系及选购参考不构成照明设计或用眼健康建议。
800 流明的灯为什么照到 1.6 米就只剩 25 勒克斯一键开通华为云码道 CodeArts 代码智能体 https://developer.huaweicloud.com/codeartsco.html?sourcedmzntgwatomgit1sourceaddmzntgwatomgithd先说这东西是什么一个零依赖的单页网页。填四个数灯泡总光通量、灯到桌面的距离、光线入射角、你想要的照度。它告诉你桌面实际有多少勒克斯、离目标差多少、这盏灯能均匀照亮多大一块圆、以及按光效折算这大概是几瓦的灯。仓库在 atomgit.com/yl4928/desk-luxMIT双击 index.html 就能跑。为什么做这个我给我家书桌换过一次灯。买的时候盯着瓦数看觉得 9 瓦 LED 挺亮装上去一照桌面还是暗。后来才搞明白我看错了两个东西一瓦数是耗电不是亮度。同样 9 瓦光效 60 lm/W 和 110 lm/W 差将近一倍。二就算看流明也没用。流明是灯泡往外发的总量桌面收到多少是另一回事中间隔着距离、角度和受光面积。阅读要 300 勒克斯这句话从来没人和自己家那盏灯对上过。所以我把这个换算做成了一个能填数字的页面。四条式子就把事情说完了均匀照明 E Φ / A 照度 光通量 / 受光面积 点光源强度 I Φ / (4π) 各向同性假设下 点光源照度 E I · cosθ / r² θ 是光线与桌面法线的夹角 反推需求 Φ E · A单位Φ 流明(lm)、I 坎德拉(cd)、E 勒克斯(lx)、A 平方米(m²)、r 米。把 800 流明代进去看看它随距离怎么塌800 lm 各向同性点光源垂直入射 0.2 m - 1591.5 lx 亮到刺眼 0.3 m - 707.4 lx 0.5 m - 254.6 lx ← 台灯典型高度还差一点到 300 0.8 m - 99.5 lx 1.2 m - 44.2 lx 1.6 m - 24.9 lx ← 吊灯挂在这个高度桌面就是能看见级别这张表解释了一件很常见的事为什么吊灯亮堂堂、书桌却暗。灯到地面的高度是 2.4 米你干活的地方在 1.6 米以下同一盏灯到你眼睛前面那本书记的照度只有到地面的一半不到——而人的直觉是房间挺亮。角度那一栏也值得看同一盏灯同样的距离光线斜 45 度入射照度直接乘 cos45° 0.707。白色系这一批三篇统一白色系。这一篇的强调色是琥珀 #a86a12灯光的暖调警示色 #b3261e 只在差多少 lx那句和不达标的进度条上出现。全部内联、零外部资源、file:// 双击可跑观感目标是一张打印出来的检测记录单。提示词钉到函数级这一篇的规格我写得比上一批更克制——因为上一批学到规格越重码道越容易空转。1) illuminance(flux, area) E flux / areaarea 0 时 throw RangeError 2) luminousIntensity(flux) I flux / (4π) 3) pointIlluminance(I, dist, cosT) E I × cosθ / dist²dist 0 时 throw RangeError 8) diskIlluminance(luminance, R, h, n) 数值积分同心环面元第 k 环半径 r_k (k-0.5)R/n环面积 dA 2π·r_k·(R/n) 斜距平方 d² h² r_k²两侧入射角余弦同为 h/√d²每环贡献 dE L·dA·cosθ·cosθ/d² 注意dA 必须是 2πr·dr不能写成 R²/n 或 πR²/n——上一版有人在这里丢了一个 π。最后那句不能写成 R²/n不是随手写的是我在自己的差分脚本里真丢过一次 π才知道这个坑有多好踩。最硬的一条对拍圆盘照度有解析解点光源是理想化。真实台灯灯罩是个发光的曲面所以我在引擎里放了一个有解析解可对照的数值积分半径 R、亮度 L 的均匀发光朗伯圆盘在轴线上距盘 h 处的照度教科书答案是E π·L·R² / (R² h²)推导很短取同心环 dA 2πr·dr斜距 d² h² r²两侧余弦都是 h/d于是dE L · dA · (h/d)² / d² 2πL·h²·r·dr / (h² r²)² ∫₀ᴿ 2πL·h² · [ R² / (2(h²R²)) ] πL·R²/(R²h²)引擎里的diskIlluminance用环带数值积分实现我的参考实现用 30 位定点整数算同一个积分两边都跟解析解比L1000, R0.1, h0.3解析值 314.159265359 n200 误差 3.738e-4 n2000 误差 3.738e-6 n20000 误差 3.738e-8 n200000 误差 3.738e-10网格每加密 10 倍误差正好降 100 倍——这是 O(h²) 中矩形法则该有的样子而且四位有效数字一点没飘。这条对拍比两个数相等有力得多因为它验的是收敛行为写错面元面积、写错余弦、漏掉 π全都活不过这一关。护城河连 π 都是自己算的上一批我把可信度押在国标全文上结果取不到一手文本只能写公开转载。这一批三个项目统一改成锚点放在纯数学上标准值只当可修改的输入。所以参考实现里我不允许自己用Math.PIπ 16·arctan(1/5) − 4·arctan(1/239) Machin 公式arctan 用整数级数 ln(x) 先用 2 的幂把 x 归一到 [0.5, 2]再用 2·artanh((x−1)/(x1)) exp(x) 参数约化到 |y| ≤ 1 做泰勒再连乘还原 √x 定点牛顿迭代 全程 BigInt比例尺 10³⁰只有整数运算先自检常数再判引擎pi 3.141592653590 与 Math.PI 一致 ln2 0.693147180560 sqrt(2) 1.414213562373然后跑差分8585 次跨实现断言0 分歧。脚本就在evidence/diff.mjs一条命令可重放。测试里我还专门留了一条防丢 π的断言// T7 面元面积不能丢 π// 闭式在 L1、R1、h0.05 处是 πR²/(R²h²) π/1.0025 3.133753...assert.ok(Math.abs(eng.diskIlluminance(1,1,0.05,200000)-Math.PI/1.0025)1e-4);如果实现把 dA 写成R²/n丢了 2πr 也丢了 π这条会差出好几个数量级。300 勒克斯这个数我把它降级成了输入界面默认目标照度填 300 lx来源是 GB 50034《建筑照明设计标准》里住宅书写阅读档的公开转载值。这台机器上我取不到该标准可访问的一手全文。上一批我在 README 里写标准规定评审直接指出这是替标准说话。这次我改了三件事一300 做成可修改输入不做常量二页脚和 README 都明写未取到一手全文取自公开转载仅作默认输入参考三把点光源近似这个更大的假设写在最前面——真实灯具的配光曲线不均匀本工具算出来的是理想化下限估计也就是最多这么暗实际可能更暗或更亮。工具最容易骗人的地方不是算错是把一个近似说成结论。这一轮我自己踩的坑规格写太重界面轮空转。第一版 UI 提示词我写了 2.7 KB把每个像素和每条禁令都展开了。码道跑到正文 10.5 万字、贴了 62 个代码块就是不落盘。停掉压到 1.8 KB只保留 id、公式、色值清单和禁止项一次过。给 AI 的规格不是越详细越好是越能一次做完越好。上下文涨到 12 万字之后什么都变慢。README 那轮在一个跑了七八个回合的老会话里正文 11.8 万字、结束但没提交。我新开一个会话重发同一条提示词60 秒落地。会话用久了要换新别指望它自己瘦下来。合并脚本时撞了标识符。我想把数学库和差分驱动合并成一个自包含文件提交进仓库结果库里已有const PI、const pow2驱动里也各有一个直接 SyntaxError。修法是合并时剔除库里那两个由驱动自定义的顶层声明。这类看起来只是复制粘贴的活恰恰最容易翻车。够不够那一列我一开始写死了目标值。界面表格第三列原本是照 300 lx 判的把目标改成 100 lx 之后表格还在说差 200 lx。改成随 target 动态判定才对。提效数据轮次交付结果R1src/engine.js 8 个函数 12 条锚点一次过R2package.json 7 个测试一次过本地 npm test 7/7R3index.html2.7 KB 规格空转停R4index.html1.8 KB 规格一次过控制台干净R5README LICENSE老会话结束但未提交R6README LICENSE新会话60 秒落地R7evidence/diff.mjs 入库一次过仓库内跑出 8585 断言 0 分歧已知边界不粉饰各向同性点光源近似。灯到桌面的距离小于灯具自身尺寸时比如台灯灯罩几乎贴着桌面误差很大。不含墙面、天花的反射光也不含灯具效率同样的灯珠罩子吃掉 20~40%所以算出来的照度普遍偏低于实测。未计维护系数灯用久了会衰减 20~30%。多盏灯需要逐盏算完再线性相加界面只算单灯。300 lx 这类参考值不替代专业照明设计真正要设计得看 GB 50034 原文和照度计实测。把瓦数思维换成流明-距离思维同一张桌子上我把几个常见组合用仓库里的引擎算了一遍数值就是页面算出来的灯光通量到桌面距离桌面照度够不够 300 lx60 W 白炽的 LED 替换泡806 lm0.45 m316.7 lx够客厅吸顶灯1500 lm1.6 m46.6 lx差 253.4 lx小台灯400 lm0.35 m259.8 lx差 40.2 lx台灯800 lm0.4 m397.9 lx够结论很反直觉一盏 1500 流明的主灯在你读书的位置上比不上一盏 400 流明的台灯。因为距离是平方反比而流明只是总量。1500 lm 1.6 m - 46.6 lx 400 lm 0.35 m - 259.8 lx 800 lm 0.4 m - 397.9 lx客厅那 100 勒克斯呢把目标改成 100 lx客厅一般活动的公开转载参考值一只 1600 流明的吸顶灯挂在 2.4 米1600 lm 2.4 m - 22.1 lx 连 100 lx 都差 77.9也就是说客厅很亮和客厅够亮是两回事——人眼对数响应加上天花板反射会让你觉得亮但桌面照度计不会同意。这张截图想说的是达标与否完全取决于你把哪个面当受光面同一个房间里沙发区够亮和书桌够亮是两件事。交付回执与仓库差分脚本入库后我重新 clone 验证过在仓库目录里直接跑$nodeevidence/diff.mjs 跨实现断言8585次分歧0条把数学库和驱动合并成自包含文件时两边都有const PI、const pow2直接撞出 SyntaxError。不在仓库目录里跑一遍这种问题根本发现不了。为什么用 4π以及它什么时候不成立各向同性点光源是个假得不能再假的模型——真实灯泡上方有灯头遮挡、台灯有灯罩、吸顶灯是面光源。我还是用了它理由有两个一它有一个可以手算的解析对照。圆盘那个例子里数值积分和 πLR²/(R²h²) 必须收敛到同一个数这能验出实现层面的错。二它是下限估计把光均匀撒到整个球面上任何方向的实际照度都不会比总量守恒地摊开更乐观地偏离太多。但它有明确的失效区我在 README 的已知边界里写了这里说得更具体当 观察距离 灯具自身尺寸 时点光源假设崩 例灯罩直径 20 cm桌面离灯罩 15 cm —— 此时 r 比灯具还小 点光源公式会给出偏高的照度因为把整个灯罩当成一个点 正确做法把灯罩面拆成多个面元逐个叠加本工具的 diskIlluminance 就是这条路也就是说界面里那个理想化下限估计的说法对台灯贴得极近的场景其实偏乐观。这是我愿意承认的模型边界而不是藏起来。这个工具不管的三件事买灯还有三个维度比照度更影响体验本工具一概不算免得让人误以为算出来够亮就行均匀度 桌面中心 500 lx、边缘 50 lx 也很难受本工具只算单点 眩光 灯珠裸露、遮光角小照度够但刺眼需要看 UGR 与灯具配光 显色性 Ra/Rg 与色温决定看着舒不舒服与流明无关上一批我做过台灯色温那篇那管处理光谱这管处理几何。两者不冲突也不互相替代。复用同一份数学库意味着什么这一批三篇共用同一个 30 位定点库π 用 Machin、ln 用 atanh 级数、exp 用泰勒、开方用牛顿迭代。复用的代价是我在合并成自包含文件时踩了标识符冲突两边都有 const PI好处是同一个 bug 只可能出现在一处被查到一次就三篇都干净。分贝篇要 log10照度篇要 π 和开方咖啡因篇要 ln2 和 exp——三个项目对数学库的覆盖面不一样合起来才算把这份库真正压过一遍。不打开网页时的三步心算工具是给较真用的日常判断有个粗糙版就够第一步 估强度 I ≈ Φ / 12.6 4π ≈ 12.566取 12.6 好算 第二步 除距离方 E ≈ I / r² r0.5 - 除 0.25即乘 4 第三步 比目标 阅读 300 lx、厨房操作 300 lx、客厅活动 100 lx 例一 800 lm 台灯灯头离桌面 0.4 m I ≈ 800/12.6 ≈ 63 cd E ≈ 63/0.16 ≈ 398 lx - 够读 例二 1500 lm 吸顶灯挂 2.2 m人坐桌前 r ≈ 1.45 m I ≈ 119 cd E ≈ 119/2.10 ≈ 57 lx - 差得远加台灯第二步最容易错的是距离要算灯到桌面不是灯到地面。坐着时桌面高约 0.75 m吸顶灯挂 2.22.4 mr 只有 1.451.65 m。这套心算和页面的精确值差在 5% 以内因为我把 4π 圆成了 12.6。页面上是精确数心算用来在建材市场做判断——两者对得上说明我没有把工具当成权威。怎么自己验一次这个换算我不要求你信页面。手上有一台带照度计 App 的手机多数安卓的 lux API 精度有限iOS 需要外接传感器可以做一次粗验证1. 关灯把手机放在桌面固定位置记录本底照度 E0通常 5 lx 2. 只开这一盏灯同一位置记录 E1 3. 量出灯发光中心到传感器平面的垂直距离 r以及光线与法线的夹角 θ 4. 查灯泡包装上的标称流明 Φ 5. 比对页面算的 Φ·cosθ/(4πr²) 与实测 (E1 - E0)差多少算正常我的经验判断是 20~40%来源有三个手机传感器余弦响应不好斜射光记不满、灯具不是各向同性灯罩把光往下压实测会高于页面值、房间反射也会偏高。所以如果实测明显低于页面值大概率是距离量错了或者灯泡实际流明虚标——这恰恰是页面能帮你发现的问题。这一段没有对应的自动化测试因为它是现实。工具能验的是算术验不了世界。为什么值得为够不够亮单独做一个工具照度是这一批三个项目里最看不见的量分贝你听得见咖啡因你有体感而勒克斯没有直接感觉——人眼会自动适应整体亮度你能判断这屋比那屋亮但判断不出300 还是 150。这恰恰是它需要被算的原因。买灯时包装上写流明、商家说瓦数、装修图上标照度三套单位互相不认。把它们串起来只需要两条式子I Φ/4π、E I·cosθ/r²但没人会在建材市场掏笔算。所以这个工具的价值不在算法在于把两条式子做成一个输入框。它也算不了全部均匀度、眩光、显色性都还得看别的前面那节写了我不算什么。至少你从此不会因为买了 1500 流明的灯而以为书桌一定够亮真要说够得把灯到桌面的距离量出来让平方反比替你说话。本地怎么跑gitclone https://atomgit.com/yl4928/desk-lux.gitcddesk-luxnpmtest# 零依赖7 个用例nodeevidence/diff.mjs# 定点参考实现 vs 引擎8585 次跨实现断言# 界面双击 index.html写在最后这一篇最让我满意的是那条圆盘对拍。它不是我算了一遍你也算了一遍结果一样而是一个用积分算、一个用解析解算中间把网格加密十倍误差必须老老实实降一百倍。这种验证不会因为改错一行代码而侥幸通过——它验的是形状不是点。至于 300 勒克斯该不该是 300那是标准的事我把它做成输入框灯到底够不够亮你自己填三个数就能算出来。本工具用于理解光通量与照度的关系及选购参考不构成照明设计或用眼健康建议。
