# 背景
底层打工人如何逆天改命？这里做一些思考，不一定能马上改变个人命运，但是起码不去想，就永远不会做到

# 思路
1. 对于一定阅历的打工人，选择大于努力，也就是说，对机会的认知，提取站位永远是一个要持续不断去thinking的过程；
2. 寻求被时代放大的位置，每一年都需求提前思考；
3. 财富跃迁，靠的是指数，即寻求股权激励；
4. 做好每周更新简历的准备；
5. 在公司就要想办法建立自己的能力库；日常化
6. 关注外企招聘要求，如英伟达，google，微软；
7. ai短视频平台，想想自己感兴趣的部分，噜噜，时光对比，建筑摄影；（抖音/视频号）——尝试了下，但是阅读量不太理想
8. 疯狂看书，深入自己专业的领域；

抉择与机遇

# 背景
获取安卓执行日志

# 操作
命令行执行：
```bash

Windows (PowerShell)：

adb logcat --pid=$(adb shell pidof com.abc.ddd) > test1202002.txt


Windows CMD：

adb logcat --pid=%(adb shell pidof com.abc.dddn)% > test.txt

```

同时观察Android Studio中的logcat日志，复制到文本中，双备份对比

安卓日志获取

# 背景
日常使用cursor时，发现有些措施可以使得代码提效的效率倍增（经实测，通常存在半个小时完成几天开发工作量情况），特此记录，方便后续持续优化



# cursor喜好
1. 对md格式相当友好
2. 对协议层、标准的代码、二进制理解友好
3. 对已经实现的部分参考实现友好（即新需求，建议先开始调研清楚后再看具体代码引入，大致要自己心里有个理解）
4. 可以让其写具体的开发文档，便于后续开发评审

# tips
1. rules
GPT增加cursor的rules配置
在项目根目录下增加.cursor/rules.md
如果是Django的，参考：
```js
# Cursor Rules - Python / Django 项目团队规范

## ✅ 基础代码规范
- 所有 Python 代码必须遵循 PEP8
- 变量、函数、方法使用 snake_case
- 类名使用 PascalCase
- 常量使用 UPPER_CASE
- 禁止无意义命名，如 a、b、tmp、test1
- 禁止提交 print 调试代码，使用 logging

## ✅ Django 项目结构规范
- apps/ 下每个模块是独立 Django APP，遵循 “单一职责”
- models 放在 models.py 或 models/ 目录
- serializers 放在 serializers.py
- views 放在 views.py 或 views/ 目录，不写业务逻辑
- 业务逻辑写在 services.py
- 工具类放在 common/utils
- 配置放在 config/，不可硬编码在业务中

## ✅ 数据库规范
- 所有模型字段必须写 verbose_name、help_text
- 必须开启 auto_now 或 auto_now_add 的时间字段
- 删除、更新尽量使用软删除
- QuerySet 操作必须捕捉异常，不能直接裸 try
- 不允许 N+1 查询，建议使用 select_related / prefetch_related

## ✅ API 接口规范（RESTful）
- 使用 DRF 编写 API
- 所有接口返回统一结构：

成功：
{
  "code": 0,
  "msg": "success",
  "data": {...}
}

失败：
{
  "code": 非0,
  "msg": "错误信息"
}

- 分页接口必须返回 total / page / page_size
- 不允许返回内部异常堆栈
- 所有接口必须有权限控制 （IsAuthenticated 或自定义权限）

## ✅ 注释规范
- 所有类、方法必须包含 docstring
- 函数必须写入参数说明、返回值说明
- 写关键业务逻辑时必须加注释
- 注释要说明 “做什么 + 为什么” 而不是“代码翻译”

## ✅ 依赖与环境规范
- 依赖固定在 requirements.txt
- 开发/生产分离：settings/dev.py、settings/prod.py
- 禁止将敏感信息（密码、密钥、URL）写死，必须使用环境变量
- migrations 必须提交

## ✅ Git 规范（遵循 Conventional Commit）
- feat: 新功能
- fix: 修 bug
- docs: 文档
- style: 格式（不影响逻辑）
- refactor: 重构（不影响功能）
- test: 测试
- chore: 构建、脚本、依赖管理

示例：
feat: add user login API
fix: fix token expire bug
refactor: move business logic to service layer

## ✅ 单元测试
- 所有 API 必须写测试
- 覆盖率不低于 70%
- 测试命名为 test_xxxx.py
- 必须断言 status_code 和返回结构

## ✅ 日志规范
- 用 logging，不用 print
- 错误级别必须包含上下文信息
- 不输出敏感数据（密码、token、手机号明文）

## ✅ 安全规范
- 表单和接口必须进行参数校验
- 禁止 SQL 拼接
- 密码必须加盐存储
- Token 必须带过期时间
- 不返回敏感数据（密码、ID卡号、密钥）

## ✅ 其他
- 遇到不确定实现方式，优先选择 Django 官方推荐实践
- 代码尽量可读、可维护、可测试，而不是“能跑就行”

```

