Claude Code負責人Lenny Rachitsky拋出"Coding is solved"的觀點，引發技術圈熱議。作為測試工程師，我們該如何看待這場AI革命？是恐慌、抗拒，還是擁抱？

背景：一句話炸翻技術圈

前幾天刷到Claude Code負責人Lenny Rachitsky的訪談，他説了句讓整個技術圈炸鍋的話：

"Coding is solved"（編程已解決）

這話什麼意思？簡單説就是：有了Claude Code這樣的AI編程助手，寫代碼已經不是問題了，未來的開發者主要工作是"提出正確的問題"而不是"寫代碼"。

説實話，看到這句話的第一反應，我心裏咯噔一下。

作為一名測試老兵，這些年一直在努力提升代碼能力，為了更好地做自動化測試、看懂開發同事的代碼、定位Bug的根因。現在告訴我"寫代碼不重要了"，那我這些年積累的技能是不是要廢了？

但冷靜下來想了一週，又實際試用了Claude Code，我發現事情沒那麼簡單。

今天就從測試工程師的視角，聊聊我對"Coding is solved"這個觀點的真實感受，以及我們這個職業在AI時代的真正價值。

核心內容

Claude Code到底有多強？

先説體驗。我用Claude Code幫我重構了一個單元測試模塊，總共300多行代碼。

之前我的做法：

1. 理解業務邏輯，畫時序圖
2. 設計測試用例，考慮邊界條件
3. 手寫Mock對象
4. 一行行寫斷言
5. 跑測試，修復失敗的用例
6. 補充遺漏的場景
7. 整個過程大概4-5小時

用Claude Code之後：

1. 描述需求："幫我為這個UserService類寫單元測試，覆蓋正常、異常、邊界場景，使用Mockito"
2. Claude Code分析代碼，自動生成測試
3. 檢查生成的測試，補充幾個特殊場景
4. 跑測試，全綠
5. 整個過程不到40分鐘

這效率提升確實讓人驚豔。從這個角度看，"Coding is solved"也不是完全沒有道理——常規的、套路化的編程工作，AI確實可以做得又快又好。

但是（重點來了），真的就"解決"了嗎？

"Coding is solved"背後的真相

我覺得這句話只説對了一半。更準確的表述應該是：

"Template coding is solved"（模板化編程已解決）

但真正考驗技術功力的"複雜編程"，AI還遠沒到"解決"的程度。

我試了幾個場景，發現Claude Code的侷限：

場景1：業務邏輯複雜的測試用例

我讓Claude Code為一個涉及多狀態流轉的訂單系統寫集成測試。它生成了大概80%的代碼，但缺失了幾個關鍵場景：

• 訂單在"待支付"狀態下的超時取消邏輯
• 併發創建訂單時的庫存一致性校驗
• 優惠券疊加使用的邊界條件

這些場景都需要深入理解業務才能設計出來，AI只能看到代碼，看不到業務背後的規則。

場景2：性能測試的腳本設計

我讓Claude Code幫我寫一個JMeter壓測腳本。它能生成基本的HTTP請求配置，但對於以下問題束手無策：

• 如何根據線上流量分佈設計TPS目標？
• 如何模擬真實用户的操作路徑，而不是隨機請求？
• 如何設計數據預熱策略，避免冷啓動影響測試結果？

這些都需要經驗和判斷，AI目前做不到。

場景3：缺陷定位的深度分析

我故意模擬了一個偶發的空指針異常，日誌裏只有堆棧信息，沒有業務上下文。我讓Claude Code幫忙分析，它給出了幾個可能的"常見原因"，但都沒抓住關鍵。

最後還是需要靠：

1. 梳理業務流程，找到可疑的代碼路徑
2. 在可疑位置加日誌，重新復現
3. 通過日誌對比，定位到真正的問題

這個過程需要推理、假設、驗證，AI目前只能做到"基於已有模式的匹配"，做不到"基於業務理解的推理"。

測試工程師的真正價值在哪裏？

"Coding is solved"這句話如果真成立，那測試工程師的價值在哪裏？

我認為，測試工程師的核心價值從來就不是"寫代碼"本身，而是"發現問題的能力"和"保證質量的思維"。

代碼只是工具，不是目的。

讓我換個角度説：

AI可以幫你寫測試腳本，但它不能決定"測什麼"
AI可以幫你生成測試數據，但它不能判斷"什麼數據是有效的"
AI可以幫你執行測試用例，但它不能設計"如何讓系統崩潰"

這些都需要測試工程師的專業判斷。

實戰案例：AI做不了的測試

分享一個朋友公司案例。去年他們公司上線了一個新的推薦系統，負責算法的團隊信心滿滿，説準確率提升了15%。

但測試團隊發現了幾個嚴重問題：

問題1：冷啓動偏差
新用户第一次打開App，推薦結果全是熱門內容，完全沒有個性化。這説明推薦系統對"新用户"這個特殊場景考慮不足。

AI生成的測試用例都是基於正常用户行為設計的，想不到"剛註冊的空白用户"這種邊緣場景。

問題2：時間衰減異常
晚上推薦的內容跟中午完全一樣，沒有考慮用户興趣的時間變化。比如用户中午看美食，晚上看娛樂，但推薦系統沒有捕捉到這個模式。

這需要對用户行為模式有深入理解，AI看不到業務背後的邏輯。

問題3：長尾內容曝光異常
熱門內容的曝光率超過90%，中長尾內容幾乎沒有機會。這會導致內容生態惡化，長期看對平台不利。

