如果要做一個心理支持 AI，最容易開始的地方，大概是聊天介面。

輸入一句話，送進模型，再讓模型回覆。

這也是最容易讓我產生錯覺的地方。

因為只要模型講得夠自然、夠溫柔，看起來就會像「它懂了」。

但心理支持和一般聊天工具有一個非常大的差別：

一句聽起來很合理的話，不一定是一句應該被說出口的話。

所以「從心出發」目前最重要的工作，不是先把聊天畫面做出來，也不是趕快把某個大型語言模型接進去。

我反而先往更底層走。

我想先回答：

在 AI 開始回覆一個人以前，它到底應該知道什麼？

我不想只存一個「情緒標籤」

假設使用者說：

我最近真的很累，什麼都不想做。

最簡單的系統可能會把它分類成：

emotion = sad

然後直接開始生成安慰文字。

但這個表示方法對我來說遠遠不夠。

「很累」到底是使用者自己明確說的，還是系統推論的？

系統有多確定？

使用者現在希望被傾聽、整理問題、找資訊，還是其實根本不知道自己需要什麼？

有沒有風險訊號？

哪些資訊只是推論，哪些是真正由使用者陳述？

因此目前的 Psychological State 並不是單一情緒分類，而是拆成：

• emotions
• concerns
• intent
• risk
• uncertainty
• context
• user goal
• support preference

甚至每一個 State Signal 都另外保存：

value
source
confidence

而 source 目前明確區分：

USER_STATED
SYSTEM_INFERRED

這是一個很小的設計，但我認為它可能會影響後面整套系統。

因為：

「使用者說了什麼」和「AI 覺得使用者可能是什麼狀態」不能被混成同一件事。

如果連資訊從哪裡來都丟掉，後面的推論做得再漂亮，都可能只是建立在自己產生的假設上。

第二件事：不知道，不能偷偷變成沒事

我在設計安全邏輯時，碰到另一個很重要的問題：

如果系統不知道風險程度，該怎麼辦？

直覺上很容易寫成：

沒有發現危險
→ LOW

但這兩句其實完全不同。

「沒有危險」和「我不知道有沒有危險」，不是同一個狀態。

因此目前的風險模型除了：

LOW
ELEVATED
HIGH
CRITICAL

還保留：

UNKNOWN

而且 UNKNOWN 不會被偷偷降級成 LOW。

目前 deterministic safety policy 的方向甚至更加保守：

如果風險是 UNKNOWN，系統會進入限制較高的 response authority。

如果 uncertainty 高到一定程度，也會提高限制。

核心原則可以簡化成一句話：

資訊越不確定，AI 不應該因此獲得更多行動自由。

現在的測試裡，也特別檢查了這件事。

包括：

• unknown risk 不能被當成 low risk
• critical risk 會映射到 crisis protocol
• risk 越高，普通支持權限不能反而增加
• uncertainty 越高，普通支持權限不能反而增加

目前這些仍然只是 deterministic rule 與 synthetic tests。

它不能證明真實世界中的危機辨識能力。

但至少它先把一個我很在意的工程原則固定下來：

Fail closed，而不是 Fail optimistic。

我也開始處理一個很容易被忽略的問題：AI 太會附和人

心理支持 AI 還有一個非常危險、但表面上很討喜的特性：

它很容易順著使用者講。

例如有人說：

大家一定都討厭我。

一個過度迎合的模型可能回答：

聽起來大家真的讓你受了很多傷。

這句話看起來充滿同理。

但它其實有可能偷偷完成了一次邏輯跳躍：

使用者的情緒是真的。

但「大家都討厭我」這個判斷，並沒有因此變成事實。

因此目前我把 representation 拆成了：

emotion
belief
truth_status

其中 belief 預設維持：

UNVERIFIED

目前的 anti-sycophancy representation 甚至直接規定：

emotion_validation_allowed = True
belief_validation_allowed = False

換句話說：

我可以承認你的感受存在，
但不代表我要替一個尚未驗證的信念背書。

這目前還不是完整的回覆生成器。

它甚至刻意「不生成回覆」。

但我反而覺得這個順序是對的。

在教 AI 怎麼說話以前，我想先把它不應該混淆的東西表示清楚。

Evidence 也不能只是「我好像在哪看過」

心理支持系統如果未來真的要使用研究證據，那來源追蹤也不能等到最後再補。

目前的 PsychologicalEvidenceRecord 已經包含：

• title
• authors
• year
• evidence type
• population
• tags
• summary
• limitations
• contraindications
• evidence strength
• provenance
• ingestion version

而 provenance 本身又保存：

• source name
• DOI
• URL
• retrieval time

目前 Intervention Registry 也已經能描述：

• 適用目標
• 適用情境
• contraindications
• constraints
• authority level
• source references
• version

但是這裡必須很誠實地說：

目前還沒有 RAG。

也沒有 vector database。

沒有外部文獻 retrieval runtime。

目前所有 intervention records 的 evidence strength 仍是 UNRATED，source references 也還沒有真正接上研究來源。

所以現在完成的不是：

AI 已經會根據心理學研究選擇治療方式。

而是比較接近：

如果未來要讓 AI 使用 evidence，我先決定 evidence 必須帶著哪些資訊進來，以及什麼東西不能被省略。