2. 跨项目代码使用，可以直接把需要的项目放到当前项目下，然后chat中，使用@引入所需要的部分，加上描述使用，最后是有参考某某实现

```js
参考a2l文件的解析逻辑，这个页面http://localhost:8086/#/file/data/list?current=2&pageSize=20
调用解析逻辑时，参考后端Django的接口：class DataFileViewSet(ModelViewSet):
@action(detail=True, methods=['post'], url_path='parse-hex-data')
    def parse_hex_data(self, request, pk=None)
@src 
```

3. 如果是word或PDF等其他形式的文档，需要转换为md格式再使用@引入，加上描述，目的

```js
@hex_client.py 根据地址具体是怎么分析出来最终的物理值的？给出详细的分析过程
```

4. 如果直接指定模型使用，发现有时会特别轴，比如指定sonnet 4.5时（跟他说了几遍，注意事项和需求等还是会犯同样的问题），现在都是setting设置models圈定范围，默认AUTO即可

5. 如果跨不同IDE使用，即apk开发、iOS开发等，建议使用cursor描述开发，调试用对应的IDE，比如Android Studio调试

6. 多看极客时间相关课程，看看业界对这块使用的方式，对比自己的方式

7. 直接选中命令行或输出窗口中的情况（Add to chat），告知chat处理

```js
@Python (162-307) @a2l_client.py 存在很多乱码的情况，麻烦修复
```
8. 针对已经成熟模块的改动，建议分拆成一定模块来问，附带测试进行，避免引入新bug


# 为啥要优先AI编程
1. 可以基于已经存在的代码，快速实现，尤其是类似的；
2. 由于设定了rules，会默认按照最官方的方式实现，最标准，和不容易踩坑；
3. 不用完全熟悉具体底层实现，只需要知道大概需要用到什么即可，不需要自己想代码实现；
4. 联动上下游的，使用AI不容易忘记且少硬编码实现；

# 效率分析
业界某公司调研分析为：cursor 40%；copilot 35% 其他忽略不计

经内部日常使用分析，cursor起码能到80%以上的代码编写，尤其是新项目，或参考类似的、官方的实现；

1. hex解析、a2l解析，cursor实现了90%以上的代码，1个小时，顶起码一周的工作量；（分析了类似协议的实现，需要至少2周以上，但是cursor+清晰文档md化后，1个小时就可以实现绝大部分类型协议的实现，经测试无误）
2. 日常接口新增字段，抽象类型定义及工具类的实现，cursor半个小时内可以解决起码要写一个早上的代码效果工作量；

# 其他
gemini 3 Pro
目前发现丢大量的日志分析是可以完全精准分析的，这个是个不错的实测功能；

