21個容器零文檔，本地大模型一小時內全搞定

我做了一件多數開發者都想過、但很少真動手的事：把二十多個Docker容器的Compose文件全部扔給本地大模型，讓它在沒有任何人工提示的前提下，自己反推出每個服務的用途、配置邏輯和彼此之間的關系。這原本是個近乎自虐的任務，但最后花的時間不到一小時，而產出的文檔質量，比過去任何一次手動維護都要好。

事情的起點很普通：我的homelab里，Docker容器的數量不知不覺就突破了20個。不到一年前，我手上還只有寥寥兩三個服務棧，現在每周都會加一兩個新實驗。其中有每天依賴的固定服務，也有只跑幾天就關停的臨時應用。問題在于，這些容器我當初親手配置完成之后，上線就再也沒怎么碰過——除非它們出問題自己來找我。日子一久，我甚至回想不起當時為什么會這樣配端口、為什么選擇那個鏡像版本。Compose文件能清晰展示Docker是怎么運行它的，卻完全無法告訴我當初做這些決定的真實理由。

這種“跑著就好，別管為什么”的狀態，在容器數量超過20之后，幾乎必然導致知識斷層。真正當某個服務需要遷移、調試，或者關停很久后再次啟動，我才會意識到自己對它一無所知。也就在這兩周，我開始認真使用本地大模型，把Gemma 4、Qwen 3.5和DeepSeek-R1全部部署在了自己那臺帶RTX 4070 Ti的游戲PC上。之前我曾把一份65萬行的網絡DNS日志喂給Gemma，讓它自己找出異常模式，實驗成果相當不錯。既然模型對大體積半結構化數據能抓出線索，那干脆把Compose文件也交給它，看看它能不能把部署意圖給“還原”出來。

當真的開始整理Compose文件時，我很快發現，這只是“毫無文檔”的表面之下，更深一層混亂的真正入口。我一直用Portainer來可視化管理這些容器，原以為所有Compose文件都會被規整地放在一個數據卷里。但某次Portainer升級時，它拉取的新鏡像初始化到了另一個卷名下，于是就有了兩套卷、兩套結構，再加上幾個非Compose管理的容器，它們的配置散落在JSON文件里。我本來可以輕巧一點，只拉取運行中的容器列表，但這次實驗我不想要一個“干凈”的環境——我要的是一個真實的homelab，帶著它所有的歷史包漿。所以，我把能找到的全部Compose YAML都拉了出來，包括那些早就退役的（Cloudflare、Watchtower、Newt），也包括那些因為并行實驗而臨時暫停的（Pi-hole、dnscrypt-proxy、Meilisearch）。總共二十多個文件，沒有分類，沒有注釋，就這么堆在一起。

真正讓我下定決心的，是面對這堆文件時的無助感。單看每一個Compose文件我都能懂，但同時又確信，如果不在今天做點什么，再過兩周我連現在這份“懂”也會忘干凈。換句話說，此刻正是用模型生成文檔的最佳時間窗口——我對所有容器還殘留著足夠多的短期記憶，能判斷模型產出是否亂說，而模型又能把那些即將消失的長期意圖固化下來。這種“人機互補”的感覺，是促使我快速動手的核心動力。

在此之前，我所有的本地大模型實驗都是用定制前端加上Python后端來驅動的。我太熟悉React做交互界面、Python搭API這條鏈路了，以至于對于這次全新的文檔生成任務，我本能地覺得現有的接口（比如Open WebUI）雖然能用，但不夠順手。我想要的，是一個能逐容器輸出Markdown或HTML、允許我當場編輯措辭、并且可以連續追問上下文的交互環境。所以沒多做猶豫，我直接動手搭了一套全棧的面板：前端用React接管所有容器條目的分組、展開和就地編輯，后端通過Python調用本地模型推理接口，并且用簡單的狀態緩存維護每個容器的對話上下文。這套界面本身花費的時間，甚至比準備數據還要長一些，但它給了我最需要的東西——一種不是“提問-回復”數據庫式的僵硬對話，而是像跟同事坐在一起一塊兒看配置文件那樣的協作感。

