用Claude產生駐場工程師交接報告

一句話結論：Claude 能把駐場工程師那份潦草、縮寫、四分鐘內寫完的交接草稿，變成一份格式一致、帶未結事項、升級項和待觀察項的交接報告，用時不到一分鐘。它看不見這個班次。報告裡的一切都來自工程師真正寫下來的東西——這也是為什麼，格式比模型更重要。

週一 08:15，接班工程師刷卡進入客戶位於觀塘的辦公室。他收到的交接，是週五 18:52 發出的一則 Teams 訊息：「一切正常。三樓印表機還是有點毛病，採購單已提。財務的筆電換好了。週末愉快。」

到 09:30，他已經知道了那則訊息裡沒有的三件事。三樓印表機根本不是印表機故障，而是一個間歇性的交換器連接埠，兩週前就有人診斷過。財務那次換機，把舊設備未加密地留在了抽屜裡。而所謂「一切正常」，是因為站點的監控代理程式從週四下午起就不再回報了——此後沒有人再提過這件事。

這些都不是失職。週五那位工程師是在 18:52 邊收拾邊憑記憶寫下那則訊息的，沒有範本，並且篤定：如果真有要緊事，讀的人會來問。那三件事，每一件都有人知道。但沒有一件，被寫在了同事找得到的地方。

這就是專職駐場支援的日常：一兩名工程師常駐客戶現場，輪班，有時和替班或遠端同事交接。知識是真實的，人也是稱職的。缺的是每天那二十分鐘——那二十分鐘沒有人有，而它本可以把「發生了什麼」變成「下一個人讀得懂的東西」。

為什麼下一位工程師上班時總是有點兩眼一抹黑

交接是一件沒有工時、沒有排程的工作，而且發生在一天裡最糟糕的時刻。它落在班次結束時，工程師已經累了、想走了、心理上也已經把這一天關掉了。至於它的品質標準，只存在於某個人的腦子裡。

它也沒有天然的格式。工單有欄位。變更申請有範本。而班次交接只是一個訊息框，所以裡面裝什麼，完全取決於是誰在寫、以及他這一天過得怎麼樣。同一位工程師，在一個清閒班次後會寫出詳盡的交接，在一個慘烈班次後只寫三行——而這恰恰跟下一個人的需要正好相反。

接著是紀錄問題。工單系統記錄的是被開成工單的工作。而駐場工作裡有相當一部分不是：在走廊上攔住工程師的財務長、順手重新插好的那條線、「機房那台 UPS 開始喀噠響了」這個觀察。這些恰恰是交接應該承載的內容，而它們在別處並不存在。

而且這種失效會悄悄累積。一件沒有被寫下來的事不會消失；它只是不再屬於任何人。三樓印表機每隔幾週就會被一位新工程師重新發現一次，每個人都花四十分鐘得出同一個結論——因為那個結論從來沒有被記在下一個人會讀的地方。

Claude 到底能從工程師的原始筆記裡整理出什麼

先把邊界說清楚：Claude 只讀它拿到的東西。它看不見現場、看不見工單、看不見這個班次。如果工程師沒寫下來，報告裡就沒有，再怎麼調提示詞也變不出來。模型做的事，是把藉口拿掉——工程師不再需要在 18:52 組織出一份條理清晰的文件，只需要把發生過的事倒出來。

這筆交易是划算的，而它帶來兩樣輸出。

用不一致的輸入，產出一致的格式

給它四分鐘的潦草筆記——「換了財務筆電，舊的在抽屜裡要抹除，三樓印表機又來了感覺是連接埠不是印表機，MD 問 VPN 速度，機房 UPS 有異音」——再加上一份固定範本，Claude 每次都會回傳同樣結構的文件：這個班做了什麼、什麼還開著、歸誰、升級了什麼、需要盯什麼、下一班第一件該查什麼。

一致性本身就是產品。同樣五個小標題的報告，一個即將上班的人九十秒就能掃完。一則自由文本訊息做不到，因為讀的人必須先搞清楚它的結構才能開始讀——而在 08:15，他們大多懶得費這個勁。

把那件已經悄悄跨了五個班次的事翻出來

第二樣輸出，只有在你把前幾份交接連同今天的筆記一起給它時才成立。直接問它：這幾份裡，有哪些未結事項出現了超過兩次；有哪些只被提過一次，之後既沒解決也沒關閉。

這個問題，靠翻一個聊天頻道幾乎無法回答；而一旦報告結構化了，它就變得輕而易舉。它抓的正是代價最高的那種失效——那件所有人都以為有人在管的反覆出現的事，實際上已經被默默繼承了五次。

Claude 的 Projects 功能在這裡比較合適，因為它可以存放你的範本和固定指令，讓每個班次都產出同樣的形狀，而不必每次重貼。可用功能因方案而異、也會變化，所以請查閱你所用方案的當前文件。

一套可落地的流程：從下班筆記到一份下一位工程師信得過的報告

1. 範本要和工程師一起定，而不是替他們定。五到六個小標題，不能再多：本班完成了什麼、未結事項及負責人、升級項、待觀察清單、下一班第一件該查什麼。如果寫筆記的人沒參與設計，第二週之後他們就不會再用它。

2. 讓原始紀錄的成本盡可能低。工程師的任務是「倒」，不是「寫」。碎片式要點、縮寫、不用標點、四分鐘。任何讓人覺得像在寫報告的東西，都會在最要緊的那個班次被跳過。

3. 在提示詞裡帶上前兩份交接。正是這一步，把一次排版練習變成有用的東西，因為這是「反覆出現項檢查」唯一能成立的方式。把它們放在一個 Project 裡，或者每次貼進去。

