能描述問題，就能建工具

先把話說在前頭：這一章幾乎全是官方實證。核心的兩個案例——行銷團隊、法務團隊——都出自 Anthropic 官方那篇〈How Anthropic teams use Claude Code〉（Anthropic 各團隊怎麼用 Claude Code），講的是公司內部真實發生的事，不是想像、也不是行銷願景。這次深化另外補了三份同樣站得住腳的料：Anthropic 官方部落格分別對行銷、法務案例發的加長版報導、一份分析二十多萬名使用者的官方研究，以及法務案例後來真的做成、任何人都能安裝的公開專案。所以這一章的份量，不是「理論上你能做到」，而是「已經有人這樣做到了，而且還是不寫程式的人——現在還有資料和可安裝的成品可以佐證」。

23.1　行銷團隊：一個非工程師，建出處理數百則廣告的代理工作流

第一個案例來自 Anthropic 的 Growth Marketing（成長行銷）團隊。這是一個不寫程式的團隊，做的是廣告投放——你可以想像他們每天要面對成堆的廣告資料、要不斷產出新的廣告變體。傳統上這要嘛靠工程團隊排隊支援，要嘛純手工硬幹。他們選了第三條路：用 Claude Code 建一套代理工作流，讓 Claude 自己動手處理。

這套工作流裡，他們設計了兩個專門的子代理分工合作。你在第 10 章、第 16 章學過子代理是什麼——這裡就是它的實戰實作，而且操刀的是一位非工程師。兩個子代理大致這樣分工：

更進一步，他們還串接了一個 Figma plugin（Figma 外掛），用程式化的方式一口氣生成最多 100 個廣告變體——把「做一張、調一張、再做一張」的手工流程，變成一次產出一整批。整條流程從「分析成效」到「產出新素材」幾乎全自動，而搭起這條流水線的，是一個不寫 code 的行銷人。✅官方

這套組合換算成效率數字才真正有感——Anthropic 後來另外發過一篇份量更重的行銷案例報導，寫得更白：改版前做一則廣告平均要 30 分鐘，現在壓縮到 30 秒。更值得玩味的是「建工具」這件事本身花的時間：動手做出那個 Figma plugin 的，同樣是一位不寫程式的行銷人，而她建這個外掛前後只花了 45 分鐘到 1 小時。✅官方 很多人一聽到「自己建工具」就想像成要籌備好幾天的大工程，這個數字剛好打破這個迷思：只要流程想清楚，「建」這個動作本身常常比你猶豫要不要動手還快。

把常做的事包成一個指令：/rsa 給的啟示

這位行銷人還做了一件更聰明的事：把「產出一批廣告文案」這個天天要做的動作，包成了自己的一個斜線指令，取名 /rsa——對應 Google Ads 的 RSA（Responsive Search Ads，一種一次放好幾組標題和描述、讓系統自動排列組合去測試成效的廣告格式）。她只要打一句話，就能一次拿到 15 組標題、4 組描述，還直接輸出成一份能上傳的 CSV 檔案，不必再手動一格一格填廣告後台的表單。✅官方

官方沒有公開這個指令檔案的原始內容，但照著上面的行為描述，你完全可以自己動手做一個類似的——第 8 章教過的 Skill 格式，搭配 $ARGUMENTS 帶入參數，寫起來大概會長這樣（下面是照官方描述重建的示範，不是 Anthropic 內部那份真正的檔案）：

---
name: rsa
description: 針對指定的廣告活動，生成 Google Ads RSA 格式的標題與描述
---
針對「$ARGUMENTS」這個廣告活動，生成 15 組標題（每組上限 30 字）
與 4 組描述（每組上限 90 字），遵守我們的品牌語氣與產品正確性規則，
最後輸出成一份可直接上傳 Google Ads 的 CSV 檔案。

官方報導裡也提到，這整套行銷工作流其實還掛了幾個獨立的 Agent Skill 當背景知識——一個定義品牌語氣該怎麼寫、一個確保產品資訊正確不能亂講、一個收著 Google Ads RSA 的最佳實務規則。✅官方 這幾個 Skill 平常不會出現在對話裡，只有任務一觸發，Claude 才會自動把它們讀進來——這正是第 8 章教過的 Skill「按需載入」特性，在這裡不是紙上談兵，是真的被一個行銷人拿去用了。

