技術域先行論：AI 工程中的語言、Runtime 與承載域選擇

Technology-Domain First Theory: Language, Runtime, and Substrate Selection for AI-Native Engineering

系列： AI 原生全域完成方法論
篇次： 01 / 03
作者： Neo.K with Aletheia
機構： EveMissLab／一言諾科技有限公司
版本： v0.1
日期： 2026-09-11
文件類型： 方法論論文／AI Agent 工程理論

摘要

當代 AI Coding Agent 已具備大規模程式生成、Repository 級理解、跨檔案修改、測試執行與自動修復能力，但其工程決策仍經常停留在「既有技術選型之內進行局部優化」。一旦專案最初選擇 Python、JavaScript、Rust、C++ 或其他技術，Agent 往往傾向將後續所有問題都解釋為「如何把目前方案修得更完整」，而較少重新詢問更根本的問題：目前的程式語言、Runtime、框架、資料模型與部署基底，是否仍是這個任務的正確承載域？

本文提出「技術域先行論」（Technology-Domain First Theory, TDFT）。其核心主張為：在開始大規模實作與精修之前，AI 應先根據任務目的、生命週期、性能要求、安全需求、部署環境、可逆性、迭代速度、團隊條件與長期維護成本，選擇適合的技術域。若任務需求已經跨越原技術域的合理邊界，應重新選擇語言、Runtime、框架、資料層或執行基底，而不是透過無限驗證、補償性 wrapper、額外 runtime guard 與流程儀式，試圖把一個不適合的技術域人工修造成另一個技術域。

本文延續 PLDST 的複雜度配置論。既有研究已指出，一項語言機制的簡化並不代表總體複雜度消失；複雜度可能被移動至語義、編譯器、Runtime、工具、使用者、組織或治理層。真正需要回答的是：複雜度在哪裡、由誰承擔、何時支付、是否可見，以及失敗時向哪裡外溢。

因此，程式語言選擇本質上也是「複雜度支付位置」的選擇。Python 可以降低初期撰寫與原型成本；Rust 將更多成本前移至型別、所有權、編譯器與學習階段，以降低部分 Runtime 記憶體錯誤與後期除錯成本。兩者不是單純的優劣排序，而是在不同任務域中選擇不同的複雜度配置。PLDST 對 Rust 的分析已明確指出，其價值取決於錯誤成本與目標領域。

本文進一步提出「語言—流程一致性原則」、「技術域重選閾值」、「補償過度反轉」、「底空間錯置」及「承載域—保證域一致性」等概念，並將其整合進 AI 原生全域完成方法論：

\boxed{ \text{Task} \rightarrow \text{Technology Domain Selection} \rightarrow \text{Global Architecture} \rightarrow \text{Global Implementation} \rightarrow \text{Bounded Validation} \rightarrow \text{Completion} }

本文最終主張：

不要先選一個技術，再無限修正它以適應所有需求；應先判斷問題真正存在於哪一個技術域，再讓工程在正確的底空間中收斂。

1. 問題的提出：AI 很會修，但不一定先問「為什麼用這個？」

現代 AI Coding Agent 已經非常擅長以下工作：

補型別；
補測試；
加 wrapper；
加 validation；
加 retry；
加 fallback；
補 exception handling；
加安全檢查；
重構模組；
加 interface；
補文件；
修 lint；
加 integration test。

這些能力本身沒有問題。

真正的問題是：如果所有這些工作都建立在一個不適合的技術選型上，那麼 Agent 做得越勤奮，可能只是越深入錯誤的底空間。

假設最初選擇技術 $L_0$ ：

L_0=\text{Python}.

後續需求逐步演化為：

R_t= \{ \text{高並行}, \text{低延遲}, \text{記憶體安全}, \text{可預測資源}, \text{Native Deployment}, \text{長期大型維護} \}.

一般局部優化 Agent 容易採取：

L_0 \rightarrow \operatorname{Patch}(L_0) \rightarrow \operatorname{Guard}(L_0) \rightarrow \operatorname{Validate}(L_0) \rightarrow \operatorname{Refine}(L_0) \rightarrow\cdots

但技術域先行論首先要求詢問：

\boxed{ L_0 \stackrel{?}{\in} \mathcal D(R_t) }

也就是：

原始技術是否仍位於目前需求的合理可行域？

如果答案是否定的，真正合理的動作可能不是再加一層補償，而是：

