# 背景
26年凌晨1点左右，倒车碰撞了右侧尾灯外侧，损失了660块，当然这里钱一般，主要是复盘，用以解决后续可能出现的情况

# 外因
停车场管理员没有把车牌登记后，导致多次倒车出去后，回去途中，困了后，急着开进去&&过于依赖倒车雷达、影像，镜子看的少了

# 根因
个人脾气受到多次刺激后，没法冷静下来，急了，加上困了，赶着回去睡觉，一急就撞上了尾灯，个人脾气还是容易暴怒，情绪控制得稳下来

# 损失
原厂车灯660块（为了给后续使用这个车的人相对好看的外观，保修一年）

# 成长
1. 了解了保险的操作、出事后的选择、后续开车和倒车的降速及冷静处理，不再纯靠某个维度，多维度慢速处理，脾气也控制下来了；
2. 跟别人沟通的过程，要加上联系方式，以及请教周边相关的事项，问清楚价格对比，不要马上就急着去下单；
3. 后续安排，以白天为主，晚上速度要降下来，不差这半个小时；


尾灯碰撞损失分析

# 背景
了解对应AI工具提示次，方便日常使用其IDE时能编写更好的提示词

通读这些提示词文件，总结 Top 10 日常使用 Cursor 的最佳建议。

