> ## Content Index > Fetch the complete content index at: http://localhost:2368/llms.txt > Use this file to discover other available public pages before exploring further. # 不會寫程式，如何靠 AI 協作獨立交付一套公司系統 - URL: http://localhost:2368/ai-collab-newcomer-handbook/ - Published: 2026-07-07T01:56:23.000Z - Updated: 2026-08-23T13:54:26.000Z - Description: 給新人的 AI 協作手冊：專案六站旅程、必懂的五塊積木、決定成敗的七個協作原則。 - Author: yuchang23 - Tags: #article *這不是教你寫程式的文章——因為你不需要會。作者半年交付了四套公司內部系統，沒有親手寫過一行程式；他做的事情是：把需求說清楚、在決策點拍板、驗收成果。這份手冊把這條路整理成地圖：專案的六站旅程、你必須看得懂的五塊積木，以及真正決定成敗的協作方法。* ## 壹 先建立正確的自我定位 你不是工程師，你是產品負責人 透過 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 協作的六個月：廠內系統篇](https://claude.ai/code/artifact/59d0d5ce-08ea-463f-bf86-d3fb6577bc72?ref=localhost)、[個人研究篇](https://claude.ai/code/artifact/4a8010e8-e7dc-4e3d-bc4f-328b310737dd?ref=localhost)