[AI 分享] 大模型 Skill 載入機制

 [AI 分享] 大模型 Skill 載入機制

摘要 : 大模型技能不該一次全塞進提示詞，而應以三層按需載入機制，兼顧上下文、成本與效果。

內容:

在大模型系統中，很多新手一開始會直覺地認為，既然要讓模型具備多種能力，那就把所有技能說明、程式碼檔案與參考資料一次性全部放進提示詞裡。這種做法看似直接，實際上風險很高。

首先，大模型的上下文視窗非常寶貴。如果同時塞入大量技能內容，不只容易讓上下文迅速膨脹，導致模型無法抓住重點，也會明顯提高推理成本，進而帶來高昂的使用費用。

較好的做法是採用「漸進式披露」的思路，也就是一種三層式的技能載入機制。它的核心精神是：只在真正需要時，才載入對應的資訊，避免無效佔用上下文空間。

第一層是「原資料」。可以把它理解為一張簡潔的工具清單，放在模型隨時可見的位置。這份清單只包含每個工具的名稱，以及一句簡短介紹，讓模型知道自己有哪些能力可用。因為內容非常精簡，所以可以長期保留在上下文中，而不造成太大負擔。

第二層是「技能正文」。當模型根據第一層的清單，判斷當前任務需要某個特定技能時，系統才會進一步載入該技能的詳細說明。這部分通常包含具體步驟、操作規則與注意事項。也就是說，只有在技能真正被觸發時，這些較長的核心內容才會被臨時加入上下文。

第三層是「捆綁資源」。有些任務除了技能說明外，還需要更大型的參考資料、字典，甚至可直接執行的程式碼腳本。這時系統不會一次把所有內容完整展開，而是依照任務進度，精準調用當下需要的那一小部分資源。像是腳本可以直接執行，不必把全文讀進上下文；查資料時，也只取出必要片段即可。

整體來看，這種三層載入機制的本質就是按需載入。用不到的資訊不提前加入，需要時再精準調用。這樣不僅能有效保護上下文空間、降低成本，也能讓大模型把注意力集中在眼前任務上，提升整體執行效率與品質。

[AI 評估維護] AI模型技能評估與回歸測試方法

 [AI 評估維護] AI模型技能評估與回歸測試方法

摘要 : 建立AI Skill評估與維護系統，提升生產環境中的穩定性、可靠性與可維護性。

內容:

如何建立一套系統化的方法，來評估與維護 AI 模型的 Skill，並進一步提升它在實際應用中的可靠性與可維護性。這件事之所以重要，是因為很多 Skill 一旦部署到生產環境後，表面上看起來可以正常運作，但每次修改之後，團隊往往缺乏客觀標準去判斷這次調整究竟是優化，還是造成退步。短期內或許還能靠經驗判斷，但隨著系統越來越複雜，風險也會快速累積。

尤其當 Skill 已經接入真實工作流後，它可能會呼叫工具、生成檔案、改變系統狀態，因此每一次修改都不只是改一段提示詞，而是可能牽動整個系統行為。真正的挑戰，不只是讓 Skill 能運作，而是要確保它在持續變動的過程中，依然保持穩定、可預期的表現。

在評估 Skill 之前，首先要先釐清到底要評估什麼。根據內容提到的方法，成功標準可以分成四大類。第一是結果目標，也就是任務有沒有完成、應用有沒有成功跑起來。這是最直觀、也最容易被單獨關注的一項。第二是過程目標，重點在於 Skill 是否依照預期設計的步驟與工具鏈執行。第三是風格目標，也就是輸出是否符合既定規範，例如檔案結構、命名方式、程式碼風格等是否一致。第四則是效率目標，檢查是否存在多餘的工具呼叫、資源浪費，或不必要的 Token 消耗。只有把這四類目標綜合起來，才能比較全面地衡量一個 Skill 的真實表現。

另外，Skill 的維護不應只聚焦在執行內容本身，而是要分成「執行體」與「觸發邊界」兩個獨立面向來看。執行體指的是 Skill 的具體指令、步驟與工具鏈；觸發邊界則是 Skill 的名稱與描述，也就是它在什麼情況下會被選中或被呼叫。這兩者雖然彼此獨立，但都會直接影響最終效果。實務上，團隊通常比較容易關注執行體的修改，卻忽略了描述文字與觸發條件的變動也可能讓 Skill 在不該啟動的時候被啟動，因此兩部分都必須分開維護與檢查。

