Using AI Without Losing Your Critical Thinking給開發(fā)者的 AI 判斷力生存指南最近團(tuán)隊里出現(xiàn)了一個很有意思的現(xiàn)象新來的同事用 AI 寫代碼很快一天能提交好幾個 PR但代碼 review 的時候問他為什么這么寫、有沒有考慮過邊界條件、異常路徑怎么處理他支支吾吾答不上來。這不是個例。AI 編程工具、AI Agent、AI 測試助手已經(jīng)在整個開發(fā)鏈路里鋪開了但很多開發(fā)者的工作模式正在悄悄變化從我要想清楚再寫代碼變成AI 生成什么我用什么。代碼能跑但沒人真正理解它測試能過但沒人知道斷言寫得對不對報錯信息直接粘貼給 AI答案看起來合理就直接采用。這篇文章想討論的核心問題是用 AI 這件事本身沒有錯錯的是把判斷權(quán)也一起交給了 AI。我會從工程實(shí)踐的角度拆解為什么 AI 會侵蝕批判性思維以及開發(fā)者在 AI 編程、AI Agent、AI 測試、數(shù)據(jù)分析這些真實(shí)場景里應(yīng)該建立什么樣的驗(yàn)證習(xí)慣和護(hù)欄機(jī)制。文章不會勸你少用 AI——那是因噎廢食。更實(shí)際的做法是保留 AI 帶來的效率提升同時把思考的主動權(quán)拿回來。這才是 2025 年開發(fā)者真正需要的能力。1. 為什么你的批判性思維正在被 AI 悄悄繞過很多開發(fā)者把 AI 依賴歸咎于自己變懶了但問題沒那么簡單。從技術(shù)層面看大語言模型的生成機(jī)制天然會繞過人的批判性思維。大語言模型本質(zhì)上是一個概率推理系統(tǒng)。它根據(jù)輸入的上下文預(yù)測最可能出現(xiàn)的下一個 token然后不斷重復(fù)這個過程直到生成完整回答。整個生成過程里沒有內(nèi)置的事實(shí)核查機(jī)制。模型不知道它說的是對的還是錯的它只知道這樣說最流暢、最像人類會說的話。這里有一個容易忽略的點(diǎn)模型訓(xùn)練時優(yōu)化的是答案在語料中出現(xiàn)的概率不是答案在現(xiàn)實(shí)中是否正確。當(dāng)語料里充斥著大量不夠嚴(yán)謹(jǐn)?shù)募夹g(shù)帖子、過時的 API 文檔、甚至互相矛盾的代碼片段時模型學(xué)到的就是這些說法很常見所以應(yīng)該這么說。這解釋了為什么 AI 會一本正經(jīng)地給出錯誤答案——它并不是在撒謊它只是把概率最高的內(nèi)容組合起來了。工具設(shè)計也在加重這個問題。AI 編程助手通常提供Tab 補(bǔ)全這樣的交互方式光標(biāo)停在代碼上按一下 Tab幾十行代碼就進(jìn)去了。整個交互過程里工具沒有引導(dǎo)你停下來檢查沒有要求你說明需求沒有讓你確認(rèn)邊界條件。它默認(rèn)你按了 Tab 就是同意。驗(yàn)證環(huán)路從代碼生成過程中被剝離了取而代之的是一個非常順滑的接受動作。更隱蔽的是心理層面的責(zé)任轉(zhuǎn)移效應(yīng)。當(dāng) AI 給出的答案非常自信、結(jié)構(gòu)完整、格式漂亮?xí)r人天生傾向于相信它——這和人們傾向于相信語氣堅定的專家是同一個心理機(jī)制。于是開發(fā)者從我要驗(yàn)證這個方案對不對變成了它看起來很有道理應(yīng)該沒問題。從工程后果看這種習(xí)慣的代價是延遲爆發(fā)的。短期看代碼能跑、任務(wù)能完成中期看技術(shù)債開始堆積——沒人理解的代碼邏輯、覆蓋不全的測試、依賴不明的第三方庫長期看團(tuán)隊里沒有人能獨(dú)立判斷技術(shù)選型和技術(shù)方案整個系統(tǒng)的安全性建立在一個不可解釋的黑盒之上。說白了AI 讓代碼生產(chǎn)變快了但讓代碼理解變慢了這兩者之間的差距就是技術(shù)風(fēng)險。2. 三個基礎(chǔ)概念批判性思維、AI 幻覺與驗(yàn)證環(huán)路要把這個問題講清楚先統(tǒng)一幾個概念。這里我用工程場景來定義不扯學(xué)術(shù)定義。批判性思維在軟件開發(fā)語境里指的是評估證據(jù)這個方案有依據(jù)嗎、識別假設(shè)它默認(rèn)了哪些前提、考慮替代解釋有沒有別的實(shí)現(xiàn)方式、判斷結(jié)論可靠性這個結(jié)論在什么條件下成立。寫代碼時考慮邊界條件、review 時追問設(shè)計動機(jī)、排查問題時懷疑初步結(jié)論這些都是批判性思維的具體表現(xiàn)。AI 幻覺指的是模型生成的內(nèi)容雖然流暢、符合語法、邏輯結(jié)構(gòu)完整但事實(shí)是錯誤的或憑空編造的。比如 AI 給你推薦了一個看起來非常合理的 API但你去查官方文檔發(fā)現(xiàn)它根本不存在或者 AI 給你描述一個開源項(xiàng)目的活躍維護(hù)狀態(tài)但那個項(xiàng)目三年前就停止更新了?；糜X不是偶發(fā)缺陷它是大語言模型生成機(jī)制的內(nèi)生屬性你只能通過驗(yàn)證來發(fā)現(xiàn)它無法通過提示詞徹底消除它。驗(yàn)證環(huán)路是我在這篇文章里反復(fù)用到的一個概念。正常的認(rèn)知過程是提出假設(shè) → 收集證據(jù) → 交叉檢驗(yàn) → 形成結(jié)論。比如你懷疑某個接口超時是數(shù)據(jù)庫連接池耗盡導(dǎo)致的你提出假設(shè)然后看監(jiān)控、查日志、復(fù)現(xiàn)請求最后確認(rèn)根因。AI 工具介入后環(huán)路變成了提出問題 → AI 給出答案 →省略證據(jù)收集和交叉檢驗(yàn)→ 直接采用。被跳過的那兩步恰恰是批判性思維發(fā)生的地方。這三個概念放在一起看你就能理解一個判斷AI 并沒有替你做思考它只是替你做完了生成答案這一步而把驗(yàn)證答案這一步留給了你。工具效率再高驗(yàn)證環(huán)節(jié)不補(bǔ)上整個鏈路就是斷裂的。維度專家思維AI 依賴型思維拿到答案后先問依據(jù)是什么直接看結(jié)論對不對面對異常情況懷疑前提假設(shè)認(rèn)為 AI 沒提到就是不存在代碼生成后補(bǔ)充邊界測試能編譯通過就提交排查問題時從根因出發(fā)驗(yàn)證把問題原樣貼給 AI最后防線自己的判斷模型的自信程度3. 建立 AI 信任分層先判斷你在哪個層級使用 AI不是所有 AI 輸出都需要同等強(qiáng)度的驗(yàn)證。如果每次用 AI 都要做一次完整的事實(shí)核查效率反而會拖垮你。更合理的做法是建立信任分層根據(jù)任務(wù)的風(fēng)險等級決定驗(yàn)證強(qiáng)度。層級 0低風(fēng)險的事實(shí)查詢。比如查某門語言的語法格式、某個框架的配置項(xiàng)寫法、某個函數(shù)的簽名。這類內(nèi)容的驗(yàn)證成本很低編譯器會告訴你對錯就算 AI 答錯了你也能在幾秒鐘內(nèi)發(fā)現(xiàn)。驗(yàn)證方式看一眼文檔或直接運(yùn)行。層級 1設(shè)計建議與問題分析。比如這個微服務(wù)拆分方案是否合理這個 SQL 查詢?yōu)槭裁绰?。這類回答沒有絕對的對錯但可能包含過時信息、錯誤假設(shè)或片面視角。驗(yàn)證方式檢查它隱含的前提是否成立、有沒有考慮到當(dāng)前項(xiàng)目的實(shí)際約束。層級 2代碼生成與重構(gòu)。AI 生成的代碼必須經(jīng)過人工閱讀、邊界檢查、真實(shí)運(yùn)行測試三關(guān)才能進(jìn)入代碼庫。這里沒有捷徑任何直接采用 AI 生成代碼而不運(yùn)行測試的行為都是在給自己埋雷。層級 3自動化決策與 Agent 執(zhí)行。當(dāng) AI 不再只是給建議而是直接操作文件、執(zhí)行命令、修改配置時它已經(jīng)進(jìn)入了生產(chǎn)鏈路。這時候你必須有護(hù)欄最小權(quán)限、執(zhí)行前審批、全程日志、可回滾。后面我會專門講 Agent 場景怎么做。判斷自己處在哪個層級的快速方法是問一句話如果 AI 在這個任務(wù)上答錯了造成的損失是什么損失是花五分鐘重查文檔還是線上服務(wù)掛了直接決定你是掃一眼就接受還是需要完整驗(yàn)證。風(fēng)險分級是批判性思維的第一步它不是不信任 AI而是把信任建立在可控的范圍內(nèi)。4. AI 編程中的批判性思維驗(yàn)證 AI 生成代碼的五道檢查AI 編程是絕大多數(shù)開發(fā)者使用 AI 的主要場景。要想在編程時保住批判性思維不需要什么高深技巧只需在流程里卡住五個檢查點(diǎn)。第一道檢查需求先于生成。無論用什么工具先自己寫清楚需求和驗(yàn)收標(biāo)準(zhǔn)。你可以先寫出測試用例再讓 AI 實(shí)現(xiàn)功能而不是讓 AI 直接給你一版代碼。這樣做的好處是你的頭腦里先有了正確的錨點(diǎn)AI 生成代碼后你可以對照測試來判斷而不是被它帶著走。第二道檢查讓 AI 解釋代碼而不是只看輸出。很多開發(fā)者的習(xí)慣是AI 生成代碼 → 運(yùn)行通過 → 提交。缺少了人理解代碼這一步。一個很有效的強(qiáng)制性要求是讓 AI 逐行解釋它寫的代碼說明每個分支的意圖。當(dāng)你要求 AI 解釋時你會發(fā)現(xiàn)很多地方它的解釋是含混的——因?yàn)樗约阂矝]有完整的因果模型只是按概率拼接出來的。這個發(fā)現(xiàn)過程就是你在恢復(fù)判斷力。第三道檢查邊界與異常檢查。AI 生成的代碼最擅長處理正常情況最不擅長處理意外情況。重復(fù)鍵、空值、超長輸入、并發(fā)沖突、網(wǎng)絡(luò)超時這些場景 AI 很少主動考慮。你需要做的事非常具體把每個輸入?yún)?shù)問一遍如果是空值會怎樣如果重復(fù)出現(xiàn)會怎樣如果格式不符合預(yù)期會怎樣?？匆粋€具體例子。假設(shè)你讓 AI 寫一個把keyvalue文本解析為字典的函數(shù)它可能給你生成這樣的代碼# 文件路徑config_parser.py def parse_config(raw: str) - dict: config {} for line in raw.strip().splitlines(): if not line or line.startswith(#): continue if not in line: raise ValueError(finvalid line: {line}) key, value line.split(, 1) config[key.strip()] value.strip() return config這段代碼看起來很正常但真正的風(fēng)險在邊界處。于是你用測試用例來驗(yàn)證# 文件路徑test_config_parser.py import pytest from config_parser import parse_config def test_normal_case(): assert parse_config(a1\nb2) {a: 1, b: 2} def test_empty_line_and_comment(): assert parse_config(# comment\n\na1) {a: 1} def test_duplicate_key_should_keep_last(): # AI 生成的代碼是否處理了重復(fù)鍵 assert parse_config(a1\na2) {a: 2} def test_value_with_equals_sign(): # 值里包含等號時是否只按第一個等號分割 assert parse_config(urlhttp://example.com?a1)[url] http://example.com?a1 def test_value_missing(): # 后面沒有值會怎樣 with pytest.raises(ValueError): parse_config(key)寫測試用例這個動作本身就是批判性思維。它逼著你去想 AI 沒想到的問題。你會發(fā)現(xiàn)AI 生成的代碼很可能沒處理值里包含等號的情況或者對空值直接拋出 ValueError 而不是給出更友好的提示。這不代表 AI 生成的代碼沒有價值——它的主體邏輯是正確的——但只有當(dāng)你親自補(bǔ)充了這些邊界測試代碼才從看起來正確變成真的正確。第四道檢查依賴審查。AI 經(jīng)常會給代碼推薦第三方庫。這里特別容易踩坑因?yàn)樗扑]的包可能是真實(shí)存在的但已經(jīng)停止維護(hù)了也可能是存在安全漏洞的舊版本甚至可能是名字相似的山寨包。檢查方式不復(fù)雜查官方源里的版本歷史和下載量、看項(xiàng)目的最后提交時間、確認(rèn)與當(dāng)前運(yùn)行環(huán)境兼容。不要因?yàn)?AI 說推薦使用 xxx 包就直接裝。第五道檢查合并前人工 review。無論 AI 生成代碼的質(zhì)量多高PR 都必須經(jīng)過人類審查。而且審查者不能只是大概看一遍要針對你信任分層里的高風(fēng)險點(diǎn)逐一確認(rèn)依賴變更說明、異常處理路徑、敏感信息泄露風(fēng)險。如果團(tuán)隊里每個人都只是AI 生成 → 自測通過 → 合并那代碼評審制度就名存實(shí)亡了。5. 用提示詞工程保護(hù)思考讓 AI 暴露不確定性很多開發(fā)者沒有意識到提示詞的質(zhì)量直接決定了 AI 輸出的可信度。默認(rèn)情況下AI 傾向于給出一個自信、完整、不含糊的回答——因?yàn)橛?xùn)練數(shù)據(jù)里權(quán)威回答的權(quán)重很高。但你需要的是它能幫你暴露風(fēng)險和不確定性而不是給你一種一切盡在掌握的錯覺。所以設(shè)計提示詞時的一個重要思路是強(qiáng)制 AI 輸出它的不確定點(diǎn)。一個在實(shí)際項(xiàng)目中很有效的提示詞模板請評估下面這段數(shù)據(jù)庫遷移腳本在 PostgreSQL 13 上執(zhí)行的影響。 要求 1. 先列出你認(rèn)為該腳本在什么條件下是安全的。 2. 然后列出該腳本可能失敗或破壞數(shù)據(jù)的 3 個場景。 3. 對每個風(fēng)險點(diǎn)給出你的置信度高/中/低。 4. 如果信息不足請直接說明缺失了哪些信息不要猜測。 腳本 ALTER TABLE orders ADD COLUMN status VARCHAR(20) NOT NULL DEFAULT pending;注意第三點(diǎn)和第四點(diǎn)的關(guān)鍵作用。第一點(diǎn)幫你看到 AI 的假設(shè)前提第二點(diǎn)逼它去思考負(fù)面情況第三點(diǎn)讓 AI 從權(quán)威模式切換到概率評估模式第四點(diǎn)則杜絕了信息不足時強(qiáng)行編造的傾向。同理在代碼評審場景可以用反討好提示詞你是資深后端開發(fā)工程師正在給一位 3 年經(jīng)驗(yàn)的同事評審技術(shù)方案。請先指出這個方案里你認(rèn)為最不可靠的假設(shè)再說優(yōu)點(diǎn)。不要為了讓我滿意而刻意贊同我已有的結(jié)論。這個提示詞之所以有效是因?yàn)樗@式地告訴你希望 AI 怎么做而不是依賴 AI 自己領(lǐng)悟。大模型不會拒絕你的明確要求但也不會主動做你沒要求的事。所以在提示詞里明確寫先列出反例、再給結(jié)論、標(biāo)注置信度實(shí)際上就是在給驗(yàn)證環(huán)路裝回開關(guān)。這里做一個直觀對比。錯誤的提問方式這段代碼有 bug 嗎正確的提問方式這段代碼在什么情況下會出錯請先列出你發(fā)現(xiàn)的所有隱患再給出修復(fù)建議。前者的默認(rèn)答案是沒發(fā)現(xiàn)問題或者有一個小問題修復(fù)如下——AI 會順著你的期待走。后者的默認(rèn)答案是帶著負(fù)面視角去掃描代碼你用提示詞逼它展示不確定性自己就能省下大量排查時間。6. Agent 場景的批判性思維給自主執(zhí)行設(shè)計護(hù)欄AI Agent 是比代碼生成更進(jìn)階的使用場景。Agent 不只給你建議它還能自己拆解任務(wù)、調(diào)用工具、操作環(huán)境、生成文件?？雌饋砗苊赖@里的風(fēng)險量級完全不同一個錯誤操作可能導(dǎo)致文件被覆蓋、配置被修改、命令被執(zhí)行。在 Agent 場景里保持批判性思維靠的不是時刻盯著屏幕——那太累了而且人總有走神的時候。更可靠的做法是在 Agent 工作流里內(nèi)置護(hù)欄把人監(jiān)督變成流程強(qiáng)制。第一個護(hù)欄是執(zhí)行前審批。Agent 規(guī)劃好任務(wù)后不能直接執(zhí)行必須先把執(zhí)行計劃展示給人等人確認(rèn)后才能繼續(xù)。這一步打斷了AI 決策 → AI 行動的閉環(huán)強(qiáng)制插入了一個人類判斷節(jié)點(diǎn)。第二個護(hù)欄是最小權(quán)限。Agent 執(zhí)行任務(wù)時只授予它完成當(dāng)前任務(wù)所需的最小權(quán)限。比如它只是處理某個目錄下的文件轉(zhuǎn)換你就不應(yīng)該讓它擁有刪除整臺服務(wù)器文件的能力。權(quán)限越小錯誤操作的爆炸半徑越小。第三個護(hù)欄是審計日志。Agent 做的每一步操作都要有記錄包括時間、操作對象、具體命令或變更內(nèi)容。出了問題能回放、能定位、能回滾這本身就是一種降低風(fēng)險的方式。下面是一個簡化示意展示帶護(hù)欄的 Agent 工作流應(yīng)該長什么樣# 文件路徑agent_workflow.py # 說明這是一個結(jié)構(gòu)化示意不是可運(yùn)行的產(chǎn)品代碼 class GuardedAgentWorkflow: def __init__(self, agent, auditor): self.agent agent self.auditor auditor def run(self, task: str): # 第 1 步Agent 先生成計劃不直接執(zhí)行 plan self.agent.plan(task) print(Agent 計劃) for step in plan.steps: print(f - {step.action} - {step.target}) # 第 2 步人工審批 if not confirm_before_execution(plan): return 任務(wù)已取消未執(zhí)行任何操作 # 第 3 步在最小權(quán)限范圍內(nèi)執(zhí)行并記錄審計日志 with restricted_scope_ctx() as scope: for step in plan.steps: self.auditor.before(step) # 記錄執(zhí)行前狀態(tài) result self.agent.execute(step, scopescope) self.auditor.after(step, result) # 記錄執(zhí)行后結(jié)果 if not step_is_safe(result): self.auditor.alert(step, result) return 執(zhí)行中斷等待人工介入 return 任務(wù)完成完整日志已保存這個示意代碼里值得注意的點(diǎn)Agent 的執(zhí)行被拆成了計劃 → 審批 → 執(zhí)行 → 審計四個環(huán)節(jié)。人不需要全程盯著 Agent 的每個動作但必須在關(guān)鍵決策點(diǎn)上保持在場。計劃審批是一個點(diǎn)執(zhí)行中異常中斷是一個點(diǎn)執(zhí)行后審計是兜底。這三個點(diǎn)覆蓋了大部分風(fēng)險。如果你的 Agent 還在設(shè)計階段建議把回滾也作為默認(rèn)能力。任何 Agent 執(zhí)行的變更都應(yīng)該有一個明確的回滾方案否則一旦出錯你的選擇只有人工修復(fù)這一條路這會讓風(fēng)險大幅上升。7. AI 測試與數(shù)據(jù)分析不要盲目相信 AI 給的結(jié)論AI 輔助測試和數(shù)據(jù)分析越來越常見但這里有一個特別容易讓人放松警惕的地方AI 生成的結(jié)論往往有結(jié)構(gòu)化的形式、清晰的圖表、合理的敘述看起來非常專業(yè)。然而形式上的可信度不等于事實(shí)上的正確性。舉個例子。AI 分析一份線上日志后告訴你P95 響應(yīng)時間在最近兩周內(nèi)上升了 40%主要原因是訂單接口出現(xiàn)慢查詢。這個結(jié)論模板看起來完全合理但你需要驗(yàn)證的東西很多它分析的日志日期范圍是否覆蓋了完整的業(yè)務(wù)周期它挑選的樣本是否存在偏差主要原因是訂單接口慢查詢這個結(jié)論是從數(shù)據(jù)里推出來的還是因?yàn)槿罩纠镉唵谓涌诘膱箦e很多所以它主觀地做了歸因在 AI 輔助數(shù)據(jù)分析的場景批判性思維表現(xiàn)為三個動作第一交叉驗(yàn)證。用不同的工具、不同的查詢方式、不同的數(shù)據(jù)源看能不能得到相同結(jié)論。如果 AI 說 P95 響應(yīng)時間上升了你應(yīng)該自己看一下原始監(jiān)控系統(tǒng)的趨勢圖兩個來源對得上才可信。第二檢查統(tǒng)計口徑。AI 不會主動告訴你它怎么定義P95、怎么處理異常值、怎么定義上升。這些統(tǒng)計口徑直接決定結(jié)論是否成立。你不能在不知道口徑的情況下接受一個數(shù)字。第三對結(jié)論進(jìn)行可復(fù)現(xiàn)性檢驗(yàn)。給 AI 同樣的數(shù)據(jù)和同樣的分析任務(wù)隔一天再問一次看結(jié)論是否一致。如果結(jié)論差異明顯說明 AI 的分析本身不穩(wěn)定這比結(jié)論本身更值得警惕。至于 AI 測試常見的坑是AI 生成的測試用例看起來很全但測試價值很低。AI 傾向于生成與實(shí)現(xiàn)邏輯一致的測試——它讀了你的代碼然后寫一組斷言來驗(yàn)證這段代碼做了它該做的事。但好的測試應(yīng)該驗(yàn)證代碼在各種環(huán)境下都不出錯而不是驗(yàn)證代碼按既定邏輯運(yùn)行。所以人工補(bǔ)充異常場景測試、并發(fā)測試、性能測試依然不可替代。從效率角度看AI 生成測試用例的基礎(chǔ)版本是劃算的但你必須把它當(dāng)成初稿而不是終稿。審查每一組斷言是否真的有驗(yàn)證價值是測試場景里最核心的批判性思維。8. 團(tuán)隊層面保護(hù)批判性思維代碼審查、失效清單與對抗性提問個人習(xí)慣是基礎(chǔ)但團(tuán)隊機(jī)制更可靠。一個團(tuán)隊如果從制度上默認(rèn)程序員應(yīng)該理解自己提交的每一行代碼那么 AI 使用就會停留在效率工具的層面而不會變成判斷外包。比較實(shí)用的機(jī)制有三個。第一PR 描述里顯式標(biāo)注 AI 參與度。很多團(tuán)隊用模板約束 PR 描述但模板里值得增加一欄本 PR 中哪些內(nèi)容由 AI 生成人工驗(yàn)證了哪些點(diǎn)如果沒有人工驗(yàn)證點(diǎn)PR 直接打回。這個機(jī)制不復(fù)雜但它強(qiáng)制每個人在提交代碼前至少想一次我到底有沒有理解這段代碼。想一次就比不想強(qiáng)很多。第二維護(hù)一份AI 失效清單。團(tuán)隊里每個人在真實(shí)工作中遇到 AI 給出錯誤答案、幻覺 API、誤導(dǎo)性建議時都可以記錄到共享文檔里。條目包括場景描述、AI 給出了什么、實(shí)際正確是什么、錯誤原因分析。維護(hù)一段時間后這份清單就成了團(tuán)隊專屬的AI 陷阱地圖。新成員入職時讀一遍能少踩大量坑。它同時也在不斷提醒團(tuán)隊AI 不是權(quán)威是需要驗(yàn)證的對象。第三對抗性提問成為 review 文化的一部分。代碼評審時除了問這段代碼對不對還要問AI 為什么這樣寫還有沒有別的實(shí)現(xiàn)方式如果輸入完全出乎意料會怎樣。不是所有問題都要在 PR 里解決但提出這些問題是必要的它讓 AI 生成代碼從被接受變成被審視。對抗性提問示例評審 AI 生成的代碼時建議逐條過一遍 1. 這段代碼在沒有 AI 的情況下你會怎么寫差異在哪里 2. 它用了哪些你沒見過的 API 或模式你驗(yàn)證過它們的正確性嗎 3. 輸入數(shù)據(jù)不符合預(yù)期時這段代碼會表現(xiàn)出什么行為 4. 這個實(shí)現(xiàn)的錯誤信息對排查問題有幫助嗎 5. 有沒有隱藏的副作用比如修改了全局狀態(tài)、寫入了不該寫的文件這一組問題不針對 AI而是針對代碼本身。但它特別適合用來審查 AI 生成的代碼因?yàn)?AI 生成代碼最大的特點(diǎn)就是沒有可追溯的設(shè)計過程只能靠外部審視來彌補(bǔ)。9. 總結(jié)與下一步實(shí)踐回到開頭的問題用 AI 而不失去批判性思維這件事到底怎么做我的判斷是AI 的價值在于放大你的能力而不是替代你的判斷。它替你完成生成文本、生成代碼、初步分析這些高重復(fù)性工作但驗(yàn)證、權(quán)衡、決策這些真正體現(xiàn)工程水平的部分必須留在人的手里。這不是道德要求而是工程風(fēng)險的必然結(jié)論——AI 的生成機(jī)制不可靠你只能通過驗(yàn)證讓它變得可靠。這篇文章里真正值得記住的幾個操作點(diǎn)判斷任務(wù)風(fēng)險等級用信任分層決定驗(yàn)證強(qiáng)度而不是對 AI 的所有輸出一視同仁。AI 生成的代碼必須經(jīng)過需求先行、代碼解釋、邊界測試、依賴審查、人工 review五道檢查。用提示詞強(qiáng)制 AI 暴露不確定性列出反例、標(biāo)注置信度、說明缺失信息。Agent 場景靠護(hù)欄不靠盯屏執(zhí)行前審批、最小權(quán)限、審計日志。團(tuán)隊層面用 PR 標(biāo)注、失效清單、對抗性提問把 AI 批判性思維變成制度而不是個人自覺。你不需要戒掉 AI也不需要成為 AI 懷疑論者。你只需要在每次按 Tab 接受 AI 建議之前多問一句它為什么是對的如果這個習(xí)慣堅持一個月你會發(fā)現(xiàn)自己的代碼質(zhì)量在上升對 AI 輸出價值的判斷也越來越準(zhǔn)確。下一步的實(shí)踐可以很簡單從明天開始每天挑一個 AI 給你的回答故意找它的一個漏洞——一個沒考慮到的邊界、一個編造的 API、一個不成立的假設(shè)。每天挖一個一個月后你對 AI 的信任和懷疑就都處在正確的位置上了。建議收藏這篇文章等你遇到問題時再翻出來對照一遍。