前言

昨天我們建立了一個核心心態:AI 不是聊天對象,是需要規格書的產線員工。今天要往下追問一個更根本的問題:這門叫做 Prompt Engineering 的技術,到底在解決什麼問題?

如果你去查字典式的定義,大概會看到「設計指令以引導 AI 產出理想結果的技巧」這種說法。但這個定義沒有回答一件事:如果只是「讓 AI 產出好結果」,那我隨便多聊幾句、多試幾次,運氣好也能得到好結果,為什麼還需要一套「工程」?

答案就藏在 Engineering 這個字裡——工程要解決的從來不是「能不能做出一次好結果」,而是「能不能每一次都做出好結果」。

一、單次成功 vs 穩定產出:兩種完全不同的難度

想像兩個情境:

情境 A:你今天心情好,花 20 分鐘來回調整,終於讓 AI 寫出一份完美的週報。

情境 B:接下來 52 週,不管你當週忙不忙、資料乾不乾淨、心情好不好,AI 都要穩定產出格式一致、內容正確的週報。

情境 A 幾乎每個人都做得到,只要有耐心試錯。但情境 B 才是你實際要解決的問題——而這正是「穩定性」與「可重複性」這兩個詞真正的意思:

• 穩定性(Stability):同一份範本,面對「正常範圍內」不同的輸入資料時,輸出的品質與格式不會忽好忽壞
• 可重複性(Reproducibility):同一份範本,今天用、明天用、下個月用,只要輸入資料條件相同,產出結果應該高度一致,而不是每次都要重新調整才能用

換句話說,Prompt Engineering 要解決的核心問題是:如何把「一次靠運氣湊出來的好結果」,變成「一套不靠運氣、可以重複驗證的流程」。

二、為什麼「隨便聊、多試幾次」這條路走不通

你可能會想:反正 AI 很好用,每次資料進來我就順手調整一下 prompt,不也能解決問題?

問題在於成本會隨時間指數放大。如果你每週都要重新想一次「這次要怎麼跟 AI 講」,你等於每週都在重新發明輪子——這根本不是自動化,而是把「手動寫報告」換成「手動跟 AI 對話生報告」,省下的時間非常有限,而且品質完全取決於你那天有沒有耐心調整。

真正的自動化,是把「怎麼跟 AI 溝通」這件事本身,變成一份寫死的資產。你只在建立範本的階段投入心力去反覆調整,之後每一次使用,都是「套公式」,而不是「重新創作」。這也是為什麼 Day 22 我們會特別談版本控制——因為範本本身就是你的核心資產,值得被認真維護。

三、穩定性從哪裡來?先拆解「不穩定」的來源

要讓輸出穩定,得先搞懂輸出為什麼會不穩定。通常來自三個地方:

1. 指令本身模糊:你沒有明確定義格式、語氣、範圍,AI 每次都在「猜」,猜的結果自然時好時壞
2. 輸入資料的變異:這週資料很乾淨,下週資料缺了幾個欄位、格式跑掉,AI 沒有被告知「遇到這種狀況該怎麼辦」,就會自由發揮
3. AI 本身的隨機性:語言模型在生成文字時,本質上帶有一定機率性的變化,即使輸入完全相同,兩次輸出也可能有些微差異

這三個來源裡,前兩個是我們可以透過設計範本來控制的,第三個則是要透過「把規則寫得夠明確、夠具體」來降低它的影響範圍——規則越明確,AI 能自由發揮的空間就越小,隨機性造成的差異自然也越小。

這也直接呼應了接下來幾天的內容:Day 3 會談如何把範本拆成「骨架」和「血肉」,對應的正是解決第一個來源;Day 12 談「資料缺漏時如何安全降落」,對應的正是第二個來源。

四、今天的行動練習

回頭看你自己過去手動寫報告的經驗,想一下:

1. 有沒有哪一次,是因為「資料格式跟平常不一樣」,導致你花了額外時間處理?把這種「意外狀況」記下來,這些之後都是範本裡要特別註明的例外規則。
2. 如果請你用一句話,對一個完全沒看過你工作內容的人,描述「什麼叫做這份報告寫得好」,你會怎麼說?先寫下這句話的草稿,這會是 Day 5 建立品質檢查清單的起點。

小結

今天最重要的一句話是:Prompt Engineering 不是在追求「一次寫出神奇的咒語」,而是在建立一套「每次都能穩定運作的流程」。 這個認知會決定你接下來 28 天的學習方向——你不是在收集「厲害的 prompt 技巧」,而是在建立一套屬於你工作場景的「規格系統」。

下一篇,我們會正式拆解範本的結構,搞懂 System Prompt 與 User Prompt 之間,「骨架」與「血肉」該怎麼切分。