上週，我和 AI 一起從零打造了一個學習管理系統。 學員可以註冊、登入、看教材、繳作業、參與討論； 老師可以上傳教材、批改作業、管理學員。 聽起來像常見的線上課程平台， 但這次是為「伴飛計畫」量身訂做，從頭打造。

整個過程，我一直在想 Patrick Lencioni 的《凝聚團隊的五大障礙》—— 缺乏信任、懼怕衝突、缺乏承諾、逃避責任、忽視結果。 這本書原本是寫給人與人的團隊， 但當我把 AI 當成隊友，這五個障礙竟然一個都沒少， 只是換了一種形式存在。

這篇文章，是關於我從一週人機協作裡體會到的想法—— 也給正在思考如何與 AI 共事的人，開一條實踐的路。

▍敢承認「我不懂」

AI 跟我講解專業術語時， 我大可以似懂非懂地猜測，點點頭就過去。 但為了溝通效率，我選擇直接承認我不懂。 勇敢承認自己不懂， 不會讓自己莫名的自尊把目標越帶越遠。

第一天規劃時，我把「我要什麼」說清楚： 學員可註冊登入、老師可上傳教材、學員可下載、有討論區。 不是「我要一個好用的系統」那種模糊說法， 而是具體、可驗證的條列。

遇到卡關時，我也不包裝成完美問題， 直接描述「現象＋我試過什麼」。 例如：執行時顯示 ENOENT: no such file or directory，路徑是 backend/public/uploads。 或者，當我無法解釋我所面臨的狀態時， 我選擇截圖請 AI 幫我判讀。 能夠基於事實的訊息流通， 在面對錯誤時，才能更有目標性地去因應。

▍敢問「為什麼」

有時候 AI 的產出跟我想像中差距甚遠。 我本可以直接否決，請他按照我的想法完全執行。 但在下指令前，我總會好奇：他為什麼選擇了這樣的方案？

中文檔名亂碼那次， AI 提議用「時間戳＋隨機數＋副檔名」，例如 1773066057518-440821096.pdf。 我一度想堅持用原始檔名，因為學員下載時要看到有意義的檔名。 後來我說明我的需求與底線： 若編碼會亂，可以接受時間戳，只要下載時能顯示正確檔名。

徽章觸發邏輯那次，AI 寫錯了—— 特等勳章第一次優秀就觸發，應該是累計五次才對。 我指出來，我們一起迭代修正。 遇上自己不滿意的事情可能導致衝突， 但停下來去釐清每一件事為什麼會發生， 往往特別重要，甚至會帶來一些新的 idea。

▍開發歷程與迭代式承諾

和以往不同的是， 我知道這次的開發時間會比以往的工具來得長一些。 如何確保我們的想法能夠逐步執行，而不是一時興起， 變成極為重要的課題。

每次討論到一個進度， 我總是會請 AI 幫我記錄開發歷程與未來規劃。 透過逐步的檢核、增減， 讓我們不論走到哪裡，都不會迷失曾經訂下的目標。

作業系統的「迭代式設計」—— 學員可多次重交、老師每次評最新版、舊版本和舊評語都會保留—— 是明確的承諾。 後續所有卡關，路由被攔截、PDF 崩潰、連線失敗、時區錯八小時， 都圍繞這個承諾修，沒有推翻。

▍檢測者與回饋者

我不懂 code，AI 在這部分強我太多太多。 很多朋友說，交給 AI 直接做到好就好。 我能夠貢獻的方式，除了指點江山外， 更大的價值在：我會在每一步完成後， 仔細檢測每一個環節是否存在 bug。 AI 強又有自信， 我能做的，就是給予他最實在的回饋與檢測紀錄， 也讓開發過程中，我們清楚釐清了每一步的意義。

另外，回饋過程中，我很努力地克制自己給予評價式的回饋。 不說「你寫錯了」「這什麼爛東西」， 而是描述現象、提供截圖、說明預期與實際的落差。 每次出錯，都是「我們一起修」，而不是「AI 寫錯了」。 責任在我：我沒說清楚、我沒驗證、我環境沒設好。

▍結果優先的取捨

正因為我做我能做的， 讓我在和 AI 協作的團隊中， 不單純是個浪漫的夢想家，也是個務實的檢測者。 最終的成品也超出了我的預期。

最後選擇隱藏通知偏好、改用共用雲端硬碟、暫時關閉驗證信—— 都是「結果優先」的取捨，而非堅持完美才上線。

▍你跟你自己在協作

和真人團隊相比，和 AI 協作時有什麼不一樣？ AI 不帶情緒，好也不好。 好的是他不太違抗你， 不好的事是他也不會主動為你做更多。

在協作過程中，其實就是你跟你自己在協作。 你要忍受你自己的不耐煩、壞脾氣、粗心大意。 真實的團隊，有人必須承接你的脾氣； 但人機協作的團隊，是你自己承擔。

使用 AI，就是直面你自己的鏡子。 你在 AI 中碰到什麼阻礙， 很可能就是你在團隊中會慢慢潛藏的阻礙。

（人機協作三部曲之一，續見之二〈在造輪子中找專屬劇本〉、之三〈當 C 型人遇上更 C 的機器〉）