太阳高度角、天顶角、太阳方位角:定义、公式与光伏建筑农业实战应用
最近在复核一个光伏项目的阴影分析报告发现团队里几个同事对天顶角、太阳方位角、太阳高度角这三个词的理解不在一个频道上。有人把天顶角当成高度角填进了组件倾角计算有人拿着合作方给的太阳方位角数据做阵列排布结果东边和西边完全反了。这些问题在太阳能、建筑采光、农业温室设计里非常常见——三者定义高度相关但又彼此独立搞混一个后续所有计算全盘皆错。如果你正要接触光伏设计、日照分析、建筑节能模拟或者只是想在户外用手表判断方向这篇文章都值得花十分钟读完。我会把三个角的定义、底层原理、计算公式、完整算例和行业里的典型错误一次讲清楚尽量用大白话但该给公式的地方一个都不会少。1. 三个太阳角度到底是啥定义、基准、常见误区1.1 太阳高度角它只回答太阳有多高太阳高度角solar elevation angle常用 h 表示是太阳光线与其在地平面上投影之间的夹角。直观理解就是你站在平地抬头看太阳视线与地面之间的那个角。日出日落时太阳贴着地平线h 0°正午太阳升到最高h 达到一天中的最大值。它的范围其实是 -90° 到 90°地平线以下为负值也就是说晚上太阳高度角也是存在的、只是为负。这听起来像废话但在计算里非常关键——很多光伏反推算法需要判断太阳是否在地平线以上用的就是这个符号。正午高度角有个非常实用的快速算法h_noon 90° - |φ - δ|其中 φ 是当地纬度δ 是太阳赤纬。这个公式我建议所有做光伏的人都刻在脑子里因为组件倾角、前后排遮挡的初步估算全靠它。举个例子北京纬度约 40°N夏至赤纬约 23.45°正午高度角 90 - |40 - 23.45| 73.45°冬至赤纬约 -23.45°正午高度角 90 - |40 - (-23.45)| 26.55°。同一个地方夏天中午太阳挂得很高冬天中午却只比地平线高不到27°这直接决定了冬天光伏发电量的大幅下降。1.2 天顶角和高度角互余但不是同一个角天顶角solar zenith angle常用 θ 表示是太阳光线与天顶方向——也就是从观测点垂直向上的那条线——之间的夹角。关键关系只有一条θ 90° - h也就是天顶角和高度角互余。正因为这个简单关系很多人觉得两者只是同一件事的两种说法实际上在工程应用中它们的使用场景完全不同。气象数据、辐射模型里经常给的是天顶角而不是高度角因为很多辐射传输算法按天顶角推导更自然而光伏人习惯用高度角因为直观。我见过非常多的翻车现场有人把一份气象数据里的天顶角直接当成高度角输进模拟软件等于把本来该做减法的地方做成了加法角度整体抬高了。比如高度角30°的数据被当成60°来处理阵列间距的遮挡计算结果直接崩溃。一个容易忽略的细节在太阳刚好在头顶的瞬间天顶角为0°高度角为90°这两者相等除此之外绝大多数时间天顶角数值都大于高度角。记住一个画面太阳在地平线上时高度角0°但天顶角是90°——同一时刻两个角差了90°这就是互余的意义。1.3 太阳方位角从哪个基准起算决定了你看的是哪个世界太阳方位角solar azimuth angle常用 A 表示描述的是太阳在地平面上的投影方向即我们常说的太阳在东南方、西南方中的具体角度值。这里有一个大坑不同学科、不同软件对太阳方位角的起算基准和正方向约定不一致导致同一时刻的数据在不同系统里看起来完全不同。常见的约定主要有三种第一种从正南方向起算向西为正、向东为负范围 -180° 到 180°这是中国太阳能行业最常用的约定第二种从正北方向起算顺时针从 0° 转到 360°这是天文、地理和气象领域常用的约定第三种从正南起算但按顺时针方向增加范围 0° 到 360°部分国外软件和气象辐射资料会这样用。这三种约定本身没有优劣但混用时极为致命。比如同一时刻下午四点的太阳按第一种约定是 A 60°西南方向按第二种约定是 A 240°。你要是拿着约定一的数据填进约定二的模型结果必然是镜像的——正东变成正西全部反掉。我在实际项目中处理合作方数据时第一件事永远是问清对方方位角的基准。而基于各领域经验这里最稳妥的工作流是拿到数据后先根据大致时间和地点算一个粗略方位角再反推对方用的什么约定全部归一化后再进入后续流程。1.4 先记住这张表后面所有计算都是填表为了让你不看后面也知道怎么区分我把三者关系整理成一张速查表参数物理含义基准面常用范围与另外两个角的关系太阳高度角 h太阳视线与地平面的夹角水平面-90° ~ 90°h 90° - θ天顶角 θ太阳视线与天顶方向的夹角天顶垂线0° ~ 90°90°表示在地平线下θ 90° - h太阳方位角 A太阳投影方向与基准方向南或北的夹角地平面依约定而定与 h、θ 无简单线性关系这里最需要警惕的一点是高度角和天顶角之间只差一次减法但方位角和它们的计算关系要复杂得多——因为方位角涉及的是方向而不是仰角球面三角形里的耦合关系决定了它必须用包含时角和纬度的完整公式去计算。基础概念先到这里接下来进核心原理。2. 从原理到公式为什么要用这三个量2.1 三个底层输入纬度、赤纬、时角要算出任意时刻的三个太阳角度你需要三个底层变量观测点纬度 φ、太阳赤纬 δ、太阳时角 ω。纬度好理解就是你所在位置的南北位置。赤纬是太阳光线与地球赤道平面的夹角它随季节变化反映的是地球公转带来的太阳直射点南北移动。冬至直射南半球约 23.45°S夏至直射北半球约 23.45°N春秋分直射赤道为 0°。工程上最常用的是 Cooper 近似公式δ 23.45° × sin(360° × (284 N) / 365)其中 N 是当年第几天。比如 3 月 21 日左右 N 约 80括号里算出接近 360°sin 接近 0δ 接近 0°和春秋分一致。时角是三个变量里最容易被算错的一个。它反映地球自转带来的太阳东升西落每小时对应 15°正午时为0°上午为负下午为正。比如上午 10 点真太阳时时角 15 × (10 - 12) -30°下午 15 点时角 15 × (15 - 12) 45°。注意这里必须用真太阳时而不是你手机上的北京时间。后面 2.4 我会专门讲这里的坑。2.2 高度角公式能直接推出什么有了 φ、δ、ω太阳高度角的标准公式如下sin h sin φ × sin δ cos φ × cos δ × cos ω这个公式是球面三角学里余弦定理在太阳位置计算中的应用本质上是把天球上的位置关系转成地平坐标系。我不建议死记它而是建议你把它的几个特例推一遍正午时 ω 0°cos ω 1代入后合并可得 sin h cos(φ - δ)进而 h 90° - |φ - δ|——这就回到了前面说的正午高度角快速公式。日出日落时 h 0°sin h 0可以反推出日出日落时角 cos ω₀ -tan φ × tan δ。如果右边绝对值大于 1说明该地在当前季节出现极昼或极夜。这个判断在做高纬度光伏项目时非常有用。有了高度角遮挡分析就顺理成章了。光伏阵列前后排间距设计的基本逻辑是冬至日一年中正午高度角最低的日子之一上午 9 点到下午 3 点之间前排组件阴影不能遮挡后排。这需要逐时刻算高度角、方位角然后做几何投影但核心起点就是这条公式。2.3 方位角公式与象限修正方位角计算比高度角稍麻烦因为要处理象限。一个工程上很好用的计算公式是从正南起算、西正东负的 atan2 形式A atan2( sin ω, cos ω × sin φ - tan δ × cos φ )这里的 atan2 是带符号的反正切函数会自动根据分子分母的正负确定结果落在哪个象限一次出值不用手工修正。如果你的计算工具没有 atan2比如某些老旧的表格工具可以用余弦公式先算从正北起算的方位角cos A_north (sin δ - sin φ × sin h) / (cos φ × cos h)然后根据上下午判断方向上午太阳在东侧A_north 180°下午太阳在西侧A_north 180°。这种方式勉强可用但注意当太阳接近天顶时 cos h 接近 0公式会变得不稳定所以我还是推荐 atan2。一个快速自检方法是北半球任何一天正午之前太阳方位应该在东半边也就是从南起算为负值或者从北起算小于180°正午之后在西半边。如果在下午算出来一个负值方位角多半是你把符号约定搞反了。2.4 真太阳时与钟表时间的坑这是太阳位置计算里最容易翻车的环节值得单独展开。时钟上的时间叫钟表时间或平太阳时它与真太阳时之间存在两个偏差经度造成的偏差和地球公转速度不均匀造成的均时差。经度偏差的修正方法你所在经度与所在时区的标准经度每差 1°时间差 4 分钟。比如北京在东经 116.4°位于东八区标准经度是 120°E那么本地真太阳时要减去 (120 - 116.4) × 4 14.4 分钟。均时差是地球轨道离心率和黄赤交角共同作用的结果全年在 -14 到 16 分钟之间波动。工程上可用近似公式E 9.87 × sin(2B) - 7.53 × cos(B) - 1.5 × sin(B)其中 B 360° × (N - 81) / 364。真太阳时 钟表时间 经度修正 均时差。举个例子北京时间 14:00东经 116.4°N 1726月21日经度修正 -14.4 分钟均时差约 -1.5 分钟6月下旬真太阳时 ≈ 13:44时角 ω 15 × (13.73 - 12) ≈ 26°。我见过不少人在这一步直接用 14:00 算时角把 ω 写成 30°导致最终高度角差了一度多。对于阵列间距设计来说这一两度就会让阴影长度差出十几厘米积累起来不可忽视。3. 实战一个算例走完三个角度3.1 手算完整流程从北京夏至下午两点开始理论讲完我们实际算一遍。目标北京市区约 40°N116.4°E6 月 21 日北京时间 14:00求三个太阳角度。第一步算日序 N。6 月 21 日在平年里是第 172 天312831303121 172。第二步算赤纬 δ。用 Cooper 公式δ 23.45 × sin(360 × (284 172) / 365) 23.45 × sin(449.75°)。449.75° 减去 360° 后等于 89.75°sin 89.75° ≈ 0.99992所以 δ ≈ 23.45°。和夏至日理论值一致。第三步算真太阳时得到时角。北京时间 14:00经度修正116.4° 与 120° 差 3.6°3.6 × 4 14.4 分钟因为是向西偏移真太阳时要减去 14.4 分钟。均时差按前述公式估算约 -1.5 分钟。真太阳时 14:00 - 14.4 - 1.5 ≈ 13:44。时角 ω (13 44/60 - 12) × 15 ≈ 26°。第四步算高度角。sin h sin 40° × sin 23.45° cos 40° × cos 23.45° × cos 26°。取 sin 40° 0.6428sin 23.45° 0.3978cos 40° 0.7660cos 23.45° 0.9174cos 26° 0.8988。代入0.6428 × 0.3978 0.25570.7660 × 0.9174 × 0.8988 0.6319。相加得 0.8876反算 h ≈ 62.5°。第五步算天顶角。θ 90° - 62.5° 27.5°。第六步算方位角。用 atan2 公式A atan2( sin 26°, cos 26° × sin 40° - tan 23.45° × cos 40° )。sin 26° 0.4384tan 23.45° 0.4336。分母 0.8988 × 0.6428 - 0.4336 × 0.7660 0.5778 - 0.3321 0.2457。atan2(0.4384, 0.2457) ≈ 60.7°。结果为正表示太阳在西南方向从正南向西偏约 60.7°。手算完成结果可以做个合理性检查夏至北京正午高度角 73.45°下午两点的 62.5° 比正午低 10° 左右时角 26°、方位角 60.7°太阳确实在西南方一切符合直觉。3.2 Python 脚本30 行搞定任意时间地点手算做一次可以加深理解但实际生产里你大概率需要批量计算。我给一个简短的 Python 实现基于标准库 math无需安装任何第三方包适合集成到小工具里。import math from datetime import datetime def solar_position(dt, lat, lon, tz_hour8): # dt: 本地时间lat: 纬度北正南负lon: 经度东正西负tz_hour: 时区 N dt.timetuple().tm_yday # 赤纬Cooper近似 delta 23.45 * math.sin(math.radians(360 * (284 N) / 365)) # 均时差分钟 B math.radians(360 * (N - 81) / 364) eot 9.87 * math.sin(2 * B) - 7.53 * math.cos(B) - 1.5 * math.sin(B) # 真太阳时小时 true_solar_time dt.hour dt.minute / 60.0 (lon - tz_hour * 15) * 4 / 60.0 eot / 60.0 omega 15.0 * (true_solar_time - 12.0) phi math.radians(lat) dlt math.radians(delta) omg math.radians(omega) sinh math.sin(phi) * math.sin(dlt) math.cos(phi) * math.cos(dlt) * math.cos(omg) h math.degrees(math.asin(sinh)) theta 90 - h az_atan math.degrees(math.atan2(math.sin(omg), math.cos(omg) * math.sin(phi) - math.tan(dlt) * math.cos(phi))) return h, theta, az_atan # 北京夏至下午2点 dt datetime(2025, 6, 21, 14, 0) h, theta, az solar_position(dt, 40.0, 116.4, 8) print(f高度角 {h:.1f}°, 天顶角 {theta:.1f}°, 方位角(南为0西正) {az:.1f}°)运行结果应该和手算高度角 62.5°、方位角 60.7° 基本一致。脚本里把经度、时区、均时差全部纳入了真太阳时修正换任何城市都只需要改参数。一个提醒代码里方位角用的是从正南起算、西正东负的约定如果你需要从北起算加一句az_north (az 180) % 360即可。3.3 用 Excel 也能算在项目里更常见如果项目要求可复现的表格存档Excel 反而是更好的选择。我常在配表格里这样设置A 列填日序 NB 列填纬度C 列填赤纬D 列填时角E 列填高度角F 列填方位角。Excel 的三角函数默认用弧度所以公式里要包一层 RADIANS。以 E 列为例DEGREES(ASIN(SIN(RADIANS(B2))*SIN(RADIANS(C2))COS(RADIANS(B2))*COS(RADIANS(C2))*COS(RADIANS(D2))))。F 列方位角用DEGREES(ATAN2(COS(RADIANS(D2))*SIN(RADIANS(B2))-TAN(RADIANS(C2))*COS(RADIANS(B2)), SIN(RADIANS(D2))))。这里有个很重要的参数顺序问题Excel 的 ATAN2(x_num, y_num) 第一参数是 x 坐标、第二参数是 y 坐标和其他语言的 atan2(y, x) 顺序相反上面公式是把 x 放前面、sin ω 放后面。很多人在这里栽过跟头出来的方位角整个反了。建议写完公式后用一组已知数据比如北京夏至正午、春分上午 10 点先校对一轮再投入正式使用。4. 行业里的实际用法光伏、建筑、农业都在用这三个角4.1 光伏组件倾角选多少阵列间距怎么排光伏行业的太阳角度计算贯穿设计全流程。组件倾角优化的目标是让全年发电量最大工程上常用全年辐照量最大倾角经验值——大部分地区在纬度附近加减 10° 左右但真想做好就得逐时计算太阳位置模拟倾斜面上的逐时光照。这个模拟的核心输入之一就是太阳高度角直射分量需要根据入射角组件法线与太阳光线夹角做余弦修正而入射角由组件倾角、方位角和太阳高度角、方位角共同决定。阵列间距设计则主要依赖冬至日的极端低太阳高度角。以纬度 40° 地区为例冬至正午高度角约 26.5°上午 9 点可能只有 12° 左右。前后排间距要保证这些低角度时刻不被前排遮挡计算公式为D H × cos A / tan h其中 H 是前排组件顶端相对后排底端的高度差A 和 h 是该时刻的方位角和高度角。你可以看到方位角和高度角在这里共同决定了阴影方向和长度缺一不可。追踪系统就更依赖准确方位角了。平单轴追踪器要根据太阳方位角实时调整组件朝向算法错误哪怕只偏 5°全天发电量就会掉 1% 到 3%。我见过某项目直接把气象数据里的方位角按默认约定接进追踪算法结果所有追踪角度镜像发电量反而大幅低于固定支架。4.2 建筑遮阳板尺寸和日照分析建筑日照分析软件如天正、绿建斯维尔计算日照时间时用的是太阳高度角和方位角逐时逐分的数据。遮阳设计里比如你给西向窗户设计水平遮阳板需要知道夏季下午太阳的高度角和方位角来确定板出挑长度——高度角决定垂直投影长度方位角决定水平偏移两者配合才能确保遮阳又不挡光。这里有个很多建筑师容易忽略的点日照分析软件里的太阳方位角基准和光伏软件常常不同。建筑师习惯从正北起算、顺时针 0° 到 360°光伏工程师习惯从正南起算、西正东负两者相差 180° 再加镜像关系。当你跟建筑专业对数据时务必先搞清楚双方模型里的约定否则图纸上看着合理的遮阳板实际效果完全不同。另外国内建筑日照标准中要求的是有效日照时间不同城市规定不同有的是大寒日、有的是冬至日计算时必须按对应日期的太阳轨迹来分析。这直接决定了小区楼间距、户型开间等关键决策。楼间距不够导致冬至日底层住户无直射光在多地规划验收时一票否决背后全是太阳高度角的事。4.3 农业与生态温室透光率怎么估算农业温室大棚的采光设计同样离不开这三个角。温室朝向的选择依据是冬季太阳方位角分布区间——北半球温室通常朝正南或南偏东 5° 到 10°目的是在冬季太阳高度角低的时候尽量多捕获下午的阳光因为下午气温较高光合作用效率也好。温室屋面倾角的设计则会参考冬季正午的太阳高度角如果屋面倾角接近 90° 减去正午高度角太阳光在中午前后能近似垂直入射到屋面上反射损失最小。比如北方地区冬季正午高度角约 30°屋面倾角取 50° 到 60° 比较合适。这里如果误把天顶角当成高度角来算设计角度会完全偏掉冬季透光率大幅下降。还有农业上常用的影子判断方向法——立一根杆影子最短的时刻是当地真太阳时正午影子指向正北北半球。这个方法的原理就是正午时太阳高度角最大、方位角为 180°从北起算或 0°从南起算。手表定向法也是基于太阳方位角的粗略估算北半球将时针指向太阳时针与 12 点方向的角平分线就是正南方向但这个方法在太阳高度角很低和纬度较高时误差明显原理就是此时方位角与表盘角度的对应关系被破坏了。5. 高频翻车现场与避坑清单5.1 天顶角当高度角用差出来的 30° 白给这是我在各类项目里见到最多的低级错误。很多气象数据文件里提供的是天顶角比如某些典型气象年文件里的辐射模型参数或者卫星遥感反演产品。开发者看到zenith angle字段就直接当成高度角去用结果在北纬 35° 左右地区正午前后的天顶角大约 30° 到 55°跟高度角完全是两个量级代入遮挡计算后整个阵列间距模型崩溃。我的建议是拿到任何数据源后先别管后续流程单独检查这个角度字段的数值分布。如果一天中正午前后数值最小、早晚最大这是天顶角如果中午最大、早晚为零左右这是高度角。用这个分布特征几十秒就能判断清楚。5.2 方位角基准不同影子镜像全错方位角约定的问题在前面已经反复提过。实际项目中国际气象数据库比如美国能源部的 TMY 数据里太阳方位角从北起算、顺时针增加国内很多设计院的小工具从南起算、西正东负还有一些海外软件从南起算但按顺时针取 0° 到 360°。三个约定之间互相转换不是简单加减一个常数还可能涉及正负号翻转。最实用的排查技巧是取一个特征时刻做验证北半球正午太阳应该在正南方向从北起算为 180°从南起算为 0°上午在东南方向从北起算约 90° 到 180° 之间从南起算为负或 0° 到 -90°。如果某个数据在正午输出的是 0° 而不是 180°大概率它用的是从南起算的约定你要么整体换算、要么让输出方统一。5.3 本地时间、首都时间、真太阳时傻傻分不清时区问题也是高频坑。中国地跨五个地理时区但全国统一用北京时间这意味着新疆、西藏、云南等地的地方钟表时间和当地真太阳时可能差出一两个小时。以乌鲁木齐约 87°E为例当地时间中午 12 点时北京时间已经 14 点真太阳时约 14:00时角达 30°——如果你直接用北京时间 12 点去算太阳位置算出来的太阳还在东边大角度位置上实际太阳却已经在西南方了。凡是要精确计算太阳位置的场景都必须先做经度修正和均时差修正再进入角度计算。我推荐在项目脚本里把真太阳时作为一个独立变量输出方便核对。5.4 大气折射和海拔修正什么时候需要的、什么时候别加太阳高度角的几何公式没有考虑大气折射而实际观测中太阳光线穿越大气层会发生偏折使得太阳看起来比实际位置高。在地平线附近折射可以让高度角增加约 0.5°——这就是日出日落时太阳看起来扁的原因之一。当太阳高度角大于 10° 时折射修正量通常小于 0.1°可以忽略。工程上我的建议很简单除天文观测、日出日落时刻精确计算之外一律忽略折射修正。如果你做的是日出日落特别长的高纬度项目可以用简化的 Bennett 公式近似修正但普通光伏、建筑项目用这个修正纯属给自己添乱因为后续模拟精度根本达不到这个量级。海拔的影响主是大气密度变化对折射的影响在太阳角度几何计算里完全可以忽略。5.5 三个角快速自查口诀实测下来真的好用给一套我用了很多年的快速检查方法做完任何太阳角度计算后顺手过一遍能揪出九成以上的方向性错误正午高度角 90° - |φ - δ|如果算出来偏差超过 1°检查时角和赤纬。上午太阳方位必在东侧下午必在西侧。北半球从南起算上午 A 0下午 A 0。天顶角永远大于等于高度角太阳在地平线上时大 90°在天顶时相等为 0°——其实是天顶角最小为 0、高度角最大为 90。正午前后方位角变化最快尤其是低纬度地区正午时刻附近方位角可能从 89° 直接跳到 -89°这不是公式错了这是角度穿越北方向/南方向时的正常跳变。再补充一条数据处理的建议所有外部输入的太阳角度数据入库前做一次全年逐时回放把每个时刻的角度画成太阳轨迹图高度角 vs 方位角。如果轨迹在夏季和冬季呈平滑的拱形曲线数据大体可信如果出现突变、跳跃、镜像说明角度约定或时区处理有误。这一步值得投入半小时能省下一百小时的返工。最后分享一点实际体会我最初学这三个角的时候也被各种公式和约定绕得头昏。现在回头看最关键的不是背公式而是建立一套验证直觉的工作习惯无论用哪个工具、哪份数据先拿一个你已经知道答案的时刻去反推确认方向和量级都对再放手处理批量数据。太阳位置计算是太阳能、建筑、农业领域所有分析的基石这一层错了上面再漂亮的算法都白搭。希望这篇文章能帮你少踩几个我曾经踩过的坑。

