什麼是 AI 程式設計工作流程?
AI 程式設計工作流程是一種可重複使用的方式,讓你在整個軟體任務中運用 AI,同時不放棄工程判斷。開發者定義成功的標準,並審查每一項重要變更。程式設計 Agent 會先調查專案並提出方案,獲得核准後,才會編輯相關檔案並執行專案的檢查。
為什麼無結構的 AI 程式設計反而製造更多工作
無結構的 AI 程式設計感覺很快,因為程式碼立即就出現了。隱藏的成本會在之後才浮現——當開發者必須釐清各種假設,或修復擴散到原始需求之外的變更時。
規劃與執行同時進行
當需求模糊不清時,Agent 必須在撰寫程式碼的同時決定該功能該做什麼。這些決定可能與開發者原本的意圖不符。舉例來說,如果你只說「新增一個深色模式切換開關」,Agent 並不知道這個開關該放在介面的哪個位置,也不知道使用者關閉應用程式後,這個選擇是否應該被記住。
龐大的提示詞會產生難以審查的變更
範圍過廣的需求會促使 Agent 在一次操作中變更專案中許多相互關聯的部分。最終產生的變更可能龐大到讓開發者難以有把握地理解全貌,即使每個檔案單獨看起來都合理。舉例來說,「建立一個設定頁面」可能同時影響介面,以及偏好設定的儲存方式。
缺少背景資訊會產生泛用的程式碼
程式設計 Agent 無法遵循它未曾見過的專案慣例。如果缺少相關檔案或儲存庫指示,它可能會在已有現成抽象的地方另外引入新的抽象,也可能使用與已安裝依賴版本不相符的 API。
快速產出掩蓋了返工的成本
產生程式碼的時間不等於交付的時間。一分鐘內產出的變更,仍可能需要一個下午的除錯時間。更好的衡量方式,是從明確需求到團隊願意維護的、已驗證的變更之間所花費的時間。
AI 程式設計工作流程一覽
下面的工作流程讓開發者掌控決策,同時將可重複的調查與實作工作交給 Agent 負責。
| 階段 | 人的職責 | AI 的職責 | 產出 |
|---|---|---|---|
| 定義 | 設定目標與限制條件 | 找出模糊之處 | 確認後的規格 |
| 探索 | 確認範圍 | 檢查相關檔案與依賴項 | 上下文地圖 |
| 規劃 | 核准架構與取捨方案 | 建立有順序的任務計畫 | 審核過的計畫 |
| 實作 | 控管範圍 | 進行聚焦的程式碼變更 | 可審閱的差異（diff） |
| 驗證 | 定義預期行為 | 執行測試並檢查失敗項目 | 測試證據 |
| 審查 | 做出最終判斷 | 揭露風險與不一致之處 | 核准後的變更 |
| 上線 | 授權整合 | 總結工作內容與剩餘風險 | 附帶發布證據的審查後變更 |
Kimi Code 可以透過檢查儲存庫檔案、進行已核准的編輯,以及執行專案的驗證指令,來支援這個循環。
第一步:在要求程式碼之前先定義結果
在規定實作方式之前,先描述期望的行為。找出受影響的使用者或系統,定義任務的邊界,並加上變更後可供檢查的驗收標準。
來看一個簡單的例子。假設你想在現有的網頁應用程式中新增深色模式,你可能會向程式設計 Agent 提出這樣的請求:
Agent 可以照做,但它必須自行補上缺失的需求。它可能把切換開關放在介面錯誤的位置,或只把深色模式套用到單一頁面。產生出來的程式碼在技術上可能可以運作,但呈現的使用者體驗卻不對。
更有效的提示詞會在 Agent 開始編輯之前先定義好結果:
這個版本為 Agent 提供了明確的目標,避免它在無形中做出產品層面的決策。它也讓開發者有具體的方式來審查完成的成果——你不必問這項功能「看起來是不是做完了」,而是可以對照已陳述的需求檢查它的實際行為。
第二步:選擇合適的程式設計框架與模型
模型決定了 AI 對程式碼的理解與推理能力,而程式設計框架則決定了這些推理能否轉化為你專案中已驗證的變更。及早選定兩者,可避免你打造出一套建立在無法勝任該任務的工具之上的工作流程。
選擇能完成整個循環的框架
一個實用的程式開發框架不該只是產生程式碼片段。它需要能存取儲存庫、擁有編輯檔案的權限,並能執行專案現有的指令。當任務涉及多個檔案時,規劃支援與明確的核准機制也很重要。
讓模型與任務相匹配
快速修改可能只需要一個速度快的程式開發模型。複雜的除錯或跨檔案重構則需要更強的推理能力,以及足夠的上下文來理解周邊程式碼。此外,模型也應該能穩定地配合框架所提供的工具運作。
搭配 Kimi for Coding 使用 Kimi Code
Kimi Code 提供了一套完整的任務級開發框架。它能探索陌生的儲存庫、在編輯前先制定計劃、更新相關檔案,並針對實際專案執行測試。你可以透過終端機、瀏覽器,或相容的 IDE 來使用它。
針對第三方程式開發工具,Kimi Code 平台提供穩定版模型 Kimi K3。此模型可以在不需要變更客戶端設定的情況下升級。當迭代速度更重要時,highspeeed 模型能以相同的程式開發能力提供更高的輸出速度。
Kimi Code 與 Kimi 模型共同涵蓋了工作流程的兩端:模型負責處理程式碼推理,而框架則將這些推理結果轉化為可供審查的變更。
第 3 步:讓程式開發代理檢視專案
一旦明確了預期結果,就請代理找出目前控制該行為的程式碼。探索應該在進行任何檔案變更之前縮小任務範圍。
先從儲存庫的說明文件開始
先讓代理查看儲存庫本身提供的指引。這些內容可能存在於 README.md、CONTRIBUTING.md 或代理指示檔案等檔案中。有用的資訊包括專案實際使用的指令、程式碼慣例,以及不應執行的操作。
使用類似以下的提示詞:
回應應該指出它讀取了哪些指示檔案,並引用相關的指令。如果它提出的指令並未出現在儲存庫中,請在執行前先詢問該指令的來源。
在編輯前先找出相關程式碼
一份有用的上下文對應應列出具體的檔案,並說明每個檔案為何重要。僅列出大範圍的目錄是不夠的。如果回應遺漏了你知道涉及其中的共用工具程式,請在開始規劃前先修正這份對應。代理應該從行為的進入點開始追溯,一路查到它所依賴的模組。它也應該找出既有的測試,以及可供參考的類似實作(如果有的話)。
只在必要時加入外部上下文
當程式碼庫無法回答某個問題時,再引入外部文件。請提供確切的官方文件網址,或請代理自行找出官方來源。文件版本應與儲存庫中安裝的版本相符。錯誤日誌與問題描述也很有用,但在放入提示詞前,請先移除憑證或私人使用者資料。
在允許進行任何編輯之前,先檢查工作目錄並記錄現有的變更。完整的版本控制流程會在第 8 步中說明。
第 4 步:將規劃與執行分開
規劃與撰寫程式碼需要不同的審查重點。在規劃階段,你要判斷提出的方向是否符合系統需求。在實作階段,你則要檢查是否正確遵循了已核准的方向。
使用明確的「僅規劃、不寫程式碼」提示詞:
在核准計劃之前先進行審查。確認計劃在適當的情況下有使用現有的專案抽象層。留意隱藏的範圍擴大,尤其是需求中未提及的新依賴項或公開 API 變更。檢查提出的測試是否確實展示了要求的行為,而不只是執行了新寫的函式。
這個階段的產出是一份已核准的計劃。不能因為代理給出了一份詳細的回應,就視為「完成」。你應該自己編修這份計劃,或要求修改,直到假設條件與檔案範圍都準確無誤為止。
第 5 步:將計劃拆解為可審查的任務
每個實作任務都應該只有一個明確的目標,以及一種驗證結果的方式。這樣能讓變更保持在容易審查的規模,並讓出錯時更容易找出原因。
舉例來說,第 1 步中提到的深色模式功能可以拆解為以下任務:
檢視現有的色彩標記與主題相關樣式。
新增主題偏好設定,並儲存使用者的選擇。
將深色主題套用到共用的版面配置與元件。
在設定選單中加入主題切換選項。
為切換與儲存所選主題新增測試。
檢查主要頁面是否有視覺或無障礙方面的問題。
請依序完成這些任務,而不要要求代理一次實作整個功能。針對其中一個實作任務,可以使用類似以下的提示詞:
預期的結果是一項聚焦明確的程式碼變更,並附上實際執行過的測試。在進入下一個任務之前,請先審查這兩者。如果代理同時也新增了設定切換選項,或修改了不相關的元件,請先將這些變更分離出來或還原。
當代理在某個任務上反覆遇到困難時,請把任務拆得更小。例如,可以先請它只新增主題偏好設定,之後再實作持久化儲存。範圍較窄的任務能減少代理需要做出的假設,也能讓你在繼續之前有更明確的檢查點。
第 6 步:以緊密的循環進行實作、測試與檢視
一旦計劃拆解成可管理的任務後,就逐一完成它們。趁著每項變更的目的與範圍仍清晰時,及時審查。
對每個任務使用以下循環:
先從檢視差異開始。確認代理只變更了目前任務所需的檔案。如果修改內容包含了不相關的重構,或是規劃在後續步驟才要做的工作,請在執行測試前先移除或分離這些變更。
接著，使用該儲存庫已定義好的驗證指令。你通常可以在 package.json、專案文件或 CI 設定中找到它們。舉例來說，使用 npm scripts 的 JavaScript 或 TypeScript 專案可能會提供類似以下的指令：
先執行針對性的測試以更快得到回饋。如果通過了，再繼續進行更全面的檢查。成功執行時應該不會出現任何錯誤：
這些指令僅為範例。請勿在未確認專案實際使用的套件管理工具與腳本之前，就直接複製使用。Python 或 Go 專案會有不同的驗證流程，即使是兩個 JavaScript 專案，腳本名稱也可能不同。
額外提示：用 Kimi Code 實踐這套工作流程
Kimi Code 是以任務為單位運作，而不只是逐行處理。只要描述你想要的結果，它就能找出相關程式碼、提出實作計畫、更新必要的檔案，並執行專案的檢查。你收到的會是一個聚焦的變更供你檢閱，而不需要自己手動組裝每個步驟。
更快理解陌生的程式碼庫
Kimi Code 可以從進入點開始，追蹤執行流程並貫穿相關模組。它能識別相關測試與既有的專案模式，減少你手動蒐集檔案或解釋儲存庫運作方式所耗費的時間。
把程式碼以外的內容也納入任務
開發情境中經常包含錯誤截圖、設計參考、圖表或錄製的行為紀錄。Kimi Code 可以將多模態輸入與原始碼一併使用，幫助實作結果更貼近最初定義任務的證據。
在實際專案中測試變更
Kimi Code 可以在編輯後執行儲存庫既有的測試與品質檢查指令。如果某項檢查失敗，它會讀取實際的錯誤輸出並依此回饋繼續處理，這比一個從未被實際執行過的獨立程式碼建議更值得信賴。
把好的工作流程變成可重複的流程
Skills 可以保存重複性任務的指示，Hooks 則會在重要節點觸發預先定義的動作。MCP 讓 Kimi Code 連結到你團隊已在使用的工具，而 Plugins 可以把這些能力打包成更易於重複使用與分享的設定。
讓較長的任務持續推進
對於無法在一次短時間工作階段內完成的工作，/goal 可以為 Kimi Code 提供明確的目標與完成標準，讓它據以推進。它會追蹤跨多回合的進度，讓任務得以持續進行，而不需要你每次都重新陳述完整目標。
第 7 步：以維護者的角度審查 AI 產生的程式碼
在接受變更之前，親自閱讀最終的 diff。檢查程式碼是否如要求運作，並且是否符合既有專案的風格。
正確性
程式碼是否符合驗收標準？檢查正常的使用者流程以及至少一種錯誤情境。確認測試涵蓋了你要求的行為。
架構
程式碼是否遵循專案中既有的模式？邏輯應放在合適的模組中，並避免不必要的抽象層。
安全性
檢查新的輸入是否經過驗證，權限是否有被落實。確認記錄檔（logs）不會洩漏機密或個人資料。在接受任何新的相依套件前先進行審查。
可維護性
程式碼應該在沒有 Agent 解釋的情況下也能被理解。命名要清楚，註解則只需說明那些從程式碼本身看不出來的決策。
範圍
確認 diff 只包含當前任務所需的變更。移除無關的重構、非預期的介面變動，以及不必要的格式調整。
Agent 產生的摘要有助於審查，但無法取代閱讀程式碼本身。切勿發佈你無法解釋的程式碼。
第 8 步：在整個工作流程中使用版本控制
版本控制讓 AI 輔助的工作更容易檢查與復原。雖然這裡把它列為獨立的一步，但它的保護作用其實在 Agent 編輯任何檔案之前就已經開始。一開始就先檢查工作目錄，這樣才能區分既有工作與任務期間所做的變更。
在儲存庫根目錄開啟的終端機中執行以下指令：
git status --short
git diff --stat
git diff乾淨的起始工作目錄執行 git status --short 應該不會有任何輸出。如果已經有檔案被修改，記錄下來並告知 Agent 不要覆寫它們。每次任務完成後，再次檢查 diff。開發者應自行判斷已驗證的狀態是否適合建立版本控制的檢查點。
當某項實驗可能牽動許多檔案時，請使用獨立的分支或 worktree。並行的多個 Agent 不應編輯同一個工作目錄。為每個工作流程明確劃分檔案所有權，等其檢查通過後再進行整合。
不要在未經明確核准的情況下，讓程式碼 Agent 改寫歷史紀錄、捨棄本機工作內容、強制推送（force-push）或發佈變更。這些操作的影響範圍遠大於一般的檔案編輯，需要另外做出決定。
第 9 步：在多個編碼工作階段之間保留情境資訊
長時間的任務往往會超出單一對話的範圍。請把工程狀態保存在儲存庫的產物中，而不是仰賴對話紀錄。
保留一份簡短的功能文件，內容包含：
已核准的規格
已核准的實作計畫
已完成的任務與目前的 TODO 項目
改變原本做法的決策
已執行的指令與其最新結果
已知風險或未解決的問題
使用交接提示詞開始新的工作階段：
回應內容應與文件及目前的儲存庫狀態一致。在要求新工作階段繼續之前，先解決任何不一致之處。這種交接方式可減少 AI 編碼代理從不完整的對話紀錄中重建專案狀態的需求。
多代理 AI 編碼工作流程如何運作
多代理 AI 編碼工作流程會將不同角色分派給各個 agent。一個 agent 可能負責調查儲存庫，而另一個則審查已完成的差異（diff）。其價值來自職責分工，而不是同時開啟多個對話視窗。
一套實用的設定可包含以下角色：
**規劃者：**將需求對應到程式碼庫，並提出有序的計畫，但不編輯檔案。
**實作者：**在獨立的工作空間中完成範圍明確的任務。
**測試者：**檢查驗收標準，並獨立重現失敗情況。
**審查者：**檢查差異是否正確或存在隱藏風險，不預設實作一定正確。
**人類整合者：**核准決策、控制合併順序，並驗證整合後的結果。
當任務能被清楚拆分時，多代理工作流程效果最好。給每個 agent 相同的核准規格、分配明確的負責範圍，並使用獨立的分支或工作樹來避免衝突。對於小型修正或依賴單一變動檔案的任務，通常單一 agent 效率更高。
Kimi Code 可以將較大的任務拆分給多個具有獨立上下文的子 agent。透過 Agent Swarm，多個子 agent 可以並行處理任務的不同部分，再將結果回傳給主工作流程進行審查與整合。這能縮短執行時間，同時讓任務邊界與最終核准仍由你掌控。
依任務選擇合適的工作流程
並非每項編碼任務都需要相同程度的規劃。簡單的修正可以快速完成，而複雜或高風險的變更則需要在發布前進行更多審查。
**小型變更：**檢查相關程式碼，做出一項聚焦的修改，執行相關測試，並審查差異。
**中型功能：**撰寫簡短規格，核准實作計畫，並將工作拆分成幾個較小的任務完成。審查前先執行更廣泛的測試套件。
**高風險變更：**加入設計審查與回滾計畫。涉及身分驗證、付款或資料遷移的變更，可能還需要安全審查與分階段發布。
**多代理專案：**給每個 agent 相同的規格與明確的任務負責範圍。整合完各自的工作後，重新執行完整的相關測試。
Kimi Code 能支援上述每一種工作流程。對簡單任務使用輕量流程，並在變更較難復原或更可能影響使用者時，增加規劃與審查的力度。
可重複使用的 AI 編碼工作流程提示詞
此範本適用於任何編碼代理。將方括號中的欄位替換後，再提交給該 agent。
你可以將此作為 Kimi Code 的開場指令。隨著工作進展更新「目前階段」與「任務」，而不是用一個提示詞涵蓋整個功能。
結語
可靠的 AI 編碼工作流程的目標不在於盡量產生最多程式碼，而是在於及早暴露錯誤的假設，並讓每一項變更都易於審查。Kimi Code 透過讀取與編輯程式碼、執行殼層指令、擷取相關網頁內容，並隨任務進展調整其行動來支援這一流程。開發者仍需對架構與最終發布決策負責。從小型、可驗證的任務開始，只有在專案風險需要時才增加更多流程。
常見問題
kimi、kimi web 與 kimi acp。