AirOps 如何追著摩擦點，用 Claude 打造 AI 產品（第 2/2 段）

🧑‍🏫 這一段是 AirOps（做 AI 內容行銷工具的公司）講他們怎麼把 Claude 做成真正能用的產品。前半段示範怎麼讓 AI 自動跑流程、又保留人工把關；後半段講他們踩過的坑，以及改善後省了多少時間和用量。如果你常用 AI 產出內容、又擔心品質不穩，這段很有參考價值。

• 13:24 Playbook 是一種類似 skill 的自然語言建構器：可以用 slash command 定義輸入、輸出，以及內容行銷人員常用的各種工具
  ↳ Playbook 是 AirOps 裡用白話寫成的做事流程，概念像 skill（教 AI 完成某件事的說明書）。打「/」叫出指令（slash command），就能設定要給什麼、產出什麼、用哪些工具。
• 13:24 Playbook 的工具可以加入任何 MCP，所以平常在用的外部 connector 都能接進來使用
  ↳ MCP 是讓 AI 接上外部服務的共通規格，connector 就是已經接好的外部服務，例如雲端硬碟或數據分析工具。也就是說，你原本在用的服務，都能變成 playbook 裡的工具。
• 13:56 可以設定觸發條件（trigger），依排程或 webhook 執行，讓 playbook／agent 變成一直在線、自動執行特定動作
  ↳ trigger 是自動開跑的條件；webhook 是別的系統發生事情時自動發過來的通知。設好之後，agent（能自己規劃步驟、使用工具做事的 AI）時間一到或事情一發生，就會自己開始跑。
• 13:56 Monitor 功能是和 Parallel 合作：輸入一個查詢，等於幫你「盯著網路」，特定事情一發生就觸發 playbook
  ↳ Monitor 是監測功能，背後的網路搜尋由合作夥伴 Parallel 提供。你寫下想追蹤什麼，例如競爭對手有沒有發新品，它就一直幫你留意，一出現就啟動對應的 playbook。
• 14:26 AO insights：某個指標下滑時（例如上週 citation rate 掉了）就觸發 playbook，自動做研究並回報下滑原因
  ↳ AO insights 是看數據的功能。citation rate 指你的內容被引用的比例。這個數字一掉，系統就自動去查原因再回報你，不用等到有人發現才開始追。
• 14:26 人工審核：在 SOP 的每個段落（例如大綱）最後可以指派使用者，agent 跑到這一步時，背景的工具會觸發審核流程
  ↳ SOP 是標準作業流程，這裡指寫一篇文章的步驟。你可以在某個步驟結尾指定審核的人，例如大綱寫完就先停下來，等這個人看過再繼續。
• 14:57 只有被指派的人能讓 agent 繼續往下跑，其他人只能留言或給回饋；被指派的人就像守門員，目的是做好 governance
  ↳ governance 指內容管控，也就是誰有權放行。只有被指定的人能按「繼續」，其他人只能留言。就像稿子要主編簽過才能發，避免沒人把關就直接發出去。
• 15:28 Inbox：每次需要人工審核，或系統找到新機會時，都會出現在 AirOps 的 inbox 讓使用者查看
  ↳ inbox 就是收件匣。所有等你審核的東西、系統發現的新機會，都集中在這裡，不用到處去找。
• 15:28 點開 inbox 項目後，右邊是 agent 執行的過程，可以看到它的 thought traces；左邊是 playbook 定義好的各種輸出和 artifact
  ↳ 右邊是 thought traces，也就是 agent 一路思考和動作的紀錄；左邊是 artifact，就是 playbook 規定的產出，例如大綱、草稿。兩邊對照看，比較容易判斷它哪裡出錯。
• 15:59 在 inbox 可以直接編輯文件、留言，然後核准讓流程繼續
  ↳ 審核時不用另外下載或換別的工具，直接在這裡改文件、留言，改好按核准，agent 就會接著跑下一步。
• 15:59 Grid 是另一個做 governance 和人工審核的地方，用來大規模編排內容；示範中 Augustine 和講者同時在同一份文件裡協作
  ↳ Grid 是類似試算表的畫面，適合一次處理很多篇內容。示範中兩個人同時在同一份文件裡編輯，跟多人一起改 Google 文件差不多。
• 16:29 Grid 的每一列都是一個要完成的工作、各自跑一次 playbook，等於大規模執行 skill；點儲存格就能大量審核和給回饋，確保語氣符合品牌
  ↳ 每一列是一篇要做的內容，各自跑一次 playbook，等於同時跑幾十份。點一下格子就能逐篇檢查、給意見，確認語氣像自家品牌。
• 16:59 第二個摩擦點：大家對 agent 最擔心的是一致性，特別是原本習慣 workflow 的人；問題是怎麼穩定產出有品質的結果
  ↳ workflow 是每一步都寫死的固定流程，結果穩定。agent 會自己決定怎麼做，比較有彈性，但每次結果可能不同。大家最怕的就是品質忽好忽壞。
