-
刻意練習: Design for Safe Testing
我平常會習慣捕捉工作上看到的 “難題”, 覺得有意思, 有研究價值的, 就會挑出來親自想個情境 PoC 練習解題, 這是我快速獲取經驗的方法, 直接面對問題, 排除不相關的環節, 是我嘗試過最精準且有效率的學習方法｡ 這次碰到了一個新的題目, 就是怎麼有效率的在有正式資料的環境進行測試? 過去工程師的直覺反應就是: 蓋一個測試環境, 然後把資料搬過去…, 但是困難的是這 “資料” 的維持是個很高的開發跟同步成本, 從 infra 的角度切入, 實在沒有太理想的解決方案, 於是, 過去為了解決維運問題我都傾向直接變更設計, 讓你的服務 “天生” 就更好維運的角度設計 (design for operation), 今天面對這問題, 我能否也可以 “design for safe testing” ?
這問題的重要性, 不知不覺的被 agent 放大了, 所以我才開始重新在意這個問題｡ 最近我都在研究 design for agents 的軟體設計, 影響 agent 行為最大的因素是 context, 而不是過去傳統資訊科學談的資料結構跟演算法… , 當 agent 要代替你操作某套系統 (我拿先前的 Andrew Shop 當案例), 那什麼是操作這系統關鍵的 context ? 就是你系統背後累積的 data, 當你沒有 “完整” 重現這些 context 的時候, 你是測不出 agent 預期的行為的｡ 單純的功能測試, 有規則可循, 你可以按照情境建立能呈現預期結果的測試資料, 但是 for agent, 就沒那麼容易…, 你至少必須把整體的資料對齊, 到能合理的執行 evaluate 的程度才行…
回過頭來, 目的還是測試環境 + 資料的準備方式, 我決定從搞清楚 “測試” 的意圖開始, 我想走的路線是如何安全的在既有的環境測試, 而能隔離測試造成的影響 (這樣我就不用一直清除測試資料或是重建測試環境) 為主要的執行方向｡ 我研究了幾個業界的實作案例, 定義自己想要的 “測試” 的邊界跟原則, 最後拿我自己的 Andrew Shop 當作實驗場所實際做一次重構, 驗證結果並且留下的記錄文章｡
這個 side project, 是延續先前我在 DevOpsDays Taipei 談的案例, 做法也是延續這個場次提到的 Core Context 做法, 你可以把這篇的內容當作這場演講的延續, 也可以獨立看 Test Mdoe 這個課題來看待.
-
AI Era, 架構師的注意力該用在哪裡?
今年六月底, 忙完兩場演講 (DevOpsDays Taipei 2026 Keynote, Generative AI 開發者年會 2026), 把我上半年的所有研究都交代完了｡ 過程中得到不少現場參加的朋友給我的回饋, 最熱烈的是 DevOpsDays 會後, 找我聊我示範的 side project: Andrew Shop 的執行方法｡ 其實這本來只是單純的架構設計難題驗證而已 (交易系統, 要標準化, 又必須滿足高度客製化的要求), 只是我 “順手” 用了我覺得 AI coding 應該要有的樣子來執行而已｡
這篇, 我換了另一個案例當作練習, 我挑的題目是:
需求規格 我的系統有很多操作需要計費, 而計費的機制我希望做的像 Claude Code 的使用量限制那樣的規則, 有每 5 小時, 也有每 7 天的額度限制, 超過額度可以選擇從儲值的點數扣除｡ 系統上的要求則是我只能用 SQLite, 設計上我想盡量降低 database 處理交易的負擔｡
我改用這個案例, 重新用我在台上分享的流程來做一次, 並且把過程記錄下來, 讓大家親自體驗跟直接不經思考就把需求扔給 AI 開發的差別｡ 這些過程跟步驟, 我在台上其實沒機會好好說明 (畢竟我的場合是演講, 不是工作坊), 所以我把這段用文章形式放在這裡, 有興趣的人可以參考~
-
AI-First Testing, 以 AI 為核心重新設計測試流程
不知道要找啥當 Logo 了, 這次就放 NieR Automata 吧, 一個操控 AI (2B, 9S and A2) 的 context window 到極致的故事… (咦?)
–
首先, 我自己打臉我半年前寫的那篇 聊聊 Vibe Testing 實驗心得 的文章｡ 其實那篇文章研究的 “自動執行 API 測試” 是可行的, 但是應該拿來探索測試步驟用, 而不是拿來當最終重複執行用｡ 當時我的思路是:
” 現在的流程太花人工了, 那我讓 AI 替代人工來跑測試吧 “
結果, 不知不覺就掉到這 “局部最佳化” 的陷阱裡.., 手上有威力很強的新武器, 我卻還在用傳統作戰的戰術去運用它… 有效是有效, 但是總覺得沒有完全發揮出應有的戰力…
所以我在想, 如果我重新設計工作流程, 是否這一切都會變得簡單且有效率? 因此重新想過一輪之後, 這篇我想談:
” 從 AI 的能力出發, 重新思考 “測試” 這件事應該怎麼進行? “
這陣子思考 + 嘗試實作, 有了一點心得, 我換了個方式拿 AI 來進行軟體測試, 這次的效果比我預期的好, 於是就有了這篇…｡
-
心得 - Emerging Developer Patterns for the AI Era
忙完了我自己部落格的重構 (上一篇), 開始補一下還沒寫的文章了。這次是補之前只在 Facebook 分了多篇分享的創投趨勢報告讀後心得。趨勢報告都會用很客觀公正的資訊 & 數字來告訴你那些事正在發生。但是這樣看起來很冷冰冰，對這領域不夠深入研究的人，其實難以想像背後到底發生了什麼改變。
我的心得就著重在看懂背後發生的事情，並且舉了很多現在我觀察到正在改變的實際案例當作參考，等於是換個角度更具體地描繪了改變會怎麼發生，以及發生在哪裡。
在 Facebook 上的 PO 文限制蠻多的, 格式有限 (我怎麼都沒辦法用 markdown 貼文?), 還不能有連結… 貼到部落格後就順手補上這些細節問題了。這篇集合了我先前分散在 12 篇 Facebook PO 文的內容, 修正的格式等等部分我就不特別標註了，我在整理當下額外加上的註記則有特別標示。另外，在 Facebook 上仍有些值得參考的資訊, 例如其他朋友在底下的留言, 以及有些人分享我的 PO 文時會加上自己的觀點，這些都還蠻值得參考的。因此我特別把 Facebook PO 文的連結跟基本的統計數字也列出來，方便查閱。
-
讓 Agent 懂我的部落格: MCP-first 的服務化設計
圖: 實在想不到要放什麼圖當封面了, 突然聽到這首歌, 有 AI 又有 Code, 就決定是妳了… XDD–
過去，我在寫部落格文章的時候, 總是有個難題: 當題目我越挖越深入的時候, 即使我有能力交代清楚來龍去脈跟思考過程, 但是對讀者而言, 從 “看完文章” 到能理解並且能 “用來解題” 的過程往往都很漫長，中間隔著好幾道門檻。
我曾經暗地嘗試過幾種做法，包含:
- 不要寫那麼長的文章 (結果是最重要的心法沒交代到位)
- 只寫操作步驟跟範例 (我寫的又沒別人快, 只想找操作步驟的根本不會看我文章)
- 拆成好幾篇分開寫 (結果是讀者不一定每篇都看, 時間間隔太久, 看了後面忘了前面)
結果都沒有解到痛點，最後還是回到原本的寫法，篇幅拉的很長，但是都把重要觀念交代清楚。不過，現在有 AI 了，我覺的這題應該會有更漂亮的解法才對。我閃過的念頭是:
”
如果可以開發一個專屬我部落格的 MCP, 把我的部落格重構成一套可以被 Agent 充分運用的 “工具與素材”。這些素材 + AI 的理解能力，應該能讓這些門檻降低，直接用在寫文件，系統設計，或是撰寫程式碼應該都是可行的才對。
“因為我覺得軟體服務的未來, 一定是走向使用者高度與 Agent 互動，因此軟體服務開始提供 MCP, 就跟過去軟體服務提供 API 一樣，是個必然的發展路線了。因此，我挑了這個題目: “Chat with My Blog” 當作目標, 來啟動這個 MCP 開發，跟部落格重構的 Side Project. 這正好呼應九年前我部落格系統大改版的紀錄 “Blogging as Code!!” (2016/09/16), 做個對照。九年前是完全放棄 “系統”，改以靜態內容為主的改版；現在則是把被動的靜態內容，轉換成主動與 Agent 結合的服務。