接著，內容也提到三類容易被忽略的隱藏假設，這些往往是 Skill 失控的來源。第一類是觸發假設，意思是 Skill 是否能在該被呼叫時被呼叫，不該被呼叫時不會誤觸發。如果邊界不清楚，就可能出現原本只是要調整樣式，卻意外啟動新應用的情況。第二類是環境假設，也就是 Skill 是否偷偷假設了某些執行環境條件，例如預設目錄是空的、系統已安裝某些工具，這些在開發環境中可能不明顯，但一旦換環境就容易出錯。第三類是執行假設，指的是 Skill 內部步驟之間的依賴是否被妥善處理，例如還沒安裝依賴就嘗試啟動服務，這種問題可能不是每次都發生，但本質上是潛在風險。

為了降低這些風險，就需要建立回歸樣本集。最重要的原則，是把歷史上曾經導致 Skill 出錯或失控的真實案例收集起來，整理成回歸測試樣本。這個樣本集不一定要很大，每個 Skill 大約十幾到二十個 Prompt 就可能足夠，關鍵在於能否覆蓋重要的失敗場景與風險邊界。

這些樣本可以分成幾種類型。第一種是顯示呼叫，也就是直接指定要測試某個 Skill。第二種是隱示呼叫，只描述要解決的問題，觀察系統會不會自動正確選中這個 Skill。第三種是帶上下文的呼叫，也就是加入真實業務中的雜訊與背景資訊，測試 Skill 在複雜情境下是否仍能被正確識別。第四種則是復控樣本，也就是刻意設計那些本來不應該觸發該 Skill 的輸入，檢查是否出現誤觸發。這類樣本特別重要，但在實務中經常被忽略。

在自動化評估方面，核心前提是先把 Skill 的執行軌跡完整記錄下來。像是執行了哪些命令、建立了哪些檔案、操作順序如何，都應該以結構化日誌的方式保存。只有當這些過程資料被穩定記錄後，後續的自動評分器才有依據可以判斷 Skill 的表現是否合格。

自動評分器大致可以透過兩種方式來運作。第一種是確定性檢查，也就是預先定義明確規則，檢查某個命令是否有執行、某個檔案是否有建立、步驟順序是否正確。這種方式優點是規則明確、容易除錯，也適合驗證基礎功能是否正確。不過它的限制是，很難判斷最終產物「好不好」。

因此，第二種方式是評分細則檢查，也就是引入大模型進行整體評估。像是程式碼結構是否合理、命名規範是否一致、輸出品質是否達到要求，都可以透過多維度打分的方式進行判斷。把確定性檢查與評分細則檢查結合起來，就能同時兼顧底層功能正確性與整體結果品質，讓 Skill 的評估更完整，也更接近實際生產需求。

[AI 分享] RAG是否已死

 [AI 分享] RAG是否已死

摘要 : RAG並未過時；雖然大模型上下文變長，但在成本、效率與私有知識接入上，RAG仍具重要價值。

內容:

RAG（Retrieval Augmented Generation，檢索增強生成）是近年大模型領域中相當成熟的一項技術。不過，最近有不少自媒體開始宣稱「RAG已死」，因此本文希望從原理、價值與爭議三個角度，重新梳理RAG的前世今生，看看這個說法是否站得住腳。

從名稱來看，RAG本質上是一種「用檢索來增強生成效果」的方法。傳統做法是把問題直接交給大模型作答；而在RAG架構中，會在問題與大模型之間加入一個檢索模組，先從外部知識庫中找出相關內容，再將問題與檢索結果一併交給模型。這樣做的根本原因在於：原始問題所需的資訊，往往不完整存在於大模型本身，因此需要透過外部知識庫來補足，尤其是企業私有資料、內部文件或特定領域知識。

那麼，為什麼不直接把整個外部知識庫全部丟給大模型？原因很簡單，因為大模型有上下文長度限制。即使上下文已經比以前大很多，把所有知識一次性輸入，不但可能超出限制，也會讓模型分析與計算的成本大幅上升，因此仍需要一套有效率的篩選與檢索機制。

RAG的基本流程大致如下。首先，外部知識庫會先被切分成多個較小的文本分片。這樣做的目的是讓系統在每次檢索時，更容易找到和問題最相關的局部內容，而不是從龐大原文中無差別處理。這些分片，就是之後會提供給大模型參考的文本材料。

接著，這些文本分片需要經過向量化（embedding）處理。由於電腦本質上處理的是數值而不是文字，因此必須將文本轉換為向量，映射到向量空間中。在這個空間裡，語意相近的文本應該彼此靠近，語意差異大的文本則距離較遠。也就是說，若兩段內容意思相近，經過向量化之後，它們在向量空間中的位置也應該相近。

當使用者提出問題時，問題本身也會先被向量化。接著，系統會拿這個問題向量去比對知識庫中各個文本分片的向量，找出最接近、也就是語意上最相關的幾個分片。最後，再把問題與這些相關分片一起送進大模型，讓模型在有額外上下文支援的情況下生成答案。這也是RAG能提升回答準確度的核心原因。