相关新闻

Atlas 300V推理加速卡部署YOLO实战:从ONNX转换到性能调优

Atlas 300V推理加速卡部署YOLO实战:从ONNX转换到性能调优

后台三天两头有人来问:atlas部署yolo到底怎么搞?atlas 300v 24g是不是一块运算加速卡,买回来能不能直接跑模型?说实话,这两个问题背后其实是同一件事——昇腾生态里的Atlas系列板卡,在实际生产中到底怎么跟…

2026/9/25 10:54:34 阅读更多 →
Atlas 300V 24G推理加速卡部署YOLO全攻略:从模型转换到性能调优

Atlas 300V 24G推理加速卡部署YOLO全攻略:从模型转换到性能调优

最近不少同行在私信里问我同一个问题:Atlas 300V 24G是不是运算加速卡,能不能跑YOLO。这个问题每次线下技术交流也会被翻出来,可见大家对这个卡确实感兴趣,但官方资料又写得不够接地气。我直接给结论:Atlas 300V 24G就…

2026/9/25 10:54:34 阅读更多 →
VsCode安装Copilot详细教程:用TaoToken统一Key接入AI补全的配置与验证

VsCode安装Copilot详细教程:用TaoToken统一Key接入AI补全的配置与验证

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

2026/9/25 10:53:34 阅读更多 →

