從 PRD 到可驗證代碼：AI 需求開發閉環實踐
整理版優先睇
AI編碼閉環實踐：從PRD到可驗證代碼嘅工程框架
呢篇文章係作者基於RN（React Native）跨端開發經驗，提出一套AI編碼嘅工程框架。作者指出AI編碼最常見嘅問題唔係寫唔出code，而係缺少一套約束AI工作邊界、產物順序同驗證標準嘅流程。為咗解決呢個問題，作者設計咗一套「harness」流程框架，將prompts、commands、subagents、rules同門禁流程組織成開發約束，確保AI係合適嘅時候做合適嘅事，將一次性對話變成可追蹤嘅開發流水線。
流程嘅核心係將不確定性前移，將代碼生成後移。首先，AI會將PRD、接口文檔同Figma設計稿整理成需求規格（RequirementSpec），然後經人工審閲確認後，先進入架構設計（ArchitectureDesign）。架構設計通過後，由代碼生成Agent（code-generator）依據證據（接口字段、Figma節點等）生成RN/TypeScript代碼，並輸出架構對齊報告。之後經編譯驗證Agent（build-verifier）檢查lint、TypeScript編譯同構建，確保代碼可運行。最後由視覺審計Agent（visual-auditor）對照Figma檢查UI還原，偏差會迴流修復。完成後，經驗沉澱Agent（experience-depositor）將有效模式寫迴流程。
整體結論係：高效AI編碼唔係將人從流程中移除，而係重新分配職責——AI負責分析、生成、修復、驗證，人負責判斷需求是否正確、架構…
- AI編碼嘅瓶頸係缺乏工程框架約束；透過需求規格化、人工審閲、架構確認、證據驅動編碼、編譯驗證、視覺審計同經驗沉澱閉環，可以大幅減少返工。
- 流程要求先產出需求規格（RequirementSpec），所有關鍵結論標註來源，經人工審閲確認後先進行架構設計；代碼生成Agent必須按設計分塊執行計劃。
- 與「一句話生成代碼」做法唔同，呢套流程將不確定性前移、代碼生成後移，通過兩道人工門禁防止AI係錯誤基礎上快速生成大量代碼。
- 視覺審計要建立直讀審計（direct-read-audit），每個視覺常量追溯到Figma節點、屬性、原始值同RN mapping，確保UI還原有證據鏈。
- 團隊可以參考呢套流程建立自己嘅AI編碼框架，包括定義產物規範、人工審閲節點、自動化驗證閘口，並將經驗沉澱為SOP同檢查清單。
問題根源：AI編碼需要工程框架
作者指出AI編碼最常見嘅問題唔係寫唔出code，而係缺少一套約束AI工作邊界、產物順序同驗證標準嘅流程。
一次性對話變成可追蹤嘅開發流水線
為咗解決呢個問題，作者設計咗一套「harness」流程框架，將prompts、commands、subagents、rules同門禁流程組織成開發約束。
將不確定性前移，代碼生成後移
第一步：將輸入變做可審閲嘅需求規格
開發第一步唔係寫頁面，而係將PRD、接口文檔同Figma設計稿整理成
需求規格（RequirementSpec）
規格要寫清功能範圍、頁面結構、字段規則、接口依賴、狀態流轉、異常場景、埋點要求、Figma節點拆分同驗收標準。
關鍵結論都要標註來源，後續偏差才能回到證據本身定位
- 核心路徑是否完整
- 異常場景是否覆蓋
- 字段可信度是否標註
- Figma組件狀態同資源節點是否記錄
需求規格產出後先進入人工審閲，確認AI對業務同邊界嘅理解是否可靠。AI擅長整合信息，但字段缺失時係等接口補充、做本地兜底定調整交互口徑，需要人做決定。需求通過後，先進入架構設計（ArchitectureDesign）。
兩道人工門禁，防止AI係錯誤需求或錯誤架構上快速生成大量代碼
證據驅動編碼：按架構同設計稿生成代碼
代碼生成Agent（code-generator）按架構設計實施RN/TypeScript代碼，並輸出
架構對齊報告（ArchitectureAlignmentReport）
證明實現同架構一致。佢會先識別實現類型，例如列表頁、詳情頁、表單頁等，對應唔同嘅產物。
- 1 types.ts：定義接口類型
- 2 api.ts：封裝接口調用
- 3 hooks/state：狀態邏輯
- 4 leaf components：子組件
- 5 page container：頁面容器
- 6 route/web registration：路由同Web註冊
- 7 tracking/logging：埋點同日誌
實現前，根據設計分塊生成
執行計劃
每個block都有目標文件、目標組件、數據字段、交互同證據。
缺少落點時，唔可以硬寫代碼，只能係報告中標記blocked
視覺審計：UI還原要回到證據鏈
編譯通過只能說明代碼能跑，唔代表頁面還原正確。視覺審計Agent對照Figma檢查佈局、間距、字號、顏色、組件狀態等。
視覺審計不能只看整頁截圖
穩定做法係輸出偏差清單，迴流畀代碼生成Agent精準修復。修復時要遵守
直讀審計（direct-read-audit）
新增或調整嘅視覺常量必須追溯到設計稿原始值。
- 佈局結構是否一致
- 間距、字號、顏色是否還原
- 組件狀態是否正確
- 圖片資源是否正確加載
- 響應式表現是否對應設計
需求交付後，
經驗沉澱Agent（experience-depositor）
會將有效提示詞、常見失敗、修復方式等沉澱為SOP、檢查清單或模板。
把有效模式寫迴流程，下一個需求就能更早避開同類問題
總結：穩定嘅人機協作閉環
高效AI編碼唔係將人從流程中移除，而係重新分配職責。
AI負責分析、生成、修復、驗證，人負責判斷、確認、取捨、兜底
呢個係核心嘅分工原則。
- 將不確定性前移，代碼生成後移
- 所有產物同決策都可追溯
- 自動化驗證閘口：編譯驗證、視覺審計
- 人工負責判斷、確認、取捨、兜底
- 經驗沉澱閉環，流程越跑越穩
AI編碼（AI Coding）最容易被誤解成「一句話生成代碼」。真實項目入面，呢種方式前期好快，後期就成日因為需求冇對齊、接口字段唔穩定、設計圖還原偏差大而不斷返工。問題唔係在於AI唔識寫代碼，而係缺少一套能夠約束AI工作邊界、產物順序同驗證標準嘅工程框架。
呢度嘅解決思路係引入流程框架（harness）：將提示詞（prompts）、命令（commands）、子代理（subagents）、規則（rules）同門禁流程組織成一套開發約束。呢個框架唔負責取代工程判斷，而係規定AI幾時分析、幾時等審閲、幾時生成代碼、幾時一定要驗證，從而將「一次性對話」變成「可追蹤嘅開發流水線」。
呢套流程面向RN（React Native，跨端移動開發框架）需求開發，輸入包括產品需求文檔（PRD）、接口文檔同設計稿（呢度以Figma做例子）。AI負責分析、整理、生成、修復同審計；人負責判斷、確認、取捨同兜底。核心原則係將不確定性前移，將代碼生成後移，令實現可以追溯到需求、接口、設計同架構證據。
先統一幾個下文會成日出現嘅術語。佢哋喺項目入面通常都會以英文文件名、Agent名稱或自動化產物名出現，所以正文保留返對應原文，方便同實際工程產物對照：
需求規格（RequirementSpec）：將PRD、接口同設計稿整理成可以審閲嘅實現依據。 架構設計（ArchitectureDesign）：說明模塊拆分、數據流、文件落點同驗證策略。 Agent：承擔某類固定職責嘅AI子流程，例如代碼生成、編譯驗證、視覺審計。 代碼生成（code-generator）：按架構設計實現代碼，並說明實現係咪對齊架構。 架構對齊報告（ArchitectureAlignmentReport）：代碼生成後輸出嘅檢查結果，用嚟證明實現係咪符合架構設計。 編譯驗證（build-verifier）：執行lint、TypeScript編譯同構建檢查。 視覺審計（visual-auditor）：對照Figma檢查UI還原效果。 直讀審計（direct-read-audit）：記錄顏色、字號、間距等樣式值嚟自邊個設計節點。 產物（artifact）：流程入面生成嘅中間文件，例如接口字段表、Figma節點信息、資源映射表。
一、首先將輸入變成規格
開發嘅第一步唔係寫頁面，而係拆清楚輸入源。PRD提供業務目標、功能範圍同驗收口徑；接口文檔提供字段結構、錯誤碼同前後端邊界；Figma提供頁面結構、組件狀態、資源節點同交互細節。
呢啲信息如果直接撈埋入代碼生成，AI好容易會做經驗補全：接口冇寫字段就自己改名，PRD冇描述異常狀態就只做成功態，Figma冇讀到資源就用佔位圖。代碼越早生成，呢類隱性假設越難發現。
因此流程先要求AI產出需求規格RequirementSpec，而唔係直接實現。規格入面要寫清楚功能範圍、頁面結構、字段規則、接口依賴、狀態流轉、異常場景、埋點要求、Figma節點拆分同驗收標準。關鍵結論都要標註來源，之後嘅偏差先可以返到證據本身定位。
二、兩道人工門禁：需求審閲同架構確認
需求規格產出之後先進入人工審閲。審閲重點唔係改文案，而係確認AI對業務同邊界嘅理解係咪可靠：核心路徑係咪完整，異常場景係咪覆蓋，字段可信度係咪標註，Figma組件狀態同資源節點係咪記錄。AI擅長整合信息，但字段缺失嗰陣係等接口補充、做本地兜底，定係調整交互口徑，需要人決定。
需求通過之後，先進入架構設計ArchitectureDesign。架構設計要明確模塊拆分、目錄結構、組件分工、狀態管理、接口封裝、數據流、異常處理同驗證策略。對RN項目，仲要覆蓋平台差異、組件複用、路由註冊、埋點routeList（路由埋點清單）、響應式佈局同資源處理。
Figma喺架構階段唔會直接變成最終樣式值，而係形成「分塊到實現映射」同「直讀計劃」：邊個設計分塊落到邊個組件，綁定邊啲字段，後續代碼生成Agent（code-generator）要直讀邊啲nodeId（Figma節點ID）同屬性。兩道門禁嘅價值，係防止AI喺錯誤需求或錯誤架構上快速生成大量代碼。
三、代碼生成：按架構同證據執行
代碼生成Agent（code-generator）嘅職責唔係「睇需求寫TSX」，而係按架構設計實施RN / TypeScript（類型化JavaScript）代碼，並輸出架構對齊報告ArchitectureAlignmentReport，證明實現同架構一致。佢會先識別實現類型，例如列表頁ListPage、詳情頁DetailPage、表單頁FormPage、彈窗Popup、純接口APIOnly、純埋點TrackingOnly、工具方法Utility或數據模型Model；唔同類型對應唔同產物，新頁面仲可能涉及native route（客戶端路由）、web route（網頁路由）同埋點routeList。
實現之前，代碼生成Agent必須讀取需求規格、架構設計、接口字段產物、Figma summary（設計稿摘要）、codeHints（代碼生成提示）同項目規則。codeHints 會約束參考頁面、Figma樣式、限定文件、Web特殊處理同依賴變更；團隊經驗文檔亦會按RN頁面開發、RN UI組件庫、lint（靜態代碼檢查）、埋點等關鍵詞檢索之後再應用。
真正寫代碼之前，仲要根據架構設計入面嘅「分塊到實現映射」生成執行計劃。每個block（設計分塊）都一定要有目標文件、目標組件、數據字段、交互同證據。缺少落點嗰陣，唔可以硬寫代碼，只可以在架構對齊報告入面標記blocked（受阻）。
涉及Figma嗰陣，代碼生成Agent會先驗證磁盤產物係咪真實存在，包括元數據metadata、原始節點raw node、參考代碼reference code、覆蓋度審計coverage audit、資源映射asset mapping、單元契約unit contract同產物清單artifact manifest。文檔寫住已驗證verified唔夠，一定要以文件事實為準；缺少關鍵產物嗰陣，回推需求分析子流程requirement-analyzer補齊，禁止憑截圖手寫UI。
UI編碼前會生成 direct-read-audit.md。每個關鍵視覺常量都要能夠追溯到 node_id + 屬性名 + raw_value + RN mapping，即係「設計節點、樣式屬性、原始值、RN寫法」四者要對應返。顏色、字號、圓角、間距、邊框、陰影同圖片資源唔可以只係來自截圖感覺；截圖只用嚟做最終校準，唔作為首要編碼來源。
設計稿參考代碼Figma reference code係實現藍本，但需要適配到RN / ZRN UI（團隊RN組件庫）：div轉View，text轉Text，img轉Image，按鈕形態分組button-like frame轉ZRN Button或Pressable，CSS flex轉RN flexbox，陰影shadow拆成平台策略。組件複用之前核查ZRN UI嘅組件參數props、默認狀態、Web/Harmony可用性同樣式覆蓋方式；資源節點按資源映射asset mapping分類處理。
最終實現順序保持穩定：types.ts、api.ts、狀態邏輯hooks/state、子組件leaf components、頁面容器page container、路由同Web註冊route/web registration、埋點同日誌tracking/logging。實現結束之後生成架構對齊報告，覆蓋文件、分塊、接口字段、路由平台、ZRN UI與樣式、埋點、偏差同待驗證項。只有關鍵項全部通過（pass），先可以進入編譯驗證；如果發現缺失（missing），最多回流補全5輪，仍然冇辦法補齊就blocked。
四、編譯驗證：將「寫完」變成「可運行」
代碼生成完成並唔代表任務完成。編譯驗證Agent（build-verifier）會執行lint、TypeScript編譯同必要嘅網頁構建Web/build檢查；多平台場景下，仲會追加iOS、Android、Harmony相關打包產物bundle驗證。
編譯失敗嗰陣，AI唔單止貼出錯誤，而係自動定位並修復。常見問題包括模塊引入import路徑錯誤、類型不匹配、接口字段變更、平台後綴缺失、依賴誤用同lint規則唔滿足。只有錯誤確實嚟自外部環境或缺少人工決策嗰陣，先允許部分通過partial。
呢一步將「語義上看起來啱」嘅代碼推進到「項目工具鏈可以接受」。好多AI生成代碼嘅問題唔係思路錯，而係工程約束冇滿足，編譯驗證就係基礎質量閘口。
五、視覺審計：UI還原要返到證據鏈
編譯通過只能夠話明代碼可以運行，唔能夠說明頁面還原正確。視覺審計Agent（visual-auditor）會對照Figma檢查佈局、間距、字號、顏色、組件狀態、資源、響應式表現同多端差異。
下面係一組視覺審計對比樣例。左邊係Figma設計稿，右邊係RN實現效果。結論係：除咗標籤同虛線因為圖層複雜未被完整識別之外，其餘頁面結構、文本、圖片、間距、按鈕同刷新浮窗等核心元素都完成咗還原。
 |  |
