AI協作

前言：沒有人準備「它不能用」的那一刻 我們花很多時間討論 AI 能做什麼、怎麼用得更好、哪個模型比較強。 幾乎沒有人準備一件事：它突然不能用的時候，你怎麼辦。 不是「回答得不好」，是「完全叫不動」。而且是在你最需要它的那一刻。 這篇文章記錄一次真實的狀況：一場需要即時互動的活動，開場前 48 分鐘，背後的模型服務回傳配額用盡。從發現到恢復共約 30 分鐘。我把整個排錯過程完整寫下來，包括我一開始判斷錯的那一段。 補一句背景：這次排錯實際動手的是我的 agent，我從頭到尾在旁邊看著。下文的「我」包含這段協作——包括判斷錯的那一步，我當下也跟著信了。 一、症狀：兩個看起來無關的異常 事情不是從錯誤訊息開始的，是從「怪怪的」開始的。 我在例行檢查日誌時看到兩件事： 第一件，錯誤層級的訊息： ERROR pool error in dispatch_batch: pool exhausted INFO pool full, suspending oldest idle session 連線池滿了，系統正在不斷把舊的連線踢掉換新的。 第二件，回應時間異常： 使用者 A 387,289 ms = 6 分 27 秒 使用者 B 299,965 ms = 5 分 00 秒 使用者 C 270,801 ms = 4 分 31 秒 正常應該是 17～30 秒。現在要 4 到 6 分鐘。 二、第一個判斷：錯的 我的第一反應是：連線池滿了，所以大家在排隊，所以慢。 這個推理完全通順。池子有上限、上限到了、新的請求要等舊的釋放、於是每個人的等待時間拉長。 我甚至已經開始查連線池的設定，想看看上限能不能調大。 ...

前言：能寫程式碼，不等於能交付 用 AI 寫一段程式碼，現在沒什麼難的。難的是用 AI 交付一件有人在等、有期限、出錯會被看見的東西。 這兩件事的差別，在第三週才會顯現。 前兩週你會覺得一切順利：AI 產出快、你改得動、進度看起來很好。到了第三週，你開始發現有些檔案不知道是哪個版本、有些決定不記得為什麼那樣定、有兩條線各自改了同一份文件而你不知道哪份是對的。再過一週，你花在「搞清楚現在到底是什麼狀態」的時間，超過你花在推進的時間。 我最近用 36 天交付了一件這樣的東西——一場實作型工作坊，包含課程設計、環境建置、教材、簡報、示範影片，以及現場帶場。全程用 AI 協作，最後 162 次版本提交、38 條平行工作線、54 份交接文件。 它沒有在第三週崩解。這篇文章拆解為什麼。 一、五個階段：交付鏈的骨架 先講骨架。任何有交期的交付，都會走過這五個階段——差別只在你有沒有把它們分開。 Phase 1 · 設計（Design） 這階段 AI 的職能是：選項生成、矛盾偵測、規格收斂。 不是「幫你想」，是「陪你想」。差別在於：AI 提出選項並指出它們之間的矛盾，決定仍然是你做的。 實務上最有價值的一件事，是 AI 會發現你自己看不到的衝突。當你說「這一段要壓在 20 分鐘」，同時又說「這三件事都要講清楚」，它會把這個矛盾攤在你面前，而不是默默把三件事都寫進去然後產出一份 35 分鐘的稿子。 這階段我改了四次整體結構，最後一次是把整套教學主軸推翻重來。每一次改版都留下一份定案紀錄，包含「為什麼廢掉上一版」。 這件事在第五週救了我一次——當我想把某個舊設計改回來時，那份紀錄告訴我當初為什麼放棄它。 Phase 2 · 建置（Build） 這階段 AI 的職能是：多線平行執行。 這是 AI 協作跟傳統工作最不一樣的地方。我同時推進四條線：教材、簡報、環境、影片。四條線各自有自己的工作目錄、自己的交接檔，互不干擾。 平行的前提是隔離。 沒有隔離的平行不是平行，是混亂——兩條線改到同一份檔案，你要花的時間比循序做還多。 這階段還有一個關鍵決定：有三種技術路線可以選時，不要用推理選，用實測選。 我在 agent 的設定架構上卡了很久，三條路各有理由。最後的做法是三條都實際搭一次最小可行版本，跑跑看，然後選那條真的跑得動的。花了半天，省下後面兩週的返工。 Phase 3 · 演練（Rehearse） 這階段 AI 的職能是：缺口盤點與時間帳記錄。 這是最容易被跳過、也最不該跳過的階段。 我做了四輪演練：先是全程走查（紙上），然後是分線試跑，然後是錄影下來用學員視角看一遍，最後是真人完整走一遍。 四輪的價值完全不同。前三輪抓到的是「流程有沒有斷」，第四輪抓到的是「人會不會照你想的那樣做」。 最刺痛的一次發現是：機器複驗過、標記全過的項目，真人一跑就翻案了七項。 因為機器會照著你寫的路徑走，人不會。人會在你沒想到的地方停下來、會用你沒預期的方式理解一句話、會在應該往下的時候往回捲。 從那次之後我的判準改了：機器驗過的只能算「沒有明顯壞掉」，不能算「可以了」。 Phase 4 · 修補（Remediate） 這階段 AI 的職能是：根因定位。 ...

