一部完整的聖經，適用於任何語言，
建構於單一可攜檔案之上。

I.什麼是 GOI？

GOI 代表 Global Ordinal Index（全域序數索引）。 這正是整個專案命名的核心概念——一個單一的整數鍵，讓每一節經文， 在每個版本、每種語言之間，都能以相同的方式被定位、比較與連結。 本頁其他一切——資料庫、翻譯流程、審查記錄—— 都是為了填入並驗證附著於這個索引上的文字。

每一部聖經都有自己的分節系統——書、章、節。問題在於 不同的分節系統彼此並不一致。希伯來馬索拉文本將某些詩篇標題 算作第 1 節；許多英文譯本則不這麣做。不同的正典順序會把書卷排在 不同的位置。如果兩個版本的編號方式不同，比較「第 14503 節」 在兩個版本之間毫無意義。

全域序數索引（GOI）用一個概念解決這個問題： 為每個版本中的每一節經文，依照該版本正典閱讀順序中的位置， 指定一個單一、連續的整數。

SELECT
    *,
    ROW_NUMBER() OVER (
        PARTITION BY edition_id
        ORDER BY conical, chapter, verse
    ) AS goi
FROM verses;

（conical 是目前資料庫結構中實際使用的欄位名稱—— 這是「canonical」長期以來的拼寫錯誤，為了保持資料庫內部的向後相容性 而維持原樣未改。）

因為 GOI 是依每個版本分別從正典順序計算出來的，它讓 「這個譯本在結構上是否完整？」變成一條單一查詢；而且—— 一旦兩個版本被對應到同一套正典序數序列之後—— 它讓「另一個版本中對應的是哪一節？」變成一個 join。 GOI 並不能消除整合不同分節系統所需的工作；它所做的是 為這項整合提供一個單一、持久的目標表示法，因此每個版本只需做一次， 而不必每次比較時重新推導。（本專案中的希伯來文 WLC 版本， 正是這項整合尚未完成的活生生例子——詳見下方狀態表。）

兩個版本，兩套不同的分節系統，一個共用的整數鍵。 結構上的差異從手動比對變成了一條查詢。

本專案需要一個版本作為參考序數序列—— 也就是其他每個版本的 goi 最終都要對照的正典書/章/節順序。 欽定版（King James Version）被選為此角色： 66 卷書、31,102 節經文，goi 值從 1 到 31,102。 選擇它並非因為其用詞——AI 翻譯並不會照抄它—— 而是因為其分節方式是最廣為人知的「最大公分母」順序， 因此是偵測其他版本節數差異時最有用的固定標尺。

為何從 WLC + TR1550 開始——以及為何採用 MIT 授權？

本專案中每一個翻譯所依據的兩份原文—— 西敏列寧格勒抄本（希伯來文舊約）與 1550 年公認文本（Textus Receptus）（希臘文新約）—— 皆屬於公共領域。這個選擇並非偶然； 它正是讓本專案其他一切得以成立的基礎。從一份本身不受限制的原文出發， 意味著最終產出的譯文、資料庫與管線程式碼， 可以採用真正寬鬆的授權——MIT—— 不必擔心上游版權、不會有版稅鏈， 也不會有任何暗中限制他人複製、分叉或重新散布成果的條款。

這裡的「MIT」就是它一貫的意思：任何人——一所神學院、 一名獨立開發者、一個沒有預算的宣教機構—— 都可以取得這個資料庫、程式碼或翻譯文字，使用它、修改它、 將它發行出去、再免費分送給別人，不需要徵得任何人同意， 也不需要付費給任何人。一個建立在受限授權或受版權保護原文上的 聖經專案，永遠無法提供這樣的條件。從公共領域進，以 MIT 授權出， 就是整條供應鏈。

GOI 為本專案帶來的具體好處：

• 版本間比對——不需要分節對照表， 即可對齊任意兩個版本。
• 差異偵測——goi 序列中的跳號或重複， 會立即標示出結構性問題。
• 缺節偵測——一個版本的節數就是 MAX(goi)；翻譯是否不完整一眼可見。
• 跨語言對齊——一旦新語言的經文以相同的正典順序 載入，其 goi 值就會自動與英文、希伯來文、希臘文對齊。

