美赛A题指南：手机电池耗电建模与Python仿真实战

1. 这道题到底在考什么：先别急着写代码，把问题读懂

1.1 从一个参赛队的真实痛点说起

2026年美赛A题把目光投向了智能手机电池消耗。很多队伍拿到题的第一反应是去网上找电池数据集，或者直接套一个时间序列预测模型，结果做到第三天发现方向跑偏了。我经历过好几届美赛，也带队写过A题，最深的感受是：A题考的不是你会多少花哨的算法，而是你能不能把一个连续系统的物理规律用数学语言讲清楚，并且让评委在十页纸里看到你的思路是自洽的。

这道题的核心关键词有两个：一个是“建模”，一个是“代码”。建模解决的是“电池电量怎么随时间衰减”的问题，代码解决的是“这个模型能不能跑起来、能不能复现”的问题。美赛评委最讨厌的就是那种“我提出一个模型，但不知道怎么算”的论文。如果你能把一个即使简单但完整跑通的模型放在附录里，得分一定比堆砌三个半成品模型高得多。

1.2 电池消耗问题本质上是连续系统建模题

为什么美赛要把手机电池作为A题？往深了看，A题历年都偏向“物理过程建模”加“优化决策”，比如2019年的“龙卷风数据”、2021年的“真菌分解”。电池消耗恰好是一个典型的连续时间过程：电量是时间的函数，而且这个函数的形式取决于很多因素——屏幕亮度、后台应用数量、无线通信状态、信号强度、温度、电池老化程度。

如果你把它看作一个纯粹的“回归问题”，拿一堆特征去拟合剩余电量，那就偏离了美赛的出题意图。出题人真正想让你做的是：

• 建立电池荷电状态（SOC）随时间变化的微分方程或差分方程；
• 识别哪些因素对耗电速率有显著影响，给出量化关系；
• 用数据或实验设计来验证模型；
• 基于模型回答一个实际问题，比如“怎样的使用习惯能延长续航”或者“哪种充电策略最优”。

所以读完题的第一件事，不是打开Python，而是拿出一张白纸，写下：系统的状态变量是什么？输入是什么？参数是什么？边界条件是什么？这一套流程走完，你的建模骨架就清晰了。

1.3 你能从这篇博文里得到什么

我会尽量用一次完整的美赛A题解题流程来写这篇分享，而不是只讲理论。内容包括：数据怎么获取和构造（因为美赛往往不直接给你一份现成的电池数据）、如何从物理常识出发建立核心耗电模型、怎么用Python做参数估计、灵敏度分析怎么做、论文图表怎么画、以及最容易踩的坑和对应的排查办法。

不管你是第一次参加美赛的新手，还是常年混迹国赛、数模竞赛的老手，只要按照这套流程走，至少不会在A题上出现方向性错误。后续的所有代码片段，我都会以Python为主，用到的库尽量集中在numpy、scipy、pandas、matplotlib这几个最常见的库里，避免因为环境装不上影响你的进度。

2. 整体建模思路设计：先把“物理骨架”搭起来

2.1 为什么建议采用“机理+数据”的混合思路

很多队伍面对一道题，容易走两个极端：要么完全从物理机理出发，列一堆偏微分方程，最后自己都解不动；要么完全靠数据驱动，遇到什么训练什么，最后得到一个没有任何解释性的黑箱。

我个人的建议是：以机理模型为主体框架，用数据去校准参数。这样做的优势很明显：第一，机理模型在有数据之前就能给出合理的定性行为；第二，数据只用来拟合少数几个关键参数，降低了过拟合风险；第三，论文里可以清楚地解释每个参数对应的物理含义，这种“可解释性”在美赛评委那里非常加分。

具体到手机电池问题，最经典的做法是建立一个基于时间的SOC衰减方程：

[
\frac{dS(t)}{dt} = -r(t)
]

其中 (S(t)) 是时刻 (t) 的剩余电量（以百分比表示，范围0~100），(r(t)) 是瞬时耗电速率（单位：%/小时）。这个方程的物理含义很简单：电量的下降速度等于当前的耗电速率。但 (r(t)) 本身是复杂的，它取决于手机当前在做什么。