這裡有一個很重要的前提：知識分片與使用者問題在向量化時，應採用一致的向量化模型或演算法。只有在同一套語意映射規則下，系統才能保證語意相近的內容在向量空間中也足夠接近，進而讓檢索結果具有可靠性。

雖然RAG的整體流程看起來不複雜，但真正進入工程實作時，仍有許多細節需要最佳化。首先是分片策略。分片如果切得不好，就可能破壞語意完整性，例如把同一句話、同一條法規或同一段關鍵說明拆散，導致檢索時拿到的是殘缺資訊。以法律文件為例，理想情況是以完整法條作為切分單位，而不是把一條法規拆到不同分片裡。因此，不同場景下需要不同的分片邏輯。

第二個關鍵點是向量化演算法的選擇。RAG是否能準確找回相關內容，很大程度取決於向量模型是否能正確表達語意相似性。實務上常常需要針對不同資料集，測試多種向量化方案，挑選效果與效能兼顧的方法。

第三個重點是檢索策略本身。系統可以只取最相近的兩個分片，也可以擴大到三個、五個甚至更多。檢索條件設得太嚴，可能漏掉重要資訊；設得太寬，則可能帶入太多雜訊。因此，檢索數量與門檻也需要依應用場景做客製化調整。

那麼，為什麼會有人說「RAG已死」？其中一個主要理由，是因為現在大模型發展很快，上下文長度越來越大。像 DeepSeek、Gemini 等模型都已支援非常長的上下文，於是有人認為，既然模型可以一次讀進大量內容，就不再需要額外的檢索流程，只要把所有相關資料直接給模型即可。

但這樣的推論其實並不充分。即便上下文夠大，把所有資料一股腦交給模型，仍然會面臨兩個現實問題：第一是效率，因為大模型推理本來就慢，輸入內容越多，整體處理時間越長；第二是成本，更多的上下文代表更高的計算資源消耗。因此，僅因上下文變長就斷言RAG失去價值，並不合理。

另一種批評則來自效果面。有人認為，RAG依賴分片檢索，容易造成語意遺失，因此最終效果不如預期。這個問題確實存在，但它更像是「RAG做得不夠好」，而不是「RAG沒有用」。因為RAG本質上是一個框架，真正的效果高度依賴分片方式、向量化品質與檢索策略。只要這些環節有足夠細緻的最佳化，RAG仍然可以產生相當不錯的結果。

總結來說，RAG並沒有死。相反地，它仍然是在私有知識接入、大模型回答增強、控制成本與提升效率等場景中非常重要的方法。大模型上下文變長，確實會改變RAG的使用方式，但不代表它會被完全取代。更準確地說，RAG正在演進，而不是消失。

痛點營銷的成交關鍵

 [AI 影響] 痛點營銷的成交關鍵

摘要 : 透過具體場景與嚴重後果，讓客戶看見問題風險，提升危機感與購買意願。

內容:

痛點營銷的核心，不是一直強調產品有多好，而是要真正站在客戶角度，理解他內心的擔憂與需求。很多銷售雖然很勤奮、很熱情，卻始終無法成交，原因往往在於只會介紹產品優點，卻沒有讓客戶感受到「不解決問題」的後果。

客戶真正買單的原因，通常不是因為產品參數多厲害，而是因為他意識到，如果現在不處理這個問題，未來可能會付出更大的代價。換句話說，客戶害怕的不是產品本身，而是忽略問題之後所帶來的風險。

因此，銷售在溝通時，不能只停留在表面介紹，而要把產品轉化成生活中的具體場景，並清楚描述問題若持續存在，可能造成哪些實際影響。當風險可以被想像、被看見，客戶就更容易產生危機感，也更願意採取行動。

例如賣淨水器時，如果只是說水裡有雜質、鐵鏽，客戶通常不會覺得嚴重。但若進一步說明，長期使用含有雜質與重金屬的水，可能影響皮膚狀態、堵塞毛孔，甚至讓保養效果變差，客戶就會更直接感受到這個問題與自己生活息息相關。

這套方法的關鍵公式，就是「具體場景＋嚴重後果」。它適用於大多數行業，因為本質上是在幫助客戶看見那些平常被忽略的小問題，並理解這些問題若不處理，將逐步影響生活品質、形象，甚至健康。

除了淨水器，像服裝銷售也能運用相同邏輯。若只是強調價格或款式，吸引力有限；但若讓客戶意識到，長期只圖便宜、忽略穿搭質感，可能會影響整體氣質與他人對自己的印象，客戶就更容易理解購買背後的價值。

