生成式 AI 精準生成術結構性 PROMPT ‣ 六叔觀察站

生成式 AI 聰明但無厘頭、不精準，讓它增加專業生產力，試試看結構性的 Prompt 。

有這個經驗嗎？覺得 AI 是比人類努力又勤快（通常還更聰明）的下屬，你要 500 字他交 2000 字，一次交 4 版給你選！敬業精神雖然可嘉，但翻開看，唉！往往少了個「魂」。

身為 Product Manager，AI 雖然可以幫忙執行複雜的系統企劃，但靠口語描述常出錯、重做又跟前面完全不同了，結果是花了很多脣舌要它改正，改正後又出新錯誤。

不只系統開發，只要是專業使用者，例如學者寫論文、企劃寫大型報告、編劇寫多集的電視劇劇本，應該也有相同的問題，你的要求比 AI 的程度高，但不知如何要它準確達成你的要求。

除了品質要專業，用 AI 產出複雜內容要花錢的，或是有限制時數，我用 AI Agent 工作 8 小時曾經花掉 NTD$1000 元，能一次到位不是省錢了嗎？

參考 AI 做圖的人研究精準提示（prompt），說清晰讓 AI 懂，就能畫出有細微差別的圖，那麼 LLM 也可以嗎？於是長年使用心智圖和 RemNote 的我想到用「結構性提示」的方法，雖然跟 AI 繪圖咒語差別很大，但目的相同，就是讓 AI 懂我。

要省時且達到你的專業品質，你可以試試看，我覺得比用自然語言效果好多了。

如果是「嚐鮮」階段，會覺得 AI 很厲害什麼都會，但專業上你一定比它厲害，要讓它幫到你，得幫它提升水準。

減少歧義增加意義的思維

海明威的文章是冰山寫法，冰山露在水面上的只有 10%，水下是 90%。

其實任何人的語言文章都分作「從文字中看得到」的意義，和「文字中看不到」的「言外之意」。

要減少歧義、增加意義，要從「言內之義」和「言外之意」雙管齊下。

言內之義：詞彙的豐富性

英文老師教閱讀測驗時都說「看到動詞不懂，就換成 do, get 讀讀看」通常會看懂。這是因為，沒受過很多教育的英語母語人士，詞彙量也不大，所以英文中有一大堆片語都是 do… get…，這種「萬用動詞」，我稱為「虛詞」或「虛動詞」。

中文不假思索說出來的話，通常充滿虛詞，例如「『下架』被講成『進行一個下架的動作』，『了解』成了『做一個了解的部分』¹」，虛詞多到變成「語言癌」了！

如果發簡訊限制 40 字²，就會斟酌去掉「虛詞」，例如一篇貼文：

虛詞版：「萬事問臉書：臉書每天發一大堆亂七八糟的貼文內容糟糕很討厭，求問要怎麼樣讓它停止？」
精簡版：「防臉書推薦可憎貼文，關閉、檢舉，還是封鎖？」

不討論個人喜好，精簡版雖短但表達更多意義，例如：

定義了臉書的行為：不是「發文」而是「推薦」，人家就不會問「是什麼發文？」
定義對這種行為的態度：不是與我無關的內容，而是有關且有態度—-可憎
定義了回覆選項：不只問怎麼辦，而是有選項讓人好回覆。

不用虛詞才能定義清晰，常常試試看在例如 Twitter 這種限制長度的平臺發文，可以練習做到短捷有力。

言外之義：文法、典故、故事

文法定義時間、態度、語氣等意義

自然語言帶有很多歧義，中文尤多，例如有名的例子：

臺灣大勝韓國隊；臺灣大敗韓國隊，都是臺灣勝

英文文法比中文結構性，歧義少，而法語、德語文法繁雜，更少歧義。

聽說德語定義太清晰讓德國人不風趣，因為說不出雙關語，沒有言外之意的生存空間。

典故是對知識庫的索引

古代文人說話都要帶着典故，因為他們都讀差不多的書，一講彼此都懂，就是兩位知識儲備類似的人索引同樣內容的方法。