視覺審計唔可以只係睇整頁截圖，亦唔可以發現問題之後就等人手動修。更穩定嘅做法係輸出偏差清單，迴流俾代碼生成Agent精準修復。修復嗰陣仍然遵守直讀審計direct-read-audit：新增或調整嘅視覺常量一定要能夠追溯到設計稿原始值Figma raw value。
六、經驗沉澱：令流程越跑越穩定
需求交付之後，經驗沉澱Agent（experience-depositor）會將有效提示詞、常見失敗、修復方式、組件複用經驗、Figma直讀規則、構建問題同視覺偏差沉澱為SOP（標準作業流程）、檢查清單或模板。將經驗寫返入流程之後，下一個需求先可以更早避開同類問題。
結語
高效嘅AI編碼唔係將人從流程入面拎走，而係重新分配職責。AI負責信息整理、代碼生成、錯誤修復同視覺審計；人負責判斷需求係咪正確、架構係咪可靠、取捨係咪符合業務目標。
呢套流程嘅關鍵唔係某一個提示詞，而係穩定嘅人機協作閉環：需求規格化、人工審閲、架構確認、證據驅動編碼、編譯驗證、視覺審計、經驗沉澱。只有前後鏈路都可追溯、可驗證、可迴流，AI先可以從「生成代碼嘅工具」變成「參與工程交付嘅協作者」。
AI 編碼（AI Coding）最容易被誤解成“一句話生成代碼”。真實項目裏，這種方式前期很快，後期卻常因需求沒對齊、接口字段不穩、設計圖還原偏差大而反覆返工。問題不在於 AI 不會寫代碼，而在於缺少一套能約束 AI 工作邊界、產物順序和驗證標準的工程框架。
這裏的解決思路是引入流程框架（harness）：把提示詞（prompts）、命令（commands）、子代理（subagents）、規則（rules）和門禁流程組織成一套開發約束。這個框架不負責替代工程判斷，而是規定 AI 什麼時候分析、什麼時候等待審閲、什麼時候生成代碼、什麼時候必須驗證，從而把“一次性對話”變成“可追蹤的開發流水線”。
這套流程面向 RN（React Native，跨端移動開發框架）需求開發，輸入包括產品需求文檔（PRD）、接口文檔和設計稿（這裏以 Figma 為例）。AI 負責分析、整理、生成、修復和審計；人負責判斷、確認、取捨和兜底。核心原則是把不確定性前移，把代碼生成後移，讓實現能追溯到需求、接口、設計和架構證據。
先統一幾個後文會反覆出現的術語。它們在項目中通常也會以英文文件名、Agent 名稱或自動化產物名出現，所以正文保留對應原文，方便和實際工程產物對照：
需求規格（RequirementSpec）：把 PRD、接口和設計稿整理成可審閲的實現依據。 架構設計（ArchitectureDesign）：說明模塊拆分、數據流、文件落點和驗證策略。 Agent：承擔某類固定職責的 AI 子流程，例如代碼生成、編譯驗證、視覺審計。 代碼生成（code-generator）：按架構設計實現代碼，並說明實現是否對齊架構。 架構對齊報告（ArchitectureAlignmentReport）：代碼生成後輸出的檢查結果，用來證明實現是否符合架構設計。 編譯驗證（build-verifier）：執行 lint、TypeScript 編譯和構建檢查。 視覺審計（visual-auditor）：對照 Figma 檢查 UI 還原效果。 直讀審計（direct-read-audit）：記錄顏色、字號、間距等樣式值來自哪個設計節點。 產物（artifact）：流程中生成的中間文件，例如接口字段表、Figma 節點信息、資源映射表。
一、先把輸入變成規格
開發的第一步不是寫頁面，而是拆清輸入源。PRD 提供業務目標、功能範圍和驗收口徑；接口文檔提供字段結構、錯誤碼和前後端邊界；Figma 提供頁面結構、組件狀態、資源節點和交互細節。
這些信息如果直接混進代碼生成，AI 很容易做經驗補全：接口沒寫字段就自己命名，PRD 沒描述異常狀態就只做成功態，Figma 沒讀到資源就用佔位圖。代碼越早生成，這類隱性假設越難發現。
因此流程先要求 AI 產出需求規格 RequirementSpec，而不是直接實現。規格里要寫清功能範圍、頁面結構、字段規則、接口依賴、狀態流轉、異常場景、埋點要求、Figma 節點拆分和驗收標準。關鍵結論都要標註來源，後續偏差才能回到證據本身定位。
二、兩道人工門禁：需求審閲和架構確認
需求規格產出後先進入人工審閲。審閲重點不是改文案，而是確認 AI 對業務和邊界的理解是否可靠：核心路徑是否完整，異常場景是否覆蓋，字段可信度是否標註，Figma 組件狀態和資源節點是否記錄。AI 擅長整合信息，但字段缺失時是等待接口補充、做本地兜底，還是調整交互口徑，需要人決策。
需求通過後，才進入架構設計 ArchitectureDesign。架構設計要明確模塊拆分、目錄結構、組件分工、狀態管理、接口封裝、數據流、異常處理和驗證策略。對 RN 項目，還要覆蓋平台差異、組件複用、路由註冊、埋點 routeList（路由埋點清單）、響應式佈局和資源處理。
Figma 在架構階段不會直接變成最終樣式值，而是形成“分塊到實現映射”和“直讀計劃”：哪個設計分塊落到哪個組件，綁定哪些字段，後續代碼生成 Agent（code-generator）要直讀哪些 nodeId（Figma 節點 ID）和屬性。兩道門禁的價值，是防止 AI 在錯誤需求或錯誤架構上快速生成大量代碼。
三、代碼生成：按架構和證據執行
代碼生成 Agent（code-generator）的職責不是“看需求寫 TSX”，而是按架構設計實施 RN / TypeScript（類型化 JavaScript）代碼，並輸出架構對齊報告 ArchitectureAlignmentReport，證明實現與架構一致。它會先識別實現類型，例如列表頁 ListPage、詳情頁 DetailPage、表單頁 FormPage、彈窗 Popup、純接口 APIOnly、純埋點 TrackingOnly、工具方法 Utility 或數據模型 Model；不同類型對應不同產物，新頁面還可能涉及 native route（客戶端路由）、web route（網頁路由）和埋點 routeList。
實現前，代碼生成 Agent 必須讀取需求規格、架構設計、接口字段產物、Figma summary（設計稿摘要）、codeHints（代碼生成提示）和項目規則。codeHints 會約束參考頁面、Figma 樣式、限定文件、Web 特殊處理和依賴變更；團隊經驗文檔也會按 RN 頁面開發、RN UI 組件庫、lint（靜態代碼檢查）、埋點等關鍵詞檢索後再應用。
真正寫代碼前，還要根據架構設計裏的“分塊到實現映射”生成執行計劃。每個 block（設計分塊）都必須有目標文件、目標組件、數據字段、交互和證據。缺少落點時，不能硬寫代碼，只能在架構對齊報告中標記 blocked（受阻）。
涉及 Figma 時，代碼生成 Agent 會先驗證磁盤產物是否真實存在，包括元數據 metadata、原始節點 raw node、參考代碼 reference code、覆蓋度審計 coverage audit、資源映射 asset mapping、單元契約 unit contract 和產物清單 artifact manifest。文檔寫着已驗證 verified 不夠，必須以文件事實為準；缺少關鍵產物時，回推需求分析子流程 requirement-analyzer 補齊，禁止憑截圖手寫 UI。
UI 編碼前會生成 direct-read-audit.md。每個關鍵視覺常量都要能追溯到 node_id + 屬性名 + raw_value + RN mapping，也就是“設計節點、樣式屬性、原始值、RN 寫法”四者要對應起來。顏色、字號、圓角、間距、邊框、陰影和圖片資源不能只來自截圖感覺；截圖只用於最終校準，不作為首要編碼來源。
設計稿參考代碼 Figma reference code 是實現藍本，但需要適配到 RN / ZRN UI（團隊 RN 組件庫）：div 轉 View，text 轉 Text，img 轉 Image，按鈕形態分組 button-like frame 轉 ZRN Button 或 Pressable，CSS flex 轉 RN flexbox，陰影 shadow 拆成平台策略。組件複用前核查 ZRN UI 的組件參數 props、默認狀態、Web/Harmony 可用性和樣式覆蓋方式；資源節點按資源映射 asset mapping 分類處理。
最終實現順序保持穩定：types.ts、api.ts、狀態邏輯 hooks/state、子組件 leaf components、頁面容器 page container、路由和 Web 註冊 route/web registration、埋點和日誌 tracking/logging。實現結束後生成架構對齊報告，覆蓋文件、分塊、接口字段、路由平台、ZRN UI 與樣式、埋點、偏差和待驗證項。只有關鍵項全部通過（pass），才能進入編譯驗證；如果發現缺失（missing），最多回流補全 5 輪，仍無法補齊則 blocked。
四、編譯驗證：把“寫完”變成“可運行”
代碼生成完成並不代表任務完成。編譯驗證 Agent（build-verifier）會執行 lint、TypeScript 編譯和必要的網頁構建 Web/build 檢查；多平台場景下，還會追加 iOS、Android、Harmony 相關打包產物 bundle 驗證。
編譯失敗時，AI 不只是貼出錯誤，而是自動定位並修復。常見問題包括模塊引入 import 路徑錯誤、類型不匹配、接口字段變更、平台後綴缺失、依賴誤用和 lint 規則不滿足。只有錯誤確實來自外部環境或缺少人工決策時，才允許部分通過 partial。
這一步把“語義上看起來對”的代碼推進到“項目工具鏈可以接受”。很多 AI 生成代碼的問題不是思路錯，而是工程約束沒滿足，編譯驗證就是基礎質量閘口。
五、視覺審計：UI 還原要回到證據鏈
編譯通過只能說明代碼能跑，不能說明頁面還原正確。視覺審計 Agent（visual-auditor）會對照 Figma 檢查佈局、間距、字號、顏色、組件狀態、資源、響應式表現和多端差異。
下面是一組視覺審計對比樣例。左側為 Figma 設計稿，右側為 RN 實現效果。結論是：除標籤和虛線因圖層複雜未被完整識別外，其餘頁面結構、文本、圖片、間距、按鈕和刷新浮窗等核心元素都完成了還原。
| |
視覺審計不能只看整頁截圖，也不能發現問題後讓人手動修。更穩定的做法是輸出偏差清單，迴流給代碼生成 Agent 精準修復。修復時仍遵守直讀審計 direct-read-audit：新增或調整的視覺常量必須能追溯到設計稿原始值 Figma raw value。
六、經驗沉澱：讓流程越跑越穩
需求交付後，經驗沉澱 Agent（experience-depositor）會把有效提示詞、常見失敗、修復方式、組件複用經驗、Figma 直讀規則、構建問題和視覺偏差沉澱為 SOP（標準作業流程）、檢查清單或模板。把經驗寫回流程後，下一個需求才能更早避開同類問題。
結語
高效的 AI 編碼不是把人從流程裏拿掉，而是重新分配職責。AI 負責信息整理、代碼生成、錯誤修復和視覺審計；人負責判斷需求是否正確、架構是否可靠、取捨是否符合業務目標。
這套流程的關鍵不是某一個提示詞，而是穩定的人機協作閉環：需求規格化、人工審閲、架構確認、證據驅動編碼、編譯驗證、視覺審計、經驗沉澱。只有前後鏈路都可追溯、可驗證、可迴流，AI 才能從“生成代碼的工具”變成“參與工程交付的協作者”。