-
從 Intent 到 Assertion #1, 聊聊 Vibe Testing 實驗心得
最近，起了一個小型的 Side Project, 想說先前研究 “安德魯小舖”，一年半以前就已經做的到用對話的方式讓 AI 替我執行對應的 API 的應用了，現在這些應用更成熟了 (每間大廠都在推各種 Agent 的解決方案..)，某天就突發奇想:
AI 都有自動執行 API 的能力了，那能不能拿來簡化工程師要寫 script 來做 API 自動化測試的任務?
會有這篇，當然是試出了一些成果了，就是我前幾天在 FB 發的這篇。這篇就是要聊聊 FB 沒辦法提及的實作過程心得，有興趣的請繼續往下看。在開始之前，複習一下我貼在 FB 的 貼文 :
-
用 WSL + VSCode 重新打造 Linux 開發環境
圖: DALL-E, 趕流行, 我讓 ChatGPT 搜尋我自己然後畫出來的形象圖..
TL;DR; 這篇只是心得文而已，記錄我把主要工作環境翻新成 WSL + VS code 的過程，跟背後追問題學到的冷知識..
–
因為越來越多東西需要在原生的 linux 環境下執行, 趁著更新 24H2，重灌 windows 的機會, 就一起認真的重整我的開發環境了。在 windows 下要以 linux 為主要的工作環境，用 WSL (windows subsystem for linux) 是首選，不過畢竟是跨 OS 的使用，也有不少障礙要排除。趁這次花了點時間研究作法，同時也惡補了一下 wsl 的相關背景知識，這才發現 Microsoft 對 WSL 下了不少功夫啊，背後藏了很多不錯的巧思。
在這篇，我會交代我的作法，同時我也會整理一下我找到的參考資訊，以及背後架構與限制。我最想解決的問題 (也是我的動機) 是這幾個:
- 我想拋開 docker desktop for windows:
太多我不必要的東西了, 授權的限制也是原因之一。其實我用的功能不多，改成直接在 linux 下執行 docker 還更單純，少了一堆束縛，跑起來也更輕鬆愉快 - 我想避開 docker 掛載 volume 的 IO 效能低落問題:
目前用法，在 windows 下執行 docker, 掛載 volumes 的 IO 效能很糟糕 (糟到用不下去) - 我想在 docker 使用 GPU / CUDA 應用:
目前在 windows 下跑 CUDA 困難重重，我只是想爽快地跑 ollama 啊… 我想要把 AI 應用都搬到 docker 環境下去執行, 支援 GPU 的 docker / linux 環境是必要條件 - 我想建立一個 linux 為主, 能長期使用的通用工作環境:
並且能無縫的跟我慣用的 windows 環境整合在一起。常用的工具就那些，包含 visual studio code, git, dotnet 等，能高度整合 windows, 不需要花太多心思在兩套系統間的協作，認知負荷越低越好
花了一個禮拜的下班時間，我總算把我的工作環境打造好了。過程中也發現不少 Microsoft 藏在 WSL 裡面的黑科技。自 WSL2 推出以來，這幾年相關的整合也都成熟了，我就野人獻曝，分享一下我的整理心得。
- 我想拋開 docker desktop for windows:
-
從 API First 到 AI First
這篇的內容，是我在今年 DevOpsDays Taipei 2024 擔任 Keynoye 演講 + 時間不夠被我略過的部分寫下來的文章。延續 2022, 2023 談的 “API First”, 延伸到 AI 應用程式開發，正好銜接到我半年前在研究的 LLM App 時寫的三篇文章內容, 這次投稿就用了這標題 “從 API First 到 AI First” 來聊聊這內容。
各行各業的每個環節, 大家都在想怎麼善用 AI 與相關工具了, 不過開發人員把它當作服務或元件，用在自家的產品上的案例就少得多。我自己是軟體開發產業的人，我的角色是架構師，我看到的是: AI 是個強而有力的元件，只要掌握清楚它的特性，就有機會在你的應用程式好好的利用他，而這也是這半年間，我下班時間都在摸索的事情。我驗證過好幾種想法，在那段時間我的 ChatGPT plus 的額度每天都被我用光了，到現在也算是有點心得，於是就有了這個主題，也有了這場演講 & 這篇文章。
這整篇的心得，其實摘要起來只有一段話，就是:
未來 AI 充分運用在各個領域的年代，你現在的軟體開發基礎只會越來越重要。
要確保未來 AI 盛行的世代還保有競爭力，請把基礎的功夫做好。 -
替你的應用程式加上智慧! 談 RAG 的檢索與應用
來源: 動畫瘋, 不起眼女主角培育法 S1.EP2, 這動畫一定是在談 embedding space (咦?)..
LLM 應用開發，來到第三篇。這篇我想談談 LLM 應用程式處理資料的做法。在 LLM 帶來很好的語言理解能力後，這需求也延伸到資料處理 (資料庫) 的領域了。這些過程跟我過去理解的資料庫正規化等等技巧，完全是不同領域啊，為了補足這段空缺，前兩篇研究完 LLM 如何替你呼叫 API 完成任務後，這篇我想以同樣角度，研究讓 LLM 能幫你找出並應用你的 DATA 的作法了。在軟體開發的領域，行為跟資料同樣重要，一直都是開發人員關注的兩大主題。補完這篇，我覺的對整個 LLM 應用開發的版圖就完整了。
這次我拿我自己累積的文章為主的應用: “安德魯的部落格 GPTs” 來示範吧。我希望能藉著 AI 的力量，讓我的讀者們能更有效的運用 (我期待不只是閱讀) 我的文章，來解決各位開發設計上的問題。我的部落格，一直是我過去 20 年來不間斷持續維護的 side project, 我除了改善系統本身之外，也不斷地在累積文章內容，因此不論文件的質、量、儲存格式等等，我都有十足的掌控能力，拿來做這次的 PoC 再適合也不過。
-
替你的應用程式加上智慧! 談 LLM 的應用程式開發
圖片來源: DALL-E, 這篇都是過年期間的研究心得, 就用龍(年) + 未來都市當主題吧
上一篇文章 架構師觀點 - 開發人員該如何看待 AI 帶來的改變?，展示了我嘗試的 安德魯小舖 GPTs 整合應用，實現了讓 AI 助理的嘗試，我開始真的可以用自然語言就完成整個購買流程的操作了。過程中，AI 也幫我 “腦補” 了部分我 API 沒有提供的功能 (指定預算跟購買條件，AI 自動幫我思考購買組合)。這結果其實比我預期的還理想，完成之後，我開始探索接下來的這兩個問題:
- 未來的應用程式，會怎麼運用 “AI” ?
- 未來軟體開發的流程與角色，會變成甚麼樣貌?
因此，這篇我就要面向應用程式的開發面，來探討該怎樣把 “智慧” (我暫時把 “智慧” 解讀為能理解語意的能力，拿 LLM / Large Language Model / 大型語言模型 當作代表) 加到你的應用程式內。雖然目前 LLM 還有很多缺點，但是應該開始把 LLM 當作 “人” 來看待了，溝通的方式都要把它當作 “人” 的方式溝通 (因此要善用 prompt, 而不是 function + parameters)。這其實跟傳統的軟體開發結構完全不同，也是我這篇想繼續往下挖的主題。
