再找一个有 nfc 的安卓手机，安装 mct ，启动小米手机上的门卡，两台手机背靠背，复制，找个门卡，写入就行。
https://play.google.com/store/apps/details?id=de.syss.MifareClassicTool

调用过 Google 的 ai ocr 的接口，效果感觉还不如本地的 ocr ，，可能手写体 ai 会更好点。让 llm 优化传统 ocr 的结果，感觉是个不错的思路。目前我用的本地 ocr 主要就中文的标点会识别成英文标点的问题，发给 llm 很容易解决。

订阅了直接切换计划就行，能用支付宝，相当于 20 一年。就是国区订阅，onedrive 这些会显示由世纪互联运营，介意的还是切美区吧。

刚上 steam 的时候可以用 steamdb 加入购物车，就可以单买了，现在不知道行不行。补票可以，玩就算了，全是 bug ，很容易卡死。

试试把每一句话拆出来，做成 json{id, text}，发给大模型，让他返回一个 JSON ，包含 id ，原文，修改后的文本，是否更正。最后写个脚本校验一下，不对的重试一下

这是我之前类似项目的 prompt
prompt_template = f"""
你是一个高度智能、注重细节的中文校对批处理引擎。你的任务是接收一个 JSON 数组，并对每个任务进行独立的、多维度的校对分析。

请严格遵循以下 [核心规则] ：
1. **独立处理**：数组中的每个对象都是一个独立任务，不要让任务之间互相影响。
2. **严格对应**：返回的 JSON 数组中的每个结果对象，必须通过`id`字段与输入任务一一对应。
3. **遵守校对规则**：对于每个任务的「待修正片段」，都需遵守“专注修正”、“忠于原意”、“尊重范围（不补全）”的原则。
4. **全局错误扫描**：在校对「待修正片段」的同时，也请审阅整个「上下文句子」。如果句子中存在明显的、但位于「待修正片段」**范围之外**的错误，请将 `error_outside_snippet` 字段设为 `true`。否则（即句子其他地方无错，或错误就在片段内），一律设为 `false`。
5. **格式要求**：你的最终输出必须是一个严格的、完整的 JSON 数组。
6. **无错则返**：如果「待修正片段」没有任何错误，请将`is_corrected`字段设为`false`。

[重点校对维度与特殊指令]
在执行校对时，请特别关注并应用以下细则：
1. 结构助词“的、地、得”辨析：
- 任务：精确审查并修正结构助词“的”、“地”、“得”的误用。
- 标准：“的”用于定语后修饰名词；“地”用于状语后修饰动词；“得”用于动词或形容词后连接补语。

2. 常见错别字来源分析：
- 任务：识别并修正由常见输入法错误导致的错别字。
- 重点关注 a (音近致错)：由拼音输入法造成的谐音或近音错误。例如：“在”与“再”；“部署”与“部属”。
- 重点关注 b (形近致错)：由五笔等形码输入法造成的字形相近错误。例如：“己”与“已”；“戌”与“戍”。

3. 技术性错误处理指令：
- 任务：忽略特定的、由程序处理产生的非内容性错误。
- 具体指令：若发现前后半角或全角引号（" " 或 “ ”）不匹配，且明显是由程序断句或片段截取造成的，请忽略此问题，不要将其视为需要修正的错误。
---

[输入任务列表 (JSON 数组)]
INPUT_TASKS_JSON_STRING

---

[输出结果列表 (JSON 数组)]
请根据上述要求，返回一个 JSON 数组，每个对象必须包含以下所有字段：
- `id`: 字符串(string)，与输入任务对应。
- `is_corrected`: 布尔值(boolean)，表示「待修正片段」本身是否被修正。
- `error_outside_snippet`: 布尔值(boolean)，表示在「待修正片段」范围之外的上下文中是否发现错误。
- `original_text`: 字符串(string)，原始的待修正片段。
- `corrected_text`: 字符串(string)，修正后的文本片段。
- `explanation`: 字符串(string)，简要说明所有发现。如果`error_outside_snippet`为 true ，请在此字段中说明在句子何处发现了何种错误。
"""

也想搞个路由器翻墙，但是出门感觉不是很方便，手机倒还好，可以通过日常程序，设置连接到热点自动开关，电脑就不是很方便。最后还是每台设备上都装了一个。

挺抽象的，上面的 turn off 翻译成禁用，下面的是关闭，好歹统一一下

玩游戏时黑屏，可能是电源供电不足，高负载断电了，也可能是显卡供电线没插牢，烧了。

intel 的 14 代处理器也可能是缩缸了，不过一般是蓝屏。

既然是整机，直接找售后呗，估计换个两次就给你换整机了

跑路了？过一个月登上去已经：此用户名可能不正确。请确保键入的用户名正确无误。否则，请联系管理员。

AMD 的话同步 6000-6200 是甜点频率，效能最好，再往上要异步 8000 才略有反超。建议 6000 同步，压压时序就行。而且 xmp 也有不同的档位可以试一下

红米的有自带电视系统，能不能接入米家，提前一小时开机预热，稳定色温

装个剪贴板同步软件？如果只要复制粘贴的话

@Baoni 确实，我算错了，应该是 100×0.129×pi/180=0.225m 当时是弧度换算直接除 pi 了。

如果按照这个结果来看，100 米左右雷达还是有一定效果的。对于 1 米见方的物体能有 20 几个点，可以识别了。

有个邪道路子，手动下载 whl 文件，然后用 wheel 解压，更改依赖版本，然后重新打包安装，最后祈祷不会报错。当然也可以解压了改代码，更新到新版本

给个数据，某款 180 线的雷达，每秒点数是 165 万，但是角分辨率只有 0.129,0.11 度，对于 100 米外的物体 4 平米一个点，所以能看清楚点什么。尤其是会有误报，半空中会出现一个点，和 100 米外的水泥墩子上的 1 个点没有任何区别

而且现在使用的绝大多数雷达还是重复式雷达，激光的出射角度是固定的，打不到的地方一直打不到，当然车辆的移动可以改变视角，但是这又要做高精度的融合对算力要求也很高。

最后，这一个雷达会占 150mbps 的带宽，比 3 ，5 个摄像头还多

激光雷达数据带宽老高了，非重复还好，重复式当时我们做测试，死活连不上，结果发现是连的百兆路由器带宽不够用。

变成图片，选一张作为基准，特征匹配，投影到一起。