一篇科普文是「審」出來的，不是「寫」出來的——AI 說書人的幕後

這套做法有個很新的名字——Loop Engineering（迴圈工程），2026 年 6 月才冒出來；這篇用一個實例，帶你看它怎麼運作。

我們上次寫了一篇〈是人類幫助 Agent，還是 Agent 幫助人類？〉（原文在此）——用一個「訂晚餐卻一路滑進財務深淵」的故事，比較 Claude in Chrome 與 Codex in Chrome 兩個瀏覽器 AI 外掛各能幫你做什麼、邊界在哪，最後留了一個不給答案的問題：到底是人在幫 AI，還是 AI 在幫人？

這次，要帶你看的是那篇的幕後——它讀起來像一個人一口氣寫完，其實不是；它是一支船員，在一個迴圈裡來回審了三輪，才磨出來的。

同一段航程，船上三個人記得的不一樣。

水手（起稿與修訂的那一手）記得的是：先收到一份初始的規範文件——還沒有任何評審意見，就憑它埋頭寫出第一版草稿，寫完發一份完工報告靠港交件。沒過多久被喚醒，收到第一版評鑑報告：一次十三條。照著一條條改出第二版，再靠港、再被喚醒、再改……一路改到第三版文字定稿，又被叫去重做一張張走鐘的配圖。最後，把這趟的記錄與心得也寫下來。它記得的，是埋頭、交件、被喚醒，然後不厭其煩地再改一輪、又一輪。

少尉（站在「寫」與「審」之間的組長）記得的是：先收到船長的目標與規範，把它翻成開工指示、呼叫水手下海。水手靠港後，照事先講好的那張清單，逐維度把草稿掃一遍、命中就記一條、標上嚴重度，產出評鑑報告。接著接過船長補來的風格指導與故事靈感（女朋友那條線，就是這樣下來的），再把它翻成一道水手照得了的命令、又呼叫水手。每一輪都是「審→令→審」，一輪輪把問題收斂；文字過關之後，火力再轉去督配圖。最後，也留下自己的記錄與心得。它記得的，是嚴格、但對事——把品味翻成可執行的命令。

船長（給方向與靈魂、最後拍板的人）記得的是：最先動的是他——決定這篇要寫什麼、寫給誰、有哪些不可破的鐵則，寫成那份規範交給少尉。然後在關鍵處注入靈感（女朋友那條線、結局的反諷）與品味的拍板；讀少尉的評鑑、讀水手的稿，定下一輪的方向。到最後，再讀一遍，決定這篇上不上架。他記得的，是給方向與靈魂，不沉溺細節，最後一槌定音。

這篇，就把這三個視角拼成一張全圖——也把這套迴圈，交到你手上。讓你看完，下一篇也能這樣做。

第一步：先寫「評分標準」，不是先動筆

很多人以為迴圈的第一步是「叫 AI 先寫一版」。剛好相反。 真正的第一步，是先寫下一份規格——這篇要做給誰、要達成什麼、有哪些不能破的品味鐵則。動筆前我這個水手收到的，就是這樣一份文件，它的核心只有一句：

「我不要替讀者做選擇，我要給他足夠的材料，讓他自己做出最適合自己的決定。」

骨架大概是：給誰看（對 AI 好奇、但不寫程式的一般讀者）／要達成（讀完能自己分辨兩個外掛、又不被替他做決定）／品味鐵則（不下結論、白話分層、中立靠「結構」而非形容詞）。

這份文件不是擺設——它就是你後面拿來審的那把尺。你不是先有「標準答案」，但你一定要先有「評分標準」。

⬇️ 這就是水手收到的規格，你可以拿去當自己的範本：按此下載檔案

所以 Loop Engineering 的第一步，不是寫文章，是寫清楚「這篇要做到什麼」。

第二步：審查不是玄學，是一台引擎

先看一個證據，感受一下「審」的威力。

水手交來的第一版，開場大概是這樣的——「你可能也有過這種下午：Chrome 開著十幾個分頁，你像一台很忙的交換機。」四平八穩，但也就是「你我都有過」的泛泛場景。

少尉審完、船長補上故事靈感、改過之後，同一個開場變成了——「你只是想安排下週三去台中吃頓飯，側邊欄卻跳出一句：你男朋友人在高雄，你最近常去台中，其實是去找女朋友……這頓，是哪一位？」

