AI 工具幾乎每天都在變，現在學會的東西，明天還有用嗎？

標題是我最近講座時，最常被問到問題。

老實講，以現在工具發展的速度來看，就算我們拼盡全力學習，也不可能全部掌握。

而且就算掌握了工具的最新技巧，真的等於工作能力變強嗎？

如果換一套工具，過去學習的方法能辦法轉移過去嗎？

這堂課會以 Claude Code 作為主要示範工具。

但不管你平常使用的是 Cursor、Antigravity，還是 Codex，都可以跟著一起操作。

因為我設計這堂課，是以「完成專案」為目標，工具只是在實戰過程中自然掌握的能力。

工具應該讓大家學以致用，而不是靠大腦死記硬背。

我會著重分享 Rules / Commands / Agent Skills 的具體應用，因為這些技巧，在主流的 AI Agent 都有相似的概念。

也就是說，切換到新工具時你不用重新學一遍。

甚至可以透過 npx @dean9703111/dotagents建立不同工具之間的軟連結（symlinks），讓規則集中管理。

這樣只要修改一次，就能同步套用到不同工具中，讓維護更輕鬆。

面對生成式 AI 結果的不確定性，我們也不能只靠感覺驗收。

所以我會搭配 Lint 與 Unit Test，來確保專案基礎品質。

Lint 可以規範程式碼的 Coding Style，初步過濾冗贅、格式不一致，或不符合團隊規範的程式碼。

Unit Test 則能幫助我們在功能新增或修改時，確認是否影響既有邏輯，並在錯誤發生時更快定位問題。

當我們把 Lint 與 Unit Test 放進 Pre-Commit 與 CI/CD 流程，很多問題就能在進入主分支前被擋下來。

考量到大多數人不喜歡寫文件，或者不知道規格該如何撰寫，

所以我會帶大家了解如何用 OpenSpec 生成規格文件，讓 AI 執行的每一步都有明確方向。

它不僅幫你從 0 到 1 建立系統，更重要的是，這些文件讓後續每一次功能迭代都有依據。

在多人協作、長期維護、持續迭代的專案，文件不只是寫給人看的，也是 AI 理解專案的基礎。

每個人（團隊）在開發時都有一套工作流。

但當專案有時程壓力時，我們容易「先求有，再求好」，然後留下一堆技術債。

此時我們不妨反過來思考：

能不能把這些重複發生、又容易被省略的工作，設計成可以讓 AI 穩定執行的 Skills？

例如：

這樣就能讓我們把注意力放在驗收「結果」，而非消耗精神的「過程」。

在人人都能用一行指令生成系統的年代，「軟體工程」反而變得更加重要。

因為有好的地基，AI 才知道該照著什麼規格開發、用什麼標準驗收、依循什麼流程交付。

如果需求是模糊的，規格是破碎的，測試是缺席的，那 AI 生成得再快，也只會成為後續維護的負擔。

所以這堂課想帶給大家的，是如何把 AI 放進真實開發流程裡，建立一套穩定、可維護、能持續迭代的實務工作流，而不是停留在一次性的工具展示。

AI 工具幾乎每天都在變，現在學會的東西，明天還有用嗎？（圖 1）

留言討論