```js
根据你提供的日志，`com.xiaopeng.remotecalibration` 应用崩溃的根本原因是 **内存溢出 (Out of Memory - OOM)**，具体表现为 **Native 层（C/C++层）内存耗尽**。

以下是详细的分析：

### 1. 崩溃的核心原因
**错误类型：** `java.lang.OutOfMemoryError`
**具体错误信息：**
```
Throwing OutOfMemoryError "Could not allocate JNI Env: Failed anonymous mmap(0x0, 8192, 0x3, 0x22, -1, 0): Out of memory. See process maps in the log." (VmSize 17019908 kB)
```
**解释：**
*   应用试图创建一个新的线程（或 JNI 环境），需要申请内存映射，但系统内存已经耗尽，无法分配。
*   日志显示进程的 **VmSize（虚拟内存占用）达到了惊人的 ~17GB (17019908 kB)**，这对于一个安卓应用来说是极不正常的，说明发生了严重的内存泄漏或内存滥用。

### 2. 异常发生的迹象（崩溃前兆）

在崩溃发生前几秒，日志中已经出现了大量的内存分配失败警告：

*   **Scudo 内存分配器报警 (15:56:12):**
    `Scudo OOM: The process has exhausted 256M for size class 33296.`
    `Stats: SizeClassAllocator64: 821M mapped`
    *   这意味着 Native 层的内存分配器检测到内存正在被疯狂消耗，从 500MB 迅速飙升至 800MB+ 并持续增长。

*   **Malloc 失败刷屏 (15:56:18):**
    `libc: malloc(32768) failed: returning null pointer`
    *   系统底层 `libc` 库在尝试分配 32KB (`32768` bytes) 的内存块时连续失败。这通常是因为没有连续的内存空间可用了。

### 3. 罪魁祸首推断

根据日志上下文，问题出在 **JNI 层对 XCP 数据的处理** 上：

1.  **高频数据接收：**
    日志中充满了 `AKLib_Jni: Received buffer: ...`。这表明应用正在通过 JNI 从底层（可能是车辆总线）接收大量的高频二进制数据。

2.  **XML 写入操作：**
    在 `15:56:10.883` 附近，日志显示 `AKLib_Jni: XML数据写入100ms数据名称...`。应用似乎在尝试将大量的信号数据写入 XML 文件。

3.  **可能的泄漏点：**
    *   **缓冲区未释放：** JNI 层接收到的 `buffer` 可能没有被及时释放 (Release)，导致堆积。
    *   **XML 构建过大：** 如果是在内存中构建一个巨大的 XML 字符串/对象然后再写入文件，会瞬间消耗巨大内存。
    *   **线程池积压：** 错误堆栈显示 `ThreadPoolExecutor`。如果数据处理速度慢于接收速度，任务队列会无限膨胀，最终撑爆内存。

### 总结

*   **崩溃原因：** **Native OOM (内存溢出)**。
*   **触发点：** `AKLib_Jni` 库在处理 XCP 协议数据接收和 XML 写入时，消耗了所有的可用内存（虚拟内存飙升至 17GB）。
*   **解决建议：**
    1.  检查 `AKLib_Jni` 的 C++ 代码，确保 `malloc/new` 分配的内存在使用后被 `free/delete`。
    2.  检查 JNI 传递数据给 Java 层时，`NewByteArray` 等引用是否被及时释放。
    3.  避免在内存中构建完整的超大 XML，改用流式写入 (Stream Writer)。
    4.  限制数据接收缓冲区的大小或频率。
```

# 参考提问

```js
对比结果页，筛选增加标定量筛选，放置于标定量类型左侧
http://localhost:8086/#/calibration-data/comparison/same-project
```


```js
标定量编辑入口，开放关键标定量 备注字段，供用户编辑，其余的只读不能改
```


```js
标定管理页面，页面调整。
要求：可对标定量进行备注说明，并且进行筛选，包括是否需要进行标定等
其中， 备注取           "remark": "",
```


```js
可视化对比按钮，请基于当前标定量的current_value做曲线对比，如果是单值，则点对比，依次类比。
@same-project 
```