所以，銷售真正賣的從來不只是產品，而是一種更安心、更省心、更有品質的生活方式。好的銷售，是透過專業幫助客戶發現風險、看見後果，並提供解決方案，進而促成成交。

[AI 影響] AI分詞到未來職場的關鍵變化

 [AI 影響] AI分詞到未來職場的關鍵變化

摘要 : AI其實靠分詞、機率預測與上下文運作，並非真正思考；理解其侷限與Knowhow價值，將是未來關鍵。

內容:

想了解AI，首先要先理解它最基礎的動作：分詞。分詞可以視為人類語言與AI語言之間的翻譯過程。當人類輸入一句話時，系統會先把文字拆成一個個token，再進一步轉成對應的數字，也就是token ID。這些token ID才是AI真正能理解與處理的語言，之後才會送入大語言模型進行計算。

很多人以為大語言模型像人類一樣，會先思考、分析，再給出答案，但其實並不是如此。大模型本質上是一個數學函式，它不會思考，只會計算。它每次只能產生一個token，也就是一次只輸出一個單位的答案，所以我們平常看到AI像是一個字、一個字慢慢生成回覆，其實正是它逐步計算與輸出的結果。

而AI之所以能持續產生內容，是因為它會根據接收到的所有資訊，去計算詞表中每個候選詞出現的機率，再選擇最有可能的結果作為下一個輸出。因此，AI看起來像是有智慧，實際上是因為它不斷在做高機率預測，而不是像人類那樣真正理解世界。

這也帶出一個重要問題：高機率不等於正確答案。AI之所以可能答對，是因為某個答案在資料中出現機率最高；但如果錯誤資訊被大量散播，錯誤答案的機率也可能上升，甚至超過正確答案。這代表AI不僅會出現幻覺，也可能被輿論、內容操作與商業手法所影響。

近年出現的GEO（生成式引擎最佳化），正是建立在這種邏輯之上的商業模式。透過最佳化網路上的產品資訊與內容格式，讓AI更容易將這些內容判定為高品質、高相關，進而提高推薦機率。這說明AI的回答不只可能出錯，也可能受到商業利益引導，尤其對老人與孩子這類較缺乏判斷能力的使用者來說，更需要建立正確認知：AI可以參考，但不能盲信。

除了輸出邏輯，AI還高度依賴Context，也就是上下文。上下文包含對話歷史、使用者提示詞、系統提示詞，以及AI正在生成中的內容。這些資訊會被一併送入模型，成為它預測下一個token的基礎。若把LLM比喻成AI的大腦，那麼Context就像它的短期記憶。

而這個記憶是有上限的，這個上限就叫Context Window。它指的是模型單次最多能處理多少token。目前主流模型的上下文容量已經相當驚人，基本都能超過100萬token，換算成中文約可達150萬字。對一般使用者而言，問題往往不是夠不夠用，而是如何有效利用這麼大的容量。

為了讓AI接觸更多外部資料與工具，於是出現了MCP，也就是模型上下文協議。它可以理解成AI世界裡的統一接孔，像電腦的USB一樣，讓模型能更方便地連接外部能力。在這個基礎上，又延伸出幾個重要概念，例如Workflow工作流、Agent智慧體、智慧體駕馭框架，以及Skill技能包。

如果把整個AI系統想像成一座工廠，那麼工作流就是高度自動化的生產線；智慧體則像是能規劃、執行任務的AI員工；而智慧體駕馭框架則像主管，負責協調、管理與約束這些智慧體，避免它們失控或出錯。至於Skill技能包，則像是每位AI角色所擁有的專業能力證照，不論是文案、設計、維修、表格，甚至各行各業的專業技能，都可以被封裝成工具供AI調用。

這也讓知識的形態出現巨大改變。對人類而言，知識往往需要長期學習、練習與內化；但對AI來說，知識更像是可直接使用的工具。一旦具備相關能力模組，它就能快速投入工作。這種效率差距，對許多職位都形成了壓力。

因此，未來人類真正的競爭力，可能不再只是會不會用AI，而是是否擁有Knowhow。Knowhow指的是一個行業長時間累積下來的隱性經驗，是那些沒有完整寫在書上、卻存在於專家判斷與實作細節中的能力。這種能力來自實戰、直覺、感受與判斷標準，也是AI最難直接取代的部分。

例如同樣是做出百萬播放影片，新手可能需要反覆嘗試很多次，但有經驗的創作者往往能更快掌握觀眾心理、節奏、選題與傳播方式，因此更有機會一次成功。這種差距，不只是技術工具的問題，而是Knowhow的差距。

