我們如何使用 AI¶

Time Compass 有兩個使用 AI 的核心理念：

AI 應該幫助人類從簡單但很煩的事情中解放出來
人類應該保留最終決策權

這個原則同時用在產品設計，也用在開發流程。

產品上：AI 幫忙整理與提案，人負責選擇¶

在時間管理這件事上，最耗力的常常不是做決定本身，而是先把資料找齊、整理好，再拆成可以開始做的下一步。

這些事情非常適合交給 AI：

整理來自 Google Calendar、Google Tasks、Moodle 的資訊
找出真正值得注意的待辦與事件
將大任務拆成較容易開始的小步驟
產生多個可比較的規劃方案

但我們不希望 AI 直接替使用者做最後決定。

所以 Time Compass 的設計不是「AI 幫你決定」，而是「AI 先提出幾個方案，再由你選擇」。我們相信 AI 可以降低開始規畫時的阻力與拖延情緒。但最終的安排仍應該由人來決定，因為當方案是使用者發自內心選擇的，那麼方案也會更容易落實。

開發上：先規劃，再動手¶

我們和 AI 一起開發時，也遵守同樣的分工邏輯。AI 很擅長探索脈絡、列出方案、補充文件與加速實作，但最後的方向選擇不能外包。

我們目前的開發迴圈可以濃縮成四步：

釐清問題
發現 bug 或想新增功能時，我們會先讓 AI 用 OpenSpec 或其他工具探索現狀，例如相關程式、資料在程式裡長怎麼樣、程式之間如何互相引用，以及需要查閱的最新文件。
選擇方案
在完成 explore 之後，我們會讓 AI 提出 proposal，必要時比較多個方案，再由人決定要採用哪一個方向，並把 proposal 修到滿意為止。
分階段解決
方向確定後，再把工作拆成不同階段，逐步實作、驗證、重構，而不是一次暴衝到底。
驗證結果
最後一定由人驗證成果，確認功能、行為、都符合預期，再進入 git 同步。

這套流程本質上就是三個理念：

先計畫再行動
邊改邊寫很容易陷入「能跑」，但其實不是最佳解的實作方法。因此應該要先調查清楚現狀，先 explore，再整理成 proposal。
先比較方案再選擇，人類最最終決策
不要直接問AI怎麼做。你應該要問 AI 有哪些可能的方法可以達成你的目的、在自己權衡利弊後挑選。事實上，這個部分是最能與AI一起成長的部分，詳細可見下個章節
人類要在最後實際驗證
應該要在最後檢查 AI 做了什麼改動、改動後的效果是否真的解決問題。

為什麼方案挑選不能交給 AI¶

因為開發對我們來說困難的地方，往往不是簡單的把程式碼補到能跑，而在於找出問題的源頭、哪一個修改方案才對長期有利。

在我們的經驗中:

如果人不做判斷，最後會失去整個系統的掌控權，反過來被 AI 控制。

這在工程上通常會表現成幾種問題：

AI 傾向做小修補，而不是重看整體架構
AI 可能知道如何通過測試，但不一定知道這是不是好設計
AI 不一定會主動停下來說真正的問題在哪
如果人不自己做決策，最後連 debug 都會變得困難，因為你已經不知道為什麼變成現在這樣

AI 很擅長提案、加速與補強，但他無法代替人類做決策。

最有價值的是人的成長¶

和 AI 一起開發時，常常會出現我們不熟悉的知識或概念，這時往往就是成長的機會。我們會請 AI 向我解釋概念。AI 能根據現有的程式碼與文檔做出符合我們程度的解釋，我們也能一直追問直到了解為止。我們在一次次的決定中，逐漸學會如何權衡時間、專案規模、成本、可維護性等等方面，最終選出最適合的做法。

跟 AI 還會在其他方面合作嗎?¶

會。除了提到的開發流程以外，AI也會使用到我們設計的全域的 prompt 、 skills 跟 mcp。我們也會使用AI把經驗寫回 skills。

我們的 prompt 會在每一次跟 AI 開始對話時加入。拿來記一些每次都希望他能記住的東西，比如說專案使用了什麼技術、對話時應該使用繁體中文等等。

mcp 這個工具能讓 AI 做到更多事情，而 skills 告訴 AI 如何實際行動。

當需要查詢文檔時，我們會請 AI 調用 context7 這個 mcp，讓 AI 獲得與問題相關的最新文檔。

當需要設計前端時，我們會請 AI 使用 ui-ux-pro-max 選擇前端的風格、配色等等。

當我們發現有一個重複的工作流程時，我們會將他轉換成可重複使用的 skills。例如讓 AI 學會分析 JSON (一種文本的格式)的結構，並轉換成程式方面好用的型態。

那麼，我們是如何開發的¶

前面提到開發的四個階段，以下我們會具體說明在每個階段我們是怎麼跟 AI 合作的。

釐清問題¶

這步驟包括:

使用 openspec 的 explore 指令。核心是AI先理解我們的 code，但不做更動。
請 copilot 開 subagent 掃描相關檔案。包括上下游、函數的互相調用、pydantic model、已有文檔等等
追蹤 data flow，看看資料是否在某個部分有不合理的轉換、或是哪裡的型別不清楚
使用相關 mcp ，例如前面提到的使用 context7 蒐集第三方相關文檔
使用相關 skills ，例如前面提到的 ui-ux-pro-max
如果問題較為複雜，會讓 AI 寫小程式，嘗試重現問題。

選擇方案¶

這步驟我有時候會請網頁版的 ChatGPT ，在網路上搜尋大家如何解決類似的問題。也會直接讓 AI 使用 openspec propose 產出提案，然後由我持續修改、刪減、補充，直到 proposal 足夠貼近真正想做的事為止。如果有多個方向，也會先要求 AI 列出可選方案，分析每個方案的優缺點，再由人做最後決定。

分階段解決¶

有兩個主要理念，分別是 TDD(Test-Driven Development) 跟 DDD(Domain-Driven Development)。

TDD 是先寫測試，再寫程式碼。這樣可以確保每個階段的改動都有明確的驗證標準。先寫好測試也可以避免 AI 寫出與問題無關的程式碼(另有真實資料抓取、以及資料階段性輸出等檔案裡兩個細節，詳見 [])。
DDD 是先定義好資料模型，再寫程式碼。這樣可以確保每個階段的改動都有明確的資料結構，避免 AI 寫出不合理的資料轉換。並且在 debug 的時候，可以以資料模型為基準，追蹤資料在程式中的流動、並分析哪裡出錯。例如實際內容與模型不符合、或是在哪一部的模型轉換做錯了。

每個 phase 的最後一步當然要馬上 commit 並 push，確保每個階段的成果都被記錄下來。

驗證結果¶

這步驟一個可以從 tests 生出的檔案進行驗證；也可以想edge case、自己操作看看成果、跑一次冒煙測試等等。