2.2 把耗电速率拆成“基础耗电+场景耗电”

一个合理的假设是：手机耗电速率由基础空闲耗电和任务相关耗电两部分组成。

[
r(t) = r_{base} + r_{screen}(B(t)) + r_{app}(A(t)) + r_{comm}(C(t)) + \varepsilon(t)
]

• (r_{base})：待机时的基础耗电，包括系统进程、信号搜索等。这个量一般来说比较稳定，可能每小时0.5%~1.5%；
• (r_{screen}(B(t)))：屏幕耗电，和屏幕亮度 (B(t)) 强相关，通常近似线性；
• (r_{app}(A(t)))：应用负载耗电，比如游戏、视频、导航等，不同的应用类型对应不同的功率等级；
• (r_{comm}(C(t)))：通信耗电，取决于是否使用4G/5G/Wi-Fi、信号强弱等；
• (\varepsilon(t))：随机噪声，用来描述不可预测的波动。

为什么拆成这几项？因为每一项都有明确的物理背景，而且每项都可以通过实验设计单独标定。比如你把手机屏幕关闭、所有应用退出、连接固定Wi-Fi，测出来的耗电就近似等于 (r_{base})；再打开屏幕固定亮度，测出来的增量就是 (r_{screen})。

2.3 电量作为积分结果：用离散化简化计算

因为真实使用场景中 (r(t)) 不是一个简单的连续函数，而是一段一段的（比如你刷了20分钟视频，然后切到微信聊天，再锁屏走路），所以实际计算时都会把时间离散化。设时间步长为 (\Delta t)（比如1分钟或5分钟），那么从 (t_i) 到 (t_{i+1}) 的电量变化可以写成：

[
S_{i+1} = S_i - r_i \cdot \Delta t
]

其中 (r_i) 代表时间段 ([t_i, t_{i+1}]) 内的平均耗电速率。这就是一个理想的差分方程递推模型。当你把用户一天的行为拆成一连串的“状态段”，每一段赋予一个耗电速率，累加起来就能预测一整天的电量曲线。

这种离散化处理的另一个好处是，它天然适合程序实现。用Python写一个for循环就能完成递推，不需要解复杂的微分方程。后面我会给出具体代码。

2.4 模型选型的横向对比

在实际比赛中，很多队伍也会考虑其他方案，我简单做个对比：

我的建议是：论文主模型用离散差分递推，配合一个从物理角度推导的耗电速率公式；可以适当用回归方法去标定参数，但不要让机器学习模型变成主角。原因很简单：美赛评委会更欣赏“你能解释每个变量为什么出现在公式里”，而不是“你的随机森林分数比对方高0.01”。

3. 数据处理与参数估计实战：没有现成数据也能做

3.1 数据从哪来：构造和采集两手准备

很多队伍到了比赛时才发现，美赛不像国赛那样给一份整理好的CSV文件。A题给出的往往是一段背景描述和几个问题要求。这时候你得多线并行：

• 如果题目里带附件，先检查附件字段，别急着建模；
• 如果题目没有附件，就自己构造一个符合物理规律的仿真数据集；
• 有条件的话，可以真的用一台手机实验半小时，记录不同场景下的耗电速率。

构造仿真数据时，核心原则是“参数要落在合理区间”。比如屏幕亮度0~100%对应的屏幕耗电增量，我参考主流手机的资料，可以在0.5%~2.0%/小时之间线性变化；大型游戏满载时总耗电可能达到15%~25%/小时；待机基础耗电按0.5%~1.5%/小时算。用这些数据生成“带有已知参数的模拟数据”，先跑通模型，再去回答题目的开放性问题，逻辑上就非常自洽。

3.2 Python实现数据预处理和可视化

假设我们自己生成一组“用户一天使用行为”的原始数据，包含时间点、行为类型、屏幕亮度、是否使用移动网络。下面这段代码用于生成模拟数据：

python复制import numpy as np
import pandas as pd

np.random.seed(42)

# 模拟时长：24小时，步长1分钟
time_minutes = np.arange(0, 24 * 60, 1)
n = len(time_minutes)

# 行为类型：0-待机, 1-亮屏浏览, 2-视频, 3-游戏, 4-通话
# 随机生成行为片段
behavior = np.zeros(n, dtype=int)

