项目交接时最常见的一句话是「代码都在仓库里」。但新接手的人真正需要知道的是：密钥在哪、怎么换、日志里有没有敏感内容、数据出境怎么处理、出了事找谁。这些不在代码里，也不在 README 里，往往只存在于上一个人的记忆里。

这一节给一份可勾选的上线清单，作为全书的收口。

一、问题不是「有没有文档」，而是「能不能换人接手」

一份合格的交接，要能被一个没参与开发的人独立执行。判断标准很朴素：把这份清单交给新人，他能不能在不问原作者的情况下完成一次密钥轮换、一次故障排查、一次合规自查。

所以清单不写「注意安全」这种话，只写可验收的动作：密钥存在哪、轮换分几步、日志里哪些字段必须没有、数据出境走哪道审批。

二、最小可运行示例：交接清单自检

下面的脚本不联网、不需要真实密钥。它用一份清单模拟交接自查，输出完成度与缺失项。

"""交接清单自检（mock）：完成度与缺失项。"""

CHECKLIST = [
    ("密钥存放在环境变量或密钥管理服务", True),
    ("旧密钥已轮换，且有双钥过渡窗口", True),
    ("日志已剔除密钥与推理内容", False),
    ("数据出境与备案事项已确认", False),
    ("错误码重试策略已写入文档", True),
]

def audit(items: list[tuple[str, bool]]) -> tuple[int, list[str]]:
    missing = [name for name, done in items if not done]
    return len(items) - len(missing), missing

def offline_check() -> None:
    done, missing = audit(CHECKLIST)
    print(f"完成 {done}/{len(CHECKLIST)}")
    print(f"缺失：{missing}")

if __name__ == "__main__":
    offline_check()

真正交接时，把 CHECKLIST 换成你的实际项，每一项都要能指出「在哪、谁负责、怎么验」。只有 True/False 而没有证据的清单，等于没做。

三、上线清单：五个必查项

项	验收标准	常见缺口
密钥管理	只存环境变量或密钥服务，仓库无明文	配置文件里留了测试 Key
轮换机制	双钥过渡，旧钥有失效时间	只能停机换钥
日志脱敏	无密钥、无推理内容、无原文	整段响应 json.dumps 落盘
数据合规	出境与备案事项已走流程	默认「应该没问题」
故障交接	重试、降级、回滚都有文档	只写了「重启试试」

三件要强调的事：

• 轮换要能不停机。先发新钥、双钥并存、观察无异常后再停旧钥；只有一把钥时，「轮换」等于「停服」。
• 脱敏要覆盖推理内容。第 3 章讲过 reasoning.encrypted_content 不能进日志；同样的原则适用于用户原文与工具参数。
• 合规只做客观提示，不下法律结论。数据出境、生成式 AI 备案等事项，请按你所在地区的规定与公司法务流程确认；本书不提供任何绕行方案，也不判断某种做法是否合法。

四、预期输出与异常分支

运行自检，预期输出：

完成 3/5
缺失：['日志已剔除密钥与推理内容', '数据出境与备案事项已确认']

换成真实交接时，若出现异常，按下面顺序处理：

现象	优先怀疑	第一步动作
新人拿不到密钥	只在个人环境里	迁到团队密钥服务
换钥必须停机	无双钥过渡	设计并存窗口
日志出现敏感内容	未做脱敏关卡	在写盘前统一过滤
合规无人负责	没指定责任人	明确到岗到人

最后一行尤其重要：合规事项最怕「大家都以为别人在管」。清单上写一个名字，比写十条原则有用。

五、判据卡

判断项	该这么做	不该这么做
密钥存放	环境变量或密钥服务	写进代码或配置文件
轮换	双钥过渡、不停机	直接替换旧钥
日志	写盘前统一脱敏	事后审计补救
合规	按地区规定与法务流程	自行判断「应该没事」
交接	每项有责任人与验收	只交一份代码

这张卡的重点是交接要可执行。五条里有三条在说：没有责任人和验收标准的清单，只是愿望。

六、来源与核验

• 官方安全 FAQ：https://docs.x.ai/developers/faq/security（核验日期 2026-11-04）。零数据留存（ZDR）、数据不用于训练、默认加密留存周期等口径以该页为准。
• 官方 Quickstart：https://docs.x.ai/developers/quickstart（核验日期 2026-11-04）。密钥从环境变量读取、base_url 指向 api.x.ai 的写法来自该页。
• 官方 Voice 概览：https://docs.x.ai/developers/model-capabilities/audio/voice（核验日期 2026-11-04）。语音场景的 ZDR 与合规能力说明来自该页。
• 数据出境、生成式 AI 备案等事项，请按你所在地区的规定与公司法务流程确认；本节只做客观提示，不构成法律意见，也不提供任何绕行方案。

七、动手试

1. 把你的项目按本节五列做一次自查：每项写出「证据在哪」，写不出来的标为未完成。
2. 设计一次不停机轮换：写出新钥下发、双钥并存、旧钥停用的三个时间点与验证方式。
3. 列出你日志里最可能泄漏的三类内容，并为每一类写一条过滤规则。想一想：为什么脱敏要放在写盘前，而不是查询时？