另一個用途就是把不具有這些知識儲備的人排除在小圈圈外。

故事用劇情和情境增加表達力

故事是用結構組合繁雜的事物，內含一個邏輯，或是世界觀，結構化以後，就算繁瑣，卻容易吸收記憶。

比如《阿凡達》拍攝前，主創團隊把故事裡的星球的生態做了 500 多頁百科全書，所有人腦中都有相同情境，才能拍出觀衆感動的電影。

市面上銷售的記憶法課程就這麼做，把無關事物編故事串起來。

小總結

利用文法表達豐富的時間態度語氣，用豐富的詞彙讓每句話都帶有意義，對複雜的事物，有時一句成語一個典故就能理解，而組合成結構性內容，讓人易於理解也不會忘記。

用這樣的方法，語言有更強的表達力，目的是減少歧義，一次生出想要的內容

結構性文件，解決複雜

前面提到的各種方法，似乎很難用語言表達出來，更難用缺乏結構的中文表達，而想要把這些內容都編碼進去，還要能表達要 AI 工作案子的來龍去脈（Context），結構性文件是個好方法。

心智圖，基本的結構性文件

知識圖譜沒有中心，是個網狀結構，如果把其中一個節點做中心，就是心智圖，心智圖忽略知識庫的複雜，取切片（圖：ChatGPT）

知識可形成知識庫，知識庫軟體可以幫你把知識庫用「知識圖譜」（knowledge graph）檢視，把它的其中一個節點做為中心就成了心智圖，可以這麼說：心智圖是知識庫的切片和壓縮。

心智圖是「線性」（前後關係已被鎖定）的，把它從圓形拉成長形，就像書的目錄。

大師腦中的知識不但是立體的、靈活調動的，而且互相連接，這就是知識庫，為了轉換成書這種「低解析度」的媒體，要把立體壓成平面、靈活變成線性、連結大多刪除，這還能反映大師的知識精髓嗎？莊子說聖人之書不過是「古人之糟粕」³，經過重重降維，大師的書已不能讓我們成為大師。

雖然心智圖是重重降維的結果，但它把複雜的 context 封裝起來，協助你迅速喚起很久以前某主題的回憶。

心智圖是幾十年的發明，已經普遍了，「結構化文件」就是這個樣子，它用「上下順序」和「前後點列」來表現邏輯，把瑣碎的事情組合起來。

對心智圖感興趣，請參考拙文：心智圖學社會 | 學如何學才是上學該學的

那麼心智圖是否能把前面提到的「言內之意」和「言外之意」都封裝起來呢？我覺得還不夠。

結構增加文字說明力

AI 讀圖形不擅長，但可以把心智圖轉換成 AI Friendly 的形式，例如轉成 Markdown 列表，下層節點是上層節點的補充說明。

因為是純文字，AI 易讀，但心智圖轉換 Markdown 的節點缺乏說明力，因為文字不含「屬性」（attributes, properties）。如果記錄的是你的記憶，它可以幫助你回憶，但如果給一位沒有相同經歷的 AI 就無法全懂，要它猜測就產生歧義。

那什麼是「屬性」？它是「形容資料的資料」，例如我在讀文章時讀到《莊子》這本書，我沒有讀過，把滑鼠靠近，跳出這本書的屬性：

作者：莊子, 王邦雄
出版社：立緒
出版日期：2000/02/05
語言：繁體中文
定價：200元
優惠價：9折180元

上述這種「屬性：描述」的資料格式叫做「鍵值對」（key-value pairs），冒號前叫「鍵」（key），冒號後叫「值」（value），為什麼要這樣呈現呢？例如博客來的每本書都有「作者」這一欄，就是相同的「鍵」，但每本書的作者的「值」不同：

書名	作者
《莊子》	莊子, 王邦雄
《原子習慣》	詹姆斯‧克利爾

如果把上表任意一格抽出來，就只有「值」沒有「鍵」，單獨看不知道是什麼意思，心智圖沒規定要輸入鍵值對，輸出結果可能像這樣：

《莊子》
- 莊子, 王邦雄
- 立緒
- 2000/02/05
- 繁體中文
- 200元
- 9折180元