• 17:29 業務副總畫的圖被講者認為是解釋 harness engineering 最好的方式：模型（Claude、Opus 或 Sonnet）是車子的引擎
  ↳ harness 指包在模型外面的整套架構。業務副總畫了一張圖：模型（Claude 的 Opus、Sonnet 等型號）是引擎，但引擎再好，也要有車身和方向盤車子才開得動。
• 17:59 引擎外面、疊在模型之上的所有東西，對做出很棒的 agent 都非常重要
  ↳ 換句話說，agent 好不好用，不只看模型多強，你給它的工具、資料和流程設計一樣關鍵。
• 17:59 他們最專注的兩件事是工具，以及如何編排 context
  ↳ 工具就是 agent 能做的動作；context 是當下交給模型參考的所有資訊。他們最花心力的是：要給哪些工具，還有要給哪些資訊、怎麼安排順序。
• 17:59 Claude Agent SDK 和 Claude Managed Agents API 讓他們能快速迭代、用程式設定 subagent，對達到高品質輸出很關鍵
  ↳ SDK 是給工程師用的開發工具包，API 是讓程式互相呼叫的介面。subagent 是主 agent 派出去、專做一件事的小幫手。靠這兩套，他們能快速改版、用程式設定 subagent。
• 18:31 一開始只給 agent 一堆 primitive tools（流量資料、citation 資料、找競品頁面的 scraper），想讓 Claude 找出網頁哪裡有問題
  ↳ primitive tools 是最基本的工具，一個只做一件小事，例如查流量、查被引用的數據；scraper 是自動抓網頁內容的程式。一開始只給這些，讓 Claude 自己拼湊出網頁的問題。
• 19:01 最早是寫一個 skill，教它怎麼判斷頁面為什麼表現差、schema 有沒有錯、跟競品比起來如何；但 agent 會到處亂逛，很浪費 token
  ↳ 他們寫說明教它診斷頁面為什麼表現差、schema（網頁給搜尋引擎看的結構標記）有沒有錯。但它東查西查，浪費很多 token（AI 計算用量的單位，也跟費用有關）。
• 19:32 改法：把 Claude 會反覆做的工作做成 specialized tools，讓結果更 deterministic
  ↳ 解法是把 Claude 每次都會重複做的那一串步驟，直接包成一個專用工具。deterministic 的意思是同樣的輸入會得到同樣的結果，不會每次都不一樣。
• 19:32 例子：輸入一個 URL，馬上吐出這個頁面的所有資訊、跟相似頁面比較的結構化內容缺口，以及目標關鍵字和目標 prompt
  ↳ 例如丟進一個網址，工具馬上回傳這頁的資訊、跟類似頁面比少了哪些內容，還有這頁應該瞄準的關鍵字，以及使用者可能會問 AI 的問題（prompt）。
• 20:03 第二個工具是 page versus tool：把自己的頁面拿去跟同領域排名前面的頁面比較，找出差距並補上
  ↳ 第二個工具把你的頁面，拿去跟同主題排名比較前面的頁面並排比較，列出別人有、你沒有的地方，讓你知道要補什麼。
• 20:03 這是有效率取得 context 的簡單方法，有點像 code mode：直接產生程式碼，一輪就抓到需要的東西，不用來回呼叫好幾次工具
  ↳ code mode 是讓 AI 直接寫一段程式，一次把資料抓齊，而不是問一次、等回覆、再問下一次。就像先列好購物清單一次買齊，不用來回跑好幾趟。
• 20:34 Subagent 對輸出品質非常關鍵；他們建議剛開始建 agent harness 時，先讓 Claude 自己呼叫工具就好，不要一開始就塞一堆 context、弄得太複雜
  ↳ 他們的建議是：剛開始不要設計得太複雜，也不要一開頭就塞一大堆資料，先讓 Claude 自己用工具做做看。
• 21:05 等到輸出品質遇到問題，再慢慢加上 subagent
  ↳ 等發現產出品質卡住了，再針對那個問題加 subagent，一步步加上去，而不是一開始就全部設計好。
• 21:05 第一個 subagent 是 compliance check，目的是不要污染主要的 context window，因為 context 現在還是一個很大的問題
  ↳ compliance check 是合規檢查；context window 是模型一次能讀進去的資訊量上限。把檢查交給 subagent，檢查過程產生的雜訊就不會塞進主 agent 的腦袋。
• 21:36 Compliance subagent 掌握所有品牌規則，會檢查內容有沒有遵守，回傳分數和問題清單，主 agent 再根據回饋修改
  ↳ 這個 subagent 手上有所有品牌規範，例如用詞和語氣上的禁忌。它看完內容後給出分數和問題清單，主 agent 再照著清單修改，像編輯退稿時附上修改意見。
• 21:36 第二個是寫作 subagent：比起直接用一般的 Claude harness 寫，另外開一個 context 很聚焦的 subagent 專門寫內容，效果比較好
  ↳ 主 agent 一直在查資料、處理很多事，與其讓它順手寫文章，不如另外開一個只負責寫作的 subagent，寫出來的東西比較好。
