用ChatGPT把摸底溝通變成HLD初稿和BOM

一句話結論：ChatGPT 能把一份東拉西扯的專案摸底通話逐字稿，變成一份結構化的高階設計（HLD）初稿和一份起始物料清單（BOM）——用一個下午，而不是一週。它產出的是一份供持證架構師去修正並承擔責任的工作草稿，不是設計，也不是報價。風險不在於它寫得差，而在於它會對「沒人真正說過的事」寫得很有底氣。

那次摸底溝通開得不錯。和客戶營運負責人聊了九十分鐘，財務總監在最後二十分鐘加入，一個大致清晰的畫面浮現出來：新辦公室三層樓、大約 180 名員工、現有網路設備已過保、傾向於繼續用微軟，以及一個十一月的硬性時間點，因為租約那時開始。

然後逐字稿在一個資料夾裡躺了十一天。

不是因為誰偷懶。開這場會的售前工程師手上還有另外兩個機會，而把九十分鐘你一句我一句的對話變成一份客戶能拿去和另一家供應商作比較的文件，確實是實打實一天的活。於是它就等著。與此同時，正在比價的客戶，先收到了別人的文件。

那十一天的空檔才是值得解決的問題，而它是一個「寫文件」的問題，不是一個「做工程」的問題。

為什麼「我們聊過」和「這寫下來了」之間的差距，會讓專案損失幾週

一次摸底溝通產生的是一種共同理解，而這種理解只存在於到場者的腦子裡。下游的一切——設備清單、報價、時程、內部核准、和競爭對手的比較——都取決於這種理解變成一份文件。

文件產出慢，原因和技術難度毫無關係。對話是無序的：第 4 分鐘討論的需求，在第 61 分鐘被改掉了。內容裡有一半根本不是需求。而最關鍵的是，那些缺口只有當你試著把它寫下來時才會顯現——在某一節需要填一個數字之前，沒人會注意到無線基地台的數量其實壓根沒被討論過。

拖延的代價是具體的。客戶對這次溝通的記憶在衰減，隨之衰減的還有「你聽懂了我」這種感覺。在競爭局面裡，第一份可信的文件會框定整個比較，之後所有人都要在那個框架下被評判。而對內，在範圍寫下來之前，什麼都沒法報價、也沒法排程。

需要的不是一位更強的架構師，而是一條從對話到「可審閱初稿」的更快路徑。

ChatGPT 到底能從一份通話逐字稿裡起草出什麼

新版 ChatGPT 處理長文件的能力不錯，而且可以直接基於逐字稿檔案工作。這裡真正要緊的那項能力並不炫目：把無結構的文字忠實地重組成一個既定的形狀，而且不會讀到第十四頁就分心。

有兩樣輸出是真有用的。

一份高階設計（HLD）初稿大綱

給它一份逐字稿和一個指定的文件結構，它會產出一具填好內容的骨架：業務背景與驅動因素、對方描述的現況、按領域歸類的需求、已陳述的限制、假設，以及——最有價值的——被明確排除在範圍之外的東西。

「範圍外」和「假設」這兩節，正是這套做法真正賺回成本的地方。人寫的初稿習慣性地會少記這兩項，因為在當下大家都記得談成了什麼。六週之後，在一次變更申請的對話裡，「我們從來沒說過要做監視器」這句話，白紙黑字地寫著是很值錢的。

要求它清楚區分「通話中被明說的」和「它推斷出來的」。一份指令得當的初稿會標註推斷；一份沒有指引的初稿會把兩者揉進自信的行文裡，而這正是這類輸出最危險的一個特性。

一份起始的設備與軟體物料清單（BOM）

從同一份逐字稿裡，它能把所有暗示著採購的東西抽出來——交換器、基地台、防火牆、授權、佈線，還有某人提過一次的那台 UPS——整理成一份結構化清單：說了數量的寫上數量，沒說的明確寫「未指定」。

這是一張核對清單，不是一份 BOM。它沒有可以下單的料號、沒有做相容性驗證、沒有價格，也不知道一個真實設計會需要、但恰好沒人提到的東西。它的價值在於它花二十分鐘而不是一個上午，而且能把遺漏盡早暴露出來：一份顯示著十一處「未指定」的清單，就是一份精確的回訪議程。

絕不要把它當作報價發給客戶。價格取決於框架協議、區域可得性和交期，這些活在供應鏈團隊那裡，不在一份逐字稿裡。

一套可落地的流程：從原始逐字稿到一份架構師可以審閱的文件

