與 AI 知識庫共事一週：服務供應商的專案經理工作如何改變

Monday：與 Visscher Logistiek 的啟動會議

九點整，Sanne 加入本週第一通電話。電話另一端是 Visscher Logistiek 的兩位同仁，這是一家位於 Groningen 的中型運輸公司。他們想要現代化其路線規劃，而 Buro Noord 將協助他們完成這件事。

她像往常一樣開始會議——逐項確認議程、對齊期待——但有一點不同。在螢幕角落，一個小圖示正在閃爍：錄音已經開始。自上個月起，Buro Noord 開始為每個專案使用 AI 知識庫。每個專案都有自己的環境，用來儲存所有對話、筆記與文件。AI 是跟著專案一起學習，而不是跟著整家公司一起學習。

會議持續了 53 分鐘。Sanne 匆忙在紙上寫了兩則筆記，但她知道：其餘內容都已被捕捉下來。會議結束十分鐘後，她收到一則通知。知識庫已經處理完錄音。摘要已經準備好，發言者也已自動辨識，決策點被標註出來，並附上三個建議的追問問題：

• 「哪些外部單位依賴新的路線規劃？」
• 「一年中是否有規劃壓力特別高的尖峰期間？」
• 「Visscher 由誰對供應商選擇做最終決定？」

她把這些問題轉寄給聯絡窗口。一小時內，對方回覆了。Sanne 將答案貼進知識庫。完成。

這類系統現在由 Symphoria.io 等公司提供，重點服務具有重複性客戶專案的服務供應商。其理念是：不是為整家公司建立一個大型知識庫，而是為每個客戶或專案建立一個獨立、隔離的環境。這讓所有內容保持分離、可搜尋，並且對真正使用它的人來說可用。

Tuesday：Iwan 有個問題

Iwan 在 Buro Noord 擔任初級顧問已有六個月。他正在為另一位客戶的專案工作，但卡在一個關於 API 整合的技術問題上。他知道 Sanne 去年曾為一家物流公司做過類似的事情。

過去，他可能會發一則 Slack 訊息，或在咖啡機旁問 Sanne。現在，他把問題輸入舊專案知識庫的搜尋列。三秒內，他得到一個答案：三個月前某場會議的一段摘錄，包含時間戳與逐字稿。當時他們選擇的供應商、選擇原因，以及他們避開的陷阱。

Iwan 在 Slack 傳了一個讚給 Sanne。她什麼都不必做。

這或許是最大的轉變：原本通常留在人們腦中、收件匣裡，或被遺忘在筆記中的知識，現在可以被搜尋。不是因為有人勤奮地記錄一切，而是因為文件化會自動發生。

Wednesday：狀態更新代理程式

每週三早上，Sanne 都會寄一封更新給客戶。簡短、具體、沒有意外。撰寫這封信通常需要她 45 分鐘到一小時。她必須回顧本週、檢查決策點、組織語句、重寫。

今天，她嘗試了不同做法。她打開 Visscher Logistiek 的知識庫，啟用「狀態更新代理程式」。它可以存取過去一週的所有對話、文件與筆記。她給它一項指令：

「為客戶撰寫一份每週更新。具體、商務化，不要使用行銷語言。最多 200 字。說明討論了什麼、決定了什麼，以及下一步是什麼。」

十秒後，一封電子郵件草稿出現了。Sanne 通讀一遍。有兩句話稍微太含糊。她加以調整。其餘內容都正確。她按下傳送。

總投入時間：兩分鐘。

這不是魔法。代理程式只是能存取 Sanne 原本會查閱的相同資訊——會議摘要、決策點、待辦事項——但它不必從零開始搜尋、篩選或組織語句。它取用已經存在的脈絡，並將其包裝成可讀的形式。

Thursday：隱私問題

兩點半，Visscher 的聯絡窗口打來電話。他聽起來有些不自在。

