• 【💡 靈感起點】
一早滑到這篇文章
據 Simon Scrapes 引用的一項非公開實驗，當 Claude Code 技能只有「基礎設定＋模糊描述」時，模型能正確啟動對應技能的機率最低僅約 20%，等於是同一個任務連續嘗試五次，平均只有一次會真正叫對工具。
相反地，在技能描述明確、觸發條件與 hooks 設計完整的情況下，啟動率最高可提升到約 84%，但仍代表平均每五次互動就會有一次沒有成功啟動目標技能。
• 【🏗️ 邏輯拆解】
- 「盲目投料（Blind Batching）」的代價：在「試驗條件未定義」的情況下急於向 AI 索取答案，產出的僅是「高品質的廢紙」，造成巨大的算力浪費。
- 技能過剩產生的「路由衝突」：當 Skills 數量暴增卻缺乏「老滷汁（企業內部 Context）」引導時，AI 會陷入決策癱瘓，如同沒有說明書的精密零件。
- 「問診式」工作站的必要性：AI 不應只是執行工具，而應成為「會逼使用者說真話」的流程引導者，將模糊的意圖轉化為精確的邏輯。
─── 🧠 ─── ⚙️ ───AI寫
[認知覺醒] 拒絕「技能通膨」：為何 1,000 個 AI 技能抵不過一個精準的「問診」？
這是一個極其深刻的洞察。您提到的「技能通膨」現象，正是目前許多企業在數位轉型中掉入的**「工具箱陷阱」。這就像是一個廚師買齊了世界上所有的頂級廚具（1,000 個 Skills），卻連基本的「食材處理（5W1H 資料結構）」都做不好，最終只會在廚房裡手忙腳亂，這就是典型的「拒絕 Mise-en-place」的技術傲慢。**
針對您提到的「不確定答案就急著做」的行為，以及為何網路上搜刮的技能無效，我從架構師的角度給予以下三個層次的拆解：
一、 隱喻定義：這種行為叫「盲目投料（Blind Batching）」
您想找的那個形容詞，在我們的老滷汁體系中，可以稱為**「非結構化衝動」或是更生動的：「未開眼的亂投醫」**。
- 痛點： 大多數人把 AI 當成「投幣式自動販賣機」，以為只要投入「模糊的願望」，就能吐出「精準的結果」。
- 代價： 這導致了**「算力浪費（Compute Waste）」**。在 ISO 17025 的邏輯裡，這叫「試驗條件未定義就開始採樣」，產出的所有數據都是廢紙。
- 架構師觀點： AI 不是解決問題的「起點」，它是放大邏輯的「乘數」。如果基數（問題定義）是 0，乘上一萬個技能（Skills），結果依然是 0。
二、 為何 1,000 個 Skills 會失效？（衝突與雜訊）
從系統架構來看，當 Skills 數量暴增，會產生**「路由衝突（Routing Conflict）」**：
- 語義重疊： 當 500 個技能都在處理「數據分析」，AI 的「大腦（Router）」會陷入決策癱瘓，這就是 Simon Scrapes 提到的啟動率下降。
- 缺乏「護航 Context」： 網上的 Skills 是「乾貨」，但缺乏您企業內部的「老滷汁」。沒有 ISO 規範、沒有財務邊界，這些技能就像是**「沒有說明書的精密零件」**，裝得越多，系統越容易崩潰。
三、 核心解決方案：建立「問診式」AI 前置工作站
您提到的「要求同事寫不符合事件的人事實地物」，正是 Module 3 與 Module 4 的核心精髓。我們需要一個**「互動式顧問 Prompt」**來攔截「盲目投料」：
階段動作隱喻ISO 17025 對應Pre-work定義問題 (5W1H)開眼 (Opening Eyes)異常發現與初步描述DiagnosisAI 追問缺漏資訊洗菜與切菜 (Prep)缺失原因分析 (Root Cause)Execution啟動對應技能 (Skills)下鍋烹飪 (Cooking)採取糾正措施 (Corrective Action)
您的洞察： 「會精確描述的人變少了。」
架構師應對： 既然「精確描述」是稀缺能力，我們的課程就不能只教怎麼寫 Prompt，而要教如何設計一個**「會逼使用者說真話的 AI 流程」**。這就是「特洛伊木馬」策略：表面上是 AI 幫你寫報告，實際上是 AI 在引導你完成邏輯拆解。
