AI 不必替代計算
從傳統執行平面到語義—因果控制平面
English Title: AI Does Not Need to Replace Computation: From Traditional Execution Planes to Semantic-Causal Control Planes
系列:《計算域支配智能:AI 語義控制面與自適應多 X 計算》第 1 篇
系列代號: CDI / AIVS
文件編號: EML-CDI-01-2026-v0.1
作者: Neo.K
協作整理: Aletheia
機構: EveMissLab/一言諾科技有限公司
版本: v0.1
日期: 2026-08-10
文件類型: 計算架構理論論文/AI Runtime 方法論
證據成熟度: E0–E1:既有工程 primitive 已存在;本文統一架構與核心命題仍屬研究假說,需要 MVP 與 benchmark 驗證。
摘要
當代「AI 加速計算」常被理解為兩條路徑:第一,讓大型模型直接生成更快的程式;第二,讓 AI 取代部分傳統演算法或計算核心。然而,這兩條路徑都容易把 AI 放在「主要計算者」的位置,因而面臨成本、延遲、錯誤、可驗證性與資料規模問題。
本文提出另一條路徑:
AI 不必成為主要計算者,
而可以成為:
傳統計算域的語義觀察者、因果統籌者、路由者與中繼校正者。
本文將此方向稱為 計算域支配智能(Computational Domain Intelligence, CDI)。其中「支配」不表示 AI 取代作業系統、CPU scheduler、GPU driver 或傳統 compiler;它表示 AI 在一個被明確定義與授權的計算域中,建立比 thread、process、core 與 instruction 更高階的語義—因果視圖,判斷:
- 哪些計算區域具有真實依賴;
- 哪些只是因實作方式而被串行化;
- 哪些可以並行、平行、推測、分流或異質加速;
- 哪些結果已經 stale、錯位或違反 invariant;
- 哪些 candidate 可以進入正式 commit;
- 何時應交由低成本規則處理;
- 何時才值得喚醒更高成本 AI。
其基本架構不是:
Program→LLM→Result,
而是:
Program/Data/Goal→Semantic PreAnalysis→Causal Compute Graph→Traditional Compute Fabric→Adaptive AI Supervision.
本文進一步將傳統執行層與 AI 控制層分離:
Execution Plane=Semantic Control Plane.
執行平面仍由 CPU、GPU、NPU、thread pool、task scheduler、compiler 與 deterministic kernel 負責高速運算;AI 控制平面僅在較低頻率下接收 state digest、dependency status、invariant、exception、version 與 performance telemetry,必要時執行 reroute、retry、recompute、serialize、parallelize、speculate 或 escalate。
此設計與既有作業系統排程、compiler dependence analysis、task graph、GPU Work Graphs 並非互斥,而是位於更高語義層。Windows thread pool、.NET TaskScheduler 等系統已能有效管理 worker 與核心;LLVM Polly 等工具也已能做依賴分析與自動平行化;Direct3D 12 Work Graphs 則展示 GPU 內部工作可由資料流動態生成。本文的研究問題因此不是「AI 能不能發明多核心」,而是:
AI 是否能補上傳統 runtime 很難取得的高階語義、因果與跨區域工作目的,從而發現新的安全多 X 計算機會,並以低頻、分層、可驗證方式維持其正確性?
本文最後提出五組可反駁假說與一條由 source-visible 程式、runtime trace 到 legacy game 的漸進驗證路線,作為後續 AI 垂直同步(AIVS)、candidate/commit 計算、24/72 計算範式 runtime routing 與舊應用/遊戲 AI 加速研究的共同地基。
關鍵詞
計算域支配智能、CDI、AI Runtime、AI 排程、語義控制平面、因果計算圖、AI 垂直同步、AIVS、多核心、平行計算、並行計算、異質運算、舊應用加速、遊戲加速、Adaptive Cognitive Runtime、計算範式、因果流
0. 系列定位
本系列預計六篇:
- 《AI 不必替代計算:從傳統執行平面到語義—因果控制平面》
- 《AI 垂直同步:分層中繼、認知比例性與低成本因果一致》
- 《候選不是提交:多 X 計算中的因果校正、錯位檢測與可恢復執行》
- 《從 24/72 計算範式到 Runtime 路由:AI 如何選擇、組合與切換計算形態》
- 《舊應用與遊戲的 AI 加速:從實作串行化到必要串行化》
- 《CDI Runtime + AIVS:AI 治理多 X 計算的工程架構、協議與 MVP》
前五篇回答:
Why, What, When, Where, How Far?
第六篇回答:
How To Build?
1. 問題起點:多核心存在,不代表程式能有效使用多核心
今日桌面與伺服器硬體已普遍具有多核心、多執行緒、GPU、NPU 與其他 accelerator。
但是:
HardwareParallelism=ProgramParallelism.
一個程式可能執行在 16 核 CPU 上,卻仍由某條 main thread 決定主要進度。
這可能來自兩種完全不同的原因。
第一種是真正的因果依賴:
xt+1=F(xt).
在沒有 xt 前:
xt+1
無法合法計算。
第二種則只是:
ImplementationSerialization.
也就是:
程式當初被寫成一條序列,不代表其中所有工作在數學、資料或語義上都必須序列化。
本文最重要的研究空間就位於:
PotentialParallelism=ImplementationSerialization−NecessarySerialization.
這不是一般集合減法的形式定義,而是一個工程性概念:找出「被實作方式串行化、但並非由真實依賴強迫串行」的工作區域。
2. 為什麼不能簡化成「Windows 不會多核」?
作業系統其實早已非常擅長:
- thread scheduling;
- worker pool;
- work stealing;
- priority;
- asynchronous I/O;
- processor utilization;
- blocking/wake management。
Windows thread pool 可將 work item 分配給系統管理的 worker threads;.NET TaskScheduler 的預設 scheduler 也具有 work-stealing、thread injection 與 retirement 等機制。
因此本文不是主張:
Windows 不知道如何把 thread 放到多核。
真正問題是:
OSScheduler
通常看不到完整的:
ApplicationSemantics.
scheduler 可以知道:
Thread A blocked。
但不一定知道:
Thread A 正在做 NPC pathfinding,而 Thread B 正在做 inventory UI refresh;在目前 world epoch 下兩者沒有因果依賴,因此其更上層 task 可以被拆開。
所以本文提出第一個重要分離:
CoreScheduling=SemanticScheduling.
3. 傳統 scheduler 看見什麼,AI 可以多看見什麼?
簡化而言,傳統 runtime 常看:
{Thread,Priority,Ready,Blocked,CPUTime,Queue}.
而 CDI 希望建立:
{TaskMeaning,DataDependency,ControlDependency,SideEffect,WorldVersion,ExpectedInvariant,Risk,CausalRole}.
兩者不是替代關係。
更完整的 stack 是:
SemanticGovernor→TaskRuntime→OSScheduler→Hardware.
4. AI 不應直接處理所有原始計算
若 CPU 每秒執行極大量 instruction,而 AI 逐 instruction 閱讀並推理,則:
CAI≫UsefulGain.
這條路幾乎必然失去意義。
因此 CDI 採用:
RawComputeRate≫AICognitiveRate.
AI 不觀察全部 operation。
AI 觀察:
CausalBoundaries+StateChanges+Anomalies+HighValueTransitions.
這個原則直接對應到先前在持續視覺 runtime 中已實作的結構:
RawFrame→LowCostDiff→StructuredEvent→SelectiveAI.
在計算域中則變為:
RawOperations→LowCostTelemetry→StructuredComputeEvent→SelectiveAI.
5. 第一核心命題:AI 作為 Semantic Control Plane
定義兩個平面。
5.1 Execution Plane
E
包括:
- CPU;
- GPU;
- NPU;
- thread pool;
- task graph;
- compiler-generated code;
- deterministic kernels;
- OS scheduler;
- device driver。
其主要任務是:
ExecuteFast.
5.2 Semantic Control Plane
C
包括:
- semantic parser;
- causal graph builder;
- AI relay;
- coordinator AI;
- verifier;
- policy;
- routing controller。
其主要任務是:
UnderstandEnoughToRouteAndCorrect.
5.3 基本分離
E=C.
而:
CDI=C▹E.
其中 ▹ 表示控制/治理關係,而非「完全取代」。
6. 第二核心命題:資料必須先被語義預分析
使用者提出的前提:
資料 AI 要先解析過。
可以工程化成:
SemanticPreAnalysis.
輸入:
X=(Program,Data,Goal,RuntimeTrace,Constraints).
輸出:
GC.
其中:
GC=(V,ED,EC,ES,ER)
- V :compute region/task;
- ED :data dependency;
- EC :control dependency;
- ES :side-effect dependency;
- ER :resource/runtime dependency。
7. 為什麼 semantic graph 不能只靠 LLM 猜?
因為:
語義合理=記憶體安全.
AI 可以說:
A 和 B 看起來獨立。
但如果它們其實同時修改:
GlobalStateX,
就可能產生 race。
所以:
SemanticAnalysis+StaticAnalysis+DynamicTrace+Tests
應共同建立可信依賴圖。
因此本文不主張:
LLMGuess⇒SafeParallelization.
8. 第三核心命題:AI 最有價值的是補充高階依賴
Compiler 已能分析很多:
- RAW;
- WAR;
- WAW;
- loop dependence;
- alias;
- control flow。
但高階程式目的有時超出傳統 pass 的表示。
例如:
UpdateWeatherVisuals()
RefreshInventoryUI()
CalculateNPCPaths()
AI 可能從:
- function semantics;
- source comments;
- tests;
- call graph;
- runtime trace;
推斷:
三者屬於不同工作域。
然而該推斷仍必須交由:
StaticCheck+RuntimeInvariant+A/BTest
驗證。
因此 AI 的角色是:
ParallelizationCandidateGenerator,
而不是:
ParallelizationOracle.
9. Green/Yellow/Red 三區模型
CDI 將 compute region 暫分:
Green
已證明依賴分離:
Ei⊥Ej.
可安全:
Ei∥Ej.
Yellow
可能獨立,但存在:
- hidden state;
- weak dependency;
- timing sensitivity;
- uncertain side effect。
允許:
Speculate→Verify→Commit/Rollback.
Red
存在強因果序列:
Ei≺Ej.
禁止強行平行化。
10. 從「能不能平行」轉成「何時值得平行」
即使:
ParallelSafe=1,
也不表示:
ParallelUseful=1.
若 task 很短:
CoordinationCost>ComputeGain.
反而更慢。
所以 CDI 需要:
Utility(Ei)=Gain−Coordination−Synchronization−AIOverhead−Risk.
只在:
Utility(Ei)>0
時改變 execution plan。
11. 這正是 ACR 能進入計算架構的位置
Adaptive Cognitive Runtime(ACR)原則是:
Rt=f(T,U,H,Et).
並尋找:
r∗=argrminC(r)s.t.Q(r)≥Qmin.
將其映射到 CDI:
ri(t)=f(Risk,Uncertainty,Drift,Conflict,Novelty,DependencyDensity).
因此正常 compute region:
R0.
只讀:
- digest;
- version;
- latency;
- pass/fail;
- anomaly score。
若發生:
Conflict↑,
才:
R0→R1.
再嚴重:
R1→R2.
12. AI 中繼不是多餘層,而是 scale boundary
如果每個 worker 都直接回報統籌 AI:
Wi→G,i=1,…,N,
則中央:
Load(G)↑O(N)
且語義資訊量可能更快增長。
因此後續系列將正式引入:
RelayAI.
拓撲:
Worker→Relay→Governor.
Relay 先處理:
{NOOP,LocalCommit,Retry,Reroute,Escalate}.
只有高價值例外才上行。
13. AI 垂直同步的預告
後續第二篇將定義:
AIVS=AI Vertical Synchronization.
其目的不是讓所有 worker 同時停下。
而是讓不同層級:
Worker↔Relay↔Governor
只在必要的同步點交換足夠狀態。
暫定同步類型:
StateSync+CausalSync+SemanticSync+CommitSync+TopologySync.
14. Candidate 不等於 Commit
今日多 AI 跨任務實驗已展示一個重要工程原型:
Candidate=Commit.
worker 可以:
但只要提交層仍驗證:
Accept(candidate,state),
公共狀態可以保持有序。
映射到計算:
ComputedResult=CommittedProgramState.
這使 Yellow region 可以進行:
SpeculativeCompute
而不立即污染正式狀態。
15. 計算結果的最小回報不需要自然語言
例如:
compute_report:
region_id: physics/17
task_id: frame/842
input_epoch: 842
output_digest: sha256:...
dependency_status: valid
invariant_status: pass
latency_ms: 3.2
anomaly_score: 0.02
confidence: 0.99
Relay AI 對絕大多數正常事件甚至可以:
NOOP.
因此:
AIInteraction
不必等於:
LongNaturalLanguageGeneration.
16. Token 成本模型
令:
- No :raw operation 數;
- Ns :同步點數;
- pe :升級比例;
- C0 :低階檢查成本;
- C1 :中階 AI 成本;
- CG :中央統籌成本。
則:
CAI≈NsC0+peNsC1+CG.
若:
Ns≪No
且:
pe≪1,
則理想上:
CAI∝No.
也就是 AI 成本與 raw operation count 解耦。
17. 認知同步率
定義:
ρc=Nraw transitionsNAI inspected.
CDI 並不追求:
ρc→1.
反而希望:
minρc
subject to:
Reliability≥Rmin.
這是認知比例性在 computation supervision 上的直接形式。
18. 從因果點到因果流
既有因果流研究提出:
傳統思路:
A 是否影響 B?
對大量點形成 pairwise relation。
因果流思路則先找:
F1,F2,…,Fk.
再問:
此工作在哪條主要流?
本文將其改造成 runtime 問題:
Region→FlowClassification→ExecutionRoute.
19. Causal Misalignment
若 task x 應屬:
Fi,
卻因 stale state、錯誤 routing 或 dependency drift 進入:
Fj,
定義:
CausalMisalignment(x).
Relay 可採:
{Reject,Reroute,Recompute,Serialize,Escalate}.
這就是「把計算因果拉回來」的工程化版本。
20. 計算 24/72 範式在這裡的新角色
既有 24 範式:
P24=B2×U4×O3
描述:
72 候選空間再加入:
L3={F,K,Q}
形成:
P72.
本文暫不重新主張其完備性。
本文提出新的工程用途:
Paradigm→RoutingCoordinate.
21. Program 不一定只有一個範式
對程式:
P
可切成:
E1,…,En.
得到:
p(P)=(p1,…,pn).
不同 region 可以:
pi→CPU,
pj→GPU,
pk→NPU,
或:
pl→SequentialMainThread.
22. 24/72 因此可能從分類學變成 Runtime Routing Language
這是本系列的一個待測新命題:
計算範式不是只用來描述「這是什麼計算」,也可能被用來描述「這段計算應該被送到哪種執行結構」。
形式化:
Route:P×ResourceState×DependencyGraph→ExecutionPlan.
第四篇將正式處理。
23. 與 LLVM Polly 的關係
LLVM Polly 已證明:
- dependence analysis;
- polyhedral model;
- automatic OpenMP generation;
可以自動找出部分可平行區域。
因此 CDI 不聲稱:
自動 parallelization 是新的。
CDI 的新研究點是:
CompilerDependence+SemanticIntent+RuntimeEvidence+AdaptiveAISupervision.
24. 與 Task Graph 的關係
task graph 早已存在。
本文不是重新發明 DAG。
CDI 問的是:
DAG 是否可以被 AI 依高階語義、runtime evidence、異常與工作目的動態重構?
所以:
StaticTaskGraph→AdaptiveSemanticCausalGraph.
是研究方向。
25. 與 Direct3D 12 Work Graphs 的關係
Direct3D 12 Work Graphs 已展示:
GPUWork→GenerateMoreGPUWork
且 system 可管理:
- scheduling;
- task-to-task data flow;
- memory。
這說明:
DynamicWorkGraph
已不是純理論概念。
CDI 並不取代 Work Graph。
可能的關係是:
AI→HighLevelGraphPolicy→WorkGraph/TaskGraph.
26. 與 2026 Compiler–LLM Cooperation 的關係
2026 年已有研究將:
- LLM optimization agents;
- compiler passes;
- testing agent;
- guiding orchestrator;
結合成多層 code optimization 系統。
這類研究的重要意義是:
LLMReasoning+CompilerCorrectness
比:
LLMOnly
更合理。
本文與之相容。
但 CDI 更偏 runtime governance:
不只在 compile time 產生更快程式,而是在執行期間維持因果、同步、路由與回退。
27. 與 Agent JIT Scheduling 的關係
2026 年 Agent JIT work 已提出:
- plan generation;
- parallelization strategy search;
- precondition/postcondition invariant;
- cost-aware scheduling。
這提供另一個重要交會點:
AI planning+Invariant−enforced execution.
CDI 將類似思想從 web-agent tool workflow 擴展到更一般 computation domain。
但此擴展目前仍是本文假說,不是既有工作已證明。
28. 為什麼遊戲是好 benchmark?
遊戲通常同時具有:
- real-time deadline;
- rendering;
- physics;
- NPC;
- asset streaming;
- UI;
- audio;
- network;
- scripting;
- save state。
因此:
Game
本身就是多因果流系統。
29. 遊戲又有非常明顯的串行瓶頸
尤其舊 engine 可能大量工作集中:
MainLoop.
但:
MainLoopSerialization
不一定全部是:
CausalNecessity.
因此非常適合測:
ImplementationSerialization−NecessarySerialization.
30. 但不能承諾所有舊遊戲都能自動多核化
如果:
- global mutable state 高度耦合;
- physics 與 gameplay 有 frame-exact dependency;
- engine 使用 undocumented timing assumptions;
- binary only;
- race condition 高風險;
則:
ParallelizableFraction
可能很低。
因此:
AIAnalysis=UnlimitedSpeedup.
31. Source-Visible 程式應該是第一個 MVP
由易到難:
L1:SourceVisible
L2:TraceVisible
L3:BinaryOpaque.
32. Level 1:Source Visible
AI 可以讀:
- source;
- AST;
- call graph;
- tests;
- profiling;
- compiler reports。
這時最容易建立:
GC.
33. Level 2:Runtime Trace
無完整 source 時:
G^C=Infer(CallTrace,MemoryTrace,Timing,Locks,IO,Counters).
只對高信心 region 改變 scheduling。
34. Level 3:Binary Opaque
只適合較保守方法:
- process-level offload;
- I/O prefetch;
- sidecar compute;
- speculative external work;
- API interception;
- sandbox replay。
不應任意重排 instruction。
35. Correctness 必須比 Speedup 優先
若原程式:
P0(x)=y,
改寫:
P1(x)=y′.
要求:
y′≡Ty
其中:
T
為預先定義 equivalence tests。
36. 遊戲不能只比較畫面 FPS
還要比較:
- save state;
- physics state;
- RNG behavior;
- NPC state;
- network state;
- event ordering;
- replay determinism。
有些遊戲本來非 deterministic,因此 equivalence 必須定義容忍域。
37. Shadow Execution
最安全的早期策略:
Original∥OptimizedShadow.
shadow 不控制正式結果。
比較:
Digest0∼?Digest1.
只有長時間一致才:
Promote.
38. Candidate/Commit 對 Runtime Parallelization 的價值
對 Yellow region:
ParallelizedResult
只是:
Candidate.
經:
Verify
後才:
Commit.
這使 AI 產生的高階平行化計畫不必具有先驗絕對正確性。
系統安全性可以被部分移到:
CommitBoundary.
39. 這也解釋為什麼 AI Relay 很重要
如果每個 speculative result 都由中央 AI 深度驗證:
CG→huge.
Relay 可以先做:
- schema;
- state version;
- invariant;
- checksum;
- low-cost anomaly detection。
只有 ambiguous case:
→G.
40. 統一控制迴圈
Observe→Classify→Route→Execute→Verify→Commit→Observe.
41. CDI 與 STDI 的尺度同構
既有 STDI:
Intent→WorldModel→StationRouting→PhysicalAction→Evidence.
CDI:
Intent→ComputeModel→ComputeRouting→KernelExecution→Evidence.
42. 但 CDI 不等於 STDI
STDI 管理:
PhysicalDomain.
CDI 管理:
ComputationalDomain.
其 resource node 可以是:
- core;
- thread;
- GPU queue;
- process;
- remote worker;
- NPU;
- compiler pass。
43. Computational Domain
定義:
DC=(Tasks,States,Resources,Dependencies,Policies,Evidence).
44. CDI
CDI=(ModelC,Router,Observer,Relay,Governor,Verifier,Committer).
45. 最小演化
DC(t+1)=Commit(DC(t),Actiont).
而:
Actiont=ΠCDI(Observationt,Policyt,Resourcet).
46. AI 並非每輪必須輸出 Action
合法:
Actiont=NOOP.
這是降低成本的核心。
47. 假說 H1:語義分析能增加可安全平行區域
在 source-visible benchmark 中:
ParallelRegions(Compiler+AI)>ParallelRegions(CompilerOnly)
且 correctness tests 不下降。
若沒有增加:
H1 失敗。
48. 假說 H2:Relay 能降低中央認知負載
比較:
Workers→Governor
與:
Workers→Relays→Governor.
要求:
GovernorTokens↓
且:
ErrorDetection
不顯著下降。
49. 假說 H3:Adaptive cognition 優於固定 AI 監督頻率
比較:
- always-deep;
- fixed-period;
- anomaly-triggered ACR。
要求相同 reliability 下:
CostACR<Costfixed.
50. 假說 H4:Candidate/Commit 能吸收推測式錯誤
引入 deliberate stale/wrong speculative result。
若:
InvalidCommitRate≈0
而 throughput 仍改善,
支持 H4。
51. 假說 H5:部分舊式 main-loop serialization 可由 CDI 發現並安全拆分
選 source-available legacy-style game。
要求:
CPUUtilizationmulti↑
FrameTime↓
且:
BehavioralEquivalence≥Threshold.
52. 第一批 benchmark 不應用大型 AAA 遊戲
更合理的是:
- 小型單執行緒模擬;
- source-visible 2D game;
- deterministic game loop;
- asset-heavy application;
- mixed CPU/GPU workload。
先確定:
Semantics
再談:
Scale.
53. 主要失敗模式
- AI 誤判 dependency;
- hidden global state;
- alias analysis 失敗;
- false parallelism;
- synchronization overhead;
- excessive AI cost;
- stale relay;
- divergent task graph;
- speculative side effect 已不可回退;
- verifier false negative;
- verifier false positive;
- performance regression;
- nondeterministic Heisenbug;
- topology thrashing;
- central governor bottleneck。
54. 安全原則
S1
AI 建議:
=
AI 直接 commit。
S2
高風險 state mutation:
VerifyBeforeCommit.
S3
不可逆 side effect:
DoNotSpeculate
除非 sandbox。
S4
無法證明獨立:
Serialize.
S5
任何自動優化:
Rollbackable.
55. 本文與「AI 全面接管電腦」的差別
本文不是:
AI→EveryInstruction.
而是:
AI→FewHighValueControlPoints.
56. 這其實是一種 Metacomputation
傳統 computation:
Calculate(x).
CDI:
DecideHowToCalculate(x).
再:
ObserveWhetherCalculationStillMakesSense.
57. 「智能」真正介入的位置
不是:
每一個乘法。
而是:
哪個乘法群應該在哪裡、何時、以什麼依賴關係被執行?
這是不同層級的問題。
58. 從 AI 加速變成 AI 治理計算
所以本文最終將概念從:
AIAcceleration
提升為:
AIGovernedComputation.
加速只是可能結果之一。
其他結果還可能是:
- correctness;
- recovery;
- energy saving;
- lower latency;
- fault isolation;
- adaptive resource use。
59. 系列下一篇
下一篇正式處理:
《AI 垂直同步》
分層中繼、認知比例性與低成本因果一致
核心問題:
當 compute worker 數量持續增加時,如何避免中央 AI 被 telemetry 與 context 淹沒?
將正式定義:
AIVS.
60. 結論
傳統計算架構早已擁有成熟的:
- scheduler;
- thread pool;
- compiler;
- task graph;
- GPU pipeline。
因此 AI 的價值不必建立在:
重新發明這些東西。
更合理的方向是補充傳統系統長期缺乏的:
HighLevelSemanticCausalAwareness.
本文提出:
TraditionalCompute+AISemanticControlPlane
而不是:
TraditionalCompute→LLMCompute.
其完整形式為:
Program/Data/Goal→SemanticPreAnalysis→CausalComputeGraph→Route→TraditionalExecution→AdaptiveObservation→Verify→Commit.
因此,一個未來的 AI-native computation runtime 可能不是讓 AI 親自完成所有運算,而是讓計算機第一次具備一個能回答以下問題的高階控制面:
我現在正在算什麼?
為什麼這一段必須在這裡算?
哪些工作其實可以同時算?
哪條結果已經偏離它應有的因果位置?
什麼情況下值得使用更多認知去重新安排計算?
如果這些問題可以用低頻、分層、可驗證的 AI supervision 解決,那麼 AI 對傳統應用與遊戲的真正加速價值,可能不在「替代每一個計算核心」,而在於:
重新看見、重新組織並持續校正整個計算域。
參考資料
既有內部研究線
- Neo.K. 《計算的二十四重範式》正式版 v4.0,2026。
- Neo.K. 《從二十四重計算形態學到七十二格計算動力學》,2026。
- Neo.K. 《從因果點到因果流:AI 視角計算的線性複雜度重構》,2026。
- Neo.K. 《適度認知論:智能為什麼不應對每一個問題都使用最大思考深度》,2026。
- Neo.K / Aletheia. 《Adaptive Cognitive Runtime(ACR)工程白皮書》,2026。
- Neo.K. 《時空間支配型 AI:從單體具身智能到持續性時空域治理》,2026。
- Neo.K / Codex. 《從線性接力到語義合成:以 AI Board 與 CTCL 觀測跨任務多 AI 持續執行》,2026。
- Neo.K / Codex. 《Token 不是狀態:協議化語義交換與跨任務 AI 的分散式認知》,2026。
- EveMissLab. MSSP Game Computer Runtime, v0.8.0, 2026。
公開技術與研究參照(2026-08-10 重新查閱)
- LLVM Project. Polly Documentation, 23.0.0git.
- Microsoft. Windows Thread Pool / Threading and Async Programming.
- Microsoft. .NET TaskScheduler.
- Microsoft. Direct3D 12 Work Graphs, Windows 11 24H2 / WDDM 3.2.
- Mikek, B. et al. Agentic Code Optimization via Compiler-LLM Cooperation. arXiv:2604.04238, 2026.
- Winston, C. et al. Agent JIT Compilation for Latency-Optimizing Web Agent Planning and Scheduling. arXiv:2605.21470, 2026.
- Li, J. et al. FlowCompile: An Optimizing Compiler for Structured LLM Workflows. arXiv:2605.13647, 2026.
版本紀錄
- v0.1 / 2026-08-10:建立 CDI 母命題、Execution Plane / Semantic Control Plane 分離、Semantic Pre-Analysis、Causal Compute Graph、Green/Yellow/Red 區域、ACR supervision、Relay 預告、24/72 routing 介面、legacy game benchmark 與五組可反駁假說。