AI 辭典

SEO 優化的是排名，GEO 優化的是「被寫進答案裡」。兩者不衝突，但要求不同：排名看的是連結、權重與點擊訊號；引用看的是這一段能不能被單獨抽出來還讀得懂。所以 GEO 的施工位置在段落層級，不在整頁層級。 可引用的段落有三個共同特徵：開頭是一句自足的定義或斷言（不依賴上下文）、帶得出具體數字、而且數字附出處與日期。反過來說，最不容易被引用的是行銷語言——「業界領先的全方位解決方案」這種句子，模型抽出來也沒辦法拿去回答任何問題。 王永鉞的 GEO 方法論分三層：語意一致化（同一個概念全站用同一個詞，不要三種說法）、權威鏈接化（每個主張連得到出處，內部有主題中心頁）、可引用化（把答案放在段落最前面）。本網站本身就是這套方法論的示範品——包含它的取捨與尚未做完的部分。

傳統 SEO 的成績單是排名與點擊，兩者都看得到。AI 能見度的成績單不在你的報表裡——使用者問完就走，你不會知道自己被提過。這是它最難的地方：不可見，但正在決定買方在接觸你之前對你的第一印象。 最常見的誤解是「排名好＝AI 會引用」。兩者的重疊正在下降：AI 引用的來源與傳統前十名的重疊率已掉到四成以下。原因是模型挑的不是「最多人連的頁」，是「最好抽取的那一段」——有明確定義句、有數字、有出處、語意乾淨的段落。 要開始量它，最低成本的做法是自己當使用者：把客戶會問的十個問題丟進 ChatGPT 與 Perplexity，記錄品牌有沒有出現、出現在第幾句、旁邊是誰。每月一次，就是一份可以比較的基線。這件事沒有工具能完全代勞，但也不需要工具才能開始。

傳統 IDE 的假設是「一個人改一個檔案」，ADE 的假設是「一群代理同時改很多分支」。這個假設差異會一路影響到介面：ADE 的主畫面通常不是編輯器，是任務列表與差異比對。 判斷一套工具是不是真的 ADE，看它的工作區單位是什麼——是分頁，還是 git worktree。用分頁的，代理們其實還在同一份工作目錄裡互相覆蓋；用 worktree 的，每個任務有自己的資料夾與分支，跑壞一個不影響其他。這是分水嶺，不是實作細節。 實務上，一個人能穩定同時審查的代理數量大約是三到五個——上限不在工具，在人審查差異的速度。所以評估 ADE 時真正該問的不是「能開幾個代理」，是「它把結果整理得多好審」。差異呈現、測試結果、以及「這個代理改了什麼、為什麼」的說明，決定你敢不敢按下合併。

程式碼助理與編碼代理的差別不在模型強弱，在「誰決定下一步」。助理等你打字，代理自己規劃步驟。這個差別使得評估標準完全不同：助理比的是補完準確率，代理比的是做完一整件事的成功率，以及做不完的時候會不會誠實停下來。 最常見的導入失敗是把代理當助理用——丟一句「幫我修這個 bug」就期待它自己搞定。實際上代理的表現跟你給的紀律成正比：明確的驗收條件、可以跑的測試、以及一份寫清楚「這個專案怎麼做事」的說明檔，三者到位時成功率差距是數倍，不是幾個百分點。 代理會不會寫程式已經不是重點，重點是你能同時管幾個。一個人能穩定指揮的代理數量，正在成為新的產能單位——而放大這個數字的不是更強的模型，是更好的隔離機制與更清楚的交付規格。

沒有 worktree，多代理平行開發就得一路 stash 來 stash 去：A 代理改到一半、B 代理要跑測試，只能先把 A 的改動暫存起來——只要順序錯一次，就會丟掉工作。有了 worktree，一個任務一個資料夾，代理各改各的分支，最後再挑要合併哪一份。 它比「複製一份倉庫」好在哪：worktree 共用同一份 .git 物件庫。十個工作區不會佔十倍磁碟，分支與提交紀錄也是同一份，不會出現「這個複製品的歷史跟主倉庫對不上」這種問題。建立一個工作區是秒級的操作，用完刪掉即可。 這也是判斷代理開發環境成不成熟的分水嶺。一套宣稱能平行跑代理的工具，如果底層不是 worktree（或等價的隔離機制），那個「平行」多半只是介面上的分頁——代理們其實還在同一個資料夾裡搶同一批檔案。

