pdd卡笔试中

我已经崩溃了 开发怎么这么坏

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

HR 面看起来轻松闲聊，其实每一句都在做录用判断。大多会聊离职与求职动机、稳定性、薪资期望、加班接受度、团队协作经历，也会侧面考察性格和价值观。它不考高深技术，却决定你能不能走到最后。真诚不敷衍、边界感清晰、表达得体的人更容易通过。HR 面筛的不是技术大神，而是公司愿意长期共事的靠谱队友。

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