《莊子》
- 莊子, 王邦雄
- 立緒
- 2000/02/05
- 繁體中文
- 200
- 0.90

你看，結構是有了，問題是只有值，AI 就要猜這值的意思。當然這例子看上下文就很清楚，但如果沒這麼清楚，很容易猜錯。

左邊的比較好猜。「2000/02/05」是日期，不過是出版日期還是購買收藏的日期呢？「立緒」是一個人還是出版社呢？
右邊的比較難猜（資料庫通常存成這樣）。「200」是什麼？「0.90」是什麼？

寫程式用的檔案格式，如 OPML、JSON、YAML，都要求輸入資料是「鍵值對」，像下面這樣，文字帶有屬性，意義清晰，AI 不用猜了。

《莊子》「作者 : 莊子, 王邦雄」
《原子習慣》「作者: 詹姆斯‧克利爾」

不同領域要有不同的鍵規劃

那就用心智圖轉出各種文件？好像不行，請看下例軟體轉出的結構性文件 OPML：

<outline text="《莊子》">
  <outline text="莊子, 王邦雄"/>
  <outline text="立緒"/>
  <outline text="2000/02/05"/>
  <outline text="繁體中文"/>
  <outline text="200元"/>
  <outline text="9折180元"/>
</outline>

HTML

它的鍵是為心智圖設計的，例如「text」、「hyperlink」、「note」，把它輸入心智圖可以恢復原有的心智圖，但全部的鍵都是「text」，AI 還是要猜。

每個領域不同規則，要定義自己的鍵，你不能把西洋棋規則拿去記錄足球吧！

收集某領域相關的鍵寫入規則，這文件就叫「Schema」（綱要，翻譯各式各樣，臺灣直接說英文）⁴，這概念抽象，如果你用 Notion 或 RemNote，可以把它想像成「模板」（Templates），因為它定義一個詞的各種屬性，你要把這些都填上，不就是個模板嗎？

科技行業多有人佛心地設計共通 schema，方便同行交流，如果你的規範只有你的團隊或甚至只有你一個人用，可以自己寫一個 schema，你怕 AI 不懂的話，當你用它寫結構文件時，把 schema 文件給 AI，它可以讀了再理解你的文件。

用哪一種文件格式更好？

Schema 有了，你可以用它來半自動寫一個文件丟給 AI 它就全懂了，問題是前面講了那麼多種格式，要用哪一種呢？我列了幾個條件：

具有鍵值對：AI 友善，就不用多說。
具有層級、巢狀：就可以做到像心智圖的結構。
人機都能讀懂：問題在我們，AI 總能看懂，我們覺得有怪符號的格式不容易看懂。
可以註解：特別注意事項，以後給自己看，或給 AI 看都行。

OPML

<outline text="書籍">  <outline text="莊子"> 
    <outline text="作者">莊子, 王邦雄</outline>
    <outline text="出版社">立緒</outline>
    <outline text="出版日期">2000/02/05</outline>
    <outline text="語言">繁體中文</outline>
    <outline text="定價">200元</outline>
    <outline text="優惠價">180元</outline>
  </outline>
</outline>

HTML

這個格式對人類不友善，一大堆符號和術語，還要把文字前後包起來，符號比本文還多，考量要用手工打字，不優。

它類似 HTML，可以寫註釋，但註釋的方式怪怪的，個人對 HTML 的規範是儘量別碰它，總之要打很多符號就是了。

JSON

{
  "title": "莊子",
  "metadata": {
    "author": "莊子, 王邦雄",
    "publisher": "立緒",
    "publication_date": "2000/02/05",
    "language": "繁體中文",
    "price": 200,
    "discounted_price": 180
  }
}

JSON

聽說 JSON 是最快速的，但電腦做什麼都快，問題是我這個愚拙的人類慢啊！我們才是瓶頸！（沒有人類 AI 可能早就征服火星了）

它的符號比較少，但還是有怪怪的 { } 符號、前後引號，和逗號，用 Excel 寫公式時，常常少一個括號就無法運作，找半天找不到問題在那裡。

