技術 Day 30：總結——如果重來一次，AI 開發工作流該怎麼設計

前言：為什麼要花 30 天講「怎麼跟 AI 協作」這件事本身 決定寫這個系列時，其實猶豫過。市面上不缺「AI 工具怎麼用」的分享，但大多數停在功能介紹的層次——...

技術 Day 17：Skill 設計實戰——把一次性的重構經驗變成可重複套用的流程

前言：規則講過一次，AI 下次還會忘記嗎？ 「昨天才糾正過 AI 一個錯誤判斷，今天換個任務，它是不是又會犯一樣的錯？」 會的——如果那個教訓只留在昨天那次對話...

技術 Day 16：案例——某類規則從「每次人工複查都漏」到寫成自動化檢查工具的過程

前言：明明每次都有檢查，為什麼還是漏掉？ 「我們每次發文前都會請人再看一遍，怎麼還是會漏掉不該出現的東西？」 這是很多團隊在導入某種內容規範（不管是去識別化、格...

技術 Day 15：Skill 附帶可執行工具（script）：把機械式檢查自動化

前言：寫進 skill 裡的規則，AI 真的會照做嗎？ 「這條規則我已經寫進 skill 了，AI 應該會照著做吧？」 這句話聽起來很合理，卻藏著一個容易被忽略...

技術 Day 13：CLAUDE.md vs Skill vs Memory——三層分工怎麼不互相打架

前言：三個地方都能寫規則，到底該寫在哪？ 「這條規則到底該放進 CLAUDE.md、寫成一支 skill，還是存進記憶就好？」 這個問題聽起來瑣碎，但答錯的代價...

技術 Day 29｜AI 不只是聊天機器人：我試著把 AI 講給爸媽聽

前情 這二十幾天寫下來，介面切來切去、規範改來改去，都是在解決「我自己」（技術人）怎麼用得更順的問題。但有個場景一直放在心裡沒處理：回家的時候，當長輩問「AI...

技術 Day 07：Skill 的「定位」段落——為什麼比規則本身更重要

前言：規則寫得夠細，還會出什麼問題？ 「一支 skill 只要把規則寫得夠詳細、夠具體，AI 應該就會用得準吧？」 這句話對了一半。規則寫得詳細，確實能讓 AI...

技術 Day 06：案例——一支 skill 從無到有的誕生過程

前言：Skill 是規劃出來的，還是長出來的？ 「要幫 AI 寫一支 skill，是不是要先坐下來，把這個領域的規則想清楚、列完整,再一次寫好？」 如果你也這樣...

技術 Day 05：Reference 型 vs Task 型 skill——什麼時候用哪一種

前言：反正都是「給 AI 讀的規則」，分那麼細幹嘛？ 「Skill 不就是一份寫給 AI 看的說明文件嗎？裡面寫規則也好、寫步驟也好，AI 都看得懂，有必要分成...

技術 Day 04：Skill 的本質——把一次性經驗提煉成可重複套用的規則

前言：寫一份文件，跟寫一支 Skill，差在哪裡？ 「不就是把規則寫成一份文件嗎？跟寫在 README 或內部 wiki 有什麼不一樣？」 這是我剛開始用 Sk...