小红书推荐算法校招三面 ld面

说到AI相关的项目的话，我第一个反应就是小智，这个项目非常有意思，而且并不是特别难，只要大家有单片机相关的基础以及会使用AI工具，我觉得花一些时间都是可以做出来的，还是非常有趣的。

由于我的代码水平十分有限，我全让AI帮我写代码，有的时候他会写着写着改了老问题，又产生新的问题，也有可能是产生了新的问题，然后原来的老问题也没改好。这个时候你就得换个模型了，不能老用这个在上面死磕，要不然上下文记忆的多了，然后他给你乱改，最后可倒霉了。你还付出了时间，怎么搞都搞不好。再就是多加调试，多加打点，多加日志，然后给AI更多的信息去定位，然后去解决问题，再就是设计方案的话，最好不要自己拍个脑门说句话就让他实现，最好是先脑海里有一个大致的框架，然后给一个大模型，让他给你设计一个方案出来用那个orchest什么orchestra模式，或者说是那个plan模式之类的，先给你设计出来一个大纲，然后你把这个大纲发给大模型，让他修改优化，然后看看这个好不好，然后你再提意见，然后最后给一个比较好的完整的提示词文档，然后让他去实现，这样相对来说会好一些

从我自己的体验来看，嵌入式还行，真的还行。能摸到硬件，能看到代码跑在真实设备上，问题也更具体：寄存器、时序、内存、调度，出了问题就是“它不动了”，很直观。而且学着学着会发现，这条路虽然不算热闹，但也没那么卷到离谱。慢一点，但稳一点。当然，这只是我的个人感受。至少对我来说，嵌入式还挺对胃口的。

1. 基于存在高QPS的API，设计函数实现访问频率控制，具体要求为根据IP/用户ID和访问时间戳，限制两次访问间隔超过5毫秒才允许访问，可使用map记录用户上次访问时间，要求阐述具体实现逻辑2. 针对基于安全隧道的大访问量离线访问场景，设计记录访问日志的表，要求阐述表的核心字段3. 若使用Kafka传输访问日志但业务对日志要求较高，Kafka存在丢数据问题，要求阐述对应的补偿手段4. 为记录离线访问日志的表设计主键，要求阐述具体的设计方案5. 若使用MySQL存储离线访问日志表，要求阐述表中时间字段应使用的数据类型6. 不考虑数据量，若使用MySQL存储离线访问日志表，要求阐述表的索引设计方案7. 针对访问日志表，要求设计实现找出某5分钟内访问频率最高用户的功能，阐述具体实现思路8. 针对访问日志表，要求设计实现选定任意时间段后查看该时间段内访问次数TOP10的用户/应用的功能，阐述具体实现思路9. 要求阐述日常进行SQL优化的具体操作流程和检查要点10. 针对日志查询场景，日志中仅记录关联信息ID，查询/导出时需要关联出详细信息，且该查询操作频繁、数据量较大，要求阐述如何利用缓存解决该问题11. 针对读多写少的日志关联详细信息，要求阐述使用Redis构建缓存的具体实现方式12. 结合百万级客户端、高QPS的业务场景，针对日志查询的缓存击穿问题，要求阐述缓存的构建思路和解决方案13. 若为日志查询缓存设置永久有效（不设置固定过期时间），要求阐述如何判断并更新缓存数据14. 针对微服务架构下服务之间的频繁调用场景，要求阐述对应的设计思路和技术实现方案15. 针对访问日志系统，从建表、写入到查询的全流程，要求阐述各环节的设计和实现思路