還有一件奇葩的事，JSON 不允許寫註解，硬寫會跳出錯誤，那你寫完後一年打開，會想「我當初幹嘛寫這個啊？」，註解很重要。

YAML

- title: 莊子
  metadata: # 把 metadata 包在另一層
    author: 莊子, 王邦雄
    publisher: 立緒
    publication_date: 2000/02/05
    language: 繁體中文
    price: 200
    discounted_price: 180

YAML

YAML 的處理速度比 OPML 快，比 JSON 慢（不重要啊！）；沒有括號、引號、逗號；一個內縮就可以分塊，不用前後包起來；打一個「#」就可加註釋，程式碼讀起來像一篇文章；用清晰的鍵值對。

重點是手工撰寫時，跟打筆記差不多，內縮就按「Tab」鍵，像 Python 一樣簡潔，Python 被譽為最好閱讀的程式語言。

這麼多優點，所以到處都看到它，Docker 文件、GitHub Actions… 太多了，它改善了前兩者的缺點，成為人機都很懂的文件格式。

簡直完美！是不是？所以我選 YAML。

我做了 Web UI Components 的 Schema

我的工作有一大部分是網站和 App 等系統規劃。產品經理多用原型工具（prototyping tools）來規範網頁有什麼基本元件，例如最近火紅的 Figma，然後再交給設計師美化，兩個人類用繪圖軟體或輸出的圖片溝通效果非常好。

但圖對 AI 不友善，因為 AI 看文字的能力比昂貴的讀圖好，它有建議也不能操作 Figma 修改圖片，失去雙向交流能力，成效就打折了，它可以幫你把事情完善，用圖就自己封印了這功能。

我意外發現居然沒有人提供網頁元件的 Schema，例如文字輸入框、小日曆、按鈕…，於是我把它做好了，放上 GitHub 人人可用，如果對你有用，請造訪這裡 https://github.com/richblack/Web-UI-Schema ，有清楚說明。

如何使用

如果你不熟悉 GitHub, Visual Studio Code, YAML… 沒關係，我建議你下載 Microsoft Visual Studio Code 來寫作，這是可以安裝插件增加功能的文字編輯器，別因為名字有「Code」就很擔心，需要打字都可以用，做得很好速度很快，跟以往微軟肥大產品完全不同，我最近也用它畫心智圖。

這是我電腦中唯一的微軟產品，當然是開源的，因為它讓我對微軟這個惡霸企業改觀了一些。當然你用其他的工具也行，但要自己想辦法。

下載完 VSCode，要安裝一個 YAML 插件，再做一點小設定，請參考 GitHub 說明。

使用 Web UI Components Schema，你要在 VSCode 的市集中安裝 YML 這個插件，至於設定，請參閱 GitHub 說明

一般軟體有很多按鈕，但寫 YAML 檔都是文字的變化，Schema 加上 YAML 插件，可以幫你做幾件事：

Auto Complete：如果你要輸入的屬性存在，打頭一兩個字就跳出下拉選單，用選的就不會打錯字
Lint：會依照 Schema 檢查文件中是否有錯誤，滑鼠放上去可以看到錯誤的原因
說明：滑鼠放上去會跳出所有可用選項

因為 Schema 定義的規則很多很難記，有自動功能不易出錯，可在單一文件定義所有網頁，把檔案上傳給 AI，不費脣舌 AI 就幫你產出正確的頁面。

有了 AI 還自己做不是太累了嗎？對，你可以把 Schema 網址發給 AI，叫它幫我按照規範寫出想要的 YAML 檔，修改都叫它做，ChatGPT 和 Claude 可以在顯示文件頁面直接標示你覺得不對的地方叫它改，因為只是小文件，不會很快就把你的時數用光。

最後，滿意再叫它產生網頁就行了。

結論：為何要需求定義文件

我接過一個顧問案，運作快 10 年的科技公司，技術長換了好幾個，系統一套一套的開發，這時老闆發現，公司裡居然沒有一個人知道全部的系統可以做什麼！於是老闆要我回到 Day 1 把全部系統的規格書重新寫出來，真是個大工程。

