讓AI寫程式之前，先決定它在你的開發流程裡站哪個位置

把鏡頭拉近一點，先看這篇教學文裡最容易被略過的一句話：如果每一步都臨時提問，AI給出的內容可能互相矛盾，自己也容易忘記驗證哪些地方。這句話講的不是AI的能力問題，而是使用方式的問題。多數開發者已經會用AI寫程式，但很少人想過，把AI放進一整條開發流程時，順序和分工要怎麼設計。

八月三十一日，掘金平臺上出現一篇標題為「從零搭建你的AI編程工作流」的長文。作者用一個再日常不過的功能當例子：給商品列表加上關鍵字搜尋。前端Vue 3、後端Node.js與Express、資料庫MySQL，技術棧普通，需求也普通。正因為普通，才適合用來說明流程，因為流程要能在大多數專案裡重複使用。

AI適合做什麼，開發者必須留什麼

文章先把分工畫清楚。AI適合處理的，是整理資訊、發現遺漏、生成程式碼草稿、提供多種實作方案、補充測試場景、檢查修改內容、整理技術文件。開發者仍然要負責的，是確認真實需求、選擇方案、判斷程式碼正確性、處理業務與安全問題，以及在真實環境中執行驗證。

這個分工可以用一個比喻理解。AI像一位手腳很快、記憶力很好的助手，你把資料丟給他，他很快整理出草稿，還會提醒你幾個你沒想到的細節。但這位助手不認識你的公司、不知道你們的業務規則，也不必為上線後的結果負責。所以「自動交付系統」和「高效助手」是兩種完全不同的期待，前者目前不存在，後者已經每天都在用。

許多開發者的挫折感，來自用前一種期待去用AI。一次提問要它從需求到程式碼全部包辦，結果寫出來的東西方向偏了，回頭修的時間比自己寫還長。這與我們先前分析的技術深度和可量化商業價值之間的落差有相似的結構：難的從來都不是單一步驟的品質，而是把每一步串起來時，判斷點放在哪裡。

第一階段：先不寫程式碼，先確認需求

這篇教學最反直覺的地方，是第一步就明說：不要一開始就讓AI寫程式碼。先讓它分析需求，暫時不寫任何實作。

以搜尋功能為例，提問時把專案背景、技術棧、需求描述全部給足，然後要求AI輸出它對需求的理解、需要確認的問題、前端任務、後端任務、測試驗收標準，並且明確限制它不要自行增加分頁、排序等功能。

AI在這一步經常會問出好問題：搜尋是否區分大小寫、是否用模糊匹配、關鍵字要不要去首尾空格、搜尋失敗時顯示什麼提示、要不要防止使用者頻繁請求。這些問題如果到了測試階段才被發現，改動成本會高好幾倍。讓AI在需求階段就把它們翻出來，等於用幾乎零成本做了一次需求審查。

這一階段的產物很重要，而且不是聊天記錄。教學文建議整理出一份簡短的實現約束文件，把匹配方式、空關鍵字行為、空格處理、錯誤處理、範圍限制都寫下來。這份文件就是後續所有階段的共同上下文。你可以把它想成裝修前和設計師確認的那張平面圖，後面不管換幾個工班進場，都照同一張圖施工。

第二階段：先出方案，再分小步寫程式碼

需求確認後，下一步仍然不是寫程式碼，而是讓AI先設計實作方案。要它說明前端要改哪些檔案、後端要改哪些檔案、介面參數和回傳結果、關鍵邊界條件，並且優先複用現有專案結構、不引入新依賴，先輸出方案，不寫完整程式碼。

方案確認後，才進入分小步生成。一次只讓AI實作一個部分，例如只做後端介面，並附上明確約束：使用現有的Express路由和資料庫存取方式、關鍵字為空時查全部、必須用參數化查詢、不改資料庫表結構、保持現有回傳格式。

「參數化查詢」這條約束值得單獨看。SQL注入是搜尋功能最典型的安全風險，AI生成的程式碼如果直接拼接字串，表面上能跑，實際上把整個資料庫暴露在攻擊面裡。把這條寫進約束，就是把開發者的安全判斷，以指令的形式注入AI的輸出。這正是「關鍵判斷留在自己手中」的具體操作方式：判斷不留在心裡，寫進提示詞。

分小步還有另一個好處：容易發現問題，也方便回退。一次生成五百行程式碼，出錯時很難定位；一次生成一個函式，出錯時重寫的成本接近零。

第三階段：先列測試場景，不急著重構

程式碼寫完後，教學文的建議是先別讓AI重構或加新功能，而是先讓它根據需求列出測試場景，暫時不寫測試程式碼。

這個順序設計的邏輯和需求階段一致：先對齊「什麼算對」，再產出「檢查對不對的東西」。關鍵字為空時回傳全部商品、前後空格要自動去除、這類場景如果由AI自由發揮，它可能列得很全面，也可能漏掉最關鍵的邊界。所以測試場景要對著前面那份實現約束文件來列，而不是憑AI的常識。

到這裡，五個階段的輪廓已經完整：需求分析、編碼實作、測試驗證、程式碼審查、文件整理。每個階段進下一個階段之前，都有一份明確的產物作為銜接。這也是這篇教學真正的核心主張：工作流的價值不在於自動化，在於讓每次AI互動都有一致的上下文，讓驗證有清單可對。

成本訊號：這條工作流的經濟基礎

這種以提示詞為骨架的工作流之所以現在可行，和AI使用成本的變化直接相關。當反覆提問、多輪確認的邊際成本夠低，開發者才負擔得起「先確認需求、再出方案、再分步實作」這種看似繞路的流程。模型定價的變動正在把AI從示範品變成日常耗材，這一點在微軟把語音轉文字壓到每小時0.10美元的定價策略裡同樣看得到：工具夠便宜，使用方式才會從「偶爾用」變成「嵌進流程」。

一般開發者能帶走的三件事

第一，把每次和AI的互動都當成有前後文的連續工作，而不是獨立事件。需求階段產出的約束文件，值得花十分鐘寫，因為它會在後面每個階段回收價值。

第二，把你的判斷寫進提示詞。安全性、回傳格式、不改表結構，這些約束愈明確，AI的輸出愈接近可以直接採用的狀態。含糊的提問得到含糊的程式碼，這件事在流程裡放大得特別快。

第三，控制粒度。一次一個部分，出錯時好回退，驗證時好定位。粒度是開發者手上最實際的風險控制工具，比挑哪個模型重要得多。

這篇教學文沒有談任何自動化平臺，也沒有綁定特定工具。它示範的其實是一種態度：AI把生產草稿的速度提高了好幾倍，於是慢下來確認方向的那幾分鐘，反而成了整條流程裡報酬率最高的投資。