它跑在終端機裡，這個選擇比看起來重要。因為終端機是通用介面，所以 Claude Code 能被任何終端機工作台或代理開發環境接管——這也是為什麼「用哪個代理」與「用哪個環境管代理」是兩個可以分開決定的問題，不必綁在一起選。 三個擴充點各管一件事，經常被混為一談：Skills 管「該怎麼做」（一份 Markdown，寫下這個情境要照什麼紀律）、MCP 管「能碰到什麼」（把資料庫、行事曆、第三方 API 接給它）、hooks 管「什麼時候攔下來」（在指令執行前後插入檢查，例如擋掉危險的 Git 操作）。導入時只接 MCP 卻不寫 Skills，是最常見的半套做法——工具給了，紀律沒給。 它也可以在 CLI 之外使用：桌面應用程式、網頁版與 IDE 擴充套件都能跑同一套代理，差別只在介面。

它不是外掛、不是框架，也不綁特定模型——就是純文字、可版控、可修改。這個「無聊」正是它的價值：能進 Git 就能審查、能回溯、能在團隊之間傳遞，不會變成某個人電腦裡的黑盒子。 最常見的誤解是把它當提示詞範本。兩者的差別在啟用方式：提示詞要人記得貼上，Skills 由代理自己依情境判斷要不要讀。所以檔頭那句「什麼時候該用我」比內文更關鍵——寫得太模糊會該用時沒用、不該用時亂用，寫得太窄則永遠不會被觸發。 實務上的用法是把公司重複發生的流程各寫成一個技能檔：報告怎麼出、客戶回信怎麼寫、上線前要檢查哪幾項。團隊每個人的 AI 就都照同一套標準做事，而且人員異動帶不走——因為那份紀律留在倉庫裡，不在某個人的腦袋裡。這是它跟「教員工怎麼下提示詞」最根本的差別。

在 MCP 之前，每接一個工具就要為每個模型各寫一次串接，成本是「工具數 × 模型數」。MCP 把它變成「工具數 ＋ 模型數」——工具方實作一次伺服器，任何支援協定的模型都能用。這是它真正的價值，不是功能多，是整合成本的量級改變。 最常見的誤解是把 MCP 當成外掛市集。它是協定不是產品，本身不提供任何能力；能力來自你接上去的那些伺服器，而那些伺服器的品質與權限範圍要自己把關。接一個能讀寫正式資料庫的 MCP 伺服器給代理，等於把生產環境的鑰匙交出去——這件事該有審核流程，跟裝瀏覽器外掛不是同一個層級的決定。 MCP 解決的是「AI 能碰到什麼」，AI Skills 解決的是「AI 該怎麼做」。兩者互補，不是二選一——很多導入失敗是因為只接了工具，卻沒有寫下做事的紀律。

三個字母指向的概念本身是真的：內容深度、主題權威、語意結構，都是搜尋優化領域既有的討論，不需要新名詞。沒有出處的是「把它們綁成一個叫 DSS 的框架、並宣稱這是判斷 AI 引用的標準」這一層。真的東西被包進一個假的容器裡，是這類框架最難拆的地方——你去驗證它的內容，每一項都查得到；你去驗證那個容器，什麼都查不到。而要賣你服務的人，賣的正是那個容器。 查核紀錄（2026-09-19，可自行重跑）：英文查 "DSS" framework SEO "data depth" "source authority" "semantic structure"，零命中；中文查 DSS 框架 SEO 資料深度 來源權威 語意結構 AI 引用，零命中；中文查 "DSS框架" OR "DSS 框架" AI搜尋 引用 指標，零命中。唯一的 DSS 條目是維基百科的「決策支援系統（Decision Support System）」，屬資訊管理領域，與搜尋優化無關。拿一個早就被佔用的縮寫來命名新框架，本身就是這套說法沒有經過嚴謹整理的線索之一。 這一條收錄在辭典裡不是因為它成立，而是因為它正在被拿來賣服務。判斷方法比結論更值得帶走：看到新縮寫，先找出處；找不到出處，就先不要押預算。下一個縮寫出現時一樣管用，而下一個一定會出現。