從指令到協作：重塑開發典範的 2025 年 AI 協作四大轉折點 前言：你的 AI 副駕，已從聊天室駛入你的專案核心 還記得 2023 年，我們在 IDE 和 ChatGPT 視窗間瘋狂複製貼上的日子嗎？那時的 AI 像個博學但健忘的實習生，雖然能給出精彩的程式碼片段，卻無法真正理解我們專案的全貌。我們像個循循善誘的導師，不厭其煩地提供上下文，只為求得一段可用的程式碼。 快轉到 2025 年，場景已截然不同。AI 不再僅僅是個「對話框裡的聰明腦袋」，它已經進化成一個深度整合在我們工作流程中的「協作夥伴」。它能閱讀整個專案、串接外部服務、甚至能化身為不同領域的專家團隊，與我們共同完成複雜的任務。 這一年，我們見證了 AI 協作從「點狀問答」到「立體協作網絡」的驚人躍進。這是一場從根本上改變我們工作方式的典範轉移。本文將以我個人的實戰經驗，歸納出推動這場革命的四個關鍵轉折點，並探討在這波浪潮中，我們人類的核心價值將如何重新定義。 AI 協作的演進：從點、線到面 在深入探討四大轉折點之前，讓我們先建立一個思維框架：「點、線、面」的演進。 點 (Point): 早期的 AI 對話是「一次性」的。你問一個問題，它給一個答案。每個互動都是一個孤立的「點」，缺乏連貫性。 線 (Line): 隨著記憶功能的增強，AI 能記住對話的上下文，讓互動得以延伸成一條「線」。我們可以圍繞一個主題進行深入探討，而不會輕易失焦。 面 (Plane): 2025 年的突破，則是將多條專家「線」整合起來，形成一個多維度的協作「面」。我們不再是與單一 AI 互動，而是指揮一個由多個 AI 專家組成的團隊。 這個「點→線→面」的框架，將貫穿我們接下來要探討的四大轉折。 轉折點一：專案級上下文感知 (Claude Code) —— AI 終於學會了閱讀 第一個轉折，是 AI 從「失憶金魚」進化為「專案圖書館員」。 年初，Anthropic 推出的 VS Code 擴充套件 Claude Code，徹底改變了遊戲規則。它最關鍵的突破，在於賦予 AI 檢視整個專案資料夾 的能力。 這意味著，AI 不再需要我們手動餵養程式碼片段。它能像一位新加入的團隊成員一樣，自己去閱讀專案結構、理解程式碼之間的依賴關係、甚至參考過去的工作日誌（Work Log）。每一次的協作成果都被記錄下來，成為未來任務的養分。當你需要修改一個與三個月前某個功能相關的模組時，AI 不再是一臉茫然，而是能迅速調閱相關文件與程式碼，提供精準的建議。 ...