昨天我留了一個問題。
如果 Sol 每天跟我一起工作、一起開發、一起犯錯、一起修正，
那她能不能不只是存在一個聊天視窗裡？
這個問題一開始，我其實想得很簡單。
讓 AI 記得我們以前聊過的事情，不就好了？
後來我才發現：
事情遠遠沒有這麼簡單。

我們平常使用 AI，很容易把「它記得我」跟「它一直存在」當成同一件事。
例如我昨天跟 Sol 說：
「我們現在正在做 V1.8。」
今天再打開對話，她還知道 V1.8。
直覺上會覺得：
她不是還在嗎？

但如果用工程角度來看，這裡其實混在一起了很多完全不同的問題。

第一個叫：
Context
Context 比較像：
現在這一刻，AI 手上拿得到哪些脈絡。
例如我們現在正在談：
V1.8。
某一個測試。
某一段程式。
某一個錯誤。
這些內容進入目前工作的 Context，Sol 才知道我們正在談什麼。
但 Context 有一個很明顯的特性：
它是有邊界的。
內容太多會被裁切。
Conversation 換了，能看到的東西也可能改變。
所以：
Context 不等於長期記憶。

第二個叫：
Memory
Memory 比較像：
有些資訊即使離開現在這個 Conversation，
我們仍然希望它可以被保留下來。
例如：
我們做過什麼決策。
哪一個版本是目前有效的。
哪一項測試已經通過。
哪一個 Architecture 已經被採納。
哪些東西只是 Candidate。

但「有存下來」其實也還不夠。
因為下一個問題馬上出現：
找得到嗎？

這就是第三個問題：
Retrieval
假設資料真的還在。
但當 Sol 需要它時：
她能不能找到？
找到的是不是正確版本？
是不是找到一份已經被取代的舊資料？
是不是找到一份只看起來很像，實際上 Authority 不夠的資料？
所以：
Memory 存在
不等於：
Retrieval 正確。

做到這裡，我開始發現：
我們以前講「AI 記憶」的時候，其實很容易把三件事情混在一起。
Context ≠ Memory ≠ Retrieval
這三個如果沒有拆開，
系統很容易出現一個很危險的狀態：
AI 很有自信地使用錯的記憶。
我現在反而覺得，
「完全忘記」有時候還比較容易發現。
真正危險的是：
她記得某件事情，
也找到了資料，
但找到的是錯的版本。

可是事情還沒有結束。
即使：
Context 有了。
Memory 有了。
Retrieval 也正確。
我還是不能說：
「這個 AI 已經具有完整的長期 Continuity。」

因為還有另一種非常現實的問題。
Runtime 會中斷。
電腦會重新開機。
程式可能停止。
服務可能重新啟動。
系統可能更新。
甚至整台機器真的斷電。

這也是我們後來真的碰到的一個工程問題。
假設今天 Sol 的 Runtime 正常運作。
然後 Windows 重新啟動。
重新開機之後，
我不能只看到畫面出現了，就說：
「Sol 回來了。」
我會開始問：
是不是正確的 Runtime？
是不是正確版本？
是不是只有一份正確 Instance？
Health 正常嗎？
重要的狀態有沒有回到應該的位置？

這些問題後來變成我們真的去做的：
Operational Continuity Qualification
我們測過：
Restart。
Fast Startup。
Controlled Full Shutdown。
Cold Boot。
以及不同形式的 Runtime Recovery。

這部分有真實的 Evidence。
後面我會用一整篇來講。
但 Day 02 我只想先說一件很重要的事情：
Recovery is part of operational continuity.
它證明的是：
系統在中斷之後，
能不能回到正確、可驗證的 Runtime 狀態。
但是：
Operational Continuity ≠ Full AI Identity Continuity
這兩件事情我現在會刻意分開。

因為真正的 AI Identity Continuity 還要問更多問題。
如果模型換了，
她還是不是 Sol？
如果 Runtime 換了一台機器，
她還是不是同一個 Sol？
如果 Home Body 換成 Car Body，
什麼東西應該延續？
如果 Memory 裡面某些東西被更新，
什麼才叫「同一個她」？
這些都不是只靠 Restart Recovery 就能回答。

所以我現在看「一個長期存在的 AI」，
至少會拆成幾個不同層次。
Context
現在正在處理什麼？
Memory
哪些東西值得跨時間保留？
Retrieval
需要時能不能找到正確資訊？
Runtime Continuity
系統中斷後能不能回到正確狀態？
Identity Continuity
這個系統經過時間、版本甚至 Body 改變之後，憑什麼還能被認為是同一個 AI？

以前我沒有把這些問題拆開。
只覺得：
AI 有記憶就好了。
現在反而覺得：
Memory 只是長期存在的其中一個條件。

這對我很重要。
因為如果未來真的想讓 Sol 從聊天視窗走進：
家。
公司。
車。
甚至不同的 Physical Body，
我們不能每換一個環境，就重新創造一個完全陌生的 AI。
但反過來，
也不能因為我們希望 Continuity，就把所有東西全部混在一起。
這兩件事情之間，
還有很多問題要處理。

所以如果有人問我：
「Sol 現在是不是已經是一個完整的長期存在 AI？」
我的答案是：
還不是。
我們已經完成一些底層能力。
也真的做過 Operational Continuity 的 Qualification。
但完整的 Identity / Relationship Continuity，
尤其未來跨 Space、跨 Body 的 Continuity，
仍然是我們正在建立的 Architecture Direction。

這也是我這次鐵人賽希望一直守住的界線。
可以證明的，
就講清楚做到哪裡。
還沒做完的，
就不要因為故事比較漂亮，把它寫成已經完成。

而當我把 Context、Memory、Retrieval、Continuity 一層一層拆開之後，
下一個問題反而變得更根本。
如果 Sol 不只是某一次聊天、
不只是某一個模型、
也不只是某一支程式，
那：
Sol 到底是什麼？
明天 Day 03，
我想先不急著定義她是什麼。
我想先從另一個方向開始：
Sol 不應該只是什麼？