实习中的Redis缓存，如何估算Redis占用内存TCP三次握手四次挥手，TCP的可靠性如何保障，讲一讲超时重传、滑动窗口和拥塞控制Linux查找哪个端口占用的命令MySQL事务的四个特性SQL一条命令查找分别数学成绩高于90分和英语成绩高于90分的学生人数如何排查慢SQL，索引具体如何优化数据结构方面zset和树应用场景的不同Go语言中的并发介绍大量数据内存小的情况下判断是否存在集合内的数怎么解决谈一谈对于Agent的理解好久没面试了，还有一些缓存和数据库方面的基本八股不太记得了，感觉细节方面回答得很一般，还是太菜了要多学习

牛友们注意了，能写进简历的 AI 项目，至少得满足这三点：第一，有明确的任务场景和输入输出第二，系统可自动运行，无需人力维护第三，解决了某个实际问题很多人做了个小 AI demo，就急着在简历上写 “主导某某 Agent 系统”，结果一面聊下来，项目既不成型、跑不通，更谈不上闭环。我招人看项目经历时就遇到过这种情况：有个同学写了 “多轮对话 Agent 系统”，但被问到 “系统在哪用？触发条件是什么？对话上下文怎么保存？Agent 之间怎么分配任务？” 时完全答不上来 —— 其实这个系统就一段 prompt，用户每次都要手动输入一串命令，根本没有完整流程，更谈不上调度。反过来，另一个看起来没那么 “技术炫酷” 的项目反而更亮眼：一个 AI 写 OKR 的小工具。针对公司每季度填 OKR 的需求，这位同学写了个不到 200 行代码的小服务，只需上传本季度的工作内容，就能自动拆分为多个目标，还能输出三种版本（自我驱动、结果导向、量化可追踪），甚至支持风格转换（偏运营、偏产品、偏技术），能跑、能用、还能灵活修改。显然后者更值得写进简历。真正有价值的 AI 项目，不在于你集成了多少模型、用了多少工具，而在于你是否跑通了完整任务流程，交付了一个能解决实际问题的系统 —— 工具可以借鉴，但核心逻辑必须是自己琢磨出来的。

我是最近才开始用cursor并且使用一些国内外的编程模型，我发现不管是国内的还是国外的模型，在进行长对话之后大概率都会有幻觉情况。我现在的解决方法就是从prompt和rule上下手。将一些常用的代码规范和数据库表设计规范整合成rule，这样在编写prompt的时候可以轻松一点不同的职责需要创建不同的rule，比如最近在写毕设时就会涉及到原型设计、前端编码、后端编码以及数据库表结构的设计，这就得编写四个rule，如果写到一个rule中会使规则文本过长，对模型也是一种压力，分开设计可以让ai在扮演不同角色的时候单独使用不同的rule。在编写prompt时，主要就是以角色+需求来写，需求尽量精简即可...

不带薪我就跑路了