Swimm

一句話結論

現在的 Swimm 已經不是你印象中那個寫程式文件的 IDE 外掛，而是一家幫大企業拆解大型主機與老系統的現代化公司——想找程式碼文件工具的人，該看別家了。

實際的產品邏輯

這是這次評測裡轉型最徹底的一個。Swimm 早年的產品是「docs-as-code」：文件跟程式碼放在一起、跟著程式碼變動自動提醒更新，有 IDE 外掛和免費方案。2026 年 3 月 24 日官方發布 Swimm 2.0，自己把定位改成「AI 現代化的理解平台」，並坦白說公司正在變成一家服務公司。舊的免費 IDE 外掛與 docs-as-code 模式在新官網上已經找不到。

現在的 Swimm 分三層運作：確定性分析（自家引擎靜態分析相依性、資料流與跨 repo 關係）、以靜態分析為錨的生成式 AI agent（把模式套用到整個程式庫），再加上資深工程師的人工驗證。支援 COBOL、JCL、PL/I、CICS 等主機語言，也做 .NET、Java 遷移與單體拆微服務。另外它提供 MCP 伺服器，讓 Copilot、Cursor、Claude Code 這類 AI 工具可以直接讀取經過驗證的系統理解，官方稱之為 Agentic Context Layer。

合作模式是四階段的固定價格專案：評估、規格、現代化、能力移轉給內部團隊。定價頁只寫「依要理解的程式碼行數計價」，沒有公開數字。

優點

方向很清楚：它押的是「AI 自動改寫老程式碼常常錯」這個痛點，所以用確定性的靜態分析打底，而不是讓 LLM 自己猜。官方引用一家美國前五大銀行的主機主管說法，稱 Swimm 產出的應用地圖經驗證「100% 準確」——這是客戶證言，不是第三方稽核，但方向對。支援地端與完全離線（air-gapped）部署、可以用客戶自管的 LLM，並有 SOC 2 與 ISO 27001，對銀行是必要條件。MCP 這一層很聰明：它不跟 AI coding 工具搶，而是當它們的上游，提供可信的上下文。

缺點

對一般開發團隊來說，Swimm 已經不再是可自助購買的工具，得先約 demo、談專案，門檻很高。固定價格專案加人工驗證，本質上更接近顧問服務，成本與時程都不是 SaaS 月費的量級。舊版使用者如果還在找當年的文件功能，會發現產品已經轉向，需要另尋工具。官網公開的具名客戶很少，多數是匿名證言，評估時要主動要求參考客戶。

適合誰

核心系統還跑在大型主機上、COBOL 工程師逐漸退休、正在規劃現代化的銀行、保險與政府單位；要做大規模 .NET 或 Java 遷移、需要先搞清楚既有系統在做什麼的企業 IT。不適合新創、一般 SaaS 團隊，也不適合只想維護 README 與 API 文件的人。

台灣觀點

台灣不少銀行、壽險與公部門的核心系統仍然跑在大型主機上，懂 COBOL 的資深工程師年年退休，「系統在做什麼只剩老師傅知道」是真實風險。Swimm 這類以靜態分析為主、可以離線部署的方案，在資料不能出境的前提下是可行選項。但它的中文支援沒有公開說明，程式碼裡的中文註解、Big5 編碼的舊檔案處理能力，一定要在評估階段實測。國內也有系統整合商在做主機轉置，可以把 Swimm 當成分析工具搭配在地 SI 執行。

替代方案

Kodesage 同樣瞄準老系統理解與現代化，是最接近的比較對象；想要程式碼問答與跨 repo 理解，Augment Code、Greptile 與 Cody 更輕量、可以自助試用；只是要自動產生或維護開發文件，Mintlify 或 GitBook 才是對的工具。