1. 在它去任何地方之前，先清洗逐字稿。去掉客戶名稱、公司名、據點地址，以及討論到的任何商務數字。這裡面大部分是一次尋找取代，換成「客戶 A」、「據點 1」。每一次都先做這一步，然後檔案才允許靠近一個通用 AI 工具。

2. 給它你自己的文件範本，而不是一個籠統的請求。把你公司 HLD 實際使用的章節標題貼進去。「起草一份 HLD」產出的是泛泛之物；「用這份逐字稿填充這十一個章節」產出的才是你的審閱人認得的東西。

3. 明確指令它把「明說的」和「推斷的」分開。類似這樣：只使用逐字稿裡的內容；某一節沒有支撐內容時，寫「通話中未討論」，而不要自行填充；任何合理但未被說出口的內容標為假設。僅這一條指令，就構成了「有用的初稿」和「一份負債」之間的大部分差別。

4. 先產生 HLD 大綱，再單獨產生 BOM。兩次窄指令的處理，好過一次要它把什麼都辦了。BOM 那一輪要明確告訴它：凡是沒有被說出口的數字，一律輸出「未指定」，絕不推斷。

5. 在給任何人看之前，先對著你自己對這場會的記憶讀一遍。你當時在場。你要查兩樣東西：細微錯誤的內容，以及那些自信地存在、卻從未被說過的內容。第二種更難發現，恰恰因為它讀起來很順。

6. 把每一處「未討論」和「未指定」變成一份編號問題清單。這是整件事裡價值最高的產物。它是回訪溝通的議程，而且客戶會把一份具體的問題清單讀作「你當時在認真聽」的證據。

7. 把初稿交給架構師時，就標明它是初稿。在合格的人通讀之前，文件上必須帶著一個可見的狀態——「AI 輔助初稿，未經審閱」。典型的翻車方式，是一份初稿溜進了某條郵件討論串，從而獲得了它從未掙得的權威。

8. 讓架構師去修正、補充，並承擔責任。他們會改東西，也會補上沒人提過的需求，因為他們知道這一類設計實際需要什麼。那部分工作才是設計。在此之前的一切，都只是帶結構的謄錄。

9. 把提示詞和範本留下來，並持續改進。第二個專案會比第一個快得多，因為可重複使用的資產是那套指令，而不是那份輸出。

AI 起草的 HLD vs 持證架構師的 HLD vs 根本沒有書面設計

AI 輔助的初稿。幾小時而不是幾天，能把假設和範圍外事項記得很全，而且能盡早暴露缺口。它不承擔任何專業責任，無法判斷這個設計是否成立，而且除非被明確指令，否則它會把推斷當作事實來呈現。正確用法：作為架構師工作的輸入，絕不作為其替代。
持證架構師的 HLD。一位有資格的人判定了這個設計能跑通、做了正確的容量估算，並且署上了自己的名字。那份責任才是真正的產品——客戶要一份設計時買的就是它，供應商在交付時扛的也是它。它消耗的是稀缺的專業時間，而這恰恰是「謄錄與結構化」那部分值得自動化的原因。
根本沒有書面設計。比任何人願意承認的都更常見：一個口頭共識、一封郵件裡的設備清單，然後一張發票。在第一次關於範圍的分歧出現之前，它都行得通；而分歧一旦出現，沒有任何文件可指，最後由更執著的那一方說了算。

對多數公司現實的組合是前者餵給後者。收益不是一份更便宜的設計，而是更快的回應、被記錄得更好的假設，以及架構師把時間花在判斷上而不是排版上。

一份初稿會在哪些地方主動誤導你

從未被提到的限制，不會出現在逐字稿裡。大樓的線槽容量、房東方的限制、客戶預設你知道的某條合規要求——錄音裡都沒有，所以初稿裡也都沒有。文件看上去是完整的，卻恰好缺了那個決定設計走向的東西。

編造出來的具體性，是這類失敗的典型形態。當你要求它產出一份專業文件時，模型會補上看似合理的細節：一個沒人討論過的型號，一個由它默默做出的假設推導出來的交換器數量。它讀起來和正確的部分一模一樣，而這正是它危險的地方。

謄錄錯誤會一路傳下去。自動謄錄誤聽技術術語和數字是家常便飯，「五十」變成「十五」會產出一個讀起來完美無缺、實則錯誤的句子。請對著錄音核對每一個數字，而不是對著逐字稿。

自信的行文會掩蓋薄弱的來源。當有人說的是「我們實在承擔不起停機」，而初稿斷言客戶「要求 99.9% 的可用性」時，它已經憑空造出了一條規格。那個數字最終會出現在 SLA 的討論裡。

