積沙成塔，滴水穿石

身為不同模型都要能夠使用到它的最大效益的人，A模型使用體驗的額度到達上限後，就會切玩到B模型...依此類推。 以現在的專案製作方式，在AI上就能分成好幾角色，組成一個團隊來製作專案，同時並行達到多工，發揮出最大效益，省下的不少時間。 寫好規格，剩下就是請master分派給其他slave(AI)，執行事情就交給其他slave，人就繼續和master討論。 一個AI(小明)的聊天會有上下文上限，連帶的每次使用的token會很多，另一個困擾點是 切換成 其它AI(小華) 並不知道，我與小明的討論決定。 那為了解決這個困擾，就把決策點保存下來，每一個agent去讀這份文件，就能知道上次的決策點，一來也能降低token上下文的使用，也能有在其他AI 互有共同的對話記憶。 無論是原本的master，也能請其他的slave，變成master，替換大腦的概念。 今天claude 聊天也能共享給grok、chatgpt 架構網址:  https://dogr2487php7.pintech.com.tw/knowledge-base/

在寫spec 規格文件，有的時候有點偷懶，會請AI 輔助寫SDD文件，但寫出來的SDD 文件仍有需要調整的地方。 AI 寫出來的SDD 文件有的時候會過分設計(overdesign)，最後就先收斂個MVP版，但寫出來的MVP 又太去蕪存菁，有時會把原本要做的功能又過濾掉，這樣幾次之後就在反問AI 為甚麼會這樣想，得到的回饋是 我誤會了! 😅。 在後來則是先請AI 先審視現有文件，再去針對需求檔 寫擴增文件，最後三者交叉比對，最後在團隊開會。(圖1) 圖1. 流程優化 架構表+需求表 ──→ AI整理SDD ──→ [Day1: PM快速審] ──→ MVP版 ──→ 交叉驗證 ──→ [Day3: 全團隊簽]        ↑                                                    │        └────────── 個人優化循環 ───────────────────────────┘我 團隊開會的功能，腦力激盪的時間！(圖2) 圖2.團隊開會 再進一階，做任務表儀表板(圖3)。 做TDD 檢測(圖4、圖5)。 圖4.TDD 測試 圖5.TDD 測試 自動寫E2E測試，真是輕鬆多了(圖6、圖7) 圖6.自動E2E測試 圖7. 測試清單儀表板 任務追蹤表(圖8) 圖8.任務追蹤表 -------------------------------- 使用心得:  有AI 真的是方便~ AI完成了所有後台CRM，開始跑就監控、校正、驗證，最後執行的時候就可以開啟subagent，請主master AI 去驅使多個subagent來使用，多工並行，並主動回報任務。 

 今天做一個內部SQL簡易查詢器(圖1)，出發點是在做簡單的查詢，不需要再到SQL工具查詢，可以直接透過 web 直接「簡易查詢」，但因為安全性的考量，適合在內部環境使用，再沒有綁定SQL金鑰 也只想做 簡易select SQL，ex: 客服、內部遠端主機。   圖1.內部SQL 簡易工具 當今天要做簡單的SQL 查詢DEBUG， 就可以直接從內部工具查詢。 當然只限定SELECT查詢(圖2)，如果輸入非select 字眼 就是會擋掉。 圖2. 限定SELECT 查詢 題外話: 進到這個頁面，也是需要輸入動態密碼。每1天 就是更新一次動態密碼。(圖3) 圖3. 動態生成密碼&404狀態頁

 最近做了一個研究，在製作產品前先進行市調與分析。 調查同類型在市場上的情況、延伸服務型的價值效益在哪裡？ 剛好看到一個覺得很有趣的內容，Line PNP，它會去比對line 的資料庫手機， 向SNS 一樣，發給用戶 ，主要是從  LINE Official Account 發送，也就是官方認證的帳號，所以簡訊可信率也很高，不是 好友 也能主動收到通知，但不能用於廣告行銷投放，會有審核 。(圖1) 圖1. LINE PNP 比較常用在的地方，就是 包裹的通知、賣場貨到通知，一些比較重要的通知。(圖1) 圖2. 通知型訊息(line PNP)

最近接手的專案，它的底層用bootstrap3.4 來撰寫。 bs3.4 的一些css utility 已經太舊了， 在使用上沒有bs5 來的方便。 所以就只好compile  bs5.3 向下兼容性的。 在基礎上 還是保有bs3.4 的功能，ex: <p> 、<a>  、.col-lg-3  這次的向下兼容改版不好改，有些地方需要修改底層加入特殊prefix，前提是不能影響既有bs3框架。 這次就用了postcss 來幫忙做css 後處理 SCSS 程式碼撰寫 → Utility 前綴撰寫→ PostCSS→ 最終 CSS 輸出 現在是只要加入bs5- 前綴 就能使用bs5 的語法，幸好bs5 寫得很多是變數，所以在使用postcss 改， 會比較輕鬆

最近做了一個案子，打算做的是顧客與店家的聊天小幫手。 第一版做的雛形，是AI 智能回覆 動態產生SQL ，可以做智能查詢，依照顧客想要的查詢。 自己設計了幾次下來，發現在測試階段，智能回答問題就花了不少token，有的時候回答準度還是很差。 在開會時，收到了意見回饋「客人會花錢買單使用智能客服嗎? 效益在哪裡 ?」 闆: 「還是先做成傳統的linebot」。 --------------------------------------------- 思考了一下之後， 我打算做個「微智能客服」。 在程式邏輯流程的API 還是先寫好固有的API、SQL。 整理歸類好的意圖分類，當顧客詢問的時候，先透過NLU 去做意圖分類，讓問題落在意圖分類之間，再去觸發固定的API、SQL。 之後再收斂回答的信心度校準、語意相似度輔助、模型和技術優化、 定期重訓練。 ---------------- @@  根據現有的資料庫及客服的回饋，再加上以往的經驗，能做的標籤及意圖分類就需要花些時間做整理了。

 最近用python + LINEBOT +AI +資料庫做了動態的智能客服💖💖。 底層的模型選用gemini-2.0-flash-thinking-exp，SQL 的架構採用混和的，分為AI動態產生、既有固定的SQL，之後可側錄使用者行為避免重複性高的SQL 會一直動態產生。 AI 動態查詢範圍設定為: orders(訂單)、users(顧客)。 目前的上下文記憶採用5回對話，短期對話記憶20分鐘TTL。 有做了標籤化來增加上下文的關聯性、信心比率的回覆。 目前測試下來，有的時候上下文的問題，會無法回答正確、對於問題描述後的輕澄清的信心比率還不夠，既使回答完問題，AI還會加入輕詢問(圖1)。 對話紀錄(圖1) 目前的標籤採用的是手動標籤，AI會去評估問題是在哪個標籤(圖2)。 對話紀錄(圖2) 之後再優化用NLU來做標籤分類、區分標籤，應該能改善有時回答失效的問題。 成果影片： https://mega.nz/file/tp0k1RJJ#9G3tCjcM3iVg_VEfTEcb6l7K5JHLU9Pe5GV3LEz-GEc 心得： 我也沒想到能夠做出來，但至少能夠客製化智能AI、會依據資料庫的東西再去思考與分析回答。 滿好玩的，把以前研究所快忘記的東西都呼叫回來，langchain 真的很好用。 要改善智能回答到優化，還有很多功夫要做。👊 一步一步改善啦~💖