蚂蚁大模型应用开发一面(暑期)

1. 自我介绍

2. 如果让你设计一个面向跨境售后纠纷的智能工单中台，整体架构怎么落

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

3. 单机服务迁移到集群后，订单类接口最先暴露的问题通常是什么

最先暴露的一般不是性能，而是状态一致性、幂等和时间窗口竞争。单机时很多逻辑默认依赖内存状态、线程串行或本地锁，迁到集群后会出现重复请求被多节点同时处理、缓存与数据库状态短暂不一致、消息重试导致副作用重复执行、读写分离下旧数据被读出来这些问题。所以设计集群前先要明确每个接口的幂等键、主状态来源、跨节点互斥方案和补偿机制，否则越扩容越容易把隐性 bug 放大。

4. 防重复下单为什么不能只靠数据库唯一索引

数据库唯一索引只能兜住最终写入冲突，但不能解决用户体验、并发窗口和链路副作用。比如两个重复请求都在写库前触发了库存预占、优惠券冻结、消息投递和日志埋点，即便最后只有一个订单写成功，前面的副作用也已经发生。更稳的做法是请求入口就建立业务幂等键，结合短期缓存占位、状态机约束和最终写库唯一索引形成多层防护。唯一索引是最后一道闸，不是完整方案。

5. 幂等 Token 的生成、传递和过期策略应该怎么定

幂等 Token 要满足唯一、可验证、作用域明确和可过期。通常会把用户标识、业务类型、关键参数哈希和时间片组合后签名生成，前端在提交时传回，服务端先做去重登记，再执行业务逻辑。过期时间不能拍脑袋，要根据用户操作时长、重试窗口和业务副作用风险来定，比如支付确认和普通表单提交完全不是一个量级。真正关键的是 Token 要绑定关键业务参数，否则同一个 Token 被拿去发不同请求就失去意义。

import hashlib
import time

def build_idempotent_token(user_id, biz_type, payload, ts=None):
    ts = ts or int(time.time() // 60)
    raw = f"{user_id}|{biz_type}|{payload}|{ts}"
    return hashlib.sha256(raw.encode()).hexdigest()

print(build_idempotent_token("u1001", "create_order", '{"sku":1,"cnt":2}'))

6. 为什么很多分布式 ID 方案最后还是会回到雪花算法或它的变体

因为大多数业务真正需要的是高吞吐、趋势递增、基本有序、可横向扩展且不依赖中心数据库。UUID 无中心但太长且无序，对索引和存储不友好；数据库自增简单但扩展性差，跨库后还要解决冲突和热点；号段模式能缓解一部分问题，但仍依赖中心分配。雪花算法把时间、机器标识和序列号拼起来，兼顾吞吐、可排序性和工程落地性，所以非常常见。它不是绝对最优，但在大量业务场景里是平衡后的结果。

7. 雪花算法在时钟回拨下为什么危险，工程上怎么补

雪花算法高度依赖时间戳单调递增，一旦机器时钟回拨，就可能生成重复 ID 或打破全局有序性。工程上常见补法有三种：检测回拨后拒绝服务并告警，等待时钟追平；引入逻辑时钟，用上一次成功发号时间兜底；或者在集群层做时钟隔离和节点摘除。真正稳的做法往往不是某个算法技巧，而是配合 NTP 治理、监控告警和容灾切换一起做。

8. 订单状态机设计时，为什么“中间态”往往比终态更重要

因为线上故障大多发生在中间态，而不是最终成功或最终失败。比如已创建未支付、支付中、支付回调处理中、库存锁定中、退款审核中、取消申请中，这些状态决定了系统在异常、重试和人工介入下如何继续推进。没有中间态，系统只能把复杂过程硬塞进一个接口里，出问题后既无法恢复，也无法解释。状态机设计的关键不是状态个数，而是每个状态的触发条件、可见性和可转移边界。

9. 在网络乱序、重复投递、回调延迟同时存在时，怎么保证状态不被错误覆盖

不能只靠“后来的消息覆盖前面的消息”。更稳的办法是每个状态转移都带版本号或事件序号，状态更新时校验当前状态是否允许这次转移，再结合幂等表记录事件处理结果。也就是说，系统接受的不是“谁先到谁赢”，而是“谁满足状态机约束谁生效”。如果外部回调链路不可靠，还需要把回调处理设计成可重放但不可重复生效。

allowed = {
    "CREATED": {"PAYING", "CANCELLED"},
    "PAYING": {"PAID", "PAY_FAIL", "CANCELLED"},
    "PAID": {"REFUNDING", "DONE"},
}

def can_transfer(cur, nxt):
    return nxt in allowed.get(cur, set())

print(can_transfer("PAYING", "PAID"))
print(can_transfer("PAID", "CREATED"))

10. 评论系统做分库分表时，分片键为什么经常选内容主体 ID 而不是评论 ID

评论读取通常围绕内容主体发生，比如某个视频、商品、帖子或文章下拉评论。按主体 ID 分片可以让同一个主体下的大部分评论落在同一分片，分页、排序和聚合更自然；如果按评论 ID 分片，单个主体的评论会散落到多个库表，查询和统计代价会明显上升。缺点是热点主体会更热，所以后续还要配合二级分片、冷热分层和缓存兜底。

11. 爆款内容下评论热点倾斜怎么治理

热点倾斜本质上是访问集中到少量主体，单纯扩容不一定有效。一般会同时做三层：读层用多级缓存和热点副本，把热门第一页、热门楼中楼、计数结果提前顶住；写层用异步削峰、批量聚合和局部顺序写，避免数据库被高频小写打穿；数据层对超热点主体做特殊分桶或逻辑拆分，让单个主体不至于压死单个分片。真正难的是一边保持读一致体验，一边接受最终一致的工程现实。

12. 一级评论表和二级回复表拆开设计，和统一单表设计各自的边界在哪里

拆表的好处是语义清晰，一级评论和楼中楼回复的查询路径、排序策略和数据规模通常不同，单独设计更容易优化。统一单表的好处是结构简单，扩展方便，尤其在层级不深时维护成本低。边界在于业务是否真的把两者当成两种不同对象来运营，如果一级评论要按热度分页、回复要按时间展开、审核和折叠策略还不同，那拆表通常更合理；如果只是简单树形展示，统一单表加 parent_id 往往够用。