Growth Marketing 不是唯一在用這套心法的行銷團隊。同一份報導接著列出其他子團隊各自的成果，做法不盡相同，但方向一致——把重複、規則明確的工作交出去，省下的時間都相當可觀：✅官方

23.2　法務團隊：用 MCP 接起四個系統，建一個「總機」幫你找對的人

第二個案例來自 Anthropic 的 Legal（法務）團隊——又是一個典型「離寫程式很遠」的部門。法務常見的痛點是：公司同事有個法律問題，但不知道該找哪位律師；問題在不同系統間（文件在這、案件在那、討論在另一邊）散落，光是「找到對的人」就很費神。

他們的解法是用 MCP（你在第 9 章學過的「讓 Claude 連外部工具」的標準介面）把四個常用系統接起來——Google Drive（文件）、JIRA（案件追蹤）、Slack（團隊溝通）、Calendar（行事曆）——然後在上面建一個他們稱為「phone-tree」（電話總機／轉接樹）的工具：同事丟進一個問題，它就根據問題內容，自動路由、轉接到對的那位律師。整個過程不寫一行 code，靠的是把現成的 MCP 連接器組起來、再把「什麼問題該轉給誰」的規則描述清楚。✅官方

不只總機：法務部門其實還有四條並行工作流

「總機」只是這個法務團隊眾多工作流之一。同一個團隊後來另外發了一篇報導，把手上其他幾條並行在跑的流程攤開來講，剛好可以當「同一套心法還能用在哪裡」的示範：✅官方

從案例到可安裝的成品：claude-for-legal

這幾條工作流沒有停在「內部案例分享」就結束。Anthropic 後來把整套法務工作流真的做成了一個公開、任何人都能安裝的專案——GitHub 上的 anthropics/claude-for-legal，Apache 2.0 授權。裡面依業務領域切成 13 個外掛（商業合約、公司治理、隱私、訴訟……），總共內建超過 70 個具名的代理人，官方在說明文件裡特別強調一句話：一切都是 markdown 和 JSON——不需要 build 步驟，也不需要寫程式背景。✅官方 這句話幾乎是把這一章的核心論點，直接寫進了一個真的能裝、能跑的產品說明裡。

安裝任何一個外掛之後，第一步不是馬上開始審合約，而是先跑一段大約 10 到 20 分鐘的暖身訪談（官方稱 cold-start interview）——讓 Claude 讀進你既有的樣本（像是公司自己的 NDA 範本、內部政策），產出一份很像第 5 章教過的 CLAUDE.md 的「業務檔案」，之後這個外掛底下所有 Skill 都會回頭讀這份檔案。官方講得很直接：跳過這一步，得到的會是一份通用、不貼身的結果。這跟第 5 章「沒有 CLAUDE.md，Claude 每次都要重新猜你的專案慣例」是同一個道理，只是換了個法務場景的名字。✅官方

整套流程實際跑起來，大致是這樣的指令順序（外掛市集與安裝畫面的細節官方仍在調整，實際操作請以當下的 repo 說明或 /plugin 指令當時的畫面為準）：

# 把 claude-for-legal 加進外掛市集
/plugin marketplace add <claude-for-legal 的 repo 路徑>

# 安裝其中一個依業務領域分的外掛
/plugin install commercial-legal@claude-for-legal

# 先跑暖身訪談，餵它讀你的樣本文件
/commercial-legal:cold-start-interview

# 之後每次要審合約，就用這個
/commercial-legal:review

23.3　核心教訓：門檻是「描述問題」，不是「會寫程式」

把這兩個案例擺在一起看，結論就浮出來了：建出這些工具的人，都不是工程師。一個是做廣告的，一個是處理法務的。他們沒有比你多會一種程式語言——他們只是把自己每天在做的事，拆解、描述、講清楚，剩下接線、寫 code、跑工具的部分，Claude Code 接手了。

