AI 寫的內容怎麼查核？8 篇有一半細節是編的
文 / Coolkid發布：2026-05-31 · 最後更新：2026-09-08閱讀約 8 分鐘
摘要
AI 代寫的內容可以直接上線嗎？我的 8 篇 workflow 頁有一半細節是 AI 代寫時編出來的。機器人排程被寫成「每天 8am、用 GitHub Actions」，但真實是「每天 20:00、用 Claude Code 排程」。對照 8 個真實專案逐篇重寫之後，文章才有可信度。讀者驗證得了的細節，比堆漂亮術語重要得多。
#14 把 /about 改成實體資料，最後那段講「誠實比漂亮術語重要」。當時我以為那只是 about 頁的小問題。
這篇是同一件事的延伸，而且這次踩得更大、更難看。
我要把 workflow 圖書館的 8 篇填上真實內容。
打開之前 AI 幫我生成的規格一看，有一半是「看起來很專業、但跟我真實專案對不上」的東西。
我的網站在替我說我根本沒做過的事。
這件事我看了很久才敢承認。
這篇記錄我怎麼抓包自己的網站在唬爛、8 篇全部對照真實來源重寫，還有為什麼這件事是 E-E-A-T 的地基，不是潔癖。
為什麼 AI 代寫最危險的是合理的亂編？
AI 生成內容最大的陷阱，不是犯低級錯誤，是把假的編得很合理。
AI 把我的 Threads 機器人寫成「用 GitHub Actions 排程，每天早上 8 點自動發文」。這句話讀起來完全合理，技術上也成立。問題是我的機器人根本不是這樣跑的。
AI 沒有查證，只是根據常見作法猜一個機率最高的版本。
對一個沒讀過我真實程式碼的模型來說，「Threads 自動發文等於 GitHub Actions 排程」是機率最高的答案。所以 AI 就這樣寫了，寫得理直氣壯。
說穿了，AI 只是在補空白而已。
所以 AI 代寫的內容才特別危險，因為錯得不明顯。
低級錯誤你一眼看得出來，但合理的假內容會直接通過你的直覺檢查，然後上線。
怎麼抓出文章在編造？
方法很笨但有效：把 8 篇規格逐篇攤開，跟對應的真實專案程式碼核對。我看不懂程式碼，這件事不是我自己看，是用高階模型去檢查。
8 篇 workflow，逐篇打開對應的真實專案資料夾，把真實程式碼跟規格一起丟給模型，叫它一行一行比對，只列差異、不准改。
github-trending-bot、ai-news-ig-bot、TRADERREPORT、LINE 機器人，真實程式碼跟設定檔擺旁邊，看規格寫的跟實際跑的差多少。我做的是讀它列出來的差異清單，逐條決定要不要信。
對出來的落差比我想的多。每一條單看都合理，但沒有一條是真的：
| AI 編的(看起來很合理) | 真實(對照專案後) |
|---|---|
| Threads 機器人用 GitHub Actions cron 每天 8am | Claude Code 排程每天 20:00，抓 GitHub trending 挑一個 |
| IG 機器人用 Newsdata.io 抓新聞 | RSS collectors + 兩階 LLM(Haiku 評分 → Opus 寫稿) |
| 家庭 LINE 機器人接 Claude API 做對話助手 | 刻意不接 LLM，keyword + 規則解析就夠 |
如果我沒去對帳，這 8 篇會帶著一身假細節繼續掛在網站上，替我吹我沒做過的東西。
最諷刺的是，真實版本其實比 AI 編的更有料。兩階 LLM 省 token、刻意不接 LLM 的判斷，這些細節 AI 都不知道，所以只能編一個平庸但安全的版本。
為什麼差點把別人的開源成果當自己的？
重寫時我發現一個更嚴重的問題：我可能把別人開源的東西寫成自己做的。
我的素材資料夾裡，有些是我自己寫的專案，有些是我從 GitHub 裝的別人開源的 skill。AI 在生成的時候把這些混在一起，差點把別人做的東西寫成「我的 workflow」。
這是可能違法的紅線。你可以介紹別人的工具，但不能讓讀者以為那是你做的。
判斷方式很簡單，看 README 有沒有外部安裝來源、有沒有別人的署名。是別人的就明確標來源，是自己的才放進「我的 workflow」。
所以這條線我看得很緊，因為一旦破了，整個 Lab 的「第一手實作」定位就沒了。
大家要看的是「我真的做過」，而不是拿別人的當自己的。
這條線我不會模糊帶過。
真實是不是等於要攤開一切？
答案是不會。真實是流程要誠實，不代表要把私人內容全部公開。
其中一篇是「怎麼用 AI 鎖個人品牌定位」。我確實做過這件事，也有真實產出，但那份定位內容是我私人的東西。
所以我的處理方式是，workflow 只分享方法，不公開我的答案。
怎麼讓 AI 當顧問、怎麼餵背景給 AI 探討個性，這些可以講。誠實不等於暴露隱私，真實的是流程，私人的留給私人。
這跟「不能編造」是同一個原則的兩面。不編你沒做過的，也不必攤開你不想公開的。
中間的平衡線是，我寫的每一句話，讀者都驗證得了，而且我願意負責。
為什麼這是 SEO／GEO 的地基，不是潔癖？
E-E-A-T 的信任，白話講就是「讀者跟 AI 驗證得了你說的話」。
workflow 頁正是讀者驗證 Lab 真假的地方。頁面寫的工具如果跟我的 build log、跟真實專案對不上，信任直接扣分。
GEO 更是這樣。AI 在決定要不要引用一個來源的時候，越來越會交叉比對內容的一致性。
細節自相矛盾、對不上真實，就是被降低引用權重的理由。反過來說，第一手的真實細節是 AI 編不出來的，那是只有真做過的人才寫得出的護城河。
所以據實寫不是道德潔癖，是把護城河補回來。
AI 幫你寫得順，但順跟真是兩件事。順是 AI 的強項，真只能你自己保證。
真這件事沒辦法外包。
怎麼從源頭防止 AI 幫你編造？
重寫完，我把這次的教訓鎖成一條 prompt 規則。之後讓 AI 寫任何「我的專案」內容之前，先貼這一段：
# 讓 AI 寫「我的專案」內容前 先鎖死這幾條(貼在 prompt 最前面)
- 只能根據我貼的真實 source(README / code / 設定檔)寫
- source 沒寫的細節(時間 / 數字 / stack 名稱)不要猜 → 標 [待確認]
- 別人的工具 / 開源專案 明確標來源 不要寫成「我做的」
- 我的隱私(品牌定位 / 家人資料)只描述方法 不公開內容核心就一句話，讓 AI 從「猜一個最合理的版本」切換成「只寫查證過的版本」。
AI 預設會幫你補完空白，這是它的本能。你要主動把「不知道就標出來，別亂猜」寫進規則，AI 才不會用合理的假話填滿你的網站。
規則要寫死，不能靠提醒。
AI 寫作能力越強，這個問題只會越嚴重，因為它編得越來越像真的。真實是最低標，不是加分項。而這個最低標 AI 幫不了你，只能你自己去對帳。
名詞解釋
- 機器人（bot）
- 自動執行特定任務的程式，例如 LINE 機器人自動回訊息、發文機器人每天定時發貼文。
- 排程（cron）
- 讓程式「每天 8 點」「每小時」自動執行的定時器。自動發文、定期抓資料都靠它。
- E-E-A-T
- Google 評估內容可信度的四個面向：經驗（Experience）、專業（Expertise）、權威（Authoritativeness）、可信（Trustworthiness）。
- GitHub
- 放 Git 程式碼的雲端平台，也是全世界開源專案的集散地。程式碼推上去之後可以接自動部署。
- 大型語言模型（LLM, Large Language Model）
- ChatGPT、Claude 這類 AI 背後的技術：讀過海量文字後，學會理解與生成人類語言的模型。
- Threads
- Meta 旗下的文字社群平台。本站的社群引流主戰場之一，相關自動發文流程有整篇教學。
- SEO（搜尋引擎優化）
- 讓網站在 Google 搜尋結果排得更前面的一整套方法，涵蓋技術體質、內容品質、連結結構三層。
- GEO（生成式引擎優化）
- 讓 ChatGPT、Perplexity 這類 AI 在回答問題時引用你網站內容的優化方法，是 SEO 在 AI 時代的延伸戰場。
- API（應用程式介面）
- 程式跟程式之間溝通的窗口。例如你的程式透過 LINE 的 API 自動發訊息、透過 Google 的 API 讀試算表。
看完這篇之前先確認:
- 用 AI 大量生成內容的人
- 在乎 E-E-A-T / 被 AI 引用的人
- 做 build-in-public 怕內容失真的人
- 全部手寫、完全不用 AI 代筆的人
- 內容農場(要量不要真)經營者
- 純創作站不在乎事實一致性的人
如果內容對你有用就太好了
隨喜斗內
相關閱讀
這篇背後的真實開發過程記錄在 Build Log。
搜尋標籤：eeat、trustworthiness、ai-content、honesty、build-in-public、workflow。
本篇為個人學習與實驗紀錄。E-E-A-T 是 Google 品質評估概念、不是可直接操作的排名開關 本文做法不保證在你的網站產生相同結果 請依自身狀況驗證。本站不接 YMYL 高風險站、不做 PBN、不做品牌矩陣 SEO。