生成式 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…，這種「萬用動詞」，我稱為「虛詞」或「虛動詞」。
  - 中文不假思索說出來的話，通常充滿虛詞，例如「『下架』被講成『進行一個下架的動作』，『了解』成了『做一個了解的部分』1」，虛詞多到變成「語言癌」了！
  - 如果發簡訊限制 40 字2，就會斟酌去掉「虛詞」，例如一篇貼文：
    - 虛詞版：「萬事問臉書：臉書每天發一大堆亂七八糟的貼文內容糟糕很討厭，求問要怎麼樣讓它停止？」
    - 精簡版：「防臉書推薦可憎貼文，關閉、檢舉，還是封鎖？」
  - 不討論個人喜好，精簡版雖短但表達更多意義，例如：
    - 定義了臉書的行為：不是「發文」而是「推薦」，人家就不會問「是什麼發文？」
    - 定義對這種行為的態度：不是與我無關的內容，而是有關且有態度—-可憎
    - 定義了回覆選項：不只問怎麼辦，而是有選項讓人好回覆。
  - 不用虛詞才能定義清晰，常常試試看在例如 Twitter 這種限制長度的平臺發文，可以練習做到短捷有力。
- 言外之義：文法、典故、故事
  - 文法定義時間、態度、語氣等意義
    - 自然語言帶有很多歧義，中文尤多，例如有名的例子：
      - 臺灣大勝韓國隊；臺灣大敗韓國隊，都是臺灣勝
    - 英文文法比中文結構性，歧義少，而法語、德語文法繁雜，更少歧義。
    - 聽說德語定義太清晰讓德國人不風趣，因為說不出雙關語，沒有言外之意的生存空間。
  - 典故是對知識庫的索引
    - 古代文人說話都要帶着典故，因為他們都讀差不多的書，一講彼此都懂，就是兩位知識儲備類似的人索引同樣內容的方法。
    - 另一個用途就是把不具有這些知識儲備的人排除在小圈圈外。
  - 故事用劇情和情境增加表達力
    - 故事是用結構組合繁雜的事物，內含一個邏輯，或是世界觀，結構化以後，就算繁瑣，卻容易吸收記憶。
    - 比如《阿凡達》拍攝前，主創團隊把故事裡的星球的生態做了 500 多頁百科全書，所有人腦中都有相同情境，才能拍出觀衆感動的電影。
    - 市面上銷售的記憶法課程就這麼做，把無關事物編故事串起來。
- 小總結
  - 利用文法表達豐富的時間態度語氣，用豐富的詞彙讓每句話都帶有意義，對複雜的事物，有時一句成語一個典故就能理解，而組合成結構性內容，讓人易於理解也不會忘記。
  - 用這樣的方法，語言有更強的表達力，目的是減少歧義，一次生出想要的內容
結構性文件，解決複雜
- 前面提到的各種方法，似乎很難用語言表達出來，更難用缺乏結構的中文表達，而想要把這些內容都編碼進去，還要能表達要 AI 工作案子的來龍去脈（Context），結構性文件是個好方法。
- 心智圖，基本的結構性文件
  - - 知識圖譜沒有中心，是個網狀結構，如果把其中一個節點做中心，就是心智圖，心智圖忽略知識庫的複雜，取切片（圖：ChatGPT）
  - 知識可形成知識庫，知識庫軟體可以幫你把知識庫用「知識圖譜」（knowledge graph）檢視，把它的其中一個節點做為中心就成了心智圖，可以這麼說：心智圖是知識庫的切片和壓縮。
  - 心智圖是「線性」（前後關係已被鎖定）的，把它從圓形拉成長形，就像書的目錄。
  - 大師腦中的知識不但是立體的、靈活調動的，而且互相連接，這就是知識庫，為了轉換成書這種「低解析度」的媒體，要把立體壓成平面、靈活變成線性、連結大多刪除，這還能反映大師的知識精髓嗎？莊子說聖人之書不過是「古人之糟粕」3，經過重重降維，大師的書已不能讓我們成為大師。
  - 雖然心智圖是重重降維的結果，但它把複雜的 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：
    - - - - - - -
  - HTML
  - 它的鍵是為心智圖設計的，例如「text」、「hyperlink」、「note」，把它輸入心智圖可以恢復原有的心智圖，但全部的鍵都是「text」，AI 還是要猜。
  - 每個領域不同規則，要定義自己的鍵，你不能把西洋棋規則拿去記錄足球吧！
  - 收集某領域相關的鍵寫入規則，這文件就叫「Schema」（綱要，翻譯各式各樣，臺灣直接說英文）4，這概念抽象，如果你用 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) ↩︎

📚 相關文章