必须保持最新的清单
服务目录只有在反映当下现实时才有用。这一约束决定了它的设计：条目应放在代码旁边，由变更该服务的同一个 PR 更新，并被自动校验。靠季度问卷维护的目录，只是一份历史文档。
记录什么
记录服务名、负责人、接口、依赖、数据分级和运行手册。schema 要小到团队愿意填写。实践中，归属、接口和依赖三类字段贡献了大部分价值：它们回答了该找谁、怎么调用、出故障时可能影响什么。
如何保持真实
目录会因为漏更新和乐观填写而腐烂。自动校验有帮助：拒绝没有负责人的描述文件、校验链接、把声明的依赖与实际观测到的流量对比。只声明而从未观测到的依赖，应标记为未验证，而不是当作事实呈现。
故障期间的价值
服务目录真正的考验是凌晨三点的告警。值班工程师应该能在一分钟内搜到服务、看到负责人和升级路径、列出上游调用方并打开运行手册。例如，在事故指挥提问之前就能回答「哪些服务在调用 payments」的目录，把十五分钟的排查期缩短为一眼。
与 wiki 的对比
wiki 容易起步，却难以信任：页面会漂移、链接会失效，也没有查询能回答谁依赖谁。服务目录强制结构并可被校验。代价是前期的 schema 设计，收益是在时间最紧张的時刻拿到机器可读的答案。