diff --git a/docs/自动化与资料收集规划.md b/docs/自动化与资料收集规划.md
index 858a48a..ba3da1a 100644
--- a/docs/自动化与资料收集规划.md
+++ b/docs/自动化与资料收集规划.md
@@ -534,9 +534,21 @@ lookup_order(order_no) -> {
 
 #### 7.4.7 上线方式（三段，同 P1a 的谨慎程度）
 
-1. **小规模实测**：挑 10~20 个 invalid（覆盖「未重试过」与「取码 bug 时代失败过」两类），
-   用现有手动重登链路跑一次 —— 把「78% 成功率」从历史推断变成实测，同时验证
-   `20261001` 的取码修复在生产真的生效；
+1. **小规模实测** ✅ **已完成（2026-10-02），结果远好于预期**：
+
+   | 项 | 结果 |
+   | --- | --- |
+   | 样本 | **20 个** invalid，两组各 10：A「还没重试过」/ B「取码 bug 时代失败过」 |
+   | 成功率 | **20 / 20 = 100%**（历史推断只有 78%） |
+   | 耗时 | 2 分 13 秒（≈ 9 个/分钟） |
+   | 极验滑块 | **0 次** |
+   | 邮箱取码 | 全部正常 → **`20261001` 的取码修复在生产验证通过**（B 组全过，证实那 144 个「验证码失败」就是旧 bug 造成的） |
+   | CK 替换 | 20 个全部换成新 CK；`ck_check_status` 由登录流程自动改回 `valid`（`login_service.py` 成功分支） |
+
+   **结论**：会话确实只是过期，重登几乎必定成功；可救量从估的 1,050 上调到
+   **≈1,350**（1,356 × 近 100%）。失败分型仍然要做，但属少数路径（极验/配额/凭证）。
+   实测 9 个/分钟且零极验，说明斗鱼当前风控容忍度比预想高，不过全量仍建议限速
+   （先按每小时 100~200 个开，观察极验率再决定是否加速）；
 2. **限量开作业**：按实测成功率定 `batch_size` 与日上限，先只跑一个分组；
 3. **全量**：观察若干轮，确认分型与退避符合预期后再放开。