Perplexity CEO 宣布自研键值数据库 CobbleDB，替代 AWS DynamoDB 用于快速网页内容抓取，消息提到迁移后每年最多可节省一亿美元；该项目由两名工程师和数百个持续运行的 Computer 智能体在两个月内完成核心基础设施，官方研究称热存储批次读取延迟较 DynamoDB 全分布下降约 5 倍，P50 从 31.4ms 降至 5.60ms。这些数字很亮眼，但投基础设施岗前，更该问清自己会负责哪一部分。

“两名工程师+智能体两个月完成”对求职者意味着什么？

小团队快速交付，可能意味着岗位边界宽、责任重，而不是进去就做核心自研。面试时可以问：这个项目现在由几人维护？两名工程师之外是否有其他团队参与？智能体承担的是生成、测试还是运维？如果对方答不上来，说明分工可能还没稳定。

假设你拿到一个类似岗位的面试，可以这样问：“我入职后前三个月，是参与存储引擎开发，还是做迁移和监控？”两种回答对应完全不同的日常。前者更接近核心开发，后者更依赖内部系统。

自研替代云服务，岗位技能是偏开发还是偏运维？

替代云服务不等于从零造轮子。求职者要区分两类工作：写核心存储引擎，和做迁移、监控、运维。前者技能更可迁移，比如数据结构、分布式共识、性能调优；后者更依赖内部系统，换公司后可能用不上。

读岗位描述时，看到“负责数据库设计、开发、运维”这类笼统表述，要追问比例。可以问：团队现在自研和采购的边界在哪？哪些模块仍用云服务？维护责任归属谁？如果维护责任在个人，on-call 频率和故障处理流程也要问清。

延迟下降 5 倍这类指标，面试时怎么用来判断团队水平？

性能数字是团队成果，不是个人岗位承诺。P50 从 31.4ms 降至 5.60ms 很具体，但求职者应追问：指标由谁定义、在什么负载下测得、谁负责维护、自己入职后能否接触到同类问题。

如果面试官只说“我们延迟很低”，却说不清测试方法和维护分工，这个团队可能还在早期摸索。反过来，能讲清指标边界和故障复盘流程的团队，通常更值得考虑。

最后给一个实际可做的小建议：投递前，把上面几个问题写成三行笔记，面试时逐条问，比背八股更能判断岗位真实内容。