# 简单构造：设定几个典型时间段（真实的场景数据应来自调研或实测）
segments = [
    (0, 7 * 60, 0),          # 凌晨睡眠待机
    (7 * 60, 7 * 60 + 30, 1),# 早起看消息
    (8 * 60, 9 * 60, 0),     # 通勤锁屏
    (9 * 60, 10 * 60, 2),    # 上午刷视频
    (12 * 60, 12 * 60 + 40, 1),
    (18 * 60, 19 * 60, 3),   # 晚间游戏
    (22 * 60, 23 * 60, 2),   # 睡前视频
]

for start, end, b in segments:
    behavior[start:end] = b

# 屏幕亮度：待机为0，亮屏浏览为60%，视频为80%，游戏为90%
brightness = np.zeros(n)
for i in range(n):
    if behavior[i] == 1:
        brightness[i] = 60
    elif behavior[i] == 2:
        brightness[i] = 80
    elif behavior[i] == 3:
        brightness[i] = 90

# 通信状态：0-WiFi, 1-4G
comm = np.zeros(n, dtype=int)
comm[(time_minutes >= 8 * 60) & (time_minutes <= 9 * 60)] = 1
comm[(time_minutes >= 18 * 60) & (time_minutes <= 19 * 60)] = 1

# 保存到DataFrame
df = pd.DataFrame({
    'time_min': time_minutes,
    'behavior': behavior,
    'brightness': brightness,
    'comm': comm
})

print(df.head())
print(df['behavior'].value_counts())

这段代码本身没有做任何建模，但它把“用户如何使用手机”这个抽象问题，转换成了计算机可以处理的结构化数据。你可以根据题目要求调整时间段和行为类型，甚至加入更细的场景。很多队伍花了一天时间争论“电池耗电和哪些因素有关”，其实做一个这样的生成器，把所有可能因素都放进数据里，后面用相关性分析筛选，效率高得多。

数据生成之后，最好先画一张行为时间线图，看一下用户的“使用画像”。这一步看似简单，但能在论文里起到很好的数据展示作用：

python复制import matplotlib.pyplot as plt

fig, ax = plt.subplots(figsize=(12, 4))
ax.plot(df['time_min'] / 60, df['behavior'], drawstyle='steps-post', linewidth=1)
ax.set_xlabel('Time (hour)')
ax.set_ylabel('Behavior Type')
ax.set_yticks([0, 1, 2, 3, 4])
ax.set_yticklabels(['Standby', 'Browsing', 'Video', 'Gaming', 'Call'])
ax.grid(alpha=0.3)
plt.tight_layout()
plt.savefig('behavior_timeline.png', dpi=150)

3.3 参数估计：从数据反推耗电速率

有了行为序列和实测电量数据，下一步是估计各个场景下的耗电速率。如果你生成的是仿真数据，参数已知，这一步主要是验证模型能否反推出正确参数；如果你拿到的是真实采集数据，这一步就是核心工作。

方法上，最常用的是最小二乘估计。把电量变化写成矩阵形式：

[
\Delta S = X \cdot \beta
]

其中 (\Delta S) 是每个时间段的电量变化百分比，(X) 的每一行表示[r_base, r_screen, r_app, r_comm]对应的“开启时间或状态值”，(\beta) 就是我们需要估计的系数。

举个例子：第一分钟待机（基础耗电开启，屏幕关闭，无通信额外耗电），那么这一分钟的耗电可表示为：

[
\Delta S_1 = r_{base} \cdot 1 + r_{screen} \cdot 0 + r_{app} \cdot 0 + r_{comm} \cdot 0
]

第二分钟亮屏浏览且使用4G，那么这一分钟耗电为：

[
\Delta S_2 = r_{base} \cdot 1 + r_{screen} \cdot B + r_{app, browsing} \cdot 1 + r_{comm} \cdot 1
]

把所有分钟拼在一起，就是一个典型的线性回归问题。用Python的scipy或者numpy就能完成：

python复制import numpy as np
from numpy.linalg import lstsq

