知乎科技说实话，看到2026年美赛问题E把"被动式太阳能遮阳"搬上来的时候，我第一反应是：这不是建筑设计题吗？但如果你把题目里那几个关键词拆开揉碎，就会发现它其实是一道非常典型的策略优化题——表面在谈遮阳板、太阳能得热，底层要的是你在节能、舒适、成本、气候适应性这几组互相打架的目标之间找平衡。对大多数队伍来说，这个题算比较友好的：不依赖重型仿真软件，不需要极高的编程门槛，但很考验建模思路的完整度和论文叙事的说服力。这篇文章就把我准备这个题时的完整思路捋一遍，从题目拆解、物理量建模、优化框架，到一套能直接跑的Python代码骨架，再到论文拿分点，一次性说清楚。
1. 读懂"被动式太阳能遮阳"这个题，先别急着写公式
1.1 题目到底在问什么：一个关于"如何选择"的问题
拿到题目第一件事，不是查资料，不是下数据，而是先把问题重新表述一遍。被动式太阳能遮阳，关键词是"被动式"——它不靠光伏、不靠机械制冷、不靠主动控制电路，而是靠建筑本身的朝向、遮阳构件的几何形状、围护结构的热惰性，来实现"夏天少吸热、冬天多得热"。
那这个题目到底要你做什么？我理解它不是一个纯物理计算题，而是一个"在给定气候条件下，为某类建筑设计遮阳方案，并在多个目标之间做权衡"的综合问题。你要回答的不只是"这个遮阳板角度对太阳辐射阻挡了多少"，还包括"这样的遮阳方案对全年能耗影响多大""住户舒适度会不会受影响""改造成本值不值得""在不同纬度和气候下方案要不要变"。
换句话说，题目给的是一栋楼和一个遮阳装置的物理场景，但真正考的是你如何建立一套从物理输入到策略输出的决策框架。这个认知一定要先建立，否则后面很容易陷入"死磕热传导方程"的泥潭。
1.2 被动式三件套：朝向、遮阳装置与蓄热体
被动式太阳能设计里有三个常被并提的要素，题目虽然聚焦"遮阳"，但你建模的时候很难绕开另外两个，因为它们和遮阳是耦合的。
第一个是朝向。同样一栋建筑，朝南立面的冬季太阳辐射收益和夏季遮阳难度完全不同于朝西立面。朝西是夏天最头痛的方向，下午太阳高度角偏低，直射辐射很强，普通水平遮阳板根本挡不住——这是很多人在第一问就可能踩的坑。
第二个是遮阳装置。它可以是固定式的（挑檐、遮阳格栅、固定挡板），也可以是可调式的（百叶、外遮阳帘、内窗帘）。固定式的好处是零维护、不耗能，坏处是冬夏需求矛盾时只能取折中；可调式虽然灵活，但要考虑控制策略——什么时候展开、什么时候收起、人工操作还是自动控制。
第三个是蓄热体。墙体、楼板、地面的热容会把白天吸收的热量延后释放，这个"热惰性"和遮阳是联动的：遮阳挡掉了部分白天得热，蓄热体的存在又决定了这些得热何时变成室内冷负荷或热负荷。做简化模型时可以先把蓄热体作为恒定热容处理，后面灵敏度分析再考虑它的影响。
1.3 这类题最容易翻车的起点
我见过不少队伍拿到这个题之后，第一反应是去翻ASHRAE手册，把逐时太阳辐射公式、墙体传热函数、窗户U值、太阳得热因子逐项列出来，然后试图做一个"毫米级精度"的能量模拟。方向没错，但作为美赛建模，这里有个致命的坑：你只有三天，而且评委更关心的是你的分析逻辑和决策建议，不是把你的模型精确到和EnergyPlus误差小于5%。
最容易翻车的三个起点：
第一，一上来就陷入逐层墙体传热的偏微分方程。你当然可以写，但很难在三天内验证，更难以支撑后续的优化与决策部分。第二，把所有精力放在物理公式推导上，导致数据收集、图表绘制、灵敏度分析、政策建议全部潦草带过。第三，忽略"不同地区气候差异"这个变量，用一组固定参数跑完全程，这让你的结论非常单薄。
我的建议是：先做一个"够用但是完整"的简化物理模型，把物理量都定义清楚，然后用它跑通一套"输入气候—模拟运行—输出评价指标"的链路，再做优化，这样层次感就有了。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 从太阳位置到建筑得热：先把物理底账算清楚
2.1 太阳几何：任何太阳能模型都绕不开的第一步
无论是算太阳辐射、遮阳效果，还是冬夏得热差异，第一步永远是算太阳在天空中的位置。太阳高度角决定辐射穿过大气层的路径长度，太阳方位角决定它和建筑立面的夹角，这两个角直接决定一个有遮挡的窗户实际能接收到多少辐射。
基础公式在这里：
- 赤纬角：δ = 23.45° × sin(360° × (284 + N) / 365)，N是日期序号。
- 时角：H = 15° × (地方太阳时 - 12)。
- 太阳高度角：sin(alpha) = sin(φ)sin(δ) + cos(φ)cos(δ)cos(H)，φ是纬度。
- 太阳方位角可以用cos公式或者atan2版本，我建议在代码里用atan2，因为能正确处理全天各个时刻的角度，不会出现象限判断问题。
这里提醒几个容易错的地方：时角必须在"地方太阳时"下计算，而不是北京时间或标准区时。你需要先根据经度修正时区差，再应用均时差公式（EoT），否则算出来的高度角在早晨和傍晚会明显偏离实际。很多入门代码都栽在这个细节上。
另一个常见错误是直接用水平面总辐射数据当作窗户接受到的辐射，忽略了入射角的投影效应。真实情况下，垂直窗户上的辐射等于法向直射辐射乘以入射角余弦，再叠加散射辐射。比赛时如果你没有法向直射数据，可以用典型气象年数据里的水平面总辐射，再配合一个经验系数简化处理——这一点在论文里说清楚，比硬造一个不准确的精确模型更受认可。
2.2 遮阳设施的关键参数不是"面积"而是遮阳系数
很多队伍一开始会把遮阳板面积、倾角当成核心变量去优化，这没错，但你需要把这些几何信息转化成一个能和建筑能耗模型对接的参数。这个参数就是遮阳系数（Shading Coefficient，SC）或者更通用的太阳得热系数（SHGC）。
SHGC的定义是：通过窗户进入室内的太阳辐射占室外入射太阳辐射的比例。普通双层玻璃SHGC大约在0.5到0.7之间，加装外遮阳之后，这个值可以降到0.1到0.3。内遮阳的效果通常比外遮阳差，因为一部分阳光已经在室内被转化为热量，内窗帘只能反射掉一部分、阻挡一部分，但热量已经"进屋子了"；外遮阳则直接在室外就把辐射挡掉了。
所以建模时，我会定义一个综合有效得热系数：
Q_solar_gain = G_normal × A_window × SHGC_window × SF_shading
其中SF_shading是遮阳装置的遮挡系数，不遮时取1，全遮时取0到0.2之间。这个公式虽然简单，但它把"窗户本身"和"遮阳行为"解耦了，后续做优化时，你只需要把SF_shading作为决策变量，或者把它作为遮阳策略的输出，就能和建筑热平衡方程接起来。
2.3 一个够用的简化建筑热平衡模型
接下来的问题是：给了太阳辐射之后，房间温度怎么变化？需要拿能耗评价比较不同遮阳方案。
我的建议是用一个单节点热容模型，而不是搞复杂的多层墙体传热。虽然它忽略了墙体内的温度梯度和延迟，但对赛题级别的对比分析已经够用，而且计算量小，方便嵌入优化算法做成千上万次迭代。
简化热平衡方程可以写成：
C_room × dT_room/dt = Q_solar + Q_internal - UA_total × (T_room - T_out)
C_room是室内空气加上家具、内墙的等效热容，Q_internal是人员、设备、照明的内部得热，UA_total是围护结构的总传热系数乘以面积，T_out是室外温度。
用欧拉法逐时迭代，就能得到全年8760小时的室内温度变化曲线。有了逐时室内温度，就能统计：
- 夏季超过舒适温度上限（比如26℃）的小时数；
- 冬季低于舒适温度下限（比如18℃）的小时数；
- 需要辅助供暖或制冷的名义能耗，可以近似成UA_total乘上温差超出部分的积分。
这套模型的核心优点不是精度，而是"可解释"。每一个参数都可以讲清楚物理含义，每一处简化都能在灵敏度分析里被检验。竞赛里，"解释清楚假设 + 完整跑通流程"的分数，往往比"公式复杂但算不明白"高得多。
3. 把"遮阳策略"变成数学优化问题
3.1 决策变量怎么定义
从竞赛解题的角度，遮阳方案可以抽象成几类决策变量。
第一类是固定遮阳几何参数，比如挑檐的挑出长度、遮阳板与窗户的夹角、遮阳板的宽度和间距。这类变量是连续的，优化出来之后就是一个具体的建筑构件设计。
第二类是遮阳控制策略，比如可调百叶的角度随太阳高度角的响应规则，或者"当室内温度超过某个阈值就启动遮阳"的反馈规则。这类变量可以表示成阈值、规则参数，也可以直接表示成一天24小时每个小时的遮阳状态。
第三类是材料与窗户组合选择，比如玻璃的SHGC、遮阳材料反射率、是否采用双层Low-E玻璃。这类是离散选择，适合用枚举或整数编码处理。
这三类变量不是互斥的。我建议比赛时将问题分成递进的层次：先固定建筑参数，优化遮阳控制策略；再比较几种不同遮阳装置的成本效果；最后做多城市气候推广分析。这样文章结构清晰，也不会在一个优化模型里堆太多变量导致算法跑不动。
3.2 目标函数怎么定：能耗与舒适度的权衡
如果只把全年能耗最小作为目标，优化器一定会告诉你：夏天全部遮满，冬天全部打开，并且尽量多用保温性能好的窗户。这个结论无趣，而且不符合真实生活——住户不会愿意为了节能一年四季被一块帘子关在屋子里。
所以目标函数必须考虑舒适度。我在做这类题时常用的做法是双目标：
minimize: 年度辅助能耗（制冷+供暖）
minimize: 不舒适小时数（室内温度超出舒适区间的小时数）
不舒适小时数可以简单定义为加权和：夏季每超过26℃一小时计1，冬季每低于18℃一小时计1。更精细一点，可以参考PMV、PPD这些热舒适指标。但PMV公式涉及代谢率、服装热阻、风速等一堆输入，比赛里很难全部估准，所以如果做简化版，建议用温度超限小时数，并明确说明这是对PMV的近似。
双目标问题的解不是唯一最优，而是一个帕累托前沿。你可以用NSGA-II跑出几十个非支配解，然后画出一条"节能幅度 vs 舒适度牺牲"的曲线。这条曲线在论文里非常有说服力，因为它展示了不同偏好下方案如何变化。
3.3 约束条件与情景设计
约束条件要覆盖物理可行性和使用可行性。比如：
- 遮阳装置的几何尺寸不能超出建筑立面范围；
- 可调遮阳的控制规则必须"因果可执行"，不能用未来温度数据去控制当前遮阳状态；
- 遮阳后的室内自然采光不能太差，可设定最低采光系数约束，或者用一个简化窗口照度模型来估计；
- 投资成本要在预算上限内。
情景设计方面，建议至少做两种：单城市全年对比，多城市气候推广。多城市选三个典型气候区就够了，比如一个夏热冬冷、一个寒冷干燥、一个温和海洋性。这样能得出"遮阳策略是否具有普适性"的结论。评委很吃这一套，因为环境类题目特别看重方案的可持续性和可推广性。
3.4 优化算法的选型逻辑
很多人上来就上遗传算法，但我觉得要根据决策变量维度来选。
固定遮阳几何优化，变量只有两三个连续量，用网格搜索加局部精修就够，没必要上启发式算法。可调遮阳策略优化，变量可能有几十个逐时状态，但可以通过滚动窗口+贪心规则简化。真正需要遗传算法的情况是：变量维度较高、目标函数非凸、带离散选择和多目标约束——这时候用NSGA-II或者粒子群都合适。
选算法的理由是比算法本身更重要。我在备赛时给自己定了一个原则：任何优化器跑出来的结果，都要能回代到热平衡模拟器里再验证一遍。因为启发式算法可能陷入局部最优，如果你不做回代验证，论文里的"最优方案"可能一跑模拟就崩了。
4. 一套能直接跑的Python骨架：从太阳角度到遮阳结果
4.1 数据准备：天气、位置、建筑参数
数据不用多，核心是三个：典型气象年的逐时室外温度、逐时水平面总辐射、建筑所在地的纬度和经度。这些可以从开源气象数据库直接下载，或者用题目可能附带的简化气候数据。如果没有逐时数据，可以用日平均数据配合正弦插值生成近似曲线，但分辨率会差一些。
建筑参数方面，至少需要：窗户面积、房间等效热容、围护结构总UA值、内部得热功率、门窗的SHGC。这些参数不需要精确到某栋真实建筑，可以设置一个"参考房间"，然后用灵敏度分析检验它们对结论的影响。
4.2 太阳位置计算模块
直接在代码里写一个太阳能角度计算函数，逻辑简单，方便替换。下面这段代码是我备赛时准备的简化版本，精度对竞赛足够：
python复制import math
import numpy as np
def solar_position(lat, lon, day_of_year, hour_of_day, timezone_lon=120):
# 纬度、经度、日期序号、小时数、时区参考经度（东八区为120）
# 1. 均时差（分钟）
B = 2 * math.pi * (day_of_year - 81) / 364
eot_minutes = 9.87 * math.sin(2 * B) - 7.53 * math.cos(B) - 1.5 * math.sin(B)
# 2. 地方太阳时（小时）
longitude_correction = (lon - timezone_lon) / 15.0
solar_time = hour_of_day + longitude_correction + eot_minutes / 60.0
# 3. 太阳赤纬角
declination = 23.45 * math.sin(2 * math.pi * (284 + day_of_year) / 365)
# 4. 时角（度）
hour_angle = 15.0 * (solar_time - 12.0)
lat_rad = math.radians(lat)
decl_rad = math.radians(declination)
hour_rad = math.radians(hour_angle)
# 5. 太阳高度角
sin_elev = (math.sin(lat_rad) * math.sin(decl_rad) +
math.cos(lat_rad) * math.cos(decl_rad) * math.cos(hour_rad))
elevation = math.degrees(math.asin(max(-1, min(1, sin_elev))))
# 6. 太阳方位角（从北顺时针，粗略版）
cos_az = (math.sin(decl_rad) - math.sin(lat_rad) * sin_elev) / (
math.cos(lat_rad) * math.cos(math.radians(elevation)) + 1e-6)
cos_az = max(-1, min(1, cos_az))
azimuth = math.degrees(math.acos(cos_az))
return elevation, azimuth
这个函数输入地点和日期时间，返回太阳高度角、方位角。对于朝向为南的垂直窗户，入射角可以由高度角和方位角换算出来；朝东朝西的窗户则需要额外考虑立面方位角差。解释代码时注意说明用近似式，避免被评委认为过度自信。
4.3 简化热平衡与遮阳决策模块
下面是一个逐时模拟主循环的骨架。核心思路是：每小时判断当前遮阳状态（这里用简单规则），计算太阳得热和围护结构热损失，用热容模型更新室温。
python复制# 模拟参数
C_room = 1.2e6 # 房间等效热容 J/K
UA_total = 45.0 # 围护结构总传热 W/K
window_area = 6.0 # 窗户面积 m^2
SHGC_window = 0.6 # 窗户太阳得热系数
Q_internal = 400.0 # 内部得热 W
# 气候数据：T_out 是逐时室外温度数组，G_h 是逐时水平面总辐射数组
# 数组长度均为 8760
T_room = 24.0
T_room_list = []
energy_use = 0.0
for i in range(8760):
hour = i % 24
month = int(i / 24) // 30 # 简化月份判断
# 遮阳策略：夏季白天启动遮阳，冬季白天不遮阳
summer = month in [5, 6, 7, 8]
daytime = 7 <= hour <= 18
shading_factor = 0.15 if (summer and daytime) else 1.0
# 太阳得热：粗略用水平面辐射估算，实际可按立面入射角修正
Q_solar = G_h[i] * window_area * SHGC_window * shading_factor
# 围护结构热损失
Q_loss = UA_total * (T_room - T_out[i])
# 温度更新（欧拉法，步长 3600 秒）
T_room = T_room + (Q_solar + Q_internal - Q_loss) / C_room * 3600.0
T_room_list.append(T_room)
# 辅助能耗：室温低于18度或高于26度时按差额折算
if T_room < 18.0:
energy_use += (18.0 - T_room) * UA_total
elif T_room > 26.0:
energy_use += (T_room - 26.0) * UA_total
这套代码虽然简化，但已经具备了一个模拟闭环：气候输入 → 遮阳规则 → 室温变化 → 能耗统计。你在赛题里可以把它扩展成三层：基础模拟、单目标优化、多目标优化。优化循环里反复调用这个模拟函数就行。
4.4 第一张能拿得出手的图
跑完模拟之后，第一张该画的图不是总能耗柱状图，而是"夏季典型周室温对比图"。横轴是小时，纵轴是温度，两条曲线分别是"无遮阳"和"有遮阳"的室温变化。这张图的冲击力极强——它能一眼看出遮阳方案在高温时段降低了多少度、有没有把峰值压低到舒适阈值以下。
第二张图建议画全年不舒适小时数的空间分布，比如以月份为纵轴、小时为横轴的热力图，颜色深浅代表温度超限程度。第三张图再画能耗优化帕累托前沿。这样从现象到机制，再到方案权衡，叙事逻辑非常顺。
画图时注意坐标轴单位、图例、阈值线标注清楚。美赛论文里，一张信息量大且标注规范的数据图，价值往往抵得上半页公式推导。
5. 论文拿分关键：摘要、灵敏度分析与给非专业读者的一封信
5.1 摘要怎么写：不是概括全文，而是推销结论
美赛评奖时评委在每篇论文上花的时间有限，摘要几乎是决定第一印象的最重要部分。问题E这类题目的摘要，不能按照"本文建立了XX模型"这种流水账去写，而应该在开头两句话就说清三件事：问题是关于什么的、你做了什么关键决策、结论是什么。
我的习惯结构是：
第一句：明确问题本质，比如"被动式太阳能遮阳需要在夏季遮阳效率与冬季太阳能得热之间寻找最优均衡"。
第二句到第四句：给出你的整体方法，包括建立的热平衡模型、优化目标、采用的算法。注意只提最核心的两个方法特征就够了，不需要把全部模型列出来。
第五句开始：直接给出具体结论。例如"针对夏热冬冷城市，可调外遮阳方案相比无遮阳方案可降低约XX%的全年辅助能耗，同时将不舒适小时数减少XX小时；针对寒冷干燥城市，固定挑檐+高遮阳系数玻璃的性价比最优"。
结尾一句：提你的灵敏度分析和可推广性结论。这样摘要读起来像一份决策简报，而不是论文提纲。
5.2 灵敏度分析：评委判断你模型是否稳健的主要证据
很多队伍把灵敏度分析放在最后草草写两段，这是很可惜的。对于E题这种环境类题目，参数不确定性是很重要的考察点，因为气候参数、建筑参数在真实场景里都有波动。
我建议至少做三类：
一是气候数据敏感性。把夏季温度整体上调2℃和下调2℃，看最优遮阳策略是否变化。如果最优策略几乎不变，说明方案具有很好的气候稳健性；如果变了，说明你的方案对气候阈值敏感，反而可以引出一个"适应性策略"的讨论。
二是建筑参数敏感性。UA值和SHGC是决定结果的骨架参数。你可以做局部敏感性分析，画出"总能耗随SHGC变化"的曲线。这个曲线也很有信息量：如果斜率很大，说明该参数是主导因素，后续政策建议可以聚焦窗户改造。
三是模型时间分辨率敏感性。把逐时模拟改成每天四个时段模拟，比较结论是否一致。如果趋势一致，说明你的模型结论不依赖时间细节；如果不一致，你要能解释为什么——往往是忽略了傍晚太阳辐射的延迟效应。
5.3 给决策者的一封信：美赛E题的隐藏加分项
美赛的E题和F题经常会要求"为非专业受众"写一份报告或一封信。别忘了这个要求，这往往是拉开差距的关键。
这封信和正文模型不同，不需要公式，甚至不需要技术术语。你要写的是一个地方政府官员或建筑设计师能够直接采纳的建议。结构可以是：
背景段：说明这个地区夏天过热、冬天过冷，空调能耗逐年上升，我们需要利用建筑本身的设计来缓解。
方案段：给出三条具体建议，比如"优先对朝西窗户加装外遮阳帘""在光热充足的地区推广高反射率外遮阳格栅""对新建建筑，把遮阳设计纳入规划审批环节"。
量化段：用一句话说明预期效果："模拟显示，这套方案可使试点建筑夏季高峰室温降低约X℃，空调能耗减少约X%。"
结尾段：强调推广路径，比如"建议先在公共建筑试点，再逐步向住宅小区推广"。
这封信500词左右就够，但要注意语气必须像"给市长写信"，而不是"给同学讲题"。
6. 关于备赛和选题的几条实操经验
6.1 为什么我建议普通队伍选E题
E题和C题一样，通常属于"数据和政策结合"的方向，但它比C题更欢迎简化物理模型，也更鼓励提出可实现方案。如果你的队伍是第一次参赛，或者成员里没有很强的算法选手，E题是一个性价比较高的选择：物理门槛可以控制在高中物理加一点点热工常识；数据需求不需要像大数据题那样处理海量表格；论文部分很容易发挥讲故事的能力。
但同时要提醒：E题做的人多，想脱颖而出就需要在"方案落地性"上做文章。只算能耗而不给改造建议，或者给了建议但没有成本估算，都会显得单薄。试着在模型后面加上成本效益分析，哪怕只是粗略的"遮阳装置投资回收期估算"，也会让你的论文更像一份完整咨询报告。
6.2 数据来源与资料筛选
准备E题，手边至少要有一个可以快速取用气候数据的渠道。推荐优先使用典型气象年数据集，这类数据包含全年8760小时的温度、湿度、辐射等要素，直接能喂给模拟模型。如果所在地区数据缺失，可以用NREL或类似机构生成的气候数据，或者使用简化气候数据文件并在论文里说明来源和假设。
建筑参数方面，不需要纠结于某个具体工程。你可以设定一个"参考建筑"，然后明确说明参数依据来自建筑热工设计规范中常见取值。规范给的节能设计参数是可以直接引用的，这比你在网上查到的各不相同的工程数值更权威。
6.3 三天的节奏怎么分配最合理
我建议把三天按"六段式"划分，避免沉浸在某一环节中出不来。
第一天上午完成问题理解、参考文献收集和物理模型草图；第一天下午到第二天中午完成基础模拟代码，并跑通"无遮阳 vs 固定遮阳"的对比结果；第二天下午完成优化框架，把决策变量和目标函数搭好；第二天晚上到第三天早上完成灵敏度分析和多城市推广模拟；第三天上午开始写论文，特别是摘要和给决策者的一封信；第三天下午完成图表统一、排版和逐段检查。
这个节奏的核心思想是：论文不是最后才写，而是从第二天下午就同步开始。很多队伍死在"最后八小时疯狂赶论文"，那样摘要和结论的质量一定不理想。
6.4 最后再提醒几个常被扣分的小毛病
第一，忽略单位。辐射强度、传热系数、热容的单位混用，会让所有结果差出几个数量级。备赛时建议在代码里统一使用国际单位制，并在论文里贴一个"符号与单位表"。
第二，把模拟结果当成绝对真值。任何气象数据都有不确定性，不要让论文像预言一样斩钉截铁。建议在结论里加上"在上述数据条件下"这类限定。
第三，代码和论文不对应。评委不一定会看你的代码，但如果论文里的公式和代码变量名对不上，一旦被抽查就很尴尬。写论文时把关键公式的符号和代码里保持一致，能省很多麻烦。
第四，忽略图表统一性。颜色、字体、线宽的混乱会降低专业感。提前在matplotlib里设定统一的绘图样式，包括字体大小、图例位置、正弦曲线的颜色循环，会让整篇论文的观感提升一个档次。
说实话，准备这种题目，最忌讳的就是把大量时间花在"让模型更精细"上。美赛的评分逻辑很现实：第一看你对问题本质理解得是否准确，第二看你的模型链条是否完整闭环，第三看你的结果是否有洞察力。被动式太阳能遮阳这个题，恰好就给了你把这三件事都做好的空间。公式不用堆，代码不用炫，只要把物理逻辑讲通、把优化逻辑讲顺、把建议讲得让人愿意采纳，这篇论文就一定差不了。