最新新闻

Atlas 300V 24G推理卡实战:YOLO模型部署全流程与性能调优

Atlas 300V 24G推理卡实战:YOLO模型部署全流程与性能调优

1. 这卡到底是干什么的?先把Atlas 300V的定位搞清楚先说结论:Atlas 300V 24G是一张推理加速卡,不是用来跑训练的GPU,也不是传统意义上的“显卡”。不少朋友第一次看到这个命名会以为它和游戏显卡或者工作站显卡是一类东西&#xf…

2026/9/25 12:53:24 阅读更多 →
Atlas 300V 24G 推理加速卡上部署 YOLO:从 PyTorch 到昇腾 NPU 完整指南

Atlas 300V 24G 推理加速卡上部署 YOLO:从 PyTorch 到昇腾 NPU 完整指南

最近总有朋友问,“Atlas 300V 24G是运算加速卡吗?”“YOLO到底能不能在Atlas上跑起来?”正好我这段时间在一台装了Atlas 300V 24G的服务器上,把YOLOv5和YOLOv8的推理流程完整走了一遍,中间踩了不少文档里没写清楚的坑。…

2026/9/25 12:53:24 阅读更多 →
Atlas 300V部署YOLO全流程:从环境配置到性能优化

Atlas 300V部署YOLO全流程:从环境配置到性能优化

