1. 自我介绍2. 如果让你设计一个面向跨境售后纠纷的智能工单中台，整体架构怎么落可以把系统拆成接入层、规则与路由层、会话编排层、模型服务层、工单状态层、证据存储层和审计回放层。接入层处理 IM、邮件、表单和外部 API；规则层做租户隔离、语言识别、风险分级和触发策略；会话编排层维护案件上下文、节点执行历史和工具调用轨迹；模型服务层只负责生成和抽取，不直接持久化状态；状态层维护工单生命周期和人工接管点；证据层保存截图、订单记录、退款日志和模型引用片段；审计层负责回放每一步输入输出，便于定位误判和争议。真正难的点不在“能不能生成回复”，而在于把模型能力约束在可追踪、可回滚、可仲裁的业务流程里。3...

不是我应聘个it技术支持岗位4-6k 还学历歧视上了😭

1. 先做一下自我介绍，重点讲你做过的系统背景和你负责的核心链路2. 你在团队里主要负责哪部分，怎么证明这部分不是“打杂型开发”3. 你把整个系统架构讲一下，如果让我听完就能知道瓶颈可能在哪里4. 技术栈选型的时候你会怎么做取舍，尤其是 Redis 和消息队列为什么这么选选型不是比组件名气，而是比业务约束。Redis 适合做热点缓存、轻量状态、分布式协调和短期去重，但不适合承接强一致主数据；消息队列适合解耦、削峰和异步补偿，但不适合所有需要实时可见结果的主流程。真正的取舍点在于数据是否允许延迟、失败是否可补偿、顺序是否重要、消费是否要求可重放、以及业务能否接受最终一致。很多系统不是选错中间件，...