相關就業資料也反映了這種趨勢。當高Knowhow的高級崗位仍維持成長時，低Knowhow的初級崗位卻開始下滑，尤其在生成式AI普及後，這個差距變得更加明顯。這代表AI正在重塑職場門檻，也讓年輕人在還沒真正累積工作經驗前，就面臨被替代的壓力。

這也引發兩個值得深思的問題。第一，年輕人若在進入職場前就被AI取代，未來該如何累積自己的Knowhow？第二，已經擁有Knowhow的專家，是否還願意繼續分享自己的經驗？因為在AI時代，知識分享不再只是幫助後進，也可能同時成為提升AI能力、加速取代更多人的來源。

最終，這些問題或許沒有簡單答案。但可以預見的是，未來世界的人可能會分成兩個方向：一群人選擇回歸家庭、自然、身體、信仰與真實關係，重新尋找文明的源頭；另一群人則全面奔向AI、機器人、腦機介面與新生產力革命，探索文明的下一站。這兩條路，也許都代表著人類在新時代中的不同選擇。

[分享] 賣的不只是產品，而是顧客的嚮往

 [AI 分享] 賣的不只是產品，而是顧客的嚮往

摘要 : 真正高價與高利潤的關鍵，往往不是解決問題，而是滿足顧客對身分、自由與美好生活的嚮往。

內容:

最會賺錢的人，往往不只是會解決問題，而是懂得滿足顧客內心深處的嚮往。當產品只是在解決功能性需求時，顧客可能只會購買一次；但當產品承載了某種理想生活、身分象徵或情感價值時，顧客就更容易持續買單。

以咖啡為例，速溶咖啡主要解決的是「提神」與「方便」的需求；但星巴克賣的並不只是咖啡，而是都市人嚮往的「第三空間」——一個介於家庭與工作之間，能夠放鬆、社交、短暫喘息的生活場景。因此，一杯原本只值幾塊錢的咖啡，能夠被賦予更高的價值。

再看包包市場，幾百元的包已足以解決日常收納需求，但愛馬仕販售的並不是單純的實用品，而是一種頂級階層的象徵與入場券。像鉑金包這樣的產品，價格可高達數十萬，甚至長年缺貨，背後反映的正是顧客對身分認同與稀缺價值的追求。

同樣的邏輯也出現在其他產業中。露營經濟賣的不只是帳篷與裝備，而是現代人對逃離內捲、回歸自由與自然的想像。迪士尼賣的也不只是樂園門票，而是一種能短暫逃離現實、進入夢幻烏托邦的沉浸式體驗。

這也說明了一個重要觀點：痛點只能促成一次交易，但嚮往更能建立長期吸引力與品牌忠誠。當顧客購買的不再只是功能，而是對某種生活方式、情感狀態或社會角色的投射時，產品的價值就會被大幅放大。

因此，真正值得思考的，不只是你的產品能幫顧客解決什麼問題，而是它能幫顧客實現什麼樣的嚮往。

[AI 分享] 設計師也能高效用 Codex

 [AI 分享] 設計師也能高效用 Codex

摘要 : Codex正快速成為設計師新工具，透過上下文、外掛與技能配置，可產出更精緻且可迭代的UI原型。

內容:

OpenAI正式推出更適合設計師使用的Codex，且設計師已成為成長最快的使用族群之一。隨著外掛、標註、可分享站點預覽等功能陸續上線，Codex不再只是工程師的工具，對設計師、行銷人員等非技術使用者也越來越友善。

Codex本質上是一個由OpenAI推出的編碼代理，可以在終端、IDE與桌面端運作，自主完成讀取專案、編寫程式、檢查成果，再交由使用者稽核的流程。背後模型也針對不同場景進行調校，有適合快速任務的低延遲版本，也有能處理複雜工作的高能力版本。

對設計師來說，使用Codex是否能做出真正有質感的成果，關鍵不在一句提示詞，而在於事前是否提供足夠完整的上下文。如果只輸入「幫我做一個儀表盤」，雖然它能生成畫面，但結果往往會流於常見、缺乏辨識度的AI風格，因此建立明確的上下文是最重要的一步。

第一個核心做法，是建立一份Agent MD檔案。這份檔案可以視為專案簡報，裡面可放入設計規範、元件樣式、設計變數、排版規則、色彩系統與注意事項。它的好處是Codex會自動讀取，不需要每次重新解釋需求。除了告訴AI要做什麼，也要明確寫出不要做什麼，例如避免過度花哨、玻璃擬態或亮眼漸層等風格，這能大幅降低產出偏離預期的機率。