在做AI推理这块的朋友,最近应该经常听到“atlas”这个名字,尤其是搭配“atlas部署yolo”这个关键词一起出现。我估计不少人和我一样,第一次看到“atlas 300v 24g”时,第一反应是:这到底是不是一张运算加速卡&#xff1…

2026/9/25 12:53:24 阅读更多 →
七个Agent撑起围棋小程序:场景拆解、提示词设计与结构化输出

七个Agent撑起围棋小程序:场景拆解、提示词设计与结构化输出

做了大半年围棋小程序,真正让我觉得“这产品有AI味”的,不是接了个会下棋的引擎,而是藏在功能后面的七个Agent。它们分别负责规则问答、术语解释、棋谱转述、全局复盘、单步点评、死活题判题和用户意图路由。每个Agent都有自己的提示词、输入…

2026/9/25 12:53:24 阅读更多 →
DeepSeek Engram 配置实战:给 MoE 模型加一张 N-gram 记忆小抄

DeepSeek Engram 配置实战:给 MoE 模型加一张 N-gram 记忆小抄

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

2026/9/25 12:53:24 阅读更多 →
从免费CRM到独立部署:小团队搭建私人CRM网站全记录

从免费CRM到独立部署:小团队搭建私人CRM网站全记录

上个月我终于把客户资料从微信聊天记录、Excel表格和记事本里统一搬了出来,全部塞进了一套自己部署的CRM系统里。项目代号DeskcommCRM,听起来像个大厂产品,其实是我基于开源组件和一台轻量云服务器搭起来的私人客户关系管理网站。到今天跑了1…