II.背景與動機

這個世界為什麼還需要另一個聖經翻譯專案？

聖經翻譯傳統上是現存最昂貴、最耗時的文字工作之一。 單一語言的翻譯,可能需要一支訓練有素的團隊花上十年甚至更久， 而最終成果——儘管極為用心——通常被鎖在某種格式裡 （印刷書籍、某個教派的專有資料庫）， 難以比較、搜尋,或進行機器輔助審查。

GOI 聖經專案從一個不同的前提出發。大型語言模型現在已具備一定能力—— 雖非完美，但已足夠勝任——能根據已標記的原文產出初步翻譯。 真正有趣的問題已不再是「AI 能翻譯聖經嗎？」 而是：能否以我們對待程式碼庫同等的嚴謹程度， 大規模地檢驗這個結果——自動化測試、完整性關卡、 回歸追蹤,以及每一次修正都留下可見的審查記錄？

這正是 GOI 的核心思路。每一節經文都是一行資料。 每一個譯本都是一個版本。每一個名詞、子句與數字， 都是可以對照原文語言查核的事實。而這一切—— 文字、交叉引用、審查中介資料——都裝在一個可以放進隨身碟的單一檔案中。

我們的目標不是宣稱 AI 第一次就做對了所有事情。 它幾乎從來不會。我們的目標是讓每一個出錯的地方都 可被找到、可被修正、可被重新驗證——並公開所有記錄。

III.為何選擇 SQLite

整個專案——原文、譯文、交叉引用、審查表格——都存放在一個 SQLite 檔案中。 這個選擇是刻意的,而且重點不在於流行與否, 恰恰相反：重點在於耐久性與可攜性， 畢竟這是一份本質上理當比任何特定基礎設施都更長久的文本。

• 預設離線。不需要伺服器、不需要網路、 不需要帳號。複製檔案、開啟它、查詢它。 聖經不應該需要網路連線才能閱讀。
• 同一個檔案，到處都能用。SQLite 原生支援 Android、iOS、桌面作業系統,以及透過 WebAssembly 在瀏覽器中執行。 驅動一個網站的同一個資料庫,可以直接打包進手機 App, 或在個人電腦上直接開啟——在手機 App、網站或私人電腦上使用起來一樣容易, 中間不需要任何伺服器。
• 體積小。公開發行的跨版本索引資料庫 （GOI_bible.sqlite3）約為 23 MB。 隨附的完整生成文字版本（英文、中文、希臘文原文） 總共約 280 MB。 內部管線資料庫帶有逐字審查與來源資料,不屬於公開發行內容, 體積更大——但公開發行的成果仍是一部能裝進手機、 還綽綽有餘的聖經。
• 可攜。SQLite 資料庫是單一檔案， 格式有完整文件記錄且穩定。不需要遷移腳本、 不會被特定版本的伺服器綁住。今天下載的檔案, 二十年後仍能正確開啟。
• 虛擬表與檢視表即物件。SQLite 的 VIEW 機制讓資料庫可以呈現預先連結、 預先解析好的「物件」——例如一節經文, 其正確的詞義已針對特定語言解析完成——而完全不需要任何應用程式碼。 資料庫本身就是 API。

最後一點的重要性超乎其字面。在本專案偏好的技術組合中 （SQLite 檢視表 → PHP 直接傳遞檢視表的資料列 → htmx 變更 DOM)，「該為某個語言、某個情境選用哪個詞」 這項「商業邏輯」,完全活在資料庫的檢視表定義裡。 應用層因此變得極其精簡——也意味著幾乎沒有東西需要維護、 替換或移植。

為何從「一節一檔」開始？

在任何內容進入 SQLite 之前,翻譯流程本身是以 每節經文一個純文字檔案的方式處理整個語料庫—— 例如 001_GEN_002_004.txt。這是一種不尋常的切分粒度， 而且是刻意如此：

