雖然網路上常笑著說重開機治百病，但現實總是會遇到許多奇奇怪怪的事情，並沒辦法用重開機暴力解決。雖然現在有 Google 搜尋還有 AI 輔助，但建立保持著求知慾，主動學習新知，了解遇到問題的背後原因與原理。
與 AI 討論問題求解很方便，但需要像我們審閱 Google 搜尋的結果頁面一樣，我們自己需要去判斷這些回覆是否合理，因為最後決定是否採取行動的是我們自己。之前在網路上有聽過一些故事，缺乏足夠知識的職員在工作時未經求證，便拿著 AI 產生幻覺的回答去挑戰專業人士的建議。當我們有去了解到 AI 這個工具的原理與注意事項後，對這些故事只會無言，用不負責任的態度使用工具與對待同事，把 AI 當作藉口取得權威，這樣不是頂好的。
雖然我常常提到 AI 工具，但在查找資料時我自己還是以 Google 搜尋居多，只有當遇到陌生領域的問題或需要一些靈感時，我才會跟 AI 來回討論，也會審閱 AI 提供的參考連結或自己再次搜尋做比對。
很酷的一位工程師，貢獻了許多開源專案。我的 Blog 就是使用他貢獻的 Hugo 架設的。
💡 一条FPC排线的故事，让你知道软件和硬件的差别
故事一：https://x.com/manateelazycat/status/1965219025174364330
故事二：https://x.com/manateelazycat/status/1965220051105304630
如果沒有足夠的專業知識，很多硬體的問題看起來很玄，沒有一些契機還真不知道怎麼排查。這讓我想到了一則以前看到的故事《每天早上七點固定斷網 英國小村找到罪魁禍首》。
Context coding 比 Vibe coding 更符合現在大家使用 AI 工具開發的情境。AI 工具竟可能地從我們的專案中找出與請求相關的程式碼或文件，交由 LLM 透過 MCP 與 Tool 來產生回應與執行動作。除了在輸入框中提供更精確的提示詞之外，大廠的實踐建議也提到在專案中放置如 guideline 或是 coding style 的文件，讓 LLM 每次都依照這些規範來進行思考與限制回應格式。
作者在文中分享對於 Context coding 的一些技巧和經驗。在商業上，驗證想法的成本更低了，透過 AI 工具可以更快速地產生 demo 程式，將時間用在實現通過市場驗證的想法。
我以前覺得coding是科學，可以我越來越覺得是玄學，這樣是正常的嗎？