TL;DR
- 本文解決：寫文章引用「Spring Boot 3.2 是最新版」「Cursor 一個月 20 鎂」這類數字，發出去半年才發現過時。
- 推薦給：寫技術部落格、評測文、教學文，常常引用版本號 / 價錢 / GitHub stars 的人。
- 讀完你會知道：Step 0 查證為什麼不夠、哪 5 種數字必須當下重抓、grep 全文掃數字的技巧。
📌 目錄
🔄 Step 0 一次查完 vs Live Search 即時注入
我的 /blog-create skill 第一版規範是 Step 0 寫文章前先查證：搜索主題、確認版本、抄下來、然後開始寫。
問題：「Step 0 那一刻」跟「文章發出去那一刻」中間可能差 2-4 小時。寫長文時更慘——抄下來的「Spring Boot 3.2」可能在我寫到第 8 段時已經出 3.4 了。
| 階段 | Step 0 一次查完 | Live Search 即時注入 |
|---|---|---|
| 主題本體研究 | ✓ | ✓（沿用 Step 0） |
| 引用數字當下查 | ✗ | ✓ |
| 風險窗口 | 數小時內版本可能變動 | 趨近於 0 |
| 工作量 | 寫前 30 分鐘 | 寫前 30 分鐘 + 寫中每次數字 30 秒 |
🎯 必須當下重抓的 5 種數字
不是所有數字都要重抓。動態數字才需要：
| 類型 | 範例 | 觸發時機 | 動作 |
|---|---|---|---|
| 版本號 | Spring Boot 3.2、Node 20、Python 3.13 | 提到任何具體版本 | WebFetch 官方 release 頁 |
| 價格 | Cursor Pro $20/mo、Claude Max $200/mo | 提到任何訂閱費 | WebFetch 官網 pricing |
| Stars / Downloads | GitHub stars、npm downloads | 提到 repo 受歡迎程度 | WebFetch repo 或 npm |
| 發布日期 | 「今年 X 月推出」 | 任何時間描述 | 查實際發布日期 |
| Benchmark 數字 | 「比 GPT-4 快 30%」 | 任何效能比較 | 找原始 benchmark 來源 |
邊界情況：「相對受歡迎度」描述
「Karpathy 的 repo 一週衝到 43k stars」這種句子，寫的當下一定要重新 WebFetch。我自己踩過：草稿寫 43k，發文時已經 108k——被 Twitter 上有人指出來「你的數字過時了」，那種尷尬不想再來一次。
🔧 寫文章中如何接 Live Search
兩種模式，看你工具：
模式 A：Claude Code 邊寫邊呼叫 WebFetch
寫到具體數字的那一行，先暫停打字，呼叫 WebFetch 抓官方頁。例：
寫到：「Cursor Pro 一個月 $20」
動作：暫停 → WebFetch https://cursor.com/pricing
回來：確認還是 $20 → 繼續寫
發現變 $25 → 改數字 + 看其他段落有沒有也提到我自己用 Claude Code 寫長文時都這樣——每個數字按 Tab 暫停，30 秒查一次，然後繼續。
模式 B：寫完文章再 batch 重查
如果中斷打字節奏成本太高，至少在最終 review 階段把所有數字 grep 出來重查一次。
# 全文掃所有數字
grep -E "[0-9]+(\.[0-9]+)?(k|m|億|萬|%|美元|鎂|刀|台幣|RMB)?" article.md跑完拿到一張清單，逐個對照來源。
我兩種都用——關鍵數字（標題裡的、TL;DR 裡的）走 A，內文細節走 B。
✅ 發文前的最後一道閘：grep 全文數字
寫完文章、跑完 SEO Content Score、發 Firestore 之前，跑一個 grep 把全文數字掃出來：
# 抓所有數字 + 量詞 + 上下文 2 行
grep -nE "[0-9]+(\.[0-9]+)?(k|m|億|萬|%|美元|鎂|刀|台幣|RMB|分|秒|分鐘|小時|天|週|月|年|GB|MB|KB)?" article.md -B 1 -A 1逐個對照：
| 數字 | 在文章哪行 | 來源 | 重查時間 | 還是這個數字嗎？ |
|---|---|---|---|---|
| 108k | 第 6 行 | github.com/forrestchang/... | 寫完當下 | ✓ |
| $20/mo | 第 18 行 | cursor.com/pricing | 寫完當下 | ✗ 改 $25 |
| 30% | 第 42 行 | benchmark blog | 找不到原始 | ✗ 改成「明顯較快」或刪除 |
🐛 踩過的坑
坑 1：Step 0 抓到版本就放著用一整篇
寫一篇 Spring Boot 教學，Step 0 抓到「目前最新 3.4.5」就放著用。寫到第 6 段提到「3.4 起內建 XX 功能」，寫到第 12 段提到「升到 3.4 之後 startup 變快」——整篇都用 3.4。
發文當天早上一查，已經出到 3.5.0，Spring 釋出快得跟雲一樣。
解法： Step 0 抓到的版本號是「主題下界」，正文寫到具體版本時每次都重新查。寫完前再用 grep 掃一次。
坑 2：價錢忘記查匯率 / 區域
Cursor、Claude、ChatGPT 訂閱費台幣價錢跟美元價錢不是固定匯率換算，而且「Plus / Pro / Team / Enterprise」的對應價可能改名。
解法： 寫價錢一律抓「USD 主價」+「最後查證日期」。例：
> Cursor Pro $20/mo（USD，2026-05-05 查證）讀者自己換算當下匯率。寫死台幣價兩個月就會錯。
坑 3：GitHub stars 寫死沒帶日期
「Karpathy 的 repo 有 108k stars」——半年後這篇文還在，stars 已經 200k 了。讀者看到「108k」會覺得文章很舊。
解法： 帶查證日期：
> Karpathy andrej-karpathy-skills repo 在 2026-05-05 有 108k stars或乾脆寫成相對描述：「累積到目前已是 GitHub 上 markdown 規範類最紅的 repo」——這個一年內都不會錯。
坑 4：Benchmark 數字不查原始來源
「GPT-5 比 GPT-4 快 30%」——這種數字幾乎都是部落格傳言。原始 benchmark 通常出自 OpenAI / Anthropic / 學術論文，轉述兩三層後數字會漂移。
解法： 引用 benchmark 必須附原始來源連結。找不到原始來源就刪除這個數字，改成「明顯較快」「有感提升」這類定性描述。
📅 明天（2026-05-06）會發：抽自己的寫作指紋擋 AI 腔（Brand Voice Profile）
下一篇拆 P3，看怎麼把自己寫過的 10 篇文章抽出「個人風格指紋」，當未來文章的對照表，避免越寫越像 ChatGPT。
❓ 常見問題
每個數字都當下重查不會打斷打字節奏嗎？
會，但成本可控。我的做法：標題、TL;DR、第一段這些「核心數字」當下查（10 個之內），內文細節數字寫完後 batch grep 重查。完整篇大概多 5-10 分鐘，換掉「文章半年後過時」絕對划算。
Live Search 跟一般 fact-check 有什麼不一樣？
Fact-check 通常是發文後或 review 階段才做，Live Search 是寫的當下就驗證。差別在「錯誤是否會進入草稿」——寫進去再改成本高得多，因為周邊邏輯可能也跟著錯。
沒有 Claude Code 的人怎麼做 Live Search？
開兩個視窗：左邊寫文章，右邊瀏覽器打開官網 / GitHub repo。寫到具體數字按 Cmd+Tab 切過去查、改完切回來。土法但有效。我之前沒 Claude Code 時這樣搞過半年。
Static site 沒有真實時間怎麼辦？
寫死「YYYY-MM-DD 查證」就好。讀者知道你那天查的是準確的，半年後過時是讀者責任不是你的。比起寫一個沒日期的數字（永遠錯）好太多。
可以用 cron 定期回頭重查所有舊文嗎？
理論上可以但通常不值得。我的策略：只回頭更新流量前 5 名的文章。其他舊文的數字過時是長尾的代價，不值得花時間維護。除非該數字會誤導讀者做錯誤決策（例：價錢、安裝指令），那種要立刻補。