把二十多份Compose文件按原始目錄結構上傳完成之后，我沒有任何額外指令，只讓Gemma 4從第一個服務開始，逐個給出它理解的：這個容器在做什么、為什么要這樣暴露端口、有沒有特殊的環境變量邏輯、以及可能與其他容器之間的依賴關系。第一批輸出出來的時候，我下意識地拿它和我心里的印象做對比——驚異地發現，模型不僅能在絕大多數服務上準確抓出核心用途，還能在好幾個我已經忘記的場景里，通過端口映射和環境變量組合，還原出我當初想要解決的那個特定問題。比如有個監控類容器，當初為了繞過某個網絡策略，我配置了一組奇怪的DNS設置，模型直接指出“這個配置看起來是為了在私有DNS解析失敗時，回退到公共解析器”。那一刻我甚至有點后背發涼：因為它不僅讀出了配置，還讀出了當時的意圖。

當然，并不是每條輸出都這么精準。第一個草稿里，模型把兩個實驗性容器的關系錯當作主從架構來描述，把其中一個停止狀態的Web服務誤判為還在為另一個提供后端支持。但這樣的錯誤，在擁有可編輯界面的條件下，修正起來非?？臁恍枰诿姘謇稂c開對應的條目，把錯誤描述改掉，再告訴模型一句“這兩個其實是獨立測試，彼此沒有關系”，它就能立即糾正該容器的文檔，并且不會在其他容器的描述中再次犯同樣錯誤。這種就地微調、上下文即時生效的能力，與其說像在使用工具，不如說像在訓練一個能讀懂項目歷史的新同事。

更難得的是，模型在生成過程中還自動識別出了容器之間的潛在分組。在沒有輸入任何網絡拓撲信息的前提下，Gemma 4僅憑Compose文件里的網絡名稱、外部鏈接和共同出現的卷掛載，就把所有服務分成了幾個清晰的集群：核心基礎設施、媒體與存儲、網絡與代理、以及實驗沙箱。這個歸類后來直接變成我內部文檔的大章節標題。我唯一做的事情就是看了一眼分組，確認沒有邏輯硬傷，然后全文保留。相當于整個homelab的運維手冊框架，由一個本地模型在一小時內自動搭建完成。

這次實驗給我的最大啟發，并不是“大模型能寫文檔”這個結果本身，而是它揭示出一種新的文檔生成范式：從配置逆向推導意圖，再用人機協作快速校對和凍結結果。在以往，開發者面對老項目，要去翻commit記錄、看環境變量、查Wiki，然后重新拼湊出當時為什么會那么做。而有了本地大模型之后，我完全可以把所有配置文件、環境變量和部署描述一次性喂給它，先拿到一個用“意圖級”語言寫成的初稿，再基于我自己仍然留存的經驗去校準。這效率的差距，不是漸進的改進，而是工作流結構的徹底翻轉。更重要的是，所有數據都跑在我自己的機器上，沒有任何一行配置離開過本地網絡，這對需要處理生產環境信息的人來說，幾乎是不可替代的先決條件。

當我把這批自動生成的文檔分發給幾個一同維護homelab的朋友時，他們第一反應都是“你終于舍得寫了”，而得知這不是我手動寫的之后，語氣立刻變成“能不能給我的Compose也跑一遍”。這讓我意識到，這種需求的規模遠比我想象的大——幾乎每個長期維護私有服務器的工程師，都生活在容器配置“只有自己知道”的脆弱平衡中。一旦本地大模型能將這種隱性知識轉化為結構化的共享文檔，它所撬動的就不只是個人效率，更有可能改變小團隊內部基礎設施可持續性的基本假設。

最后，那批退役容器的文檔也意外地成了這次實驗的重要副產品。Cloudflare、Watchtower、Newt，還有Pi-hole和dnscrypt-proxy這些服務，雖然已經沒在運行，但因為形成了完整的配置記錄，我反而能從歷史角度看清自己的網絡架構是如何一步步演進的。這種演進脈絡，以前只存在于我的零散記憶和每次折騰時留下的臨時筆記里，現在被模型用一致的語言重新講述出來，變成了一份活的技術編年史。說真的，看完它生成的那些退役服務說明，我甚至有些遺憾自己過去那么多次遷移和廢棄，連一則簡單的退出說明都沒留下。

一個小時內，從零文檔到一份包含了所有運行容器、停運容器，甚至實驗容器的完整手冊，這幕后的角色切換很微妙：我不再是那個在空白頁面前苦思冥想的撰稿人，而是變成了一個有實權的審閱者。而那個真正把空白頁填滿的，是一個運行在我顯卡上的本地模型。這種體驗帶來的心理變化，可能比省下的那幾個小時更值錢。我開始不自覺地把未來的每一次部署改動，都看作一個可以交給模型去首輪封裝的事件，而自己只需要做最后的把關。在開發者工具的鐵律里，只有真正降低認知負荷的東西，才能嵌入日常流程；這一次，本地大模型做到了。