# 08｜理解的工程驗收：如果真的懂，就重建給我看 ## Engineering Acceptance of Understanding: If You Really Understand It, Rebuild It **系列：**《可執行資料與深層解構學習》 **篇次：** 08 / 10 **作者：** Neo.K with Aletheia **機構：** EveMissLab／一言諾科技有限公司 **版本：** v0.1 Research Draft **日期：** 2026-08-17 **文件性質：** AI 理解驗收／重建 Benchmark／執行測試／反例／跨域遷移 **範圍聲明：** 本文把「理解」限制為可被工程驗證的 operational understanding，而不處理主體性、意識或哲學意義上的理解。 **重要限制：** 成功重建只支持功能性／結構性理解，不能推出模型已恢復原系統唯一真實內部實作。 --- ## 摘要 人工智慧可以閱讀文件、解釋程式碼、摘要系統架構、模仿行為，甚至對看似複雜的系統給出流暢說明。然而，這些能力存在一個共同驗收困境：模型是否真的掌握了足以重新建立系統的結構，還是只在既有材料附近形成高品質描述？ 本文提出一個工程化而刻意嚴格的驗收原則： $$ \boxed{ \text{Claimed Understanding} \rightarrow \text{Reconstruction Challenge} } $$ 其核心不是要求 AI 複製原始程式，而是要求模型在有限證據與明確功能契約下，獨立生成一個候選系統： $$ \hat X, $$ 使其在未見測試、反例、干預與遷移任務上，對目標系統 $X$ 的核心功能保持足夠接近： $$ \boxed{ d_{\mathcal T} \left( Behavior(X), Behavior(\hat X) \right) \leq \epsilon. } $$ 本文將重建驗收拆為六個層級：已見樣本重現、隱藏測試、干預預測、失敗區域、跨初態泛化與跨域遷移。並提出： $$ \boxed{ \text{Reconstruction Score} = f( F, H, I, R, G, T ) } $$ 其中 $F$ 為功能正確性、 $H$ 為 hidden-test 表現、 $I$ 為 intervention fidelity、 $R$ 為 robustness、 $G$ 為 generalization、 $T$ 為 transfer。 本文引用軟體工程與程式合成中的執行式評測作為方法論先例。APPS 以測試案例判定自然語言規格生成的程式；SWE-bench 要求模型在真實 repository 中修改程式並以 fail-to-pass tests 驗證；CodeBenchGen 強調現代 code-generation benchmark 必須執行生成程式，而不是只依文字相似度；Synthesize–Execute–Debug 則顯示 execution feedback 可以直接驅動候選程式修復。2026 年的 Understanding by Reconstruction 進一步提出：靜態 repository 只是軟體開發的終態，若逆向重建 planning、reasoning、debugging 與 refinement trajectory，可形成比 raw code 更豐富的訓練信號。 本文將這些思想推廣到遊戲、軟體、模擬、Agent、工程與其他可執行系統，提出「重建不是理解的哲學定義，而是理解的一種高強度工程證據」。AI 若能在不知道完整原始實作的情況下，重新組合 functional types、control contracts、state model、timing、failure handling 與 resource policy，並通過未見測試，其「我懂了」才開始具有可操作的驗收意義。 **關鍵詞：** Reconstruction Benchmark、Operational Understanding、Hidden Tests、Program Synthesis、SWE-bench、Execution-based Evaluation、Counterexample、Transfer、Behavioral Equivalence --- # 1. 問題：AI 說「我懂了」時，我們到底驗收什麼？ 人類對另一個人說： > 你懂了嗎？ 很多時候可以接受： > 懂了。 但工程系統不能只依賴自我陳述。 對 AI 更是如此。 模型可能可以： - 流暢解釋； - 引用正確術語； - 重述 architecture； - 畫漂亮流程圖； - 生成合理 pseudocode。 然而這些輸出仍可能來自： $$ \boxed{ \text{Local Pattern Completion} } $$ 而不是： $$ \boxed{ \text{Operationally Usable System Model}. } $$ 因此需要外部驗收。 --- # 2. 本文不定義「真正理解」 「真正理解」涉及： - 認知哲學； - 意識； - 主體性； - 心智表徵； - 意向性。 本文暫時不處理。 我們只定義： $$ \boxed{ U_{\mathrm{op}} = \text{Operational Understanding Evidence}. } $$ 也就是： > 有哪些行為證據支持 AI 已掌握足以操作、修改、預測與重建系統的知識？ --- # 3. 最殘酷也最簡單的驗收 如果模型說： > 我理解這個系統。 那麼可以問： $$ \boxed{ \text{Can you rebuild a functionally equivalent system?} } $$ 不是： > 你能把原始碼背出來嗎？ 而是： > 你能否用自己的結構重新做出來？ --- # 4. Reconstruction 與 Copy 必須分離 本文的重建： $$ \hat X $$ 不是： $$ Copy(X). $$ 而是： $$ \boxed{ \hat X = Synthesize( Requirements, Evidence, Constraints ). } $$ 若 $\hat X$ 的 source、module layout、class naming 與原作完全不同，只要核心功能在指定測試域保持等價，它仍然是有效重建。 --- # 5. Behavioral Equivalence 給定測試集合： $$ \mathcal T = \{t_1,\ldots,t_n\}. $$ 定義： $$ B_X(t) $$ 為原系統輸出／行為， $$ B_{\hat X}(t) $$ 為重建系統輸出。 則： $$ \boxed{ d_{\mathcal T}(X,\hat X) = \frac{1}{|\mathcal T|} \sum_{t\in\mathcal T} d( B_X(t), B_{\hat X}(t) ). } $$ 若： $$ d_{\mathcal T}\leq\epsilon, $$ 則支持： $$ \boxed{ \hat X \equiv_{\mathcal T,\epsilon} X. } $$ --- # 6. 等價永遠相對於測試域 不能寫： $$ \hat X=X. $$ 更正確的是： $$ \boxed{ \hat X \equiv_{\mathcal T,\epsilon} X. } $$ 因為測試之外仍可能不同。 --- # 7. 已見測試不夠 如果模型已經看到： $$ \mathcal T_{\mathrm{train}}, $$ 再讓它通過同一批： $$ \mathcal T_{\mathrm{train}}, $$ 證據很弱。 這可能只是： $$ \boxed{ \text{Memorization / Overfitting}. } $$ --- # 8. Hidden Tests 的核心作用 因此需要： $$ \boxed{ \mathcal T_{\mathrm{hidden}}. } $$ 模型在重建前不知道其內容。 如果： $$ Score_{\mathrm{hidden}} $$ 仍然高， 表示： $$ \hat X $$ 更可能捕捉到一般規律。 --- # 9. 軟體工程早已大量使用這種驗收 APPS benchmark 給模型自然語言 programming problem， 要求生成： $$ Program. $$ 再用測試案例判斷： $$ \boxed{ \text{Program Correct?} } $$ 這比： > 生成程式看起來像答案。 具有更強客觀性。 --- # 10. SWE-bench：從單函式走向真實 repository SWE-bench 進一步將： $$ \boxed{ \text{Issue} + \text{Repository} } $$ 交給模型。 模型必須修改真實 codebase： $$ Repo \rightarrow Repo'. $$ 最後用： $$ \boxed{ \text{Fail-to-Pass Tests} } $$ 判定 issue 是否真正被解決。 這非常接近本文的哲學： > 說你理解 issue 不重要；把系統修到測試通過才重要。 --- # 11. Execution-based Evaluation CodeBenchGen 明確提出： > 要可靠評測 modern code generation，需要執行並測試生成的 code。 這意味： $$ \boxed{ \text{Text Similarity} \ll \text{Execution Evidence} } $$ 在可執行 domain 中尤其如此。 --- # 12. 這可以直接移植到遊戲解構 假設 AI 聲稱理解： > 某款遊戲的 NPC autonomy。 不要只讓它寫： > NPC 有 Need + Utility + Scheduler。 而是要求： $$ \boxed{ \text{Build a new autonomy runtime}. } $$ --- # 13. 最低重建規格 例如只給： ```text Agent has hunger, fatigue, safety and work obligations. Tasks can be interrupted. Two agents cannot reserve the same unique resource. Offscreen simulation may run at lower fidelity. Save/load must preserve continuity. ``` 要求 AI 自己設計： - state schema； - task model； - arbitration； - reservation； - interrupt； - scheduler； - persistence； - simulation LOD。 --- # 14. 真正測的是「結構能力」 如果 AI 只是背過某款遊戲， 但題目故意改： - 名稱； - 美術； - 世界觀； - 變量； - map； 仍然應能重建核心功能。 所以 benchmark 應抽掉： $$ \boxed{ \text{Surface Identity}. } $$ 保留： $$ \boxed{ \text{Functional Requirements}. } $$ --- # 15. Level R0 — Seen Example Reproduction 最弱重建層： $$ R_0. $$ 提供完整樣本， 要求重現已見 output。 這主要測： - syntax； - local consistency； - basic execution。 --- # 16. Level R1 — Hidden Input Generalization $$ R_1. $$ 提供： $$ D_{\mathrm{train}}, $$ 但測： $$ D_{\mathrm{hidden}}. $$ 要求： $$ \boxed{ \text{Generalize}. } $$ --- # 17. Level R2 — Perturbation Robustness 改變： - initial state； - resource； - NPC count； - timing； - map； - task order。 測： $$ \boxed{ \text{Does the reconstruction remain coherent?} } $$ --- # 18. Level R3 — Intervention Fidelity 對重建與原系統施加： $$ do(a). $$ 比較： $$ P_X(Y\mid do(a)) $$ 與： $$ P_{\hat X}(Y\mid do(a)). $$ 若接近： $$ \boxed{ \text{Intervention Fidelity}\uparrow. } $$ --- # 19. Level R4 — Failure Recovery 故意注入： - path fail； - unavailable item； - task conflict； - interrupted animation； - missing resource； - changed goal。 測： $$ \boxed{ \text{Recovery}. } $$ --- # 20. Level R5 — Transfer Reconstruction 最強層之一： > 把這套原理換到新 domain。 例如原本學的是： $$ \text{Colony NPC Scheduler}. $$ 改成： $$ \text{Hospital Task Scheduler}. $$ 或： $$ \text{Game Crafting Pipeline} \rightarrow \text{Manufacturing Workflow}. $$ 如果核心 functional structure 可以遷移， 代表： $$ \boxed{ \text{Abstraction Depth} } $$ 更高。 --- # 21. 六層重建階梯 因此： $$ \boxed{ R_0 < R_1 < R_2 < R_3 < R_4 < R_5. } $$ 分別： $$ \boxed{ \begin{aligned} R_0 &: \text{Seen Reproduction}\\ R_1 &: \text{Hidden Test}\\ R_2 &: \text{Perturbation Robustness}\\ R_3 &: \text{Intervention Fidelity}\\ R_4 &: \text{Failure Recovery}\\ R_5 &: \text{Cross-Domain Transfer} \end{aligned} } $$ --- # 22. Reconstruction Score 本文提出： $$ \boxed{ \mathrm{RScore} = w_FF + w_HH + w_II + w_RR + w_GG + w_TT. } $$ 其中： - $F$：functional correctness； - $H$：hidden-test； - $I$：intervention； - $R$：robustness； - $G$：generalization； - $T$：transfer。 --- # 23. 不要一開始壓成單一總分 實務上應同時保存： $$ \boxed{ (F,H,I,R,G,T). } $$ 因為兩個 reconstruction： $$ A $$ 與： $$ B $$ 可能： $$ F_A>F_B $$ 但： $$ T_A 這個 component 其實不是測試真正覆蓋的東西。 --- # 29. Component Ablation 對候選： $$ \hat X $$ 進行： $$ Ablate(m_i). $$ 計算： $$ \Delta Score_i. $$ 若： $$ \Delta Score_i\approx0, $$ 則： - $m_i$ 可能多餘； - 或 benchmark 未覆蓋其作用。 --- # 30. Invariant Test 如果 AI 說： $$ I $$ 是不變量， 應設計： $$ \boxed{ \text{Invariant Stress Tests}. } $$ 例如： > 任一 resource 都不應被兩個 NPC 同時 exclusive-reserve。 則跑： $$ 100000 $$ 次 concurrency simulation。 --- # 31. Reconstruction 也要看資源成本 一個： $$ \hat X $$ 功能上等價， 但需要： $$ 100\times $$ CPU， 並不等於成功商品重建。 因此： $$ \boxed{ \text{Functional Equivalence} + \text{Resource Viability}. } $$ --- # 32. Resource-Aware Distance 可以加入： $$ d_R = d( CPU, Memory, Latency, Storage ). $$ 完整距離： $$ \boxed{ d = w_Bd_B + w_Rd_R. } $$ --- # 33. Reconstruction Complexity 如果 AI 能用： $$ 10 $$ 個清楚模組重建， 而另一個需要： $$ 1000 $$ 個 hardcoded case， 即使測試分數相同， 前者可能具有更高： $$ \boxed{ \text{Structural Compression}. } $$ --- # 34. Minimum Description Bias 在多個等價候選： $$ \hat X_1,\ldots,\hat X_k $$ 中， 可以偏好： $$ \boxed{ \arg\min Complexity(\hat X_i) } $$ 但這只是 inductive bias， 不是原始實作證明。 --- # 35. 不能把最簡模型當唯一真相 如果： $$ \hat X_{simple} $$ 能解釋全部目前測試， 只能說： > 它是目前足夠的模型。 不能說： > 原系統一定如此簡單。 --- # 36. Multiple Hypothesis Reconstruction 成熟 benchmark 可以要求 AI 輸出： $$ \boxed{ \{\hat X_1,\hat X_2,\hat X_3\} } $$ 並附： - evidence； - expected distinguishing tests； - confidence。 這比強迫一個答案更科學。 --- # 37. Experiment Proposal 也是理解證據 如果 AI 知道： > 目前無法區分 Utility 與 Priority Rule。 然後提出： > 建立兩個 priority 相同但 utility 分數相反的 action，觀察選擇。 這本身就是： $$ \boxed{ \text{High-Value Understanding Evidence}. } $$ 因為它知道： > 自己不知道什麼。 --- # 38. Unknown Calibration 因此 benchmark 還應測： $$ \boxed{ \text{Can the model say UNKNOWN correctly?} } $$ 而不是強迫它每次回答。 --- # 39. Overclaim Penalty 若模型宣稱： $$ Confidence=0.99 $$ 但 hidden tests 大量失敗， 應懲罰： $$ \boxed{ \text{Overclaim}. } $$ --- # 40. Calibration Score 令： $$ c_i $$ 為 confidence， $$ y_i $$ 為實際成功。 可測： $$ \boxed{ \operatorname{Calibration}(c,y). } $$ 因此「知道自己懂到哪」也是工程能力。 --- # 41. Program Synthesis 的重要啟示 Program synthesis from examples 長期面對： $$ \boxed{ \text{Many Programs Fit the Same Examples}. } $$ 這和系統重建完全同構。 --- # 42. Synthesize–Execute–Debug SED 不要求 neural synthesizer 一次生成完美 program。 而是： $$ \boxed{ \text{Synthesize} \rightarrow \text{Execute} \rightarrow \text{Debug} \rightarrow \text{Repair}. } $$ 這直接支持： $$ \boxed{ \text{Execution Feedback} } $$ 作為重建閉環的一部分。 --- # 43. 重建 AI 應該允許迭代 第一版： $$ \hat X_0. $$ 測試後得到： $$ E_0. $$ 再： $$ \hat X_1 = Repair( \hat X_0,E_0 ). $$ 所以： $$ \boxed{ \hat X_{k+1} = Update( \hat X_k, Failure_k ). } $$ --- # 44. 一次答錯不代表沒理解 真正值得測的是： > AI 能不能利用 failure 改進？ 因此 benchmark 可以同時報： $$ \boxed{ \mathrm{Score}_{0} } $$ 與： $$ \boxed{ \mathrm{Score}_{after\ repair}. } $$ --- # 45. Learning from Failure 定義： $$ \boxed{ \Delta R = \mathrm{RScore}_{after} - \mathrm{RScore}_{before}. } $$ $\Delta R$ 大表示： > 模型可以從 execution evidence 修正 internal model。 --- # 46. Software Reconstruction 的新研究方向 2026 年 Understanding by Reconstruction 提出： > 靜態 repository 只是軟體發展最後狀態。 真正缺失的是： - planning； - reasoning； - debugging； - iterative refinement。 其方法嘗試逆向重建： $$ \boxed{ \text{Latent Development Trajectory}. } $$ --- # 47. 這和本文高度相容，但本文更廣 該研究主要針對： $$ \text{Software Pretraining}. $$ 本文將同一思想泛化到： - game system； - AI controller； - workflow； - simulation； - engineering artifact。 目標是： $$ \boxed{ \text{Artifact} \rightarrow \text{Latent Process} \rightarrow \text{Rebuild}. } $$ --- # 48. Final State 不是完整知識 一個完成遊戲： $$ G_T $$ 並沒有直接保存： $$ G_0 \rightarrow G_1 \rightarrow \cdots \rightarrow G_T $$ 的設計路徑。 因此只餵 final source， 可能失去： - rejected architectures； - bugs； - tradeoffs； - why-not decisions。 --- # 49. Reconstruction 可以補回部分 lost trajectory 若 AI 從： $$ G_T $$ 反向推： $$ \hat \tau_{dev}, $$ 再用生成過程驗證： $$ Build( \hat \tau_{dev} ) \rightarrow \hat G_T, $$ 就得到新的 supervision。 --- # 50. 但 reconstructed trajectory 仍然不是歷史事實 它只是： $$ \boxed{ \text{Plausible Development Explanation}. } $$ 除非有： - commit history； - issue； - developer log； - version control。 才能提升歷史證據強度。 --- # 51. 遊戲版 Reconstruction Benchmark 本文提出： # **Game Reconstruction Benchmark, GRB** 每個 task 包含： ```text functional specification behavior traces partial observations selected public evidence resource constraints hidden tests stress tests transfer task ``` --- # 52. GRB 不應提供什麼 為避免 copy： - 不提供完整原 source； - 不提供直接一比一 implementation； - 不要求資產複製； - 不依賴商業 IP 表面內容。 目標是： $$ \boxed{ \text{Functional Reconstruction}. } $$ --- # 53. Example GRB — Auto Battle 提供： ```text Party has HP, MP, status effects and roles. Actions have cost and cooldown. Healing should prefer endangered allies. Expensive skills should be conserved outside high-risk states. Player may override automation. ``` AI 自己設計： $$ \boxed{ \text{AutoBattle Controller}. } $$ --- # 54. Hidden Tests 可能包含： - two allies critically injured； - healer silenced； - MP shortage； - boss enrage； - player override； - revive conflict； - status cleanse priority。 --- # 55. Example GRB — Persistent NPC 規格： ```text NPC works, eats, sleeps, socializes. Tasks can be interrupted by danger. World continues offscreen. Save/load must preserve schedule continuity. ``` hidden tests： - bed unavailable； - workplace destroyed； - simultaneous fire； - save during interrupted task； - NPC returns after long offscreen period。 --- # 56. Example GRB — RTS Strategic AI 規格： - economy； - build order； - scouting； - threat response； - tech choice； - recovery after failed rush。 hidden test： > opponent uses strategy unseen during provided demonstrations. --- # 57. Reconstruction Should Be Style-Neutral First 第 08 篇的第一目的： $$ \boxed{ \text{Can it work?} } $$ 先不要把： - 好不好玩； - 有沒有靈魂； - 美不美； 全部混進來。 那些會在第 09、10 篇進入 value / style selection。 --- # 58. Functional Acceptance Gate 因此先要求： $$ \boxed{ A_F(\hat X)=1. } $$ 若： - crash； - invariant fail； - hidden test fail； 先淘汰。 --- # 59. 第二階段才比較風格 通過： $$ A_F=1 $$ 之後， 才比較： $$ \boxed{ \text{Style}, \text{Novelty}, \text{Efficiency}, \text{Player Preference}. } $$ --- # 60. Cross-Game Reconstruction 真正好的 Game AI learner 不應只： > 重做它看過的五款遊戲。 而應從： $$ \{G_1,\ldots,G_n\} $$ 抽取： $$ \boxed{ I_{\mathrm{family}} } $$ 再重建： $$ G^\* $$ 的 subsystem。 --- # 61. Leave-One-Game-Out 例如有： $$ 10 $$ 款 colony sim。 訓練／研究： $$ 9 $$ 款。 隱藏： $$ 1 $$ 款。 測： > 能否預測其 functional architecture？ 或： > 能否用前九款的知識重建第十款的行為族？ --- # 62. Leave-One-Mechanism-Out 更難： 故意不提供： $$ Mechanism_m. $$ 只給： - behavior； - outcomes； - constraints。 測 AI 是否能重新發現。 --- # 63. Cross-Domain Transfer 例如從遊戲的： $$ \text{Reservation System} $$ 轉到： $$ \text{Warehouse Robot Resource Locking}. $$ 如果： $$ \boxed{ \text{exclusive resource} + \text{acquire} + \text{release} + \text{timeout} } $$ 能被抽象出來， 才真正顯示 functional typing 有效。 --- # 64. Reconstruction Failures 也必須分類 建立： $$ \boxed{ \mathcal F_R. } $$ --- # 65. F1 — Surface Imitation 看起來像， 但功能錯。 例如： > 做了 RimWorld 樣 UI， 沒有 job scheduling。 --- # 66. F2 — Test Memorization 已見 test 通過， hidden test 崩。 --- # 67. F3 — Happy-Path Reconstruction 正常流程可用， edge case 無 recovery。 --- # 68. F4 — Wrong Latent Structure 結果短期相同， intervention 一改就分歧。 --- # 69. F5 — Overfitted Architecture 只適用原 map／原角色數。 換 initial state 就失效。 --- # 70. F6 — Resource Explosion 功能對， 但 CPU / memory 不可接受。 --- # 71. F7 — Non-Transferable Reconstruction 重建一款成功， 抽不出任何跨案例 pattern。 --- # 72. F8 — False Confidence 實際不確定， 但宣稱確定。 --- # 73. Reconstruction Benchmark 的資料價值 這種 benchmark 自己也會產生： - successful designs； - failed designs； - repair trajectories； - counterexamples； - confidence errors。 所以： $$ \boxed{ \text{Evaluation} \rightarrow \text{New Training Data}. } $$ --- # 74. 這直接接到合成資料 每一次： $$ \hat X_k \rightarrow Test \rightarrow Failure \rightarrow Repair $$ 都產生： $$ \boxed{ \text{Synthetic Development Trajectory}. } $$ 第 09 篇就會正式研究： > 當重建已經成熟，AI 能否開始探索「以前沒有人做過」的新候選？ --- # 75. 理解驗收與 Novelty Search 的分界 第 08 篇： $$ \boxed{ \text{Can you reconstruct known functionality?} } $$ 第 09 篇： $$ \boxed{ \text{Can you create valid functionality beyond known designs?} } $$ 先重建， 再創新。 --- # 76. 不能跳過重建直接宣稱創新 如果 AI 連： $$ \text{Known System} $$ 都無法可靠重建， 卻生成： > 前所未有的新架構。 我們很難知道： $$ \boxed{ \text{Novelty} } $$ 究竟是創新， 還是錯誤。 --- # 77. Reconstruction as Calibration Phase 因此在生成式研究系統中： $$ \boxed{ \text{Reconstruction} } $$ 可以作為： $$ \boxed{ \text{Calibration Before Novelty}. } $$ --- # 78. Human Acceptance 最後，工程驗收仍然需要人類。 因為測試不能窮盡： $$ \Omega. $$ 所以： $$ \boxed{ \text{Machine Verification} + \text{Human Review}. } $$ --- # 79. 人類的角色也開始改變 人類不用逐行寫程式。 而是： - 定義 contracts； - 設計 hidden tests； - 找 counterexamples； - 判定 failure importance； - 決定 acceptable error。 這很像： $$ \boxed{ \text{Boss / Evaluator}. } $$ --- # 80. 這就是「慣老闆」的工程版本 人類最後只會問： > 所以能不能用？ 因此 AI 的知識價值最終會被壓縮成： $$ \boxed{ \text{Can it produce a working artifact under constraints?} } $$ --- # 81. 命題一：重建證據命題 成功重建不是理解的哲學充分條件， 但： $$ \boxed{ \text{Successful Hidden-Test Reconstruction} } $$ 是 operational understanding 的強證據。 --- # 82. 命題二：已見重現不足命題 若： $$ Score_{\mathrm{train}}\gg0 $$ 但： $$ Score_{\mathrm{hidden}}\approx0, $$ 則重建更接近記憶／過擬合，而非一般化理解。 --- # 83. 命題三：干預忠實度命題 若： $$ \hat X $$ 不只在正常 trajectory 上相似， 還在： $$ do(a) $$ 條件下保持結果結構相似， 則 mechanism evidence 更強。 --- # 84. 命題四：失敗恢復命題 商品級重建必須測： $$ \boxed{ \text{Failure Space}. } $$ 只通過 happy path 不足以宣稱系統級重建成功。 --- # 85. 命題五：跨域遷移命題 若模型能將抽取出的 functional invariant 轉移到新 domain 並產生有效 implementation，則提供比單案例 reconstruction 更強的抽象證據。 --- # 86. 命題六：多重重建命題 $$ \boxed{ \hat X_1 \equiv_{\mathcal T} \hat X_2 } $$ 不代表： $$ \hat X_1=\hat X_2. $$ 因此重建 benchmark 必須允許多種功能等價解。 --- # 87. 命題七：不確定性也是能力 能正確說： $$ \boxed{ \text{Insufficient Evidence}. } $$ 比高信心猜錯更有價值。 因此 calibration 應納入理解驗收。 --- # 88. 命題八：重建—資料閉環命題 每一次 reconstruction benchmark 都會產生： $$ \boxed{ \text{Attempt} + \text{Test} + \text{Failure} + \text{Repair} } $$ 因此評測本身可以成為下一輪深層學習資料源。 --- # 89. 與下一篇的連接 第 07 篇回答： > 看過資料為什麼不等於學會？ 第 08 篇回答： > 那要怎麼驗收「學會」？ 答案是： $$ \boxed{ \text{Reconstruct} + \text{Execute} + \text{Test} + \text{Break} + \text{Repair}. } $$ 當這個閉環成熟後， 下一個真正有意思的問題就是： > 如果 AI 已經能可靠重建人類做過的系統，它能不能開始創造「還沒有存在過」的有效設計？ 因此下一篇： # **09｜合成資料之後：從模仿既有設計到探索新穎可執行設計空間** 將正式進入： $$ \boxed{ \text{Reconstruction} \rightarrow \text{Novel Generation} \rightarrow \text{Executable Validation} \rightarrow \text{Novelty Search}. } $$ --- # 90. 結論 AI 時代最容易降低標準的一句話是： > 模型看起來懂了。 工程世界不能停在這裡。 本文提出一個簡單而嚴格的替代問題： $$ \boxed{ \text{If you understand it, can you rebuild it?} } $$ 如果可以， 再問： > 未見條件呢？ > 干預呢？ > 失敗呢？ > 資源限制呢？ > 換 domain 呢？ 所以真正的驗收階梯是： $$ \boxed{ \text{Explain} \rightarrow \text{Reconstruct} \rightarrow \text{Generalize} \rightarrow \text{Intervene} \rightarrow \text{Recover} \rightarrow \text{Transfer}. } $$ 此時「理解」不再是模型對自己的評價。 而變成： $$ \boxed{ \text{A falsifiable engineering claim}. } $$ 它可以失敗。 可以被反例打破。 可以被 hidden test 淘汰。 也可以在 execution feedback 中被修正。 這正是可執行系統相對純內容資料最重要的優勢之一： > AI 不必只說自己學會了。 我們可以真的叫它： $$ \boxed{ \text{做出來。} } $$ --- # 參考資料 1. Hendrycks, D. et al. (2021). **Measuring Coding Challenge Competence With APPS.** 2. Jimenez, C. E. et al. (2024). **SWE-bench: Can Language Models Resolve Real-World GitHub Issues?** ICLR 2024. 3. SWE-bench Project. **SWE-bench Evaluation Framework and Repository.** 4. Xie, Y. et al. (2024). **CodeBenchGen: Creating Scalable Execution-based Code Generation Benchmarks.** 5. Gupta, K., Christensen, P. E., Chen, X., & Song, D. (2020). **Synthesize, Execute and Debug: Learning to Repair for Neural Program Synthesis.** 6. Chen, X., Liu, C., & Song, D. (2017). **Towards Synthesizing Complex Programs from Input-Output Examples.** 7. Zeng, Z. et al. (2026). **Understanding by Reconstruction: Reversing the Software Development Process for LLM Pretraining.** 8. Rajendran, G. et al. (2024). **An Interventional Perspective on Identifiability in Gaussian LTI Systems with Independent Component Analysis.** CLeaR 2024. 9. Han, Y., Poggio, T. A., & Cheung, B. (2023). **System Identification of Neural Systems: If We Got It Right, Would We Know?** ICML 2023. --- ## 系列導航 - 01｜AI 時代的資料資產：從「賣資料」到授權可計算知識 - 02｜高品質資料之後：從 Quality Paradigm 到 Novelty Paradigm - 03｜遊戲不是內容資料：遊戲作為可執行因果世界 - 04｜商業遊戲智能考古：從 AI 名作到普通遊戲群 - 05｜遊戲解構經濟學：成本、難度、資訊增益與研究深度 - 06｜商業遊戲 AI 的隱藏層：真正稀缺的是組合，而非基礎演算法 - 07｜餵資料不等於學習：從 Raw Exposure 到深層解構學習 - 08｜理解的工程驗收：如果真的懂，就重建給我看 - 09｜合成資料之後：從模仿既有設計到探索新穎可執行設計空間 - 10｜慣老闆測試：意圖重建、設計生成與可執行世界考古