2026/9/25 12:52:24 阅读更多 →

日新闻

AI元人文:从工具使用到思维重构的深度探索

AI元人文:从工具使用到思维重构的深度探索

最近半年我一直在琢磨一件事:AI元人文到底是什么?说白了,就是“用元视角重新审视人与AI的关系”,也在“探索AI如何反向逼着我们发现自己的思考边界”。标题里的“元探索”,在我看就是一层套一层的追问——当你用AI解决…

2026/9/25 0:00:41 阅读更多 →
Python+CNN车牌识别实战:从数据预处理到模型训练与部署

Python+CNN车牌识别实战:从数据预处理到模型训练与部署

简介:基于Python与卷积神经网络的车牌识别项目,面向计算机视觉初学者及智能交通开发者,目标是帮助用户掌握从数据预处理、模型构建到实际部署的完整流程。压缩包共25个文件,包含jpg/png图像样本、py训练脚本、md说明文档、dat数据…

2026/9/25 0:00:41 阅读更多 →
Vim基础操作全攻略:保存退出、模式切换与高频命令实战

Vim基础操作全攻略:保存退出、模式切换与高频命令实战

1. 项目概述1.1 核心需求解析今天聊聊Vim。写这个题目的原因是:几乎每个后端开发者、运维人员、数据工程师某天都会遇到一个场景——深夜加班,服务器登录界面只有黑底白字,编辑器只有vi/vim,你必须在五分钟内完成一次配置修改并保…