這正是 Anthropic 從內部實踐得到的那句結論：能描述問題的人，就能建工具。過去「自動化」「建工具」是工程師的專利，因為中間隔著一道「你得先會寫程式」的牆。Claude Code 把這道牆拆了——現在隔在你和「一個能幫你做事的工具」之間的，不再是語法、不再是框架，而是一個更基本、人人都練得起來的能力：把問題想清楚、講明白。

官方真的量過：分析 23.5 萬人、40 萬個 session 的研究

這句結論聽起來像信念喊話，但 Anthropic 後來拿出了資料，把它從「兩個漂亮案例」墊高成「大樣本量出來的統計結果」。官方研究〈Agentic coding and persistent returns to expertise〉分析了 2025 年 10 月到 2026 年 4 月之間，大約 23.5 萬名使用者、將近 40 萬個 Claude Code session。✅官方

研究團隊用一套五級量表幫每個使用者的「熟練度」打分，依據不是他寫不寫程式，而是三件事：指令下得夠不夠精準、有沒有主動要求驗證、犯錯之後怎麼修正。更關鍵的是，這份研究刻意把「成功」拆成兩種，別搞混：

這份研究挖出幾個數字，很值得記住。使用者自己動手做的規劃決策佔了大約 70%——要做什麼、方向怎麼定，大多還是人自己拿主意；但實際執行的決策只佔大約 20%，剩下的都交給 Claude 自己判斷怎麼做。Claude 平均每個提示會執行大約 10 個動作，複雜一點的任務甚至能超過 100 個——這中間的落差，就是「描述問題」這件事真正撬動的槓桿有多大。✅官方

有意思的是，多數的進步發生在「新手→中階」這一段，之後往上爬的邊際效益反而變小——換句話說，脫離「完全生手」所需要的門檻，比你想像得低。

但這份研究對這一章的論點來說，最直接的一組數字是這個：拿「軟體從業者」跟「非軟體從業者」在跟程式相關的 session裡的有實證成功率相比——軟體從業者 30%，非軟體從業者 29%，兩個數字非常接近；研究報告自己下的結論是：「資料集裡十大職業類別，每一個都落在軟體工程師 7 個百分點以內」。✅官方 換句話說，就算把程式相關的任務也算進去，會不會寫程式帶來的差距，遠比大多數人以為的小。

研究裡舉了一個很生動的例子：一位會計，準確地告訴 Claude 一支 Python 腳本必須遵守哪些沖銷規則，還抓出它在月結時處理錯的邊界情況。這位會計贏的不是 Python 寫得多好，而是把每個規則的例外都想得一清二楚——這正是這一章從頭到尾想證明的事：贏的關鍵是任務掌握度，不是程式能力。

23.4　這個心法後來怎麼發展：從一個洞察到一款產品

前面三節講的都是「用 Claude Code 這個終端機工具」做出來的案例。但「不寫程式的人也能建工具」這個發現，後來被 Anthropic 自己往前推了一步，直接做成了一款新產品——Claude Cowork。這一節純粹是背景脈絡，讓你知道這個心法後來走到哪裡，不是 Claude Code 本身的功能，操作方式也不一樣，讀的時候留意別跟前面章節教的指令混在一起。

官方揭露的使用資料頗有意思：Cowork 超過九成的使用場景，來自非工程用途。在其中 120 萬個 session 裡，商業營運（business operations）佔 33.4%、內容創作佔 16.4%，軟體開發只佔 8.7%。✅官方 這個比例剛好跟這一章的論點對上：一旦「建工具」不再需要先學會寫程式，多數人真正拿它去做的，反而是自己專業領域裡的事，不是軟體開發。

這也不只是 Anthropic 自家員工的專利。藥廠 Novo Nordisk 有一位負責數位轉型策略的主管，本身是分子生物學博士、不是工程背景，一樣直接用自然語言，在同一套代理架構上做功能原型。同一個心法，換了一家公司、換了一個完全不同的專業領域，一樣成立。

23.5　動手前，把這幾個習慣養成

