如何用 Claude 把網路拓撲圖和 BOM 變成一份部署手冊

一句話結論：Claude 可以同時讀取匯出的網路拓撲圖和設備 BOM，起草一份有先後順序的部署手冊——上架順序、逐埠的佈線對照表，以及一份 UAT 驗收簽核清單——用一個下午，而不是三個晚上。它產出的是一份供部署工程師去修正並承擔責任的初稿。它看不見現場。

設計已經簽核。採購單三週前就發出去了。四個棧板將在十一天後送到一個新的六十工位辦公室，而負責開箱的兩名現場工程師手上只有一份網路拓撲圖的 PDF、一份四十三行的 Excel BOM，以及一個週一的開工日期。

他們沒有的，是一份部署手冊——按順序列出：什麼設備上架到哪個 U 位、哪條線接進哪個埠、哪台設備必須先設定好下一台才能測試，以及在任何人簽署交接單之前，什麼必須被證明是通的。

於是他們憑經驗現場發揮，而且做得不錯，大部分都很順利。然後三樓的無線基地台起來時掛在了錯誤的 VLAN 上，因為交換器埠樣板是在現場而不是事先定下來的；標籤和圖面對不上；六週之後，沒有人能從文件裡說清哪個配線架埠餵的是會議室那塊顯示器。

這個落差——設計已經完成，而施工卻沒有被排序——是一個「寫文件」的問題，不是一個工程問題，而它恰恰是值得交給模型的那一部分。

為什麼「圖面畫完了」之後，施工班組還是只能靠猜

拓撲圖陳述的是最終狀態，部署手冊陳述的是操作順序。第二樣並不會自動從第一樣裡長出來。系統整合商的部署專案經理之所以年復一年在進場前一晚手寫手冊，是因為這兩者之間的轉換枯燥，而不是因為它難。

圖上畫著一台帶 WAN 埠的防火牆。它不會告訴你：電信業者電路的交付日期握在第三方手裡，在它落地之前下游任何東西都無法被正經測試，因此班組需要一份明確的「如果延期，第一天做什麼」的備案。

而對於最消耗現場時間的兩樣東西——標籤規範和埠位對照表——圖面隻字未提。兩者都是當天由拿著標籤印表機的那個人臨場發明的，而下一個到場的工程師將完全依賴它們。

代價在班組撤場之後才出現。竣工文件要靠某人手機裡的照片來還原。UAT 變成了一句「我們測過了，是通的」。半年後的一次變更，要從一輪本不該必要的盤點排查開始。

Claude 能從一張圖和一份設備清單裡起草出什麼

Claude 能讀圖像和文件，所以從 Visio、Lucidchart 或 draw.io 匯出的 PDF 或 PNG 可以直接餵給它，旁邊再附上從 Excel 複製成 CSV 的 BOM。它讀的是圖上標註了的東西。它不評判設計是否成立，也看不見那棟樓。

在這個邊界之內，有兩樣輸出確實值一個下午。

一份排好順序的上架與佈線核對清單

給它拓撲圖、BOM，以及你自己的機櫃配置規範，它會產出一份有序的安裝清單：什麼裝在哪裡、按什麼順序、相依關係寫明白——供電與接地先於任何上架動作，核心交換器先於接取層，防火牆先於任何需要連網啟用授權的設備。

真正省時間的那部分是埠位對照表。從一張標明了設備互連關係的圖面出發，它會起草出這樣的清單：「SW-CORE-01 埠 1/0/24 接 FW-01 埠 ge0/1，標籤 A-24」——每條實體連線一行。這恰恰是沒人願意手敲的那份材料，也恰恰是能讓班組在下午四點不必靠猜的那份材料。

要明確指令它：凡是圖面沒有規定的地方——一條沒有標註的鏈路、一台沒寫機櫃位置的設備——一律標成「設計未指定」，而不是替你做決定。僅這一條指令，就構成了「一份手冊」和「一份負債」之間的大部分差別。

一份與設計所宣告功能一一對應的 UAT 測試與簽核清單

同樣的輸入還能產出一份可執行的驗收清單，而這正是多數新站點建置真正缺失的文件。如果設計寫了上行備援，清單裡就該有一步：拔掉其中一條，確認切換成功。如果寫了訪客 Wi-Fi 與辦公 VLAN 隔離，就該有一步：從訪客 SSID 嘗試存取一個辦公資源，並且預期失敗。

一套可落地的流程：從圖面和 BOM 到一份能帶進現場的手冊

