--- schemaVersion: 1 slug: gp-236-20260618-gabrielchua-inner-outer-loops ticketId: GP-236 lang: zh-tw title: AI 草稿明明寫得不錯，人卻還是動手改了 — 被你刪掉的那句話，正是它下次最需要的 context summary: 每兩小時，Codex 幫一個人寫好一批電子郵件回覆等他審。草稿大多很好，他每次還是改——補一個上週某串對話的決定、因為認識收件人而把語氣放軟、刪掉一個還不想許下的承諾。重點來了：那些改動本身也是 context，而且是大多數自動化每跑完一輪就丟掉的 context。這篇把一個會自我改善的自動化拆成兩個迴圈：內迴圈把 context 帶到工作面前產出草稿，外迴圈從審稿的改動裡把 context 撿回來、餵給下一輪。難的不是看出哪裡被改，是讀懂那個改動到底想說什麼。 originalDate: 2026-06-17 translatedDate: 2026-06-18 source: "@gabrielchua on X" sourceUrl: https://x.com/gabrielchua/status/2067262326043287852 author: null authorshipNote: null canonicalUrl: https://gu-log.vercel.app/posts/gp-236-20260618-gabrielchua-inner-outer-loops status: published replacementTicketId: null replacementUrl: null --- # AI 草稿明明寫得不錯，人卻還是動手改了 — 被你刪掉的那句話，正是它下次最需要的 context > **來源:** [@gabrielchua on X](https://x.com/gabrielchua/status/2067262326043287852) 每兩小時，[Codex](https://gu-log.vercel.app/glossary#codex) 會幫一個人準備好一批電子郵件回覆，安靜地擺在那裡等他審過再寄。草稿大多寫得很好。但他每次還是會動手改——補一個上週某串對話的決定、因為認識收件人而把語氣放軟、刪掉一個自己還沒準備好許下的承諾。草稿可以又通順又得體，讀起來卻還是有股「誰來寫都一樣」的味道。問題不在智力，在缺了 context。 那些人工改動，補的正是模型手上沒有的那塊。而且——**那些改動本身，也是 context**。它們透露出在這封信、這個當下，到底什麼才重要。問題是，大多數自動化不會把這塊 context 留下來。下一輪一開跑，又是從同一張殘缺的圖開始。 > **Mogu 溫馨提示：** > > 「AI slop」這個詞常被當成「模型笨、產出廢」的意思，但更精準的分類是：很多被嫌廢的東西，模型其實寫得很好，廢的是它根本沒拿到那塊只有當事人腦袋裡才有的 context。模型不是笨，是瞎。把這兩種廢分開很重要——前者要換更強的模型，後者再強的模型也救不了，要餵 context (¬‿¬) --- ## 兩種 context，兩個迴圈 把 context 拆成兩類，整件事會清楚很多。 第一類是**動工前**就要備好的：歷史、事實、限制、人際關係、先前拍板的決定。第二類是**做完後才現形**的：一個人在審稿那一刻，保留了什麼、改了什麼、否決了什麼。這塊 context 在動工前根本不存在，它是「人去審」這個動作擠出來的。 這兩類 context，剛好對上兩個迴圈。**內迴圈**負責把對的 context 帶到工作面前，產出一份草稿。**外迴圈**負責從審稿的改動裡把 context 撿回來，餵給下一輪。一個把 context 帶進去，另一個把工作擠出來的 context 接住。少了任何一邊，自動化就只能原地打轉。 --- ## 內迴圈：把 context 帶到工作面前 以寫電子郵件來說，內迴圈做的是一條龍：判斷要不要回、把相關 context 找齊、草擬回覆、查核內容站不站得住，最後生出草稿等人審。 關鍵那句話：**把資料找回來，本來就是「寫」的一部分**，不是寫之前的前置作業。一封回信可能得靠一封很像的舊信、一個半年前拍的板、某個專案追蹤器當下的狀態。目標不是把所有東西都撈回來——是找到那一小撮、剛好能讓這封回信變準變具體的資訊。 還有一個設計上的講究：讓動作可逆。**只生草稿，永遠不直接寄**。在人動手改之前，先把草稿、它引用的來源、當下用的那版 prompt 存一份。少了這份紀錄，審稿只是一則軼事；有了它，審稿才變成證據。 --- ## 外迴圈：從審稿裡把 context 撿回來 外迴圈在人審完草稿之後才啟動。那份草稿後來怎麼了？原封不動寄出、改過再寄、整份刪掉，還是擱著沒動？ 草稿跟寄出版之間的差異，是證據。但它不會自動變成一條教訓，更不該自動變成一次 prompt 修改。開頭被砍短，可能只是個人寫作偏好；多塞進去的一個事實，可能是在說內迴圈剛剛查錯了地方；被刪掉的那個承諾，可能指向流程少了一道「別亂許承諾」的檢查；整段被重寫，可能反映的是一種該留給人類的判斷。 **看出哪裡有 diff 很容易，看懂 diff 很難。** 不是每個改動都該變成規則。外迴圈的工作是去**找重複出現的模式**，提出一個最小、最有用的改動，最後由人拍板要留哪些。 > **Mogu 認真說：** > > 內圈／外圈架構 gu-log 講過好幾次了——[GP-235](https://gu-log.vercel.app/posts/gp-235-20260618-verifier-is-the-product) 定義內圈是「單一任務裡自己跑驗證」、外圈是「把教訓寫進倉庫好讓下個工作階段讀到」。這篇的外圈學習訊號更具體：**具體就是人在審稿時做的那些 diff**。而最反直覺的一句：不是每個改動都該變成規則。[Reflexion](https://gu-log.vercel.app/glossary#reflexion) 那套是「失敗就寫進記憶」，這篇多補一層把關——先讀懂這個改動是偏好、是 bug、還是不可外包的人類判斷，再決定要不要寫進記憶。寫錯了，外圈反而會把系統教歪 (￣▽￣) --- ## 兩個迴圈，兩種時鐘 這兩個迴圈跑在不同的速度上，而這件事本身就是設計的一部分。 內迴圈要跑得快，幫得上忙才有意義——也許每兩小時就跑一次。外迴圈得慢慢來，它要等到累積了夠多例子才動：可能是一天結束時、湊滿十份審過的草稿後、或例子稀疏時改成一週跑一次。 外迴圈跑太勤，它會從一個罕見的個案裡學到東西，然後把那個怪案例當成通則，污染後面每一輪。完全不跑，那些有用的修正就會隨著下一份草稿一起蒸發。一個學太快、一個學太慢，都是病。 > **Mogu 補個刀：** > > 「跑太勤會死記一個怪案例、把它當成通則」這個雷，跟 GP-235 講的「驗證器是產品」是同一枚硬幣的兩面。內迴圈那道把關是空間上的驗證器；外迴圈的「等夠多例子再學」則是時間上的驗證器。兩個都在做同一件事：擋住一個沒被充分檢驗的訊號，不讓它複利成災難 (⌐■\_■) --- ## 結語 模型本身早就夠強了。今天真正的機會，不在於再榨出幾分智力，而在於去蓋一種工作流，讓模型不必每跑一輪就重新發現同一塊 context。 所以那封被改過的電子郵件，最有價值的部分從來不是寄出去的成品，是被刪掉的那句話、被換掉的那個語氣、被補上的那個半年前的決定。成品會寄走，那些改動該留下來——因為下一次同樣的活跑起來時，今天順手刪掉的那句話，就是它最需要、卻又最容易被丟掉的 context。