AI, CLI 程式, 與 DSL
feedback loop 與資料驅動程式設計
客戶告訴我，他跟我一樣，用 AI 來輔助做投影片，但不一樣的地方是，他把 token 一度用爆了。我想，怎麼可能呢？多問了一下，我才搞懂，原來我們兩個人應用 AI 的方式不一樣。
客戶的應用方式：
準備素材。
叫 AI 整理一下素材。
叫 AI 根據素材，生成對應的投影片。然後，對不滿意之處反覆調整。
我的應用方式：
將我的文字整理成 marp CLI markdown 的格式、圖
反覆 AI 對話，改文字、編修文字、調整圖的控制語法。
用 marp CLI 來生成對應的投影片。
這兩種應用方式，有個關鍵差異：
我的應用方式，讓 AI 的 feedback loop 相對很短，因為 AI 不需要把內容轉成投影片，少了一段工作。而且 AI 的輸入與輸出，都是純文字的 marp CLI markdown 格式，這也節省了許多的 token 。
CLI 程式與 DSL
上述的這種應用方式，對某些 IT 專業人士來講，應該是直覺到不行，對一般人來說，卻不太容易想到，需要更多的想象力。仔細想想，我似乎也是在某個時刻，才把這個觀念打通的。
二十多年前，在我大學一二年級時，學校主要教 C++ ，同時，我參加大專 CAD 競賽時，官方也是要求寫 C/C++ 。那時真的很多應用，我第一時間在思考自動化，就是用 C++ 去想。
有一回，我的一個朋友，他的 word 文件裡，有極度複雜的文字編輯工作，沒有辦法用單純的『尋找/取代』完成時，我第一時間思考的方式，也是在想：「我有沒有可能寫程式，讀取所有的字串，然後，把編輯的複雜規則都在程式碼裡做完。」
這個想法當然是失敗了，因為開發 C++ 程式實在太慢了，不實用。
而後來，我多學了很多東西之後，遇到類似的問題，我會考慮：
用 regular expression ，這樣子的話，就容易表達更複雜的字串處理邏輯。
用 Linux 上的 shell script 拼裝一些工具來做，比方說：sed, wc, awk, tr 等。
這個故事跟上述的 AI 應用有關嗎？有的。
某種程度，如果一般人隨意地啟動 Claude Cowork ，並且對 AI 下指令，AI 解決問題的方式，往往就是暴力地直接寫程式來處理，通常是 Python 。Python 已經不算是太消耗 token 了。然而，如果使用者給的檔案格式，又是 word 又是 excel 的話，AI 的讀取與輸出，全部都要不停地寫程式，那 token 的消耗量自然就大了。
另一方面，如果叫 AI 做事，一方面指定了純文字的格式，又引導 AI 使用一些 CLI 程式，讓 AI 的輸出、輸入都是 DSL (domain specific language) ，那 AI 的 feedback loop 自然大幅縮短，token 的效率也就提高了。
更深層的連結：資料驅動程式設計
上述的概念，其實還可以連結到資料驅動程式設計 (Data-driven programming) ，這是在 The Art of UNIX Programming 一書提到的概念。以下是書中的一段話：
UNIX programmer 習慣於寫「語法解析器的規格」來生成「語法解析器」，好用來處理「標記語言」。因為做完語法解析器之後，剩下的工作就是對配置文件來做一般的「樹走訪」就可以完成了。要漂亮地解決問題，需要資料驅動程式設計的兩個階段來達成，而其中一個 (樹走訪) 建構於於另一個 (語法解析) 之上。
在上述引文裡的「標記語言」可以有很多不同的形式：
marp CLI markdown
regular expression
這些「標記語言」都是 DSL 。
在實務的應用裡，DSL 的出現，對我來說意味著，工作可以分割成兩個階段：寫作 DSL 的部分可以交給靠近商業端的人，執行 DSL 的工作可以交給靠近工程的人。
長久以來，寫作 DSL 的工作，由於沒有 AI 輔助，常常還是留在 IT 工程師身上。在 AI 流行的時代，應該可以交更多出去吧？
附帶一提，你有在處理資料倉儲或是 Excel 嗎？如果對本篇文章的概念有興趣，可以參考我的書《從試算表到資料平台》，這本書介紹了 Modern Data Stack 的概念，它會讓你對 SQL 這種 DSL 的應用有新的看法。