原本只是想在軟體工程師的日常裡，
當作一次 Retrospective Meeting 的引言，帶團隊夥伴一起想一件事：
「在 AI 時代，我們這個組要怎麼互動、怎麼一起工作？」
但隨著發想越來越多，加上生日請了特休， 就索性把文章擴寫完成，也想試試看在這個世代， 這樣偏長、偏思考紀錄的內容，會不會有人有共鳴。
「
在我們組，我有意識地把 Code Review Meeting 的結構，調整成適應 AI 時代的樣子。
」
起因其實很單純。 我要做一場「我們組如何使用 AI 迭代工作方式」的內部分享。
為了準備這個主題，我做一個長達一個月的「後設認知」練習，並把這些過程都轉換成內部分享投影片的素材。
當時我為了收集「後設認知」素材，做了什麼？
- 每一次跟 AI chat 的時候，我都會跳到一個 Notion 頁面，問自己幾個問題： 「這段思考，有沒有分享給別人的價值？」 「如果沒有，是因為我已經分享過了，還是我先入為主地覺得「這個不用講」？」
- 「思考」這個詞，在這一個月中，被拆解成 「我是如何構思 AI 互動的 chat prompt 的預期結果？」 「每一次 chat，能不能正規化成工作流程裡面，大家都可以輕易複製的 Lessons Learned？」
但其實就是我刻意觀察自己是怎麼跟 AI 工作的 🤣
除了寫 code 的工程師角色，我更多時候會刻意切出一個「旁觀者」的客觀角色，觀察我上一個時刻自己的行為、在做什麼選擇、用什麼邏輯理解問題、怎麼規劃下一步；這些過程被記錄下來，所以我說是一種「後設認知」。
用現在 AI 時代的語言比喻，很像是你在 chat 裡指定一個身份：
「你是一個有十年經驗的文章編輯，幫我檢查這段文字。」
只不過這次，是我自己思考，又要自己批判自己的思考過程。
「
這個一個月的練習後，我對 Code Review Meeting 的看法有了一個新的比喻，我會形容它是一種『旅行』
」
在過去沒有 AI 的時代，我偏好的 Code Review Meeting 風格，像是「長途自駕公路旅行」。
旅程彷彿上個時代的開發時程，很長， 路途中聊天、音樂、停靠點，都會變成記憶。 我們可以逐行 review、逐檔案檢查討論架構是否有缺漏，討論「這樣寫好不好」，相互分享經驗、和提醒夥伴是否有更好的回饋。
這樣的 meeting 在上古時代還算美好。
但現在是 AI 的時代，過去在 Code Review Meeting 裡討論的很多事情，其實自己先跟 AI 討論，就可以做得更完整，而且可以做得更好。
那問題來了：
那我們 review meeting 還有什麼價值？
有的，只是討論的東西變了，我們組開始討論
- 為什麼會這樣下 prompt？
- 問題是怎麼被拆解，才適合交給 AI？
- AI 產出是否符合預期？
- 有沒有更好的方式或技巧可以處理 prompt 的結構或是方向？
- 在過程中跟 chat 討論哪些 A/B/C 方案或架構設計，為什麼採用或是不採用？
- 哪些 AI 提出的建議非常有價值，是透過什麼 prompt 得到的？
很明顯，AI 的時代我們把 AI chat 視為 Code Review Meeting ，
那我們直接 share 這些 review 的結果，大家都能快速累積經驗與獲得成長。
有時候因為需要 context，PR 裡面都是 prompt 的節錄和對應的結果。
這就很像交通工具的改變。
飛機加速了移動的方式，我們的 Code Review Meeting 從長途自駕公路旅行變成搭飛機，本來因為旅途漫長會關注路上的風景（指過去時代的逐行 review），
現在，我們更關心的是目的地。
「
舊時代的「過程（逐行 review）」，原本是很好的 Lessons Learned。
但是現在，prompt 的思考方式，和最後結論的價值，才開始變成新的 Lessons Learned。
」
但如果什麼都不改，會發生什麼？
- 工作中只剩下大量 AI 產出，卻沒有真正的理解
- Code Review Meeting 對話可能出現 「這是 AI 產的，我⋯⋯（略）」
然後我意識到工作日常中，有幾件事也開始發生
- 後端有意識想要開始產 web code
- 設計先跟 AI 互動，確認「預期的想像」是可以被實作的
- PM 在需求文件裡用 AI 做總結
這些都不是壞事，大家都開始用 AI 迭代自己的工作流程。
但問題是：
配合這些改變，有沒有對應的流程被重新設計過？
有什麼工作流程像是前端 code review meeting 一樣被重新設計嗎？
如果沒有，摩擦就會出現。
- AI 產出的 web code 依然有維護風險，已經有不少開源專案公開表示不接受 AI 生成的 PR，因為因為驗證成本高、AI slop 太多
- 設計成功生成「看起來對的東西」，但是沒有考量到網頁裝置效能問題、跨裝置支援度 … etc ，好像只要能生成 code，複製貼上就能用
- PM 說「這是 AI 給的總結」，但說不清楚基於哪些資料、用什麼方式設計 prompt，上下文反而變少
實際上，我們組已經不太討論 code base 的程式碼片段了，
因為只要知道意圖、知道 prompt，那段程式碼片段誰都可以生成。
問題是，當「誰都可以生成」正式進入工作流程，缺失太多背後的思考，很容易變成工作流程塞入一堆 AI slop ，溝通上反而更困難。
「
*Seven Steps to Heaven，Think one step further
」
大家多想一步（step），
也許不能一步到天堂，
但多想一步，
至少可以離美好近一點。
現階段我自己的結論是：工作流程沒有調整前，不要太重視 AI 產出
- web code 還是交給 web team，或者讓後端能獨立維護自己的 codebase
- 設計即使成功生成預期的畫面，
溝通的重點仍然是設計意圖、核心理念、想達成的目標，工程師會考量工程實作面向和確保設計意圖的表達。 - 比起 「這個是 AI 給的總結」，跟 AI 互動討論過程 context 老掉牙的 「3W1H」也同等重要。
*Miles Davis – Seven Steps To Heaven
