上一篇我給出了審查 Codex 前端差異的順序先固定審查對象再把差異映射回任務目標然后沿用戶路徑檢查正確性最后核對驗證證據。這篇繼續往下落整理成一份可以重復使用的清單。我把差異審查分成三層正確性目標行為有沒有真正實現范圍實際修改有沒有遺漏或越界副作用沒有寫在目標里的其他行為是否被改變。這三層看起來有重疊關注點其實不同。正確性問“新行為對不對”范圍問“改了該改的地方沒有”副作用問“其他行為還和以前一樣嗎”。只有三層都能給出證據我才會接受一批 AI 生成的前端差異。審查前先準備四份基線清單不能脫離任務獨立使用。開始前我會準備任務基線用戶要解決的問題目標行為保持不變的行為正常、失敗和邊界驗收標準。范圍基線允許修改的位置修改前需要確認的公共位置明確禁止的目錄和無關工作。影響基線直接、間接和條件性調用方必須修改、必須回歸和明確排除的位置狀態、副作用、生命周期和樣式依賴。差異基線對比哪個分支、提交或任務開始前狀態當前工作區是否包含用戶已有修改新增、刪除、重命名、暫存和未暫存文件怎樣處理。如果其中一份基線缺失清單中的很多問題都無法作出判斷。第一層正確性審查正確性不是看代碼有沒有明顯報錯而是檢查實現與需求之間的對應關系。1. 目標是否被完整實現每個用戶目標是否有對應差異是否只實現了可見入口沒有接通數據與結果是否只覆蓋正常路徑是否遺漏失敗、空值、權限或連續操作是否把“部分完成”寫成“全部完成”。2. 數據是否正確流動輸入來自正確來源嗎狀態是否仍有唯一可信來源頁面、組件和請求之間的數據轉換是否明確空值、默認值和可選字段是否保持語義保存后使用的是服務端結果、表單值還是舊列表數據刷新、排序、篩選和頁碼是否仍然一致。3. 組件契約是否正確Props 類型、必填和默認值是否符合需求Emits 名稱、時機和負載是否匹配調用方v-model是否正確雙向更新插槽作用域和默認內容是否改變暴露方法的參數、返回值和調用時機是否兼容屬性和事件是否透傳到正確節點。4. 異步流程是否閉合Loading 在所有出口都能恢復嗎重復點擊是否受到控制請求失敗后狀態是否可繼續操作舊請求是否可能覆蓋新狀態關閉或卸載后異步結果會寫到哪里成功、失敗、取消和異常分支是否都有明確收尾。5. 生命周期是否正確初始化發生在首次掛載還是每次打開Props 變化后是否正確更新關閉時清理哪些狀態重新打開是否殘留舊數據和校驗路由返回、頁面緩存和組件重用是否恢復正確清理動作是否早于調用方需要的數據。6. 用戶體驗是否符合任務按鈕、提示、錯誤和空狀態是否明確禁用、隱藏和權限行為是否正確焦點、鍵盤和語義結構是否退化移動或窄屏場景是否與改動有關文案是否準確表達結果頁面是否出現新的閃爍、跳動或狀態錯位。正確性層的結論寫法我不會只寫“邏輯有問題”而會寫[優先級] 問題標題 觸發條件 當前行為 期望行為 影響 代碼或運行證據 建議修正邊界它能讓下一輪修復直接對應可驗證結果。第二層修改范圍審查正確實現一個需求不代表差異范圍合理。1. 是否遺漏必須修改的位置調用鏈中的直接消費者是否全部處理包裝組件是否繼續透傳舊契約公開類型和統一導出是否同步測試、示例和文檔是否因公開行為變化而需要更新多應用或本地公共包是否存在真實消費者計劃中的文件是否有未出現的部分。2. 是否出現計劃外文件新文件為什么需要公共組件、請求層、路由和狀態是否得到確認配置、依賴和鎖文件變化是否與目標直接相關生成文件是否應該由腳本產生是否誤改舊版、示例或其他應用。3. 是否夾帶無關重構重命名是否為當前目標所需函數抽取是否改變職責邊界是否順手清理技術債是否把局部邏輯提前做成公共抽象是否替換項目已有寫法是否改變與需求無關的注釋、文案和樣式。4. 是否出現大面積格式差異格式化是否覆蓋整個文件導入排序是否使真實邏輯變化難以辨認行尾、編碼或換行符是否變化自動修復是否修改了任務外文件能否縮小為只包含目標差異。5. 是否超出原定風險等級局部任務是否觸碰公共契約單頁面任務是否進入全局狀態或路由守衛內部重構是否改變用戶行為原計劃的驗證方式是否仍覆蓋新范圍是否需要重新規劃而不是繼續補代碼。范圍層最重要的問題我會讓每個差異塊完成一句話為了實現_這里必須改變 _如果不改會導致 ___。無法完成這句話的差異通常需要移出當前任務或補充更強的依據。第三層副作用審查副作用是最容易在“功能已完成”之后留下的問題。1. 原有調用方是否被破壞沒有使用新能力的調用方是否保持原行為默認值變化是否影響未顯式傳值的位置事件時機和負載是否改變包裝組件是否隱藏了破壞性變化動態或條件性入口是否回歸。2. 共享狀態是否產生連帶影響修改是否寫入更多全局狀態其他頁面是否觀察到新值緩存、持久化和恢復邏輯是否一致狀態清理是否影響并行頁面新增副本是否可能與原狀態分叉。3. 請求與接口行為是否變化請求次數是否增加參數是否新增、刪除或改變默認值調用時機是否提前或延后失敗重試是否可能重復副作用是否繞過統一封裝返回數據是否被錯誤當成完整模型。4. 路由、權限和可見性是否變化查詢參數和路由狀態是否被重置返回或刷新后能否恢復權限判斷是否移到錯誤層隱藏按鈕是否替代了真正的數據權限不同角色是否出現新的入口或缺失入口。5. DOM 與樣式是否發生隱性變化根節點和包裹層是否改變類名、深層選擇器和外部樣式是否失效屬性透傳位置是否變化定位、溢出和響應式是否退化測試選擇器和可訪問名稱是否變化。6. 性能和資源是否退化是否增加重復請求和重復計算監聽、訂閱、定時器是否正確清理是否引入無必要的深度監聽列表項是否產生過多局部狀態大對象是否被反復復制或序列化新依賴是否增加構建和運行負擔。這里不能憑感覺寫“性能可能變差”。如果沒有測量或明確機制證據應把它寫成待驗證風險而不是確定結論。7. 安全和數據邊界是否變化用戶輸入是否進入新的 HTML、URL 或命令上下文敏感字段是否被展示、記錄或緩存權限數據是否只在前端隱藏下載、跳轉和外鏈是否校驗錯誤信息是否暴露不必要細節。這部分涉及具體項目時應使用項目安全規范和真實接口要求不能憑通用清單替代專業安全審查。我怎樣給問題排序審查不是找得越多越好。過多低價值意見會掩蓋真正阻斷交付的問題。我會按影響排序。P0必須立即阻斷可能造成安全問題、數據破壞、嚴重權限越界或核心流程不可用。P1合入前必須修復穩定觸發的功能錯誤、主要調用方破壞、狀態錯亂、錯誤數據提交或關鍵失敗路徑不可恢復。P2建議在當前任務修復特定條件下的行為問題、明顯越界差異、維護成本較高的新模式或驗證缺口。P3非阻斷建議不影響當前正確性和邊界的局部改進。它應該與必須修復的問題分開必要時轉成后續任務。優先級必須根據觸發條件和影響判斷不能只根據代碼寫法是否喜歡。審查意見怎樣寫得可執行我使用下面的結構## [P1] 保存成功事件在狀態清理后觸發 ? - 位置目標文件和緊鄰代碼范圍 - 觸發條件保存成功父頁面依賴當前記錄完成局部刷新 - 當前結果關閉流程先清理記錄事件負載缺失或讀取為空 - 預期結果父頁面在清理前取得本次保存對象失敗和主動關閉行為保持不變 - 證據事件觸發順序、父頁面監聽邏輯、對應頁面路徑 - 建議邊界只調整成功路徑順序不重構彈窗公共 API - 驗證成功保存、失敗保留、主動關閉和連續編輯路徑這個結構要求審查者承擔舉證責任而不是只表達偏好。如果我不能說明觸發條件、影響或證據就會把意見降為待確認問題而不是直接宣布代碼有錯。一份可直接使用的前端差異審查模板# 前端差異審查 ? ## 0. 審查范圍 - 對比基線 - 包含文件 - 排除的已有修改 - 新增、刪除、重命名和生成文件 ? ## 1. 任務與影響基線 - 目標行為 - 保持不變 - 允許范圍 - 必須修改 - 必須回歸 - 明確排除 ? ## 2. 正確性 - [ ] 目標完整實現 - [ ] 數據和狀態正確 - [ ] 組件契約正確 - [ ] 異步流程閉合 - [ ] 生命周期正確 - [ ] 用戶體驗符合驗收 ? ## 3. 修改范圍 - [ ] 沒有遺漏必要位置 - [ ] 沒有未經確認的計劃外文件 - [ ] 沒有無關重構和抽象 - [ ] 沒有大面積格式噪聲 - [ ] 風險等級與驗證計劃仍然匹配 ? ## 4. 副作用 - [ ] 原調用方保持兼容 - [ ] 共享狀態沒有連帶錯誤 - [ ] 請求與接口行為沒有意外變化 - [ ] 路由、權限和可見性保持正確 - [ ] DOM、樣式與可訪問性沒有退化 - [ ] 性能與資源風險有證據或明確待驗證 - [ ] 安全與數據邊界沒有被擴大 ? ## 5. 驗證證據 - 靜態檢查 - 測試 - 頁面路徑 - 完整差異復查 - 未驗證事項 ? ## 6. 發現 ### P0 / P1 - 問題、觸發、影響、證據、建議邊界、驗證 ? ### P2 - 問題、觸發、影響、證據、建議邊界、驗證 ? ### P3 / 后續建議 - 建議及為什么不阻斷當前交付 ? ## 7. 結論 - 可接受 / 修復后復審 / 需要重新規劃 / 證據不足 - 結論依據清單不能替代哪些判斷不能替代業務答案失敗后保留數據還是回滾保存后刷新還是局部替換需要真實需求決定。不能替代運行驗證靜態差異無法完整證明焦點、動畫、請求競態和連續交互正確。不能替代安全與性能專項檢查高風險場景需要更具體的項目規范、工具和專業審查。不能把所有建議都變成當前修改審查發現技術債很正常但當前差異應繼續保持單一目標。非阻斷改進可以記錄為后續任務。最終結論不只有“通過”和“不通過”我會保留四種結論。可接受目標、范圍和副作用均有足夠證據未驗證項不阻斷當前交付。修復后復審存在明確問題修復范圍可控修復后要重新檢查相關差異和行為路徑。需要重新規劃影響范圍擴大、公共契約變化或實現方向與需求沖突局部補丁已經不能安全解決。證據不足代碼看起來合理但關鍵測試、頁面路徑或環境條件無法驗證。此時不能把不確定性包裝成通過。寫在最后我給 Codex 前端改動做差異審查時會從三層檢查正確性目標、狀態、契約、異步和生命周期是否正確范圍該改的有沒有漏不該改的有沒有進入差異副作用調用方、共享狀態、請求、路由、DOM、性能和安全邊界是否被意外改變。每條發現都要包含觸發條件、影響、證據、建議修正邊界和驗證方式再按真正的交付風險排序。下一篇會進入第 2 周 Day 5為什么編譯或構建通過仍然不等于任務完成。我會具體拆分類型檢查、Lint、單元測試、構建和真實頁面驗證各自能證明什么、不能證明什么。本系列持續更新。后續會把今天的差異審查清單與自動檢查和頁面驗證連接起來完成從“代碼看起來對”到“結果有證據”的下一段閉環。參考資料OpenAI Codex 文檔限定代碼審查范圍、查看優先級發現并使用行級反饋OpenAI Codex 文檔在 AGENTS.md 中配置接近代碼作用范圍的審查規則