• 有護欄的翻譯。每一次呼叫 LLM, 範圍都嚴格限定在一節經文的原文與情境—— 不是一章,也不是「接續上次的內容繼續翻」。 這將模型的工作範圍限制得足夠緊, 使幻覺或偏移的內容（多餘的句子、 合併的經節、憑空出現的轉折)立即可見： 一個檔案的輸出,要不是某一節經文的忠實翻譯, 就是明顯有問題。
• 檔案數量就是進度條。輸入 31,102 個檔案, 輸出 31,102 個檔案。「舊約翻譯完成了多少？」 就是 ls | wc -l， 不需要查詢一個必須隨時保持同步的進度追蹤系統。
• 檔名即同義反覆的位址。檔名本身就是位址—— 書卷、章、節直接編碼在 001_GEN_002_004.txt 裡， 因此沒有另外的索引會過期, 「檔名是什麼」與「內容是哪一節」之間也不會出現不一致。 任何人都能單憑檔名對整個語料庫做 grep、排序或差異比對,並得到有意義的結果。

一旦這個切分好的語料庫載入 SQLite, 原本的剛性就消失了,靈活性則轉移到輸出端。 讓翻譯安全地切分的「每節一行」結構, 也讓重新組裝變得輕而易舉——一章、一整卷書、 要不要顯示節號,都只是一條 SQL 查詢之遙：

-- Whole chapter, with verse numbers (e.g. for study/reference view)
SELECT verse, rendering FROM v_effective_rendering
WHERE book='JHN' AND chapter=3 AND lang=:lang ORDER BY verse;

-- Same chapter, reading view — no verse numbers, just flowing text
SELECT group_concat(rendering, ' ') FROM v_effective_rendering
WHERE book='JHN' AND chapter=3 AND lang=:lang
GROUP BY book, chapter ORDER BY verse;

-- A whole book, concatenated, for export/printing
SELECT group_concat(rendering, '

')
FROM v_effective_rendering
WHERE book='JHN' AND lang=:lang
GROUP BY book, chapter ORDER BY chapter, verse;

同樣的底層資料列,三種不同的呈現方式—— 帶節號的研讀文本、流暢的閱讀文本,或可直接印刷的書卷輸出—— 都不需要不同的資料格式、匯出步驟或重新排版。 讓翻譯保持誠實的切分方式, 與讓呈現變得低成本的靈活性, 是同一套「每節一行」設計的兩面。

想親自試試嗎?請參閱 SQLite 範例, 其中提供可直接複製貼上的查詢—— 產生整本聖經、取出單一章、製作詞頻熱圖, 以及用 FTS5 虛擬資料表搜尋「光」與「暗」相鄰的經文。

IV.GOI + 虛擬表：為何強大

GOI 讓每一語言的每一節經文都擁有相同的位址。 SQLite 的檢視表把這個共用位址, 變成應用程式可以直接讀取的預先解析「物件」—— 應用層完全不需要任何翻譯邏輯。

範例：詞義解析檢視表

許多詞語的意義取決於語境。希臘文 κύριος 可以是「主」,也可以單純是「主人/先生」。 希伯來文 אֱלֹהִים 可以是「神」、「眾神」,在某些句型中甚至是「審判官」。 與其為每一種新語言重新爭論這些判斷, 新約管線將每一個有歧義的出現位置一次性地、 不分語言地解析,並以詞義鍵 （例如 KYRIOS.HUMAN_MASTER)記錄這個決定。 一個檢視表接著針對每個詞、每種語言, 解析出該呈現哪個實際的詞：

狀態說明：下方的詞義鍵檢視表描述的是 新約管線。舊約的名詞錨定目前是透過更直接的 noun_translations 對照表進行,而非此檢視表； 隨著舊約審查的進展,兩者將會統一。

CREATE VIEW v_effective_rendering AS
SELECT
    o.book, o.chapter, o.verse, o.word_pos,
    COALESCE(
        sr.rendering,              -- 1. sense-specific word for this language
        dr.rendering               -- 2. fall back to the language's default
    ) AS rendering
