diff --git a/docs/自动化与资料收集规划.md b/docs/自动化与资料收集规划.md
index 660ea4a..7f4b7b1 100644
--- a/docs/自动化与资料收集规划.md
+++ b/docs/自动化与资料收集规划.md
@@ -365,6 +365,25 @@ lookup_order(order_no) -> {
 > `tests/test_automation_ck_health.py`（22 条）。
 > 端到端已用 3 个真实账号验证：巡检结果与直接检测逐条一致，且 `cookie` / `status` / `message` / `attempt_status` 全程未变。
 
+**生产上线记录（2026-10-02）**
+
+按三段走完，全部通过：
+
+| 段 | 动作 | 结果 |
+| --- | --- | --- |
+| ① | `AUTOMATION_ENABLED=true` + 重启 | 容器内变量生效，日志「自动化调度器已启动，tick=300s」 |
+| ② | 手动跑一轮（每轮 50 条，作业开关仍关） | `success`，50 条 / 7 秒，**斗鱼无风控反应**（无验证码、无频控、无超时） |
+| ③ | 每轮 200 条 + 打开作业开关 | 调度器自动接管：12:27:26 → 12:27:48 跑完 200 条（22 秒），`next_run_at` 按 tick 推进到 +5 分钟 |
+
+**上线过程中抓到（并已修）两个只有生产才会暴露的问题**，都已在 §C.2 记档：
+
+1. `NULLS FIRST` 在 SQLite 合法、**MySQL 报 1064** → 改用 `col IS NULL DESC`，并加了一条按 MySQL 方言 `compile()` 的回归测试；
+2. compose 的 `environment:` 是**显式列表**，只写 `.env` 不会传进容器 → `AUTOMATION_ENABLED` 起初根本没生效（顺带发现早先写入的 `ORDER_SITE_*` / `OSS_*` 也全都没传进去）。
+
+**首轮数据结论（供客服侧预期管理）**：前几轮 100% `invalid` 属正常且正是价值所在 —— 选行是「从没检测过的优先」，而积压的 1,897 条未检测记录里大部分是 **2026-08-04 一次性批量导入、`attempt_status` 为空（从未尝试登录）**、CK 已放两个月的陈旧账号。错误信息统一是斗鱼侧的「用户未登录」，不是风控。按 200 条/5 分钟，约 5.4 小时扫完全库积压后进入稳态。
+
+> **注意**：巡检会把这些陈旧账号的 `ck_check_status` 从空翻成 `invalid`，客服在「CK 检测与重登」页会突然看到大批失效账号 —— 这是预期行为，不是故障。
+
 ### 7.2 数据模型（迁移 1 个，P1a/P1b 共用）
 
 **新表 `automation_jobs`**