用ChatGPT生成辦公室IT搬遷作業手冊

簡而言之： 把資產清單、線路開通日期，以及那個唯一挪不動的日子交給模型，然後讓它從那個早晨倒著往前排，而不是從今天往後順著排。一個下午就能拿到一份站得住腳的四階段作業手冊。但它不知道你的電信商真實交付週期，也不知道業主的規矩。

辦公室搬遷的計畫，通常由離問題最近的那個人來做——多半是行政主管或營運負責人，手上拿著仲介發來的一張表格，而整個IT部分在這張表上只是一行字：「IT——搬電腦」。這一行字實際上是四十到兩百項獨立任務，其中大約三分之一必須在任何人動一張桌子之前的好幾週就完成。

搬遷作業手冊是一種高度結構化的文件，而結構化文件恰恰是語言模型真正擅長的東西。只要給它足夠真實的環境細節，它就能在一次對話的時間裡產出一份帶負責人、帶相依關係、排好日期的任務清單。限制值得放在方法前面說而不是後面：作業手冊是便宜的那一半。一個下午生成的東西，改變不了這個事實——到了那個週六，機櫃打開的時候必須有人在現場。

搬辦公室真正出問題的地方（很少是桌椅）

家具會到的，搬家公司搬東西很在行。去問任何一個真正操盤過搬遷的人「後來是哪裡出了問題」，同一份很短的清單會在不同公司、不同國家反覆出現。

線路沒通。 一棟從來沒接過專線的大樓，新拉一條光纖或專線，視市場以及管道間是否需要改造，可能要六到十二週。這是搬遷日期延期最常見的原因，而且純粹是交付週期問題——到了那天誰也壓縮不了。

某樣東西相依著另一樣，而沒人寫下來過。 倉庫的標籤印表機是對著一台即將除役的伺服器做驗證的。財務系統的授權綁在一個MAC位址上。掃描到資料夾指向一個即將換網段的共享目錄。這些都不複雜，只是沒有文件，然後在週一早上九點集中爆發。

有一台老設備沒辦法跟其他東西一樣搬。 幾乎每家中小企業都有這麼一台——又老又重要、廠商早已不支援、上一次重開機還是三年前。它需要一個屬於自己的小專案，而且必須在第一週就被辨識出來，而不是在搬遷週末。

壞掉的是門禁，不是網路。 門禁卡、警報密碼、非上班時間進入的登記流程，以及業主保全櫃檯的名單上寫的是誰的名字。團隊在搬遷週六到了現場卻進不了自己要搬進去的那一層，是常態而不是意外。

第一天沒有支援模式。 技術上一切正常，四十個人還是列印不了，因為印表機裝好了但沒派送，而知道怎麼弄的人在飛機上。

生成的作業手冊自己就能涵蓋第一類的大部分，因為交付週期屬於通用常識。剩下幾類，只有你告訴它，它才會知道——這正是輸入環節存在的意義。

在你開始寫提示詞之前，一份有用的作業手冊需要哪些輸入

一份值得照著執行的作業手冊和一份泛泛的檢查表，差別完全在於你放進去了什麼。

線路交付週期、資產清單、相依關係，以及挪不動的日期

五樣東西，每次都是這五樣。

挪不動的日期。 租約起訖、舊場地必須按合約狀態交還的那一天，以及所有人必須能在新場地正常工作的第一個上班日早晨。大多數搬遷只有一個真正挪不動的日期，另外幾個只是看起來固定；整個排程都是從分清這兩者推導出來的。

連線的現況。 已經下單了什麼、找的哪家、確認的交付日期是哪天、如果延期備案是什麼。如果目前什麼都還沒訂，那這就是作業手冊的第一項產出，而不是中間的一個細節。

誠實的資產清單。 工作站、螢幕、印表機和事務機、話機、交換器、防火牆、無線AP、機櫃裡的一切，以及那幾台你其實不太想承認還在跑的實體伺服器。從RMM隨手匯出一份就夠了——完整比精確更重要。

相依關係圖。 哪些系統之間有通訊、哪些在地端哪些在雲端、哪些綁了固定IP或綁了硬體的授權、以及對外IP變了會導致什麼壞掉。這是最容易被跳過的一項輸入，也是回報最高的一項。

人的限制條件。 各團隊人數、週一早上絕對不能離線的是誰、哪些團隊必須坐在一起，以及搬遷窗口期內有沒有人出差。

把這些以純文字給模型，並且明確告訴它：在產出任何東西之前先向你提釐清性問題。一個先問八個問題的模型，產出的作業手冊明顯好過一個立刻開始寫的——而且那些問題本身，正是一個搬遷專案經理會問的東西。

組織產出結構——搬遷前、搬遷週末、第一天，以及兩週收尾

要求分成四個階段，並且說清楚每個階段該放什麼，否則你會拿到一長串沒有區別度的清單。

搬遷前，從十二週前開始。 所有帶交付週期的事：線路、採購、授權移轉、向供應商變更地址、綜合佈線與機櫃安裝、搬遷前稽核。這些任務的日期應相對於搬遷日標註而不是相對於今天，這樣排程在延期時還能活下來。