這需要從產品戰略高度思考，AI做不到。

這些問題都不是"寫代碼"能解決的，而是需要測試思維、業務理解、產品視角。

AI能幫你快速寫出測試腳本，但這些腳本"測什麼"、"怎麼測"、"測到什麼程度"，必須由人來決定。

優缺點分析

Claude Code這類AI工具的優點

1. 效率提升明顯

   • 常規測試腳本的編寫速度提升5-10倍
   • 減少重複勞動，讓人專注更重要的工作

2. 降低技術門檻

   • 新手測試工程師也能快速上手自動化測試
   • 不需要深入學習各種測試框架的細節

3. 代碼質量穩定

   • 生成的代碼符合最佳實踐
   • 減少低級錯誤

侷限性

1. 業務理解不足

   • 看不到代碼背後的業務邏輯
   • 難以設計針對業務漏洞的測試用例

2. 邊緣場景覆蓋差

   • 更傾向於測試"正常路徑"
   • 對異常、邊界、併發場景考慮不足

3. 複雜推理能力弱

   • 無法進行深度的缺陷根因分析
   • 難以設計複雜的測試策略

適用場景

• ✅ 單元測試：生成基礎測試用例效率很高
• ✅ API接口測試：快速生成請求和斷言
• ✅ UI自動化腳本：錄製回放場景效率提升明顯

不適用場景

• ❌ 複雜業務場景的測試設計：需要深入理解業務
• ❌ 性能測試策略制定：需要經驗和判斷
• ❌ 安全測試：需要攻擊思維和漏洞知識

最佳實踐/建議

基於我的使用經驗，給測試工程師幾個實用建議：

1. 把AI當助手，不是替代品

正確用法：

• AI生成基礎代碼 → 你補充業務邏輯
• AI提供測試用例 → 你設計邊緣場景
• AI執行自動化測試 → 你分析測試結果

錯誤用法：

• AI生成什麼就用什麼，不檢查
• 完全依賴AI設計測試策略
• 把AI的輸出當成最終結果

2. 提升不可替代的核心能力

既然AI能幫你寫代碼，那你應該把精力放在AI做不了的事情上：

業務理解能力

• 深入瞭解產品背後的業務邏輯
• 能識別業務規則中的漏洞和風險點

測試設計能力

• 能設計出覆蓋全面的測試策略
• 能想到AI想不到的邊緣場景

缺陷分析能力

• 能從表面現象推導根本原因
• 能提供有價值的修復建議

溝通協調能力

• 能跟開發、產品、運維有效溝通
• 能推動質量問題的解決

3. 學會"提問"比"寫代碼"更重要

Claude Code負責人的觀點有道理：未來更重要的是"提出正確的問題"。

對測試工程師來説，這意味着：

• 能清晰地描述測試需求
• 能給出充分的上下文信息
• 能對AI的輸出進行有效反饋

比如，不要只説"幫我寫個測試"，而要説：

幫我為PaymentService的processPayment方法寫單元測試，
場景包括：
1. 正常支付流程（成功扣款、訂單狀態更新）
2. 餘額不足（拋出InsufficientBalanceException）
3. 支付超時（模擬第三方支付接口超時）
4. 併發支付（同一訂單多次支付）
使用Mockito模擬依賴的PaymentGateway和OrderRepository，
確保測試是獨立的，不依賴外部系統。

這樣AI才能生成真正有用的測試代碼。

4. 保持學習，但不要焦慮

AI確實在改變這個行業，但不是在"消滅"這個職業，而是在"升級"這個職業。

歷史上每一次技術革命都會引發恐慌：

• 計算器出現時，有人説會計會失業
• Excel出現時，有人説統計員會失業
• 自動化測試出現時，有人説手工測試會失業

但結果呢？

• 會計轉型為財務分析師
• 統計員轉型為數據科學家
• 手工測試工程師轉型為自動化測試工程師

每一次技術革命，淘汰的不是職業，而是"只做重複勞動"的人。

未來展望

我的判斷：

未來3-5年，測試工程師這個職業不會消失，但會兩極分化：

低端測試（重複執行、簡單腳本）會被AI取代
高端測試（測試設計、質量策略、風險控制）會更值錢

測試工程師的技能樹會從：

• 編碼能力 → 測試設計能力
• 工具使用 → 業務理解
• 執行測試 → 質量規劃

簡單説：AI幫你寫測試腳本，你來設計測什麼、怎麼測、測到什麼程度。

總結

回到開頭的問題："當Claude Code負責人説'編程已解決'，測試工程師該慌嗎？"

我的答案是：不該慌，但該變。

不該慌，因為測試工程師的核心價值從來就不是"寫代碼"，而是"保證質量"。AI能幫你寫測試腳本，但它不能代替你設計測試策略、分析業務風險、發現隱藏缺陷。

該變，因為AI確實在改變這個行業的規則。如果你只會寫簡單的測試腳本、執行重複的測試用例，那確實該焦慮了。但如果你具備業務理解能力、測試設計能力、缺陷分析能力，AI反而會成為你的武器，讓你更高效地工作。

未來不屬於會寫代碼的測試工程師，也不屬於會用AI的測試工程師，而是屬於"懂業務、會設計、善用AI"的測試工程師。

所以，別慌，學起來。

參考資料

1. Claude Code Creator: "Coding is solved"訪談
2. Large Language Model Reasoning Failures論文
3. Claude Code CLI資源消耗問題討論