它背後沒有供應商的責任擔保。一份文件的價值，等於發出它的機構願意為它背書的程度。一份未經審閱的 AI 初稿，無論看起來多好，都不構成任何人對任何事的承諾——它留在內部時這沒問題，而客戶一旦把它當作提案書，就是真問題了。

把它做對：逐字稿裡的客戶機密、文件歸屬，以及什麼時候該讓 IT 介入

預設一份摸底通話逐字稿是機密的，因為它就是。它通常包含客戶的法定名稱、據點、人數、現有基礎設施及其弱點、預算數字、內部的人事角力，還常常有一句關於「某個系統一直沒更新」的隨口之言。這對攻擊者是一份有用的文件，外洩出去則是一份難堪的文件。

清楚這份逐字稿實際進了哪個工具、適用什麼條款。個人版帳號、商業版和企業部署，在資料保存以及是否可能被用於訓練上是不同的。請確認你所用的那個具體方案的條款，並在公司層級定下一條規則：哪些工具可以接收客戶素材——這是專業服務公司裡最常見的一項失控 AI 風險，而且它是一個治理問題，不是技術問題。

預設去識別化，而不是靠臨場判斷。「上傳前先去掉客戶識別資訊」作為一條常設規則，能撐過交付期的壓力；而「小心一點」這條規則撐不過。

決定錄音存在哪裡、保留多久。通話錄音和逐字稿預設會在會議平台裡無限期堆積。如果客戶合約裡對保密資訊或素材返還有任何約定，這件事就在適用範圍內。

在文件內部標註初稿狀態。在架構師簽核之前，一份 AI 輔助初稿應當在頁面上就寫明這一點。這裡的版本管理比平時更要緊，因為整套方法產出的正是「看起來已經完成」的早期文件。

審閱人必須有資格否決它。這套做法的價值，完全取決於有一位勝任的人願意劃掉整整一節。如果審閱只是走形式，那麼起草速度買給你的，只是一條通往糟糕設計的更快的路。

決定 AI 在售前流程裡該待在哪兒、撰寫那套指令範本、以及定下「什麼可以上傳」的規則，這些是 AI+ 支援的工作。底下的工具、存取控制和資料處理，是一般的託管 IT 支援。而那些不會被自動化的部分——出具帶成本的、廠商中立的 HLD 的持證架構師，跑交付的 PMP 或 PRINCE2 專案經理，以及把一份願望清單變成帶交期的真實 BOM 的供應鏈團隊——是我們的 IT 專業服務。如果你也在用這種方式起草其他專案文件，我們寫過為 ERP 上線起草 UAT 腳本與切換手冊和簽約前審查 IT 服務合約，用的是同一套「AI 起草、專業人士擔責」的模式。

常見問題

這能取代持證架構師的簽核嗎？

不能，而且這個區別不是走形式。客戶用一份設計買到的是責任：一位有資格的人判定了這個方案在那個規模、那棟樓、那個預算下能跑通，並且他所在的機構在交付時為此背書。模型承擔不了這份責任。它取代掉的，是從通話到架構師審閱之間那幾個小時的謄錄與排版。

通話錄音和逐字稿之後會怎麼處理？

取決於你的會議平台和 AI 工具的保存設定說了什麼，而多數公司從來沒去看過。錄音留在會議平台裡，逐字稿被上傳到某個聊天工具，副本最後躺在某人的下載資料夾。請有意識地決定：錄音存在哪裡、保留多久、哪些工具可以接收它們，以及專案結束時怎麼處理——尤其是在客戶合約對保密資訊有約定的情況下。

BOM 裡包含真實價格嗎？

不應該包含，你也不該讓它去做這件事。價格取決於框架協議、區域可得性、匯率、進口關稅和交期——這些是活在供應鏈團隊那裡、並且持續變動的商務事實。一個模型產出一個看似合理的價格，產出的就是一個虛構的價格，而一個虛構數字流到客戶那裡的風險是很嚴重的。請把這份輸出當作一張已界定範圍的設備核對清單，再由採購去定價。

這和直接讓 ChatGPT「給我寫一個網路設計」有什麼不同？

完全不同，差別就在來源。要它寫一個設計，等於邀請它憑一般知識生成一套看似合理的通用架構，而這套架構和你客戶的大樓、限制、預算毫無關係。本文這套流程做的恰恰相反：它被明確禁止添加任何不在逐字稿裡的東西，並被要求把缺口標註為缺口。你是在把它當作一個作用於你自己來源素材之上的結構化工具，而不是當作一位設計者。