1. 為什么不能讓 Codex 一口氣寫完整個前端先講一個我自己的翻車經(jīng)歷。早先用 Codex 寫前端的時候我干過一件特別偷懶的事把整個項目的需求往對話里一丟來一句“幫我寫一個完整的任務看板前端”然后看著它一行一行往外吐代碼。前 20 分鐘確實很爽頁面能跑組件也齊全但等我把功能往深了加問題就全冒出來了。1.1 一口氣寫完的三大坑上下文漂移、風格失憶、牽一發(fā)動全身第一個坑叫“上下文漂移”。Codex 本質上是基于上下文窗口推理的你讓它一口氣寫 30 個文件前 10 個文件里定義的變量名、組件接口寫到第 25 個文件的時候它可能已經(jīng)記不清了。最常見的表現(xiàn)就是前面用UserCard后面變成UserProfileCard前面接口字段叫user_name后面又冒出個username。代碼能跑但整個項目像是三個人各寫各的拼起來的。第二個坑是“風格失憶”。哪怕你在需求里寫明了“用 Tailwind不要寫 CSS 文件”它寫到后期也會偶爾給你插一段內聯(lián)樣式或者在某些地方用px固定寬度在另一些地方用rem。這種風格不統(tǒng)一的問題等代碼量上去之后改起來真要命。第三個坑最致命叫“牽一發(fā)動全身”。一個完整前端里頁面、組件、狀態(tài)管理、API 請求、路由是強耦合的。Codex 一次性生成時它會默認這個項目里只有自己寫的代碼一旦你中途說“這個列表改成卡片布局”它只會去改列表組件完全意識不到還要同步調整相關的空狀態(tài)、加載狀態(tài)、測試用例和路由參數(shù)。結果就是改一處崩三處你比不寫代碼的時候還累。1.2 Skills 的本質把“大任務”變成“小合約”后來我開始琢磨怎么才能讓 Codex 老老實實、一步一個腳印地干活。試過很多辦法最后發(fā)現(xiàn)最有效的是把 Skills 當成“小合約”來用。Skills 說白了就是一組結構化的指令文件每個文件描述一個特定子任務的背景、約束、輸入輸出和驗收標準。你可以把它理解成給新同事寫的崗位說明書——不是告訴他“你要好好工作”而是告訴他“你的職責是這些你的產出長這樣做完之后拿這個清單自檢”。我用 Skills 重新規(guī)劃前端開發(fā)之后Codex 的行為立刻就不一樣了。它不再是那個“一口氣憋個大招”的毛頭小子而是一個按流程辦事的熟練工拿到頁面任務它先看組件清單一個組件一個組件實現(xiàn)拿到邏輯任務它先理數(shù)據(jù)類型再寫 API 層最后才接 UI。每個階段它都清楚自己該做什么、不該做什么輸出質量肉眼可見地提升。注意Skills 不是提示詞模板不是“請你寫一個按鈕組件”這種一次性指令。它的價值在于沉淀和復用——這個項目能用下個項目微調一下還能用。2. 五組 Skills 怎么劃分頁面、邏輯、測試、構建、質量想明白了要拆接下來的問題是按什么標準拆我見過有人按頁面拆一個頁面一套 Skills結果頁面之間有大量公共邏輯Skills 之間互相打架。我也見過按技術棧拆的React 一套、Vue 一套但拆完發(fā)現(xiàn)同一個技術棧里頁面和邏輯的差異遠比跨技術棧大。2.1 劃分原則按“變更頻率”和“出錯代價”拆我自己實踐下來靠譜的依據(jù)是兩個維度變更頻率和出錯代價。前端代碼里頁面的變更頻率最高——產品經(jīng)理三天兩頭改布局、換文案、調間距。邏輯狀態(tài)管理、API 封裝、業(yè)務規(guī)則變更頻率中等但出錯代價很高一個邊界條件沒處理線上就是白屏或者數(shù)據(jù)錯亂。測試的變更頻率跟著邏輯和頁面走但它的核心價值在于“兜底”必須單獨管。構建相關的代碼變更頻率最低但一出錯就是全軍覆沒而且排查難度大也需要獨立上下文。按照這個邏輯我最后沉淀出五組 Skills分組管什么不管什么出錯代價page頁面結構、組件實現(xiàn)、樣式、布局、響應式數(shù)據(jù)獲取、業(yè)務判斷中l(wèi)ogic類型定義、API 層、狀態(tài)管理、錯誤處理UI 渲染、樣式高test單元測試、組件測試、E2E 冒煙測試業(yè)務實現(xiàn)中build構建配置、環(huán)境變量、代碼分割、產物分析業(yè)務代碼極高quality代碼審查、規(guī)范校驗、提交信息、README具體功能開發(fā)低2.2 分組總覽五組 Skill 的職責邊界看到這個表你可能會問quality 這一組是不是多余的頁面、邏輯、測試、構建已經(jīng)覆蓋了整個開發(fā)流程為什么還要單獨拆一組出來原因很簡單前四組保證的是“把東西做出來”quality 這一組保證的是“把東西做得像樣”。Codex 寫代碼有一個特點單看每個模塊都還行但合在一起看你會發(fā)現(xiàn)命名不一致、工具函數(shù)重復寫了好幾個、組件 props 設計得亂七八糟。這些小問題不致命但累積起來項目維護成本會飆升。必須有一個專門的關卡去做整體審查。我給每一組 Skill 都定了明確的邊界。page 組只管“用戶看得到的東西”它不負責決定數(shù)據(jù)從哪來logic 組只管“數(shù)據(jù)怎么流轉”它不關心按鈕是什么顏色test 組負責織一張安全網(wǎng)但它不重寫業(yè)務代碼build 組負責最后把產物體面地交出去但它不摻和業(yè)務邏輯quality 組則凌駕于前四組之上做交叉檢查和收尾。這五個分組不是拍腦袋想出來的是我在幾個真實項目里反復調整后的結果。最早我只分了三組UI、邏輯、構建后來發(fā)現(xiàn)測試沒人管一改代碼就提心吊膽于是加了 test再后來發(fā)現(xiàn) Codex 提交的代碼雖然能跑但質量參差不齊又加了 quality。現(xiàn)在這個結構基本穩(wěn)定了我拿到一個新前端項目第一件事就是把這五組 Skills 的框架搭好再讓 Codex 進場干活。3. 頁面 Skills把界面拆成組件清單再動手頁面 Skills 是我最早寫的一組也是迭代次數(shù)最多的一組。一開始我寫得太粗就一句“用 React 和 Tailwind 寫一個任務卡片組件”結果 Codex 交出來的東西從組件命名到樣式實現(xiàn)都不符合項目風格。后來我總結出一個規(guī)律頁面類任務一定要讓 Codex 先出清單再動手寫代碼。3.1 SKILL.md 里放什么內容以我之前做的“團隊任務看板”項目為例page 組 SKILL.md 的核心內容大致是這么幾塊# Page Skill - 任務看板前端頁面實現(xiàn) ## 技術棧約束 - React 18 TypeScript只允許使用函數(shù)組件和 Hooks - 樣式統(tǒng)一用 Tailwind CSS禁止書寫自定義 CSS 文件 - 組件庫使用項目內的基礎組件禁止從零實現(xiàn)下拉、彈窗等通用交互 ## 開工前必須完成組件清單 - 列出當前頁面涉及的所有組件 - 標注每個組件的 props 接口和職責邊界 - 標注哪些組件是公共組件哪些是頁面私有組件 ## 實現(xiàn)順序 1. 先實現(xiàn)無狀態(tài)展示組件 2. 再實現(xiàn)包含交互邏輯的組件 3. 最后組裝成頁面 ## 樣式規(guī)范 - 使用 design-token 里定義的顏色和間距禁止自創(chuàng)色值 - 寬度單位統(tǒng)一使用 rem禁止使用 px - 必須處理 375px、768px、1280px 三檔響應式 ## 驗收清單 - 頁面在三種斷點下無橫向滾動 - 所有交互元素都有 hover 和 focus 狀態(tài) - 無未使用的 import 和變量 - 組件職責單一無超過 200 行的組件為什么強調“先出組件清單”這個動作因為 Codex 在生成代碼時有個毛病它會按自己的理解直接寫而不是先想清楚整體結構。讓它先列清單相當于強迫它做一次設計。你去看它列出的清單如果某個組件職責描述得含糊或者公共組件和私有組件混在一起你就能在寫代碼之前發(fā)現(xiàn)問題這時候糾錯成本幾乎為零。3.2 實操中讓頁面 Skills 真正生效的三個細節(jié)光有 SKILL.md 還不夠我在實操里還摸出幾個容易踩的細節(jié)。第一交互組件和展示組件要分開。展示組件只管渲染數(shù)據(jù)比如任務卡片、狀態(tài)標簽、用戶頭像交互組件管用戶操作比如篩選器、拖拽排序、彈窗編輯。拆開之后Codex 寫展示組件的時候不需要關心數(shù)據(jù)從哪來寫交互組件的時候不需要糾結樣式細節(jié)兩邊都輕松。第二樣式規(guī)范里一定要寫死設計令牌。前端頁面最怕 AI 自由發(fā)揮顏色和間距一個頁面出現(xiàn)十幾種灰色是家常便飯。我在 SKILL.md 里直接給出一份design-token的約定主色#4F46E5、成功色#16A34A、危險色#DC2626間距只允許使用4px的整數(shù)倍。Codex 有了明確的顏色和間距錨點產出的頁面視覺統(tǒng)一性會好很多。第三驗收清單要讓 Codex 自己執(zhí)行。我之前總是寫完代碼讓 Codex 再檢查一遍但它經(jīng)常敷衍了事說“看起來沒問題”。后來我改成在驗收清單里寫明確的可執(zhí)行驗證項比如“檢查是否有組件超過 200 行”“檢查是否包含未使用的變量”逼著它自己跑 lint 或者逐項核查效果比一句“請檢查代碼質量”好得多。3.3 常見翻車場景布局和間距為什么會失控頁面 Skills 用了這么久翻車最多的還是布局和間距。Codex 對“讓這個區(qū)域水平居中”的理解經(jīng)常是 “margin: 0 auto” 或者 “flex justify-content: center”結果在不同父容器下表現(xiàn)完全不一樣。我的解決辦法是在 SKILL.md 里增加一個“布局約定”小節(jié)明確說明復雜布局一律使用 flex 或 grid禁止使用 float 和絕對定位頁面級容器統(tǒng)一用mx-auto max-w-7xl px-4組件間距使用gap而不是margin。這些約束看起來瑣碎但正是這些瑣碎的約定讓 Codex 產出的頁面從“看著還行”變成了“真的能上線”。4. 邏輯 Skills先定數(shù)據(jù)流再寫業(yè)務代碼頁面寫出來只是空殼真正的前端難點在邏輯層。我在用 Codex 的過程中發(fā)現(xiàn)如果你不單獨給邏輯寫一套規(guī)則它會把邏輯代碼和 UI 代碼攪成一鍋粥——組件里直接發(fā)請求、業(yè)務判斷寫進 JSX、錯誤處理隨手 throw 一個字符串這些都是常見的“自來熟”寫法。4.1 邏輯 Skills 的核心三大模塊我設計的 logic 組 Skills 固定管三塊東西類型與接口、API 層、狀態(tài)管理。類型與接口是地基。我會要求 Codex 在寫任何邏輯代碼之前先用 TypeScript 定義完整的領域模型比如任務Task有哪些字段、狀態(tài)機的取值有哪些、接口返回的數(shù)據(jù)結構長什么樣。這一步做好之后后面所有代碼都基于這些類型來寫類型不匹配的問題會大大減少。API 層是進出數(shù)據(jù)的大門。所有網(wǎng)絡請求必須走統(tǒng)一的api/目錄使用統(tǒng)一的請求實例配置好 baseURL、超時時間、鑒權頭禁止在組件里直接調fetch或axios.get。每個 API 函數(shù)都返回類型化的 Promise錯誤統(tǒng)一拋ApiError。狀態(tài)管理負責的是跨組件共享的數(shù)據(jù)。我用的是 Jotai所以在 SKILL.md 里定義的狀態(tài)管理規(guī)范是原子化的數(shù)據(jù)寫在store/目錄下派生狀態(tài)用selector完成異步更新走統(tǒng)一的異步流程。對于只有組件內部使用的狀態(tài)明確要求用useState不要動不動就上全局 store。# Logic Skill - 業(yè)務邏輯與數(shù)據(jù)流實現(xiàn) ## 核心原則 - 組件內禁止直接調用 fetch / axios必須通過 api/ 目錄 - 業(yè)務判斷禁止散落在組件里抽成純函數(shù)放入 utils/ - 所有異步操作必須處理 loading、error、empty 三種狀態(tài) ## 數(shù)據(jù)類型先行 - 先繪制數(shù)據(jù)模型字段命名使用 camelCase - 接口返回的字段要在 api/ 層完成映射杜絕 snake_case 泄漏到組件層 ## 錯誤處理 - 網(wǎng)絡錯誤統(tǒng)一拋出 ApiError包含 status、message、detail - 組件層只能通過 useEffect 或 Suspense 消費錯誤 - 禁止使用 console.log 調試統(tǒng)一使用項目內 logger ## 驗收清單 - 類型定義覆蓋所有接口返回結構和請求參數(shù) - 無組件直接調用請求方法 - 無 any 類型除第三方庫無類型聲明的情況4.2 實操順序為什么必須“數(shù)據(jù)先行”剛開始用 logic Skills 時我犯過一個錯誤讓 Codex 按 UI 組件順序逐個實現(xiàn)邏輯結果組件 A 定義了數(shù)據(jù)類型組件 B 又有自己的版本兩邊數(shù)據(jù)流完全對不上。后來我把 SKILL.md 里的流程改成了“數(shù)據(jù)先行”第一步讓 Codex 輸出完整的領域模型類型定義這是所有邏輯代碼的共同語言第二步基于這些類型寫 API 層函數(shù)第三步寫狀態(tài)管理和業(yè)務純函數(shù)第四步才是讓 UI 層消費這些數(shù)據(jù)和函數(shù)。這個順序的好處是每一層的輸入輸出都是清晰的。API 層的輸入是“用戶要看哪個任務”輸出是Task對象狀態(tài)管理層的輸入是 API 層的結果輸出是組件可用的數(shù)據(jù)流。Codex 按照這個順序來寫就不會出現(xiàn)“為了一個列表頁臨時在組件里定義接口類型”這種土辦法。4.3 讓 Codex 把狀態(tài)窮舉完而不是只處理主流程我踩過一個特別深的坑Codex 寫的邏輯代碼總是只處理“happy path”也就是最順利的那條路徑。任務加載成功、列表有數(shù)據(jù)、用戶點擊正常這些場景它處理得很流暢但你要讓它處理加載失敗、列表為空、權限不足、接口超時它就比較敷衍經(jīng)常是直接catch (e) {}靜默吞掉。后來我在 LOGIC SKILL.md 里加了一條硬性要求“所有異步操作必須處理 loading、error、empty 三種狀態(tài)缺一不可?！辈⑶野阉鼘戇M驗收清單。Codex 收到這個約束之后寫出來的代碼明顯更規(guī)范——列表加載時顯示骨架屏、加載失敗顯示錯誤提示和重試按鈕、數(shù)據(jù)為空時顯示空狀態(tài)文案。提示這一步非常關鍵。讓 AI 寫業(yè)務邏輯一定要把“異常路徑”作為顯式要求寫進約束里否則它只會給你一個“看起來能用”的實現(xiàn)而真實用戶永遠會走你沒想到的路徑。5. 測試 Skills讓 AI 給后續(xù)修改兜底測試這一組是我最晚加的但也是現(xiàn)在最離不開的。為什么單獨拆出來因為我發(fā)現(xiàn)讓 Codex 在同一個上下文里既寫實現(xiàn)又寫測試它總是先寫完實現(xiàn)然后草草補幾個測試用例應付你。這些測試跑起來全綠但仔細看全是“調用了一個函數(shù)沒報錯”這種毫無營養(yǎng)的斷言。5.1 測試 Skills 的職責邊界與配置我把 test 組 Skills 定義成“獨立于業(yè)務實現(xiàn)的質檢工序”它包含三個層面層級工具覆蓋范圍單元測試Vitest純函數(shù)、工具函數(shù)、數(shù)據(jù)類型轉換組件測試React Testing Library組件渲染、交互、狀態(tài)展示E2E 冒煙測試Playwright核心用戶流程登錄、創(chuàng)建任務、完成任務配置上我固定了兩條規(guī)則。第一所有測試文件放在被測模塊旁的__tests__目錄用xxx.test.tsx命名這樣 Codex 在改某個組件的時候能很容易看到對應的測試第二覆蓋率閾值定在 80%分別在lcov報告里統(tǒng)計語句、分支、函數(shù)、行覆蓋率跑不到就視為失敗。5.2 實操如何讓 Codex 寫出有價值的測試讓 AI 寫測試最大的問題是它只會寫“成立的測試”。所謂成立的測試就是找個輸入跑一遍斷言輸出不是undefined就當作完成。這種測試對維護毫無價值。我在 TEST SKILL.md 里的對策是要求 Codex 針對每個函數(shù)列出至少三個用例——正常輸入、邊界輸入、異常輸入并且每個用例必須使用具體的輸入值和期望輸出禁止使用模糊斷言。比如測試一個formatTaskTime(timestamp: number): string函數(shù)你讓它寫三個用例傳一個有效時間戳斷言返回格式化的日期字符串傳 0 或負數(shù)斷言返回空字符串或拋出異常傳一個超出范圍的極端時間戳斷言不會崩潰且格式正確。有了這類具體要求Codex 寫測試的認真程度會提升好幾個檔次。組件測試也一樣。我要求每一個交互型組件必須覆蓋以下場景初次渲染時各個狀態(tài)是否正確展示用戶執(zhí)行核心操作后回調函數(shù)是否被調用且參數(shù)正確異步操作成功和失敗時的 UI 反饋。這三個場景寫全比寫十來個空泛的“渲染無報錯”有用得多。5.3 避坑指南AI 寫測試常見的三個歪招和 Codex 磨合測試 Skill 的過程中我遇到過三類特別典型的“應付式測試”這里直接列出來。第一類是“全覆蓋但全無效”。AI 會生成十幾個測試文件每個測試文件里都有好幾個用例你以為覆蓋得不錯了仔細一看全是expect(element).toBeInTheDocument()沒有任何交互和斷言。第二類是“過度 mock”。為了不讓測試碰到真實依賴AI 會把所有東西都 mock 掉包括它自己剛寫好的模塊導致測試結果完全失真。第三類是“污染全局狀態(tài)”。測試里改變了一些 module 級變量跑完不清理后面的測試用例全被帶偏。針對這三類問題我的 TEST SKILL.md 里寫死了三條禁令禁止出現(xiàn)沒有行為的斷言禁止 mock 當前被測模塊內部依賴所有測試必須在afterEach中清理副作用。有了這三條Codex 的測試質量穩(wěn)定了很多。6. 構建 Skills把產物體面地交出去構建階段是很多 AI 編程工具最糟糕的環(huán)節(jié)之一。原因很好理解構建報錯往往不是業(yè)務代碼的問題而是環(huán)境變量、依賴版本、打包配置這些“周邊因素”導致的而 Codex 在寫業(yè)務代碼時的上下文里根本沒有這些信息。它連報錯日志都沒看全就開始瞎猜“可能是這個依賴版本有問題”然后胡亂升級依賴反而把項目搞壞了。6.1 構建 Skills 的核心內容我的 build 組 Skills 專注于四件事構建配置、依賴管理、產物質量、環(huán)境區(qū)分。構建配置包括 Vite 配置文件里的別名、代理、打包 chunk 規(guī)則。依賴管理的關鍵是鎖定依賴版本我明確要求 Codex 只通過包管理器的lock文件檢查依賴樹禁止直接修改package.json里的版本號。產物質量指的是構建完成后必須檢查dist/目錄的大小、chunk 數(shù)量、各個頁面的入口文件、是否有異常大的資源。環(huán)境區(qū)分是要求 Codex 使用import.meta.env或process.env按環(huán)境區(qū)分配置接口地址、上傳域名、埋點開關都不能寫死。# Build Skill - 構建流程問題排查與產物優(yōu)化 ## 判斷步驟必須按順序執(zhí)行 1. 完整讀取報錯日志提取關鍵錯誤信息 2. 檢查 package.json 和 lock 文件確認依賴狀態(tài) 3. 檢查 vite.config 和 tsconfig 配置 4. 定位報錯涉及的具體文件和依賴關系 ## 依賴管理規(guī)則 - 禁止直接修改依賴版本號 - 報錯指向依賴問題時先提供完整的 error stack 和運行環(huán)境 - 更新依賴后必須執(zhí)行完整構建驗證 ## 產物質量要求 - 構建成功后在 dist/ 中找到各路由對應的 html 入口 - 檢查 chunk 數(shù)量單個 chunk 超過 200KB 需要拆分 - 確認靜態(tài)資源引用路徑正確無 404 ## 多環(huán)境配置 - 開發(fā)、測試、生產環(huán)境必須使用獨立的環(huán)境變量文件 - 接口地址、上傳域名等配置必須在環(huán)境變量中禁止硬編碼6.2 讓 Codex 排查構建報錯的標準姿勢我自己總結出了一個比較管用的配合方式遇到構建報錯時不直接把報錯丟給 Codex而是先做一步預處理——把報錯信息、復現(xiàn)步驟、當前運行環(huán)境Node 版本、包管理器版本、系統(tǒng)架構整理成一封“病歷報告”再發(fā)過去。原因很簡單Codex 的上下文窗口是有限的你把完整且結構化的問題描述給它它才有足夠的信息做推斷如果你直接復制一大段終端日志它會被無關信息干擾或者被日志截斷影響判斷。我在 BUILD SKILL.md 里專門加了一節(jié)“問題描述模板”要求 Codex 在處理構建問題時先按模板輸出自己的理解報錯出現(xiàn)在哪個階段依賴安裝、編譯、打包、部署前檢查、涉及哪些文件、可能的觸發(fā)條件是什么。這個步驟看起來額外耗時但它能幫 Codex 在動手之前理清思路排查成功率明顯提高。6.3 構建產物體積失控讓 Codex 自己分析前端構建還有一個常見問題是產物越來越大首次訪問越來越慢。這個問題的排查思路也是 AI 擅長的分析產物構成。我讓 Codex 跑構建之后把dist/目錄的文件大小列表拉出來用可視化的依賴分析插件檢查哪個第三方庫占了大頭。Codex 能快速識別出“某個表格組件引了完整包”“某個圖表庫沒按需加載”這類典型問題然后建議用按需導入或動態(tài)導入拆分。實際項目里我遇到過最夸張的一次一個詳情頁首屏加載了 1.2MB 的 JS其中一個圖表庫占了 800KB最后改成按需導入后直接降到 300KB。這個優(yōu)化如果憑我自己在密密麻麻的依賴關系里找至少要折騰一上午Codex 配合 build Skill 十幾分鐘就搞定了。7. 質量 Skills最后一道代碼審查關卡前面四組把開發(fā)流程跑通了但你會發(fā)現(xiàn)代碼雖然能跑、有測試、能構建整體上還是有點“野”。命名不一致、重復代碼、組件邊界混亂、注釋和代碼對不上……這些問題單個看不致命但累積到一定量維護效率會急劇下降。所以第五組 Quality Skills 是專門做“整體把關”的。7.1 讓 Codex 以“資深 Review 者”身份工作Quality 組最常見的用法是在所有功能開發(fā)完成后讓 Codex 扮演一個資深前端工程師的角色對全項目做一次代碼審查。我的 Quality SKILL.md 里定義了一個審查清單審查維度具體檢查項一致性命名風格、API 封裝規(guī)范、錯誤處理方式是否統(tǒng)一簡潔性是否存在重復代碼、冗余組件、無用依賴健壯性關鍵路徑是否有異常處理、邊界條件是否覆蓋可維護性組件是否過大、職責是否清晰、類型是否明確和直接說“幫我 review 一下代碼”相比把審查維度拆細之后Codex 能給出更具體的問題列表。我實測下來它能發(fā)現(xiàn)不少真問題某個組件在其他地方已有類似實現(xiàn)、某個 API 函數(shù)既沒有統(tǒng)一錯誤處理也沒有取消機制、某個動畫庫其實完全可以用純 CSS 實現(xiàn)。這些問題靠人工自查很容易漏掉。7.2 讓 Codex 輸出“問題清單”而不是“直接改代碼”這里有一個很重要的操作細節(jié)質量審查階段不要讓 Codex 直接改代碼而是讓它先輸出一份“問題清單”每條問題標注嚴重級別和建議修復方案由你來決定改哪些、怎么改。為什么這么設計因為 Codex 在自由發(fā)揮“修問題”的時候經(jīng)常會好心地改變原有實現(xiàn)邏輯造成不必要的回歸風險。它自己改出來的代碼又需要重新測試、重新審查等于把剛才的流程再走一遍。相比之下問題清單的方式更符合“人做決策、AI 做執(zhí)行”的原則你來判斷哪些問題值得修、哪些可以保留然后逐條指派給它做定向修復。7.3 附帶的規(guī)范收尾README 和提交信息Quality Skills 里還可以掛一些收尾性質的內容比如讓 Codex 生成項目的 README、更新啟動文檔、規(guī)范 git commit message。這些內容不涉及核心邏輯但對項目交付體驗影響不小。我在實際項目里最后會讓 Codex 根據(jù)最終代碼狀態(tài)重寫一份 README把啟動命令、環(huán)境變量說明、技術棧列表都寫清楚省去自己回憶和整理的時間。commit message 我也在 Quality Skills 里定了一個模板type(scope): subject比如feat(task): add drag sort。讓 Codex 在提交前跑一遍git diff --stat概括本次改動然后按模板生成提交信息。這樣提交歷史看起來非常干凈回滾和排查問題都方便。8. 常見問題與排查技巧實錄Skills 這套玩法用了幾輪之后我也積累了一些解決問題的經(jīng)驗。這里挑幾個高頻問題集中說一下希望能幫你少走彎路。8.1 Codex 不遵守 Skills 怎么辦最常遇到的問題就是明明寫了 SKILL.mdCodex 還是按自己的想法亂來。我的排查思路有三步。先確認 Skill 文件是否真的被正確加載了很多 CLI 工具對 Skill 目錄的命名、路徑有嚴格要求比如必須放在.codex/skills/或者~/.codex/skills/放錯位置等于白寫。再確認 SKILL.md 里的指令是否足夠明確像“請盡量遵循規(guī)范”這種話 AI 根本不會認真執(zhí)行必須改成“禁止使用 px”“必須在組件清單完成后才能開始寫代碼”這種可驗證的命令式語句。最后確認上下文里是否混入了舊規(guī)則有時候前面對話里已經(jīng)出現(xiàn)了和 Skills 沖突的指令AI 會優(yōu)先聽最近的消息。8.2 Skills 之間互相沖突怎么辦多組 Skills 同時存在時偶爾會打架。比如 page 組讓 Codex 在組件里直接展示數(shù)據(jù)logic 組又禁止組件里直接發(fā)請求。遇到這種情況我在 SKILL.md 里加了一個“優(yōu)先級聲明”logic 組的約束優(yōu)先于 page 組build 組的約束優(yōu)先于一切業(yè)務代碼。這樣沖突出現(xiàn)時Codex 就有明確的裁決依據(jù)而不是隨機挑一個聽。8.3 上下文不夠用怎么辦Codex 的上下文窗口有限項目一大對話一長它就記不住前面聊了什么。我的做法是“任務緩存”每個階段結束后把結論沉淀進一個項目備忘錄文件比如“已完成組件清單”“已定義類型清單”“已確認的接口字段”下一個階段開始時先讓它讀這個備忘錄再干活。這樣做比讓它硬記整段對話可靠得多。8.4 什么時候該自己上手寫最后說一個很多人都忽視的問題Skills 再完善Codex 也不是萬能的。我的經(jīng)驗是核心業(yè)務邏輯里涉及復雜規(guī)則的部分、對性能要求極高的渲染路徑、設計稿里那種特別精細的視覺還原這三類任務還是自己動手更靠譜。Skills 的真正價值不在于讓 AI 全包而在于把你定義好的流程跑熟練讓機械性的工作量減少 80%把省下來的精力集中在真正需要人判斷的地方。實測問題原因解決方式Skill 文件加載無效目錄結構不符合工具約定檢查 Skill 目錄位置和命名確認文件名規(guī)范AI 無視樣式約束指令寫得太軟將約束改成可驗證的規(guī)則如“禁止 px”測試寫了等于沒寫斷言太寬松要求每個函數(shù)至少三個用例含邊界和異常構建報錯排查不準問題信息不完整按“病歷報告”模板提供完整上下文上下文過長導致遺忘對話歷史超限使用項目備忘錄沉淀階段性結論我個人現(xiàn)在最深的體會是把前端拆成五組 Skills表面上是給 AI 寫說明書實際上是在逼我自己把開發(fā)流程想清楚。AI 有沒有變強不好說但我的項目比之前規(guī)范了不止一個量級。最后再分享一個小技巧每組 Skills 的末尾都留一個“驗收清單”小節(jié)讓 Codex 在完成任務后逐項自檢這一步能幫你省掉大量的低級返工。