第二個重要步驟，是安裝外掛。Codex的外掛可連接MCP伺服器與各種技能包，幫助AI與外部工具整合。對設計師來說，產品設計外掛相當實用，能協助探索產品方向、檢查使用流程、分析痛點，甚至把真實網址直接轉換成可在本機執行的互動原型。若本身有使用Figma，也非常推薦安裝Figma外掛，能加快從設計稿到可執行程式碼的流程。

另外，像Mobbing這類設計靈感平台的MCP伺服器也很值得導入。因為它能讓Codex分析大量來自Uber、Netflix、Apple等成熟產品的真實介面，協助生成更符合市場慣例與高品質設計模式的UI，避免AI只靠猜測做出空泛的畫面。

第三個步驟則是使用技能。技能可理解為一套可重複使用的指令規則，能讓Codex依照特定方法工作。設計師可依自己的流程建立專屬技能，例如生成圖片、優化介面、套用設計工程規範等。搭配Agent MD與外掛，技能能讓整個產出流程更穩定，也更符合團隊標準。

當這三項配置完成後，就可以開始第一次生成。文中示範的案例，是用最新模型生成一套桌面版深色模式投資儀表盤，包含儀表盤、交易、預算與目標分析、持倉與設定等頁面。提示詞除了描述頁面需求，也會要求參考Agent MD檔案與附帶的靈感圖片，讓Codex更清楚視覺方向。

在生成過程中，如果資訊不足，Codex還會主動追問，例如要做靜態精緻UI，還是完整可互動原型。這代表它不只是被動接收命令，而是能協助釐清任務目標。若是較簡單的專案，可以直接要求產出完整原型；若專案較複雜，則建議先確認風格與結構，再逐步擴充互動功能。

值得注意的是，使用產品設計外掛後，Codex在交付成果前還會進行視覺質檢。它會自動開啟瀏覽器檢查產出畫面，擷取狀態並修正與參考圖明顯不一致的地方。這種讓AI自行檢查與校正成果的能力，對提升最終UI品質非常重要，也能減少設計師後續手動微調的負擔。

整體來看，Codex對設計師的價值，不只是「幫你畫圖」而已，而是能在設計系統、靈感參考、互動原型與視覺校驗之間形成一套更完整的工作流。只要前期把上下文、外掛與技能配置好，Codex就有機會成為設計師身邊像全職助手一樣的存在，協助快速產出更成熟、可執行且更有質感的設計成果。

[AI 分享] 賣點要翻成需求

 [AI 分享] 賣點要翻成需求

摘要 : 顧客不是為產品參數買單，而是為自己的麻煩、爽感與期待買單。賣點若能對準需求，成交力才會提升。

內容:

很多老闆賣不動貨時，第一反應是拼命加碼講賣點：材質、工藝、價格優勢、品牌實力一直重複說。但賣點講得越多，顧客反而越無感，因為問題往往不是顧客聽不懂產品，而是他感受不到這東西和自己有什麼關係。

核心觀念是：賣點是你想說的，需求才是顧客想買的。你一直講產品多厲害，使用者未必會付錢；但只要講中他的麻煩、慾望與期待，他就會立刻產生感覺。真正驅動下單的，從來不是產品參數，而是需求被點燃。

王老吉就是典型例子。如果它一直講草本配方、傳統工藝、口感清爽，大家未必記得住；但一句「怕上火喝王老吉」，立刻讓人知道什麼場景該買：吃火鍋、吃燒烤、熬夜、喉嚨不舒服時。它不是在背賣點，而是直接站穩了需求場景。

顧客下單，常被三個按鈕推動：第一是痛點，想少一點麻煩；第二是爽點，想立刻變爽；第三是癢點，想成為更好的自己。像賣枕頭，不要只講記憶棉、人體工學，而要講「醒來脖子不僵不痛」；賣口紅，不只講色號和持久，而要講「一擦上氣色變好，出門就被誇」；賣眼霜，不只講成分科技，而要講「看起來沒那麼累、沒那麼顯老」。

所以不是賣點不能講，而是不能只站在產品角度往外倒。你要把產品語言翻譯成使用者語言：把「人體工學分區承托」翻成「明天醒來脖子不疼」，把「持久不脫妝」翻成「一出門就被誇氣色好」，把「緊緻科技」翻成「看起來更年輕更有精神」。

最後要記住，顧客不是為你的產品買單，而是為自己的問題、情緒和期待買單。別再只問產品有多少賣點，而要問顧客現在有什麼麻煩、想立刻得到什麼爽感、期待自己變成什麼樣。只有被需求接住的賣點，才真正有成交力。

[AI 分享] 用戶運營與關係建立

 [AI 分享] 用戶運營與關係建立

摘要：用追求與交往的過程，比喻用戶運營從陌生到信任再到支持的完整路徑。

內容:

