本地商业1. 先做一下实习时候的业务介绍，有什么提升2. AI Coding 功能从能演示到能交付，中间差的到底是什么差的不是模型会不会写代码，而是系统有没有交付闭环。演示阶段只要能在几个样例上生成看起来对的 patch 就行，但生产可交付要求它能处理不完整需求、脏仓库、编译失败、依赖缺失、测试不稳定和回滚策略。真正落地时必须加任务约束、静态检查、sandbox、单测回归、补丁审计和失败分级，否则所谓“生成功能”只是把风险后移给人。AI Coding 一旦进入真实研发流，评价标准就从“会不会写”变成“出了错能不能收住”。 def deliverable_check(repo, patch): ...

比预想中晚了一周，时间过得真快啊，感觉越学越多，目前这版简历下周直接开投了，两个项目都是自己用AI敲的，欢迎各位继续拷打，也是在共同交流学习吧。目前可以说出项目架构业务，自己亮点设计的一些思考，技术实现以及技术选型原因，量化指标也准备了一套说辞，但深挖代码估计就寄了；八股过了一遍，属于基本能说点原理理解，但深挖细节估计也寄了；算法简单了解一些整体思路，但手撕估计也寄了；AI可以吹下项目相关的工程实现和一些技术选型，但深挖技术肯定就寄了。总之，基于自身学习状态考量，先投些小厂继续学吧。有道是：“人生南北多歧路，一处春山一路平。”

第一段实习死活找不到沟通 200+，只有 5 个面试

1. 自我介绍2. RocketMQ 里顺序消息、普通消息、事务消息分别适合什么场景，为什么不能混着用普通消息适合最终一致、无严格顺序约束的场景，比如日志分发、画像更新、通知投递。顺序消息适合同一业务键必须按时间线推进状态的链路，比如同一工单、同一订单、同一会话的状态演进，但顺序消息的吞吐和容错设计会受到队列粒度限制。事务消息适合本地事务与异步投递之间要建立“发送承诺”的场景，比如主库先落事实，再由 MQ 推动旁路索引或下游补偿。三者不能混着用，是因为它们解决的问题不同，消费模型、失败恢复方式和成本模型也完全不同。3. 如果 RocketMQ 出现消息积压，你会怎样定位，不要只说“扩容消费者”...