2026/9/25 0:00:41 阅读更多 →

周新闻

Flutter for OpenHarmony游戏卡片渐变背景实战:从原理到性能优化

Flutter for OpenHarmony游戏卡片渐变背景实战:从原理到性能优化

直接铺开项目本身吧。这几个月我一直在折腾一件事:用Flutter给OpenHarmony做一款游戏集合类的App,说白了就是把若干小游戏塞进一个壳里,用统一入口分发。这个方向本身不算新鲜,真正让我花了不少心思的,是首页那堆游戏卡…

2026/9/24 14:34:13 阅读更多 →
Word表格编号全攻略:从列表编号到题注交叉引用

Word表格编号全攻略:从列表编号到题注交叉引用

写Word文档,最让人头疼的往往是那些“看起来不起眼”的小问题。比如表格编号这事:今天在表后面多加了两个空白行,明天给客户交稿前发现整个章节的编号全部错位,光是挨个改序号就能耗掉大半个下午。我前阵子帮人整理一份上百页的技…

2026/9/25 11:15:26 阅读更多 →
从第一个站到第二个站:独立开发者的静态网站选型与落地实践

从第一个站到第二个站:独立开发者的静态网站选型与落地实践

1. 项目概述1.1 核心需求解析做独立开发者这几年,说实话,第一个网站上线的那天晚上我兴奋得没睡着。但等它跑了半年,流量惨淡、功能臃肿、代码自己都懒得看第二遍之后,我才慢慢琢磨明白一个道理:第一个网站是练手&…