# 构造设计矩阵X，这里假设行为0、1、2、3、4分别对应不同的r_app
# 为简化，暂时把不同应用合并为一个“应用耗电等级”
n = len(df)

# 设计矩阵的列：常数项(基础耗电)、屏幕亮度、应用负载(0/1)、通信负载(0/1)
X = np.column_stack([
    np.ones(n),                 # 基础耗电
    df['brightness'] / 100.0,   # 屏幕亮度归一化
    (df['behavior'] > 0).astype(float),   # 是否有亮屏任务
    df['comm'].astype(float)    # 是否使用4G
])

# 假设我们已知真实参数，生成“观测”电量变化
true_beta = np.array([0.8, 1.2, 5.0, 3.0])  # 单位: %/小时
# 为了模拟真实场景，这里把每分钟的耗电换算成百分比
delta_S_true = (X @ true_beta) / 60.0 + np.random.normal(0, 0.05, n)

# 最小二乘估计
beta_hat, residuals, rank, s = lstsq(X, delta_S_true, rcond=None)
print("Estimated coefficients (per hour):", beta_hat * 60)

这段代码演示了如何用最小二乘法从“观测到的电量变化”反推出基础耗电、屏幕耗电系数、应用负载系数和通信耗电系数。真实比赛里，你可能没有这么干净的观测值，但方法是一样的。拿到参数后，你就可以用这些参数去预测任意行为序列下的耗电曲线。

提示：实际采集数据时，电量百分比通常是整数，而且存在量化误差。建议尽量拉长采样间隔（比如5分钟记录一次），同时做好平滑滤波，不然最小二乘估计出来的参数方差会很大。

4. 核心模型实现：从“现象描述”到“可复现代码”

4.1 离散时间递推模型的完整实现

下面给出一个完整的耗电预测函数，输入是行为时间表，输出是每分钟的电量百分比曲线。这个函数就是我前面说的“离散差分递推”的落地实现。

python复制def simulate_battery(df, beta, S0=100.0):
    """
    根据行为数据帧和时间递推模型预测电量曲线
    
    参数：
    - df: 包含time_min, behavior, brightness, comm列的DataFrame
    - beta: [r_base, r_screen, r_app, r_comm]，单位%/小时
    - S0: 初始电量百分比

    返回：
    - soc: 每个时间点的电量百分比数组
    """
    n = len(df)
    soc = np.zeros(n)
    soc[0] = S0

    # 针对不同行为，定义不同的应用负载系数
    app_load_map = {0: 0.0, 1: 1.0, 2: 1.5, 3: 2.5, 4: 1.0}
    app_load = df['behavior'].map(app_load_map).values

    for i in range(1, n):
        dt = (df['time_min'].iloc[i] - df['time_min'].iloc[i-1]) / 60.0
        r = beta[0] + beta[1] * (df['brightness'].iloc[i-1] / 100.0) \
            + beta[2] * app_load[i-1] + beta[3] * df['comm'].iloc[i-1]
        soc[i] = soc[i-1] - r * dt
        if soc[i] < 0:
            soc[i] = 0.0

    return soc

# 使用上一节估计出的参数
beta = beta_hat * 60  # 转换回每小时的系数
df['soc'] = simulate_battery(df, beta)

# 画图看效果
plt.figure(figsize=(12, 4))
plt.plot(df['time_min'] / 60, df['soc'], linewidth=1.5)
plt.xlabel('Time (hour)')
plt.ylabel('State of Charge (%)')
plt.title('Battery SOC Simulation')
plt.grid(alpha=0.3)
plt.tight_layout()
plt.savefig('soc_curve.png', dpi=150)

这个函数的风格很适合美赛：结构清晰、逻辑简单、容易修改。你换一组行为数据，只需要调整df，不需要重写递推逻辑。把它封装成函数还有一个好处，后面做灵敏度分析或蒙特卡洛模拟时可以直接调用。

4.2 用户行为随机化：从固定场景到蒙特卡洛模拟

固定的一条行为时间线只能算“算例”，不能代表真实情况。要回答“哪种充电策略最优”或者“怎样的使用习惯延长续航”这类问题，需要对用户行为做随机化，跑大量模拟。

