用 Context Engineering 的思路排查線上問題最近處理一個遺留項目的生產(chǎn)問題讓我對 Claude、Codex 這類 AI Coding 工具在診斷線上環(huán)境問題有了一些心得。背景一個我并不熟悉的老項目這次問題來自一個幾年前開發(fā)完成的項目。項目本身已經(jīng)不是團(tuán)隊當(dāng)前主要開發(fā)對象但還有客戶在持續(xù)使用。這類項目有幾個典型特點(diǎn)前端、后端、App、固件都有自己的代碼和邏輯。部署方式和運(yùn)行環(huán)境可能已經(jīng)不是團(tuán)隊日常最熟悉的那套。原始開發(fā)人員未必隨時可問。文檔可能不完整或者已經(jīng)跟當(dāng)前線上狀態(tài)有偏差?？蛻羧匀辉谟盟詥栴}必須盡快定位和解決。我自己并不熟悉這個項目也沒有辦法花很多時間從頭學(xué)習(xí)它的完整架構(gòu)和基本原理?？蛻粲龅降膯栴}某個用戶前一天還能使用第二天開始頁面上沒有出現(xiàn)操作按鈕。后臺配置看起來正常服務(wù)端接口也沒有明顯報錯。最好能快速看現(xiàn)場視頻、查日志、理解鏈路然后盡快給出判斷。這也是我最想分享的點(diǎn)在不熟悉項目的情況下如何讓 Claude / Codex 這類 AI Coding 工具快速進(jìn)入狀態(tài)并且真的幫上忙。第一件事盡可能提供完整代碼上下文對復(fù)雜系統(tǒng)來說只給后端代碼通常不夠。如果問題涉及端到端鏈路最好能讓 AI 看到所有相關(guān)代碼前端代碼后端代碼App 代碼SDK 代碼固件或設(shè)備側(cè)協(xié)議代碼不用擔(dān)心AI會一次性讀完所有代碼它的能力已經(jīng)足夠在必要時候進(jìn)行深度搜索、跳轉(zhuǎn)、關(guān)聯(lián)。部署腳本、配置文件、API 文檔、歷史排查記錄 —— 這些其實不需要。因為這些都可以通過代碼得出結(jié)論。用代碼做Single Source of Truth更好。第二件事提供客戶項目背景和部署方式代碼之外還需要業(yè)務(wù)和部署上下文。比如客戶的租戶名稱、賬號清單、權(quán)限配置情況。但是這些信息提供起來比較麻煩因為我對客戶的一些具體的配置到底是標(biāo)準(zhǔn)化的還是定制化的我不太了解。我唯一能給出的是這個客戶的租戶ID和受影響用戶ID。其他的需要AI根據(jù)代碼的使用鏈路自己去后臺或數(shù)據(jù)庫里查詢。當(dāng)時大概有三種選擇。第一種是直接讓 AI 訪問生產(chǎn)數(shù)據(jù)庫。 第二種是調(diào)用生產(chǎn)環(huán)境 API。 第三種是讓 AI 使用我的賬號登錄瀏覽器直接查看客戶項目配置。我最后選了第三種也不是因為哪種更好而是這種方式最簡單不需要去搞 APIKEY也不需要搞readonly的數(shù)據(jù)庫賬號。這里用到了Chrome Dev Tools MCP第三件事告訴 AI 日志在哪里并給它 CLI這次我用的是觀測云的 CLI。排查生產(chǎn)問題日志位置非常關(guān)鍵。最好明確告訴 AI后端 API 日志、App 日志、前端監(jiān)控、設(shè)備或固件日志、第三方調(diào)用日志分別在哪里以及日志里的關(guān)鍵字段是什么request id、user id、device id怎么關(guān)聯(lián)。如果日志量不大可以直接導(dǎo)出給 AI。但真實生產(chǎn)日志往往很大不可能一次性塞進(jìn)聊天窗口這時候 CLI 就很關(guān)鍵。CLI 的價值在于AI 不需要我手工復(fù)制大量日志給它而是可以直接查詢云端日志倉庫。讓 AI 從被動閱讀變成主動查詢。AI自動排查的效果它很細(xì)地查每一段日志權(quán)限預(yù)取有沒有成功App 有沒有離線藍(lán)牙掃描有沒有發(fā)生有沒有識別到目標(biāo)設(shè)備有沒有創(chuàng)建本地 session有沒有建立連接有沒有寫入 token有沒有上報最終事件。我把幾天的工作量壓縮成了半小時并且給出了非常準(zhǔn)確的結(jié)論。一次排查結(jié)束后如果所有結(jié)論只留在聊天記錄里很快就會丟失。可以用Compound Engineering的SKILL沉淀solution 文檔形成可復(fù)用經(jīng)驗。核心收獲第一AI 需要完整上下文代碼、項目背景、部署方式、業(yè)務(wù)場景、關(guān)鍵概念和時間窗口。 第二要給 AI 進(jìn)入現(xiàn)場的工具尤其是日志查詢 CLI。沒有日志入口AI 只能猜有了 CLI它才能逐段排除。 第三不能直連數(shù)據(jù)庫時可以讓 AI 通過 Chrome DevTools MCP 查看后臺頁面。后臺本身就是業(yè)務(wù)配置的解釋層。 第四盡可能使用視覺模型。很多后臺配置不是 JSON而是表格、標(biāo)簽、狀態(tài)、按鈕和彈窗。 第五人的作用不是手工查每一行日志而是補(bǔ)上下文、審查AI的行動路徑。 最后排查結(jié)束后要沉淀把結(jié)論寫成 solution 文檔讓這次上下文變成下次可復(fù)用的經(jīng)驗。預(yù)覽時標(biāo)簽不可點(diǎn)微信掃一掃贊賞作者喜歡作者關(guān)閉0人付費(fèi)更多正在加載…正在加載…關(guān)閉更多名稱已清空微信掃一掃贊賞作者喜歡作者其它金額贊賞后展示我的頭像作品暫無作品喜歡作者其它金額￥最低贊賞 ￥0確定返回其它金額更多贊賞金額￥最低贊賞 ￥01234567890.AI調(diào)研 · 目錄#AI調(diào)研上一篇Compound Engineering 重構(gòu)把 Agent 收進(jìn) Skill下一篇如何啟動多個 Codex 瀏覽器會話作者提示: 個人觀點(diǎn)僅供參考關(guān)閉更多搜索「」網(wǎng)絡(luò)結(jié)果關(guān)閉調(diào)整當(dāng)前正文文字大小更多100%原文鏈接xiaofeng.dev 用Context Engineering的思路排查線上問題
用 Context Engineering 的思路排查線上問題最近處理一個遺留項目的生產(chǎn)問題讓我對 Claude、Codex 這類 AI Coding 工具在診斷線上環(huán)境問題有了一些心得。背景一個我并不熟悉的老項目這次問題來自一個幾年前開發(fā)完成的項目。項目本身已經(jīng)不是團(tuán)隊當(dāng)前主要開發(fā)對象但還有客戶在持續(xù)使用。這類項目有幾個典型特點(diǎn)前端、后端、App、固件都有自己的代碼和邏輯。部署方式和運(yùn)行環(huán)境可能已經(jīng)不是團(tuán)隊日常最熟悉的那套。原始開發(fā)人員未必隨時可問。文檔可能不完整或者已經(jīng)跟當(dāng)前線上狀態(tài)有偏差?？蛻羧匀辉谟盟詥栴}必須盡快定位和解決。我自己并不熟悉這個項目也沒有辦法花很多時間從頭學(xué)習(xí)它的完整架構(gòu)和基本原理?？蛻粲龅降膯栴}某個用戶前一天還能使用第二天開始頁面上沒有出現(xiàn)操作按鈕。后臺配置看起來正常服務(wù)端接口也沒有明顯報錯。最好能快速看現(xiàn)場視頻、查日志、理解鏈路然后盡快給出判斷。這也是我最想分享的點(diǎn)在不熟悉項目的情況下如何讓 Claude / Codex 這類 AI Coding 工具快速進(jìn)入狀態(tài)并且真的幫上忙。第一件事盡可能提供完整代碼上下文對復(fù)雜系統(tǒng)來說只給后端代碼通常不夠。如果問題涉及端到端鏈路最好能讓 AI 看到所有相關(guān)代碼前端代碼后端代碼App 代碼SDK 代碼固件或設(shè)備側(cè)協(xié)議代碼不用擔(dān)心AI會一次性讀完所有代碼它的能力已經(jīng)足夠在必要時候進(jìn)行深度搜索、跳轉(zhuǎn)、關(guān)聯(lián)。部署腳本、配置文件、API 文檔、歷史排查記錄 —— 這些其實不需要。因為這些都可以通過代碼得出結(jié)論。用代碼做Single Source of Truth更好。第二件事提供客戶項目背景和部署方式代碼之外還需要業(yè)務(wù)和部署上下文。比如客戶的租戶名稱、賬號清單、權(quán)限配置情況。但是這些信息提供起來比較麻煩因為我對客戶的一些具體的配置到底是標(biāo)準(zhǔn)化的還是定制化的我不太了解。我唯一能給出的是這個客戶的租戶ID和受影響用戶ID。其他的需要AI根據(jù)代碼的使用鏈路自己去后臺或數(shù)據(jù)庫里查詢。當(dāng)時大概有三種選擇。第一種是直接讓 AI 訪問生產(chǎn)數(shù)據(jù)庫。 第二種是調(diào)用生產(chǎn)環(huán)境 API。 第三種是讓 AI 使用我的賬號登錄瀏覽器直接查看客戶項目配置。我最后選了第三種也不是因為哪種更好而是這種方式最簡單不需要去搞 APIKEY也不需要搞readonly的數(shù)據(jù)庫賬號。這里用到了Chrome Dev Tools MCP第三件事告訴 AI 日志在哪里并給它 CLI這次我用的是觀測云的 CLI。排查生產(chǎn)問題日志位置非常關(guān)鍵。最好明確告訴 AI后端 API 日志、App 日志、前端監(jiān)控、設(shè)備或固件日志、第三方調(diào)用日志分別在哪里以及日志里的關(guān)鍵字段是什么request id、user id、device id怎么關(guān)聯(lián)。如果日志量不大可以直接導(dǎo)出給 AI。但真實生產(chǎn)日志往往很大不可能一次性塞進(jìn)聊天窗口這時候 CLI 就很關(guān)鍵。CLI 的價值在于AI 不需要我手工復(fù)制大量日志給它而是可以直接查詢云端日志倉庫。讓 AI 從被動閱讀變成主動查詢。AI自動排查的效果它很細(xì)地查每一段日志權(quán)限預(yù)取有沒有成功App 有沒有離線藍(lán)牙掃描有沒有發(fā)生有沒有識別到目標(biāo)設(shè)備有沒有創(chuàng)建本地 session有沒有建立連接有沒有寫入 token有沒有上報最終事件。我把幾天的工作量壓縮成了半小時并且給出了非常準(zhǔn)確的結(jié)論。一次排查結(jié)束后如果所有結(jié)論只留在聊天記錄里很快就會丟失。可以用Compound Engineering的SKILL沉淀solution 文檔形成可復(fù)用經(jīng)驗。核心收獲第一AI 需要完整上下文代碼、項目背景、部署方式、業(yè)務(wù)場景、關(guān)鍵概念和時間窗口。 第二要給 AI 進(jìn)入現(xiàn)場的工具尤其是日志查詢 CLI。沒有日志入口AI 只能猜有了 CLI它才能逐段排除。 第三不能直連數(shù)據(jù)庫時可以讓 AI 通過 Chrome DevTools MCP 查看后臺頁面。后臺本身就是業(yè)務(wù)配置的解釋層。 第四盡可能使用視覺模型。很多后臺配置不是 JSON而是表格、標(biāo)簽、狀態(tài)、按鈕和彈窗。 第五人的作用不是手工查每一行日志而是補(bǔ)上下文、審查AI的行動路徑。 最后排查結(jié)束后要沉淀把結(jié)論寫成 solution 文檔讓這次上下文變成下次可復(fù)用的經(jīng)驗。預(yù)覽時標(biāo)簽不可點(diǎn)微信掃一掃贊賞作者喜歡作者關(guān)閉0人付費(fèi)更多正在加載…正在加載…關(guān)閉更多名稱已清空微信掃一掃贊賞作者喜歡作者其它金額贊賞后展示我的頭像作品暫無作品喜歡作者其它金額￥最低贊賞 ￥0確定返回其它金額更多贊賞金額￥最低贊賞 ￥01234567890.AI調(diào)研 · 目錄#AI調(diào)研上一篇Compound Engineering 重構(gòu)把 Agent 收進(jìn) Skill下一篇如何啟動多個 Codex 瀏覽器會話作者提示: 個人觀點(diǎn)僅供參考關(guān)閉更多搜索「」網(wǎng)絡(luò)結(jié)果關(guān)閉調(diào)整當(dāng)前正文文字大小更多100%原文鏈接xiaofeng.dev