# EvoX 智能演化系統與 AI Native 科研實踐 課程講義
課時：1 · 課件頁面：16
## 閱讀導航
- [第6課｜主題：系統級持續演化：Genesis 與軟體世界的沉澱](#lecture-lesson-1)
---
## 第6課｜主題：系統級持續演化：Genesis 與軟體世界的沉澱
### 系統級持續演化：Genesis 與軟體世界的沉澱
*頁面 1*
> **頁面目標：** 學習 Genesis 如何透過多 Agent 協作與嚴格驗證機制，讓專案程式碼跨越生命週期持續累積與演化。
> **頁面目標**
>
> 一個專案如何不只完成一次編碼，而是讓程式碼在整個生命週期裡持續累積與演化。核心線索有兩條：一是多 Agent 協作與遞迴任務拆解構成的工程模式，二是編譯、測試與驗收把有效修改沉澱為專案歷史的機制。
**講授要點**
- 1. 先點出「持續演化」的含義。軟體不是寫完即定型的產物，而是隨時間被不斷修改、補充與重構的實體。Genesis 的定位，正是為這種長期演化提供一套可運行的組織方式，而不是單次生成程式碼的技巧。 2. 多 Agent 協作解決的是「誰來分工」。面對一個真實專案，任務規模往往超出單次處理能力，因此需要有角色分工、有協作流程，讓不同環節的職責清晰可追蹤。 3. 遞迴任務拆解解決的是「怎麼下手」。把一個較大的目標逐層拆成可執行的小任務，直到每個子任務都足夠具體、能夠被獨立完成和檢驗。這既降低了單步難度，也讓每一步的結果可以被單獨評估。 4. 嚴格驗證解決的是「憑什麼算數」。編譯通過、測試通過、驗收通過，是三道層層收緊的關卡。只有跨過這些關卡的修改，才有資格被寫入專案歷史
- 未通過的修改則被丟棄或返工。 協作與拆解產生大量候選修改，驗證負責篩選，篩選後的結果沉澱為專案歷史，而專案歷史又成為下一輪演化的起點。這就是「系統級持續演化」的完整迴路。
**理解檢查**
請學生用自己的話說出「拆解—驗證—沉澱」三者的先後關係，並回答：如果一個修改通過了編譯但沒有通過測試，它在本頁描述的機制中會處於什麼狀態？教師據此確認學生是否真正理解了驗證關卡的作用，而非只記住名詞。
> **過渡提示**
>
> 本頁建立的是整體框架，後續內容會進入更具體的做法與實例。確認學生能複述這條迴路後，再繼續深入具體環節。
### 大模型能力邊界與系統級演化的必要性
*頁面 2*
> **頁面目標：** 理解當前大模型在複雜系統開發中的能力邊界以及構建持續發展系統的必要性。
> **頁面目標**
>
> 理解大模型在複雜系統開發中的能力邊界，以及為什麼必須把智能組件嵌入可跨生命週期持續演化的系統閉環。
> **講解順序**
>
> 大模型是強大的智能組件，卻不是能自我維持的系統。它在理解、生成、推理與工具調用上已具備可用能力，可作為高品質的假設提案者與程式碼生產者；但它缺少跨越生命週期持續演化所需的狀態、目標與回饋機制。
>
> 理解、生成、推理、工具調用，最終得到靜態快照，會話結束狀態清零。右側是把大模型作為小模組嵌入系統級演化閉環：提議、評價、選擇、沉澱。大模型負責提議；代理模型用於降低評價成本；選擇環節處理多目標權衡；沉澱形成跨會話記憶；群體智能維持候選多樣性，並回到下一輪提議。
>
> 狀態邊界——上下文視窗有限、缺少跨會話持久記憶，長週期專案無法自持；目標邊界——真實問題常涉及多目標衝突與偏好權衡，模型難以自主給出可辯護的取捨標準；回饋邊界——缺少可執行的評價、選擇與淘汰機制，生成的方案無法被客觀驗證與迭代保留。
>
> 模型能力提升不等於系統能力提升。能力是快照，環境是過程。只有把大模型嵌入「生成—評價—選擇—沉澱」的演化閉環，以群體智能維持多樣性、以代理模型壓縮評價成本、以選擇與沉澱留存有效經驗，智能才能在動態環境中保持適應。這也是 EvoX 的立足點。
**講授要點**
- 大模型具備強大的理解與生成能力，但無法獨立演化系統。 真實世界的複雜系統需要跨越生命週期的持續演化能力，靜態快照不足以應對環境變化。 智能組件需要配合演化機制才能適應動態環境，關鍵機制包括演化閉環、群體智能與代理模型。 狀態邊界、目標邊界、回饋邊界。
**練習處理**
核心概念題應選「理解當前大模型在複雜系統開發中的能力邊界以及構建持續發展系統的必要性」。
其餘判斷題應優先選擇「能用證據或例子解釋」的選項；只憑感覺、跳過資料背誦、同時改變所有因素來比較，都不符合本頁要求。
回答正確時，可肯定其能聯繫本頁概念並說明依據；回答錯誤時，提示回到講解中找出關鍵證據或例子，重點回顧三類邊界與「提議—評價—選擇—沉澱」閉環。
先說明核心意思是「大模型具備強大的理解與生成能力但無法獨立演化系統」，再舉例說明複雜系統為什麼需要跨越生命週期的持續演化能力。
**理解檢查**
請學生用自己的話說明「為什麼模型能力提升不等於系統能力提升」，並至少指出狀態、目標、回饋三類邊界中的兩類。若學生能說清從單體能力到閉環演化的關係，即可進入下一頁；若不能，回到對比圖重新梳理左右兩條路線。
> **過渡提示**
>
> 確認學生能說出「大模型是組件，演化閉環才是系統」的核心關係後，再進入後續關於系統級持續演化、Genesis 與軟體世界沉澱的內容。
### 從數值參數到程式系統的演化邊界擴展
*頁面 3*
> **頁面目標：** 掌握大模型如何將演化對象從傳統數值參數擴展到程式、模型結構和系統狀態。
> **頁面目標**
>
> 掌握大模型如何把演化對象從傳統數值參數擴展到程式、模型結構和系統狀態，並理解這一邊界擴展的推動條件與評價變化。
> **講解順序**
>
> 對象通常是低維、預定義的數值參數向量，如超參數、權重、連續變數；搜索空間由人工預設的結構與編碼方式限定。
>
> 計算規模與工程底座擴大後，高維、離散、結構化對象的搜索從不可行變為可處理，搜索邊界隨算力與工具鏈同步外擴。
>
> 具備程式碼理解、上下文推理與候選生成能力，可直接構造、修改並評估程式級對象，降低對手工設計編碼與變異算子的依賴。
>
> 若候選生成方法仍由人工固定，系統只會重複既定套路；把候選生成方法本身納入演化對象，例如差分進化的變異策略與參數設置，正是邊界擴展的體現。
>
> 從下到上為數值參數→模型結構→算法機制→程式與軟體工程狀態；向上搜索空間維度與語義複雜度遞增；右側是大模型能力支撐；上方是可執行驗證與工程成本約束。
>
> 層級越高，語義約束越強、評價鏈路越長，候選必須可執行、可驗證；適應度評估從純量函數變為運行結果與工程約束的聯合判斷。
>
> 這不是替代參數優化，而是把參數優化納入更大的程式與系統演化循環，形成從局部調參到系統級改進的連續譜。
**講授要點**
- 計算規模擴大帶來更廣泛的搜索邊界。 大模型能理解程式碼與上下文並構造複雜候選。 演化對象從數值參數擴展到程式與軟體工程狀態，中間經過模型結構與算法機制。 一是算力與工程底座擴大，二是大模型具備程式碼理解、上下文推理與候選生成能力。
**關鍵詞覆蓋**
- 數值參數、模型結構、算法機制、程式與軟體工程狀態、搜索邊界、程式碼理解、上下文推理、候選構造、可執行驗證、工程成本、適應度評估、連續譜。 練習處理與回饋： 大模型把演化對象從傳統數值參數擴展到程式、模型結構和系統狀態。若答偏，提示先回到概念句再重試。 大模型能理解程式碼與運行上下文，並據此構造、修改程式級複雜候選
- 錯誤項常把大模型限制在人工編碼的數值參數內。 練習3、練習4、練習5的正確方向不是背誦、憑感覺或同時改變所有因素，而是能用證據或例子解釋相關結論。回饋可強調：能聯繫本頁概念並說明依據，才算真正掌握。 團隊先只調節學習率、批次大小、網路層數等數值超參數
- 隨後讓大模型閱讀訓練腳本與運行日誌，直接改寫優化器實現、資料管線與算法控制流，再把候選交給運行時執行並回傳指標，用於下一輪程式級演化。可提問：核心意思是什麼？推動擴展的兩個條件是什麼？答案要點：傳統演化以低維數值參數向量為對象，搜索空間受人工預設限制
- 算力與工程底座擴大，使高維、離散、結構化搜索可處理
- 大模型能構造與改寫程式級對象，於是演化對象逐層擴展到模型結構、算法機制與程式或軟體工程狀態。再問：大模型如何參與程式級候選的構造與評估？答案要點：讀取腳本與運行上下文，改寫優化器或控制流生成可執行候選
- 運行時執行並檢查是否可運行，再與資源、時間預算等工程約束比對，指標回傳驅動下一輪演化。
**理解檢查**
讓學生用自己的話複述層級擴展鏈，並補上右側的大模型能力和上方的驗證與成本約束。可追問：「為什麼層級越高，適應度評估越像運行結果與工程約束的聯合判斷？」確認學生能說出可執行、可驗證、評價鏈路變長等理由。
> **過渡提示**
>
> 確認學生能區分參數優化與程式或系統級演化的關係後，再進入下一頁關於多智能體協作與驗證沉澱的內容。
### 真實世界的複雜挑戰：多目標權衡與多樣性保持
*頁面 4*
> **頁面目標：** 理解真實世界問題中相互牽制的複雜目標與保留多樣化候選方案的重要性。
**講授要點**
- 多目標下沒有天然全序。看到一組候選時，先問「在什麼偏好下比較」，再談優劣；否則容易把個人偏好誤當成客觀結論。
- 只保留當前最優會讓種群早熟收斂、模式崩塌。可以用擁擠距離、小生境、外部歸檔等機制，讓候選分散在前沿不同區域，覆蓋更多權衡區間。
- 算法負責生成有差異的可用選項，領域專家負責依據偏好與約束完成評估和取捨。不要把「生成候選」和「替人決策」混為一談。
頁面目標
理解真實世界問題中目標相互牽制的本質，並說明為什麼系統應保留一組有差異的候選方案，而不是收斂到單一「最優答案」。
講解順序
真實問題極少存在唯一最優解。多個目標彼此牽制，某一指標的改善通常以其他指標退化為代價。因此，系統應保留一組具有差異的非支配候選方案，讓權衡關係顯式可見，讓決策保留在人的判斷之中。
灰色散點表示可能方案，彩色點表示互不支配的候選，它們共同構成前沿。圖中 A 偏強度、B 均衡、C 偏效率、D 極低阻力。Pareto 前沿只能被逼近，不能被消除。
3. 展開四個關鍵認識。第一，目標衝突是結構性的，不是調參問題：升阻比、結構強度、成本、可製造性等目標之間不存在同時最優。第二，多目標下沒有全序：任意兩個方案可能互不支配，「最好」必須附帶偏好方向才能定義；看到一組候選時，先問「在什麼偏好下比較」，再談優劣。第三，稀疏回饋是常態：真實工程評價依賴高成本模擬或實測，回饋少、噪聲大、梯度不可用，單點爬山式搜索難以有效推進；演化算法通過維護種群，在少量評價下同時探索多個方向。
只追求當前最優會讓種群早熟收斂、模式崩塌，最終丟失整段未被探索的權衡區間；可以用擁擠距離、小生境、外部歸檔等機制，讓候選分散在前沿不同區域。
算法負責「生成一組有差異的可用選項」，領域專家負責「依據偏好與約束完成評估和取捨」。候選方案組不是替人做決定，而是把可比較的選項擺到桌面上。
超臨界翼型設計中，氣動效率、阻力發散特性、結構強度與製造成本相互牽制。EvoX 的價值不在於給出唯一「最優翼型」，而在於輸出覆蓋不同權衡區間的候選翼型族，供工程師按具體飛行工況與工藝約束挑選。
講授要點
用偏好方向定義「最好」；主動維護多樣性；區分生成與取捨。多目標下沒有天然全序，只保留當前最優會導致種群塌縮；算法生成有差異的候選，專家根據偏好和約束完成最終判斷。圖中右側兩幅小圖已經直觀呈現了單點收斂與多樣分佈的差異：前者塌縮成一團，後者鋪開成前沿。
練習處理
沒有全序意味著偏好方向必須參與定義；稀疏回饋會讓單點搜索難以推進是因為評價昂貴、噪聲大、梯度不可用；分散候選的價值是把選擇權和領域知識留給專家；只追當前最優會導致早熟收斂與模式崩塌；超臨界翼型設計中 EvoX 的定位是輸出覆蓋不同權衡區間的候選翼型族。回饋時若學生選錯，可引導其回到「偏好方向」「稀疏回饋」「多樣性是資產」這三個關鍵詞。
案例研究引導
城市空中計程車場景中，可識別航程與有效載荷衝突、噪聲與氣動效率衝突、安全冗餘與製造成本衝突。這些目標彼此牽制，所以不存在同時最優的單一設計，只存在互不支配的 Pareto 前沿。EvoX 可將航程、有效載荷、噪聲、安全冗餘、成本等作為多目標，運行種群搜索，輸出分佈在前沿不同區域、互不支配的候選方案；領域專家再根據運營場景、法規約束與工藝條件，對候選方案進行高保真模擬或實測，依據偏好方向完成評估和最終取捨。
理解檢查
請學生用自己的話舉一個日常多目標例子，例如購買筆記型電腦時效能、價格、重量與續航之間的權衡，並回答「在什麼偏好下比較」。若學生能說明同一組候選在不同偏好下會得到不同合理選擇，就說明其理解了本頁核心。
過渡提示
確認學生能區分「生成候選」和「替人決策」之後，再進入下一頁關於計算方式改進或方法改進的內容。本頁回答「為什麼需要多目標權衡與多樣候選」，後續內容會分別回答「如何算得更快」和「如何改進方法本身」。
### 張量化計算與統一架構的並行探索支撐
*頁面 5*
> **頁面目標：** 理解 EvoX 如何利用批量張量計算支撐高強度的並行演化探索。
> **頁面目標**
>
> 理解 EvoX 如何利用批量張量計算支撐高強度的並行演化探索，並把握張量化計算圖與開放解耦統一架構這兩條互為支撐的主線。
>
> 講解順序建議：
>
> 當種群從幾十擴展到成千上萬，演化計算的核心問題不再是「能否找到好解」，而是「能否在有限時間內評估足夠多的候選」。多樣性依賴吞吐，維持多樣性本質上是一道算力題。
>
> 張量化計算負責「跑得快」，統一架構負責「換得動」。
>
> 傳統串行 CPU 循環按個體執行「評價—記錄—更新」，會產生調度開銷高、算子碎片化、GPU 利用率不足三類代價；張量化做法是把種群維護、批量評價與狀態更新整體組織為批量張量操作，讓同一代甚至多代候選並行計算。例如 N 個候選解時，串行是逐個循環，張量化是把種群組織成一個張量，一次性完成批量評價與並行狀態更新，從而降低調度開銷、提升 GPU 佔用率。
>
> 只改寫循環還不夠，若算法、問題與調度邏輯耦合，換算法或換任務就要重寫。統一架構把算法、問題、工作流、Runtime 調度解耦，並配合異構算力調度對 CPU/GPU 做批量任務級管理，使同一套並行機制可復用到 MetaDE、AutoPSO 等方法演化場景。
>
> 左側是傳統串行 CPU 循環，逐個體串行、GPU 低佔用；右側是 GPU 批量張量計算，種群張量→批量評價→並行狀態更新，底部是開放解耦的統一底座，包含算法、問題、工作流、Runtime 調度。
**講授要點**
- EvoX 不只求解問題，還把產生候選解的方法本身納入演化對象。MetaDE 中外層算法演化內層算法的配置與策略，AutoPSO、EvoGO 進一步組合組件、利用歷史回饋學習候選生成方式，從「改參數」走向「改算法結構」。這類內外雙層演化天然要求大量內層任務被批量評價與狀態更新。 它改變的是計算的組織形式，把「種群—評價—更新」整條路徑批量化為張量操作，而不是替換某個算子或改變編碼方式。 性能剖析若出現「小算子過多、GPU 佔用率偏低、CPU 調度佔比偏高」，通常說明系統仍在逐個體串行循環，這是引入張量化計算圖的入口信號。 只做張量化，換算法或換任務要重寫
- 只做統一架構，缺少批量並行仍然快不起來。
**練習處理**
張量化的核心轉變是把種群維護、批量評價與狀態更新改寫為批量張量操作；傳統串行 CPU 循環的主要代價是調度開銷高、算子碎片化、GPU 利用率不足；統一架構開放解耦是為了讓並行機制可復用於不同算法與任務；同一代 N 個候選解時，關鍵收益是一次性完成批量評價與並行狀態更新；GPU 與大模型帶來的底座使批量計算從局部優化上升為系統級演化探索的基礎能力。答題回饋應引導學生回到「批量並行」和「解耦復用」兩個關鍵詞，避免誤選「壓縮種群」「近似評價」「固定工作流」等干擾項。
案例題要求把差分進化從單機串行遷移到批量並行底座。第 1 問的答題要點：逐個體串行帶來調度開銷高、算子碎片化、GPU 利用率不足；張量化通過把種群組織為張量、合併批量評價與狀態更新來緩解，同時保持變異、交叉、選擇語義不變。第 2 問的答題要點：統一架構按算法層、問題層、工作流層、Runtime 調度層拆分解耦；
算法層只描述候選生成與更新語義，問題層封裝批量評價介面，工作流層編排內外層任務，Runtime 調度層負責異構算力調度與批量任務級管理，從而讓同一底座復用於 MetaDE、AutoPSO 等方法演化場景。
**理解檢查**
可讓學生用自己的話說明「張量化計算圖解決什麼、統一架構解決什麼」，並舉例說明為什麼兩者必須配合。
> **過渡提示**
>
> 確認學生能區分「跑得快」與「換得動」之後，再進入下一頁關於系統級持續演化的具體案例或工程機制。
### 算法自身的進化：從求解答案到改進方法
*頁面 6*
> **頁面目標：** 理解將候選生成方法本身納入優化對象以實現算法自我進化的基本原理。
**講授要點**
- 內層求答案，外層改方法。看到「策略、參數、算子、組件被放進搜索」就是方法演化；看到「只有候選解在變、生成規則始終不變」就是傳統演化算法。
- 偏好信號先進入答案評價，再經過跨任務聚合與穩定性檢驗，才允許進入方法選擇。跳過這一步，外層就會追著一個討喜但不可復現的結果跑。
- 方法空間有多大？每輪要跑多少次內層任務？用什麼獨立任務集驗證外層改進真的泛化？這三筆帳算不清，雙層搜索很容易退化成更昂貴的隨機調參。
頁面目標
傳統演化算法在固定的生成機制下搜索，被優化的始終是候選解；方法演化則把產生候選解的方法本身也納入搜索對象，完成從「求解答案」到「改進方法」的進化。
講解順序
1. 先對比傳統演化算法與方法演化的差別，點明「被優化的對象」發生了位移。
2. 引出方法演化的定義，並說明 EvoX 沿這條路線推進，把候選生成的方法本身納入演化對象。
內層求答案，外層改方法。
4. 定位偏好優化應放在哪一層，強調兩類目標不能混淆。
5. 舉 MetaDE、AutoPSO 與 EvoGO 作為典型形態。
6. 收束到收益與代價，並處理練習與案例。
講授要點
選擇、交叉、變異等「如何產生答案」的規則由人預先寫好，搜索只在答案空間中移動。算力規模打開後，固定生成機制反而成為天花板。
算法不只輸出更好的答案，還通過外層搜索持續改進產生答案的策略、參數與組件。EvoX 是這條路線上的工作，例如把差分進化的變異策略與參數設置納入演化對象。
內層用當前方法求解具體問題，產生候選解；外層依據解品質、偏好信號、穩定性或成本等回饋，比較、選擇、更新下一輪使用的方法。被上移到搜索空間的對象不是某個解，而是候選生成機制本身，因此它成為可評價、可選擇、可更新的對象。
上層是「演化產生候選解的方法」，包含策略/參數/算子組件、外層演化搜索、改進後的生成方法；下層是「求解具體問題」，包含當前方法、候選解、解品質評價。兩條迴路分別表示外層結果回灌內層、解品質/偏好/成本回饋驅動兩層。板書時可先畫上下兩層，再用箭頭標出「更新生成方法」和「回饋信號」。
可以參與上層回饋，但必須把「評價當前答案」和「改進生成答案的方法」分開。把「這個解更討喜」直接讀成「這個策略更優」，就是用答案偏好冒充方法優劣，外層會被單次結果的噪聲牽著走。偏好信號先進入答案評價，再經過跨任務聚合與穩定性檢驗，才允許進入方法選擇。
MetaDE 讓外層演化差分進化的變異策略與參數，內層照常求解任務；AutoPSO 與 EvoGO 進一步組合粒子群組件、利用歷史回饋學習候選生成方式，實現從「改參數」到「改算法結構」的跨越。
收益是把算法設計從一次性人工調參推向可持續自適應。代價有三項：搜索空間膨脹，方法空間遠大於解空間；評價成本上升，每套候選方法都要跑內層任務，通常依賴 GPU 並行批量評估來攤薄；驗證複雜度增加，外層改進是否真正泛化，需要獨立的驗證設計。
練習線索與答案指導
1. 與傳統演化算法相比，方法演化在「被優化的對象」上最本質的區別是什麼？正確方向是：把「如何產生答案」的策略、參數與算子組件本身也放進搜索對象。若學生選「種群規模更大」或「取消適應度評價」，提示他們回到優化對象的位移：被優化的不再只是答案，而是產生答案的機制。
解品質、偏好信號、穩定性或成本等來自內層任務表現的回饋。若學生誤選「隨機噪聲」或「工程師手工指定」，引導他們追問：外層憑什麼判斷一套策略比另一套好？這個「憑什麼」就是回饋信號。
讓偏好信號參與上層回饋，但把「評價當前答案」與「改進生成方法」作為兩類目標分別處理。若學生把答案偏好直接當作方法優劣，提醒他們：偏好必須經過跨任務聚合與穩定性檢驗，才能從「答案偏好」升級為「方法判據」。
方法空間膨脹、每套方法都要付出內層評價成本，且驗證難度上升。可總結為空間、算力、驗證三重壓力；方法演化把搜索對象抬升一層，代價也隨之上移。
5. 關於 MetaDE 與 AutoPSO 哪項準確？正確方向是：MetaDE 用外層演化差分進化的變異策略與參數，內層仍負責具體任務的候選求解。AutoPSO 與 EvoGO 更進一步走向組件組合與結構層面的改進，方向是從改參數走向改結構。
案例處理
場景是團隊在 GPU 叢集上優化晶片佈局，已有差分演化求解器，但變異策略與參數依賴人工經驗，性能波動明顯，計劃引入 MetaDE 類雙層優化，並用用戶偏好引導搜索。
內層輸入是當前方法（變異策略與參數配置）和一個具體佈局問題實例，輸出是候選佈局及其解品質。外層輸入是內層任務表現的匯總統計，輸出是更新後的策略與參數配置。回饋信號要跨任務、跨重複運行聚合，例如多任務平均值、分位數或穩定性指標，不能取自某一次運行。原因是單個解的好壞高度依賴具體實例與隨機性，它衡量的是「這一次答案好不好」，而不是「這套方法好不好」；若直接用單次結果驅動外層，外層會被實例差異與噪聲主導。
內層可用偏好加權的評價函數篩選候選佈局；外層必須先轉化為跨任務穩定的比較準則，例如線長與擁塞指標的加權得分及其變異數，再用於挑選方法配置，避免把一次答案偏好直接當作方法優劣。
搜索空間膨脹可用參數分組、分層搜索、先粗後細控制規模；評價成本上升可用 GPU 並行批量評估、少量樣本代理評價與早停機制降低成本；驗證複雜度增加則要保留獨立驗證任務集並重複運行，檢查外層改進是否真正泛化。
理解檢查與過渡
內層求答案，外層改方法。看到「策略、參數、算子、組件被放進搜索」就是方法演化；看到「只有候選解在變、生成規則始終不變」就是傳統演化算法。確認學生能說明「被優化的對象變了」以及「偏好不能直接冒充方法優劣」之後，再進入下一頁的例題、應用或總結。
### MetaDE 與 AutoPSO：方法演化的雙層架構
*頁面 7*
> **頁面目標：** 掌握 MetaDE 和 AutoPSO 如何通過內外雙層優化實現算法變體與參數的自動演化。
> **頁面目標**
>
> 理解 MetaDE 與 AutoPSO 如何通過內外雙層優化架構實現算法配置與結構的自動演化，並掌握其代價結構與工程權衡。
> **講解順序**
>
> 算法不再只是找解，還要改進「自己怎麼找解」。
>
> 2. 展示內外雙層架構的通用抽象，強調外層搜索算法空間、內層求解目標任務、內層表現回傳為適應度信號形成閉環。
>
> 3. 分別講解 MetaDE 與 AutoPSO 兩條實現路徑，說明前者管配置層、後者管結構/組件層。
>
> 4. 分析雙層優化的代價乘法效應，引出預算分配、近似評價、早停、並行化等工程權衡。
>
> 從手工設計單一算法轉向設計可演化的算法空間與評價機制。
**講授要點**
- 方法演化（Meta-Evolution）把「產生候選的方法」本身作為優化對象。外層搜索的是算法配置、組件組合或策略，而不是任務解。 外層負責搜索算法空間（超參數、策略、組件組合等「算法的定義」）
- 內層用候選算法真正求解目標任務，得到可度量的表現
- 內層表現被聚合為適應度回傳外層，外層淘汰劣質配置、保留並變異優質配置，形成持續改進閉環。 保留差分進化作為內層求解器，把 DE 自身的配置交給外層搜索——變異策略、交叉率、縮放因子等隨問題與優化階段自適應調整。它回答「這套配置在當前任務階段該怎麼設」，屬於配置層的方法演化。 把 PSO 的核心參數與學習機制視為可組合組件——慣性權重、學習因子以及個體與群體學習機制的不同搭配，由外層自動搜索並組合出適配不同問題的 PSO 變體。它把「選算法」轉變為「搜算法結構」，實現從參數自適應到機制自生成的跨越。 MetaDE 偏配置與超參層的自動調優，AutoPSO 偏結構與組件層的自動組合，共同覆蓋從參數自適應到機制自生成的演化範圍。 雙層優化的關鍵代價在於乘法效應——外層每評估一個候選算法，往往需要多次內層運行（隨機性重複評估、多任務聯合驗證等），計算預算被顯著放大。實際計算量約等於「外層候選算法數量 × 每個候選的內層運行次數」。 預算分配、近似評價、早停、並行化。高效執行依賴張量化並行、Runtime 調度與算法可組合性
- 並行化能緩解牆鐘時間，但不會減少總計算量。 研究者交付的不再是一個固定算法，而是一套能讓算法持續自我改進的搜索空間與回饋規則。
**理解檢查**
可依次提問並給出答案要點：
1. 外層搜索的直接對象是什麼？
算法自身的配置、結構與組件組合。方法演化的本質是把算法自身當作被優化對象，外層在算法空間中搜索配置與結構，而不是直接搜索任務解。注意區分兩層：直接搜解的是內層；外層搜的是「用什麼算法、怎麼配置算法」。
2. MetaDE 中外層主要演化哪一組對象？
差分進化的變異策略、交叉率與縮放因子。MetaDE 讓 DE 的配置隨問題與階段自適應調整，屬於配置/超參層的方法演化，而非其他算法的結構。
3. AutoPSO 與 MetaDE 的分工，哪項描述最準確？
AutoPSO 側重參數與學習機制的自動組合，把「選算法」變為「搜算法結構」；MetaDE 側重配置層演化。二者互補：MetaDE 覆蓋配置與超參層，AutoPSO 覆蓋結構與組件層，共同構成從參數自適應到機制自生成的演化範圍，且都必須經過內層評估。
4. 關於雙層優化的代價結構，哪項正確？
外層每評估一次候選算法往往需要多次內層運行，預算被顯著放大，需預算分配、近似評價或早停。雙層架構的主要代價是乘法效應，並行化只能緩解、不能消除總開銷。
5. 採用方法演化雙層架構後，研究者角色的認知轉換是什麼？
從手工設計單一算法，轉向設計算法可被演化的空間與評價機制。交付的不再是固定算法，而是「可被演化的算法空間 + 適應度評價規則」，外層搜索與內層求解由此形成持續改進的閉環。雖然不再手工固定單一算法，但核心工作變成了設計搜索空間與評價機制，責任反而更重。
**練習處理**
案例「為持續變化的任務構建雙層演化服務」可在講解完架構與代價後使用，讓學生先獨立回答，再集體討論。
請說明內層與外層各自負責什麼，以及信號如何流動。
外層在算法空間中搜索候選算法——可以演化 DE 的變異策略、交叉率、縮放因子（MetaDE 路徑），也可以自動組合 PSO 的慣性權重、學習因子與學習機制等組件（AutoPSO 路徑）。內層用每個候選算法在當天目標任務上運行並評價，輸出可比較的表現；內層表現被聚合為適應度後回傳外層，外層據此淘汰劣質候選、保留並變異優質配置，持續迭代，形成「外層搜索算法空間、內層求解目標任務、表現回饋驅動改進」的閉環。
面對「外層評估一次需要多次內層運行」的預算壓力，給出至少兩條權衡措施並說明代價或風險。
①預算分配——為外層與內層分別設定計算額度並限制內層重複次數，代價是評價變異數上升、可能誤選；②近似評價——用資料子集或短程運行估計適應度，代價是信號噪聲大、最優候選可能被低估；③早停——對明顯劣質的候選提前終止內層運行，代價是可能過早淘汰後期表現良好的慢熱配置；④張量化並行與 Runtime 調度——批量並發內層運行，能顯著緩解牆鐘時間，但不會減少總計算量，且受顯存與調度開銷限制。回答需說明每項措施與它的代價或風險之間的對應關係，並體現「外層搜索規模 × 每次內層運行次數」這一乘法估算。
回饋語言：
正確。這個回答能聯繫本頁概念，並說明依據。
請回到本頁講解，找出關鍵證據或例子後再判斷。
注意區分「層」——直接搜解的是內層，外層搜的是「用什麼算法、怎麼配置算法」；MetaDE 的對象是差分進化自身的配置，而非其他算法的結構；雙層架構的主要代價是乘法效應，並行化只能緩解、不能消除總開銷；雖然不再手工固定單一算法，但研究者的核心工作變成了設計搜索空間與評價機制，責任反而更重。
> **過渡提示**
>
> 確認學生能用自己的話區分「配置層演化」與「結構/組件層演化」，並能說出內外層信號迴路和預算乘法效應後，再進入下一頁的例題、應用或總結。
### 超臨界翼型設計的多目標實踐案例
*頁面 8*
> **頁面目標：** 學習如何利用 EvoX 處理複雜工程約束並在翼型設計中生成多樣化權衡方案。
> **頁面目標**
>
> 理解超臨界翼型設計為何是多目標問題，並掌握如何利用 EvoX 在嚴格工程約束下生成多樣化權衡方案。
> **講解順序**
>
> 超臨界翼型設計是 EvoX 在真實工程中的多目標實踐。翼型的彎度、厚度、後緣等外形參數相互耦合，改變外形會同時牽動多項氣動指標。
>
> 改善一項指標往往以另一項指標為代價，因此不能按單目標尋優處理，需要多目標權衡。
>
> 升力、迎角、厚度等要求限定了可行設計域，搜索必須在滿足約束的前提下展開，才能保證候選方案工程可用。
>
> EvoX 生成的是兼顧各項指標的多樣化候選方案組，而不是唯一最優解；候選組供領域專家比較不同收益與代價，並做出取捨。
>
> 該案例把真實複雜問題轉化為可探索、可評估的過程，在約束與目標衝突中尋找可解釋的權衡方案。
**講授要點**
- 超臨界翼型外形變化影響多項氣動指標，目標之間常存在衝突，需要多目標權衡。 設計需滿足升力、迎角與厚度等多項嚴格約束，搜索應在可行設計域內展開。 生成多樣化候選方案，幫助專家評估不同收益與代價並做出取捨。 先在翼型參數空間（彎度、厚度、後緣）中持續探索，再逼近多目標權衡前沿（指標A與指標B），最終形成候選方案組。 超臨界翼型、多目標權衡、可行設計域、候選方案組、EvoX。
> **練習線索**
>
> - 多目標問題的根源、約束的作用、EvoX 的實踐輸出、多樣化候選的意義、方法價值。正確理解應落在：外形參數同時影響多項指標導致目標衝突
> - 約束限定可行設計域
> - 輸出是多樣化候選方案組
> - 不同候選代表不同收益與代價
> - 方法價值在於把真實複雜問題轉化為可探索、可評估的過程。
**練習處理**
若學生誤選「只需優化升力」「求唯一最優解」，提示回到外形參數耦合與目標衝突。
若學生誤選「約束可隨意放寬」或「與工程可用無關」，提示約束界定可行設計域，不能隨意放寬。
若學生誤選「單一最優翼型」或「隨機外形」，提示輸出應是兼顧各項指標的多樣化候選方案組。
正確，這個回答能聯繫本頁概念並說明依據。
請回到本頁講解，找出關鍵證據或例子後再判斷。
**課堂活動**
因為外形參數變化會同時影響多項氣動指標，改善一項常以另一項為代價，需多目標權衡；約束限定了可行設計域，保證候選方案工程可用。
**理解檢查**
EvoX 在超臨界翼型設計中，如何在嚴格約束下生成多樣化候選方案組，供專家評估收益與代價。教師根據回答補充遺漏的關鍵詞：目標衝突、可行設計域、候選方案組、多目標權衡。
> **過渡提示**
>
> 確認學生能區分單目標尋優與多目標權衡，並能說明候選方案組的用途後，再進入下一頁的例題、應用或總結。
### 跨越生命週期的挑戰：上下文耗盡與專案級持久化
*頁面 9*
> **頁面目標：** 理解大模型上下文限制與真實工程項目持續數月或數年之間的矛盾。
**講授要點**
- 單次上下文是工作台，專案倉庫才是長期記憶。不要把種群狀態、失敗配置和決策理由只留在會話視窗裡；會話關閉前應寫入專案級工件，下一次會話先讀取再繼續。
- 可繼承的持久化要求工件可版本化、可檢索、可解釋：程式碼、測試、實驗記錄、決策日誌、評估指標與驗收結論要能回答為什麼這樣選、哪些已失敗、哪些衝突仍在。
- 上層 Agent 分解目標，下層 Agent 實現與測試。每次會話結束前設置檢查點：更新決策日誌與評估指標；新會話啟動時先繼承檢查點，再決定局部行動，從而跨越多個有限生命週期。
> **頁面目標**
>
> 理解大模型 Agent 的上下文限制與真實工程項目持續數月乃至數年之間的矛盾，建立專案級持久化的必要性。核心判斷：單次上下文視窗 C最大 是有限資源，專案生命週期 T專案 可持續數月甚至數年，因此 T專案 ≫ C最大。真正的困難不是單次推理能力不足，而是經驗無法跨越 Agent 生命週期。
>
> 講解順序
>
> 單次 Agent 上下文只能容納當前目標、局部觀測與近期推理；會話關閉後狀態清空，臨時結論與經驗不再可用。若缺少持久化，後續會話只能重複探索。
>
> 專案級持久化。把失敗配置、權衡過程、候選方案與驗收結論外化為持續存在的專案級工件，包括程式碼、測試、實驗記錄、決策日誌、評估指標與驗收結論。後續 Agent 不必從零開始，而是讀取前序經驗，判斷哪些方向已驗證、哪些衝突未解決、哪些指標已達標。
>
> 演化對象不再只是單次數值參數或候選解，而是持續存在、可版本化、可繼承的軟體世界。每次會話產生的新工件改變這個世界的狀態，下一次會話在更新後的世界繼續演化，於是優化過程變成專案級持續演化。
>
> 多個生命週期有限的 Agent 可協同工作，上層執行者理解目標並分解任務，下層執行者完成局部實現與測試，必要時繼續遞迴拆解。關閉前寫入關鍵狀態，新 Agent 啟動後先讀取專案記憶，再決定局部行動。
>
> 長週期專案常有目標衝突，例如性能、成本、魯棒性難以同時最優；回饋也可能稀疏，一次實驗要等數小時甚至數天。持久化的決策日誌與評估指標能把稀疏回饋轉化為可繼承經驗，避免後續 Agent 反覆踩坑。
>
> 講授要點
>
> 單次上下文是工作台，專案倉庫才是長期記憶。不要把種群狀態、失敗配置和決策理由只留在會話視窗裡；會話關閉前應寫入專案級工件，下一次會話先讀取再繼續。
>
> 持久化不是日誌堆積。可繼承的持久化要求工件可版本化、可檢索、可解釋：程式碼、測試、實驗記錄、決策日誌、評估指標與驗收結論要能回答為什麼這樣選、哪些已失敗、哪些衝突仍在。
>
> 每次會話結束前更新決策日誌與評估指標；新會話啟動時先繼承檢查點，再決定局部行動，從而跨越多個有限生命週期。
>
> 專案級持續演化，即把產生候選、評估候選、記錄權衡與驗收結論的過程，從單次 Agent 上下文遷移到專案級持久化工件中，使專案跨越多個 Agent 生命週期持續迭代。
>
> 練習線索
>
> 應選「上下文視窗有限，且會話關閉後狀態與經驗不可依賴」。回饋時強調：硬邊界在長度有限與會話關閉後的狀態清空，不是參數規模、並行度或目標函數。
>
> 應選「程式碼、測試、實驗記錄、決策日誌、評估指標與驗收結論」。回饋時說明這些工件共同構成專案記憶。
>
> 應選「從單次數值參數/候選解擴展為持續存在、可版本化、可繼承的軟體世界」。回饋時區分訓練範式變化與演化對象邊界變化。
>
> 應選「上層理解目標並分解任務，下層完成局部實現與測試，必要時遞迴拆解」。回饋時強調跨生命週期連續性由專案級持久化保障。
>
> 應選「每次會話關閉後種群狀態、失敗配置與決策理由丟失，後續 Agent 重複探索」。回饋時說明缺少持久化不會自動解決目標衝突或擴大上下文。
>
> 正確時可肯定「能聯繫本頁概念並說明依據」；錯誤時請學生回到本頁講解，找出關鍵證據或例子後再判斷。
>
> 練習處理
>
> 目標包含氣動效率、結構強度與製造成本，三者衝突，模擬回饋稀疏，團隊希望多個短生命週期 Agent 連續協作。第一問要求說明為何不能只把專案記憶放在單次上下文，並列出至少三類應持久化工件。回答要點：單次上下文視窗有限且會話關閉後狀態清空，而專案跨月，T專案 ≫ C最大；只依賴單次上下文會丟失種群狀態、模擬結果、失敗配置、指標衝突與決策理由；應持久化至少包括程式碼與代理模型訓練腳本、測試與評估指標記錄、實驗記錄與失敗配置、決策日誌與權衡理由、候選方案與驗收結論。
>
> 會話啟動先讀取決策日誌、評估指標、實驗記錄與候選方案，恢復種群狀態與未解決衝突；會話中寫入新的代理模型、模擬結果、候選評估與權衡分析；關閉前更新決策日誌，記錄本輪失敗配置、指標衝突、捨棄理由與下一步建議並提交版本化；後續會話通過讀取這些工件繼承失敗配置與決策理由，避免重複探索。
**理解檢查**
請學生用自己的話總結「為什麼專案記憶不能只保存在單次 Agent 上下文中」，並說出至少三類專案級持久化對象。過渡提示：確認學生能說出本頁的核心關係——T專案 ≫ C最大，專案級持久化把經驗外化為可繼承的軟體世界——再進入下一頁的例題、應用或總結。
### Genesis 架構與軟體世界的沉澱範式
*頁面 10*
> **頁面目標：** 掌握 Genesis 如何讓專案程式碼跨越生命週期持續累積與演化。
> **頁面目標**
>
> 幫助學生理解 Genesis 如何把智能從易失的會話過程，重新錨定到可累積的軟體世界，使專案程式碼與工程結果能夠跨越單個上下文視窗與單個生命週期持續累積、演化與繼承。
> **講解順序**
>
> 先拋出「會話是易失的，倉庫才是長期記憶」這一判斷標準，再依次展開沉澱範式的本質差異、四類可沉澱資產的分工、介面穩定的前提、沉澱閉環與驗收守門、跨生命週期繼承，最後用一句話點明 EvoX 與 Genesis 的分工邊界。
**講授要點**
- 1. 判斷一次工作是否有沉澱價值，只問一個問題——下一個人能否在不來問任何問題的前提下復現它？若不能，它還沒有成為資產。對話式工作流隨上下文結束而蒸發，產出停留在「這一次會話」裡
- 軟體世界以倉庫、版本與工件為介質，天然具備累積性。Genesis 正是把這一介質正式化為演化系統的長期記憶層，它記住的不是對話，而是被驗證過的工程結果。 程式碼管「能跑」，方法管「怎麼選」，狀態管「到哪了」，證據管「憑什麼信」。程式碼承載可執行能力，是能被直接運行、復現的求解過程
- 方法承載算法與策略決策，例如雙層演化的配置選擇與組件組合方式
- 狀態承載專案上下文與運行記憶，記錄當前進度、約束與已知邊界
- 證據承載實驗記錄與驗收結論，回答結果為什麼可信。四者缺一，沉澱即不可復現或不可繼承：只有程式碼而沒有證據，結論無法被信任
- 只有方法而沒有狀態，繼承者不知從何處繼續。因此四類資產必須成套固化，而不是各自散落。 3. 沉澱的前提是介面穩定。只有當模組邊界與契約相對穩定時，新增產出才是資產
- 否則每一次改動都會牽動周圍實現，沉澱會迅速轉化為維護負債。這與 Genesis 的開放解耦底座設計互為條件：穩定介面讓沉澱可被安全繼承，解耦讓繼承不必重寫歷史。沉澱之前先固化契約，往往比多寫幾份文件更有價值。 探索 → 產出 → 嚴格驗收 → 固化為資產 → 下一輪演化直接繼承。其中驗收是沉澱的守門人——未經檢驗的產出不進入資產層，從而避免把噪聲、偶然現象與錯誤結論固化成專案「經驗」。沒有守門人的沉澱，倉庫會越長越不可信。 5. 跨生命週期繼承的關鍵在於資產與具體運行實例解耦，使新會話、新 Agent、新任務都能以「讀取倉庫」的方式恢復專案級認知，而不依賴重放歷史對話。繼承成本從「重新講述一遍專案」降為「檢出並載入」，專案認知也不再被某個上下文視窗的容量所限制。 Genesis 負責「沉澱什麼、以什麼形式沉澱、如何被繼承」
- 多 Agent 協作與遞迴任務拆解負責「如何生產產出」
- 驗收與歷史繼承機制負責「產出如何被判定為可信」。三者疊加，才構成完整的專案級持續演化能力——缺任何一環，專案都只能原地重複。
**關鍵詞覆蓋**
- Genesis、專案級持續演化、EvoX 系統架構、程式碼／方法／狀態／證據、驗收守門人、跨生命週期繼承。 本頁以「Genesis 三層架構與沉澱閉環示意圖」組織內容，左側自上而下分別是資產層（程式碼·方法·狀態·證據）、沉澱機制（版本化·驗收網關·檢索與繼承）與 EvoX Runtime（張量化並行·異構算力·算法模組）
- 右側環形圖呈現探索、產出、驗收、固化、復用、再演化的閉環，並標註「資產隨生命週期遞增而增厚」。頁面還附有三條提示：別把會話當記憶、四類資產缺一不可、介面不穩沉澱變負債。講解時可借助該圖引導學生順著箭頭複述閉環，再指出驗收位於產出之後、固化之前。
> **練習線索**
>
> - 頁面配有五道選擇題與一個案例。 第 1 題指向可累積的軟體世界（倉庫、版本與工件），若學生誤選上下文視窗，提示回到「會話結束就什麼都沒留下」這一開始
> - 第 2 題考四類資產職責對應，正確項為程式碼承載可執行能力
> - 第 3 題考資產與維護負債的分界，正確項為「模組邊界與契約相對穩定」，需強調關鍵不在產出多少或工具多新
> - 第 4 題考閉環中的守門人，正確項為嚴格驗收
> - 第 5 題考跨生命週期繼承，正確項為「資產與運行實例解耦，新會話可通過讀取倉庫恢復專案認知」。答對時肯定其能聯繫本頁概念並說明依據，答錯時請其回到講解中找出關鍵證據或例子再判斷。 超臨界翼型多目標探索結束後，團隊手上留下可運行的 MetaDE 雙層配置與代理模型訓練腳本、評估指標定義、覆蓋翼型參數區間與幾何工況約束的中間狀態，以及本輪驗收結論。第一問要求按程式碼、方法、狀態、證據四類整理資產，並說明驗收的守門作用——只有通過嚴格驗收的產出才允許進入資產層，四類資產必須成套固化，缺一即不可復現或不可繼承。第二問要求對比「重放歷史對話」與「讀取倉庫」：前者依賴上下文視窗、成本隨專案線性增長、對話一旦截斷認知即丟失
> - 後者把繼承成本降為檢出並載入，結果可版本化、可復現、可審計，本輪重複試錯的成本因此沉澱為下一輪的復用起點。
**課堂活動**
請學生用一個貼近自身經驗的例子複述本頁內容，並說明該例子與「下一個人能否在不來問你的前提下復現它」這一判斷標準之間的關係。
**理解檢查**
隨機請一名學生用自己的話總結本頁重點，教師根據回答補充遺漏的關鍵詞，重點確認學生能同時說出「四類資產的分工」與「驗收是沉澱的守門人」兩點。
> **過渡提示**
>
> 確認學生能說出本頁的核心關係——沉澱發生在穩定契約之上，由驗收把關，最終以讀取倉庫的方式被繼承——之後再進入下一頁的應用或總結。
### 多 Agent 協作與遞迴任務拆解的工程模式
*頁面 11*
> **頁面目標：** 理解多生命週期有限的 Agent 如何協同完成複雜專案的開發與任務分解。
**講授要點**
- 拆解任務時，優先問「這一層要交出什麼可驗證的東西」，而不是先想「交給哪個 Agent」。交付物（資料集、介面、檢查點、評估報告）定義清楚之後，職責邊界與層級劃分自然會浮現。
- 遞迴拆解的停止點不是「拆到最小」，而是「拆到可執行、可驗證、能在單個 Agent 的一次上下文內閉環完成」。拆得過淺會超出下層能力，拆得過深會帶來額外的協調與交接損耗。
- 職責重疊會讓多個 Agent 重複實現同一件事，並產出互相衝突的結果。用明確的介面定義與驗收標準把邊界固化下來，同時約定好哪些內容允許下層自行決定、哪些必須上報父任務裁決。
頁面目標
當單個執行者的上下文容量與處理能力不足以承載整個工程目標時，如何把一個大問題降解為一組可交付的小問題，並讓各層協作結果可驗證、可回收。
講解順序
先用「一個大問題降解為一組可交付小問題」點題，再沿三層結構展開，隨後解釋遞迴拆解的動因與終止條件，最後落到任務樹的雙向交接關係與三條工程提示。講解時可配合圖示逐層向下指認節點，幫助學生把抽象分工與具體任務樹對應起來。
講授要點
1. 三層結構與各自職責。上層執行者面向整體目標，回答「要做什麼」，輸出可委派的子任務、約束條件與驗收標準；中層執行者承接仍然過大的子任務繼續遞迴拆解，把鬆散的大目標收斂為穩定的任務層級；下層執行者在職責邊界內完成局部實現與測試，產出可驗證結果並向上交付，形成局部閉環。圖示中上層 Agent 分出任務模組 A、B、C，模組 B 因仍然過重被繼續拆為子任務 B1、B2，四個葉節點最終各自落到下層 Agent 的局部實現與測試。
上層站在根節點，產出的是可委派任務與驗收標準，而不是親自完成實現。
2. 為什麼必須遞迴拆解。執行者的上下文視窗、可調用工具與單次可處理的任務規模都是有限的。若讓單個執行者長期持有整個專案的全部上下文，成本會隨規模上升，還容易出現目標漂移、狀態污染與關鍵信息被稀釋。遞迴拆解把這部分壓力分散到各層：每個執行者只需理解自己那一層的目標與約束，複雜目標被逐層降解為可執行、可交付的工作單元，整體一致性則由任務層級來保證。
任務樹與雙向交接。父任務與子任務構成一棵遞迴任務樹。向下流動的是任務委派——目標、邊界約束與驗收標準；向上流動的是結果回收——產出物、驗證證據與尚未解決的問題。協作能否真正成立，取決於三件事：任務層級是否清晰、職責邊界是否互斥、交接產物（介面定義、資料集、測試用例、檢查點）是否被明確約定。缺少其中任何一項，多個執行者就會退化為重複勞動與相互衝突的結果。
拆解的深度、委派的粒度以及結果回收的策略，同樣可以被持續評估與調整。當某個子任務反覆返工這類回饋反過來影響下一次如何拆解時，這套協作流程就進入了自我改進的循環。
5. 工程提示。遞迴拆解的停止條件不是「拆到最小」，而是「拆到可執行、可驗證、能在單個執行者的一次上下文內閉環完成」。拆得過淺會超出下層處理能力，拆得過深則會帶來大量協調開銷與交接損耗。可以先定交付物，再決定由誰做；邊界不清往往是協作最大的成本。
練習處理
本頁配有一組概念判斷題，建議在學生答完後要求其指出依據，而不只是說出選項。
正確答案是「理解整體目標，並將其分解為可委派的子任務與驗收標準」。若學生選錯，提示其回到根節點的定位——產出的是任務與驗收標準，而非程式碼本身。
正確答案是「當子任務仍然過於複雜、超出單個處理範圍時」。需強調遞迴不是無條件動作，觸發條件是子任務仍然過大、無法在一次處理中完成並驗證。
如果只有任務下發會怎樣？如果只有結果回收又會怎樣？由此說明協作必須雙向。
正確答案是「把上下文與處理壓力分散到各層，降低單點上下文負擔與目標漂移風險」。核心詞是「分散」，而不是「保證一次成功」。
正確答案是「讓葉節點保留可執行、可交付的工作單元，並明確介面與測試產出」。可順勢複習：邊界模糊或取消層級，都會導致重複實現與結果衝突。
課堂活動
案例研究「智能客服質檢系統的協作交付」適合做為小組活動。先讓學生畫出遞迴任務樹：根節點負責整體目標理解並產出 A、B、C 三個子任務及驗收標準；模組 B 由中層繼續拆為 B1、B2，並明確兩者介面；葉節點為 A、B1、B2、C 四類工作單元。再請各組列出向下與向上兩個方向的交接產物，例如資料介面規範與清洗後的對話資料集、特徵字典與標註規範、模型檢查點與驗證報告、評估指標與部署配置，並說明葉節點為何已滿足停止條件。
針對 B1 發現「標註規範」與「評估指標」衝突的追問，可引導學生歸納處理原則：衝突上升裁決，不自行修改驗收標準；介面與標準保持單一來源，由上一層統一維護；裁決前仍保持局部閉環可驗證；裁決結果反向更新任務樹與相關子任務輸入；全程記錄衝突、裁決依據與最終口徑以便追溯。
理解檢查
上層負責什麼、遞迴在什麼條件下繼續、上下兩個方向各傳遞什麼信息。若能同時說出停止條件與「先定交付物再定分工」，即可認為本頁掌握到位。
過渡提示
確認學生能區分「分解任務」與「親自實現」、並能說清任務樹的雙向交接之後，再進入下一頁關於驗證與沉澱機制的討論，以便把本頁的分工模式與後續的編譯、測試、驗收環節銜接起來。
### 嚴格的驗收與歷史繼承機制
*頁面 12*
> **頁面目標：** 掌握如何通過編譯、測試與驗收網關將有效修改沉澱為專案歷史。
> **講解順序**
>
> 先用一句話點明"看到任何「自動生成並自動改進」的系統，先問三句：Agent 的產物預設是什麼身份（候選？）、要過哪些驗證才能被採納（驗收？）、採納之後變成誰的基礎（基線？）。把這三件事分開，機制的整體邏輯就不會亂。"，再結合頁面上的示例、圖示或關鍵詞解釋它為什麼重要。
**講授要點**
- Agent 的產物預設是什麼身份（候選？）、要過哪些驗證才能被採納（驗收？）、採納之後變成誰的基礎（基線？）。把這三件事分開，機制的整體邏輯就不會亂。
- 編譯 → 測試 → 行為檢查 → 上層驗收，是「成本從低到高」的下坡路：越便宜越靠前，越貴越靠後。記住「便宜的先篩、貴重的後審」，就不會把上層評審浪費在海量垃圾候選上。
- 驗收通過不等於真的更好。測試覆蓋不足或行為檢查缺失時，閘門會放行有害修改。養成兩個習慣：為關鍵行為補齊回歸用例與容差定義
- 隨時保留可觀測指標與人工抽檢，作為標準不完備時的最後防線。
嚴格的驗收與歷史繼承機制
11
AI999
Genesis 與軟體世界的沉澱
由 Agent 自動生成的修改，憑什麼可以寫進專案主幹？嚴格的驗收與歷史繼承機制把 生成 與 採納 徹底解耦——Agent 提交的任何程式碼都只是 候選修改（candidate patch），必須先通過一組驗證閘門，才有資格被承認專案歷史的一部分。
候選修改 → 四層驗收閘門 → 主幹 / 拒絕 分流 候選修改隊列 Agent 提交 · 預設不可信 候選 A 待驗證 候選 B 待驗證 候選 C 待驗證 候選 D 待驗證 ① 編譯閘門 語法與介面可構建 · 成本最低、淘汰最快 ② 測試閘門 單元 / 整合測試全綠 · 覆蓋已有契約 ③ 行為檢查閘門 語義一致 · 數值容差與等價性 ④ 上層驗收 性能 · 加速比 · 可維護性 拒絕 · 失敗檔案區 · 保留為負樣本與診斷素材 · 隔離存放，不污染主幹 · 拒絕本身即噪聲過濾 · 避免重複探索同一死路 主幹版本歷史（單調累積） 基線 v3 · 可繼承、可追溯 基線 v2 基線 v1 歷史繼承回饋：已接納基線成為後續 Agent 的執行起點 候選性預設原則 Agent 的輸出預設被視為 不可信輸入：它在權限、存儲與引用上與已接納版本嚴格隔離，既不能直接讀寫主幹，也不能被其他模組當作穩定依賴。
這條原則的唯一目的，就是杜絕「生成即入庫」。只有在通過全部閘門之後，候選修改才獲得與主幹同等的地位。四層遞進過濾：成本遞增、盡早失敗 編譯：語法與介面層面可構建。成本最低、淘汰最快，先把明顯不成立的修改擋在門外。測試：單元測試與整合測試通過，覆蓋已有契約。行為檢查：語義與行為一致性，包含數值容差、等價性與回歸對比，專門防範「測試通過但行為漂移」。上層驗收：面向任務目標與工程約束的最終裁決，包含性能、加速比、可維護性等判斷。
閘門按代價從低到高排列，使絕大多數無效修改在廉價階段被截斷，把昂貴的上層評審留給少量高品質候選——這正是「盡早失敗」的經濟學。拒絕的價值與歷史繼承 未通過的嘗試不進入主幹，但可以保留為 失敗檔案 / 負樣本，用於診斷、去重與防止重複探索——拒絕本身即是一次噪聲過濾。而通過驗收的修改成為新的 基線版本，後續執行者在此基礎上繼續演化，形成單調累積的演化鏈，而不是每輪從零重來。作為多 Agent 協作與遞迴任務拆解的合併規則與品質契約，驗收網關定義了「誰能寫入歷史」，從而決定協作結果是收斂還是熵增。
在編譯器重構與科學軟體升級等強正確性約束場景中，這套機制展現出極高的可靠性，並帶來可觀的運行加速比。失效邊界 驗收標準本身的完備性會成為新的瓶頸：測試覆蓋不足或行為檢查缺失時，閘門會放行「通過驗收但實際有害」的修改。因此需要用可觀測指標與人工抽檢兜底，並持續補強回歸用例與容差定義。
在嚴格驗收機制中，Agent 提交的程式碼預設處於什麼地位？
由提交方自行判定是否可用的成品
可直接合併入主幹的正式版本
待驗證的候選修改，與已接納版本在權限、存儲與引用上嚴格隔離
僅用於日誌記錄、不參與任何流程的副產品
候選性預設把 Agent 輸出視為不可信輸入，與主幹嚴格隔離，從制度上避免「生成即入庫」。
未經驗證的輸出不應該擁有與已接納版本相同的地位。
正確。這個回答能聯繫本頁概念，並說明依據。
請回到本頁講解，找出關鍵證據或例子後再判斷。
四層驗收閘門按什麼順序排列，其設計意圖是什麼？
按成本從高到低，優先把資源投入最昂貴的上層評審
按候選提交時間排序，先到先驗
按隨機順序，以增加驗證的多樣性
編譯 → 測試 → 行為檢查 → 上層驗收，讓絕大多數無效修改在廉價階段被截斷
便宜閘門負責大規模淘汰，昂貴閘門只面對少量高品質候選。
想一想哪一層最貴、哪一層最快。閘門順序應當讓昂貴的評審盡量少遇到垃圾候選。
行為檢查（第三層閘門）主要防範哪一類問題？
單元測試用例數量寫得不夠多
「測試通過但行為漂移」，即新舊實現在語義或數值輸出上不一致
程式碼語法錯誤導致根本無法編譯
主幹版本歷史佔用過多存儲空間
行為檢查用數值容差、等價性與回歸對比來比對語義一致性，攔截測試覆蓋不到的行為漂移。
編譯層管「能不能構建」，測試層管「契約是否滿足」，行為檢查關注的是更隱蔽的語義漂移。
被閘門拒絕的候選修改，其價值應如何理解？
應徹底刪除，以免佔用存儲並干擾後續判斷
應直接寫入主幹，作為反面對照保留
可保留為失敗檔案 / 負樣本，用於診斷、去重與防止重複探索
應不加修改地反覆重投，直到自動通過為止
失敗嘗試被隔離在主線之外，但仍可作為負樣本使用——拒絕本身就是一次噪聲過濾。
關鍵區別在於它是否被允許污染主幹，以及能否轉化為可復用的診斷信息。
下列哪種情況最可能讓驗收網關放行「通過驗收但實際有害」的修改？
測試覆蓋不足或行為檢查缺失，使驗收標準本身不完備
上層驗收同時評估性能、加速比與可維護性
候選修改隊列中同時存在多個不同 Agent 的提交
失敗檔案被長期保留用於診斷
閘門只能攔住它能檢測的問題；驗收標準不完備時，需要通過可觀測指標與人工抽檢來兜底。
風險往往不來自提交方，而來自驗收標準自身的覆蓋盲區。
編譯器內核重寫補丁的驗收
閱讀場景，回答下面的兩個問題。
某團隊用多 Agent 協作重構某編譯器內核。Agent X 提交了一版內核重寫補丁，聲稱可把某基準的運行速度提升約 1.4 倍。系統按「嚴格的驗收與歷史繼承機制」處理該補丁：補丁先進入候選修改隊列，隨後依次接受編譯、測試、行為檢查與上層驗收；通過則寫回主幹並成為下一代 Agent 的起點，未通過則進入隔離的失敗檔案區。
1. 請按順序說明該補丁要依次通過哪些檢查，並解釋為什麼把上層驗收放在最後。
編譯 → 測試 → 行為檢查 → 上層驗收。編譯檢查語法與介面層面能否構建，成本最低、淘汰最快；測試檢查單元/整合測試是否全綠，覆蓋已有契約；行為檢查比對新舊實現的語義一致性，包括數值容差、等價性與回歸對比；上層驗收則面向任務目標與工程約束做最終裁決，判斷性能、加速比與可維護性。把上層驗收放在最後，是因為它代價最高、需要人工或高層評審介入，只有在前面幾關把絕大多數無效候選截斷之後，才能把這份昂貴資源集中投給少量高品質候選，實現「成本遞增、盡早失敗」。
在部分輸入上新舊實現的數值輸出超出約定容差。此時系統應如何處理它？它是否仍有價值？若移除行為檢查會發生什麼？
該補丁不得寫入主幹，應被拒絕並轉入隔離的失敗檔案區；由於它在編譯與測試階段均已通過，恰好說明它屬於「測試通過但行為漂移」的危險類型。它仍然有價值：可作為負樣本保留，用於診斷差異來源、避免後續 Agent 重複同一死路，並提示團隊補充回歸用例或重新審視容差定義。若移除行為檢查，這類補丁會在測試全綠的情況下直接進入上層驗收甚至寫回主幹，把行為漂移引入歷史基線，這正是該機制的失效邊界——閘門只能攔住它能檢測的問題，因此需要可觀測指標與人工抽檢兜底。
候選、驗收、基線
Agent 的產物預設是什麼身份（候選？）、要過哪些驗證才能被採納（驗收？）、採納之後變成誰的基礎（基線？）。把這三件事分開，機制的整體邏輯就不會亂。
閘門順序記成一條下坡路
編譯 → 測試 → 行為檢查 → 上層驗收，是「成本從低到高」的下坡路：越便宜越靠前，越貴越靠後。記住「便宜的先篩、貴重的後審」，就不會把上層評審浪費在海量垃圾候選上。
閘門只能攔住它能測的問題
驗收通過不等於真的更好。測試覆蓋不足或行為檢查缺失時，閘門會放行有害修改。養成兩個習慣：為關鍵行為補齊回歸用例與容差定義；隨時保留可觀測指標與人工抽檢，作為標準不完備時的最後防線。
step-1
掌握如何通過編譯、測試與驗收網關將有效修改沉澱為專案歷史。
lesson_6
lesson_6_slide_11
來自 EvoClass 草稿
> **頁面目標**
>
> 掌握通過編譯、測試與驗收將有效修改沉澱為專案歷史的機制
**講授要點**
- 嚴格的驗收與歷史繼承機制
- Agent 提交的程式碼僅作為候選修改，必須通過編譯、測試、行為檢查和上層驗收後，才能進入被接納的專案版本。失敗嘗試可被拒絕，而通過驗證的成果則成為後續執行者的歷史基礎。在編譯器重構與科學軟體升級中，這種機制展現了極高的可靠性與運行加速比。
**講授要點**
- 嚴格的驗收與歷史繼承機制
- Agent 提交的程式碼僅作為候選修改，必須通過編譯、測試、行為檢查和上層驗收後，才能進入被接納的專案版本。失敗嘗試可被拒絕，而通過驗證的成果則成為後續執行者的歷史基礎。在編譯器重構與科學軟體升級中，這種機制展現了極高的可靠性與運行加速比。 嚴格的驗收與歷史繼承機制
- Agent 提交的程式碼僅作為候選修改，必須通過編譯、測試、行為檢查和上層驗收後，才能進入被接納的專案版本。 lesson_id_distribution 86818163433546df25555ab4cb1c2d59fc1effedc37a25c4e84b74b7d294e704
**資料依據**
來自 EvoClass 草稿
> **素材線索**
>
> - 掌握通過編譯、測試與驗收將有效修改沉澱為專案歷史的機制
> - 嚴格的驗收與歷史繼承機制
> - Agent 提交的程式碼僅作為候選修改，必須通過編譯、測試、行為檢查和上層驗收後，才能進入被接納的專案版本。失敗嘗試可被拒絕，而通過驗證的成果則成為後續執行者的歷史基礎。在編譯器重構與科學軟體升級中，這種機制展現了極高的可靠性與運行加速比。
> - Agent 提交的程式碼僅作為候選修改，必須通過編譯、測試、行為檢查和上層驗收後，才能進入被接納的專案版本。
**課堂活動**
請用一個貼近學生經驗的例子複述本頁內容，並讓學生說出這個例子和"看到任何「自動生成並自動改進」的系統，先問三句：Agent 的產物預設是什麼身份（候選？）、要過哪些驗證才能被採納（驗收？）、採納之後變成誰的基礎（基線？）。把這三件事分開，機制的整體邏輯就不會亂。"之間的關係。
> **對應目標**
>
> - 理解多 Agent 協作與遞迴任務拆解的工程模式
> - 掌握通過編譯、測試與驗收將有效修改沉澱為專案歷史的機制
**理解檢查**
隨機請一名學生用自己的話總結本頁重點，授課者根據回答補充遺漏的關鍵詞。
> **過渡提示**
>
> 確認學生能說出本頁的核心關係後，再進入下一頁的例題、應用或總結。
### 課堂活動：模擬多 Agent 協作與自動化驗收網關
*頁面 13*
> **頁面目標：** 通過模擬演練加深對多 Agent 協作開發和自動化驗收機制的理解。
> **頁面目標**
>
> 通過一次課堂模擬演練，理解多 Agent 協作開發中的任務分工、候選修改匯合，以及自動化驗收網關如何攔截不合格修改；重點是跑通「協作開發—自動驗收—歷史繼承」的工程閉環，而不是讓 Agent 互相討論出正確。
> **講解順序**
>
> 把課堂小組分成規劃/拆解 Agent、實現 Agent、測試生成 Agent、審查/協調 Agent。同一任務可以產生多個候選修改，再由驗收網關統一裁決。
>
> 任務拆解、並行實現、自動驗收、歷史繼承。任務拆解要把目標拆成可獨立驗證的子任務，例如「介面校驗—算法修復—回歸測試」；並行實現階段，多個實現 Agent 提交候選補丁，測試 Agent 生成邊界用例；自動驗收階段運行自動化測試、靜態檢查與契約檢查，由網關按可執行標準判定；歷史繼承階段，通過的修改合入歷史基線，被拒修改保留失敗原因與復現信息，供重試。
>
> 左側是遞迴任務拆解，中間是多 Agent 候選修改，右側是自動化測試與驗收網關。候選匯合後進入網關，通過則合入歷史基線，拒絕則打回並附可復現回饋，回饋再回流給實現與測試環節。
>
> 判據必須可執行，不能停留在「看起來正確」。重點攔截不滿足介面約定、引入回歸、未覆蓋邊界條件或違反品質約束的修改。一條可用回饋至少應包含失敗用例、日誌、復現步驟、期望行為和相關約束。
>
> 通過的修改進入基線後，後續 Agent 不必從零開始；被拒修改則成為可檢索的負例，避免重複犯錯。評估時要關注驗收規則是否可復現、回饋是否可行動，以及誤攔截與漏攔截的不同風險。
>
> 如果網關缺失或標準模糊，多 Agent 協作未必更高效，反而可能因缺少統一裁決而混亂；自動化門禁的價值在於用可復現證據替代主觀審批。
**講授要點**
- 驗收前先寫出可運行測試、契約斷言和邊界用例
- 一條規則無法復現，就無法穩定攔截。 被拒候選應附帶失敗日誌、復現命令、期望行為和相關約束，讓下一個 Agent 能直接定位並修訂。 拆解粒粒過細會抬高合併與驗收成本，過粗會讓候選修改互相覆蓋
- 優先拆成能單獨測試與驗收的子任務。
> **素材線索**
>
> - 遞迴任務拆解、多 Agent 候選修改、自動化測試與驗收網關。圖中還標出「候選匯合」「回饋回流」「通過進入基線，拒絕返回可復現回饋」，適合邊指圖邊講閉環。 可讓學生圍繞「支付服務在輸入負數或超長字串時崩潰」的案例，設計一組可執行的驗收網關規則，至少覆蓋介面、回歸、邊界和品質約束。參考方向：介面層要求金額欄位拒絕負數和超長字串，返回統一錯誤碼並做契約斷言
> - 回歸層要求原有支付成功、退款、對帳用例全部通過且無新增失敗
> - 邊界層包含 0、負數、最大允許金額、超長字串、空字串和特殊字元用例，斷言不崩潰且錯誤可解釋
> - 品質約束包括靜態檢查通過、關鍵路徑覆蓋率不低於約定閾值、無高危告警。所有規則都應以可運行測試或腳本表達，並能在持續整合中復現。
> **練習線索**
>
> - 誤攔截會浪費正確候選的工作並降低協作效率，還可能誘導團隊放寬標準
> - 漏攔截則會讓缺陷進入歷史基線，後續 Agent 基於錯誤基線繼續工作，放大回歸風險。降低方式包括保留失敗證據、對攔截結果抽樣複核、把新增失敗用例沉澱為回歸集，並用邊界用例、契約檢查和灰度驗證組合控制風險。
**理解檢查**
隨機請一名學生用自己的話總結本頁重點，看其能否說出「可執行標準」「回饋可行動」「按可獨立驗證的邊界拆解」三個關鍵點。若能結合支付服務案例舉例，即視為掌握；若只回答「讓 Agent 自動討論」，則提示回到驗收網關標準和閉環流程。
> **過渡提示**
>
> 確認學生能說清多 Agent 協作、自動驗收與歷史繼承之間的關係後，再進入下一頁的應用、例題或總結。
### AI Native 工作方式與便捷入口
*頁面 14*
> **頁面目標：** 了解如何在 AI 工具中通過簡潔的入口和配置快速開展 EvoX 實驗。
**講授要點**
- 記住這條分工線：AI Native 入口負責安裝、基礎配置與環境檢查；你負責問題定義、方向選擇與評估標準。把省下來的時間投到後者，收益才會真正落到研究上，否則只是把等待從配置環節挪到返工環節。
- 一句話指令的價值是讓你快速進入實驗，而不是跳過核驗。安裝完成後主動確認版本、依賴與 GPU 可見性，把工具回報的狀態當作線索而不是結論，這樣後續實驗才有可靠的參照點。
- 跨機器復現前逐項核對：依賴與版本清單是否一致、GPU 型號與可用設備數是否相同、隨機種子與關鍵超參數是否固定。三項通過後再放大實驗規模，可以避免後期排查成本遠高於前期配置成本。
頁面目標**
AI Native 工作方式究竟改變了什麼，以及它的邊界在哪裡。學完後應能說清三點：交互入口從手工查文件、裝依賴、配環境、寫腳手架，遷移為在 AI 工具中以一句話發起實驗；安裝、基礎配置與環境檢查由工具承擔並回報狀態；問題定義、方向選擇與評估標準仍然由研究者負責。
講授要點**
1. 入口遷移是定義性特徵。傳統路徑是「查閱文件 → 安裝依賴 → 配置環境 → 編寫腳手架 → 才開始第一次實驗」，每一環都可能出錯，而且每次切換都要重新建立上下文。AI Native 路徑則是「一句話指令 → 工具接管安裝與配置 → 環境檢查通過 → 進入實驗」。變化的是人開始工作的方式，不是被優化的對象本身。
2. 摩擦的性質是轉移，不是消失。真正的負擔往往不來自單步操作有多難，而來自頻繁的上下文切換：研究者本該盯住問題建模、實驗設計與結果解讀，卻不斷被版本衝突、依賴缺失和環境路徑打斷。便捷入口把整段工程鏈路移交出去，讓注意力回到研究本身。
在單句指令內完成 EvoX 的安裝與基礎配置。例如輸入「安裝 EvoX 並完成基礎配置」，由工具執行並反饋結果，研究者隨即進入實驗。注意這只是起點，不是終點——工具回報的「配置完成」是需要核驗的狀態，而非可以直接採信的結論。
4. 路徑越短，從想法到可運行實驗的距離越小，想法當天可驗證，失敗假設能快速排除。對需要反覆搭建內外層實驗結構的方法演化類課題尤其明顯：時間可以放在策略設計、評估口徑與結果歸因上，而不是反覆修環境。
便捷入口降低上手與配置成本，但不替代研究者對問題價值、研究方向與評估指標的判斷。把「省時間」誤讀成「省判斷」，是這一頁最常見的偏差。省下的時間只有投到判斷環節，收益才真正落到研究上，否則只是把等待從配置環節挪到返工環節。
素材線索**
上排灰色為傳統路徑四步，下方標註「摩擦集中」；中排藍色為 AI Native 路徑四步，其中「一句話指令」帶高亮，下方標註「摩擦轉移」；底部橙色區塊是「定位邊界」。講解時可直接問：圖中被移走的是哪一段，被留下來的又是哪一段？引導學習者發現——被轉移的是安裝、基礎配置與環境檢查，被保留的是問題、方向與評估標準。
練習處理**
配套五道選擇題建議在講解後集中處理，逐題給出一句話判斷依據，便於學習者自查。
正確判斷是「預設交互入口從手工查文件、配環境、寫腳手架，換成在 AI 工具中以簡潔指令直接發起實驗」。若選到搜索策略、雲端遷移或網路結構替換，說明把「入口變化」與「算法變化」混為一談，需回到本頁強調：這一點描述的是人如何開始工作。
正確判斷是「工具在單句指令內完成安裝、基礎配置與環境檢查並回報狀態，研究者據此進入實驗」。若認為工具保證無需再核對版本與 GPU 可見性，或認為它會自動確定研究問題與評估指標，說明把作用範圍外擴了——它只覆蓋安裝與基礎配置這一段工程鏈路。
正確判斷是「降低上手與配置成本，但不替代研究者對問題定義、研究方向與評估標準的判斷」。把「省時間」讀成「省判斷」，或認為只對初學者有价值，都需要回到邊界結論重新定位。
正確判斷是「價值來自工程摩擦的轉移與迭代週期縮短，成立條件是研究者仍能核驗配置結果與實驗可復現性」。這裡要提示區分「減少人工操作」與「減少人工判斷」。
第 5 題是不核驗的後果推演，正確判斷是「環境不可復現，實驗之間的差異難以定位，結果穩定性無法得到保障」。回饋時點明：問題不在工具的能力上限，而在驗證環節的缺位，沒有被核對過的配置會給後續復現與故障定位埋下隱患。
課堂活動**
案例討論可按「三天跑通 EvoX 方法演化實驗」展開。第一問要求說清降低了什麼成本、保留了什麼責任：降低的是工程摩擦成本，保留的是問題與方向的建模決策、評估標準的確定、以及配置核驗。第二問聚焦多機復現，可引導學習者給出至少兩點可核對做法：保存工具實際安裝的版本與依賴清單並跨機器逐項比對；核對每台機器的 GPU 型號、顯存與可見設備數，必要時固定設備編號；固定隨機種子與批量規模等關鍵設置，先在相同配置下重跑基準任務，確認結果落在預期波動範圍內，再放大實驗規模。
理解檢查**
「如果安裝全部交給工具，你第二天最需要動手確認什麼？」能說出核驗版本、依賴與 GPU 可見性，即算掌握。
過渡提示**
確認學習者能說出「工具負責工程準備、研究者負責研究判斷」這條分工線後，再進入下一頁的例題、應用或總結。
### 研究者的核心品味：人機分工與批判性思維
*頁面 15*
> **頁面目標：** 理解在 AI 輔助演化過程中研究者不可替代的科學品味與批判性判斷。
> **頁面目標**
>
> 理解在 AI 輔助演化過程中，研究者不可替代的科學品味與批判性判斷。核心問題是：當 AI 大幅降低「實現答案」的成本後，科研價值轉向何處？
**講授要點**
- AI / EvoX 可以快速完成程式碼實現、實驗批跑、候選生成、參數搜索與回饋記錄，工程性成本不再是核心瓶頸。 研究者決定什麼問題值得研究、什麼結果有意義、什麼證據足以支撐結論。 AI 擴展實現與搜索空間
- 研究者把控問題定義、目標衝突、約束邊界與驗收標準。 把 AI 輸出視為待檢驗的假設，檢查假設是否成立、證據是否充分、邊界條件是否考慮、負面結果是否被忽略，避免被流暢但未經驗證的答案誤導。 在開放探索與稀疏回饋下，方向取捨不能外包給 AI
- 最終判斷與科研責任仍屬於研究者。 左側是 AI / EvoX，對應生成候選、執行實驗、搜索空間、記錄回饋
- 右側是研究者，對應提出問題、評價證據、權衡取捨、反思方向
- 中間是「Code is cheap. Taste matters」。下方「回饋閉環：批判性檢查點」提示這不是單向流程，而是 AI 產出回饋給人、人再定義問題與標準的循環。 在 EvoX 多目標優化任務中，AI 快速生成大量候選解和實驗程式碼。研究者需要判斷：目標函數是否反映真實需求？基線是否公平？指標是否遺漏關鍵約束？如果只看跑分，可能選出看似最優卻不符合實際需求的方案。這裡體現「Code is cheap. Taste matters」的方式是：AI 負責快速實現與搜索，研究者審視問題定義與證據標準，判斷哪些結果真正有意義。
**練習處理**
研究者不可替代的科學品味與批判性判斷，以及 AI 負責實現、人負責判斷的分工。錯誤選項的典型特徵是跳過概念、跳過資料背誦、只憑感覺下結論，或同時改變所有因素來比較結果。課堂案例的回答要落到：把 AI 輸出視為待檢驗假設，檢查目標函數、基線與指標；同時明確方向取捨和科研責任不能外包。
**理解檢查**
請學生用自己的話區分「實現成本」與「判斷價值」，並各舉一個可以交給 AI 的環節和一個必須由研究者負責的環節。能說清二者關係，再進入下一頁。
### 課程總結：構建持續演化的軟體世界基礎設施
*頁面 16*
> **頁面目標：** 總結全課核心內容，明確構建開放、演化、持續沉澱的智能基礎設施願景。
**講授要點**
- 候選解、產生候選的方法（如 MetaDE 的內外層配置）、專案級資產，是三個不同層次。做設計或答題前先明確一句「我現在優化的是哪一層」，可以避免把方法演化和專案級持續演化混為一談。
- 只有通過嚴格驗收的產物才允許進入經驗庫並被繼承。一旦未經驗收的結果被下游任務繼承，錯誤會沿著繼承鏈被不斷放大，而且很難定位源頭。
- 每次新任務開始時問自己一句：這一輪我直接復用了哪些上一輪已驗證的產物與經驗條目？如果答案是空的，說明當前流程仍停留在單次任務，而不是持續演化的基礎設施。
頁面目標
把「智能演化」從單次搜索、單次優化提升為面向真實世界的軟體基礎設施。重點不是再引入一個新算法，而是讓學生看清系統如何跨越單個任務、單個 Agent，依靠「任務—探索—驗收—繼承—再演化」的閉環保持開放、可靠，並持續連接真實問題。
講授要點
1. 演化對象升級。Genesis 將演化對象從單次任務的候選解，擴展到跨 Agent、跨任務週期的專案級持續演化。一次運行結束不再清空狀態，任務結束反而成為下一輪的起點。
2. 工程沉澱範式。嚴格驗收、歷史繼承與經驗沉澱三者缺一不可：驗收是閘門，決定什麼有資格被留下；繼承是通路，決定沉澱物能否在下一輪真正被調用；經驗沉澱讓系統在多次任務之間積累穩定性。只寫文件、週報不是工程沉澱，能被执行、被繼承、被復用的資產才是。
3. EvoX 的定位。EvoX 位於底層，提供算力底座、並行執行與演化調度，向上支撐開放、可組合、可持續積累的系統構建；它不是替代 Agent 決策的模組，也不是結果可視化展示組件。
4. 最終願景。軟體世界不是一次性交付的封閉製品，而是可持續演化、持續沉澱、不斷接入真實問題的智能基礎設施。關鍵詞是持續演化、持續沉澱、持續接入。
素材線索
驗收產物（通過嚴格驗收的階段性結果）、經驗庫（可復用策略與結構化失敗教訓）、歷史繼承（下一輪任務的直接起點）。左側分層圖從下往上讀：EvoX Runtime 到專案級持續演化，再到多 Agent 協作，最後連接真實世界問題，形成持續演化迴路。
可落地組織方式
多個 Agent 分別負責文獻檢索、程式碼實現與實驗復現；每次探索寫入實驗記錄；階段性結果必須通過人工與自動檢查共同確認，才能進入共享庫；下一輪任務直接從已確認結果出發。這樣專案不是「做完歸檔」的文件集合，而是一條任務到探索、驗收、繼承、再演化的流水線。要強調：缺少驗收，沉澱會被錯誤污染；缺少繼承，沉澱無法產生複利，專案就退化成重複勞動。
常見誤區
把工程沉澱等同於寫文件、寫週報。真正能被後續演化調用的沉澱物是可執行資產：通過驗收的產物、結構化的經驗庫條目、可繼承的策略與配置。文件只是外殼；缺少驗收與繼承通道的「沉澱」不會產生複利。
練習處理
把演化對象從單次任務擴展到跨越 Agent 與任務週期的專案級持續演化。回饋要點：本題問的是演化對象層級變化，不是採樣或執行方式變化。
嚴格驗收、歷史繼承與經驗沉澱共同構成穩定可靠的沉澱範式。回饋要點：回看「驗收產物、經驗庫、歷史繼承」三張卡片，缺一環沉澱失效。
EvoX 是連接真實世界的智能演化基礎設施，支撐開放、可組合、可持續積累的系統構建。回饋要點：EvoX 是最底層能力提供者，不是展示組件或替代決策者。
方法演化讓「產生候選的方法」參與迭代，專案級持續演化則在同一底座上跨越任務週期沉澱資產。回饋要點：先問「被優化的對象是什麼」——候選解、產生候選的方法，還是專案級資產。
軟體世界不是靜態交付物，而是可持續演化、持續沉澱、不斷接入真實問題的智能基礎設施。回饋要點：對比「交付物」有終點與「基礎設施」持續接入、持續生長。
案例研究處理
案例要求把跨月科研專案映射為「任務—探索—驗收—繼承—再演化」閉環。可引導學生指出：驗收和繼承是工程沉澱的核心職責。若要判斷是否真的在持續演化，可設置可檢驗判據：可繼承率是否上升；驗收通過率趨勢與同類失敗是否減少；經驗庫條目是否被真正調用；結論能否回溯到實驗與驗收記錄；系統是否也在演化產生候選的方法與配置本身。若這些指標長期不改善，就說明只是在重複執行任務。
理解檢查
第一，這一輪任務直接復用了上一輪哪些已驗證產物與經驗條目？第二，當前優化對象是哪一層——候選解、產生候選的方法，還是專案級資產？如果第一個問題答不上來，說明流程仍停留在單次任務；如果第二層混淆了，說明容易把方法演化與專案級持續演化混為一談。
過渡提示
任務結束不是終點，而是下一次演化的可繼承資產；軟體世界不是靜態交付物，而是持續接入真實問題的智能基礎設施。