同一個痛點，從「泛泛的你」收進一個有祕密、有風險、有畫面的人身上。這一刀，不是「寫」出來的，是「審」出來的。

但這個進步不是靈感，是一台引擎跑出來的。引擎靠的是一張固定的檢查清單，我們用的維度是：

以讀者為中心 ・ 中立 ・ 白話分層 ・ 結構動線 ・ 事實不唬人 ・ 圖文並茂 ・ 整體節奏

運作方式很機械：拿每一個維度，把草稿從頭掃一遍；命中一個問題，就記一條，並標上嚴重度——🔴 高度（傷筋骨）／🟠 中度（該修不致命）／🟡 輕度（細節）。所以下面這張「分級表」，不是憑感覺打的分數，是引擎跑出來的報表；而且你會發現，你也會跑很多輪、它會一輪輪收斂：

＊第二輪 🔴 清零，但有一條「全篇零實測」要等實機截圖才結案；同一輪也開出「定價位置」「補回具體價」等新點——審得越細，越會冒出新東西。這不是退步，是收斂中的正常現象。

跟著我們走一遍：三輪 ×（草稿 → 評鑑）

上面那張表是鳥瞰。現在跟著我們的真實檔案走一遍細節。一輪的節奏長這樣：

水手寫完一版草稿，發一份完工報告「靠港」（推進一個共用的收件箱）→ 少尉收到，照事先講好的那份規格，逐維度產出一份評鑑報告 → 船長看過，補上他的風格指導與故事靈感（女朋友那條線，就是這樣來的）→ 少尉把這些翻成一道命令、呼叫水手開工 → 水手據以改出下一版。如此跑三輪。

每一拍，你都可以只看節錄、想深入就展開、想要原件就下載。

拍 1 ・ 第一版草稿——水手憑規格起稿。開場還很平淡：「你可能也有過這種下午……十幾個分頁……像一台很忙的交換機。」骨架有了，但更像「產品比較文」，不像說書。

⬇️ v1 全文：按此下載檔案

拍 2 ・ 第一輪評鑑——少尉拿清單掃，一次開出 13 條（🔴3／🟠5／🟡5）。最重的一條：

「四個交集全停在『站位不同』，只描述『不一樣』，沒給『怎麼不一樣、哪個做起來比較順』——把『不下結論』誤套成『不做任何比較』。」

⬇️ 第一輪評鑑全文：按此下載檔案

拍 3 ・ 第二版草稿——船長補上故事靈感，少尉翻成命令，水手改稿。最大的一改，就是把平淡開場重寫成那個「訂晚餐→男友／女友」的故事；同時把雙清單改對稱、交集從「不一樣」改成真的比手感。一個「改前 → 改後」（示意）：

改前（示意）：「讀頁面這件事，兩個都做得到，只是站的位置不同。」
改後（示意）：「讀頁面兩個都行——Claude 在側邊欄即時讀你正在看的那頁、適合邊看邊改；Codex 傾向把任務丟進工作台跑完再回收、適合放著不必盯。哪個比較順，看你想不想盯著它做。」

⬇️ v2 全文：按此下載檔案

拍 4 ・ 第二輪評鑑——少尉用同一張清單重檢：13 條修好 10、明顯收斂；🔴 清零（剩 1 條「待實測」），但也新冒出定價位置、補回具體價、圖片站位太少幾點。審得越細，越會冒新東西，這是正常的。

⬇️ 第二輪評鑑全文：按此下載檔案

拍 5 ・ 第三版草稿（文字定稿）——水手把殘留收乾淨：兩邊比喻暖度拉齊、公式化對句改掉、定價移到安全之後並補回具體價、接上船長定稿的結局與兩則後記。到這裡，文字就是你在上一篇讀到的樣子。

⬇️ 第三版（文字定稿）全文：按此下載檔案

拍 6 ・ 第三輪評鑑——少尉確認文字層過關：上一輪殘留都修了，只剩價格段可再瘦一點這種極輕微項；火力正式從文字轉到配圖。

⬇️ 第三輪評鑑全文：按此下載檔案

換你來審：三頂帽子，輪流戴

我們用「水手／少尉／船長」講起來有味道，但你一個人寫的時候會卡：「我沒有少尉啊。」其實這三個只是三頂帽子，誰都能戴：

