🇹🇼 中文（本頁）｜🇬🇧 English
獨立、非官方、非 TypeSafe 贊助的社群專案（除了一般的早鳥候補名單，我們沒有收到 TypeSafe 任何報酬或提前使用權）。這個 repo 幫你、我，還有任何想用 Jev（TypeSafe 的 System One 模型）的人，判斷手上的任務適不適合交給它：用真實 API 呼叫的收據，畫出它「校準決策」這個宣稱在哪裡站得住、在哪裡站不住的邊界地圖。給人看怎麼用，給 agent 帶進專案看哪裡能試著換上去，也給任何做過真實驗的人一個把結果貢獻進來的地方。
不是排行榜（市面上已經有 jev-benchmarks、thaiexam-jev-charts 在做這件事，做得很紮實，我們引用它們、不重做）。這裡回答的是另一個問題：什麼情況下它強，什麼情況下它弱，為什麼。
它是什麼：Jev 適用的情境很「橫切」（cross-cutting），不限產業，任何系統裡「窄判斷」這一層都用得上，瀏覽器自動化、程式碼審查、內容審核、金融交易、新聞分類、電玩都有案例，見 capability-map.md 收錄的十幾種完全不相干的產業案例。💭 它本身內建的世界知識有限，但只要資訊在你餵給它的 state 裡給得夠齊，閱讀理解/擷取能力好到誇張。這是我們從幾十個真實案例（🔬 自己測的、📚 第三方跑分）歸納出的核心特徵，細節見下面「核心發現：一條軸」。
機制上：它很快、很便宜，只能做「選一個選項/打個分/回答是非」這種窄判斷，不會寫文字解釋自己在想什麼。因為答案空間是你自己先定義好的，它結構上不可能吐出選項清單以外的東西。自由生成文字的模型偶爾會格式跑掉，甚至生出一個你沒列的分類；這是不同等級的保證，不是機率低，是型別上不可能。但這只保證答案落在清單裡，不保證選到的那個是對的，細節見下面「不是瞎猜」那節。
它在「答案就寫在你餵給它的文字裡」的任務上很準（分類、判斷兩段文字關不關聯、抓語意層的矛盾），也適合把「候選項雖多但內容都給齊」的操作一次批次問完，例如瀏覽器自動化裡「畫面上這些元素該點哪個」，見下面案例。反過來，它的判斷完全建立在你給的文字上：文字有錯時，它不會提醒你題目怪怪的，照樣很有把握地選。🔬 我們自己踩過一次：一道歷史選擇題的正確選項被我們打錯一個字，它以 0.90 的信心選了錯的答案；只修正錯字重問，它就不再選那個錯的（見 suites/history-recall-context/；這個錯是讀者在 issue #2 抓到的，這一段的舊版也因此更正）。需要你沒給它的外部知識時，它知不知道你事前看不出來。📚 第三方真實案例裡，它在文章沒寫的背景關聯上比大模型弱（見 translations/libukai-hubei-news-classification-zh/），🔬 但我們自己的冷門史實題它不給背景也以 0.87 的信心答對。需要的資料放進 state 最保險。
看到上面「只能做窄判斷、不解釋自己」，很容易腦補成「它就是個狀態機/查表機」或「它在瞎猜」。兩者都不對，錯的方向還不一樣。
「語意層的窄判斷」這個架構位置，過去一年通常是規則狀態機+反應快的小模型在填，代價是死板、能力上限低。Jev 想填的正是同一個位置，但底層換成真正的語言理解。所以「狀態機」這個詞會自然冒出來，但直接套用並不準確。
為什麼不是狀態機：狀態機的核心是有限離散狀態+事先寫死的轉移規則。Jev 底層是真的訓練過的語言模型，做的是分布式語言理解，不是規則比對。證據見 suites/citation-support-check/ 的兩組對照案例：paraphrase_support（宣稱跟引文字面幾乎不重疊，但語意上真的支持，它判對了）、reversed_meaning_high_overlap（除了一個字幾乎逐字重疊，但那個字把意思整個反過來，它也判對了）。🔬 純規則/關鍵字系統做不到這兩件事。
但「狀態機」這個比喻有一件事講對了：它在系統裡該被放的位置。TypeSafe 自己的定位：「code needs a narrow decision it can inspect and act on」「99% machine-to-machine interactions」📖。它該被當成嵌進你自己程式邏輯裡的一個元件用，不是自主對話的夥伴。把它當「狀態機的一個節點」是對的架構直覺，但它的內部運作不是狀態機。
為什麼不是瞎猜：confidence 不是另一個獨立的「自信心」機制，是從它已經給出的機率分布算出來的統計量。📖 這個數字值得信任是因為訓練目標本身就衝著它去：TypeSafe 把後訓練分三條路：RLHF（對話模型，目標是「人喜歡聽」）、RLVR（推理模型，目標是「推導對」）、RLCD（Jev 用這條，目標明講是「機率越高，答案正確的機會應該越大」）。📖 我們自己的測試裡多次看到這個數字隨案例難度真實起伏：反諷偵測跨句版的兩個刻意寫模糊的對照案例，一個信心掉到 0.19（接近丟銅板），另一個維持 1.00；🔬 歷史題那組也看得到：一道本身沒有唯一答案的題（「清朝第七任皇帝」，從努爾哈赤、皇太極、順治開始數答案各不相同，三個選項剛好各對一種），三次重問機率都接近打平、信心只有 0.07–0.13；同一組裡有唯一答案的題則是 0.87–1.00。🔬
但 calibration（校準）是群體統計性質，不是對單一答案的保證，TypeSafe 自己這樣寫。📖 我們找到的第三方跑分證實這會壞：DAIR Emotion 那組任務，Jev 平均信心 0.819，實際只對了 48%，還有 16% 的題目給「正確答案」的機率剛好是零。📚 「瞎猜」的疑慮該落在這裡：它的信心機制在某些任務（類別本身重疊、糊在一起的那種）上會失準，而且失準的方向是「顯得比實際上更有把握」，這是最危險的失準方向。
還有一個常被搞混、值得跟「不是瞎猜」分開講的保證：因為 Choice/Score/Noul 的答案空間是你自己先宣告好的，它結構上不可能選到清單以外的東西，TypeSafe 自己的說法是「producing an invalid value or a hallucinated answer is mathematically impossible」。📖 這跟一般自由生成文字的模型不一樣：後者可能格式跑掉、答非所問，甚至生出一個你選項裡沒有的新分類，你得另外寫解析器去接住這些偏差；Jev 結構上沒有這個問題，回傳的值保證落在你定義的選項/等級裡。但這是型別保證，不是正確性保證。上一段的 DAIR Emotion 就是反例：答案永遠落在六個情緒選項裡（型別保證成立），但選到哪一個常常是錯的（正確性保證不成立）。兩種保證分開看，才不會把「不會選單外」誤解成「不會選錯」。
那它到底是什麼：一個訓練過真正語言理解、但被限制成只能吐出型別化答案、且訓練目標鎖定「讓機率數字可信」的模型。跟狀態機的差別在於真正的語言理解；跟瞎猜的差別在於信心數字有實證支持（但不是無限可信，見上一段但書）；跟現在講的「推理模型」（o1/DeepSeek-R1 那類）的差別在於它不做展開式、多步驟、自我承接的推導。TypeSafe 把它放進第三個類別：不是簡化版推理模型，是不同的優化目標。
這個名字要當真：SDK 的方法名稱就是 client.system_one(...)，型號家族叫 System One models 📖。在 Kahneman 那組分法裡，System 1 快、自動、不解釋理由；System 2 慢、刻意、會展開推導。所以上面那句「它該被當成嵌進你程式邏輯裡的元件」不是我們推導出來的結論，是廠商自己的定位；「讓慢的模型想、讓快的模型動」也不是誰發明的用法，是這顆模型存在的理由。
💭 這件事對讀這份地圖的人有兩個實際含意：
- 看到「大模型規劃、Jev 選動作」這種架構，不必當成新發現，那是出廠設定。值得記錄的是分界線畫在哪、以及第三層。每一個跑得動的實作其實都是三層：規劃（大模型決定目標）、決策（Jev 每一步選一個）、確定性執行（尋路、協定、算術、規則檢查，完全不是模型）。第三層最常在別人的敘述裡被整個略過，但沒有它，前兩層的輸出到不了真實系統。實例見
analysis/jev-games-tcg.md的 Minecraft 一節（規劃 35 次、決策 131 次、執行交給 Mineflayer）與browser-automation.md。 - 非直覺的是把預設方向倒過來用：PlayJev 把最沒把握的步驟往上交給 System Two；wakegate 在叫醒 agent 之前先花一次便宜的判斷。這兩個才是「不看別人做想不到」的用法，
jev-patterns.md收的就是這一類。
有兩個獨立的第三方專案把 Jev 接進瀏覽器自動化，結果一致：jev-browser（獨立開發者做的 MCP 伺服器，對照 Playwright MCP 快 1.5 倍、便宜 1.6 倍、準確度打平）跟 jev-ultrafast（Browser Use 官方整合，單一任務中位數快 25%、瀏覽器協定呼叫少 91%）。📚 兩個專案分開的完整方法論、數字、誠實但書，見 capability-map.md，這裡只講機制。
這不是「Jev 很會看網頁」。它現在只吃文字，不吃截圖，文件寫得很清楚。厲害的地方是這兩個整合都精準命中上面兩條原則：
- 把「看畫面」換成「讀給定文字」：不用截圖，改用結構化的 DOM 快照文字當
state，把原本需要視覺理解的任務轉譯成純文字、訊號自足的判斷，正好落進它的能力圈。 - 把「一次一步」換成「一次批次」：不是每走一步就問一次慢模型「該點哪裡」，是把畫面上所有候選元素的判斷一次平行問完（TypeSafe 自己的說法叫「speculative fan-out」）。這正是它的強項：大量、窄、平行的判斷。
但同一組跑分也抓到了邊界：jev-browser 那組資料裡，一個純文字擷取（沒有操作動作）的任務，Jev 反而比單獨用 LLM 更慢更貴。訊號自足的優勢只在「要對頁面採取行動」時成立，「純閱讀理解」不是它的地盤，細節同樣見 capability-map.md。
已經看完這些證據、決定要把自己的系統接上去的人或 agent，讀 browser-automation.md，裡面有參考架構（一次呼叫問三題）、打字問題怎麼解、三個真實實作，以及接自己系統前的檢查清單。
Jev 本體到今天還是只收文字，圖片、聲音、影片都不收，官方 Models 頁寫的是「not supported (yet)」📖。所以看到「讓 Jev 看圖」這類說法，先分清楚它其實是哪一種。常被混著講的有三種完全不同的東西：
- 換一顆本來就會看圖的模型，套上 Jev 的問法（decider-2b-vision、PlayJev、djev dev、jevlike，或 LitJev 接 vision 版的 Qwen）。看得到圖是真的，但那不是 Jev，是別人的權重穿上同一套題目格式，校準、準確率、硬體需求全部要重新問一次。
- 先把畫面轉成文字或結構化資料，再交給真的 Jev（DOM、OCR、深度＋分割、手勢追蹤）。用的是真 Jev，但 Jev 沒有看到圖。
- 只有宣稱、沒有東西。
💭 把已經公開的數字攤開來看，這個方向目前的狀態是這樣（全部是作者自述，我們沒有重跑）：
- 有保留集數字的只有一家：decider-2b-vision，每項 300 題，Visual7W 保留集 0.89（ECE 0.03）、ScienceQA 0.95、IconQA 0.94。但它自述文字端還停在舊的 v5 權重，而且純像素玩遊戲一離開訓練過的遊戲就是 0（保留的 Freeway、FrozenLake、較難的格子世界全是 0）。📚
- 量得最徹底的那個，結論是「專用，而且會犧牲通用能力」：PlayJev 十款遊戲平均只有老師分數的 0.57，而且純遊戲訓練把 MMBench 從基座的 0.66 打到 0.48，摻兩成通用資料才回到 0.78。📚
- 工程做得最深的那個，品質一格都沒量：djev dev 真的去改 vLLM 的注意力與排程（保住圖片 span 內的雙向可見、禁止把一張圖切一半、有圖就整批退回 eager），也做到 Jev 做不到的「選項本身是圖片」，但它自己在 performance 文件第一段就寫明這一版沒有任何外部保留集的品質評測，並公開徵求。📚
- 「先轉文字」那條路，沒有人量過準確率，量的都是成本與速度：同一張截圖，OCR 後交給 Jev 每次決策 0.0002 美元、0.13–0.38 秒，直接把截圖丟給 Claude Opus 5 是 0.032 美元、5.2 秒。那是成本與速度的比較，不是準確率的比較。📚
所以現在該問的不是「它能不能看圖」，而是你要的那個訊號，系統內部是不是早就算過、只是沒露出來。多數情況下是有的，而那條路又快、又準、又便宜。完整表格與逐項證據見 jev-variants.md，判斷準則見 AGENTS.md 的「候選訊號本來就不是文字」那節。
這三個常被放在一起比，其實是三種不同的東西。BERT 是你要自己訓練的零件；Jev 是拿來就能直接問的決策服務；Laya 是把 BERT 改造成 Jev 的問法，但理解力還停在 BERT 等級的開源模型。
| BERT（拿來做分類器） | Laya | Jev | |
|---|---|---|---|
| 本體 | 預訓練編碼器（2018 年，原版 110M／340M 參數） | BERT 類編碼器加一層決策輸出層：英文版 ModernBERT-large（共 421M）、多語版 mmBERT-base（共 322M） | 預訓練語言模型再用 RLCD 後訓練；參數量與骨幹架構官方沒有公開 📖 |
| 題目在哪裡定義 | 訓練時寫死在輸出層，換一組類別就要重新訓練 | 請求時用文字給（instructions＋criteria），格式跟 Jev 相同 | 請求時用文字給 📖 |
| state 怎麼讀 | 一次一段，原版上限 512 tokens | 每一題各組一段「題目＋選項＋state」，英文版 512、多語版 1024 tokens，超過的 state 尾端直接截掉——我們的實測裡英文版至少 6 案被截 🔬 | state 讀一次、所有題目共用，state 加最長的一題最多 32k tokens 📖 |
| 選項怎麼讀 | 選項只是輸出層的類別編號，模型不讀選項文字 | 選項文字放在同一段序列裡，但全部選項共用 192–256 tokens，選項一多，每個會被砍到只剩幾個 token（它自己公布 77 類的 Banking77 只有 0.425） | 選項文字一起讀：外部實驗發現多加一個無關選項，會改變其他選項之間的比例 📚；72 類的 Banking77 有 0.87 📚 |
| 機率 | softmax 輸出，一般用交叉熵訓練，校準要自己驗 | 用強化學習訓練校準，但它自己說出廠偏過度自信，要自己重新調溫度 | 訓練目標就是校準（RLCD）📖；我們量到 ECE 0.041 🔬 |
| 能不能自己訓練 | 一定要（要有標註資料） | 可以微調 | 不行，所有帳號共用同一組權重，只能靠 state、instructions、criteria 調整 📖 |
| 部署與成本 | 自架 | 自架，Apache 2.0，沒有每次呼叫的費用 | 只有 API：每百萬 input tokens 0.042 美元，output 不收費 📖；資料會送到外部 |
| 語言 | 看底座 | 多語版號稱支援百種以上語言，但繁中意圖分類只有 0.61 🔬 | 官方說英文最好、CJK 較弱 📖；我們量到繁中意圖分類 0.93 🔬 |
Jev 內部到底長什麼樣，官方沒有公開。有人用兩千多次 API 呼叫做黑箱實驗（Jev's Architecture Unmasked）📚：「state 只編碼一次、題目之間互相看不到、同一題的選項會一起讀」這三點有行為證據支持；「因果式 transformer、可能是 MoE、活躍參數約 10B」是推測，作者自己標明這部分最不確定。
💭 分界線不在「誰比較準」，在你手上有沒有訓練資料、題目會不會一直換：
- 用 BERT（或任何自己訓練的小分類器）：任務固定、類別固定、有上千筆標註、量大到每次呼叫的成本都要算、資料不能外送。
- 用 Laya：條件跟 BERT 一樣，但你想沿用 Jev 的題目格式（多題一次問、選項用文字寫），或想先用 Jev 標資料、再蒸餾成自架模型。微調後在自己的分布上追得上 Jev，但信心值要自己重新校準。
- 用 Jev：任務是新的、沒有標註、題目常常改、state 很長、需要可信的機率拿來分流，而且資料可以送到外部 API。
常見的組合是先用 Jev 上線、累積標註，等流程固定、量也夠大，再蒸餾成自架的小模型。TypeSafe 自己的 cookbook 就示範過拿 Jev 的機率去訓練下游的傳統模型 📖。Laya 的正面對照見 suites/laya-head-to-head/；Laya 以外十幾個開源變體、相容伺服器與擴展函式庫的整理見 jev-variants.md。
我們（用真實 API 呼叫，不是估的）加上讀到的第三方跑分，反覆驗證出同一條軸：
正確答案能不能完全從你餵給模型的
state裡讀出來，還是需要外部知識/比較，而那些不在state裡？
| 訊號自足（state 裡有） | 訊號不自足（需要外部知識） |
|---|---|
| ✅ 分類任務（AG News 91%、Banking77 87%——jev-benchmarks） | suites/history-recall-context/） |
✅ 引用支持度判讀（claim+quote 都給齊——見 suites/citation-support-check/） |
|
✅ 反諷/諷刺偵測（觸發線索在給定文字裡，即使跨對話回合——見 suites/sarcasm-vs-sincere-praise/） |
|
✅ 逐句選表情，當標準答案是「人看文字會選哪個」（0.807、ECE 0.049——見 suites/expression-selection/） |
這條軸還有一種更隱蔽的違反方式：不是任務需要外部知識，是呼叫方自己沒把該給的內容放進 state。真實案例：有人試著用 Jev 判斷該不該砍掉 Agent 自己過去的工具呼叫紀錄（context 壓縮）。真實測試中，預設設定下打分看不到輸出內容本身，256 筆結果裡 0 筆保留信心值超過 0.3，等於幾乎每次都判定「可以刪」。這裡的判斷失敗好修，但「砍掉的內容不一定能復原」這個風險改不掉。這正是 AGENTS.md 已經講的「不可逆動作不該交給機率模型」原則，只是藏在「內部清理」裡，不容易被認出來。我們不建議把它做成無人監督、預設自動開啟的東西。完整追蹤見 translations/jev-context-compaction-debate-zh/。
同一件事後來有人完整量過：📚 一個第三方實作（hermes-jev-skills）把「用 Jev 挑哪些回合該留進交接摘要」在七個真實 session、104 題回憶考上量完，然後把 Jev 拿掉：Jev 版 37.5%，輸給單純取最後一段的 48.1%（逐題 4 勝 15 敗），出貨版改成「整段對話＋1,200 字、不用 Jev」，58.7%。它的失敗理由跟上一段不一樣：這次 state 是給齊的，Jev 的判斷本身也確實比「取最近的」好（逐題 11 勝 4 敗），輸的是「挑回合」這個問題形狀。留下來的回合仍然只保留前 400 字元，而每回合平均有 1,400–7,400 字元，裁掉的東西不是換一組回合能救回來的。這給了那條軸一個補充：把任務改寫成 Jev 能答的形狀之後，還要再問一次「這個形狀本身能不能完成原本的工作」。見 translations/hermes-jev-skills-zh/。
來源標記：🔬 我們自己測的（附收據）／📚 第三方來源（我們沒有重跑）／📖 TypeSafe 官方文件／💭 我們自己的判斷；完整定義與收錄準則見 CONTRIBUTING.md；每組實驗的方法論與逐項收據在各自的 suites/ 目錄。
- 先讀 TypeSafe 官方的 skill，學怎麼呼叫 API、怎麼設計 Choice/Score/Noul 題目，那件事他們寫得很好，我們不重複。
- 再讀這裡的
capability-map.md（English），對照你要做的任務屬於「訊號自足」還是「需要外部知識」，校準你該有的期待值。想找「原來可以這樣問」的靈感，看jev-patterns.md：按手法、不按領域整理，附代表實作與證據。 - 信心閾值自己在你的資料上驗，不要照抄任何一份報告（包括這份）裡的數字，TypeSafe 自己的文件也這樣講。三段式起點：高信心→自動執行；中信心→先確認；低信心→升級給人或給完整推理能力的模型。
- 遇到需要「知道什麼」而不是「判斷什麼」的任務，先做檢索、把資料放進
state。原因不是它一定記不得（我們自己的冷門史實題它不給背景也以 0.87 的信心答對），而是記不記得你事前看不出來；放進state後同一題升到 1.00。見suites/history-recall-context/跟第三方真實案例 湖北新聞分類。 - 單題判斷真的弱，才拆成多個原子化問題疊加，不要預設拆解一定比較準。一份第三方跑分量出來：拆解在三個任務上確實拉高準確率，但在「看起來危險、其實無害」的困難良性案例上，誤判率從單題的 1.5% 惡化到拆解版本的 37.2%，約 25 倍；多分類問題也別一題問到底（12 選項單題判斷準確率只有 0.3998，是那份跑分裡最差的結果）。拆解結果適合當第二意見疊加，不建議單獨扛安全把關這類判斷。細節見
capability-map.md。 - 先問你現在的判斷成本是不是已經是零，再決定要不要接 Jev。如果你本來就在用訂閱制的工具（Claude Code、Codex 這類），一次額外的大模型判斷邊際成本本來就接近零，插一層 Jev 進去只會多一層延遲、多一次出錯機會，省不到錢；Jev 真正划算的地方是原本要為每次判斷額外付費呼叫大模型的場景。另外，「快」指的是沒有長尾，不是中位數領先：另一份第三方跑分與我們自己重跑的量測都顯示，Jev 中位數延遲不一定贏過輕量大模型，但幾乎不會出現讓人等到抓狂的離群慢查詢，這對使用者可見的即時互動場景比單純比中位數更重要。細節見
capability-map.md、suites/jev-latency-distribution/。 - 想換成開源自架的替代品（例如 Laya）之前，先分清楚你的任務是「固定工作流程、有訓練資料」還是「新任務、直接問」。我們用同一組輸入實測：Laya 微調過的專用版在自己的訓練分布上準確率小贏 Jev 3 個百分點，但校準差五倍；沒微調的通用版低於「完全不看輸入」的基準線，中文意圖分類落後 Jev 約 30 個百分點。見
suites/laya-head-to-head/。 - 評分題（Score）的每一個等級，都要寫成文字裡直接看得到的情境。TypeSafe 官方的複合評分範例拿履歷篩選示範：等級寫成「No Python experience mentioned」「Mentioned but no detail」「Used in projects, some specifics」這種看履歷就能核對的描述，每個維度分開評，權重寫在你自己的程式碼裡 📖（Composite scoring）。需要跟外部比較的等級（「這個結果很重要」）文字裡查不出來，那就是核心那條軸在評分題上的樣子。
- 送出去之前，先想清楚
state裡有什麼。Jev 是雲端 API，沒有地端版本，你放進state的每一個字都離開了這台機器。一個第三方實作把分層做得很細，值得照抄 📚：信箱/電話/token 先遮蔽、檢索段落的來源 id 與路徑換成P0/P1只送內容不送出處、看起來像憑證的整段直接不送、敏感路徑改送粗特徵（長度、有沒有程式碼、有沒有風險字眼）。有一個細節特別容易漏：先解碼再篩。電子報頁尾會把收件人地址 percent-encode 在退訂連結、base64 在追蹤連結裡，純文字的遮蔽器兩個都看不到。還有一條順序問題：如果判斷發生在 agent 行動之前（例如用 Jev 決定這一輪要用哪個模型），「叫 agent 不要送客戶資料」這條指示對它無效。見translations/hermes-jev-skills-zh/、AGENTS.md。
直接讀 AGENTS.md，不要從這頁散文推。那份文件分兩種情境：被叫去評估別的專案哪裡適合換 Jev（掃描判準+檢查清單），或被叫進這個 repo 本身跑測試/加測試（含跑既有 suite 的指令、新增 suite 的步驟、以及回報結果的具體協定：有沒有 push 權限分別該怎麼做、回報裡一定要包含什麼）。也有正式打包成 Claude Skill 的版本，見 skill/jev-fit-check/，可以用 claude plugin install 直接裝（僅涵蓋「評估別的專案」那部分）。
歡迎四種貢獻：①新的測試組 ②整理並查證外部來源（跑分、文章、貼文、repo）③純分析/心得 ④修正或補充既有頁面（變體清單、實作指南、能力地圖）。收據優先，不收手打數字。①要附真實 API 回應的原始 log，其他要附可查證的一手來源連結。什麼收、什麼不收、新東西該放哪裡，見 CONTRIBUTING.md 的收錄準則。
README.md / README.en.md 本頁雙語（含機制說明，不是另開檔案）
AGENTS.md 給 agent 讀的掃描判準
capability-map.md / .en.md 那條軸的彙整表，持續更新
browser-automation.md / .en.md 瀏覽器操作的實作指南（架構、打字問題、真實實作）
virtual-character-expressions.md / .en.md 虛擬角色表情的實作指南（決策表、參考架構、VRChat／VTuber）
jev-variants.md / .en.md Jev 的開源變體、相容伺服器與擴展函式庫（附查證狀態）
jev-patterns.md / .en.md 用法模式：按手法整理「不看別人做想不到」的用法（附證據與失敗條件）
CONTRIBUTING.md 貢獻規則
skill/jev-fit-check/ 打包成 Claude Skill 的 AGENTS.md
suites/ 每組實測（方法論＋協定＋真實 log＋報告）
translations/ 國外跑分的翻譯與整理（只翻結果，不翻題目）
analysis/ 沒有單一既有條目可掛的純分析（跨條目觀察、判準軸本身的批評）
scripts/common/ 共用的 API 呼叫樣板，不用各自重寫
scripts/zh-check/ 簡體字檢查（每個 PR 自動跑）與 Jev 校稿複查工具
程式碼與原創內容 MIT（見 LICENSE）。translations/ 裡是我們自己寫的摘要與查證，不是原文翻譯稿；被引用內容的權利仍屬原作者，詳見 NOTICE。貢獻條目前請先讀 CONTRIBUTING.md；要轉載超過短句的原文，得先確認原始授權，否則有法律風險。
本專案與 TypeSafe 無關，未受其委託或贊助。「Jev」「TypeSafe」為其各自所有者之商標，此處僅作指涉之用。