FROM verse_rendering_overrides o
LEFT JOIN sense_renderings   sr ON sr.sense_key = o.sense_key AND sr.lang = :lang
LEFT JOIN strongs_lang_renderings dr ON dr.strongs_num = o.strongs_num AND dr.lang = :lang;

成果：整本新約中, 1,060 個依語境而定的選詞判斷只需做一次。 一個全新的語言,只需填入16 行—— 每種獨特詞義各一行——就能自動繼承所有這些判斷。 十六個一次性的決定,永久解決上千個語境判斷。

範例：任意詞語在全書中的「熱區圖」

因為每一節經文都有一個單一的整數位置（其 goi), 統計某個詞出現的次數與位置只是一條查詢—— 依連續的 goi 值分組成區段並計數即可。 不需要另外的搜尋索引,也不需要預先計算的表格： 經文文字與序數軸線本來就在同一行資料中。

SELECT (goi / 100) AS bucket,        -- ~100-verse "bins" across the whole Bible
       COUNT(*) AS hits
FROM v_effective_rendering
WHERE rendering LIKE '%light%'
GROUP BY bucket
ORDER BY bucket;

將 bucket 畫在 x 軸, hits 以顏色深淺呈現, 就得到「光」這個詞在創世記、詩篇、約翰福音、啟示錄中 聚集分布的熱區圖——可以即時生成,適用於任何語言, 因為每個版本的區段邊界都是相同的序數位置。

範例：「找出所有與『暗』相距 4 節以內的『光』」

鄰近搜尋——在大多數文字搜尋引擎中都是出名地棘手的查詢—— 在這裡變成一個帶有算術範圍的自我連接（self-join), 因為「相距 4 節」在 goi 軸上就只是 ±4：

SELECT a.goi AS light_goi, a.rendering AS light_verse,
       b.goi AS dark_goi,  b.rendering AS dark_verse
FROM v_effective_rendering a
JOIN v_effective_rendering b
  ON b.goi BETWEEN a.goi - 4 AND a.goi + 4
 AND a.lang = b.lang
WHERE a.rendering LIKE '%light%'
  AND b.rendering LIKE '%dark%';

像「這兩個主題在哪些地方彼此靠近？」這類問題, 通常需要一套專門的搜尋/索引服務。 在這裡它只是一個 join 條件, 因為 GOI 早已把「經文之間的距離」變成了普通的減法運算。

建立在開放定址標準之上：OSIS 與 BCP 47

GOI 是本專案內部使用的序數—— 但它據以計算的欄位, 都是刻意採用普通、基於標準的識別碼, 讓這個資料庫與其他聖經軟體說同一種語言：

• 書卷代碼遵循 OSIS （開放聖經資訊標準）慣例—— GEN、PSA、 MAT、REV 等等—— 與聖經軟體、OSIS-XML 文本以及大多數公共領域聖經資料集 所使用的三字母代碼相同。任何人將資料匯入或匯出此結構時, 所使用的識別碼很可能早已熟悉。
• 語言遵循 BCP 47—— 瀏覽器、HTML lang 屬性 與 CLDR 地區資料所使用的 IETF 標準。 像 en、zh-Hant 或 cmn-Hant-TW 這樣的 language_subtag 值都是合法的 BCP 47 標籤, 因此一個新版本的語言身分, 可以直接套用到網頁前端、字型選擇, 以及地區感知排序,不需要自己另建對照表。

這個組合的重點在於：goi 解決的是 「這節經文在結構上位於何處」的問題 （這正是各分節系統彼此不一致的地方), 而 OSIS 書卷代碼與 BCP 47 語言標籤, 解決的是「這節經文按標準說法是什麼」的問題 （這是其他人的工具早已能理解的)。 GOI 並不取代這些標準—— 它是建立在這些標準之上的序數索引。

V.GOI 聖經的理由——以及它的審查記錄

是的——這個翻譯 100% 由 AI 生成。 正因如此,它才以這種方式被審查。