1. 把圖面匯出為 PDF，並檢查它在實際閱讀的尺寸下是否清晰。模型讀圖面和工程師讀圖面遇到的是同一個問題：如果埠位標註是壓在交叉線下面的四號字，就一定會被讀錯。用合理的比例匯出；如果圖面有多個頁籤，分別匯出成不同檔案，並說明每一張是什麼。

2. 上傳前先清洗，每一次都要做。站點地址、客戶的法定名稱、公網 IP 區段、電路編號，以及任何看起來像憑證的東西，先刪掉。這裡面大部分是一次尋找取代，換成「站點 1」和「客戶 A」。把它定成一條硬性規則，而不是一次判斷——因為在趕工期的時候，最先失效的就是判斷。

3. 給它你自己的規範，而不是讓它給「最佳實務」。把你公司實際使用的機櫃配置規則、設備命名標準、標籤格式和手冊範本貼進去。「寫一份部署手冊」產出的是泛泛之物；「用這些命名規則填充這個範本」產出的才是你的工程師認得、並且真的會帶進現場的東西。

4. 先單獨產生安裝順序。要求編號步驟，寫明相依關係，每一步註明負責人。讓它把任何相依第三方的步驟單獨標出來——電信交付、業主方管道間開放、大樓水電——因為正是這些步驟會延期，它們需要出現在計畫的最前面，而不是埋在第三十四步。

5. 埠位對照表作為第二輪，單獨產生。窄指令的多輪處理，好過一次要它把什麼都辦了。這一輪要求：每條實體連線一行，設備名稱一字不差地沿用圖面上的，凡是圖面沒有埠號的地方寫「未指定」，絕不編一個看起來合理的出來。

6. UAT 清單作為第三輪產生，只依據設計中明確宣告過的能力。每一行是一個測試、一個預期結果、一個簽核位。同時要求它單獨列出那些它無法轉成測試的內容——這份清單通常很短，而且是給設計負責人的一組很有用的問題。

7. 在它離開你的桌面之前，你自己對著圖面讀一遍。你在查兩樣東西：接錯的連線，以及那些寫得很篤定、但圖上根本沒有的連線。第二種更難發現，恰恰因為它讀起來是對的。

8. 把每一處「未指定」變成一條編號問題，發給設計負責人。這是整件事裡價值最高的產物。在進場之前得到解答的十二個具體問題，就是十二個不會由一位疲憊的工程師在週五傍晚六點、一手還拿著標籤印表機的時候拍板的決定。

9. 把它列印出來帶到現場，用筆在上面批註。批註過的那一份就是竣工記錄。撤場前拍照留存，再讓同一個模型把它轉錄回手冊文件——這就是在沒有任何人主動貢獻一個晚上的前提下，拿到竣工文件的辦法。

AI 起草的手冊 vs 持證部署工程師的手冊 vs 到現場再隨機應變

• AI 起草的手冊。幾小時而不是幾個晚上，在枯燥的部分——埠位表、UAT 條目、標籤清單——上面極其詳盡，而且因為是從範本產生的，站點之間保持一致。它沒有現場認知、不承擔任何專業責任，而且除非你明確禁止，否則它會對一條圖上從未出現過的連線寫得很篤定。正確用法：作為部署工程師去修改並承擔責任的初稿。
• 持證部署工程師的手冊。一位在真實大樓裡裝過設備的人判定了這個順序能跑通，並且已經把那條已經塞滿的管道間、那部只到四樓的電梯、以及只有週二在場的水電都算了進去。那份判斷才是真正的交付物——這恰恰說明為什麼「轉錄」那一半值得自動化，而「判斷」那一半不值得。
• 到現場再隨機應變。比這個行業願意承認的更常見，而且通常也能成，因為優秀的現場工程師本來就擅長這個。它的代價當天看不見，之後卻很貴：沒有埠位表、沒有 UAT 記錄、竣工文件靠回憶拼湊，而第二個站點和第一個站點沒有任何共用的規範。

它在哪些地方不夠用

它看不見現場，而部署恰恰是在現場翻車的。那條已經塞滿的管道間、那間只有一個十三安插座的弱電間、那扇被線槽畫著直穿過去的防火門——這些都不在圖面上，所以也都不在手冊裡。文件會看起來很完整，同時漏掉決定這一天成敗的那個限制。

編造出來的「精確」是它的典型失效方式。當被要求產出一份看起來專業的手冊時，模型會補上似是而非的細節：一個沒人指定過的埠號、一個由它默默做出的假設推出來的 U 位。它讀起來和正確的那些行一模一樣，而這正是它在一個沒人對照圖面複核的現場上的危險之處。

