跟你这一对比，突然觉得我爸妈在这件事上面还是挺讲道理的了……
感觉该说的楼上也都说了，不要因为旁人施压所带来的一些短期的压力和情绪，影响自己的决策，特别是这种关乎人生走向的决策。虽然道理估计都懂，但执行起来其实很容易变形，特别在长期承受压力的情况下，是很容易做出一些妥协的。

听起来是业务本身带来的复杂度，但信息较少不好轻易下结论，我个人建议既然是业务问题，最好不要尝试在技术方案层面去取巧，复杂度只会转移，不会消失，取巧容易产生技术债，除非这块逻辑你们不需要长期维护。
回到你说的这个具体问题，我觉得可以看下你们系统里目前是否已经有类似于复制、导入数据的逻辑，梳理看下这些逻辑跟基于模板生成样例数据的流程，是否具有共性，能否做一层抽象，从这个角度减少维护成本。仅供参考，抽象如果做得不好同样会带来额外维护成本。

跟楼主一样，我看剧练听力的时候就是以字幕台词为单位来快进快退的

@plau313 #5 我猜你说的应该是 Call Annie 😂

我把 Win 换到 Command 的位置后，其他的键位好像基本就都没啥区别了，就是偶尔复制粘贴 ctrl/command 键会弄混，但也不碍啥事儿

就是个供需关系的问题，供大于求，用人方肯定选成本和风险更低的方案

祝好

@sisi041 #2 Vision Pro 跟 Quest3 的原理是一样的，都是通过摄像头透视

以防你是真的不知道，我提一嘴，MR 赛道目前其实还有个 Quest3 ，你要是刻意忽略的话当我没说……
其次 Apple Vision Pro 彩透的延迟据说已经降到了 12 ms ，基本上是感受不出来的。实际上 Quest3 的彩透也基本感受不到什么很明显的延迟了，记得好像是几十毫秒来着。

如果是不知道怎么生成 RSS 源，可以考虑 checkchan + rsshub
如果不知道怎么通知，可以试试 IFTTT ，或者去 GitHub 搜各种 RSS 推送工具，例如这个 https://github.com/iovxw/rssbot

项目里的内容描述太偏业务了，相对来讲容易让面试官不知道问什么，除非他刚好接触过相关业务，知道痛点、难点是啥

我的显卡是 4070 ，显存 12 GB ，用 ollama 跑 qwen 7b 和 mistral 7b 感觉都挺流畅的呀，qwen 14b 也勉强能跑，如果 ollama 默认拉取的就是已经量化了的模型，那就不清楚了

开发一个感觉也不难？实在不想开发的话，你可以试试 open-interpreter ，把需求说清楚它应该能处理。

能通读的话肯定是最好的，但通常时间上是不允许的，而且性价比可能也不高。
如果有文档（还在维护的）的话，可以先看文档。如果同事愿意的话，可以请他帮你梳理下系统的大致框架结构。
这些都没有的话，那就先理解业务，然后从两个点切入去看代码：1. 用户频繁使用的功能模块 2.BUG 比较多的功能模块。

大型项目要控制复杂度，重点还是要做好模块边界划分，不要奢望能够把所有模块的业务都理解清清楚。
做一个需求的时候，要想清楚每个模块在这个需求里承担的职责是什么，然后把职责对应的实现落实到各个模块内，这个过程有时候会需要借助各种设计模式。
提高模块的内聚性的好处在于，当你在阅读一段代码时，你只需要把当前模块的上下文装进脑子里，降低心智负担。对于模块的维护者来说，如果某个外部模块的概念和流程扩散到自己的模块内，当你维护自己模块时，还得带上它的代码，而你对它可能并不熟悉，这种时候就容易改出 BUG 。

原来还有 Livid 这个节点。。

你成功把两个负责不同职责的逻辑揉杂在了一个 for 循环里，读这段 for 循环的人得同时关注两个逻辑

M1 air 16G 后端开发还是不太够用，很吃紧