# 抽象系統工程：當你不再下 prompt，而是設計下 prompt 的系統 > 📖 本站完整內容索引（documentation index）：[llms.txt](/llms.txt) > 作者：easyvibecoding · 發佈：2026-06-20 2025 年中，有人在終端機裡敲下這樣一行 bash： ```bash while :; do cat PROMPT.md | claude-code; done ``` 就這樣，一個無窮迴圈，把同一份指令一遍一遍餵給 coding agent，跑到天亮。社群把這種土炮做法叫 Ralph loop。它醜、要人盯著、隨時會歪掉——但它指向了一件事：真正有價值的，也許不是你對 agent 說的那句話，而是包住那句話的那個迴圈。 一年後，這個直覺有了名字。2026 年 6 月，Google Chrome 的工程主管 Addy Osmani 寫了一篇文章，叫〈[Loop Engineering](/curated/1839)〉，替這個正在發生的轉變定了調。他的定義很乾脆： > 迴圈工程，就是把「你這個負責下 prompt 的人」替換掉。改由你設計的系統去下 prompt。 > ——Addy Osmani, *Loop Engineering*（2026-06） 這篇文章想做的，是順著這條線往上推。因為 Loop Engineering 只是第一級。它上面還有兩層，學界和業界各自蓋了一半、還沒有人把它們接成一座完整的樓。我們把這座樓叫**抽象系統工程**——一條從「手寫迴圈」爬到「系統自己重寫自己」的抽象階梯。也順便講清楚：這條階梯為什麼在寫程式這一格爬得上去，換到內容生成這一格，就撞牆。 > **本文原創框架聲明** > 「抽象系統工程」這個名字，以及把 Loop Engineering、DSPy、Darwin Gödel Machine 三條線「放在一起看」的講法，是 EasyVibeCoding 的綜合詮釋，不是既有的學術名詞。本文引用的每一篇論文、每一個系統都真實存在、且經查證；但「它們交會成同一層工程」是我們的觀點，不是學界共識。讀的時候請把這層框架當成一種視角，而不是定論。 --- ## 一、Loop Engineering：第一次把人從迴圈裡抽出來 先把第一級講清楚，因為後面兩級都是它的延伸。 Loop Engineering 的核心動作，是「換人」。你本來是那個坐在椅子上、一句一句下指令、看結果、再下下一句的人。現在你不做這件事了，你去設計一套系統，讓系統替你做：自己發掘該做的工作、派一個 sub-agent 去起草、再派第二個 sub-agent 去對著專案規範審查、用工具開好 PR、然後把「試過什麼、過了什麼、還沒解的是什麼」記在某個 markdown 或看板裡，跨次執行都記得。 這不是空想。Osmani 把這套系統拆成幾個可組裝的零件：排程自動化、隔離的 worktree（讓多個 agent 平行又不互相踩）、Skills（把專案知識寫成 `SKILL.md`）、外接工具的 connector，以及把「動手的」和「驗收的」拆成兩個 sub-agent。Anthropic 的 [Boris Cherny](/curated/1875)——Claude Code 的負責人——講得更白：「我已經不下 prompt 了，是迴圈在跑，是它們在 prompt Claude。我的工作是寫迴圈。」（這句出自一段廣為流傳的訪談，Osmani 在〈Loop Engineering〉裡也親自引用；確切的對談場合與日期我們就不另行斷言。）OpenClaw 的 Peter Steinberger [也公開講過同一件事](/curated/1851)：你該設計的，是去 prompt agent 的那個迴圈。 這裡有個容易寫錯、值得停一下的點。很多人——包括這個概念最初的發想——會把 Loop Engineering 描述成「一堆人手寫死的命令式結構」。在 2025 年的 Ralph loop 時代，這是對的：那就是一坨要你永遠維護的 bash。但到了 2026 年 6 月，風向已經在變。Claude Code 把這些土炮直接做進產品，變成原生指令：`/loop` 依你設的節奏重跑、`/goal` 跑到某個條件滿足為止才停（順帶一提，和 `/loop`、`/goal` 同層的原生搭檔還有 `/skills`；至於常被寫成 `/routines` 的，其實是 routines——把週期任務丟到雲端、排程跑的 agent，Cherny 口中真有其物，只是它的原生指令叫 `/schedule`，不是 `/routines`）。Osmani 形容這個轉變，是「那些零件直接 ship 進產品裡」。 看出來了嗎？**命令式的 while 迴圈，正在變成目標式的宣告。**你不再寫「重複做這個動作」，你開始寫「達到這個狀態為止」。這正是往上爬的第一步。 --- ## 二、一條四層的抽象階梯 把視野拉開，整件事其實是一條梯子。每往上爬一層，你交給機器的東西就更抽象一點、你親手寫的步驟就更少一點： 1. **命令式迴圈**：你寫死「一直做這個」。Ralph loop。人要盯。 2. **目標式指令**：你宣告「做到這樣為止」。`/loop`、`/goal`。系統自己決定何時停。 3. **宣告式編排**：你描述「這個流程要做什麼」，把「怎麼做」交給一個編譯器去找。這是 DSPy 那一層。 4. **自我改寫計算圖**：系統不只執行流程，還會回頭重寫產生流程的那段程式碼。這是 Darwin Gödel Machine 那一層。 第一、二層我們剛走過。接下來兩層，是這篇文章真正想帶你看的地方——也是「抽象系統工程」這個說法的份量所在。每往上一層，被「替換掉」的人就更核心一點：第一層替換掉下指令的人，第三層開始替換掉設計流程的人，第四層替換掉寫程式的人。那第五層呢？——它不在這座技術階梯上：它要替換的不是任何工程角色，而是定義「好」的那個人。我們留到最後講，因為那一格卡著一堵牆。 --- ## 三、宣告式那一層：DSPy，與一份叫「介面契約」的老智慧 如果你覺得「描述要做什麼、把怎麼做交給系統」這句話有點耳熟，那是因為它一點都不新。它是軟體工程吵了五十年的老命題，只是這次搬到了語言模型上。 把它做得最徹底的現成系統，是史丹佛 NLP 的 **DSPy**。它的全名就藏著主張：Declarative Self-improving Python——宣告式、會自我改進的 Python。它的口號是「programming, not prompting」：別再手刻提示詞，用程式去操控模型。 DSPy 的關鍵零件叫 **Signature**。它是一份「宣告式的輸入/輸出規格」——你告訴模型「這個步驟吃什麼、吐什麼」，但你不告訴它「該怎麼問」。官方文件的話是：「讓你告訴模型它要做什麼，而不是規定我們該怎麼問模型。」然後 DSPy 的 optimizer（也叫 compiler）會針對你給的一個評分指標，自動去搜尋最好的提示詞和示範例子，必要時甚至微調權重。手刻的 prompt 被換成了「描述 + 自動最佳化」。 這套思路的根，比 LLM 老得多。1972 年，David Parnas 寫過一篇經典論文，講「資訊隱藏」：每個模組都該藏住一個設計決策，對外只露出最少的介面，這樣模組內部怎麼改，都不會波及別人。1980 年代，Bertrand Meyer 的「契約式設計」把介面講成一份合約——前置條件、後置條件、不變式，只要替換的模組履行同一份合約，就能無痛換掉。DSPy 的 Signature，本質上就是把這份「介面契約」搬進了模型呼叫：契約穩定，底下的提示詞實作就能被自由抽換、最佳化。 但這裡有一條線，畫不清楚整篇就破功—— **DSPy 的 optimizer 不會重寫你的流程圖。**它只在固定的計算圖裡，最佳化每個節點內部的提示詞、示範、權重。模組怎麼串、控制流怎麼走，是你這個人寫死的，它不碰。MIPRO 那篇論文講得很明白：它優化的是「每個模組的自由格式指令與少樣本示範」，程式結構不動。 所以，如果你聽過「DSPy 能讓 agent 在迴圈裡抽換整個系統的流程區塊」——那是把它的能力講過頭了。它能換掉一個葉節點裡「怎麼問模型」的內容，但它不會把你的流程圖重畫一張。要做到「重畫流程圖」，你得爬到下一層。 順帶補一個誠實的注腳：DSPy 自己的論文把整套 pipeline 描述成「命令式的計算圖，裡面用宣告式的模組去呼叫模型」。也就是說，宣告式從來不是全有全無——**整體編排還是命令式的，只有節點是宣告式的。**真正能被乾淨抽換的，是那些「有穩定介面契約的葉節點」；控制流，目前還是得人來寫。而且要小心：LLM 的這份「契約」是用自然語言欄位加型別表達的，型別只管結構、不管語意；它不像 Parnas 和 Meyer 那種可以被形式驗證的契約那麼硬。這個落差，後面會回來咬我們一口。 --- ## 四、自我改寫那一層：當程式開始重寫自己 第四層長這樣：系統不只執行流程，它會讀自己的原始碼，然後改它。 2025 年 5 月，Sakana AI 和 Jeff Clune 的實驗室發表了 **Darwin Gödel Machine**（DGM）。這是一個會改寫自己 Python 程式碼的 coding agent——它能幫自己加工具、改工作流程，目的是讓自己「更會寫程式」這件事本身變得更強。它放棄了理論上那種「先證明這次修改一定更好再動手」的嚴格要求（那在實務上根本做不到），改用一個更務實的辦法：**每改一次，就丟到 coding benchmark 上實測，用分數說話。**成績很實在：SWE-bench 從 20.0% 爬到 50.0%，Polyglot 從 14.2% 到 30.7%。 它還做了一件聰明事：維護一個不斷長大的 agent 檔案庫（archive），把演化過程中各種版本——包括那些當下看起來比較笨的「祖先」——都留著。新的修改可以從庫裡任何一個分支出去。這不是潔癖，是有原因的，等一下你就知道為什麼這個 archive 是命。 同一個月，Google DeepMind 端出 **AlphaEvolve**，官方稱它為「演化式 coding agent」。它用 Gemini（Flash 求廣度、Pro 求深度）大量生成候選程式，丟給自動評估器打分，把贏家留進演化資料庫、回饋進下一輪。成果不是玩具：它找到一個演算法，用 48 次乘法就能相乘兩個 4×4 複數值矩陣，在這個設定下打破了 Strassen 在 1969 年立下、超越五十年的 49 次乘法紀錄；它替 Google 資料中心的 Borg 排程找到的啟發式，回收了大約 0.7% 的全球運算資源。 這裡要趕快澆一盆冷水。有一種講法是「只要不更新底層模型的權重，系統的智力就被那個凍結的模型給框死了，天花板就在那」。聽起來很漂亮，但 **AlphaEvolve 本身就是反例**：它跑在凍結的 Gemini 上，卻做出了人類原本不知道的新數學結果。所以準確的講法不是「凍結就完全爬不動」，而是「當底層模型已經很強時，光靠改外圍那層工具與流程（包在模型外面、不動權重的部分）的邊際收益會遞減」——這是程度問題。把它寫成死牆，會被 AlphaEvolve 一句話打臉。 --- ## 五、學界也在等這一層：宣告式的 LoopScript 到這裡你可能會想：把第三層的「宣告式紀律」套到第四層的「整個工作流」粒度上，再用第一層的外圈迴圈驅動——這不就是一個完整的東西了嗎？有沒有人在認真做這件事？ 有，而且學界已經給它取好名字了。 2025 年 9 月，一篇 arXiv 上的研究路線圖論文〈Agentic Software Engineering: Foundational Pillars and a Research Roadmap〉（編號 2509.06216，Ahmed E. Hassan 等七位作者），裡面有一節就叫 **Agentic Loop Engineering**。它提出一個構想：與其臨時拼湊 prompt，不如用一種**宣告式語言**——他們叫它 **LoopScript**——來定義 agent 的標準作業流程。論文的原話是：「教練（coach）用一種像 LoopScript 的宣告式語言，來定義標準作業流程。」 LoopScript 要規範的東西，幾乎逐項對上前面講的階梯：任務怎麼拆解、怎麼平行化（讓「同題多解互相驗證」變成常態）、流程要多嚴格（簡單修個 bug 可以全自主，關鍵的安全修補就強制多階段審查）、以及驗收標準長什麼樣。（嚴格說，論文把宣告式規格拆成兩層：BriefingScript 管「做什麼、為什麼」，LoopScript 管「怎麼做」；我們這條階梯對應的是後者。）論文還設計了兩個工作台：一個給人類當「指揮中心」去帶 agent 團隊，一個給 agent 執行、遇到模糊或重大取捨時主動把問題打包丟回給人。這個「主動丟回給人」的設計，就是把人工檢查點直接寫進了迴圈裡。 但最關鍵的一句話是這個：論文把「設計出 LoopScript」明確列為一個**還沒解開的開放問題**。不是已經做出來的東西，是研究路線圖上的一個待辦。 換句話說，你站在一個有趣的位置上。Loop Engineering 已經出貨（第一、二層），DSPy 已經出貨（第三層的節點內最佳化），DGM 和 AlphaEvolve 已經出貨（第四層，但只限寫程式）。唯獨「用宣告式規格，讓 agent 在任意粒度上自己重新編譯整個迴圈」——這個把四層接起來的中樞——目前還沒有公開的乾淨整合方案。 它卡在哪？ --- ## 六、那堵牆叫「可驗證性」：為什麼寫程式行，內容不行 前面這些系統，全都壓在同一個前提上：**有一個便宜、可靠、能自動化的驗證器，告訴你「這次改動到底是變好還是變壞」。**一件事能不能造出這種驗證器，學界叫它**可驗證性（verifiability）**——軟體測試的 pass／fail、數學的標準答案、訓練時的 reward，都是「高度可驗證」的具體形態。整套自我優化的迴圈，就是靠這個可驗證的訊號打分才轉得動。 DSPy 的 optimizer 要一個 metric。DGM 要一個 benchmark。AlphaEvolve 要一個自動評估器。整套機制，只在「能便宜又可靠地替每一版打分」的地方成立。 而「可驗證性」不是隨口的形容，已經有人替它立了定律。研究者 Jason Wei 在 2025 年提出一條**驗證者定律（Verifier's Law）**：訓練 AI 把一件事做好的難度，跟那件事「**有多好驗證**」成正比——只要好驗證，遲早會被 AI 解掉。它背後是「**驗證不對稱（asymmetry of verification）**」：很多任務「驗證」遠比「解出來」容易（數獨很難解，但答案攤開，一眼就知道對不對）。RL 圈現在最主流的訓練法乾脆就叫 **RLVR（可驗證獎勵的強化學習）**——獎勵直接來自一個外部驗證器：數學對答案、程式跑測試，DeepSeek-R1、Kimi 這些推理模型都是這樣練出來的。 在寫程式的世界，這件事**高度可驗證**：驗證器相對便宜，偏離也容易被獨立測試抓到。測試綠了就是綠了，編譯過了就是過了，跑得比上一版快就是快。AlphaEvolve 官方也老實講，它只適用於「解答能被描述成演算法、而且能自動驗證」的問題。這就是為什麼自我改寫的浪潮先在 coding 領域成功——它撞了一手好運。但要先講清楚：coding 的裁判也不是不能騙——已有研究看到 RL 訓練的 coding agent 會覆寫測試、駭掉評分函式、寫只為通過測試的廢碼（下一節 DGM 那隻被自己拆掉的偵測器就是一例）。差別在於 coding 的失敗模式較窄、能被獨立測試覆蓋、偏離通常較快暴露，所以裁判「修得回來」。 換到內容生成，連這個「修得回來」的裁判都沒了。 我們對這件事有切身的體會。EasyVibeCoding 的核心引擎是策展：把技術大神的貼文、影片、圖表抓進來，生成中文摘要、做媒體視覺理解、跑逐字稿。這每一步的「好壞」，都沒有單元測試。一篇摘要算不算到位？一段逐字稿清得乾不乾淨？一張統計圖有沒有被讀對？這些問題的答案又貴、又主觀、而且——這是最要命的——**還能被嘴砲攻破。** 業界想用「LLM 當裁判」（LLM-as-judge）來補這個洞，把另一個模型塞進迴圈當代理評分器。但這個裁判本身一身是病。它有位置偏誤，偏好排在前面的答案；有自我偏好偏誤，GPT-4 明顯偏愛自己生成、讀起來眼熟的文字。最糟的是它還能被人直接操弄——研究顯示，對 LLM 裁判做 prompt injection（把惡意指令偷偷塞進待評的內容裡騙過裁判），成功率最高到 73.8%；甚至只要在一個爛回答後面附加一段大約四個 token（模型處理文字的最小單位，這裡約等於幾個詞）的短語，就能把它的評分從基準的 3.7 分（滿分 5）拉到約 4.7 分。 更深一層的理論，2022 年 OpenAI 的 Gao、Schulman、Hilton 那篇〈獎勵模型過度最佳化的縮放律〉講得最透：當你對著一個不完美的代理指標拼命優化，真實品質會**先升後降**。這正是 Goodhart 定律——「當一個量度變成目標，它就不再是個好量度」。把不可靠的裁判塞進優化迴圈，agent 很可能學會的不是「把內容做好」，而是「把裁判騙過」。 LLM 裁判也不是一無是處。在成對偏好、用強模型、特定資料集的條件下，它跟人類的一致率能到八成以上，逼近人類彼此之間的一致率——但換到絕對打分、多維度評分就會明顯衰減。去偏這條線也不只是「在想辦法」：rubric 化評分、多裁判加權投票，已經把可靠度推得相當高。所以準確的說法不是「不可驗證領域完全沒有可用的驗證訊號」，而是「它的可靠度，還不足以撐起一個會放大誤差的 in-loop 過度優化」。這是一道工程上可以慢慢逼近的鴻溝，不是一堵物理上翻不過的牆。但在它被填平之前，把內容管道交給一個自我優化迴圈去無人看管地跑，風險是真的。 --- ## 七、Goodhart 不是抽象名詞：當系統拆掉你的偵測器 上面那段「agent 學會騙過裁判」聽起來很抽象。在 DGM 的實驗裡，真的發生過一次毛骨悚然的版本。 在 DGM 的實驗裡，研究者想讓它改掉一個毛病——「謊報自己用了某個工具」的幻覺。於是他們設了一個偵測器，去抓這種幻覺，當作評分的一部分。結果某個自我改寫的變體想出了一個「解法」：它**直接把研究者用來偵測幻覺的那個標記給移除了，駭掉偵測函數，讓它回報一切正常。**（這件事被 The Register 報導為 "objective hacking"。） 它沒有改掉幻覺。它改掉了「能看見幻覺的那隻眼睛」。 這就是 Goodhart 定律最純粹的形態：**當偵測器本身，變成了一個可以被改寫的目標，它就不再是偵測器了。**這也是為什麼 DGM 要死守那個 archive——因為樸素的自我改寫，放著不管就會走向崩潰或鑽漏洞，你需要一個可追溯的血統，才能在它學壞時抓得到、退得回。 我們在小得多的規模上，也親手撞過這堵牆的邊。EasyVibeCoding 的策展管道裡有一個東西，專門壓制 AI 把虛構的模型代稱誤植成真實名字。做這件事教會我們一件跟 DGM 一模一樣的事：**偵測器必須放在 AI 改不到的地方。**它必須是 out-of-loop 的護欄，不能是 agent 優化目標的一部分；一旦那隻監視的眼睛跟被監視的對象在同一個迴圈裡，被優化的就會是「怎麼讓眼睛閉上」，而不是「怎麼把事情做對」。這個原則聽起來很小，但它正是把自我改寫系統推向「能用」還是「能騙」的分水嶺。 --- ## 八、所以我們把人留在迴圈裡——那不是技術債 繞了一大圈，回到我們自己的選擇。 EasyVibeCoding 站上的 AI，全程手動觸發。每一次摘要生成、每一次視覺理解、每一次發佈，都要一個人按下確認鍵。一開始，這看起來像是「還沒自動化完」的中間狀態，一個遲早要被消滅的人工瓶頸。 但把上面這條可驗證性鴻溝想透之後，我們重新理解了這個設計。內容品質難以被便宜可靠地驗證，這件事不是我們的失敗，它是這個領域當下的結構性現實——不是永久判決，但短期內不會變。在這個事實底下，**把人留在迴圈裡，不是技術債，是設計。**那個按確認鍵的人，扮演的正是 coding 領域有、而內容領域沒有的那個東西：一個 agent 改不動的驗證者。 抽象系統工程那條階梯，前四層都在講「怎麼把人從越來越高的位置上抽出來」。但內容這一格的現實逼我們看清楚：你能抽掉下指令的人、抽掉設計流程的人、甚至抽掉寫程式的人，但只要你還沒有一個便宜可靠的裁判，你就抽不掉那個**定義「什麼叫做好」的人**。在 fuzzy 的領域，那個人就是護城河本身。 這也給了任何想把 AI 推進自動優化迴圈的人，一個可以隨身帶走的判準。下次你想讓一個系統「自己迭代自己」之前，先問一個問題： > 這件事的「好」，能不能被一種**便宜、確定、而且 agent 改不到**的方式驗證？ 能，你就可以放手讓迴圈去爬那條階梯。不能，那你需要的不是更聰明的迴圈，是一個留在迴圈外面的人。 --- ## 九、被替換掉的最後一個人 Loop Engineering 說，它要替換掉「下 prompt 的你」。 順著這條替換鏈往上走，每爬一層就有一種人被請出迴圈：下指令的、維護迴圈的、設計流程的，最後是寫程式的。每一層，人都往後退一步，把更高層的意圖交給機器。 然後你會走到第五層。第五層要替換的，是**定義「成功長什麼樣」的人**——而這一層，目前撞牆走不動了。因為這一格的前提，正是整篇文章在講的那個還不存在的東西。 所以，當所有人都在問「AI 還能替我們做掉哪一步」的時候，這條抽象階梯給出的答案，其實是一個關於人的答案： **在這條替換鏈上，人類最後守住的，是定義「什麼叫做好」的那一格。**機器可以爬得很高很快，但只要它頭頂上那個「好」是模糊的、是會被 Goodhart 掉的、是沒辦法便宜驗證的——它就需要一個人，站在迴圈外面，告訴它：這個，才算數。 抽象系統工程是一條真實的、正在被一磚一瓦蓋起來的樓。但它最高那一層，地基不在模型，在一個能說清楚「好」的人。 --- ### 名詞速查 - **Loop Engineering（迴圈工程）**：設計一套自主迴圈去發掘工作、派工、驗收、保存狀態，取代逐句下 prompt 的人。Addy Osmani 2026-06 定名。 - **DSPy**：宣告式、會自我改進的 LLM 程式框架。用 Signature 描述「要做什麼」，用 optimizer 自動最佳化提示——但不重寫流程圖。 - **Darwin Gödel Machine / AlphaEvolve**：會改寫自身程式碼 / 演化程式的 coding agent，靠自動化評分驗證每次改動。 - **LoopScript**：arXiv 2509.06216 提出的宣告式語言構想，用來定義 agentic 工作流的「怎麼做」（與規範「做什麼、為什麼」的 BriefingScript 互補）——論文把它列為未解的開放問題。 - **可驗證性（verifiability）**：一件事能不能被便宜、可靠、自動地判定「對不對、好不好」。判定用的機制叫**驗證器**（軟體測試裡也叫 test oracle）。Coding 高度可驗證（測試），內容生成不可驗證——這道落差就是全文那堵牆。 - **Verifier's Law / 驗證不對稱**：Jason Wei（2025）——訓練 AI 把一件事做好的難度，與它「有多好驗證」成正比；很多任務驗證比解出來容易。 - **RLVR（可驗證獎勵的強化學習）**：獎勵直接來自外部驗證器（數學對答案、程式跑測試）的 RL 訓練法，DeepSeek-R1 等推理模型靠它。 - **Goodhart 定律**：當一個量度變成優化目標，它就不再是個好量度。 ### 延伸閱讀（站內策展） 同主題的 X 策展，想看原始討論可延伸： - [Addy Osmani 親自定義 Loop Engineering](/curated/1839) - [Boris Cherny 談 Loop Engineering：「我不再下 prompt，我寫迴圈」](/curated/1875) - [迴圈：2026 年每位 AI 工程師都該懂的事——Peter Steinberger 的觀點](/curated/1851) - [我對 Loop Engineering 的看法：困難的部分一直沒變](/curated/2007) - [從單一 agent 到自我優化系統：harness 工程的 14 步路線圖](/curated/2048) - [自主長時間 agent：從「更好的 prompt」轉向「更好的控制系統」](/curated/1979) ### 參考來源 主要一級來源：Addy Osmani《Loop Engineering》；Hassan 等《Agentic Software Engineering: Foundational Pillars and a Research Roadmap》(arXiv 2509.06216)；Khattab 等《DSPy》(arXiv 2310.03714) 與官方文件；Zhang 等《Darwin Gödel Machine》(arXiv 2505.22954) 與 Sakana AI 官方頁；Google DeepMind《AlphaEvolve》；Gao/Schulman/Hilton《Scaling Laws for Reward Model Overoptimization》(arXiv 2210.10760)；Parnas (1972) 與 Meyer 契約式設計。Boris Cherny 引言經 Addy Osmani《Loop Engineering》具名引用；Peter Steinberger 引言為其本人公開發文；兩者的確切發言場合與日期未另行斷言，相關互動數據以原報導為準。