• 22:08 寫作 subagent 不會被之前的研究資料或舊的 compliance check 干擾，可以只專心做一件事
  ↳ 因為寫作 subagent 看不到前面那堆研究筆記和舊的檢查結果，不會被干擾，可以專心把文章寫好。
• 22:08 第三個是 brand kit subagent；brand kit 就是一個知識庫／context 層，放著這個品牌需要知道的所有事情
  ↳ brand kit 是品牌資料庫，放著品牌語氣、產品資訊等所有該知道的事。第三個 subagent 就是專門負責從這裡找資料。
• 22:38 每次執行一開始就先跑 brand kit subagent，把相關 context 抓下來存成內部 artifact，之後主 agent 的迴圈都直接引用這個 artifact
  ↳ 每次開跑時，先讓 brand kit subagent 把這次會用到的品牌資料整理成一份內部文件，之後每個步驟都直接查這份，不用再重新找。
• 22:38 這樣就不用一直透過 MCP 工具重新抓，也避免不同 subagent 在不同時間抓到不一樣的品牌 context
  ↳ 好處有兩個：不用一直重新連線去抓資料，省時間；也不會有兩個 subagent 在不同時間抓到不同版本的品牌資料，導致內容前後矛盾。
• 23:09 最後，還可以加自訂的 subagent，這主要是內部工具，讓跟客戶合作的 solutions architect 有需要時自己開
  ↳ 另外也能加自訂的 subagent，不過主要是內部在用。solutions architect 是協助客戶導入、設計解決方案的技術人員，他們有需要時可以自己加。
• 23:09 最大的心得：就算 Opus 4.7 有一百萬的 context window，也不代表應該全部用完，還是要精簡控制讓模型注意哪些 context
  ↳ 最大的心得：Opus 4.7 一次可以讀一百萬 token，但塞越多不代表越好。資訊太雜，模型反而抓不到重點，所以要仔細挑選給它看的東西。
• 23:39 成果一：光是那個工具，token 用量就減少了 8%，因為從反覆呼叫 primitive tools，變成一次工具呼叫就拿到頁面和所有結果
  ↳ 成果一：光是換成那個專用工具，token 用量就少了 8%。因為原本要一次次呼叫小工具，現在呼叫一次就全部拿齊。
• 24:09 成果二：速度變快。以前要呼叫 20 次左右的工具才能拿到所需的 context，現在一個入口就全部拿到
  ↳ 成果二：速度更快。原本要呼叫大約 20 次工具才湊得齊資訊，現在從一個入口就全部拿到，等待時間自然縮短。
• 24:09 成果三：品質。beta 期間有 10 家企業客戶在 2 週內就開始發布內容，可以自助使用並達到有品質的輸出
  ↳ 成果三：品質。beta 是正式推出前的測試期。這段期間有 10 家企業客戶在 2 週內就開始發布內容，而且能自己操作，產出的品質也過關。
• 24:09 過去這要有人全程協助才做得到，而且上限很高
  ↳ 以前要做到這樣，得有專人從頭陪到尾才行，非常吃人力。
• 24:40 Claude 讓執行變容易，很容易讓人以為已經沒問題要解決了；但每解決一個問題，摩擦點就會移到別的地方
  ↳ Claude 讓事情變得好做，很容易讓人以為問題都解決了。但其實每解決一個卡點，新的卡點就會在別的地方冒出來。
• 25:10 持續追著摩擦點跑，才能做出 production 等級的 agent，也才能讓非技術背景的使用者用得上
  ↳ production 指正式上線、讓真實客戶每天使用的等級。要一直找出使用者卡住的地方並處理掉，才能做到這個等級，不懂技術的人也才用得上。
• 25:10 下一個要處理的摩擦點是 self-improvement 和 feedback loop；講者提到前一天有很棒的 dreaming sequences 演講
  ↳ self-improvement 是 agent 越用越進步；feedback loop 是把使用結果和回饋再拿回去改進的循環。講者也提到，前一天有一場講 dreaming sequences 的演講很精彩。
• 25:41 講者最感興趣的是：怎麼整理不同 trace 的摘要、怎麼收集最相關的記憶，還有「遺忘」其實是一個功能
  ↳ trace 是 agent 每次執行的紀錄。他想研究怎麼把大量紀錄濃縮成摘要、怎麼只留下最相關的記憶。他也認為「忘掉」不重要的東西本身就有價值。
• 25:41 最後一個是 content creation agent 的 benchmark：內容不像法律或寫程式那樣容易判斷對錯，需要品味，每個人對格式的看法也不同
  ↳ benchmark 是固定的評分基準。程式寫得對不對，跑一下就知道；但文章好不好很看品味，每個人對格式的偏好也不同，所以很難打分數。
• 26:11 目標是建立 benchmark，讓每次修改 harness（例如加 subagent 或 skill）時，都能確認輸出真的有變好，而不是只靠感覺
  ↳ 目標是做出一套評分標準，以後每次調整架構，例如多加一個 subagent 或 skill，都能用分數確認真的有變好，而不是憑感覺說「好像比較好」。

根據影片，AirOps 的 brand kit subagent 是怎麼運作的？