傳統翻譯委員會的工作筆記,很少能在出版後留存下來。 GOI 聖經採取相反的做法：每一次驗證、每一個被標記的經節、 每一次修正,都被記錄下來,可重現、可重新執行。 我們並不宣稱這個成果已經完成或達到學術水準—— 我們宣稱的是這個過程異常透明, 並且公開所有證據,讓這個宣稱可以被檢驗,而不只是被相信。

處理流程

此圖中的每一個箭頭,都對應到程式庫中的一支腳本。 這裡沒有任何步驟是一次性的人工作業——整條流程都可以重新執行。

目前審查已發現的內容

即時狀態——目前實際完成的進度

下表是本頁面嘗試在一處清楚說明—— 管線的每個部分目前進行到哪個階段—— 讓訪客（或審查者)不必從文字敘述中自行推斷。

誠實的提醒——公開,而非隱藏

• 這是一份 AI 初步翻譯。它具有可讀性, 且上述機械式檢查均已通過,但它並非 可取代同行評審學術譯本、用於教義研究之用。
• 以上數字是一項持續進行中審查工作的快照—— 隨著各項檢查重新執行、範圍擴大, 數字會在兩個方向上變動 （例如,隨著檢查器本身的精進, 舊約子句檢查的標記數量已經有所變化)。
• 在 AI 譯文用詞與公共領域的 KJV 或 WEBUS （僅作為品質參考)相近的地方, 這些重疊程度均已量測並公開 （全文平均 Jaccard 相似度約 0.55–0.64), 而且因為這兩份參考文本皆屬公共領域, 這並不會對成果造成任何權利限制。

GOI 聖經的主張,不是「相信這個 AI」。 而是「不要相信這個 AI——自動對照原文檢查它、 記錄每一次檢查與每一次修正,並讓任何人都能重新執行這些檢查」。

VI.更大的願景：每種語言都有聖經，成本不到十美元

世界上有超過 7,000 種仍在使用的語言。 其中大約 1,500 種完全沒有聖經譯本, 還有更多只有部分譯本。 要彌補這個差距,以人年計算的傳統成本極為龐大。

GOI 管線徹底重構了這個成本結構：

• 初稿翻譯成本：約 31,000 節經文, 以一般市場費率透過 LLM API 逐筆處理。 以目前的費率計算,一種語言的舊約加新約 初稿翻譯,運算成本僅需個位數美元。 （驗證與修正——即上方審查章節所描述的工作—— 是額外的、持續性的運算成本與人工審查時間, 並未計入此數字。)
• 詞義消歧成本：每種語言只需 16 行—— 幾分鐘的雙語審查—— 即可為一千多個已預先解析的歧義位置, 解鎖正確的語境化呈現。
• 審查成本：用於審查英文與中文的 同一套名詞覆蓋率與子句檢查管線, 可套用於任何新語言已標記 Strong's 編號的譯文, 其邊際成本與原始翻譯流程相同。
• 發行成本：幾乎為零。 輸出只是一個 23 MB SQLite 檔案中的資料列。 新增一種語言只增加幾 MB 的文字, 不需要新的部署。

這一切都不能取代以母語為使用者的審閱者、語言學家, 以及最終將決定他們語言中何謂「忠實翻譯」的群體所做的工作。 它所做的是移除初稿瓶頸—— 讓審閱者拿到的初稿,已經先經過機械式失誤模式 （遺漏詞語、遺漏子句、否定反轉、數字錯誤)的檢查, 這些通常會占去審閱時間中很大的一部分。

語音：即將推出。 文字轉語音技術已經發展到, 一份乾淨、逐節整理的文字語料庫, 就已經完成了製作有聲聖經大部分的工作。 因為每一節經文本身就已經是一筆可定位、 經過檢查、有 GOI 索引並標記語言的資料, 生成完整的有聲版本, 與本管線其他每一步驟一樣, 都只是「再多填一個欄位」這種模式—— 適用於任何支援的語言, 不僅僅是傳統上才有有聲錄製的少數語言。