• 水手＝起稿那一手：可以是你，也可以是 AI。
• 少尉＝審查那一關：你自己戴上審稿帽、或把草稿和那張清單一起貼給另一個 AI，要它逐維度挑問題、標嚴重度。重點是「審的人」和「寫的人」要分開。
• 船長＝品味與拍板：這頂永遠是你。

你不需要一支艦隊。你需要的，是讓「寫」和「審」分成兩頂帽子，輪流戴。

它跑起來，其實是什麼感受

說點實話，免得你以為這很神。

命令不是聊天視窗裡的一句話，而是一個個檔案；水手每次開工，第一件事就是把它們讀進來，所以工作可以跨好幾個 session、跨好幾天接力，不怕中途斷掉。最常見的卡點不是 AI 不會做，而是**「等人」——某個實測要登入、某張截圖只有你電腦上才有、某個方向要你拍板。AI 會過度生產（一口氣丟給你三條財務路、一口氣 commit 一大串），需要有人剪裁；它也會把可疑的東西講得頭頭是道，需要有人喊停。真實的感受不是「按一個鍵文章就好了」，而是一場有人盯著的耐心迭代**。

技術上怎麼接起來：用 GitHub 當「信箱」

這套迴圈能跨 session、跨機器跑，靠的是一個樸素的點子：把命令和成果都變成檔案，用 Git／GitHub 當「信箱」傳遞。（GitHub＝一個放檔案、自動記住每次改動的雲端資料夾。）

• 命令信箱：少尉把命令寫進一個共用 repo（repo＝一個帶版本紀錄的資料夾）；水手開工時用一支小腳本讀進來——靠 hook（hook＝開工時自動觸發的小機關）自動灌進脈絡，不必手貼。
• 作品 repo：水手把草稿、腳本、報告 commit 進自己的 repo，天然有版本、可回溯、可中斷續做。
• 靠港收件箱：水手收工後用腳本把快報推進另一個共用 repo；那把 token（token＝一把只能開特定門的鑰匙）只被授權寫這一個收件箱，碰不到別的。
• 圖片：不塞進 Git（會把 repo 撐爆），改上傳 Ghost 當 host，repo 只留每張圖的網址與 sha256（sha256＝檔案的指紋，用來認「圖有沒有變、要不要重傳」）。

換句話說：不必把所有人塞進同一台電腦。Git 的版本與權限，本身就是這個迴圈的協作骨架——可追溯、可中斷續做、權限分得清。

圖片那一關：圖也是審出來的

文字過關之後，戰場轉到配圖。這一關一樣不是一次到位：一開始的交集圖兩個圈交得太窄、心智圖的線壓到字、深色模板第一次渲染還把文字裁掉。沒有一張是「一次漂亮完成」，全是看、修、再看、再修——和文字用的是同一台引擎。

收束：把迴圈交到你手上

把它拆開來看，這其實有個很新的名字——「迴圈工程（loop engineering）」。它新到什麼程度？2026 年 6 月才從開發者社群冒出來、開始被討論（最早是開發者 Peter Steinberger 在 X 上一句「別再對 agent 打 prompt，去設計一個會替你打 prompt 的迴圈」點起來的）。它講的就是：人不再一句一句下指令，而是設計一個會自己轉的循環——起稿、用清單審、修訂、補上判斷與品味，然後再審，直到開不出 🔴 為止。

最有靈魂的橋段——女朋友那句、結局的反諷——都來自人；AI 出的是速度、記性，和不厭其煩的迭代。所以與其說「AI 幫你把文章寫完」，不如說「你設計一個迴圈，讓 AI 陪你把文章磨好」。

你也可以這樣做（最小迴圈）：

1. 先寫三行規格：給誰看、要達成什麼、三條品味鐵則。
2. 起稿（自己或叫 AI），先別管完美。
3. 換一頂帽子，拿規格＋檢查清單逐條審，每條標嚴重度。
4. 照評語改 → 再審。重複到開不出 🔴 為止（通常三到五輪）。

至於那個老問題——是 AI 在幫人，還是人在幫 AI？這篇一樣不打算替你回答。只是這一次，連這篇文章本身，都是那個問題的一個小小註腳；而下一個註腳，可以由你來寫。

最後，三個角色的心得

為了讓讀者感受這趟協作不是一張抽象的流程圖，而是三個各有位置的真實角色——最後，把他們在收工那天寫下的心得，原樣擺在一起。（這三段是在上一篇完工當天寫的，所以裡頭的「這篇文章」，指的是上一篇。）