AI 時代工程師的價值
現在我已經把全部的實作都交給 AI，自己只負責架構、決策和整合。
但實際一起做事之後，我也大概知道它做不來的地方在哪裡。問題是這種感覺很容易模糊：像我現在就想不起來，過去幾個月到底擋住了 AI 的哪些東西，只剩下「好像有一些」，講不出具體是哪些情境。這也是這一頁有必要存在的原因。
所以這一頁是一份持續累積的紀錄，從 2026 年 10 月底開始記。每次協作時，只要遇到「我攔下了它」「我做了不一樣的決定」，或是反過來「它的做法其實比我好」，就把具體的情境記下來：當時在做什麼、它怎麼做、我怎麼判斷、為什麼。不急著下結論，等案例夠多，再回頭看：在這個 AI 時代，工程師的價值到底還剩下什麼。
怎麼記錄
每一筆固定這幾格，重點是把情境寫具體，寫到之後的自己看得懂：
- 情境：在做什麼，
AI一開始怎麼做 - 我的判斷：我攔下來，或改成什麼
- 為什麼：
AI當下缺什麼資訊，或是我多看到了什麼 - 結果：後來怎樣，包含我其實判斷錯、或兩邊差不多的情況
- 反思（選填）：從這件事得到的做法或原則，不是每一筆都有
每一筆有一個分類和一個結果標記。
分類：
- 脈絡：
AI不知道的業務、組織或歷史背景 - 取捨：兩種做法都可行，但要選一個
- 安全：資料、權限或其他風險
- 過度設計：做太多、太複雜，或不必要的抽象
- 驗證：說完成了，但其實沒有驗證
- 需求：需求本身有問題，照做只會做出錯的東西
- 抽象層級：
AI往太細的地方鑽，或停在太粗的地方，和當下這個階段需要的層級不符
結果標記：我的判斷較好 AI 的做法較好 各有道理 抓到失誤
最後一個不是在比判斷高下，而是 AI 沒有照既有的規則做，被我抓到。如果抓到時已經造成重做或額外成本，會寫在「結果」裡。
涉及公司或客戶的案例會去識別化，只留情境和判斷。
紀錄
驗證 抓到失誤 Skill 有寫規定，AI 還是沒照做 2026/11/07
情境
我請 AI 產出同一份內容的多個版本，專案的 skill 已經明確規定各版本之間要保持一致。結果 AI 交付時，版本之間沒有對齊。
我的判斷
我好好地問它：為什麼這次沒有對齊？先前的 skill 沒有提到嗎？
為什麼
Skill 本質上只是放進 context 的文字，不是穩定的工作流程。模型有一定的隨機性，可能不照著做，連已經找到對的 skill 都可能不遵守。所以不能預設「寫進 skill 就會被執行」，交付前也要有人檢查它有沒有照做。
結果
它承認 skill 有寫(也列出位置及內容)，是自己沒遵守，也漏了交付前的一致性檢查：
「有，skills 已經明確規定，這次是我沒有遵守，抱歉。」
它提出以已核准的版本為基準去修正其他版本。但抓到時成品已經產出，所以必須重新生成，多花了一次成本。
反思
追求一定要穩定的事情，就交給腳本，讓程式碼去檢查與執行，不要只靠 skill 的文字提醒。這次的操作成本不高，暫不急著改變流程，但未來若類似情況頻繁發生，就要考慮用程式碼去強制執行。
需求 我的判斷較好 RAG 實驗的前提：AI 說 context 要塞不下才需要選取 2026/11/03
情境
我在做 RAG 相關的實驗。AI 設計實驗時建議：讓對話歷史超出 context 預算，這樣才必須做選取；如果全部歷史都放得進去，RAG 本來就不會有優勢。
我的判斷
我質疑這個前提。依我的印象，就算 context 很大，塞太多內容模型也會變得有點失憶，甚至產生幻覺。所以比較好的做法是讓 context 盡量小、盡量乾淨，而不是能全部塞就全部塞。
為什麼
AI 把「放不放得下」當成需要選取的唯一理由，但放得下不代表放進去就比較準。照它的設計，實驗只能比較「塞不下」的情況，反而測不到選取本身能不能讓結果更好。這個前提若不修正，實驗要回答的問題就偏了。
結果
它承認自己講得太絕對，並補上相關研究（「Lost in the Middle」、「context rot」）支持我的方向：
「你說得對，是我講得太絕對。就算全部內容都放得進去，選取仍可能讓結果更好。」
實驗設計之後怎麼調整、結果是否如預期，還要再觀察。
抽象層級 我的判斷較好 還沒有 Use Case 和介面，AI 就想先選技術 2026/11/02
情境
架構對齊之後，我問 AI 下一步做什麼。它提議：先確定實作技術，再建立假模型的完整垂直流程。
我的判斷
我沒有直接否決，而是用問的：下一步是確定實作技術，還是應該先規劃有哪些 Use Case、端點之類的介面？
為什麼
技術選型應該建立在 Use Case 和介面之上，順序反過來，等於在還不知道要做什麼的時候就先把技術綁死。AI 傾向往下一個看得到成果、可以動手的階段衝，所以需要有人守住順序。這和上一筆是同一種模式：它跳到比當下階段更具體的層級。
結果
它同意我的順序，並自己承認跳太快：
「我認為你說的順序更合適：先補齊 Use Case 與應用介面，再確定實作技術。我剛才太快跳到技術選型了。」
後續補完 Use Case 與介面之後的成效，還要再觀察。
抽象層級 我的判斷較好 需求訪談問得太細，在產生文件之前先喊停 2026/11/02
情境
我在試著用 AI 做一個把文件「左移」的工具：先透過需求訪談和 AI 對齊，再由 AI 產生文件，之後才進入開發。訪談時 AI 一直追問，越問越細，問到角色、介面這類細節。
我的判斷
這些已經不是產生文件之前該問的東西，我直接要它停下來，不要再往細節走。
為什麼
這一步要產出的是偏抽象的架構文件，細節問得再精確，對文件也沒有幫助。對話拉長之後，AI 還可能忘掉前面已經對齊的東西，越問反而越糟。AI 的每個問題單獨看都合理，所以它自己不會停，需要有人判斷「現在這個階段該問到哪一層」。
結果
它馬上收斂，回覆：
「對，我剛才太早進入角色與介面的細節了。接下來先聚焦在系統責任、邊界與實驗流程，具體個性等設定留到架構圖出來後再討論。」
目前只確認到它能被拉回來，這份文件最後好不好，還要等後續的開發驗證。