iT邦幫忙

2026 iThome 鐵人賽

DAY 14
0

第 1 層:事實層。

第 0 層處理的是「規則」。這一層處理的是另一種東西。事實。

而這兩者的失效方式完全不同。

一個具體的失效

舉一個例子:

AI 設定了 MaximumLength(20),但資料庫欄位是 nvarchar(10)

這不是規則問題。沒有任何一條規則叫做「欄位長度不可以設 20」。20 這個數字本身沒有對錯,錯的是它跟資料庫不一致。 檢查清單裡確實有一條「欄位長度必須對照資料庫」。但那是一條規則,它告訴 AI「你應該去查」,卻沒有告訴它查到的答案是什麼,也沒有辦法確認它真的查了。

所以 AI 就延用了原來的數字。20 看起來很合理。大部分姓名欄位都是 20。它需要的不是更嚴格的規則,是一個可以查到 10 的地方。

https://ithelp.ithome.com.tw/upload/images/20260912/20178262p7FG3r2e20.png

事實層是什麼

事實層就是那個「可以查到 10 的地方」。single source of truth。常見的內容:

  • 資料庫欄位規格(型別、長度、可否為空)
  • 欄位對照表(新舊系統的對應、業務含義)
  • UI 設計稿
  • 舊系統的行為清單
  • 版本與配置的單一真相

它跟第 0 層的差別在於:第 0 層是規則(該怎麼做),第 1 層是事實(實際是什麼)。 規則可以爭論,事實不行。所以事實層比規則層具體得多,也可靠得多。

那個案子的問題:時序

這一層那個案子其實有做,問題出在什麼時候做的。欄位對照表的建立日期是 1 月 21 日。上線準備度報告的前一天

而專案是 11 月初啟動的。

前四個月,AI 沒有任何可以對照的來源。 它寫驗證規則、寫欄位長度、寫 UI 結構,全部靠直覺。那四個月產出的程式碼,就是後來 187 個問題單的溫床。

所以事實層有一個很現實的結論:

它的價值幾乎完全取決於「什麼時候建立」。
專案末期才建的事實層,只能拿來做事後對帳,防不了任何東西。

但它還是 advisory

這裡要講清楚一件事,免得高估了這一層。

事實層本身仍然是 advisory 的。

你把欄位規格寫成一份 markdown 放在 repo 裡,AI 還是可能不去讀它。它跟第 0 層一樣依賴自願配合。只是配合的內容從「遵守規則」變成「去查資料」。

那要怎麼讓它真的被查?

演進:把事實層做成工具

這是我認為第 1 層最重要的演進方向,也是這兩年才變得可行的事:

把事實層從「文件」做成「AI 必須呼叫的工具」。

差別在哪?

  • 文件:AI 可以讀、也可以不讀。讀了可能漏、可能記錯
  • 工具:AI 要拿到答案,只能呼叫。而且回傳的是結構化資料,不是它讀了之後的印象

具體的場景長這樣:

當 AI 要寫 MaximumLength(...) 的時候,工具鏈強制它先呼叫
getColumnSpec("使用者資料", "姓名"),得到 nvarchar(10)

沒查就不能往下做。

可能的設計:

工具 用途
legacy-schema 查舊系統的欄位規格
legacy-behavior 查舊系統某頁面/某流程的實際行為
ui-spec 查 UI 設計稿規範(直接讀 HTML)
column-mapping 查欄位的業務含義與新舊映射

這些現在都可以用 MCP(Model Context Protocol)server 實作。

一個實際跑起來的例子

理論講完,講一個我最近在另一個進行中的案子看到的實作。那個專案的設定檔裡掛了一個 code graph 的 MCP server。意思是:AI 不用靠 grep 去猜「這個方法被誰呼叫」「這個類別的相依是什麼」。它可以直接查詢程式碼的結構圖。

這件事的價值不只是省時間。回想 Day 09 講的第三個場景:

「後端成功但前端失敗」的問題,第一時間判斷是要調某個框架的緩衝上限。
那個判斷在一般專案是對的,但這個專案的 client 是手動建的 bean,
那個設定完全不會生效

那正是一個「事實」問題,不是「規則」問題。

如果 AI 能查到「這個 bean 是在哪裡、用什麼方式建立的」,它就不會做那個推論。它做那個推論,是因為它只能靠 prior。事實層工具化,本質上是在削減 AI 需要用 prior 補空白的面積。 這跟 Day 09 那個原因是直接對應的。

事實層也會過期

最後講一個很少人提、但我看過真實案例的問題:

單一真相自己會過期。

有一個案子的迭代日誌裡有一條,標題就叫「單一真相自己過期」。他們建了一份配置的單一真相檔,結果那份檔案裡的版本號,跟實際的建置檔對不上了。你立了一個「以它為準」的東西,然後它錯了。而所有人都還在照著它走。 這比沒有那份檔案更危險。沒有的時候,大家至少會去查真的東西。

所以事實層需要配一個東西:一致性檢查 。定期(或每次改動時)比對「單一真相宣稱的」和「實際的」是否一致,不一致就擋。

而那已經是第 3 層的事了。

這也說明了一件事:這幾層不是各自獨立的,它們互相支撐。第 1 層需要第 3 層來確保自己不腐化。

小結

  • 第 1 層處理的是事實,不是規則。規則可以爭論,事實不行
  • 它的價值取決於建立時機——末期才建的只能事後對帳
  • 它本身仍是 advisory,除非做成 AI 必須呼叫的工具
  • 它自己也會過期,需要第 3 層的一致性檢查來守

明天講第 2 層:流程閘道。那一層要講一個我認為很多團隊做錯的事。agent、skill、subagent 都配了,但時序錯了,所以沒效。


上一篇
Day 13 - 第 0 層 憲法:說到底是參考用的
下一篇
Day 15 - 第 2 層 流程閘道:配置都對,順序錯了
系列文
綠燈不等於做對:AI 開發的驗收工程 ——從兩個失敗的案子,到驗收交付23
圖片
  熱門推薦
圖片
{{ item.channelVendor }} | {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言