随机化不是简单地从均匀分布里抽样，而是要有一定的马尔可夫性。比如现在待机，下一分钟打开亮屏浏览的概率低；现在游戏，下一分钟切回待机的概率也低。你可以定义状态转移矩阵，模拟出一天的行为序列。

python复制def generate_random_schedule(seed=0, minutes=24*60):
    rng = np.random.default_rng(seed)
    behaviors = np.zeros(minutes, dtype=int)
    current = 0

    # 状态转移矩阵：behavior[i] -> behavior[i+1]的概率
    trans = np.array([
        [0.95, 0.03, 0.01, 0.005, 0.005],
        [0.10, 0.70, 0.10, 0.05, 0.05],
        [0.05, 0.10, 0.75, 0.08, 0.02],
        [0.02, 0.03, 0.05, 0.88, 0.02],
        [0.05, 0.10, 0.05, 0.02, 0.78],
    ])
    # 注意：转移矩阵按行之和应为1

    for i in range(minutes):
        behaviors[i] = current
        current = rng.choice(5, p=trans[current])
    return behaviors

# 生成随机日程，运行模拟
df_random = df.copy()
df_random['behavior'] = generate_random_schedule(seed=1)
# 根据行为重新生成亮度和通信字段（简化处理）
df_random['brightness'] = np.where(df_random['behavior'] == 0, 0,
                         np.where(df_random['behavior'] == 1, 60,
                         np.where(df_random['behavior'] == 2, 80, 90)))
df_random['comm'] = (df_random['behavior'] == 4).astype(int)

soc_random = simulate_battery(df_random, beta)
print(f"随机日程下，24小时后期剩余电量: {soc_random[-1]:.2f}%")

蒙特卡洛模拟的核心价值在于：它让你能回答“如果用户行为服从某个统计分布，电池能撑多久”这类带概率的问题。你跑500次随机日程，就可以画出续航时间的直方图、计算平均续航和95%置信区间。这个结果拿去回答“续航焦虑”相关的开放性问题，比单纯一句“重度使用比轻度使用耗电快”有力得多。

4.3 屏幕亮度模型的细化：并不是简单的线性关系

实际上，屏幕亮度对耗电的影响不是完全线性的。不少资料显示，OLED屏幕在低亮度区间耗电曲线比较平缓，高亮度区间功耗迅速上升，可以近似为一个分段线性或二次函数：

[
r_{screen}(B) = a_1 B + a_2 B^2
]

其中 (B \in [0,1]) 是归一化亮度。你可以把平方项加入设计矩阵 (X) 重新做回归。下面的代码演示如何扩展设计矩阵：

python复制B = df['brightness'] / 100.0
X2 = np.column_stack([
    np.ones(n),
    B,
    B**2,
    (df['behavior'] > 0).astype(float),
    df['comm'].astype(float)
])

true_beta2 = np.array([0.8, 0.6, 0.9, 5.0, 3.0])
delta_S_true2 = (X2 @ true_beta2) / 60.0 + np.random.normal(0, 0.05, n)
beta_hat2, *_ = lstsq(X2, delta_S_true2, rcond=None)
print("Estimated beta with quadratic term:", beta_hat2 * 60)

如果在你的数据或者题目背景下，平方项的系数显著不等于0，那说明非线性效应不可忽略。这个步骤本身就是一个很有价值的“模型改进”，写进论文里能体现你对问题理解的深度。

4.4 自适应参数更新：用滑动窗口追踪老化电池

电池会老化，同一部手机用了一年之后，满电续航会明显缩短。这意味着模型里的参数并不是固定常数，而是随着时间和充放电循环次数缓慢变化。一个实用的做法是用滑动窗口法在线更新参数：每积累30分钟的新数据，就重新估计一次 (r_{base}) 或容量衰减系数，让模型始终贴近当前电池状态。

滑动窗口的Python思路很简单：把数据按时间滑窗截取，在每个窗口内跑最小二乘，然后取最新估计值作为当前参数。这样做的好处是模型能自适应环境温度、电池老化、系统更新带来的变化；坏处是如果窗口太短，参数估计方差会变大。建议窗口至少要覆盖2~3次完整的“亮屏-待机”循环，这样估计出的基础耗电和应用耗电才可靠。

