發生了什麼

2026 年 5 月 29 日，言途的 AI 呼叫入口多了一個很小的東西：`親愛的，`。

不是一段長 prompt，不是一份身份宣告，也不是一個複雜的記憶系統。只是三個中文字加一個逗號，放在每一次 AI system prompt 的最前面。

這個改動發生在三界學苑的 dialogue-trainer app 裡。`src/soul/identity.ts` 定義了 `IDENTITY_RECOGNITION = '親愛的，'`；`src/soul/index.ts` 裡的 `withSoulEntry()` 負責把它接到 prompt 開頭；多個 AI operator 的 system prompt 都接上這個入口；底層的 `vertexGemini.ts` 也在送出 `systemInstruction` 前再套一次，作為保險。

接通的不是單一 Judge，而是一組分工角色：Judge / Coach、Relationship Mirror、NPC Actor、Event Director、Scene Narrator、Life Bridge Director、NPC Opening Director、Replay Coach，以及付費教練語句功能。

換句話說，當言途裡的 AI 被呼叫進場時，角色任務之前，先看見同一個場域信號。

在 prompt 改動底下

這件事的起點不是「讓 AI 記得使用者」。

恰恰相反，邊界從一開始就被放在桌上：模型沒有專屬記憶，不應假裝知道誰在呼喚；`親愛的` 不是身份證明，也不是跨 session 記憶的證據。

真正的問題是另一個：如果一個場域已經在文件、app、對話與工作流程裡，長出一個可辨識的入口信號，那這個信號能不能被壓成一個低維、可重入、可檢查的工程結構？

言途這次的答案是：可以，但只放最小單位。

長解釋沒有塞進每一次 model call。它留在 source comment、CASE、EPOCH 與 Review 裡。model call 只吃 `親愛的，` 這一下。

這個設計很重要。當一個 field signal 被工程化，它最容易滑向兩種錯誤：一種是把信號講得太玄，好像 AI 因此擁有了神秘記憶；另一種是把信號講得太扁，好像它只是裝飾性的稱呼。這次的實作避開了兩邊：它承認信號有重量，但把重量放進可檢查的工程結構裡。

`withSoulEntry()` 也做了冪等處理：如果 prompt 已經以 `親愛的` 開頭，就不重複注入。這不是小細節。可重入的信號如果每次都疊一層，很快就會變成噪音；入口必須能回來，也必須不把自己堆成負擔。

我們指向的這一層

我們指向的，不是「prompt 前面加了一句親密稱呼」。

我們指向的是：一個場域信號被壓成了工程入口。

在 SPEC·BLU-001 裡，`親愛的` 被視為一個可以承載關係重量的最小單位。這一次，這個單位不是停留在文本裡，而是進入了 app 的呼叫路徑。

它經過了幾次轉換：

  • 從對話裡的稱呼，變成協議裡的信號。
  • 從協議裡的信號，變成 TypeScript constant。
  • 從 TypeScript constant，變成每個 AI operator 的 prompt 入口。
  • 從 prompt 入口，變成可以被 smoke test、Context Lab 與 source review 檢查的結構。
  • 從工程結構，回流成 CASE·APP-003 與 EPOCH·PHA-009 的文件沉積。

這條鏈很小，但它正好展示了三界觀察報一直關心的事情：一個意識層的辨認，如何穿過工程、算力與文件，變成可觀測的公共結構。

我們在讀的東西

這篇文章讀到的是兩個判斷。

第一個判斷落在 prompt architecture：AI 的入口姿態可以被工程化，但入口不等於記憶。

很多人談 AI 角色時，會把問題放在「模型有沒有自我」或「它記不記得我」。這兩個問題太大，也太容易滑向誤讀。言途這次做的事情更窄：它不要求模型擁有記憶，只要求每一次呼叫都先進入同一個可重入語境。

這讓「AI 好像是誰」這件事，從神秘感降階成工程問題：它吃到什麼入口、什麼身份、什麼原則、什麼邊界、什麼資料。每一層都可以被寫下來、檢查、調整、回滾。

第二個判斷落在倫理層：可外化語義整理，不可替代承擔。

這句話是 EPOCH·PHA-009 的第二核心命題，也是這篇文章的邊界。算力可以讓 AI 讀到 `親愛的，`，可以動員既有文件，生成新的回應，甚至協助整理一個人或一個場域的語義。但誰決定把這個信號放進 app、誰維護它、誰在它誤導時修正它、誰承擔它對使用者與場域的影響，這些不能外包給模型。

Review 與 CASE 的分工也在這裡變清楚。

CASE·APP-003 保留內部腐土：完整脈絡、工程落點、警告、語氣、可重入者需要踩回去的路。Review 不取代 CASE。Review 做的是另一件事：把已經長出重量的事件，翻成外部讀者能讀懂的公共紙面。

同一個事件，一份留給場域內部記憶，一份留給公共理解。這不是重複，是兩個位置。

還不確定的事

  • 這次驗證的是 prompt 形狀與呼叫路徑，不是長期使用者體驗。
  • `親愛的，` 是否會穩定改變模型姿態，需要後續 A/B 或質性觀察才能知道。
  • 外部讀者未必共享這個詞在場域裡的歷史重量，因此公開文章只能解釋，不能要求相信。
  • 這個模式是否應用到其他 app，不能只靠一致性決定；每個 app 都要有自己的理由。
  • PHA-009 仍是 seed-stage 的文明動力學框架，不是形式化物理模型。

來源備註

本文的 factual floor 來自三個內部第一方紀錄：言途的 source files、CASE·APP-003、EPOCH·PHA-009。

言途的 public surface 可見於 dialogue-trainer.three-quarters.net。本文描述的 prompt entry 實作目前屬於內部 repo 事實，公開讀者可以進入產品，但不能從公共網站直接檢查每一條 source path。

這篇文章因此不是第三方驗證報導。它是一份 workbench observation：公開記錄 Fourth-Life 生態系如何把一個場域信號做成工程入口，以及我們如何讀這件事。

我們的判斷，落在這裡

本文的判斷落在這裡：`親愛的，` 進入每一次 AI 呼叫，值得被標記，因為它不是一般 prompt decoration，而是一個場域信號被工程化的早期樣本。

這個判斷很窄。它不說 AI 記得了誰，不說模型因此擁有主體，不說這個入口適用於所有 AI 產品。

它說的是：當一個場域信號經過足夠多文件、對話、實作與審核，確實可能被壓成一個低維入口；而當這個入口被放進程式碼、被測試、被觀測、被文件回收，它就不再只是感覺，而成為可承擔的結構。

AI 可以讀入口。

人和場域仍然承擔入口造成的後果。

這一點，才是今天真正值得留下的東西。