我是电车车主，提醒一下 UP 。
你估计是在试驾吧，试驾的路人少车少，智驾能发挥点作用。
高峰期，车多人多路窄的路段现阶段不要用智驾，很吓人的。

@bao3 #172 病重，看哪种病重。如果已经完全失去了活着的意义，无法康复，早点死去比赖活着更好，别拖累家里人；觉得很冷淡没人情味？这是对自己说的，不是要求长辈的。

可以看看《伪善的医疗_医疗的限度与更好的告别》。

直接海马体！

@QAZXCDSWE #18 很详细，感谢你！

@innerpeace03 清洁整理流！我买个纸巾盒

@magic3584 安全流派！灭火器和破窗器准备安排！

@wxw752 可惜我车没有 HUD ，害！

@Geekgogo 蔚来哈

@yyyle 哈哈，花里胡哨的确实会看起来很乱

@stone9527 手机支架吗？

@kkkbbb #41 是的，你是对的。这里思考得不到位，不能直接返回的，还是要遍历完所有元素。

@binxin 这个问题太简洁，其实有很多隐含的内容没展开，敏锐的面试者应该主动追问细节。
比如：
是否需要保留重复元素？（例如 [1,2,2,3] 和 [2,2,4] 的交集是 [2] 还是 [2,2]？）
元素是否有序，顺序是否需要保持？
输入规模的大小？（决定是否需要优化时间复杂度）

这样方向就不仅仅是 hash 了，能够发现这些问题的面试者在实际工作中也能更好的避坑。
当然这是我想的，不知道 op 是不是和我想的雷同。

尝试解答一下

1. 我会先问列表是否会出现重复元素

1.1 假设是不会重复
那么创建 HashMap ，分别遍历两个列表，入 map 时进行计数，最后遍历 map ，取值等于 2 的。
- 扩展，如果取多个列表的交集，则在最后遍历 map 时取值等于列表数量。
1.2 假设会重复
上述 1.1 的做法会出现错误，如[1,1,2] 和 [2,3]的结果中 1 的计数也会等于 2 ，需要改进。
- 选择其中一个列表进行去重，创建 hashset 将列表 1 装入，然后遍历列表 2 ，如果元素 hashset 中存在，
则可以装入结果集的 list 中。
1.3 重复且要取最大交集
对于列表[1,2,2,3]与[2,2,3]，如果需要将重复元素的体现出来，即结果需要是[2,2,3]，1.2 的做法则不满足该需求。
方法 1: 分别对列表 1 和列表 2 进行 hashmap 的计数，然后遍历 map1 ，如果 map2 中存在，则对 map1 和 map2 取最小值，放入结果中(放入结果时要正确写对元素及其个数)。
- 方法 1 应该可以优化省略掉一个 map ，比如在遍历列表 2 时进行一些操作，暂时没想到。

其他：
1. 元素是否有序或可否排序，如果可以排序可能有一些优化方法，如经过长时间运行发现列表大概率无交集，那么先进行排序然后取第一个元素查看是否一致，不一致则直接返回空集合；还可以结合双指针遍历优化性能。
2. 比较列表大小，一个列表远大于另一个时，优先遍历较小的列表构建 HashMap ，节省内存。

原理前面的大佬解释的很好了，下面是我从 deepseek 查到的，对普通无 AI 基础的开发更友好的解释：

用大模型结合用户文档构建问答知识库，核心原理可以用“图书馆+翻译官”的类比来理解，对普通开发者来说主要分三步：

文档预处理（类似图书编目）

把你的 PDF/Word 等文档拆成小段落（类似给每本书分章节）
用嵌入模型将文字转成向量坐标（相当于给每本书贴上精确的地理坐标）
存入向量数据库（相当于建立图书馆的索引系统）
问答过程（类似图书检索）

用户提问时，先将问题转成向量坐标
在向量数据库里找坐标最近的文档段落（类似 GPS 定位最近的图书）
只把相关段落喂给大模型（而不是整个图书馆）
答案生成（像翻译官工作）

大模型将专业文档"翻译"成人话
结合找到的段落内容生成最终回答
整个过程类似你给翻译官几页参考资料，让他帮忙解释某个问题
关于 token 消耗的关键事实：

预处理阶段（向量化）是单次成本
每次问答的 token 消耗=提问长度+检索到的文档长度+回答长度

相比直接微调大模型（需数万元成本），这种方案首次构建成本通常不超过千元，且支持动态更新文档。核心开发难点在于处理 PDF 解析和设计高效的检索策略，对熟悉 Web 开发的工程师来说，主要工作量在系统集成而非 AI 算法本身。

你可以用大量的饺子图片去训练一个专属的数饺子 AI ，准确率可以极高, 训练出来的模型也很小，普通电脑都可以跑。

@Quarter 问题是这一点儿也不智能哈哈

恭喜！

你这标题很小红书!

@alogbycat #32 香港是真好吃啊，我跟我女朋友在地铁里的一个小饭店随便吃点，人均 70 多，味道比深圳的那些茶楼好吃多了。