调用者和架构师没有一条整齐的等级分界。一个人可能熟悉模型服务的 HTTP 接口却从未排查过 KV 块被提前回收也可能非常擅长内存管理却不熟悉业务的重试语义。技术成长更像是在具体边界上逐渐能做判断。我审接口时会先追三件事失败怎么表示资源由谁释放重试会不会重复产生副作用。它们比接口里用了多少抽象名词更容易暴露设计问题。接口评审围绕合同、生命周期与错误展开。资源拥有者要能被指出来以推理请求为例调用取消以后客户端连接关闭了不等于设备上的计算已经停止。正在使用的 KV 块什么时候释放结果缓冲由哪个任务持有后续异步回调会不会再触碰它们都要有答案。Rust 的引用计数章节明确区分共享所有权与单一所有权并说明Rc适用于单线程。换成跨线程任务也不是把名字改成Arc就完成了共享数据是否可变、修改如何同步、锁是否跨等待点都要继续追问。类型能表达一部分约束无法替代系统协议。“返回成功”是哪一层成功服务接收请求、模型完成前向、输出通过解码、业务收到结果是不同事件。超时发生在任一阶段调用者都需要知道是否可以重试。如果一次工具调用会写外部系统模型重试还会涉及幂等键若只是读 KV 缓存错误恢复方式又不同。2026 年 10 月 20 日 SGLang-TorchTPU 的发布说明把调度器、缓存与硬件插件的职责分开。这类结构值得学习的是责任边界不是把同样的方框复制到自己的图里。自己的系统仍要说明哪层维护请求状态哪层知道设备完成哪层负责回收。让方案接受一个小反例假设两个请求共享前缀其中一个取消。若设计无法说明共享块会不会被释放就先不要讨论容量提升。假设请求重试发生在写工具成功、回包丢失之后如果没有去重机制所谓自动恢复就可能重复执行。评审时可以用一条请求贯穿整张图不妨选一条带共享前缀的生成请求从进入队列开始追踪。它等待时持有什么资源开始执行后谁能取消设备完成时哪个任务收到通知结果发送失败后是否仍能查询状态。每走过一层都应该能指出一个具体对象或状态而不只是“由框架负责”。接着加入一个变化请求在客户端超时以后继续算完。此时系统需要决定丢弃结果、缓存结果还是提供后续查询。不同业务可以选择不同合同但都应让资源回收和幂等行为跟着合同走。没有明确选择时调用者会自行猜测重试风暴和重复写入往往就从这些猜测中出现。接口文档也可以包含一个失败时序图。它不需要罗列所有异常而要挑会改变资源归属的事件取消先于提交、取消发生在设备执行中、执行完成后回包丢失。评审者若能在图上指出每一阶段的所有者就更容易发现生命周期的空白。这种工作并不专属于某个岗位。熟悉业务的人可能最先提出重试副作用写内核的人可能最先发现设备尚未完成写 Rust 接口的人可能帮助把所有权约束编码进类型。设计质量来自这些具体信息的交汇而不是谁在图上站得最高。这些是设计情景不是本文经历过的生产事故。文章也没有宣称 AI 一定看不见这类问题。工具能帮助发现风险最终仍需要把契约写下来让测试能够拒绝不合格的实现。能提出一个会改变方案的问题往往比给自己换一个更高的岗位称呼有价值。