Claude 的 Cowork 功能，讓我第一次覺得 AI 真的開始進入工作流了
最近用 Claude 的 Cowork 功能，有一個感受越來越明確：它最有價值的地方，不是幫我多寫幾行 code，而是把原本很碎的工程操作，收成一個可以持續推進的工作上下文。
這件事在單一 repo 上未必那麼明顯。但只要工作一跨到多個專案，還夾著內部工具、部署腳本、專案差異和規格決策，你就會發現，真正耗神的通常不是實作本身，而是不斷重建上下文。對我來說，Cowork 第一次讓我覺得，AI 不是只會幫忙做事，而是真的開始進入工作流了。
真正麻煩的，通常不是寫 code，而是工作會先碎掉
我最近遇到一個很典型的場景：收到一個 API 大改動的需求，但不是只影響一個專案，而是會同時動到多個遊戲專案。麻煩的是，這些專案雖然相似，實際處置行為又不完全一樣。你不能在第一個專案改完之後，就直接把同一套做法套到其他專案上。
而且這種任務也不是改完 code 就結束，通常後面還要立刻部署到測試環境，確認整個流程有沒有真的跑通。
如果沒有一個好的工作方式，這種任務很快就會碎掉。你要先找到第一個要修改的專案，讀 spec、整理第一版；同時腦中還要一直分神去想，第二個專案可能會遇到什麼問題。第三個專案是不是又有別的差異？改完之後部署會不會牽動到另一套 scripts？某個 repo 到底是主專案，還是其實只是被引用的內部工具？
真正累的，通常不是寫 code，而是你還沒開始改，腦子就已經先被切成很多段了。
跨多個 repo，才是工程工作最容易失去上下文的地方
我平常遇到的工程流程之所以會碎掉，通常不是因為 code 本身難，而是因為工作被拆散在很多地方：多個 repo、一步一步的權限授權、相似專案之間的差異判斷，還有那些平常只有自己知道怎麼用的內部工具。
這裡面最痛的，還是多個 repo。因為一旦工作跨到多個專案，其他問題會一起放大。你要重新建立每個 repo 的上下文，重新處理權限，重新理解哪些地方相似、哪些地方其實不能照抄。真正消耗你的，常常不是改 code，而是不斷重新進入每一個專案。
Cowork 先做的，不是改 code，而是把散落資訊收成可執行草案
而這就是我覺得 Cowork 真正有感的地方。
它最先幫我接走的，不是直接改 code，而是先讀第一個專案，幫我把散落的資訊收成一份可執行草案。這一步很關鍵，因為很多跨專案任務一開始根本還不是一個完整任務，只是一堆需求、差異、限制、工具和猜測混在一起。Cowork 先做的，就是把這些東西整理成一個能往下推進的起點。
有了第一版草案之後，它才會開始把其他專案一個一個對上來。
它不是平面複製，而是會去看哪些地方不能照抄
而這也是我最在意的一點：它不是把第一個專案的做法平面複製出去，而是會去看哪些地方不能照抄。
這點很重要，因為多 repo 真正難的從來不是找出共通模式，而是分辨哪些差異會在哪裡出事。尤其是專案結構差異。表面上看起來是同類型專案，但真的進去看，資料夾組織、模組切分、依賴位置、腳本入口都可能不一樣。這種時候最怕的，就是把第一個專案的解法硬套到全部。
Cowork 在這裡比較像一個真的有在跟著任務走的人。它會把其他專案對上來，然後開始追那些關鍵差異。
它最像同事的瞬間，是知道什麼時候該停下來問
而我覺得它最像同事的瞬間，不是它幫我產了多少東西，而是它會在該停的地方停下來問。
尤其當它把其他專案對上來之後，它會開始碰到一些真正影響規格的差異。這時它最有價值的提問，不是那種表面的技術細節，而是：這個專案原本的行為差異，到底要不要保留？
這一句其實很重。因為很多時候，你以為自己在做工程修改，但真正卡住你的，根本不是 code 怎麼寫，而是不同遊戲專案的特色到底要不要繼續維持。哪些差異是設計的一部分，哪些只是歷史殘留？哪些應該跟著這次 API 改動一起收斂，哪些反而不能動？
Cowork 好的地方，不是它幫你亂補答案，而是它會把問題推到一個「已經接近可以執行、但還不能亂做決定」的邊界，然後回頭問你。
所以它停下來問的時候，我的感覺通常不是被打斷，反而比較像被提醒：原來我自己這裡其實還沒想清楚。
它保留的不是單一 repo 上下文，而是多個專案之間的交互工作區
另一個讓我很有感的地方，是它不只看主專案，連一些內部工具 repo 也能一起拉進來。
像我自己有一套部署用的 scripts 集合，平常其實就散在內部工具專案裡。以前這種東西雖然一直在用，但它在工作流裡通常是另一個世界。你改完主專案，腦袋還要切出去，重新進入部署工具那一套脈絡。
Cowork 比較不一樣。它會先理解你把這些資料夾一起拉進來到底是要做什麼，哪些是這次真的要改的主專案，哪些其實是支援流程的內部工具。換句話說，它保留的不是單一專案上下文，而是多個專案之間的交互工作區。
這一步很重要，因為如果角色判斷錯了，後面的規劃與執行很容易整個歪掉。
少掉的，不只是切換成本，還有大量的解釋成本
當它先理解哪些是主專案、哪些是內部工具之後，最明顯的變化不是某個單點操作變快，而是它能把這些原本分散的專案與工具，慢慢集成成一個工作流。對我來說，這才是它真正像 coworker 的地方。
而我最直接感受到的，是解釋成本少很多。
很多原本要反覆交代的背景，像是哪些是主專案、哪些是內部工具、哪些只是被引用的輔助 repo，就不用每次重講一次。這很重要，因為我可以更快進入真正要改的事，而不是一直花力氣在重建共同語境。
如果要很直白地介紹 Cowork，我會這樣說
它讓原本碎掉的工程操作，變成一個可以持續下去的工作上下文。
而且這個上下文不是只限於單一 repo。它可以跨多個專案，也能把內部工具一起納進來，理解每個 repo 的執掌不同：有些是主專案，有些其實是被其他專案引用的工具。當這些角色關係被穩定下來之後，整個跨專案修改流程就不會那麼容易碎掉。
對我來說，這才是 Cowork 真正開始有感的地方。不是因為它比較像人在講話，也不是因為它會自動做很多事，而是因為它真的開始能待在工作流裡。
配圖來源：Pexels（本文示意圖均為 Pexels 圖庫圖片，用於文章配圖示意）。