看完案例、看完資料，最後來談點務實的。不管是行銷人建的廣告工作流，還是法務團隊的總機，能穩定跑起來靠的不是運氣，而是幾個操作習慣；反過來，非工程背景的人第一次自己動手，也有幾個特別容易踩的雷。這節把它們收在一起，當作動工前的最後檢查。

非工程師最容易踩的三個操作雷

這幾個不是什麼深奧的道理，但根據業界對非工程背景使用者的觀察，特別容易被忽略：🌐社群

23.6　小結

這一章不教新指令，教一個心態。我們看了兩個 Anthropic 內部的真實案例：Growth Marketing 團隊用兩個子代理、Figma plugin、加一個自訂 /rsa 指令，讓一位非工程師把單則廣告的產出時間從 30 分鐘壓到 30 秒；Legal 團隊用 MCP 接起 Drive／JIRA／Slack／Calendar，建出一個自動轉接的法務「總機」，後來還把整套心法做成了公開可裝的 claude-for-legal 專案。兩個案例指向同一個結論——真正的門檻是「能不能把問題描述清楚」，不是「會不會寫程式」。而這句話不再只是漂亮的口號：Anthropic 官方分析 23.5 萬名使用者的研究顯示，軟體背景與非軟體背景的人，有實證成功率只差在誤差範圍內；這個洞察後來還真的長成了一款新產品 Claude Cowork。

走到這裡，整個大師篇就收尾了。你從 Context 工程一路學到成本控管，現在再加上這一章給的底氣：這些能力不是工程師的專利，而是「會描述問題的人」的放大器。把問題想清楚、講明白，剩下的交給 Claude Code——這就是你帶離這本書最該記住的一句話。

23.7　動手試試

這章沒有要你跑指令，而是要你練那個真正的核心能力：把一個問題描述清楚。挑一件你自己工作上「重複、規則明確、有點煩」的事，照下面四步試著把它變成一個能交給 Claude 的任務。

1. 1
   ✍️先寫下來

   挑一件你常做的重複工作，把流程拆成步驟

   不用想技術，先想流程。像那位行銷人一樣，把「我每次都怎麼做這件事」一步步寫出來——例如「先打開某份表格、找出符合某條件的項目、再針對它們做某件事」。寫得越具體，後面越好交辦。

2. 2
   🔌想想要接什麼

   列出這件事會碰到哪些工具或資料

   這件事要讀哪裡的資料、要把結果寫到哪裡？是某個檔案、某個試算表，還是某個線上系統？如果是 Drive／Slack／JIRA 這類，回想第 9 章——它們很可能有現成的 MCP 連接器可以接，就像法務團隊那樣。

3. 3
   💬講給 Claude 聽

   把流程當成任務，描述給 Claude Code，看它怎麼接

   把你寫好的流程，當成一個任務描述丟給 Claude Code，看它會怎麼拆、需要哪些工具、會不會建議用子代理。你不必一次就做出完整工具——重點是體會「我把問題講清楚，它就能往下接」這件事真的成立。

   ✅ 你會體會到

   卡住你的，往往不是技術，而是「這件事我自己其實也沒想清楚」。一旦你把流程描述明白，Claude Code 接手的部分會比你想像的順很多——這就是這一章、也是整個大師篇想留給你的底氣。

4. 4
   🔍驗一次再收工

   別急著滿意：找一個能驗證的證據，不是「看起來對」就好

   回想 23.3 那份研究區分的「看起來成功」和「有實證的成功」——Claude 做完之後，別只看它講得篤不篤定，找一個可以驗證的東西：一個算出來的數字對不對得起來、輸出跟你原本的期望逐項核對過一次，或請它自己列出做過哪些檢查。這一步小，卻是把「玩具 demo」變成「你敢真的拿去用」的關鍵。

   ✅ 你會體會到

   多數人第一次會卡在「我竟然說不出該怎麼驗證」——這正好回頭告訴你，上一步「把流程描述清楚」那件事，其實還能想得更細一點。這個回頭修正的過程，本身就是在練任務掌握度，不是程式能力。