L_0\rightarrow L_1.

2. 程式語言不是可以被無限精修的中性容器

一個常見錯誤，是把程式語言視為純粹的表面語法：

L\approx\text{Syntax}.

如果如此理解，就很容易認為：

只要程式寫得夠好，任何語言最後都差不多。

但既有程式語言設計研究已經否定這種過度簡化。

程式語言設計風格系列將完整語言描述為具有權威程式本體、基本計算單位、程式拓撲、穩定語義核心、適應與轉譯層、多重投影、控制權及治理等結構，而非只有 syntax 與 compiler。

因此：

\boxed{ \operatorname{Refine}^{n}(L) \not\Rightarrow L' }

即使：

n\rightarrow\infty,

Python 也不會因為加入大量測試、mypy、runtime check、wrapper、lint、security scanner 與 deployment discipline，就在語言本體上成為 Rust。

同樣地，Rust 也不會因為增加 ergonomic macro 與高階框架，就自然變成 Python 的動態互動式工作模式。

不同語言具有不同：

型別責任；
記憶體責任；
Runtime 模型；
錯誤發生時機；
編譯責任；
效能可見性；
FFI 模型；
生態結構；
工具成本；
開發速度；
部署假設。

因此語言不是任意可替換的「文字皮膚」，而是一種工程底空間。

3. 技術域的正式定義

本文定義一個技術域：

\mathcal D_T = ( L, R, F, S, E, O, G )

其中：

$L$ ：Language，語言；
$R$ ：Runtime，運行時模型；
$F$ ：Framework／Library ecosystem；
$S$ ：Storage／State substrate；
$E$ ：Execution environment；
$O$ ：Operational model；
$G$ ：Guarantee model。

其中 Guarantee model 特別重要。

它包括：

哪些錯誤由 compiler 阻止；
哪些錯誤延後至 Runtime；
哪些需要測試發現；
哪些依賴人工 review；
哪些由 sandbox／OS／container 提供；
哪些根本沒有保證。

因此：

\boxed{ \text{Technology Domain} \neq \text{Programming Language Only} }

例如：

Python
+ CPython
+ FastAPI
+ PostgreSQL
+ Docker
+ Linux

是一個技術域。

而：

Rust
+ Tokio
+ Axum
+ PostgreSQL
+ Native binary
+ Linux

是另一個技術域。

同樣的產品功能，可以存在於不同技術域中，但其複雜度配置、性能邊界、失敗型態與驗證需求可能完全不同。

4. 不同語言服務不同尺度，不是缺陷

Nova 早期白皮書已明確拒絕「一個語言統治所有領域」的思路。

其最終定位直接指出：

Web 應用可使用 JavaScript；
系統工具可使用 Rust；
AI 模型可使用 Nova；
Python、C++、EML、Nova 可以共存。

原因不是其中某個語言比較差，而是它們服務不同尺度。

Nova Core 後續規格更進一步明確排除「第一版就取代所有 Web、CRUD、作業系統與嵌入式語言」的通用語言幻想。

因此，本文建立：

適用域命題

對語言或技術 $L$ ，不存在脫離任務 $T$ 的普遍最佳性：

\boxed{ L^* \neq \arg\max_L Q(L) }

而應為：

\boxed{ L^*(T,C) = \arg\max_L U(L\mid T,C) }

其中 $C$ 是實際情境，包括：

時間；
預算；
團隊；
生態；
deployment；
資料；
安全；
latency；
維護期限；
AI 能力。

所以：

最好的語言不是最強的語言，而是對目前任務成本結構最合適的語言。

5. Python-first 為什麼可以完全合理？

技術域先行論並不主張：

所有正式產品都應一開始使用 Rust。

恰恰相反。

如果任務的主要需求是：

T_0= \{ \text{快速實驗}, \text{快速產品化}, \text{快速修改}, \text{大量現成套件}, \text{高 AI 生成效率} \},

那麼 Python-first 可以是非常合理的策略。

其大致配置為：

C_{\text{write}}\downarrow

C_{\text{prototype}}\downarrow

C_{\text{ecosystem-entry}}\downarrow.

並可能把部分成本延後至：

C_{\text{test}}, C_{\text{runtime}}, C_{\text{refactor}}, C_{\text{deployment}}.

PLDST 已經指出，「延後」本身並不一定是錯誤；在探索階段，延後部分約束可以提高速度，只要系統知道這筆成本之後如何支付。

所以：

\boxed{ \text{Python-first} \neq \text{Bad Engineering} }

如果它的目的就是：

快速取得完整產品閉環。

6. 問題在於：選 Python 後又把流程變成 Rust-minus-Rust

真正矛盾的是：

最初選擇 Python 是因為：

\text{Fast iteration}.

但 Agent 後續卻逐漸加入：

每一步完整測試；
極端 defensive programming；
多層型別補強；
大量 runtime assertion；
重複靜態分析；
threat simulation；
多輪 review；
permission gate；
每個 edge case 都升格為 blocker。

最後：

C_{\text{process}}\uparrow\uparrow.

甚至可能出現：

C_{\text{Python+Compensation}} > C_{\text{Rust-first}}.

但此時使用者仍然沒有真正取得 Rust 提供的語言級 ownership、borrow checking、native binary 與編譯期部分保證。

這形成本文提出的新概念：

補償過度反轉

Compensatory Overcorrection

定義：

若選擇技術 $L_a$ 的原始理由是降低某些前置成本：

C_{\text{front}}(L_a) < C_{\text{front}}(L_b),

但後續為補償 $L_a$ 的限制，新增：

C_{\text{comp}}(L_a),

使：

C_{\text{total}}(L_a) = C_{\text{base}} + C_{\text{comp}} > C_{\text{total}}(L_b),

則原始技術選擇發生補償過度反轉。

此時系統必須重新詢問：

\boxed{ \text{Why are we still in this technology domain?} }

7. 不要用流程補償可以由技術選型解決的問題

本文提出：

技術—流程替代判準

當一個問題可以由技術域本身提供穩定、一級、可重用的約束時，不應優先以大量人工流程與 Agent 儀式重複補償。

例如，如果系統真的要求：

強型別；
ownership；
memory safety；
可預測 native execution；
高 concurrency；
長期大型服務；

那麼應比較：

\text{Rust-first}

與：

\text{Python} + \text{typing} + \text{runtime guards} + \text{extensive tests} + \text{manual discipline}.

不是因為 Rust 必然獲勝，而是因為這是一個技術域比較問題，而不是「如何繼續把 Python 修好」的問題。

同理，如果目標只是：

資料分析；
小型自動化；
實驗；
ML prototype；
內部腳本；

硬塞 Rust 也可能只是：

C_{\text{compile}} + C_{\text{development}} + C_{\text{cognitive}} \uparrow

而沒有得到足夠收益。

因此：

\boxed{ \text{Process cannot substitute for domain selection indefinitely.} }

8. 語言—流程一致性原則

本文提出：

Language–Process Coherence Principle

令：

$L$ ：語言／Runtime；
$P$ ：開發流程；
$A$ ：Assurance requirement；
$T$ ：Task；
$C$ ：Context。

則工程選擇應共同最佳化：

\boxed{ (L^*,P^*) = \arg\max_{L,P} U(L,P\mid T,A,C) }

而不是：

L=L_0

先固定，再令：

P\rightarrow\infty

補償一切。

例如：

快速 MVP 域

A=\text{moderate}

可以是：

L=\text{Python / TypeScript}

搭配：

P= \text{Global Build} \rightarrow \text{Bounded Validation} \rightarrow \text{Repair}.

高可靠 Native 域

A=\text{high}

則可能更適合：

L=\text{Rust / C++ / suitable systems language}

再搭配相應 compile-time 與 integration verification。

技術與流程必須互補，而不是互相抵消。

9. 承載域—保證域一致性

一項工程需求不只有功能域，還有保證域。

定義：

G_R(T) = \{ g_1,g_2,\ldots,g_n \}

例如：

memory-safe
deterministic
low-latency
portable
sandboxed
transactional
reproducible

每個技術域本身能提供一組原生保證：

G_N(\mathcal D_T).

如果：

G_R(T) \subseteq G_N(\mathcal D_T),

則大部分保證可由底層直接提供。

若：

G_R(T) - G_N(\mathcal D_T)

非常大，則需要大量補償。

定義補償距離：

D_G = d \left( G_R, G_N \right).

則：

D_G\uparrow \Rightarrow C_{\text{compensation}}\uparrow.

因此本文提出：

\boxed{ \text{Prefer a substrate whose native guarantees overlap the required guarantees.} }

中文即：

優先選擇原生保證與任務要求高度重疊的承載域。

10. 技術域重選閾值

技術選型不是只能在專案第一天做一次。

隨著產品演化：

T_0 \rightarrow T_1 \rightarrow T_2,

需求也會改變。

因此需要動態判斷：

\operatorname{Fit} ( \mathcal D_T, T_t ).

本文定義技術域重選閾值：

\Theta_R.

當：

C_{\text{comp}} + C_{\text{verification}} + C_{\text{failure}} + C_{\text{maintenance}} - C_{\text{migration}} > \Theta_R,

或替代域 $D_j$ 滿足：

U(D_j,T_t) - U(D_i,T_t) > C_{\text{migration}},

則應正式進入：

\operatorname{DomainReassessment}.

其結果不一定是全面重寫。

可能是：

保持 Python UI / orchestration
+
將 hot path 移至 Rust

或：

TypeScript frontend
+
Rust service
+
Python ML pipeline

也可能只是換資料庫、Runtime 或 concurrency model。

重點是：

重新選域不等於整個產品重寫。

11. 多技術域不是失敗，而可能是正確分解

既然不同技術域具有不同優勢，成熟系統自然可能形成：

\mathcal S = \bigcup_i \mathcal D_i.

關鍵不是「是否只有一種語言」，而是：

C_{\text{boundary}} < B_{\text{domain-fit}}.

也就是：

多技術域帶來的 interface、FFI、deployment 與維護成本，是否小於各模組使用適合技術所取得的收益？

Nova 原始設計本身就大量依賴 FFI、Python、C/C++ 與 GPU kernel interoperablity，而不是假裝新語言可以立刻取代所有既有生態。

這也是為什麼：

\boxed{ \text{Polyglot} \neq \text{Architecture Failure} }

錯誤的是無理由地增加技術碎片，而不是所有多語言架構。

12. EML 的案例：成功 MVP 也可能造成底空間誤認

EML 是一個非常典型的案例。

早期 EML 工程成功建立：

EML
→ AST
→ semantic analysis
→ Python
→ execute
→ test
→ trace

但後續研究發現，這個成功的 Python MVP 逐漸造成產品定位縮窄：

EML
↔
Python

於是新版架構重新明確規定：

Python 是第一個 reference adapter，但不是 EML 本體。

最終判定甚至直接寫為：

成功的 Python MVP
≠
EML 的全部本體

並恢復 EML 為 Universal Semantic Overlay Protocol。

這說明：

\boxed{ \text{First successful implementation} \not\Rightarrow \text{Correct permanent substrate} }

早期選擇可以是：

\text{Bridge}.

但不能因為橋蓋成功，就宣布：

\text{Bridge}=\text{Destination}.

13. MVP 與最終技術域必須分開

這得到另一個重要命題：

MVP 技術非永久化命題

令：

D_{\text{MVP}}

為 MVP 最適域。

令：

D_{\text{scale}}

為規模化後最適域。

一般情況不要求：

D_{\text{MVP}} = D_{\text{scale}}.

因此合理產品生命週期可能是：

\text{Python MVP} \rightarrow \text{Product Validation} \rightarrow \text{Domain Reassessment} \rightarrow \text{Rust / C++ / Hybrid}.

這並不是「早期做錯了」。

如果 Python 讓：

T_{\text{market}} \downarrow,

而後續遷移成本仍低於早期就使用高成本技術的總損失，則 Python-first 仍可能是全生命週期最優解。

技術域先行論反對的不是暫時選擇。

它反對：

把暫時選擇神聖化成不可重新判斷的永久前提。

14. AI Agent 的技術域判斷責任

對高階 Coding Agent，本文主張新增一項架構責任：

\boxed{ \mathsf{SelectDomain} }

而不是只有：

\mathsf{Implement}.

其最小流程為：

Task understanding
↓
Domain requirements
↓
Technology candidates
↓
Fit analysis
↓
Select technology domain
↓
Global implementation

Agent 至少應評估：

這是 prototype、MVP 還是長期 production？
預期生命週期多長？
性能是否是一級需求？
memory safety 是否是一級需求？
concurrency 是否核心？
是否需要 native deployment？
生態依賴在哪裡？
使用者是否要求快速修改？
是否需要大量 AI 生成？
failure cost 多高？
哪些問題應由 compiler 解決？
哪些可以延後到 tests／runtime？
是否存在未來遷移路徑？

15. 高階 AI 不應只做 implementation optimizer

低階 Coding Agent 可以被簡化成：

A_{\text{local}} : (\text{task},\text{repo}) \rightarrow \text{patch}.

但高階 Agent 應具有：

A_{\text{architect}} : (\text{goal},\text{constraints},\text{system}) \rightarrow ( \text{domain}, \text{architecture}, \text{execution plan} ).

也就是：

\boxed{ \text{High-capability model} \Rightarrow \text{Architectural responsibility}. }

它應該能說：

「這個 Python 系統目前不是需要更多 wrapper，而是需要把某一個 performance-critical service 搬到 Rust。」

也應該能說：

「這只是內部 automation script，沒有理由把它做成 Rust。」

兩者都是架構判斷。

16. Agent 不應把所有問題都視為「目前技術下的修復問題」

本文提出四種不同問題類型：

16.1 Implementation Error

D\text{ 正確},\quad I\text{ 錯誤}

修 implementation。

16.2 Architecture Error

D\text{ 正確},\quad A\text{ 錯誤}

修架構。

16.3 Technology Domain Error

D\text{ 不再適合 }T.

重新選域。

16.4 Requirement Error

T\text{ 本身被錯誤理解}.

回到需求。

Agent 若將四者全部處理成：

\operatorname{PatchCode}()

就會產生大量補償性工程。

17. 底空間錯置

本文定義：

Substrate Misplacement

如果一個任務的自然約束集合為：

\Omega_T,

但承載技術要求額外建立大量補償：

\Omega_C,

且：

|\Omega_C| \gg |\Omega_T|,

則可能存在底空間錯置。

換句話說：

系統的大量工程複雜度不是來自產品問題本身，而是來自「我們選了什麼東西來承載產品」。

這就是為什麼某些系統看起來永遠在補：

wrapper
adapter
runtime guard
conversion
retry
validator
shim
compatibility layer

有時這是成熟生態必要的歷史代價。

但有時它只是：

\boxed{ \text{Wrong substrate} }

的症狀。

18. 驗證成本必須回饋技術選型

如果某技術域需要：

V(D)

的驗證成本才能達到要求的 assurance level，則技術選型成本不能只計：

C_{\text{implementation}}.

而應為：

\boxed{ C_{\text{domain}} = C_{\text{implementation}} + C_{\text{verification}} + C_{\text{debug}} + C_{\text{operation}} + C_{\text{migration}} + C_{\text{governance}}. }

這與 MACR 後來將 verification cost 納入 worker/model routing 的思想完全同構。

「便宜生成」不等於「便宜完成」。

同理：

容易寫的語言，也不等於完成整個生命週期最便宜的語言。

但反方向也成立：

編譯期保證更多，也不等於每個小型任務都值得支付那些成本。

19. 不要用最高保證域處理最低風險任務

技術域先行論同時反對另一個極端：

\text{Maximum Assurance Everywhere}.

若任務只是：

一次性資料轉換；
小型分析腳本；
內部 prototype；
研究 Notebook；
快速產品驗證；

則過度使用重型系統語言、形式驗證或複雜 deployment pipeline，也可能造成：

C_{\text{assurance}} > R_{\text{avoided}}.

因此：

\boxed{ A_{\text{technology}} \propto R_{\text{actual}}. }

這與全域完成論中的驗證比例原則一致。

20. Technology Domain Selection Matrix

對任務 $T$ ，可以建立：

\mathbf D(T) = [ S, P, M, C, L, E, I, R, G ]

其中：

$S$ ：Speed of development；
$P$ ：Performance；
$M$ ：Memory predictability；
$C$ ：Concurrency requirement；
$L$ ：Library ecosystem；
$E$ ：Deployment environment；
$I$ ：Interop requirement；
$R$ ：Failure risk；
$G$ ：Required guarantees。

候選技術域 $d_j$ 則具有：

\mathbf F(d_j).

匹配度：

\operatorname{Fit}(d_j,T) = 1- d ( \mathbf D(T), \mathbf F(d_j) ).

再考慮遷移與生態成本：

U(d_j,T) = \operatorname{Fit} - C_{\text{migration}} - C_{\text{ecosystem}} - C_{\text{verification}}.

選擇：

\boxed{ d^* = \arg\max_{d_j}U(d_j,T). }

此模型不是要機械計分，而是強迫 Agent 在動手之前回答：

為什麼選它？

21. 與全域完成論的整合

全域完成論提出：

\text{Global Coverage} \rightarrow \text{Global Refinement}.

技術域先行論在其前面新增：

\boxed{ \text{Domain Selection} \rightarrow \text{Global Coverage} \rightarrow \text{Global Refinement}. }

因此完整鏈變為：

\boxed{ \begin{aligned} \text{Intent} &\rightarrow \text{Scope}\\ &\rightarrow \text{Technology Domain}\\ &\rightarrow \text{Global Architecture}\\ &\rightarrow \text{Global Instantiation}\\ &\rightarrow \text{Validation}\\ &\rightarrow \text{Repair}\\ &\rightarrow \text{Completion}. \end{aligned} }

如果底空間錯了：

\text{Global Refinement}

只會更有效率地把錯誤方案做完整。

所以：

\boxed{ \text{Global Completion requires Global Technology Selection}. }

22. 五個核心命題

命題一：技術域先行命題

\boxed{ \text{Select substrate before optimizing implementation}. }

先決定問題應在哪裡被解，再決定怎麼寫。

命題二：語言非無限可修正命題

\boxed{ \operatorname{Refine}^{\infty}(L) \neq L' }

局部精修不能消除語言本體差異。

命題三：補償反轉命題

若：

C_{\text{compensation}}(L_a) + C_{\text{base}}(L_a) > C_{\text{total}}(L_b),

則應重新評估 $L_a$ 。

命題四：語言—流程一致性命題

\boxed{ (L,P,A) }

必須共同最佳化。

快速語言搭配無限高摩擦流程，可能抵消其原始優勢。

命題五：動態重選命題

技術選型不是一次性不可變決策：

D_0 \rightarrow D_1

可以是成熟工程的一部分，而不是失敗證據。

23. 對 AI Agent 的直接規則

未來 Coding Agent 應遵守：

1. 先確認任務域。
2. 再確認 assurance domain。
3. 比較候選技術域。
4. 說清楚為什麼使用目前語言／Runtime。
5. 若目前技術只是 MVP bridge，記錄其遷移條件。
6. 不要把所有新需求都解釋成「繼續修現在的 stack」。
7. 驗證成本若持續增加，重新檢查技術域。
8. 不要用流程模擬另一種語言本來就能提供的保證。
9. 不要為低風險工作支付高保證域的全部成本。
10. 選定域後，再開始 Global-First implementation。

24. 最終命題

本文最重要的問題不是：

Python 還是 Rust？

真正的問題是：

這件事究竟應該存在於什麼技術世界裡？

Python 有 Python 的適用域。

Rust 有 Rust 的適用域。

C++、TypeScript、Java、Go、Nova、SQL、Workflow Runtime 也各有不同的位置。

真正成熟的 AI 不應該把「已經開始使用某個技術」誤認為「這個技術永遠是正確答案」。

因此：

\boxed{ \text{Local implementation quality} \not> \text{Global technology fit}. }

一個錯誤承載域上的完美實作，仍然可能不如正確承載域上的普通實作。

而 AI 時代最大的改變之一，正是重新選擇、重寫、轉譯與遷移的成本正在快速下降。

因此 AI 原生工程不應只追求：

\text{write faster}.

而應進一步追求：

\boxed{ \text{choose better before writing faster}. }

結論

程式語言與技術棧不是專案開始時隨手選定、之後只能無限補丁的背景條件。

它本身就是全域架構的一部分。

當需求、規模、風險與產品生命週期改變，技術域也可以重新評估。

所以：

不要把 Python 修成 Rust。

如果真的需要 Rust 的問題域，就重新考慮 Rust。

如果只是要快速完成產品，也不要因為抽象的完美主義，把 Python 的速度優勢用無限驗證全部抵消。

技術域先行論最終要求的不是保守，而是匹配：

\boxed{ \text{正確的問題} + \text{正確的承載域} + \text{正確的流程} = \text{可有效完成的工程} }

這將成為下一篇「分層因果完成論」的前置條件：即使技術域已選對，Agent 仍必須知道哪些問題是宏觀、中觀或微觀，哪些局部錯誤真正具有全域因果權重，以及哪些微觀問題根本沒有資格阻塞整體完成。