自我介绍
面试官你好，我叫连奕。
毕业之后我一直从事软件开发工作，到现在已经有 5 年多时间了。这几年我做过的项目类型比较多，包括电商、医疗、互联网、ERP 系统、OA 系统、SaaS 系统，还有 AI 智能体相关项目。
在公司里，我主要承担的是全栈开发的角色。前端这块，像 Vue、React 这些技术栈我都比较熟悉；后端这块，我主要是 Java 技术栈，Spring 全家桶、数据库、中间件这些用得比较多。项目类型上，0 到 1 的项目我做过，二开的项目我也做过，所以不管是新项目搭建，还是接手已有系统继续迭代，我都能比较快地上手。
另外，我在公司里也承担过组长角色。比如新人进来以后，一般是我负责带他们熟悉项目、熟悉业务和代码规范。平时项目需求下来以后，需求拆分、任务排期、项目质量把控、进度跟踪这些事情，也会由我这边参与负责。
我的大概情况就是这样。你这边如果想深入了解某个项目或者某个技术点，我可以继续展开讲。
我怎么做任务排序和项目排期
我们在项目开发中，一般是先接到甲方或者客户的需求，然后把产品、设计、测试、前后端开发、运维这些相关人员拉到一起开需求会议。第一步不是马上写代码，而是先把需求边界、交付内容、业务优先级、上线时间这些事情确认清楚。
确认完需求以后，我作为后端组长，会根据整体排期把后端任务按模块拆开。比如哪些是基础能力，哪些是核心业务，哪些是后续优化项，我会先分清楚优先级。拆完以后，再按照时间节点分配给组员。
开发过程中，我会持续跟踪每个人的进度和质量。比如这个人负责的模块有没有按时完成，接口有没有按约定输出，联调有没有风险，代码质量怎么样。如果中间发现某个同事进度比较慢，或者某个模块风险比较大，我会及时做调整，比如帮他拆小任务、调人协助，或者把优先级重新排一下。
我们排期的时候，一般也不会把时间卡得特别死，会预留一周左右的缓冲时间。因为实际项目中经常会遇到需求变更、联调问题、测试问题，甚至线上突发情况。有缓冲时间，后面项目交付就不会特别被动。整体来说，我做任务排序主要是先看业务优先级，再看技术依赖关系，最后再结合人员能力和风险点去安排。
上一个项目的整体情况和我的职责
上一个项目整体周期大概是一年。我们公司本身是外包公司，接到甲方项目以后，这个项目分了几个产品端。
最开始甲方想快速推广，所以先做了一个小程序。小程序开发周期相对快，功能也比较轻一些。前期为了早点上线，我们团队大概是 3 个后端、2 个前端，预估 3 个月左右把第一版落地。因为这个项目是电商项目，所以第一版主要是先把电商的基本流程跑通，比如商品、购物车、下单、支付、订单这些基础能力先做出来。
后面甲方用小程序推广了一段时间，发现效果还不错，就继续让我们开发 APP 端和 PC 端。到后期，因为公司同时还有其他项目，很多人员被抽到别的项目上去了，所以 PC 端和 APP 端基本上就是我一个后端，加一个前端在持续迭代。
中间大概做了两个版本，持续了六七个月左右。整个后期的功能迭代、新版本开发，后端基本上都是我一个人负责。当然前端这块我也参与了一部分，因为我本身也承担全栈开发的角色。
所以这个项目里面，我不只是写某一个模块，而是从第一版核心流程落地，到后续 APP、PC 端迭代，再到秒杀活动、AI 客服这些功能，我都有比较深的参与。
秒杀活动的业务背景
这个秒杀活动是在第一版项目落地之后做的。当时甲方想通过活动做推广和引流，所以提出要做一个秒杀专场。
因为甲方后面可能会持续做很多场秒杀活动，所以我这边不是简单写一个临时接口，而是专门设计了一套秒杀专场能力。每次秒杀活动一般只放一件商品，这件商品由甲方指定，通常会选择热销度比较高的商品。我们后台本身有商品销量统计，所以甲方会根据销量数据挑选比较能吸引流量的商品。
第一版上线运行一个月左右，注册用户量大概到了 10 万，平时活跃用户大概 5000 左右。秒杀当天我们预估并发可能达到 3 万左右，所以在设计和压测的时候，我主要按照 2 万到 3 万并发这个量级去做准备。
这里我也会区分一下，QPS 不是简单等于并发人数。并发更多是同一时间有多少用户在请求，QPS 更关注系统每秒能处理多少请求，它跟接口链路、响应时间、机器性能、数据库压力、Redis 压力都有关系。所以我在设计方案的时候，不是只看一个数字，而是会结合压测结果，看接口吞吐、响应时间、CPU、数据库和 Redis 的压力。
当时这个项目是一个 B2C 电商项目，甲方主要卖数码产品。五一那次活动印象比较深，秒杀商品是一款 iPhone，平台原价大概 6888，秒杀价大概 1299，一共放出 10 台。这个优惠力度很大，所以它的目的不是靠这 10 台手机赚钱，而是用这个活动把用户拉进来，带动平台活跃和后续转化。
秒杀整体方案我主要分成几块：第一是活动和商品数据预热；第二是入口限流和黑名单控制；第三是 Redis + Lua 脚本保证库存扣减的原子性；第四是 MQ 异步创建订单；第五是超时未支付关单和库存回滚；最后再通过数据库事务、唯一约束和对账做兜底。
秒杀商品预热和 Redis 库存设计
秒杀开始前 10 分钟，我们会做商品预热，把秒杀活动和商品信息提前加载到 Redis 里。这样做的目的很明确，就是避免秒杀开始以后，大量请求直接打到数据库，把 DB 打穿。
Redis 本身是内存存储，响应速度比较快，而且单线程执行命令，可以避免很多并发修改带来的问题，所以秒杀这种高并发场景很适合用 Redis 来承接热点数据。
预热的时候，我主要存两类数据。
第一类是秒杀活动和商品展示信息，用 Redis Hash 存。比如活动 ID、商品 ID、秒杀数量、可用库存、秒杀价格、商品名称、商品图片、开始时间、结束时间这些字段，都会放进去。页面上要展示的内容，基本都可以从这个 Hash 里取。
第二类是库存数据，单独用 String 类型存可用库存。比如 key 可以设计成 seckill:stock:{activityId}:{skuId}，value 存当前可用库存。后面 Lua 脚本扣减库存的时候，就直接操作这个库存 key。
活动信息的 key 我一般会按活动维度设计，比如 seckill:activity:{activityId}，库存 key 再按活动和商品维度拆开。这样做的好处是，活动展示信息和真正扣减的库存是分开的。展示信息读得多，但是不一定频繁改；库存是高并发扣减的核心数据，单独拆出来后，Lua 脚本操作起来也更清晰。
为什么选择开始前 10 分钟预热？因为如果预热太早，Redis 里面会长期占用比较多内存，影响其他缓存数据；如果预热太晚，请求都已经进来了，再去加载数据就来不及了。所以我们会根据活动规模和压测结果，选择在活动开始前 10 分钟左右预热，这个时间点相对比较合适。
活动结束以后，这些秒杀相关的缓存也不会一直放在 Redis 里，会根据活动结束时间做过期或者清理，避免活动结束以后还占用内存。
秒杀入口限流、页面保护和黑名单控制
秒杀当天用户量比较大，所以入口保护我做了几层。
第一层是在 Nginx 做漏桶限流，主要限制同一个独立 IP 的访问频率。当时我设置的是每秒最多 20 个请求。这个值不是随便写的，是根据压测结果定的，后面也可以根据活动情况调整。
第二层是针对当前秒杀商品做限流。比如当时五一活动里，甲方拿了一款 iPhone 做秒杀。平台原价大概是 6888，秒杀价大概是 1299，放出 10 台，优惠力度非常大，很容易吸引大量用户参与。针对这个商品，我做了商品维度的限流，大概每秒只放 500 个请求进入后端链路。
第三层是页面和接口层面的保护。秒杀开始前，页面按钮是不可点击状态，秒杀请求地址也不会提前暴露。秒杀商品详情页里，除了倒计时和剩余库存会变化，其他内容基本不变，所以我们对页面做了静态化处理，减少后端动态渲染和数据库查询压力。
这里还有一个细节，就是秒杀按钮不能只是前端置灰。前端置灰只能挡普通用户，挡不住脚本。所以后端接口里也会校验活动开始时间和活动状态。如果时间没到，就算有人提前拿到接口地址直接请求，后端也不会让它进入真正的抢购逻辑。
第四层是黑名单和异常访问控制。比如有些黄牛或者脚本会绕过页面，直接请求我们的接口。我们会统计某个 IP 在短时间内的访问次数，如果一秒内请求异常高，或者持续攻击秒杀接口，就通过 Redis 计数和 Lua 脚本，把这个 IP 临时加入黑名单，限制它继续访问。
这块一般会用 Redis 做计数，比如按照 IP 维度设置一个短时间窗口，在窗口内请求次数超过阈值，就认为它是异常访问。正常用户不可能一秒内连续打很多次秒杀接口，所以这个规则对普通用户影响不大，但对脚本和黄牛请求能起到比较明显的拦截作用。
这些入口保护做完以后，真正进入后端的请求量就已经被削掉了一大部分，后面的库存扣减和下单链路压力会小很多。
Redis + Lua 防超卖和一人一单
秒杀过程中，甲方最核心的要求有几个。
第一，不能超卖。因为这个商品本身价格非常低，如果超卖，亏损会比较明显。第二，一个用户在单次活动里只能抢一件。第三，用户体验要好，不能让用户一直等着不知道结果。第四，如果用户抢到以后 3 分钟不支付，要自动关单，把名额释放给其他用户。
防超卖这块，我主要用 Redis + Lua 脚本来做。原因有两个：一个是 Redis 是单线程执行命令，本身可以避免很多并发修改的问题；另一个是 Lua 脚本可以保证一组 Redis 命令的原子性。
也就是说，判断库存、扣减库存、判断用户是否已经抢过，这几个逻辑可以放到同一个 Lua 脚本里一次性执行。要么一起成功，要么一起失败，这样就能避免并发情况下出现库存抢占或者超卖问题。
脚本里的逻辑大概是这样的：先读取库存 key，判断库存是否大于 0。如果库存小于等于 0，就直接返回售罄。如果库存大于 0，再判断用户是否已经参与过这个活动。
用户抢购记录的 key 一般会包含活动 ID、商品 ID 和用户 ID，比如 seckill:user:{activityId}:{skuId}:{userId}。如果这个 key 已经存在，就说明这个用户已经抢过了，不允许重复抢。
如果库存充足，并且用户没有抢过，就执行库存扣减，同时写入用户抢购标记。这样既能防止超卖，也能保证一人一单。
这里顺序也比较重要。我不会先创建订单再扣库存，而是先在 Redis 里把资格和库存控制住。只有拿到资格的用户，才会进入后面的下单流程。这样后面的订单服务处理的请求量会小很多，不会让所有用户都直接打到订单库。
如果用户不具备资格，比如库存卖完了，或者用户已经抢过了，我们不会让用户一直卡在那里等结果，而是会通过 MQ 发一条结果消息，再通过 WebSocket 长连接把结果实时推给前端。这样用户能马上知道自己是没抢到、已经买过，还是库存售罄，体验会好很多。
Sentinel 限流和 MQ 异步下单
用户抢到资格以后，后端不会在秒杀接口里直接同步创建完整订单。因为如果所有逻辑都同步处理，请求链路会很长，高并发下接口响应会变慢，也容易把订单库压垮。
所以我把“抢到资格”和“创建订单”做了解耦。秒杀接口只负责校验资格、扣 Redis 库存、写用户抢购标记，然后把下单消息发送到 MQ。订单服务消费 MQ 消息，再异步创建订单。
另外，请求真正到达微服务以后，我还会在服务层做 Sentinel 限流。因为 Nginx 限流只能挡住一部分入口流量，服务本身的抗压能力也是有限的。我们当时通过单机压测观察并发请求、响应时间、CPU、QPS 稳定性这些指标，再决定 Sentinel 的限流阈值。
压测的时候，我会逐步增加并发请求，不是一下子把并发打满。主要看几个指标：接口平均响应时间、P95 或 P99 响应时间、CPU 使用率、内存、线程池情况、数据库连接池情况，还有 QPS 是否稳定。如果发现某个并发点之后响应时间明显上升，或者 CPU、连接池开始打满，那这个点就不能直接作为线上阈值，要留出安全空间。
订单号生成这块，我们会用分布式 ID 方案生成唯一订单号。为了避免 MQ 重试或者重复消息导致重复下单，数据库层面也会加唯一约束，比如活动 ID、商品 ID、用户 ID 组合唯一，作为最终兜底。
这样就算 MQ 重复投递，或者消费端发生重试，数据库唯一约束也能挡住重复订单。
MQ 这块我也会考虑消息可靠性。比如生产者发送下单消息以后，要确保消息真正投递成功；消费端创建订单的时候，要保证幂等。因为秒杀场景下，只要消息重复消费或者消费失败没有处理好，就可能出现重复下单、库存状态不一致这些问题。
库存冻结、超时关单、回滚和对账
订单创建成功以后，数据库库存这块不是简单直接扣掉总库存，而是区分可用库存和冻结库存。
用户抢到资格并创建订单以后，我们会减少可用库存，同时增加冻结库存。因为这个时候用户还没有支付，库存只是被占用了，并不代表最终成交。如果用户支付成功，再把冻结库存真正扣减掉；如果用户 3 分钟内没有支付，就通过 MQ 延迟消息触发自动关单。
关单的时候，需要把订单状态改成已取消，同时把可用库存加回来，把冻结库存减掉。Redis 里的库存也要同步回补，保证 Redis 库存和数据库库存最终一致。
这里我没有强行追求强一致性，而是根据业务场景采用最终一致性。因为秒杀场景下瞬时并发很高，如果所有链路都强同步，性能会受影响。所以我会用 MQ、事务和补偿机制来保证最终正确。
比如用户 3 分钟没有支付，延迟消息触发关单以后，先判断订单当前状态。如果订单已经支付，就不能再取消；如果订单还是待支付，才执行取消、回滚库存这些动作。这个判断很重要，因为延迟消息和支付回调可能会有时间上的交叉，必须避免已经支付的订单被误关掉。
涉及订单状态、库存表、冻结库存这些多表操作的时候，数据库层面一定要加事务。活动结束以后，我们还会做对账，比如核对订单数量、支付数量、库存扣减数量，避免出现少扣、多扣或者订单状态异常的情况。
这次秒杀活动结束以后，当天新增活跃用户大概有 5000 多，服务器没有出现明显问题，用户体验也比较稳定。整体来看，这次活动效果还是比较好的。
另外，秒杀服务这块我们是单独部署的。因为秒杀活动不是每天都有，所以没有长期购买固定服务器，而是在阿里云上给甲方配置了弹性服务器，根据活动并发情况做弹性扩容。这样既能抗住活动流量，也能控制成本。
Redis 主要解决什么问题，使用时要注意什么
Redis 在项目里主要是做缓存，用来承接热点数据和高并发请求。因为 Redis 是内存存储，读写性能比较高，所以像秒杀商品、活动库存、热门商品详情、用户抢购状态这些访问量大的数据，都可以放到 Redis 里，减少数据库压力。
但是 Redis 也不能滥用。因为它是内存存储，内存空间有限，所以不是所有数据都适合放进去。一般我会根据业务场景，只把热点数据、临时状态数据、访问频率比较高的数据放到 Redis 里，最终核心数据还是以数据库为准。
使用 Redis 的时候，我一般会重点注意几个问题。
第一个是缓存三大问题，也就是缓存穿透、缓存击穿和缓存雪崩。比如缓存穿透，可以用空值缓存或者布隆过滤器；缓存击穿，可以用互斥锁或者热点数据预热；缓存雪崩，可以通过过期时间随机化、多级缓存来降低风险。
第二个是大 key 问题。如果一个 key 里面存的数据太大，会影响 Redis 的响应时间，也可能影响主从同步和删除性能。所以设计 key 的时候，要尽量避免一个 key 承载过多数据，必要时要拆分。
第三个是持久化策略。Redis 有 RDB 和 AOF，具体怎么选要看业务场景。比如有些临时资格状态，可以通过业务补偿和数据库兜底；但如果是比较重要的数据，就要考虑 AOF 或者混合持久化，减少数据丢失风险。
第四个是架构层面。如果单机 Redis 不够，就要考虑主从、哨兵、集群这些方案。项目里我也会结合 Redis、Caffeine 本地缓存和数据库做三级缓存，让系统在性能和可用性上更稳一些。
所以我理解 Redis 的定位不是替代数据库，而是帮数据库挡住高频读请求和热点流量。真正核心的数据，最后还是要落到数据库里做兜底。
JDK 版本和为什么做 AI 智能客服
上个项目用的是 JDK 17，Spring Boot 大概是 3.3 到 3.4 这个版本。选择 JDK 17 的一个原因，是项目后面加了 AI 智能客服和智能导购模块，整体技术栈也比较新。
当时甲方提出这个需求，是因为商城每天都会有用户咨询售前、售后、退款、物流这些问题，但人工客服没办法做到 7×24 小时在线，而且专门配人也会增加成本。所以甲方问我们有没有比较好的方案，我这边就建议做一个 AI 客服，先把常见问题和部分业务查询自动化处理掉。
AI 客服的核心思路是调用大模型，让模型辅助回答用户问题。但真正落地的时候，不能只是简单调一个模型接口，还要考虑模型选型、角色设定、知识库增强、常见问题缓存、业务工具调用、敏感词过滤和人工兜底。
我当时给甲方的定位不是让 AI 完全替代人工客服，而是先把高频、标准化的问题自动处理掉。比如退款规则、物流查询入口、订单状态、售后流程、平台活动规则这些问题，用户问得非常多，如果都靠人工处理，效率低，成本也高。AI 客服先挡住这一部分问题，复杂问题再转人工，这样更符合实际业务。
AI 客服的模型选型和接入方案
Java 这边做 AI 应用，框架上当时主要看了两个方向，一个是 Spring AI Alibaba，一个是 LangChain4j。最后我选择 Spring AI Alibaba，主要是因为它和 Spring 体系结合更好，更新也比较快，并且支持 MCP、Function Calling 这类能力，后续扩展比较方便。
大模型部署上，我给甲方说了两种方案。
第一种是本地私有化部署。优点是数据和模型能力更可控，后期调用不需要按量付费；缺点是前期成本比较高，需要买 GPU 服务器，最低也要几万块钱。
第二种是直接接入第三方大模型。优点是前期投入低，接入简单，价格也比较便宜；缺点是后期调用量上来以后会按 token 收费。
甲方当时考虑项目还在发展初期，所以先选了第二种方案，用第三方模型快速把功能做起来。模型这块我们选的是阿里百炼平台里的通义千问模型，当时用的是 Qwen-Max。选择它一方面是因为我们技术框架和阿里生态结合比较多，另一方面是它支持文本、图片，也支持 MCP 等能力，价格也比较低，整体比较适合当时的业务阶段。
价格这块我也跟甲方算过账。第三方模型是按 token 计费的，前期用户量不大的时候成本很低，接入速度也快；等后面平台用户量真正上来了，再考虑是否做私有化部署。这个选择其实是一个成本和交付速度之间的取舍。
Prompt 角色设定和 RAG 知识库
调模型的第一步，是先给模型设定角色，也就是系统提示词。比如要告诉模型：你是淘店网的智能客服，主要负责处理用户关于商品、售后、退款、物流、平台规则这些问题。
系统提示词不能写得太长。因为每次用户对话都会带上这部分内容，如果提示词过长，会消耗很多 token，也会挤占模型上下文窗口。所以提示词要把角色、边界、回答风格、不能回答的内容说清楚，但不能把所有规则都堆进去。
比如提示词里我会明确告诉模型，它只能以平台客服的身份回答，回答要简洁、友好，不确定的问题不能乱编，涉及订单、物流、售后进度这类实时业务数据时，必须通过工具查询，不能凭模型自己猜。这样可以先把模型的回答边界收住。
单靠大模型直接回答是不够准确的。比如用户问“退款流程是什么”“退款要不要扣手续费”“平台售后规则是什么”，这些都是我们平台自己的规则，模型本身并不知道。如果模型硬回答，就容易出现幻觉。
所以我们引入了 RAG，也就是检索增强生成，用平台知识库来降低模型幻觉。
知识库这块，我先整理了一份平台规则文档，用 PDF 形式维护。然后通过文档加载器把文档加载进来，再用文档分割器做切分。当时我是按页切分，每一页对应一个相对完整的平台问题或规则。
切分以后，再通过向量模型把内容转成向量，存到向量数据库里。用户提问时，也会把用户问题转成向量，再和知识库里的向量做相似度匹配，找出最相关的内容，和用户问题、系统提示词一起组装后再发给大模型。
向量模型这块，我们用的是阿里平台自带的 embedding 模型，比如 text-embedding-v3 这一类模型。它的作用就是把文本转成向量，后面用户提问时，就可以用相似度去匹配知识库内容，而不是像传统数据库那样必须完全精准匹配关键词。
比如用户问“退货要不要手续费”，知识库里可能写的是“退款是否收取服务费”。这两个表达不完全一样，但语义是接近的。通过向量检索，就能把相关规则找出来，再交给大模型组织成更自然的客服回答。
这样模型回答的时候，就不是凭空回答，而是基于我们平台自己的知识库来回答，幻觉率会低很多。
当然，RAG 也不是把整篇文档全部塞给模型，而是先检索出最相关的几段内容，再和用户问题一起发给模型。这样既能减少 token 消耗，也能避免上下文太杂，影响模型回答。
MCP 工具调用、常见问题缓存和敏感词过滤
还有一些问题不是知识库能解决的，比如用户想查订单、查物流、查售后进度，这些都需要访问我们自己的业务系统。这个时候就要用 MCP 或者类似工具调用的方式。
我们可以定义一个 MCP Server，把查询订单、查询物流、查询售后进度这些业务接口封装成工具，然后挂载到 AI 应用里。当用户输入的问题触发某个工具时，模型就可以自动调用对应接口，拿到真实业务数据以后，再组织答案返回给用户。这样客服就不只是简单聊天，而是能真正参与业务流程。
比如用户问“我这个订单发货了吗”，模型自己是不知道的。它需要先识别出用户意图是查物流，然后调用我们封装好的物流查询工具，根据用户 ID 或订单号查到真实物流状态，再把结果用客服话术返回给用户。这样回答才是可信的。
工具调用这块也要注意权限和安全，不能让模型随便调用所有接口。我们只暴露客服场景需要的接口，比如订单查询、物流查询、售后查询，而且接口内部还要校验当前用户身份，保证用户只能查自己的订单，不能查别人的数据。
AI 客服落地的时候，还有两个关键点。
第一个是成本。用户量大以后，模型 token 消耗会比较明显，所以我们做了常见问题管理。常见问题和答案会单独维护在数据表里，再把问题向量化后存起来。用户提问时，先和常见问题库做相似度匹配，如果命中，就直接返回标准答案，不再调用大模型。
这样做有两个好处：一方面能降低模型调用成本，另一方面响应时间也会更短。因为很多用户问的问题其实是重复的，比如退款流程、物流查询、售后规则，这些问题没有必要每次都走大模型。
常见问题这块，其实也相当于是一个轻量级的 FAQ 缓存。高频问题先走 FAQ，相似度命中以后直接返回；FAQ 没命中，再走 RAG；RAG 还解决不了，再看是否需要 MCP 工具调用；如果工具也解决不了，最后再转人工。这样链路会更清晰，也更省成本。
第二个是安全和内容控制。比如有些用户可能会输入不文明内容，或者同行恶意攻击平台。我们接入了敏感词过滤框架，同时也在数据库里维护了自己的敏感词表。用户输入会先经过敏感词检测，如果命中，就不让它继续走模型，而是直接返回一个友好提示。
敏感词这块不能只依赖框架自带词库，因为每个平台会有自己的业务词和风险词。所以我们额外做了一个敏感词管理表，可以在后台维护平台自己的敏感词。用户输入进来以后，会先经过框架词库和我们自定义词库两层检测。
另外，AI 客服一定要有人工兜底。比如用户连续多次追问没有解决，或者问题涉及投诉、退款争议、金额异常，这种就不适合一直让 AI 处理，要及时转人工。AI 负责提升效率，但不能把风险问题都挡在机器这一层。
所以整体来说，AI 客服这块不是简单调一个模型接口，而是通过大模型、RAG 知识库、常见问题缓存、MCP 工具调用、敏感词过滤和人工兜底组合起来，让它真正能在电商业务里用起来。
离职原因
上家公司是外包公司，主要是以接项目为主。项目一般由销售团队对接客户，但是后面销售团队和老板这边因为一些原因产生了矛盾。销售团队离开以后，也带走了一部分原来维护的客户资源。
后面公司能接到的项目就相对少了，更多是一些比较小的项目。我在那边感觉成长空间和工作饱和度都不太够，所以就想出来找一个更好的发展机会。
我个人还是希望能找一个业务更稳定、技术成长空间更大的团队，能持续参与核心业务，而不是长期处在项目断断续续的状态里。
薪资期望
我上家公司薪资是 18K，目前期望薪资是 20K。
这个期望主要是结合我自己的工作年限、项目经验，以及我在上家公司承担的职责来看的。因为我不只是单纯做业务开发，也参与过项目排期、任务拆分、后端核心模块设计、秒杀这种高并发场景，还有 AI 客服这种新技术方向的落地，所以我觉得 20K 是比较合理的期望。
反问公司项目
我想了解一下，咱们公司目前主要在做什么项目？
如果贵公司现在主要做物联网这一块，那这块我之前也接触过类似项目。对物联网项目的开发流程，包括设备接入、数据采集、状态上报、接口联调，以及中间需要注意的一些稳定性问题，我这块还是比较清楚的。如果后面有机会加入，我也可以比较快地熟悉业务并参与进去。