搬遷週末。 按小時排，寫明負責人，並在不可逆的那一步之前設一個「繼續或中止」檢查點。這是唯一應該以小時計時的階段，也是唯一順序真正重要的階段。

第一天。 刻意超配資源：現場巡場支援、一個集中受理點、一條明確的升級路徑，以及一份「十點之前最可能被回報上來的二十件事」的清單。

兩週收尾。 舊場地退場、設備歸還、關停線路以免繼續付費、更新文件、搬遷後檢討。這個階段被跳過的頻率高於其他任何階段，而錢正是從這裡悄悄漏掉的——舊線路在沒人使用之後還繼續計費好幾個月，幾乎是普遍現象。

要求輸出包含任務、負責人、階段、相依、目標日期，並且是可以直接貼進試算表的結構化文字。然後再問一個遠遠被低估的問題：這些任務裡哪些在關鍵路徑上，以及最有可能延期的是哪三項？

實例：一次60人辦公室搬遷，從週一早上倒著排

一家60人的專業服務公司要在同城兩棟大樓之間搬遷。舊租約在新租約開始五週後到期，而挪不動的那個日期是全公司必須在新地址開工的那個週一。機房裡有防火牆、兩台交換器、一台NAS，以及一台跑著某個廠商已不再積極開發的業務管理系統的實體伺服器。

週一上午九點是那個固定點。 往回推：網路必須在週日被驗證通過，也就意味著週六必須已上線並測試完畢，也就意味著線路必須至少提前兩週交付並測通——不能是前一週，因為線路測試失敗需要留出補救時間。僅這一條相依鏈，就把線路下單日期推到了大約十二週之前，這也正是「連線」成為第一項任務、而不是中間一個條目的原因。

那台老伺服器單獨走一條線。 它沒辦法像其他東西一樣週六搬、週日測，因為萬一起不來，沒有退路。現實的選項——提前一週做實體搬遷並拉一條臨時線路、搬遷前遷到雲端主機、或者接受一個更長且提前溝通過的中斷窗口——都是第一週就該做的決策。把它當成一件週六的任務，才是真正的錯誤。

工作站分兩批搬， 一半週五晚上，一半週六，這樣第一批發現的問題不會同時套在全部60台上。只要你要求模型辨識風險緩解機會，它很容易給出這類建議，而且不花一分錢。

第一天按平時三倍配人， 一人專門管列印，一人管其他所有事情，因為列印在第一天的案件裡確實佔了不成比例的一大塊。

模型在一個下午產出的，是一份約90項任務、相依關係合理、關鍵路徑站得住腳的作業手冊。它產出不了的是這條知識：新大樓的貨梯預約需要提前48小時，而且週日上午不開放——這條挪動了四項任務，是有人去讀了大樓管理手冊才發現的。

AI生成的作業手冊 vs 搬遷服務商的專案計畫 vs 硬著頭皮上

出初稿的速度與成本 — AI生成的作業手冊完勝。一個下午，邊際成本近乎為零，而且日期一變可以重新生成，而不必手工返工一張表格。
通用類目的完整度 — AI生成的作業手冊很強。交付週期、標準階段，以及那些人人都會忘掉的任務，在通用知識裡涵蓋得不錯，而且它寫到第70項也不會犯睏。
在地與大樓特定的知識 — 搬遷服務商壓倒性勝出。某個區域哪家電信商真的能按期交付、哪些大樓的管道間有問題、某個業主怎麼處理非上班時間進入。這些不在任何模型裡，而它們構成了大部分風險。
當天的責任承擔 — 搬遷服務商絕對勝出。一份作業手冊不會把機櫃從樓梯間抬下去，不會在週六晚上十一點接電話，也沒法被約束在某個服務等級上。
搬到一半出事時的應變 — 服務商勝出。車停在樓下、時間壓力之下重新排計畫，靠的是判斷和經驗，不是文件生成。
硬著頭皮上 — 只在省力這一項上勝出，而且相當多的中小企業就是這麼做的。失敗之所以昂貴，恰恰因為是在一個所有人都看著的週一早上被發現的。

這三者其實並不是互斥選項。一份生成的作業手冊，能讓你在開始談搬遷服務的時候就已經知道自己要買什麼、以及自己的環境哪裡不尋常——這個起點比一張空表格好得多，也讓專業服務的介入更短、更聚焦。

任何通用檢查表都不會包含的項目

有幾類東西對模型來說是結構性不可見的。

你的電信商真實交付週期，而不是公布的那個。 報價上的交付日期和實際交付日期，會因市場、因大樓、因管道間是否已經就緒而不同。只有最近在那個區域真正下過單的人才知道差距有多大。

業主的規定。 貨梯預約時段、允許施工的時間、要求搬家公司提供的保險證明、裝卸區是否共用、非上班時間進入的通知期。每棟大樓都不一樣，而且這些都不公開。