「Sanne，我看到你們會錄下我們的會議。這件事本身沒問題，但我想知道：誰可以存取這些錄音？你們會保存多久？」

Sanne 早就料到會有這個問題。在導入知識庫時，Buro Noord 已經刻意思考過同意、存取與保存期限。她解釋：

• 每段錄音都只會在所有參與者明確同意後才開始。
• 只有屬於該專案的人員可以存取知識庫。
• 音訊會在三個月後自動刪除；摘要與逐字稿則會保留可用。
• 知識庫運行於歐洲伺服器，並在靜態儲存與傳輸過程中加密。

客戶放心了。Sanne 也寄給他一份簡短的書面確認。

這類問題出現得越來越頻繁。而且這是應該的。每個專案的 AI 知識庫能做很多事，但前提是基礎必須到位：清楚約定誰可以看什麼、資料保存多久，以及專案結束時會發生什麼。這不是技術問題，而是組織問題。而且必須事先安排好，不能事後補救。

Friday：回顧會議

週五下午四點。Sanne 和三位同事坐在會議室裡。每兩週，他們都會針對知識庫的使用情況進行一次簡短回顧。

他們檢視做得好的地方：

• 花在狀態更新與摘要上的時間減少。
• 同事提出問題時能更快得到答案。
• 關於「那個東西在哪裡」的臨時 Slack 訊息變少。

以及可以改進的地方：

• 有些代理程式給出的答案稍微太籠統；缺少脈絡。
• 不是每個人都習慣修正或引導代理程式。
• 專案結束時知識庫該如何處理，仍然沒有明確流程。

Sanne 記下這些重點。下週，她會和負責推動導入的內部工作小組討論。

會議結束時，她快速算了一下。這一週她：

• 在撰寫狀態更新上省下 45 分鐘。
• 因為 Iwan 自己找到答案，省下 30 分鐘。
• 因為不必撰寫會議紀錄，省下 90 分鐘。
• 因為不必搜尋先前對話中的資訊，省下 2 小時。

總計：約六小時。

這不是完整的一個工作日，但已足以帶來顯著差異。這六小時讓她能投入真正需要她注意的事情：與客戶的一場困難對話、一項設計選擇、一份確實需要客製化處理的提案。

這對其他服務供應商意味著什麼

Sanne 的一週並不例外。這也不是未來情境。這件事正在顧問公司、諮詢公司、開發團隊，以及其他處理重複性客戶專案的服務供應商中發生。

這種做法與過去「捕捉知識」的嘗試有何不同：

• 它不需要紀律。因為對話會被自動處理，知識庫會自行填充。
• 它能立即提供價值。不是三個月後，而是同一週內。
• 它能按專案擴展。不是為整家公司建立一個龐大混亂的知識庫，而是為每位客戶建立小型、聚焦的環境。

這不代表它會自己發生。仍有三件事需要注意：

1. 同意與溝通

每位客戶都必須知道對話會被錄音、資料會保留多久，以及誰可以存取。這不是法律上的形式，而是信任問題。沒有妥善處理這件事的組織，會失去客戶。

2. 引導代理程式

狀態更新或摘要的第一版很少是完美的。團隊需要學會如何引導、修正並精煉代理程式。這需要一種不同於「AI 會處理」的心態。

3. 清理與封存

專案會結束。客戶會離開。知識庫接著需要被關閉、封存或刪除。沒有安排這件事的組織，一年後會得到一堆漂浮的環境，混亂到沒有人再敢查看。

回到 Monday

週一早上九點。Sanne 開始另一個新的一週。她的行事曆上有一場啟動會議，是另一個專案。她打開知識庫，檢查錄音設定是否正確，然後開始會議。

到了現在，這已經像是日常。並不令人興奮，也不特別。只是：事情就是這樣運作。

而這或許正是一種新工作方式真正落地的最佳跡象。不是當它令人印象深刻的時候，而是當它變得理所當然的時候。