5. 灵敏度分析与场景应用：让模型回答“怎么办”

5.1 哪些参数对续航时间影响最大

模型搭好之后，不能只用来画一条曲线就结束了。美赛论文的一个关键评分点是：你有没有分析模型对参数变化的响应？这道题里最重要的是回答“什么因素最耗电”，本质上就是一个灵敏度分析问题。

方法上，常见的是控制变量法：固定其他参数在基准值，让目标参数在合理范围内变化，观察“到达20%电量所需时间”的变化幅度。这个指标比“24小时剩余电量”更直观，也更贴近用户“电池还能撑多久”的关切。

python复制def time_to_20(soc, dt_min=1):
    target = 20.0
    for i, s in enumerate(soc):
        if s <= target:
            return i * dt_min / 60.0
    return None

# 对屏幕亮度系数做灵敏度分析
base_beta = beta.copy()
screen_coef = np.linspace(0.5, 2.0, 10)
tt20 = []
for a in screen_coef:
    b = base_beta.copy()
    b[1] = a
    soc = simulate_battery(df_random, b)
    tt20.append(time_to_20(soc))

plt.figure(figsize=(8, 4))
plt.plot(screen_coef, tt20, marker='o')
plt.xlabel('Screen power coefficient')
plt.ylabel('Time to 20% (hours)')
plt.grid(alpha=0.3)
plt.tight_layout()
plt.savefig('sensitivity_screen.png', dpi=150)

除了屏幕亮度，你还可以分析通信耗电系数、应用负载系数、基础待机耗电。最后用一个表格汇总各参数变化20%时续航时间变化的百分比，就能非常直观地回答“哪个因素最值得优化”。

5.2 典型场景对比：视频、游戏、导航哪个最费电

用同一个模型，定义三组典型场景，对比它们的电量曲线：

导航之所以最费电，因为屏幕常亮、亮度高、GPS模块和4G通信同时工作。模型会自动量化这种差异。你可以为每种场景单独跑一次模拟，画出叠加的SOC曲线，这样论文里就有了一张“三场景对比”的图。

实际模拟时，可以先从基础待机曲线出发，把某个时间段的behavior替换成目标场景，然后调用已有的simulate_battery函数。这样得到的各个场景曲线是在同一条基准线上做局部修改，对比时更公平。

5.3 充电策略优化：什么时候充、充到多少

这道题如果还要进一步深挖，可以加一个充电策略优化模块。设手机在电量降到20%时开始充电，充电速率为 (r_{charge})（比如40%/小时），充到80%停止，问一天下来总共有多少时间处于“低电量焦虑区”（低于20%）。

这个目标函数可以用分段函数来表达，然后用简单的枚举算法找最优阈值。如果你想写得高端一点，可以引入一个“电池健康度惩罚”：频繁充到100%会加速电池老化，所以目标函数里加一项与充放电循环次数相关的惩罚项。这个扩展能显著提升论文的深度，因为它从“预测耗电”进入“决策优化”，而这正是美赛评委喜闻乐见的数学模型应用。

python复制def objective(threshold_low, threshold_high):
    """
    给定充电起止阈值，模拟一天总低电量时间
    """
    # 这里简化：用固定行为序列，充电速率40%/h
    soc = simulate_battery(df_random, beta)
    charging = False
    low_time = 0
    charge_rate = 40.0 / 60  # %/min

    for i in range(1, len(df_random)):
        if not charging and soc[i-1] <= threshold_low:
            charging = True
        elif charging and soc[i-1] >= threshold_high:
            charging = False

        if charging:
            soc[i] = min(soc[i-1] + charge_rate, 100)
        else:
            # 重新计算自然耗电
            # 简化：直接用之前模拟soc递推（此处为避免复杂，不做循环内改曲线）
            pass

    return low_time

需要提醒的是，如果要在充电情况下重新模拟，不能直接复用simulate_battery，因为电量的递推路径改变了。推荐把充电逻辑和放电逻辑写在一个循环内，虽然代码长一点，但逻辑更清晰，不容易出错。我在比赛里吃过“改一个参数结果整个曲线崩掉”的亏，原因就是没有把两种模式的递推统一在一个函数里。

6. 常见问题与排查技巧：比赛现场踩坑实录