這就是盤點啊！老闆發現有好幾台伺服器用不到，省了；
然後他把維護全外包，工程師拜拜，專注做生意就好了，省下五六個工程師的高薪；
少了一個大部門，老闆決定換小一點的辦公室，從新北搬到臺北，又省了；
人數少，疫情的衝擊就小，平安渡過；
這份文件讓老闆每年省千萬，事業做更大。

就像老房子發現馬桶不通，但不知道管線在哪裡，不能只修一段，只好全部打掉重做。如果你有蓋房子的圖紙，就直接修有問題的地方。軟體也是這樣，有文件可以參考，人事更迭的衝擊就比較小，因為程式會常常修改。

身為產品經理，我就是寫需求的人，從前需求文件常要寫一本厚書，我第一個大專案，A4 印需求書厚達 3 公分左右，用各種圖文想辦法描述我想要的結果，花了幾個月編寫，累翻了。

但是工程師都討厭寫文件，所以系統更新時，如果沒要求絕對偷懶，過一陣子需求就跟實際脫節了，此時工程師會勸老闆「寫這個太花時間太累了，別管它了，我們會弄啦！」，最後就發生上面那一幕。

但 YAML 簡單編輯就能保存複雜需求，純文字好改，每次修改叫 AI「同時改需求書」就好了，負擔很小，文件不過時。

工業界有 Pro-E 這種「參數式設計軟體」，幾十年前就做到從頭到尾所有環節編輯同一份文件。比如新開發手機組裝時裝不上去，工廠修改後，造型設計師依照零件修改外殼、機構設計師重新考慮結構強度、模具工程師考慮模流分析…。但軟體開發這個先進領域，卻沒有這種跨流程協作！

Bonus：整個服務都能寫定義

我寫的 Schema 只定義了網頁設計基本元件，系統當然不只網頁，有很多細節需要規範，可以全部用 YAML 規範嗎？可以！但需要很多不同的 Schema。

還好，多數 Schema 都有好心人寫好了，下面是一些做網站需要的公定 Schema。

資料庫結構：Prisma、Hasura。
API 規範：OpenAPI。
流程設計：BPMN、AWS Step Functions。
權限管理：RBAC/ACL。

有了這些好心人寫好的 Schema，導入你的 YAML，可以叫 AI 寫出需求，甚至用它變出程式！

參考資料

天下雜誌：「進行一個XX的動作」你得語言癌了嗎？https://www.cw.com.tw/article/5063162?template=fashion ↩︎
劇本課老師要求寫一個 10 集單元劇劇本，1）全劇用 40 字摘要；2）拆開全劇摘要，每集寫 40 字單集摘要；3）拆開單集摘要，發展多場戲。這是迫使自己精煉的練習。 ↩︎
https://uncle6.me/%e5%a4%a7%e9%81%93%e7%84%a1%e5%bd%a2 有興趣可以參考拙文，遠在戰國時代，莊子就說聖人之書不過是「古人之糟粕」，就是製酒剩下的渣滓 ↩︎
請見維基百科說明 https://zh.wikipedia.org/zh-tw/%E7%B6%B1%E8%A6%81_(%E8%B3%87%E6%96%99%E5%BA%AB) ↩︎

生成式 AI 精準生成術 結構性 PROMPT

減少歧義增加意義的思維

言內之義：詞彙的豐富性

言外之義：文法、典故、故事

文法定義時間、態度、語氣等意義

典故是對知識庫的索引

故事用劇情和情境增加表達力

小總結

結構性文件，解決複雜

心智圖，基本的結構性文件

結構增加文字說明力

不同領域要有不同的鍵規劃

用哪一種文件格式更好？

OPML

JSON

YAML

我做了 Web UI Components 的 Schema

如何使用

結論：為何要需求定義文件

Bonus：整個服務都能寫定義

參考資料

探索更多來自 六叔觀察站 | Uncle6 Observer 的內容

生成式 AI 精準生成術結構性 PROMPT

探索更多來自六叔觀察站 | Uncle6 Observer 的內容