把使用者運營放進真實的人際互動場景裡，就會更容易理解它的本質。就像你不會在毫無鋪墊、對方還不認識你的情況下，直接向一個女生表白；同樣地，你也不該一開始就急著向使用者推銷產品、強調自己有多好。因為在最初階段，對方對你是陌生的、無感的，也缺乏了解。

這個階段可以對應到使用者運營的A1。此時最重要的不是成交，而是先讓對方認識你、了解你，並看到你值得被關注的一面。就像在追求過程中，你會自然展現自己的生活態度、價值觀與優點，慢慢建立第一印象。

當對方開始對你產生一些好感時，就進入了A2階段。這時候不只是被看見，而是開始形成初步的認同。你透過持續互動，讓對方感受到你的真誠、穩定與吸引力，讓關係從陌生慢慢走向熟悉。

接著到了A3階段，雙方關係進一步升溫。你會開始描繪共同的願景，也會在困難出現時表現出立場與承擔，讓對方感受到安全感與信任感。這在使用者運營中，代表的不只是曝光與互動，而是更深層的信任建立。

當時機成熟，對方的情感與認同都到位之後，才會來到A4，也就是正式轉化的階段。就像表白成功、確認關係一樣，這不是一開始硬推就能得到的結果，而是前面每一步累積之後的自然發生。

而A5則是更長期的關係經營。當彼此建立穩定連結、持續互信，甚至在你需要的時候，對方也願意主動支持你，這就不只是一次交易，而是一段成熟且有黏性的關係。對應到使用者運營，就是從轉化走向忠誠、認同與主動擴散。

這段比喻提醒我們，自媒體與行銷的對象並不是冰冷的流量數字，而是螢幕另一端一個真實的人。當手機隔絕了很多情感交流時，我們更容易忽略對方的感受，誤以為只要一直說自己多好，對方就會買單。

因此，更好的做法是先預設對方是冷漠的、陌生的、無感的，再依照關係發展的節奏去溝通。不要在A1的時候說A5的話，也不要在還沒建立信任前，就急著要求對方做出承諾。真正有效的使用者運營，本質上就是尊重關係建立的順序。

[AI 分享] 用 Codex /goal 理解 Agent 核心

 [AI 分享] 用 Codex /goal 理解 Agent 核心

摘要：Codex 的 /goal 模式是理解 Agent 的好入口，涵蓋目標、狀態、工具、驗證、預算與停止條件。

內容:

很多人學 Agent 時，會先接觸規劃、多智慧體、工具呼叫、長期記憶、自動化與工作流等大概念。這些當然重要，但如果想真正理解 Agent 為什麼能持續做事，而不只是回答一句話，Codex 的 /goal 模式其實是一個非常適合的切入點。它不會複雜到難以理解，卻剛好包含了 Agent 系統中最關鍵的幾個元素：目標、狀態、工具、驗證、預算與停止條件。

從表層使用來看，平常給 Codex 一個 prompt，它通常只會處理一輪，可能讀檔、改程式、跑命令、看錯誤後回傳結果。若任務很短，這樣就足夠；但當任務拉長，例如專案遷移、修複雜 bug、效能優化或補齊測試時，就不可能靠一輪完成。這類任務常常要經過多個檢查點：先重現問題、再定位原因、接著修改、執行測試、修正新錯誤，最後再驗證結果。沒有 /goal mode 時，人往往得一直守在旁邊，反覆下「繼續」指令；而 /goal 的作用，就是把這個持續推進的意圖，變成一個可持久追蹤的任務目標。

/goal 模式最重要的概念，不只是「長任務」，而是「可驗證的停止條件」。這也是許多人學 Agent 時最容易忽略的一點。很多人以為 Agent 的核心在於會拆步驟，但真正困難的是：系統怎麼知道自己什麼時候做完。如果沒有清楚的完成定義，它就只會不停生成看似合理的下一步，卻無法真正結束。因此，/goal 的本質不是讓模型更努力，而是給模型一個能反覆檢查的完成標準。

例如，若目標是把專案從 JavaScript 遷移到 TypeScript，並要求 Strict Mode 編譯通過、不保留明顯 Any、關鍵路徑測試全數通過，這就是一個明確且可驗證的 /goal。相較之下，「幫我把專案優化一下」就過於模糊，沒有範圍、驗收方式與停止依據。當目標寫得夠清楚，Codex 每一輪都能檢查：編譯過了嗎、Any 清掉了嗎、測試跑了嗎。如果答案是否定，它就不應宣告完成。這也說明 Agent 的第一層核心，就是目標必須可驗證。