```js
新增了一个专门的对比接口，返回速度快、字段精简，方便前端按 data_file 等条件拉取差异列表：
GET /calibracloud/cdm/api/v1.0/hex/compare：沿用 Hex 视图集的过滤器（data_file、hex_file、a2l_file、characteristic_type、characteristic_name 等都可用），只返回 characteristic_name、characteristic_type、current_value 三个字段，VALUE 类型仍自动去掉外层列表。
实现细节：apps/cdm/rest/serializers/hex.py 新增 HexCompareSerializer 继承现有序列化逻辑；apps/cdm/rest/viewsets/hex.py 新增 compare action，复用原过滤和分页能力。
现在前端用你给的 cURL 只需把路径换成 /hex/compare?...，就会得到更小的响应体，data_file=27/28 过滤也已生效。如需比对两组数据，可分别请求两个 data_file，拿返回的 JSON 直接做对比即可。

原接口：Request URL
http://localhost:8086/calibracloud/cdm/api/v1.0/hex?user_fields=owner&a2l_file=12&page_size=10000&data_file=27
Request Method
GET
按照以上接口调整，加快访问速度

```


```js
@src 当前已经获取到characteristic hex相关的所有信息，
需要实现一个参数对比的能力，包含：
1、可从存储的软件中，提取同项目A2L，多个不同hex之间的参数对比，识别参数一致及不一致情况，并且参数具有可视性；
2、可从存储的软件中，提取不同项目A2L，多个不同hex之间的参数对比，识别参数新增、删减、同命名信号参数的一致及不一致情况，并且参数具有可视性
同时，标定量对比功能里，可以根据标定量的类型：单值、二维表、三维表等进行筛选区分，便于进行查看标定量。
可以对于标定量进行检测，对于MAP的凸点位置或者不符合趋势的标定量进行检测和提醒。
当然 1 2可以分开不同的页面，麻烦参考以上
```


```js
参考ADB官网，要求写一个培训文档，面向对象是没有这块知识经验的人，文档需要包含背景、ADB架构、通讯逻辑、流程图、ADB常见命令（root/devices/push/pull等使用），请编写
```


```js
经查，已知数据库存在MAP类似对应的X Y坐标，估计是由于原来标定量或观测量等的判重逻辑变化，导致hex解析到对应MAP无法查到对应的坐标轴值，请参考model类及入库逻辑调整MAP类型的解析逻辑
```


```js
新接口：compare_cross_a2l
路径： GET /calibracloud/cdm/api/v1.0/hex/compare_cross_a2l
查询参数：
data_file（必需）：HEX 数据文件 ID，支持多个，用逗号分隔，如 "1,2,3"
characteristic_names（可选）：要对比的标定量名称列表，用逗号分隔，如 "CtrlACC_mV_11kwTurnU_C,OtherChar"
page_size（可选）：分页大小
返回格式：
{  "count": 100,  "next": null,  "previous": null,  "results": [    {      "characteristic_name": "CtrlACC_mV_11kwTurnU_C",      "characteristic_type": "VALUE",      "long_identifier": "剩余充电时间T4计算：11kw充电拐点电压",      "hex_values": {        "1": 123.45,  // data_file_id: value        "2": 234.56      },      "a2l_info": {        "1": {"a2l_file_id": 3, "a2l_file_name": "xxx.a2l"},        "2": {"a2l_file_id": 4, "a2l_file_name": "yyy.a2l"}      },      "a2l_files": [3, 4]  // 该标定量在哪些 A2L 中存在    }  ]}
主要特性
支持跨 A2L 对比：不要求所有 data_file 关联到同一个 A2L
基于名称匹配：按标定量名称匹配，而非 ID
性能优化：指定标定量名称时只查询相关 HEX 数据
数据验证：验证 data_file 存在性和 A2L 关联性
值规范化：自动处理 VALUE 类型的列表值
分页支持：支持分页查询
使用示例
# 对比所有匹配的标定量curl 'http://localhost:8086/calibracloud/cdm/api/v1.0/hex/compare_cross_a2l?data_file=1,2'# 对比指定的标定量curl 'http://localhost:8086/calibracloud/cdm/api/v1.0/hex/compare_cross_a2l?data_file=1,2&characteristic_names=CtrlACC_mV_11kwTurnU_C,OtherChar'
函数已实现，可直接使用。
跨A2L对比时，请参考以上后端接口调整调用，请调整
```