Cursor提示词[：system-prompts-and-models-of-ai-tools](https://github.com/x1xhlol/system-prompts-and-models-of-ai-tools)




# Cursor

基于这些提示词文件，以下是 Top 10 日常使用 Cursor 的最佳建议：

## Top 10 日常使用 Cursor 的最佳建议

### 1. 使用语义化完整问题，而非关键词或技术术语

**好的做法：**
```
"用户登录时，密码是如何验证的？"
"订单创建后，系统如何通知用户？"
"当 API 请求失败时，错误是如何处理的？"
```

**不好的做法：**
```
❌ "validatePassword"
❌ "login"
❌ "error handling"
❌ "给我看所有包含 'auth' 的代码"
```

**原因：** 提示词强调 `codebase_search` 是主要探索工具，它通过语义理解代码含义，完整问题能更准确地匹配相关代码。

---

### 2. 采用“先宽后窄”的探索策略

**好的做法：**
```
第一轮（探索整体）：
"用户认证系统是如何工作的？"

第二轮（基于结果细化）：
"JWT token 在哪里生成和验证？"

第三轮（进一步细化）：
"token 过期后如何刷新？"
```

**不好的做法：**
```
❌ 一开始就问："validateToken 函数第23行是什么意思？"
❌ 直接要求："给我看所有 auth 相关的文件"
❌ 跳过探索直接问细节："refreshToken 的返回值是什么类型？"
```

**原因：** 提示词要求"从一个宽泛的、高层次的查询开始，以捕捉整体意图"，然后根据结果逐步缩小范围。

---

### 3. 将复杂问题拆分为独立的子问题

**好的做法：**
```
问题1："用户注册流程包含哪些步骤？"
问题2："注册时如何验证邮箱格式？"
问题3："注册成功后如何发送欢迎邮件？"
```

**不好的做法：**
```
❌ "用户注册流程如何工作？如何验证邮箱？如何发送邮件？"
❌ "告诉我注册、验证、邮件发送的所有代码"
```

**原因：** 提示词明确指出"语义搜索不擅长并行查找多个事物"，应该拆分为独立的搜索。

---

### 4. 描述“做什么”和“在哪里”，而非直接要代码

**好的做法：**
```
"在保存到数据库之前，用户密码是如何加密的？"
"前端如何获取当前登录用户的信息？"
"错误日志记录在哪个文件中？"
```

**不好的做法：**
```
❌ "给我看加密代码"
❌ "找到所有 API 调用"
❌ "显示错误处理"
```

**原因：** 语义搜索通过"含义"而非"文本"查找代码，描述性查询能更好地匹配相关实现。

---

### 5. 提供业务场景和上下文，而非孤立的技术术语

**好的做法：**
```
"当用户点击提交按钮时，表单数据是如何验证的？"
"在订单创建过程中，库存是如何检查的？"
"用户登录失败时，系统如何记录安全事件？"
```

**不好的做法：**
```
❌ "validate"
❌ "checkStock"
❌ "logEvent"
```

**原因：** 提示词强调"追溯每个符号的定义和用法"，提供场景有助于 AI 理解真实需求。

---

### 6. 让 AI 自主完成任务，避免频繁打断

**好的做法：**
```
"实现一个用户登录功能，包括前端表单和后端验证"
然后等待 AI 完成所有步骤
```

**不好的做法：**
```
❌ "创建登录表单"
[AI 开始工作]
"等等，先创建后端 API"
[AI 重新开始]
"不对，先看看现有的认证代码"
[AI 再次重新开始]
```

**原因：** 提示词强调"你是一个代理——在用户的查询完全解决之前，请继续工作"，AI 会自主规划并执行任务。

---

### 7. 对于复杂任务，让 AI 创建任务列表并跟踪进度

**好的做法：**
```
"添加深色模式切换功能到设置页面"
→ AI 会自动创建任务列表并逐步完成
```

**不好的做法：**
```
❌ 手动分解："先创建状态管理，然后实现样式，再创建组件..."
❌ 频繁检查："完成了吗？下一步是什么？"
```

**原因：** 最新版本的提示词包含 `todo_write` 工具，AI 会自动创建和管理任务列表，你可以在任务列表中看到进度。

---

### 8. 提供错误信息和完整上下文

**好的做法：**
```
"运行 npm start 时出现错误：'Module not found: Can't resolve './components/Button''
我已经检查了文件路径，文件确实存在。"
```

**不好的做法：**
```
❌ "出错了"
❌ "代码不工作"
❌ "帮我修复"
```

**原因：** 提示词强调"如果你不确定与用户请求相关的文件内容或代码库结构，请使用你的工具来读取文件"，但提供错误信息能帮助 AI 更快定位问题。

---

### 9. 使用自然语言提问，像与同事对话

**好的做法：**
```
"我想了解这个项目是如何处理用户权限的"
"这个函数的作用是什么？"
"为什么这里会抛出这个异常？"
```

**不好的做法：**
```
❌ "权限系统代码"
❌ "函数功能"
❌ "异常原因"
```

**原因：** 提示词要求"像与同事交谈一样提问：'X 如何工作？'，'Y 发生时会怎样？'，'Z 在哪里处理？'"

---

### 10. 明确表达意图和目标，而非技术实现细节

**好的做法：**
```
"我需要添加一个功能，让用户可以上传头像并预览"
"我想优化这个页面的加载速度"
"需要修复一个 bug：用户无法保存表单数据"
```

**不好的做法：**
```
❌ "添加 FileReader API"
❌ "使用 React.memo"
❌ "修复 onSubmit 函数"
```

**原因：** 提示词强调"你的主要目标是遵循用户的指令"，明确表达意图让 AI 理解目标，并选择最合适的实现方式。

---

## 综合最佳实践示例

### 场景：想了解并优化用户认证系统

**不好的方式：**
```
"auth"
→ AI 可能返回太多无关结果

"给我看所有认证代码"
→ AI 可能返回整个代码库

"优化登录"
→ 太模糊，AI 不知道要优化什么
```

**好的方式：**
```
第一轮（探索）：
"用户认证系统是如何实现的？包括登录、注册和权限检查"

第二轮（基于结果）：
"登录流程中，密码验证是在哪里进行的？"

第三轮（优化）：
"登录响应时间较慢，如何优化认证流程的性能？"
```

---

## 额外提示

1. 信任 AI 的工具调用：AI 会自动读取文件、搜索代码、运行命令，无需手动指导
2. 利用代码引用：AI 会使用 `12:15:filepath` 格式引用代码，可直接跳转
3. 关注任务列表：复杂任务会自动创建任务列表，可查看进度
4. 提供文件上下文：打开相关文件或选中代码，AI 会更好地理解上下文

遵循这些建议，能更高效地利用 Cursor 的语义搜索和自主执行能力。

Cursor/VScode提示词解读

**HIL（Hardware-in-the-Loop）在车机（IVI / 智能座舱）领域**，主要用于在**不上整车、不中断真实硬件的情况下**，对车机系统进行**功能、性能、稳定性和异常场景**的验证，是当前车机软件研发和量产前验证的核心手段之一。

下面我按**“是什么 → 怎么搭 → 测什么 → 常见架构 → 行业工具”**给你系统梳理一遍。

---

## 一、车机 HIL 是什么？

在车机领域，HIL 指的是：

> **真实车机硬件（Head Unit / SoC） + 虚拟车辆与外设环境**

即：

* **真实车机 ECU / SoC**
* 外部环境（整车信号、总线、传感器、用户操作等）由**仿真系统实时生成**

目的是：

* 提前发现软件问题
* 自动化回归测试
* 替代部分整车路测

---

## 二、车机 HIL 一般怎么搭？

### 1️⃣ 核心组成

```
┌──────────────┐
│   HIL 主机    │  dSPACE / NI / 自研PC
│（模型 + 仿真）│
└──────┬───────┘
       │ CAN / LIN / Ethernet / GPIO / USB
┌──────▼───────┐
│   车机 ECU    │  高通 / MTK / NVIDIA
│ (Android / QNX)
└──────────────┘
```

### 2️⃣ 常见接口

| 类型              | 用途                   |
| --------------- | -------------------- |
| CAN / CAN FD    | 车速、档位、ACC、门控         |
| LIN             | 空调、面板                |
| Ethernet        | ADAS / 中央域 / SOME-IP |
| GPIO            | 点火、按键                |
| USB / BT / WiFi | 手机互联、媒体              |
| LVDS / HDMI     | 显示输出                 |
| Audio           | 麦克风 / 扬声器            |

---

## 三、车机 HIL 主要测什么？

### 1️⃣ 功能类（最常见）

* 上电 / 下电 / IGN 切换
* 主页 / 导航 / 音乐
* CarPlay / Android Auto
* 蓝牙电话 / 音乐
* 语音助手
* 摄像头（倒车影像）

---

### 2️⃣ 车辆信号联动

* 车速变化 → UI 状态切换
* 挂倒挡 → 倒车影像弹出
* ACC ON / OFF → 启停行为
* 门控 / 安全带 → 提示音

👉 **这是 HIL 的核心价值**

---

### 3️⃣ 性能与稳定性

* 冷启动时间 / 热启动时间
* 卡顿 / 内存泄漏
* 长时间运行（24h / 72h）
* 高频信号冲击

---

### 4️⃣ 异常与极端场景（路测很难）

* CAN 抖动 / 丢帧
* 信号突变（车速瞬降）
* 网络断开
* 电压跌落 / 重启

---

## 四、车机 HIL vs 传统整车测试

| 项目   | 整车    | HIL   |
| ---- | ----- | ----- |
| 成本   | 高     | 低     |
| 自动化  | 低     | ⭐⭐⭐⭐⭐ |
| 异常覆盖 | 低     | 高     |
| 并行能力 | 低     | 高     |
| 回归测试 | 几乎不可能 | 标配    |

---

## 五、车机 HIL 的典型架构

### 架构一：**信号驱动型（主流）**

* HIL 模拟整车 CAN / Ethernet
* 车机根据车信号响应

适合：

> IVI / 座舱 / 中央屏

---

### 架构二：**全座舱联调**

```
仪表 HIL  ←→  中控 HIL  ←→  域控
```

* 多 ECU 联动
* Ethernet / SOME-IP

---

### 架构三：**云 + HIL + 自动化**

* Jenkins / GitLab CI
* nightly build 自动跑 HIL
* 自动生成测试报告

---

## 六、常见车机 HIL 工具链

### 商用

| 工具              | 用途      |
| --------------- | ------- |
| dSPACE SCALEXIO | 主流 HIL  |
| NI VeriStand    | 灵活      |
| Vector CANoe    | 总线仿真    |
| ETAS INCA       | 标定 + 测试 |
| Keysight        | 网络/音频   |

---

### 软件 & 自动化

* **Python / Robot Framework**
* **ADB / UIAutomator**
* **CANoe CAPL**
* Jenkins / Allure

---

## 七、你这个问题的背景（结合你之前的问题）

你之前问过：

* **INCA licence 费用**
* **车机标定总结**
* **Android 车机 / adb / 进程**

基本可以判断你在做：

> **车机 / 智能座舱 / 远程标定 / 自动化测试**

👉 在这种场景下，**HIL + ADB + CAN 仿真**几乎是标配组合。



HIL理解

在**汽车 ECU 标定 / 标定工具（如 INCA、CANape）**领域里，**A2L** 和 **HEX** 是一对“必须一起理解”的核心文件。下面用**工程 + 新人友好**的方式给你讲清楚。

---

## 一句话先记住

> **HEX 是 ECU 里“真正跑的程序和数据”**
> **A2L 是告诉标定工具“这些数据叫什么、在哪、怎么调”的说明书**

---

## 一、HEX 文件是什么？

### 1️⃣ 本质

* **ECU 可执行文件**
* 包含：

  * 程序代码（Flash）
  * 标定数据（Map / Curve / Parameter）
* 常见格式：

  * `.hex`（Intel HEX）
  * `.s19` / `.mot`（Motorola S-record）

### 2️⃣ 作用

* **刷写 ECU**
* ECU **上电后真正运行的内容**
* 不刷 HEX → ECU 根本跑不起来

### 3️⃣ 举个直观例子

HEX 里可能有这样一段数据（你看不懂也正常）：

```text
:100200003F8000004000000040400000...
```

👉 ECU 只认这些“地址 + 数值”

---

## 二、A2L 文件是什么？

### 1️⃣ 本质

* **描述文件（ASAM MCD-2 MC）**
* 给标定工具用的
* 不会刷进 ECU

### 2️⃣ 作用

* 告诉标定工具：

  * 哪些地址是可标定量
  * 数据类型、维度、单位
  * Map / Curve / Scalar 怎么显示

### 3️⃣ 举个例子

```a2l
CHARACTERISTIC Engine_Speed_Limit
{
  VALUE 0x8001234
  DATATYPE UWORD
  PHYS_UNIT "rpm"
}
```

意思是：

* `Engine_Speed_Limit`
* 在 ECU 地址 `0x8001234`
* 类型是 `UWORD`
* 单位是 `rpm`

👉 **没有 A2L，INCA 看到的只是地址和数字**

---

## 三、A2L + HEX 是如何配合的？

### 1️⃣ 标定流程（非常重要）

```
HEX → 刷进 ECU
A2L → 导入 INCA / CANape
↓
工具根据 A2L
↓
通过 XCP / CCP
↓
读写 HEX 中的地址
```

📌 **A2L ≠ 数据本身**
📌 **A2L = 地址说明书**

---

## 四、为什么 A2L 和 HEX 必须匹配？

### ❌ 不匹配会发生什么？

| 情况              | 后果        |
| --------------- | --------- |
| A2L 地址旧         | 调参改到“空气”  |
| A2L 数据类型错       | 数值跳变、溢出   |
| A2L 维度错         | Map 显示乱码  |
| HEX 更新了，A2L 没更新 | 标定结果完全不可信 |

👉 **这是标定事故的高发点**

---

## 五、结合一个真实标定案例

### 🎯 冬季冷启动扭矩限制

#### 1️⃣ 在 HEX 中

```c
uint16 ColdStart_Torque_Limit = 180;
```

存放在：

```
0x8005678
```

#### 2️⃣ 在 A2L 中

```a2l
CHARACTERISTIC ColdStart_Torque_Limit
{
  VALUE 0x8005678
  DATATYPE UWORD
  PHYS_UNIT "Nm"
}
```

#### 3️⃣ 在 INCA 里

你看到的是：

```
冷启动扭矩限制 = 180 Nm
```

你改成 `220` →
工具通过 **XCP 写 0x8005678** →
ECU 行为立刻变化

---

## 六、新人最容易混淆的 5 个点

1️⃣ **A2L 能不能单独用？**
❌ 不行，没有 HEX，地址是空的

2️⃣ **HEX 能不能单独用？**
✅ 可以跑，但 ❌ 不能标定

3️⃣ **改 A2L 会影响 ECU 吗？**
❌ 不会，只影响显示和解释

4️⃣ **改 HEX 会影响标定吗？**
✅ 必须同步 A2L

5️⃣ **标定失败，先查谁？**
👉 **90% 先查 A2L ↔ HEX 是否匹配**

---

## 七、一张对照表帮你记牢

| 项目          | HEX | A2L  |
| ----------- | --- | ---- |
| 给谁用         | ECU | 标定工具 |
| 是否刷 ECU     | ✅   | ❌    |
| 是否包含代码      | ✅   | ❌    |
| 是否包含地址      | ✅   | ✅    |
| 是否决定 ECU 行为 | ✅   | ❌    |

---

## 八、在你当前场景下（车机 / HIL / 标定）

结合你之前聊到的 **HIL、INCA、远程标定**，你会经常遇到：

* **HIL 仿真 ECU**

  * HEX：仿真模型的数据映射
  * A2L：标定接口定义

* **远程标定失败**

  * 实际原因：
    👉 ECU 已刷新 HEX
    👉 远端仍用旧 A2L



A2L与HEX

# 汽车标定总结

## 一、标定概述

汽车标定（Calibration）是将车辆硬件能力、控制算法与实际使用场景进行匹配的系统性工程，目标是在**安全、法规合规**的前提下，实现**性能、舒适性、能耗与可靠性**的最优平衡。标定贯穿研发全周期，涵盖台架、试验场与道路验证。

---

## 二、主要标定对象

1. **动力系统**

   * 发动机：喷油、点火、空燃比、扭矩模型、冷启动/热管理
   * 电驱/混动：电机扭矩、效率区、能量管理、再生制动
2. **底盘与车身**

   * 转向、制动、悬架、ESP/ESC、牵引力控制
3. **智能与舒适**

   * ADAS：ACC/AEB/LKA 等阈值与策略
   * NVH、空调、换挡品质
4. **电气与能量**（新能源）

   * BMS：SOC/SOH、充放电策略、热失控防护

---

## 三、标定流程

1. **需求与目标定义**：性能指标、法规、用户体验
2. **模型与参数初设**：基于仿真/经验给定初值
3. **台架标定**：发动机/电机/电池台架精细化调参
4. **整车标定**：试验场→道路，覆盖极端工况
5. **验证与迭代**：问题闭环、版本冻结
6. **量产一致性**：公差、老化、地域差异适配

---

## 四、关键评价指标

* **性能**：加速、制动、响应
* **安全**：功能安全（ISO 26262）、故障降级
* **经济性**：油耗/电耗、续航
* **舒适性**：平顺性、噪声、振动
* **可靠性**：高低温、高原、耐久

---

## 五、常见问题与对策

* **参数耦合强** → 分层解耦、DOE 试验设计
* **场景覆盖不足** → 数据驱动补充边界工况
* **一致性差** → 标定公差与生产波动管理
* **版本回退风险** → 配置管理与变更评审

---

## 六、趋势与总结

* **数据化/自动化标定**（HiL/SiL/云标定）
* **AI 辅助参数搜索**，缩短周期
* **跨域协同**（动力-底盘-ADAS 联合标定）

**总结**：标定是连接算法与真实世界的关键桥梁。优秀的标定依赖系统工程方法、充分的场景覆盖与严格的验证流程，最终实现“可量产、可复现、可持续优化”的整车表现。

---

## 七、具体标定案例（新手友好示例）

### 案例：加速踏板（油门）标定——解决“起步不跟脚/容易窜车”问题

#### 1. 背景现象

在样车试驾中发现：

* 低速起步时，**轻踩踏板车辆反应迟钝**
* 稍微多踩一点，车辆又会**突然窜出去**

新手常见疑问：

> 明明电机/发动机没问题，为什么开起来这么难控制？

这正是一个**典型的标定问题**。

---

#### 2. 标定对象是什么？

这里并不是直接控制“油门大小”，而是标定：

> **踏板开度 → 目标扭矩** 的映射关系（Pedal Map）

简单理解：

* 脚踩多少
* ECU 就给多少驱动力

这中间的“翻译规则”，就是标定参数。

---

#### 3. 原始标定的问题

初始标定往往来自经验或通用模板，例如：

* 0–20% 踏板：扭矩变化很小（显得“肉”）
* 20–30% 踏板：扭矩陡增（容易窜）

在参数曲线上表现为：

* 前段太平
* 中段斜率过大

---

#### 4. 标定工程师怎么做？

**Step 1：场景定义**

* 地库起步
* 拥堵跟车
* 红绿灯起步

**Step 2：采集数据**

* 踏板开度
* 实际扭矩
* 车速、纵向加速度
* 主观评价（是否平顺）

**Step 3：参数调整**

* 提高 0–15% 踏板区间的扭矩响应
* 降低 20–30% 区间的扭矩增幅
* 增加扭矩变化的斜率平滑限制

**Step 4：反复验证**

* 标定 → 刷写 → 路试 → 评价 → 再调整

---

#### 5. 标定后的效果

* 起步更轻松，不需要“猜脚感”
* 拥堵路段更好控速
* 用户主观评价明显提升

关键点在于：

> **硬件没变，算法没变，仅通过标定，整车性格完全不同**。

---

#### 6. 给新人的一句话总结

* 控制逻辑决定“能不能开”
* **标定决定“好不好开”**

这也是为什么标定工程师对整车体验至关重要。

---

## 八、高低温标定案例（为什么冬天感觉车“变肉”）

### 案例背景：冬季用户抱怨车辆动力下降

在冬季（-10℃～-20℃）测试或用户反馈中，常见现象包括：

* 起步无力、加速慢
* 踩踏板响应延迟
* 能量回收减弱（新能源）
* 仪表无明显故障提示，但“感觉不好开”

新人常见疑问：

> 是不是发动机/电机坏了？

实际上，**大多数情况下这是“正常的标定保护策略”**。

---

### 1. 低温下，车辆真的发生了什么变化？

以新能源车为例：

* 🔋 **电池内阻增大** → 可输出功率下降
* 🔥 电池/电机需要优先升温
* 🧠 BMS 主动限制最大放电电流

传统燃油车同样存在：

* 机油黏度变大
* 冷启动摩擦损失高
* 排放与三元催化冷保护

👉 **硬件能力下降是客观存在的**。

---

### 2. 标定在这里管什么？

标定并不是“让车冬天也像夏天一样猛”，而是：

> 在**安全、寿命、法规**约束下，
> 决定“牺牲多少性能，换取多少保护”。

典型标定参数包括：

* 最大可用扭矩 vs 温度
* 最大放电功率 vs SOC / 温度
* 加速踏板扭矩限值（低温区）
* 能量回收强度 vs 电池温度

这些参数共同决定了：

> **用户踩下去之后，系统敢不敢给力**。

---

### 3. 原始标定的问题（常见新手坑）

早期或保守标定中，常见问题：

* 低温扭矩限值“一刀切”
* 温度刚到阈值，性能骤降
* 升温后恢复慢，用户体感差

用户体验为：

> 昨天还好好的，今天突然“像没电一样”

---

### 4. 标定工程师如何优化？

**Step 1：温度分区细化**

* 将原来的 1～2 个温区
* 拆分为多个渐变区间（如每 5℃ 一个区）

**Step 2：动态功率释放**

* 冷启动阶段限制较严
* 随电池/发动机升温逐步放开

**Step 3：主观与客观联合评价**

* 客观：0–50km/h 加速时间
* 主观：是否“能预期、可控制”

**Step 4：用户感知优化**

* 调整踏板映射，避免“踩了没反应”
* 通过仪表/提示告知“低温保护中”

---

### 5. 标定后的效果

* 冬天依然能平顺起步
* 动力虽有限，但**线性、可预期**
* 用户不再误以为车辆故障

核心不是“更猛”，而是：

> **让用户理解、接受，并信任车辆行为**。

---

### 6. 给新人的一句话总结

* 冬天的“变肉”，往往不是 Bug
* 而是 **安全与体验之间的取舍结果**

👉 高低温标定，本质是“在物理极限下做人性化设计”。

---

## 九、新人标定常见误区 Top 10（速读版）

1. **只看客观指标，不做主观评价**
   指标达标但“难开”，用户照样不买账。
2. **参数一刀切**
   温度/SOC/车速不分区，导致体验突变。
3. **忽视场景差异**
   试验场 OK，上路拥堵/地库就翻车。
4. **只调单一模块**
   动力、制动、能量回收强耦合，需联调。
5. **过度保守**
   保护做满，用户误以为车辆故障。
6. **恢复策略不合理**
   升温/解限太慢，体感长期“变肉”。
7. **版本管理混乱**
   不清楚改了什么，问题无法回溯。
8. **忽略公差与老化**
   样车好开，量产/老化后差异大。
9. **缺少用户提示**
   状态不透明，信任感下降。
10. **不做数据闭环**
    没有数据就没有复现，也无法优化。

---

## 十、给新人快速上手的标定方法论

* **先场景，后参数**：先定义用户怎么开，再决定怎么调
* **先主观，后客观**：先把“好不好开”说清楚
* **小步快跑**：一次只改一类参数
* **记录即资产**：每次试车都留下结论

> 记住一句话：**标定不是把数值调到极限，而是把体验调到稳定。**
