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

今天早高峰10号线，人挤人，我好不容易站稳，余光扫到旁边座位上有个穿校服戴红领巾的小男孩，正低头盯着iPad。我以为他在看动画片，好奇瞟了一眼——好家伙，在刷leetcode。我人都傻了。我小学五年级还在玩赛尔号，人家已经在地铁上刷题了。让我想起来现在也有很多机构推出面向小孩的人工智能课、AI使用课...现在连小孩都这么卷了吗？

从三月初就开始投 一直到现在只有一个面试几乎全是已读不回꒰>﹏< ꒱沟通600+ 只投出去20多个简历

1. 你现在做的系统如果让我一句话理解，它解决的核心问题是什么2. 如果让你重新设计这套系统，你会先拆哪几个边界，而不是先画微服务图先拆交易主链路和旁路能力。主链路只保留强约束动作，比如下单、库存冻结、支付确认、履约状态推进；旁路能力像风控、推荐、画像、报表、运营分析都要尽量异步化。再往下拆数据边界，订单事实、库存事实、支付事实不能混成一张万能表。最后才是服务边界，因为很多系统不是服务没拆好，而是业务一致性边界一开始就画错了。3. 一套交易系统里，什么地方最容易被误判成“性能问题”，其实是模型设计问题最典型的是状态字段过载。很多系统把几十种业务状态塞进一个 status，然后所有查询、补偿、回...