安全與電氣合規不是文件問題。負載計算、接地、線槽、高空作業，以及任何涉及大樓供電的事情，屬於有資格的水電技師和當地法規，而不屬於一份模型產出的清單。這些內容留在手冊裡的形式應當是「通知對應工種介入」的指令，絕不能寫成讓人照做的操作步驟。

它沒有資格簽核任何東西。一份 UAT 表之所以有價值，是因為一位具名的、有能力的人在他真正跑過的測試旁邊簽下了姓名縮寫。一份大家在漫長一天結束時統一打勾的產生清單，比沒有清單更糟，因為它看起來像證據。

把這件事做對——設計檔案的機密性、版本控制，以及什麼時候該讓 IT 介入

網路拓撲圖是一份安全文件。它展示了拓撲、分段、管理 VLAN，經常還有位址規劃，而且必然包含邊界設備的廠商與型號。它對攻擊者來說是一份真正有用的材料，而它卻經常作為附件被郵件發來發去、被上傳到聊天工具，並留在三台筆電的下載資料夾裡。

搞清楚你上傳的到底是哪個工具的哪一檔。個人版、團隊版和企業版在資料留存以及內容是否可能用於訓練上是不同的，而且條款會變——請查閱你公司所用的那個具體方案的當前官方文件，不要靠假設。然後在公司層面定一條規則：哪些工具可以接收客戶的設計檔案。在多數專業服務公司裡，這是最大的一塊失控的 AI 風險，而它是治理問題，不是技術問題。

版本控制在這裡比平時更要緊。這套做法會產出看起來已經完成的早期文件。在合格的工程師簽核之前，在文件頂部放一行可見的狀態——「AI 輔助初稿，未經審閱」——並把手冊放在一個受控位置，比如 SharePoint 或 Confluence，而不是作為附件在郵件裡流轉。班組帶進現場的那一版，必須是任何人能找到的唯一一版。

決定 AI 在交付流程裡該佔哪個位置、寫好那些範本、並定下「什麼可以上傳」這條規則，是 AI+ 支援的工作；底下的存取控制、設備管理和資料處理，則是常規的管理式 IT 支援。而真正不能自動化的那部分，是 IT 基礎架構部署本身——那些做上架、佈線、勘測和調試的持證現場工程師，讓設備到場時就已設定好的場外預組建，以及在 UAT 表上簽核的那個人。如果你要記錄的是搬遷而不是新建，我們關於用 AI 起草辦公室搬遷手冊的文章涵蓋了這個問題的「遷移版」，而把摸底溝通變成 HLD 和 BOM涵蓋的正是這份手冊所承接的設計階段。

常見問題

這能取代持證現場工程師嗎？

不能。客戶在一次部署裡買到的，是一位有資格的人判定了這個順序在那棟樓裡能跑通，並在交接時為結果背書。模型無法承擔這份責任。它取代的是手敲埠位表和 UAT 表的那兩三個晚上——是設計與施工之間的轉錄工作，不是施工本身。

現場和圖面對不上怎麼辦？

現場幾乎總有對不上的地方，而這恰恰是手冊要列印出來帶到現場的原因。工程師標註偏差、寫明原因，那份批註過的副本就成了竣工記錄。一份在現場不允許被推翻的手冊，就是用錯了；它的職責是讓偏差顯形，而不是假裝偏差不會發生。

輸入的圖面需要詳細到什麼程度？

詳細到在設備和連線關係上沒有歧義即可。有埠位級標註當然最好，但不是必需——一張沒有埠號的邏輯圖仍然能產出有用的安裝順序和 UAT 清單，只是會產出一份更長的「未指定」清單，而那本身也是有用的。唯一會真正拖垮輸出品質的輸入，是標註讀不清的低解析度匯出圖。

它事後也能產生竣工文件嗎？

能，而且這是這套流程裡被低估的另一半。把批註過的手冊拍照，連同原始版本一起餵回去，要求它產出一份「計畫 vs 實際」的對照文件，逐條列出所有偏差。那是轉錄工作，正是它擅長的。讓實際施工的那位工程師複核——轉錄是機械的，但判斷某個偏差要不要緊不是。

實際操作下來要花多久？

對本文這種規模的單站點辦公室建置，大約一個下午，而同樣的文件手寫要兩三個晚上——第一次會更慢，因為你要邊做邊把範本寫出來。更大的收益在於：埠位表和 UAT 清單終於存在了，而在這類站點上，老實說它們通常並不存在。