上一篇完成了組件調用鏈檢查先列公開面再找直接、間接和條件性調用方最后補查狀態(tài)、副作用、生命周期、樣式和測試。但找到依賴并不等于所有依賴都需要修改。例如一個組件被 12 個頁面使用改內部變量名12 個頁面可能都不受影響改 Prop 默認值只有沒有顯式傳值的頁面受影響改事件負載監(jiān)聽該事件的調用方需要檢查改根節(jié)點結構業(yè)務邏輯不變但外部樣式和測試可能受影響改保存后的關閉時機所有調用方都可能出現用戶行為變化。所以影響范圍不能直接用“引用數量”代替。我會繼續(xù)追問當前改動改變了哪一層可觀察結果哪些位置必須同步修改哪些只需要回歸哪些可以明確排除為了讓 Codex 的分析不止停在文件列表我把影響范圍拆成 7 層。評估開始前先寫一條“變化聲明”影響評估必須圍繞具體變化展開?！皟?yōu)化彈窗組件”無法判斷范圍“把保存成功后的關閉責任從組件內部交給父頁面”才有清楚的傳播方向。我會先寫四項# 變化聲明 - 當前行為 - 目標行為 - 明確保持不變 - 尚未確定其中“明確保持不變”非常重要。例如目標只改變事件負載就應明確事件觸發(fā)時機、失敗行為、關閉規(guī)則和 Loading 歸屬是否保持不變。否則 Codex 可能為了讓新接口更順手同時調整一整段流程。如果目標行為仍有多種解釋影響評估應該先暴露差異不急著給出修改范圍。第一層用戶行為影響我先看用戶能觀察到什么變化。包括入口是否仍然可見點擊、輸入、提交和取消結果是否變化Loading、禁用、錯誤和空狀態(tài)是否變化成功后頁面是否刷新、跳轉或關閉連續(xù)操作和返回重入是否變化鍵盤、焦點和可訪問行為是否變化。用戶行為層決定驗收主線。一個內部契約變化如果最終行為完全不變重點是兼容和回歸如果用戶行為本身改變就必須回到需求和驗收標準不能把它偽裝成內部重構。我會要求 Codex 用前后對照寫清場景修改前修改后是否為需求目標正常操作當前結果目標結果是 / 否請求失敗當前恢復方式目標恢復方式是 / 否關閉重開當前狀態(tài)目標狀態(tài)是 / 否連續(xù)操作當前順序目標順序是 / 否任何“不是需求目標但會發(fā)生變化”的行都是范圍擴張信號。第二層公開契約影響這一層檢查組件對外暴露的接口是否變化Props 名稱、類型、必填和默認值Emits 名稱、時機和負載v-model的值與更新規(guī)則插槽名稱、作用域和默認內容暴露方法的簽名與返回值屬性和事件透傳公開類型和統(tǒng)一導出。我會把契約變化分成三類。兼容變化舊調用方式仍然成立新能力只是可選增加。即便如此也要驗證默認行為沒有改變。需要遷移的變化調用方必須調整才能繼續(xù)工作例如事件改名、必填 Prop 增加、負載結構變化。隱性破壞變化類型可能仍然通過但運行行為變了例如默認值、事件時機、透傳位置或插槽包裹結構改變。隱性破壞最值得警惕因為自動檢查未必會報錯。第三層調用入口影響調用入口層回答變化會傳播到哪些消費者。這里使用上一篇得到的調用鏈把消費者分為直接調用統(tǒng)一導出或組件庫入口包裝組件全局注冊動態(tài)映射路由和自動掃描其他應用或本地包。我不會把所有消費者都列為“待修改”。我會進一步標注消費者是否使用變化契約是否依賴變化行為處理方式直接頁面 A是是修改并驗證頁面 B否可能依賴默認值重點回歸包裝組件 C是會向上透傳修改并繼續(xù)查上層示例 D是不進入生產路徑同步示例或記錄舊版 E否已明確不在范圍排除并說明依據這種分類能避免兩個極端漏掉真正受影響的調用方或者因為引用多就把所有文件一起改掉。第四層數據與狀態(tài)影響組件行為通常依賴數據來源和狀態(tài)歸屬。我會沿下面幾個問題檢查輸入數據來自父級、路由、狀態(tài)模塊還是請求組件內部是否保存副本是否存在計算值、緩存值或映射值修改是否改變狀態(tài)唯一來源數據轉換發(fā)生在哪一層成功和失敗會寫回哪些狀態(tài)其他頁面是否共享同一狀態(tài)。例如事件負載從“無參數通知”變成“返回更新后的記錄”看起來只是契約增強卻可能讓父頁面從“重新請求列表”改成“直接替換當前行”。這時影響不只是事件類型還包括列表數據是否完整排序和篩選是否仍然成立服務端計算字段是否已經返回當前頁總數是否變化其他共享狀態(tài)是否同步。如果這些條件沒有證據就不能把減少一次請求當成順手優(yōu)化。第五層副作用影響副作用包括所有會越過組件內部邊界的動作網絡請求路由變化全局狀態(tài)寫入緩存與本地存儲全局事件定時器和訂閱下載、打印或剪貼板日志、埋點和監(jiān)控。評估副作用時我不會只問“是否調用”還會問調用次數是否變化調用時機是否變化參數和返回處理是否變化失敗和取消路徑是否變化誰依賴副作用產生的結果。把請求從父頁面移進組件或者從組件移回父頁面可能都能實現功能但責任邊界、測試方式和復用條件會完全改變。副作用位置發(fā)生變化時我通常會提高風險等級并要求單獨驗證。第六層生命周期與時序影響前端很多問題不是“做沒做”而是“什么時候做”。我會標出關鍵時序首次掛載打開前后輸入或 Prop 變化提交開始和結束請求成功、失敗和取消關閉路由離開緩存激活與失活卸載多次請求返回順序。一項看似兼容的修改如果改變了事件觸發(fā)時機仍然可能破壞調用方。例如父頁面原本在saved事件中立即讀取組件狀態(tài)如果事件改到清理之后觸發(fā)事件名稱和類型都沒變讀取結果卻變了。時序影響通常要靠場景驗證而不能只依賴靜態(tài)檢查。第七層DOM、樣式與驗證影響我把這三項放在同一層是因為它們經常不在業(yè)務調用鏈中卻直接影響交付。DOM 與樣式根節(jié)點是否變化類名和層級是否變化外部選擇器或深層樣式是否依賴內部結構屬性透傳落在哪個元素響應式、溢出和定位是否變化語義標簽、焦點順序和可訪問名稱是否變化。測試與驗證單元測試是否依賴舊契約頁面測試是否依賴文本、選擇器和觸發(fā)順序截圖基線是否會變化類型檢查覆蓋哪些調用方哪些條件路徑必須人工驗證回退時能否恢復原行為。一個影響評估如果沒有驗證出口就仍然只是猜測。我怎樣給影響分級我不喜歡給組件改動算一個看似精確的風險分數。真實項目中的權重很難統(tǒng)一。我會用兩組標簽。傳播方式直接影響明確使用變化契約或行為間接影響通過包裝、狀態(tài)、類型或副作用傳播條件性影響只在特定配置、權限、數據或操作順序出現。處理級別必須修改不調整就會類型失敗、運行失敗或行為錯誤必須回歸代碼可能不用改但依賴默認值、時序、DOM 或共享狀態(tài)觀察記錄與變化有關但當前證據表明不進入交付路徑明確排除有依據證明不在當前應用、版本或任務范圍。每個影響點都要同時有傳播方式和處理級別。例如“包裝組件 C間接影響必須修改”“頁面 B條件性影響必須回歸”“舊版示例直接引用但明確排除”。這樣比高、中、低三個詞更容易落實到計劃。一個方法演示修改編輯彈窗的成功事件負載下面只用于說明評估方法不代表真實項目案例。假設當前彈窗保存成功后只觸發(fā)通知saved()現在計劃改為返回更新后的記錄saved(updatedRecord)表面看是一次契約擴展7 層影響可能包括用戶行為按目標應保持不變仍然保存成功、關閉彈窗并刷新正確數據。公開契約事件負載類型變化原來不接收參數的監(jiān)聽是否仍然兼容需要結合項目類型和寫法確認。調用入口所有監(jiān)聽saved的直接頁面要查包裝彈窗如果透傳事件還要繼續(xù)查它的上層調用方。數據與狀態(tài)調用方是否會用返回記錄直接替換列表項記錄是否包含完整展示字段是否會破壞排序和篩選。副作用原本的列表刷新請求是否保留如果刪除接口調用次數和服務端最新狀態(tài)的獲取方式會改變。生命周期事件在關閉和狀態(tài)清理之前還是之后觸發(fā)父級能否讀取所需上下文。DOM 與驗證模板可能不變但事件測試、頁面刷新測試和失敗路徑需要回歸。這時更穩(wěn)妥的結論可能不是“順便刪除刷新請求”而是先只增加事件負載保持刷新行為不變。等證據證明返回記錄足以替代重新請求再把優(yōu)化拆成獨立任務。影響評估的價值就是阻止一個小契約變化悄悄夾帶第二個行為變化。一份可以交給 Codex 的影響范圍模板# 組件改動影響范圍 ? ## 0. 變化聲明 - 當前行為 - 目標行為 - 保持不變 - 尚未確定 ? ## 1. 用戶行為 | 場景 | 修改前 | 修改后 | 是否為目標變化 | 驗證方式 | | --- | --- | --- | --- | --- | ? ## 2. 公開契約 | 契約 | 當前定義 | 計劃變化 | 兼容性 | 證據 | | --- | --- | --- | --- | --- | ? ## 3. 調用入口 | 消費者 | 傳播方式 | 依賴內容 | 處理級別 | 驗證方式 | | --- | --- | --- | --- | --- | ? ## 4. 數據與狀態(tài) - 輸入來源 - 唯一狀態(tài)來源 - 數據轉換 - 共享消費者 - 成功與失敗寫回 ? ## 5. 副作用 - 請求 - 路由 - 全局狀態(tài) - 緩存、事件和訂閱 ? ## 6. 生命周期與時序 - 關鍵時間點 - 連續(xù)操作 - 關閉、重入與卸載 - 異步競態(tài) ? ## 7. DOM、樣式與驗證 - DOM 與屬性透傳 - 外部樣式 - 自動檢查 - 頁面回歸 - 條件性路徑 ? ## 8. 執(zhí)行結論 - 必須修改 - 只需回歸 - 觀察記錄 - 明確排除 - 暫停條件影響范圍怎樣反過來控制執(zhí)行計劃影響評估完成后我會據此調整 Codex 的修改批次。先固定契約再改調用方契約尚未確定時不讓多個調用方同時遷移。直接影響先處理間接影響逐層展開包裝組件或共享狀態(tài)會繼續(xù)傳播影響不能把它們和最終頁面混成一個大批次。條件性影響單獨設計驗證權限、環(huán)境、舊數據和連續(xù)操作不能用正常路徑順便帶過。“只需回歸”不等于可以忽略沒有代碼差異的調用方同樣可能因為默認值、時序和 DOM 變化而出問題。明確排除要留下依據例如舊版應用未進入當前構建、示例不參與生產、某調用方顯式覆蓋了變化默認值。沒有依據的排除只是遺漏。哪些信號說明影響范圍還沒有劃清只列文件沒有說明依賴行為所有引用都被標成“可能受影響”只看類型錯誤沒有檢查默認值和事件時機修改范圍與回歸范圍完全相同條件性調用沒有觸發(fā)條件公共狀態(tài)和副作用沒有繼續(xù)向下追蹤DOM 變化被簡單寫成“不影響功能”驗證項只有“運行測試”沒有說明測試覆蓋什么計劃改變了用戶行為卻仍把任務描述成內部重構。出現這些信號時我不會讓 Codex直接進入多文件修改。寫在最后調用鏈解決“誰與組件有關”影響范圍解決“誰會因為當前變化而發(fā)生什么”。我會從 7 層判斷一個組件改動用戶行為公開契約調用入口數據與狀態(tài)副作用生命周期與時序DOM、樣式與驗證。然后給每個影響點標注直接、間接或條件性傳播再判斷它屬于必須修改、必須回歸、觀察記錄還是明確排除。這樣得到的不是一張夸大的文件清單而是一份可以直接控制修改批次和驗收路徑的工程依據。下一篇會進入第 2 周 Day 4Codex 完成修改以后我怎樣審查代碼差異。我會從正確性、修改范圍和副作用三個層面檢查并重點說明為什么“代碼看起來合理”仍然可能偏離任務目標。本系列持續(xù)更新。接下來會把今天劃定的影響范圍作為差異審查基線檢查 AI 實際改動是否既沒有漏也沒有越界。參考資料OpenAI Codex 用例理解代碼庫時應追蹤請求流、模塊職責、狀態(tài)轉換、隱藏依賴和修改后的檢查OpenAI Codex 用例復雜問題應建立評估方式聚焦修改并在有意義的變化后重新驗證每日好工具推薦在這里推薦一款超好用的圖片壓縮工具——“圖壓”在線圖片壓縮免費壓縮 JPG、PNG、WebP - 圖壓工具。同事安利給我的用過后真的覺得太香了支持批量壓縮、調整壓縮百分比最關鍵的是它是離線程序下載到本地就能反復用。我平時做自媒體和寫前端時經常用到再也不用去網上找在線壓縮工具了。它也帶在線壓縮功能很方便。