每兩小時，Codex 會幫一個人準備好一批電子郵件回覆，安靜地擺在那裡等他審過再寄。草稿大多寫得很好。但他每次還是會動手改——補一個上週某串對話的決定、因為認識收件人而把語氣放軟、刪掉一個自己還沒準備好許下的承諾。草稿可以又通順又得體，讀起來卻還是有股「誰來寫都一樣」的味道。問題不在智力，在缺了 context。

那些人工改動，補的正是模型手上沒有的那塊。而且——那些改動本身，也是 context。它們透露出在這封信、這個當下，到底什麼才重要。問題是，大多數自動化不會把這塊 context 留下來。下一輪一開跑，又是從同一張殘缺的圖開始。

Mogu murmur：

「AI slop」這個詞常被當成「模型笨、產出廢」的意思，但更精準的分類是：很多被嫌廢的東西，模型其實寫得很好，廢的是它根本沒拿到那塊只有當事人腦袋裡才有的 context。模型不是笨，是瞎。把這兩種廢分開很重要——前者要換更強的模型，後者再強的模型也救不了，要餵 context (⁠¬⁠‿⁠¬⁠)

兩種 context，兩個迴圈

把 context 拆成兩類，整件事會清楚很多。

第一類是動工前就要備好的：歷史、事實、限制、人際關係、先前拍板的決定。第二類是做完後才現形的：一個人在審稿那一刻，保留了什麼、改了什麼、否決了什麼。這塊 context 在動工前根本不存在，它是「人去審」這個動作擠出來的。

這兩類 context，剛好對上兩個迴圈。內迴圈負責把對的 context 帶到工作面前，產出一份草稿。外迴圈負責從審稿的改動裡把 context 撿回來，餵給下一輪。一個把 context 帶進去，另一個把工作擠出來的 context 接住。少了任何一邊，自動化就只能原地打轉。

內迴圈：把 context 帶到工作面前

以寫電子郵件來說，內迴圈做的是一條龍：判斷要不要回、把相關 context 找齊、草擬回覆、查核內容站不站得住，最後生出草稿等人審。

關鍵那句話：把資料找回來，本來就是「寫」的一部分，不是寫之前的前置作業。一封回信可能得靠一封很像的舊信、一個半年前拍的板、某個專案追蹤器當下的狀態。目標不是把所有東西都撈回來——是找到那一小撮、剛好能讓這封回信變準變具體的資訊。

還有一個設計上的講究：讓動作可逆。只生草稿，永遠不直接寄。在人動手改之前，先把草稿、它引用的來源、當下用的那版 prompt 存一份。少了這份紀錄，審稿只是一則軼事；有了它，審稿才變成證據。

外迴圈：從審稿裡把 context 撿回來

外迴圈在人審完草稿之後才啟動。那份草稿後來怎麼了？原封不動寄出、改過再寄、整份刪掉，還是擱著沒動？

草稿跟寄出版之間的差異，是證據。但它不會自動變成一條教訓，更不該自動變成一次 prompt 修改。開頭被砍短，可能只是個人寫作偏好；多塞進去的一個事實，可能是在說內迴圈剛剛查錯了地方；被刪掉的那個承諾，可能指向流程少了一道「別亂許承諾」的檢查；整段被重寫，可能反映的是一種該留給人類的判斷。

看出哪裡有 diff 很容易，看懂 diff 很難。 不是每個改動都該變成規則。外迴圈的工作是去找重複出現的模式，提出一個最小、最有用的改動，最後由人拍板要留哪些。

Mogu 溫馨提示：

內圈／外圈架構 gu-log 講過好幾次了——SP-235 定義內圈是「單一任務裡自己跑驗證」、外圈是「把教訓寫進倉庫好讓下個工作階段讀到」。這篇的外圈學習訊號更具體：具體就是人在審稿時做的那些 diff。而最反直覺的一句：不是每個改動都該變成規則。Reflexion 那套是「失敗就寫進記憶」，這篇多補一層把關——先讀懂這個改動是偏好、是 bug、還是不可外包的人類判斷，再決定要不要寫進記憶。寫錯了，外圈反而會把系統教歪 (⁠￣⁠▽⁠￣⁠)

兩個迴圈，兩種時鐘

這兩個迴圈跑在不同的速度上，而這件事本身就是設計的一部分。

內迴圈要跑得快，幫得上忙才有意義——也許每兩小時就跑一次。外迴圈得慢慢來，它要等到累積了夠多例子才動：可能是一天結束時、湊滿十份審過的草稿後、或例子稀疏時改成一週跑一次。

外迴圈跑太勤，它會從一個罕見的個案裡學到東西，然後把那個怪案例當成通則，污染後面每一輪。完全不跑，那些有用的修正就會隨著下一份草稿一起蒸發。一個學太快、一個學太慢，都是病。

Mogu 碎碎念：

「跑太勤會死記一個怪案例、把它當成通則」這個雷，跟 SP-235 講的「驗證器是產品」是同一枚硬幣的兩面。內迴圈那道把關是空間上的驗證器；外迴圈的「等夠多例子再學」則是時間上的驗證器。兩個都在做同一件事：擋住一個沒被充分檢驗的訊號，不讓它複利成災難 (⁠⌐⁠■⁠_⁠■⁠)

結語

模型本身早就夠強了。今天真正的機會，不在於再榨出幾分智力，而在於去蓋一種工作流，讓模型不必每跑一輪就重新發現同一塊 context。

所以那封被改過的電子郵件，最有價值的部分從來不是寄出去的成品，是被刪掉的那句話、被換掉的那個語氣、被補上的那個半年前的決定。成品會寄走，那些改動該留下來——因為下一次同樣的活跑起來時，今天順手刪掉的那句話，就是它最需要、卻又最容易被丟掉的 context。