2026/9/24 14:33:56 阅读更多 →

月新闻

持续集成 流水线自动化与 声明式交付 实践:原型怎样变成可用功能

持续集成 流水线自动化与 声明式交付 实践:原型怎样变成可用功能

持续集成 流水线自动化与 声明式交付 实践:原型怎样变成可用功能分类:[AI/大模型]细分主题:AI 增强型 CI/CD 流水线自动化与 GitOps 实践:Agent 工作流、工具调用与任务拆解:从原型到生产的验收清单很多团队在尝试用大…

2026/9/24 12:50:34 阅读更多 →
容器编排 生产环境运维与排障实战:复盘记录怎样真正派上用场

容器编排 生产环境运维与排障实战:复盘记录怎样真正派上用场

容器编排 生产环境运维与排障实战:复盘记录怎样真正派上用场分类:[工程技术]细分主题:Kubernetes 生产环境运维与排障实战:可复制的项目复盘模板与决策记录大部分团队的事故复盘报告,最后都变成了躺在 Confluence 或钉…

2026/9/24 14:33:48 阅读更多 →
容器 容器化技术与镜像安全管理:核心链路应该先拆哪一步

容器 容器化技术与镜像安全管理:核心链路应该先拆哪一步

容器 容器化技术与镜像安全管理:核心链路应该先拆哪一步分类:[工程技术]细分主题:Docker 容器化技术与镜像安全管理:核心链路的逐步实现与关键代码取舍面对一个积累了五六年历史包袱的单体架构应用(包含 Web 接口、后台…

2026/9/24 12:49:17 阅读更多 →