這幾天在社群上看到關於 AI 使用的討論,讓我非常有感。
作為一個寫過 Code、搞過演算法,現在在做實體產品( Cymkube )的人,我發現很多人用 AI 的方式,其實還停留在 Web 1.0 的「搜尋」邏輯。也就是問一個問題,期待一個標準答案。
但在我看來,這就像是開著法拉利去買菜——你只用了它 1% 的效能 (笑)。
以前我們在寫爬蟲或做 SEO 演算法時,最核心的邏輯不是「抓到資料」,而是如何「清洗」並「結構化」這些資料。回頭看現在的 AI 協作,其實也是一樣的道理。如果我們只做第一層的提問,得到的永遠只是維基百科式的通識;要產出真正能商業變現的 Insight,必須要有系統架構的思維。
這完全驗證了所謂的「迭代式提示工程」(Iterative Prompting)。我把這個過程拆解成三個層次,這也是我現在每天用來 Debug 商業問題的標準 SOP:
L1 廣度掃描 (Information Acquisition)
這是大多數人停下的地方,把 AI 當 Google 用。 在這個階段,我只求「全貌」。就像剛接手一個新專案,我要先看懂所有的文件。重點不是精確,而是建立框架。技術視角: 就像是發送一個 GET 請求,先把 Raw Data 抓回來再說。
L2 深度挖掘 (Keyword Interrogation)
這是分水嶺。高手的做法是從 L1 的回答中,抓出那些「行話」或「關鍵變數」。 我不懂某個技術名詞?那個名詞就是金礦。我會拿著這個關鍵字對 AI 進行單點爆破:「你剛提到的這個概念,運作原理是什麼?為什麼它是關鍵?」。技術視角: 這是在做 Data Parsing。從雜亂的資訊中提取出真正的 Feature,這通常才是解決問題的 Key。
L3 循環驗證 (Iterative Verification)
有了深度資訊還不夠,因為 AI 會一本正經地胡說八道(幻覺)。 我會要求 AI 角色扮演反方,或是拿 L2 的結論去打臉 L1 的資訊:「如果 L2 是真的,那你一開始說的 L1 邏輯是否有誤?」。透過這種交叉詰問,逼 AI 進行邏輯收斂,產出決策建議。技術視角: 這是 Unit Test(單元測試)。確保輸出的邏輯是自洽的(Self-consistent),沒有 Bug 才能上線執行。
結語
AI 不只是一個「回答機器」,它是一個可以被你訓練的「思考夥伴」。真正的槓桿效應(Leverage),來自於你是否願意花時間去設計這個「獲取 -> 追問 -> 驗證」的迴圈。對於創業者來說,從海量資訊中過濾出高純度的 Insight,這本身就是一種核心競爭力。
不想只拿 AI 當搜尋引擎用?這個三層次架構值得你試試。
留言
張貼留言