更深入來看，/goal 並不是只存在對話上下文中的一段文字。從原始碼可見，它會被寫入獨立的 SQLite 狀態資料庫中，並以執行緒 ID 對應任務資料，包含目標文本、狀態、Token 預算、已消耗 Token、已用時間、建立時間與更新時間等欄位。這代表 /goal 不是單純依賴模型記住你的需求，而是作為一個真正存在於系統外部的任務狀態。上下文可能被截斷、壓縮或摘要，但外部狀態表能明確保存任務目前進展、資源消耗與是否結束。這正是 Agent 的第二層重點：長任務不能只靠上下文，必須有外部狀態。

再往下看工具邊界設計，原始碼中可見幾個和 /goal 相關的工具，例如 Get/goalal、Create/goalal 與 Update/goalal。Get/goalal 用來查看當前目標與資源使用情況；Create/goalal 用來建立新目標，但不能隨意覆蓋尚未完成的任務；Update/goalal 則更關鍵，模型能更新的狀態很有限，主要只是在「完成」或「阻塞」之間做判定。至於暫停、恢復、清空、預算限制與用量限制，則由宿主系統控制，而不是交給模型自由決定。這反映出很典型的 Agent 設計原則：模型負責推進與判斷，系統負責保存狀態、控管邊界與限制資源。這也是 Agent 的第三層重點：工具要能行動，但權限必須收口。

/goal 最像 Agent 的地方，在於它的自動續跑機制。當執行緒進入 Idle 狀態時，系統會檢查是否存在 Active /goalal；若有，就會讀取該目標，生成一個 continuation 的執行項，並將它重新注入執行流程，啟動下一輪工作。所以，我們看到的「它自己繼續做」，並不是模型突然產生了自我驅動，而是執行時系統在空閒邊界做了一次排程決策。這一點非常重要，因為它把 Agent 從神祕化的想像，拉回工程實作的本質：它更像是一個有目標、有狀態、有觸發條件、能決定下一步的狀態機。這就是 Agent 的第四層：持續性來自執行時排程，而不是來自模型的主觀意志。

在資源管理與停止條件上，/goal 的設計也很值得借鏡。它不是單純讓模型一直跑，而是會記錄 Token 與時間消耗，甚至在 Token 計算上，還會扣除快取輸入，避免重複計算成本。這背後反映的是一個非常現實的系統設計問題：長任務必須有成本視角。若一個 Agent 能長時間自動執行，卻不知道自己花了多少資源，那最終只會讓自動化失控。

此外，/goal 的狀態不只包含 Active 與 Complete，還有 Paused、Blocked、Usage Limited、Budget Limited 等狀態。Paused 代表可以被人工暫停；Blocked 表示任務推進受阻；Usage Limited 與 Budget Limited 則代表達到用量或預算上限；Complete 才是真正完成。這些狀態共同說明，/goal 不是無限迴圈，而是一個有預算、有邊界、有失敗與停止條件的長任務機制。這也是 Agent 的第五層核心：不只要會開始，更要會停。很多自動化系統不好用，不是因為它不會做事，而是因為它不會停。

從實用角度來看，凡是「中間步驟多，但最後有清楚驗收標準」的任務，都很適合 /goal。像是程式碼遷移，可以定義成遷移到特定框架、頁面視覺一致、建構成功、關鍵測試通過；修 bug 可以定義為先重現問題、只修改相關模組、補回歸測試、本地測試通過並說明驗證結果；效能優化則可以要求首頁 TTI 降到指定秒數內，並以指定命令驗證，且不能犧牲核心功能；資料研究也可以要求閱讀指定資料、提取證據、給出結論與不確定點，且關鍵判斷都必須附來源。這些任務都有清楚邊界，因此很適合交給 /goal 持續推進。

相反地，有些任務就不適合 /goal。第一種是開放式、沒有完成定義的任務，例如「幫我把專案做得更好」，因為沒有 Done，系統就沒有停下來的依據。第二種是把一堆互不相關的事情塞在一起，例如一邊修登入、一邊改首頁、再重構支付、順便寫週報，這比較像待辦清單，而不是單一 /goalal。第三種則是需要頻繁人工主觀判斷的任務，例如設計風格要不要更高級、文案是否更像某個品牌、商業策略是否該轉向，這些更適合先讓系統做規劃或提出方案，再由人做決策。

整體來說，Codex 的 /goal 模式之所以是理解 Agent 的好入口，不是因為它只是多了一個更強的提示詞，而是因為它完整呈現了 Agent 系統運作的幾個核心原則：目標要可驗證、任務要有外部狀態、工具權限要受控、續跑來自系統排程、執行必須記帳且能停止。當你理解了這些，就更能明白，真正能長時間穩定運作的 Agent，不是無限循環的模型，而是一個有狀態、有邊界、有證據的系統。