```js
@xcp信号测试.xls @test1201_shanchuHT(1).cfg 
其中xls xlsx都支持，默认其开头行顺序及内容固定为：
名称	角色	10msRStr	100msRStr	Polling_100ms	Polling_500ms	Polling_1s
其中Excel中内容对应为：
名称	                  角色	10msRStr	100msRStr	Polling_100ms	Polling_500ms	Polling_1s
TQR_bar_BrkPresReq		       X
TQR_bar_MasterCylPres		   X
TQR_barps_BrkPresRampReq	   X
中X代表选中对应10msRStr或后续100msRStr等字段，
上面是固定格式，下面部分，前面信号为观测量，后面x表示10ms或者100ms（最后三列不用管）
要求其转换为cfg格式，参考选中的cfg文件，格式参考：
@test1201_shanchuHT(1).cfg (1-10) 
0表示10ms周期，1表示100ms周期
其中前三行+空行是固定格式，请写一个工具类来实现以上需求。
即，要求输入Excel，输出cfg文件，其中Excel支持xls xlsx
同时，
要求转换前打印信号数，并打印转换成功后的信号数，再加个判断，用来证明转换过程中没有丢失信号
要求加一个if __main__供测试，就用当前目录下的
@xcp信号测试.xls 
```

cursor提效tips

# 理解
临时把当前修改藏起来，恢复工作区干净，以便切分支或拉代码

# 深度理解
stash 会保存什么？

默认会保存：
✅ 工作区已修改但未提交的文件
✅ 暂存区里的文件（git add 过的）

不会保存：
❌ 未被 git 追踪的新文件（除非用特殊参数）

# 高频命令操作

1. 查看所有 stash 内容

```js
git stash list
```

你会看到类似：

```js
stash@{0}: WIP on develop: 1234567 修复接口
stash@{1}: WIP on master: UI调整
```


✅ 2. 恢复（取出并删除 stash）

把最新的 stash 应用到当前分支：

```js
git stash pop
```


应用并删除 stash@{0}

如果有冲突，解决后再 git add + git commit

✅ 3. 恢复但不删除 stash（保险一点）

```js
git stash apply
```
应用 stash

stash 记录仍保留（更安全）

✅ 4. 恢复指定 stash

例如恢复第 1 个：

```js
git stash apply stash@{1}
```

若要恢复并删除：

```js
git stash pop stash@{1}
```



git stash

# 背景
我从remote_calibration分支合并到develop分支时，提示： 

```js
Merge request cherry-pick failed: Can't perform this action automatically. It may have already been done, or a more recent commit may have updated some of this content. Please perform this action locally.
```
# 理解
意思是：GitLab 在尝试把 remote_calibration 分支的变更自动合并（或 cherry-pick）到 develop 分支时失败了，需要你在本地手动处理冲突。这种情况通常发生在：

✅ 同一段代码被两个分支改动了

✅ 分支之间有冲突文件

✅ 已经有人做过部分 cherry-pick/merge

✅ GitLab 无法自动确认冲突如何解决

# 解决
直接cursor处理

更新分支：

```js
git checkout develop && git pull
git checkout remote_calibration && git pull
```

本地尝试合并：

```js
git checkout develop
git merge remote_calibration
```

用 git status 查看具体冲突

打开冲突文件并手动解决

会提示是否直接界面解决，同意后，界面合并即可，然后提交

合并完成后：
基于develop创建新分支然后合并到develop即可

git add .
git commit
git push origin develop