你的資料受到的法規或合約限制。 如果你持有的客戶資料受特定義務約束，把伺服器實體跨越某條邊界搬遷——或者在兩個據點之間拉一條臨時線路——可能會帶來值得事前而非事後確認的影響。在跨境情境下這是實務問題，不是理論問題。

你那一個奇怪的相依。 每家都有一個。模型可以提示你去找它，但它不可能知道產線的授權伺服器是牆角桌子底下的一台桌機。

正確的做法——資產與平面圖資料、停機風險，以及何時該讓IT介入

在你把任何東西貼進對話框之前，三點實務提醒。

把資產清單當作敏感資訊對待。 一份完整的系統、版本、IP網段和相依關係清單，對你很有用，對想攻擊你的人則極其有用。使用帶有合約化資料處理條款的企業版而不是個人帳號；在細節無助於結果的地方做泛化處理——寫「一台防火牆」而不是具體型號和韌體版本；並把成稿的作業手冊放在有存取控制的地方。

對你實際買到的停機時間要誠實。 每一份搬遷計畫裡都含有一個假定的中斷窗口，而它通常被低估，因為沒人願意當那個說「公司可能要到週二才能正常上班」的人。把它明確寫出來，在搬遷前和業務單位達成共識，並規劃好退路。生成的作業手冊會很樂意假設一切順利。

盡早決定哪些部分你不打算自己做。 綜合佈線、機櫃安裝、線路協調、非上班時間的實體搬遷和第一天的現場支援是常見的候選項——而這正好就是BrocentIT搬遷服務的範圍，涵蓋從搬遷前規劃到搬遷後支援。我們的AI+支援與委外IT支援則分別位於搬遷本身的兩側。Brocent自2007年在北京創立以來一直在亞洲各地交付這類專案，總部位於新加坡，香港辦公室自2016年設立——一個已交付的例子是我們的香港電信與傳媒公司辦公室搬遷。同樣的「分階段加檢查點」模式，也出現在用AI生成ERP上線切換作業手冊裡。

常見問題

網路線路應該提前多久下單？

新的光纖或專線，請按六到十二週來假設，並且把它當作整個排程賴以建構的限制條件，而不是眾多任務之一。一棟已經為商業租戶做好接取準備的辦公大樓，會快過一個需要改造管道間的工業改建空間。在裝修方案定案之前就下單，以書面形式確認交付日期，並為頭幾週準備臨時退路，例如多卡聚合的5G線路。這是搬遷日期延期最常見的原因。

一個60人的辦公室，現實的停機窗口是多長？

如果準備充分、新場地的網路已經提前測通，那麼週五晚上到週日晚上的窗口、週一早上全員正常上班，是可以做到的——因為連線、佈線和無線在幾天前就已驗證完畢，週末只剩實體搬遷。如果線路是在週六才第一次測試，那你做的不是兩天搬遷，而是在祈禱。凡是涉及地端遺留系統的，通常需要為那個系統單獨安排更長的窗口。

AI知道在地大樓或業主的要求嗎？

不知道，這是最清晰的一條邊界。貨梯預約規則、允許作業時間、對搬家公司保險的要求、非上班時間進入流程，都是逐棟大樓不同的，而且沒有發布在任何模型見過的地方。第一週就把大樓管理手冊和物業經理的聯絡方式拿到手，對著作業手冊草稿逐條讀一遍。可以預期至少會有三項任務因此調整。

應該先搬什麼？

從下單順序講，凡是有交付週期的排在最前——線路、硬體、授權移轉。從實體順序講，網路基礎設施先搬並且先驗證通過，再動終端設備；把60台工作站搬進一個連不上網的空間毫無意義。工作站分兩批。沒有回復路徑的遺留系統，應當作為獨立專案提前單獨處理。

搬遷週末的「繼續或中止」由誰拍板？

一個指名到人的負責人，在週末之前以書面形式確定，並設定明確的檢查點和判定標準——通常是在網路驗證通過之後、舊場地終端設備被拆除之前。最常見的失敗是計畫裡根本沒有明確的不可逆點，於是週六下午四點出問題時，發生的是一場集體討論而不是一個決定。把什麼條件會觸發回復、以及回復具體要做什麼，都寫下來。

有了好的作業手冊，還需要專案經理嗎？

如果是三十人以下、且沒有地端基礎設施的搬遷，一位能幹的營運負責人拿著一份好手冊，通常可以搞定。超過這個規模，或者有機房、有遺留系統、或者兩個據點要並行運行，那麼問題就出在週末當天的協調負荷上，而不是計畫本身。作業手冊是你交給專案經理的東西，不是用來取代他的東西。

從哪裡開始

在生成任何東西之前，先做搬遷前稽核。走一遍現在的機房，把機櫃拍下來，匯出資產帳冊，把每一個沒人願意碰的系統都寫下來。這一個小時不起眼的工作，決定了你生成出來的作業手冊是專屬於你公司的，還是一份寫得不錯的範本。如果從中冒出來的問題是關於交付週期、相依關係和週末誰負責，那恰恰是在日期定下來之前值得聊的那場對話：聯絡我們。