6.1 模拟曲线在某个时刻突然归零，但实际不可能那么快

这种问题最常见的原因是：行为序列里出现了长时间的高耗电状态，而初始电量设得太低。排查思路是检查每一分钟的瞬时耗电速率 (r_i)，看看是否超出合理范围。比如游戏状态加上4G通讯、满亮度，瞬时耗电可能达到30%/小时，如果持续三个小时，那确实会从100%直接掉到10%以下。这时候需要检查时间段的分配是否合理，而不是程序有bug。

另外，如果递推循环里用 dt 不一致（比如前一行时间间隔1分钟，后一行突然变成10分钟），曲线会变得不连续。我建议在数据处理阶段统一重采样到固定步长，或者显式检查 dt 的取值列表。

6.2 最小二乘估计出来的参数是负值，明显不符合物理意义

出现负参数，通常是设计矩阵存在多重共线性，或者数据噪声太大。比如“应用耗电”和“屏幕亮度”天然强相关：亮屏的时候几乎必然有应用在前台运行，所以设计矩阵里这两列容易高度相关。解决办法是：要么合并这两项，要么先固定其中一个参数再拟合另一个。

也可以尝试给最小二乘加约束，比如用scipy的optimize.lsq_linear，把每个参数限制在非负区间。这个技巧很实用，我强烈建议参赛队掌握，因为很多物理参数天然非负，非负约束能大幅提升结果的解释性。

6.3 电量数据不够平滑，耗电速率出现明显抖动

真实采集的电量百分比是整数，每分钟下降0.5%到1%的话，量化误差非常严重。初学者经常会画出阶梯状的电量曲线，然后激进地认为模型不稳定。建议做两步处理：第一，加大采样间隔到5~10分钟；第二，用滑动平均做平滑。做灵敏度分析和参数估计时，用平滑后的数据，模型会稳定很多。

如果你是用仿真数据，可以在生成数据时加入少量高斯噪声来模拟真实测量误差，这样后面在论文里讨论鲁棒性时更有底气。

6.4 论文里的图表看不清、字体太小、坐标轴缺单位

这是比赛中最冤的扣分项。很多队伍模型做得很好，但图一缩小就糊了，坐标轴没标单位，图例和图题对不上。我的建议是：所有输出图片统一用 dpi=150 或更高，字体大小至少10号，每条曲线加粗到1.5以上，颜色用色盲友好的调色板（比如从matplotlib的tab10或Set2选）。提交论文之前，把每张图在PDF里放大200%检查一遍，确保每个数字都看得清。

6.5 时间不够用：建模和写作节奏怎么分配

最后聊一点比赛节奏。四天时间，我比较推荐的分配方式是：

美赛论文的摘要特别重要。评委通常先看摘要，如果摘要没抓住重点，正文写得再好都可能被压分。摘要里必须包含：你做了什么模型、关键参数是多少、得到了什么结论、模型有什么创新点。尽量把摘要控制在一页以内，用最精确的句子描述每部分的核心成果。

7. 从一次参赛经历谈几点个人体会

这个题目做完，我对“建模”这件事有了更深的理解。很多人以为建模是编程或者数学的事情，其实它首先是“把现实问题翻译成数学问题”的能力。手机电池消耗看起来是一个很生活化的话题，但背后涉及连续系统、随机过程、参数估计、优化决策，几乎把美赛A题要考的东西都串起来了。

我在做屏幕亮度非线性扩展时花了不少时间，开始的线性模型效果也够用，但就是因为想看看亮度项会不会有二次效应，才多跑了一组实验。比赛结束后复盘，那段非线性分析反而成了论文里最有亮点的部分之一。所以我的建议是：在时间允许的情况下，不要只停留在“模型能用”，多追问一句“模型哪里还能改进”，往往会有意外收获。

最后再分享一个小技巧：无论代码写到多晚，记得在每次修改前备份一份能跑通的版本。美赛现场我曾经因为一次重构代码把基准结果弄丢了，浪费了整个上午去恢复数据。后来我养成了习惯，每完成一个功能就把脚本复制一份带时间戳的副本。这个习惯虽然不起眼，但关键时刻能救你一命。