不會寫程式，如何靠 AI 協作獨立交付一套公司系統
給新人的 AI 協作手冊：專案六站旅程、必懂的五塊積木、決定成敗的七個協作原則。
這不是教你寫程式的文章——因為你不需要會。作者半年交付了四套公司內部系統，沒有親手寫過一行程式；他做的事情是：把需求說清楚、在決策點拍板、驗收成果。這份手冊把這條路整理成地圖：專案的六站旅程、你必須看得懂的五塊積木，以及真正決定成敗的協作方法。
壹 先建立正確的自我定位
你不是工程師，你是產品負責人
透過 AI 協作做系統，新人最常見的誤區是覺得「我不懂技術，只能聽 AI 的」。實際上整個專案裡真正不可取代的工作全部在你身上：只有你知道公司的流程長什麼樣、哪個環節最痛、同仁會怎麼使用、什麼結果算「對」。AI 負責把這些轉成程式，而你負責三件事：
- 說清楚要什麼——說到「可驗收」的具體程度
- 在決策點拍板——AI 會列出方案 A/B 的優缺點，選擇權在你
- 驗收——照著事先訂好的標準逐條檢查，不是「看起來能動就好」
整份手冊的每一站，都是這三件事在不同階段的變形。
貳 專案的六站旅程
從模糊的想法到穩定運轉，每一站你的工作不一樣
第一站 需求：把「痛」講成故事
起點不是規格，是痛點：「儀器校驗到期都靠人記，漏了就出事」。你的工作是把現況、痛點、期望講給 AI 聽，講得越具體越好——誰在用、多久用一次、現在的做法卡在哪。不用擔心講得不專業，擔心的應該是講得不完整。
真實案例： 品管系統的起點就是幾份 Excel——儀器總表、借出清單、到期日靠人腦。半年後它是一套有 狀態機 、有審核流程、有自動提醒的系統。第一步只是把 Excel 攤開給 AI 看。第二站 規格：所有決策發生在這裡
模糊需求先讓 AI 展開成規格（這套做法叫 SDD，規格先行開發）：範圍是什麼、怎麼做、怎麼驗收、不做什麼。遇到要選擇的地方，AI 會列成選項表——例如「同時編輯的衝突要用平台內建機制還是自己做？」——附優缺點讓你拍板。這站花的每一小時，都在省實作階段的十小時。
拍板時最好用的一句話：「這兩個方案各自壞掉的時候，長什麼樣子？」比較故障情境，比比較優點更容易做對決定。
真實案例： AI 助理功能規劃時，AI 列出「上檢索系統」vs「文件全塞」兩案，附上成本與故障模式的比較。因為文件量遠低於門檻，選了簡單的方案——沒有為了技術流行而選複雜的那個。第三站 實作：你在場，但不動手
AI 照規格實作。大功能會拆成幾個 sprint（衝刺段），每段有自己的「契約」：範圍、可測試的成功標準、明確的不做清單。你這站的工作是回答 AI 的提問、盯住範圍——它想多做的先記下來，不要讓這一段膨脹。
比較大的專案還會讓 AI 分角色互相把關：規劃者、實作者、驗收者是不同的 AI session，實作者自己說做完了不算數，要驗收者逐條比對契約才算。
真實案例： 圖面系統的基礎建設，獨立的驗收 AI 抓到實作 AI 的三個錯誤退回重修——這些錯誤如果上線才發現，會麻煩十倍。第四站 驗收：照清單打勾，不是憑感覺
驗收條件在規格階段就寫好了，這站只是執行：逐條打勾。重點有二：條件要量化（「解析成功率大於 95%」而不是「做得出來」）；要測壞的情況——故意輸入錯的資料、故意快速連點、故意用中文檔名，看系統會不會優雅地處理。
真實案例： PDF 自動讀取功能因為驗收訂了量化門檻，失敗了兩輪被退回，第三輪換方法才通過，最終成功率 99.3%。如果驗收只寫「做得出來」，第一輪的半成品就過關了。第五站 上線：正式與預覽是兩個世界
程式碼推上版本庫後會自動部署成網站（這條自動化叫部署管線），部署成功還能自動發 Teams 通知。這站要懂一個關鍵概念：正式環境與預覽環境是分開的——給同事試新功能的預覽網站，設定（連線金鑰、登入白名單）不會自動繼承正式環境的，每次開新預覽都要照 checklist 補一輪。
真實案例： 「同一份程式，正式好的、預覽壞的」發生過不止一次，最後原因全是環境設定差異。現在它是一條固定的檢查清單，不再是驚嚇。第六站 維運：讓知識留下來
上線不是終點。同仁的回饋收斂成 Planner 問題卡（有編號、有狀態、有往來紀錄）；發現的問題分成「要修」和「先不修」，先不修的要寫下原因和解除條件；踩過的雷寫成可重用的指南，下套系統直接繼承。做第二套系統時你會發現：起點比第一套高了一大截。
真實案例： 第一套系統踩過的認證、冷啟動、部署地雷，第二、三、四套全部沒有再踩——後端模組甚至直接沿用，愈晚開的專案愈快。參 五塊積木：看得懂就好，不用會做
目標是「看到症狀，猜對壞在哪一塊」——這決定你跟 AI 對話的效率
| 積木 | 白話 | 症狀歸這裡的長相 |
|---|---|---|
| 前端 | 使用者看到、點的網頁 | 畫面錯亂、按鈕沒反應、切太快顯示到別筆資料 |
| 後端 API | 網頁跟資料之間的服務生 | 畫面正常，但存不了、讀不到、回應「驗證失敗」 |
| 資料庫 | 所有資料真正住的地方 | 資料不見、兩人互蓋、每天第一個人開特別慢 |
| 身分認證 | 誰能登入、誰能按刪除 | 登入壞掉、權限錯亂、換個環境就不能登 |
| 部署管線 | 程式碼自動變成網站的通道 | 改了沒生效、正式好的預覽壞的 |
外加兩個常用配件：檔案儲存（附件、照片住的地方，和資料庫是分開的兩個東西）、排程（固定時間自動做事：到期提醒、資料庫預熱）。
為什麼這張表重要？因為「IQC 存檔時偶爾會蓋掉別人的修改」（資料庫層、同時編輯的衝突）比「系統怪怪的」能讓 AI 快十倍鎖定問題。你不需要知道怎麼修，你需要知道怎麼描述。
肆 協作架構：真正決定成敗的七個原則
系統架構決定你能不能開工，協作架構決定你能不能交付
01 規格先行，寫程式是最後一步
所有決策發生在動工前。模糊需求先展開成規格，改規格的成本是改程式的十分之一。
02 驗收條件要量化、要先寫
「成功率大於 95%」逼出了三輪重做；「做得出來」只會得到半成品。條件先寫好，AI 和你都沒有事後放水的空間。
03 實作與驗收分離
驗收者是獨立的 AI session，逐條比對契約。實作者自己說做完了，永遠不算數。
04 先織安全網，再做大改動
大改之前先讓 AI 補齊自動測試。有了安全網，搬遷資料層這種大手術也能無痛完成。
05 失敗要看得見
自動化處理不了的，進「待人工」清單，不准默默出錯。最可怕的不是失敗，是錯得無聲。
06 決策留痕
「先不修」是合法決策，但要寫下原因與解除條件。sprint 報告、問題卡、擱置清單——讓任何人（包括三個月後的你）能接手。
07 經驗沉澱成可重用的資產
踩過的雷寫成指南，AI 下次自動想起來。流程文件綁角色不綁模型——模型換代，你的方法自動變強。
伍 新人真正要練的三個能力
架構知識是背景，這三件事才是日常
- 把需求說到「可驗收」的具體程度——「我要一個報表功能」不行；「主管每週一要看上週各機台的稼動率排名，能匯出」可以。
- 看到症狀猜對積木——用第參節那張表對號入座，描述症狀時帶上你的猜測，對錯都能加速定位。
- 用故障情境做選擇——AI 給你選項時，問「兩案各自壞掉時長什麼樣、誰來收拾」。優點會騙人，故障模式不會。
最後一個提醒：第一套系統會很慢，這是正常的。你在同時學三件事——這個領域的語言、AI 的脾氣、你自己公司的需求到底是什麼。但每一站留下的規格、清單、教訓都是複利：作者的第四套系統，後端骨架直接沿用第一套的成果，五天就完成了過去要一個月的事。
你不需要成為工程師。你需要成為一個「說得清楚、選得果斷、驗得仔細」的產品負責人——剩下的，交給 AI 和這套方法。
延伸閱讀——這份手冊背後的真實歷程：與 AI 協作的六個月：廠內系統篇、個人研究篇