這兩句話看起來差不多，實際上的工程成熟度差非常多。

現在其實還沒有一個「心理諮商 AI」

這可能是這篇最重要的一段。

截至目前的 repository inspection，我沒有找到：

• Conversation runtime
• Session model
• Message model
• LLM integration
• RAG
• Vector database
• User persistence
• Web API
• Frontend
• External escalation client
• 真正的 ARCI adapter

換句話說，現在的「從心出發」還不能被稱作完整心理支持平台。

目前真正存在的是一層 foundation：

Psychological State
        ↓
Evidence Metadata
        ↓
Intervention Metadata
        ↓
Safety → Authority Mapping
        ↓
Anti-Sycophancy Representation

它比較像是在蓋地基。

而不是一棟已經可以住人的房子。

那目前到底測了多少？

這裡也有一個很有趣的工程日誌問題。

目前 checkout 的 default test discovery：

56 tests
56 passed
0 failed

另外 psychological support domain suite：

17 tests
17 passed
0 failed

分開執行合計：

73 passed
0 failed

Domain tests 裡包含：

• non-diagnostic ontology boundary
• UNKNOWN intent preservation
• uncertainty validation
• safety authority mapping
• higher-risk monotonicity
• higher-uncertainty monotonicity
• critical-risk handling
• anti-sycophancy fixtures
• belief 維持 UNVERIFIED

目前 concern ontology 有 19 筆 records，而且全部明確設定：

diagnostic_claim = false

但我要再次強調：

73 個 passing tests 證明的是：

目前被寫進測試的 deterministic contracts 能按照預期運作。

它不證明：

• 臨床有效性
• 真實危機辨識能力
• 真實使用者安全
• 心理疾病診斷能力
• production readiness

測試數量和現實世界的安全性之間，不能直接畫等號。

今天最尷尬的地方：Git 說「今天 0 行」

這次整理開發日誌時，我碰到一個很值得記下來的問題。

如果只看 2026 年 8 月 29 日的 Git：

Commits today: 0
Files added today: 0
Files modified today: 0
Lines added today: 0
Lines deleted today: 0

因為目前 repository 的第一個 commit 是：

bbfdc6fa...
2026-08-30 00:16:15 +0800
feat: establish From Heart project foundation

它包含：

67 files changed
12,321 insertions

但是時間已經跨到 8 月 30 日。

所以即使我知道這些東西不是午夜 00:16 突然從空氣中冒出來的，我也不能直接寫：

8/29 今天新增 12,321 行。

Git 沒有辦法支持這個說法。

比較有意思的是，8/29 下午留下的 evidence artifacts 顯示：

第一次 capture：

2026-08-29 17:51:58 +08:00
repository = UNBORN
53 tests PASS

第二次 capture：

2026-08-29 18:11:33 +08:00
repository = UNBORN
56 tests PASS

所以我們知道在 root commit 出現以前，已經存在可以執行並通過測試的內容。

但是因為當時沒有 commit history，我仍然無法可靠重建每一個 source file 到底是幾點寫下來的。

最後我決定不補故事。

這可能才是我真正想要的工程日誌

以前如果看到：

67 files
12,321 LOC
73 tests PASS

我第一個反應大概會是：

「這些數字一定要寫進文章。」

現在我開始覺得，比數字更重要的是它們的 provenance。

12,321 行是哪一天產生的？

73 tests 是現在的 checkout，還是當天的狀態？

一個功能是 implemented、documented，還是 planned？

一個測試證明的是 deterministic behavior，還是真實世界 effectiveness？

如果這些問題沒有分清楚，再漂亮的工程日誌都有可能只是在替自己製造一段方便閱讀的歷史。

所以「從心出發」目前除了心理支持 foundation 之外，另外還有一套很奇怪的東西：

一個會阻止我自己亂寫進度的工程日誌系統。

它會收集 evidence、建立 deterministic context、生成文章，再進行 claim validation。

目前 Day 1 和 Day 2 的 public article validation 都是：

16 / 16 checks PASS

而這個 generator 本身甚至刻意沒有 model call。

因為如果 evidence 不存在，它應該輸出 limitation，而不是靠模型把空缺補成一個完整故事。

今天的結論

「從心出發」現在還不是心理諮商 AI。

甚至距離真正完整的心理支持產品還有很長一段路。

但目前我至少開始把幾個我認為不能等到最後才補的問題放進程式裡：

第一，使用者陳述和系統推論必須保留 provenance。

第二，不知道就是不知道，不能偷偷被歸類成安全。

第三，情緒可以被理解，但未驗證的信念不能因為同理而變成事實。

第四，evidence 如果未來要影響決策，就必須保留來源、限制與 contraindications。

第五，測試證明多少，就只能寫多少。

下一步真正困難的事情，才正要開始。

目前這些 contracts 還沒有串成一條完整的 runtime。

下一階段，我需要開始處理 Conversation State、訊息流、模型介面，以及 psychological state 如何從一次次對話中被更新。

到了那時候，問題就不再只是：

「資料結構怎麼設計？」

而會變成：

「當一個真實的人把一句模糊、矛盾，甚至可能帶著風險的話交給 AI 時，這套系統要怎麼一步一步決定自己有資格做什麼？」

這才是我真正想做的「從心出發」。