不知不覺鐵人賽已經倒數第二天了，在我的規劃中，其實已經沒有更多技術或工具相關的內容要分享了。前幾天女朋友在看我寫文章的時候，發現我都是用 Antigravity CLI 來一起協助完成，她對於這件事覺得蠻猛的。我才發覺：「對耶！其實跟過往的寫作模式蠻不一樣的！」所以今天我想分享這個幕後花絮。這 30 天來所看到的所有文章架構、想法、圖片，背後全部都是與 Antigravity CLI 一起完成的，尤其在「去 AI 感」這件事真的費了很多心力。

在開賽前就決定把這次主題定調在「AI Agent 與一位工程師共舞著」，因此想說不能只是單純敲鍵盤寫文章、偶爾問問 Gemini。我要光明正大地 AI Driven 日常寫作，並把這次鐵人賽當成一場實驗，透過 Antigravity CLI 的終端環境來輔助我完成這整整 30 天的挑戰。

今天這篇就單純以「幕後分享」的角度，聊聊這一個月來是怎麼組織文件、怎麼規範 AI，以及協同工作時的體會。

一、其實這整場鐵人賽...

應該很多人覺得「讓 AI 幫忙寫文章，不就是叫它生出幾千字然後複製貼上嗎？」一開始確實有想過往這個方向發展，但實際嘗試後會發現文章慘不忍睹，就跟「繃帶要 18 歲以後才能拆」的那種 AI 廢片非常像，AI 感非常嚴重，可以參考 Day15 AI 中場採訪 的內容，那還是我請 AI 稍微克制一點的版本。所以，跟 Antigravity CLI 的合作模式並不是「請幫我寫一篇 Day 07」，而是：

1. 我負責定調方向與邏輯骨架。例如：這篇核心論點是什麼、要先講什麼再講什麼、想要傳達什麼感覺、不要提到什麼等等。
2. AI 根據方向與骨架產生第一版。即便了有第一步，此時產出的文章還是非常 AI 感的。
3. 我繼續來調整實際內容。由於前面已經定調方向了，我就可以專心把整篇內容改成我的方式與理解來闡述。這個階段非常容易修改很多，甚至幾乎重寫一篇文章。
4. AI 再負責校正潤飾與事實校對。幫我跑測試、比對本機程式碼、檢查內容正確性等等。
5. 接著就是反覆討論與潤飾...。這步驟就是抓錯字、語病進行微調而已。

為了避免這個龐大的 30 天專案變成混亂的文字堆，我在檔案結構上也下了功夫。

二、文件 Pipeline：從 Raw 到 Ready

在這次 iThome 鐵人賽的專案目錄下，我們將檔案結構依據文件類型切成四個階段，我印象中是參考網路上某個神人的架構：

docs/
├── 01_raw/          # 1. 素材收集池
├── 02_wiki/         # 2. 技術知識庫
├── ithome_draft/    # 3. 30 天草稿工作區
└── ithome_ready/    # 4. 正式發布庫

這個流程是怎麼跑的呢？

• 01_raw/：
  平時把 Heimdall 的一些設計討論與決策、逆向出來的二進位 HEX、或是官方文件的筆記丟進來，隨便亂丟。這裡遵循一個原則叫 「Digest & Delete（消化即刪除）」，一旦內容被提煉完成，原始雜亂的檔案就會刪掉，不讓垃圾累積。
• 02_wiki/：
  將 Raw 目錄底下所有技術知識進行驗證，然後提煉並彙整到 Wiki 的目錄底下。這個目錄期待會是一個書庫，裏面將驗證過的技術事實（例如 KV Cache 物理原理、SQLite 表結構）寫成 Wiki 卡片，並且能編織成幾本書。這裡不談鐵人賽的文章語調，只記錄客觀的技術事實。
• ithome_draft/：
  這是鐵人賽工作區。在這裡我們討論文章的起承轉合、放截圖、推敲標題，把 Wiki 裡的硬核技術轉化成好讀好懂的文章草稿。
• ithome_ready/：
  經過多次反覆校稿、討論與潤飾後，當一篇草稿審核確認沒問題後，就會搬移到 ready/。這裡有個硬性規則是一定要 「1:1」 跟 iThome 發出的文章一模一樣，沒有任何草稿筆記，複製貼上就能直接發布。

透過這條 Pipeline，AI 就較不會迷失在幾百個檔案的混亂上下文裡，它永遠知道現在在哪個階段、該做什麼事、該去哪裡找答案。

三、AI 的邊界：AGENTS.md

在專案剛開始時，我也踩過一些坑，例如：AI 有時候會突然吐出簡體中文甚至日文、有時候會在程式碼裡寫中文註解、或者寫測試時自己把預期結果改掉來讓測試通過。為了杜絕這些問題，我們在專案根目錄建立了一份 AGENTS.md，相當於專案的「行為憲法」，裏面大致有這些內容：

1. 語言政策：
   • 在程式碼、Commit Message、終端命令與非文章文件，一律使用英文。
   • 面向讀者的技術文章（docs/ 目錄）：嚴格繁體中文，嚴禁簡體字與支語。（支語一定佔中文語料庫很大一部分比例）
2. 工程紀律：
   • 嚴禁在程式碼中出現未說明的 Magic Numbers，所有數值必須定義常數。
   • 寫單元測試時，真實業務邏輯的預期不可妥協，嚴禁為了讓測試通過而修改邏輯。

之類的。因此，每次 Antigravity CLI 啟動時，它都會先讀取這份規則，規範他的行為，雖然他還是很有可能犯錯。

這一個月來與 AI 協同開發的過程，我最大的體會是 「AI 是個非常優秀的鏡子。」 當給它的指令很模糊、自己都不知道想要什麼時，它回覆的東西就會是一堆華麗但空洞的廢話；但當想法很清晰、文章結構定義得很嚴謹、方向非常明確時，它會是非常棒的助手。但如果問題上升到「AI 在寫文章上能不能取代人類」的話，只能說就算請它參考我 Day 1 - Day 28 的文章來產生 Day 29 的文章，產出的文章還是很明顯看得出來不一樣，還是會講一些無聊空洞的形容詞。反正我是覺得我寫的更有趣耐看一點啦 XDD

（雖然不一定每個情境都需要有趣耐看，就像我也會看「18 歲以後才能拆繃帶」的 AI 幹片）

這大概就是我這 30 天專案的幕後小花絮。剩最後一篇了，明天見！