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