Grok 密钥轮换与合规交接

项目交接时最常见的一句话是「代码都在仓库里」。但新接手的人真正需要知道的是：密钥在哪、怎么换、日志里有没有敏感内容、数据出境怎么处理、出了事找谁。这些不在代码里，也不在 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 而没有证据的清单，等于没做。

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

三件要强调的事：

• 轮换要能不停机。先发新钥、双钥并存、观察无异常后再停旧钥；只有一把钥时，「轮换」等于「停服」。
• 脱敏要覆盖推理内容。第 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. 列出你日志里最可能泄漏的三类内容，并为每一类写一条过滤规则。想一想：为什么脱敏要放在写盘前，而不是查询时？