4. 任何東西進去之前，先按規則清洗。不寫使用者姓名——用角色或部門代替。不寫憑證、不寫內部主機名或 IP 位址、不寫偶然聽到的客戶機密業務內容。一條固定的前處理規則能挺過一個糟糕的週五；「打算小心一點」挺不過去。

5. 報告和反覆出現項檢查，要作為兩份獨立輸出來要。報告給下一位工程師。反覆出現項清單每週給維運主管。混在一起就等於把第二份埋掉——而那恰恰是你的主管真正需要的那一半。

6. 發出之前，讓工程師本人讀一遍。三十秒。模型偶爾會把一個含糊的片段抹平成一句自信但微妙地錯了的陳述，而只有當時在場的人能抓到它。這一步不是選配；跳過它，正是一套交接流程在一次事故裡失去公信力的方式。

7. 任何出現三次的事項，一律升級。把它做成規則，而不是判斷題。一件熬過三次交接的事已經不再是一個任務了；它是一個沒有歸屬的問題，需要的是一張工單、一份變更申請，或者一次和客戶的對話——而不是第四次被提起。

8. 頭一個季度，每月複盤一次範本。從來沒被填過的小標題，刪掉。工程師老是寫錯位置的東西，給它一個自己的小標題。三個月之後它會穩定下來，不再需要照看。

AI 結構化的交接 vs 一封自由文本郵件 vs 工單系統裡的正式交接

基於原始筆記、由 AI 結構化的交接。無論這個班次過得怎麼樣，它都保持一致；便宜到可以每天做；而且是三者中唯一能跨週發現反覆出現項的。它的品質上限就是工程師寫了什麼，它不增加任何查核，產出的是文件而不是一份可追責的紀錄。正確用法：每日可讀摘要，由作者本人過目後發出。
一封自由文本郵件或聊天訊息。快、零設定，並且能承載工程師用一句話說得出、卻填不進欄位裡的那點分寸。它的品質精確地跟著作者的精力走，實際上無法檢索，而且對不在那個頻道裡的人是看不見的。正確用法：作為結構化報告的補充，承載那些塞不進格式的判斷。
工單系統裡的正式交接。可稽核、與實際工作項關聯、如果你願意還能對客戶可見，而且是唯一能在工程師離職後依然留存的版本。它同時也更慢、只涵蓋被開成工單的部分，並且在時間壓力下往往被草草填過。正確用法：作為紀錄來源，尤其是涉及合約或計費的任何事項。

這三者是層次，不是備選項。工單持有可追責的紀錄，結構化報告讓班次變得可讀，而一段簡短的人話承載範本裝不下的東西。三樣都跑的站點，在班次之間幾乎不掉東西。

它補不了哪些窟窿

一個少報的工程師，仍然會少報。如果筆記漏掉了 UPS 異音，報告也會漏掉，只是漏得更整齊。把不完整的輸入排得更好看，產出的是「看起來很周全的不完整」——這可以說比一則明顯單薄的訊息更糟，因為它讀起來像是詳盡的。

口頭交接根本不留痕。兩位工程師在機房裡重疊的那十分鐘，傳遞的資訊會超過任何文件——而這些明天一樣都不會存在。現實的解法不是禁止這場對話，而是事後在筆記裡加一行：剛才談了什麼。

產生出來的文件裡沒有追責鏈條。一份寫著「某事項未結」的報告，跟一張有負責人、有到期日的工單，不是一回事。如果交接變成了未結工作的棲身之所，工作就會遺失，因為裡面的任何東西都沒法被追。報告指向工單；它不取代工單。

工程師之間的一致性是管理問題。同一站點的兩位工程師，無論用什麼範本，報告的深度都會不同，因為其中一位注意到了 UPS，另一位沒有。這個差距靠督導、靠現場走查、靠一個「什麼算值得一提」的共同定義來收窄——而不是靠一條更好的提示詞。

把這件事做對——班次筆記裡的客戶資料、工程師之間的一致性，以及什麼時候該讓 IT 介入

班次筆記比它看起來敏感得多。它會累積主機名、共享路徑、哪些系統很脆弱、誰有本機管理員權限、偶爾還有一條本就不該被敲進去的密碼，以及在客戶樓層聽到的業務細節。請把這個檔案當作網路拓撲圖來對待——而如果工程師是嵌入在客戶現場的，請記住這些筆記描述的是別人的環境，並且受你們合約中關於其資料的條款約束。

工具這件事要和客戶一起定，而不是繞開他們定。對一位嵌入式駐場工程師而言，「AI 助理是否可以處理關於客戶環境的筆記」，既是你的決定，也同樣是客戶的決定。早提，它是一段話的對話；晚提，它是一個嚴重的問題。把它寫進服務文件裡。

按規則清洗，並且讓規則夠短。用角色代替姓名、不寫憑證、不寫主機名、不寫偶然聽到的業務內容。四條工程師在 18:52 還記得住的規則，勝過一份沒人讀的政策。

在公司層級定一條規則：哪些工具可以接收營運資料。資料保留與訓練相關條款因工具、因方案而異，而且會變，所以請查閱當前文件，並慎重地做一次決定，而不是留給當班的那個人。

判斷助理在這樣一套日常維運流程裡究竟哪裡真能幫上忙，並寫出讓它可沿用的範本、提示詞與清洗規則，是 AI+ 支援的工作。而它底下的東西——一位常駐現場的專職工程師、被覆蓋的班次、督導，以及一套明確的交接標準——屬於全職駐場 IT 支援，由持有這些工單的同一個 IT 支援團隊做後盾。如果你還要結構化其他維運文本，我們關於從會議紀錄中擷取待辦事項和把工單積壓變成派工計畫的兩篇，涵蓋的是相鄰的問題。