面試環節第一步——回答問題，寫軟件需求

面試環節第二步——上手寫代碼

測試用例

比 ChatGPT 背后 GPT-3.5 更為強大的模型 GPT-4，已正式對外發布。在 OpenAI 官方發布的 GPT-4 Developer Livestream（https://www.youtube.com/watch?v=outcGtbnMuQ）視頻中，我們親眼見證了 OpenAI CTO Greg Brockman 演示了 GPT-4 將一張手繪草稿架構圖變成一個現實可滑動的網站；同時，它也能幫助我們直接生成代碼，甚至當我們把代碼運行報錯的界面截一個圖發給 GPT-4 時，它就能給出相應的解決方案提示。

這種直接對標程序員飯碗的工具，在日常開發場景下，生成的代碼是否真的可用？如果說 ChatGPT 達到了 Google L3 級別工程師，能拿到 18.3 萬美元的薪資，那么 GPT-4 處于一個什么樣的編碼地位？

近日，前 Google 軟件開發工程師、現任 IT 在線學習平臺 Scaler 的教學系統設計師 Naman Bhalla 模擬了 GPT-4 去參加 Uber 這類公司面試會遇到的問題，其以“設計一個分布式緩存系統”為主題，探討 GPT-4 在面試環節中的表現情況。

目前，他還把包含所有測試用例的完整代碼放到 GitHub 上公開了出來：https://github.com/Naman-Bhalla/lldassignments/tree/master/src/main/java/dev/naman/lldassignments/casestudies/distributedcache/solution

整體而言，在寫需求、回答問題、寫代碼環節中，GPT-4 能力達到普通工程師級別。不過，在測試用例環境，GPT-4 似乎失去上下文的邏輯性，甚至一度把自己搞懵。

接下來，我們將分享 Naman Bhalla 測試的全過程。

面試環節第一步——回答問題，寫軟件需求

軟件項目開發過程中，對于程序員而言，實施軟件開發的基礎就是要先寫一份軟件需求說明。

因此，在開始時，Naman Bhalla 提出要求 GPT-4 ——“為 Uber 構建一個分布式緩存，給我寫一份問題需求?！?/p>

一句話之后，GPT-4 快速地給出了標題、問題描述、具體的要求：

標題：Uber 的分布式緩存系統

問題描述：

設計并實現一個分布式緩存系統，可以有效地存儲和管理 Uber 服務的數據。該緩存應支持高可用和可擴展的架構，以滿足 Uber 不斷增長的對快速和高效數據檢索的需求。

要求：

1.設計一款分布式緩存系統，可以支持以下操作：

a. Put(key, value): 將鍵值對存儲在緩存中。

b.Get(key)：如果它存在于緩存中，檢索與給定鍵相關的值。

c.Delete(key)：從緩存中刪除與給定鍵相關的鍵值對。

2.緩存應該有一個可配置的大?。ㄦI值對的數量）和一個可配置的生存時間（TTL，Time to live）。當緩存達到最大容量時，系統應該刪除最近使用最少的項目（LRU）來為新的項目騰出空間。

3.確保緩存分布在多個節點上，以提高可擴展性和可用性。設計系統能夠良好地處理節點故障和網絡分區。

4.實施一致性散列的機制，將鍵值對均勻地分布在緩存的各個節點上。

5.系統應該支持水平擴展。它應該很容易地從緩存中增加或刪除節點，而不會有明顯的停機時間或數據損失。

6.為數據的一致性和容錯性實施讀和寫的法定人數。該系統應該能夠處理并發的讀和寫，而不會造成數據的不一致。

7.包括監控和記錄功能，可以跟蹤高速緩存系統的健康和性能。

8.設計一個簡單的用戶界面或命令行界面來與緩存系統進行交互，允許用戶執行諸如放、取和刪除等操作

9.編寫測試案例來驗證緩存系統的正確性和可靠性

GPT-4 能夠說出基本要求，準確度也不錯?？梢哉f，過了第一關。

緊接著，Naman Bhalla 針對分布式緩存中一些經典的問題進行了提問，比如：“如何確保代碼中支持類似于讀取自己的寫入數據（Reading your own writes）的一致性問題？”、“緩存可以支持哪些功能？是不是包括一些優化、可擴展性和對客戶可用性的保證？”

對于提供一些文字解答方面，GPT-4 給出的答案都很充分，還列出了多個小點，便于大家很直觀地看出回答的錯與對。

針對第一問時，其答復道：

讀取自己的寫入數據（Reading your own writes）的一致性保證了一旦客戶端進行了寫操作，所有來自同一客戶端的后續讀操作都會返回更新的數據。為了保證分布式緩存系統的這種一致性水平，你可以實施以下策略：

基于 Session 的方法。

客戶端緩存。

粘性路由。

讀后寫的一致性。

版本管理或時間戳。

因果一致性。

第二個問題，GPT-4 回答，“緩存可以支持各種功能、優化和保證，以提高它的性能、可擴展性和對客戶的可用性。其中一些功能包括驅逐策略、生存時間（TTL）、數據一致性、緩存分區、緩存復制、緩存的持久性等等”。

基于 Spring Boot + MyBatis Plus + Vue & Element 實現的后臺管理系統 + 用戶小程序，支持 RBAC 動態權限、多租戶、數據權限、工作流、三方登錄、支付、短信、商城等功能

項目地址：https://github.com/YunaiV/ruoyi-vue-pro

視頻教程：https://doc.iocoder.cn/video/

面試環節第二步——上手寫代碼

當問題以不錯的結果完成之后，接下來，所謂是騾子是馬，拿出來溜溜，由此也進入了程序員崗位最為重要的實操環節——寫代碼。

Naman Bhalla 給出的要求是，讓 GPT-4 用 Java 編寫一個分布式緩存的代碼，支持以下要求：

值得注意的是，上文解答過程中，足以讓 GPT-4 能夠把 Naman Bhalla 提出的 5 項要求弄懂。

不過，當拿到最新寫代碼需求時，GPT-4 首先還是有些懵，其表示，“由于問題的復雜性和和響應格式的限制，我不能提供分布式緩存系統的完整代碼。但是，我可以給你一個系統組件的大綱和一些代碼片段，由此可以幫助你開始實施這個系統。你可以根據你的要求修改和擴展這些代碼片段?！?/p>

于是它提供了四個部分的代碼片段：

CacheNode

DistributedCache

ConsistentHashing

CacheClient

當然，這對于想要“坐享其成”的程序員而言，未必是一個好消息，大家都想要拿來就能用的代碼，必然不想聽到只給代碼片段的回復。

因此，當 Naman Bhalla 繼續要求 GPT-4 實現 CacheNode 的完整代碼時，GPT-4 還是滿足了他的小心思，提供了完整的算法和代碼：

除了 CacheNode 這部分的代碼之外，Naman Bhalla 相繼得到了 GPT-4 提供的 DistributedCache、ConsistentHashing、EvictionStrategy（接口以及LRU 和 LFU 實現）的代碼。

不知道什么原因，GPT-4 決定不再提供關于 Request Collapsing、Async Processing、Prefetching 的代碼。不過，如果進一步跟它提要求，支持這些功能時，它還是嗒嗒嗒地敲下了這些代碼。

當然，在這過程中，站在程序員的角度來看，想要 GPT-4 生成的代碼即可用，首先要看得懂這些代碼，知道分布式緩存系統實現的具體邏輯，否則，缺失哪一塊都不知道，更別論拿著代碼去運行了。

基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 實現的后臺管理系統 + 用戶小程序，支持 RBAC 動態權限、多租戶、數據權限、工作流、三方登錄、支付、短信、商城等功能

項目地址：https://github.com/YunaiV/yudao-cloud

視頻教程：https://doc.iocoder.cn/video/

測試用例

完整的代碼有了之后，便進入了寫測試用例的時候了。Naman Bhalla 直接要求 GPT-4 編碼每個部分的 junit 測試示例。

GPT-4 的回復是：

為了測試 DistributedCache 的實現，我們將創建一個名為"DistributedCacheTest "的 JUnit 測試類。這個測試類將涵蓋以下情況：

測試基本的 put 和 get 功能。

測試刪除功能。

測試添加和刪除一個緩存節點。

測試請求合并。

測試 prefetching。

很顯然，GPT-4 知道要測試哪些用例，也寫了正確的測試用例。

不過，它并沒有寫最后一個關于 prefetching 的測試用例。因為它的邏輯沒有被定義。為此，GPT-4 提供了一些建議，如「你需要在 DistributedCache 類中實現 prefetchKeys 方法，該方法根據給定的鍵生成一個 prefetch 的鍵列表。一旦你實現了這個方法，你就可以添加一個測試案例來驗證 prefetch 是否按預期工作?！?/p>

承接上文，Naman Bhalla 建議 GPT-4 還是自己直接給出一個自定義 prefetch 的示例。不出意料，GPT-4 照做了，然后實現了測試。

Naman Bhalla 表示，由于在面試過程中，面試官經常問程序員如何在代碼中支持 XXX。于是，他本著好奇的性子，就問 GPT-4 在實現中如何支持讀取自己的寫入數據（Read your own writes）。

Naman Bhalla 注意到，GPT-4 所寫的一個測試用例是不穩定的，因為它產生了非確定性的輸出。由于并發性，它產生了非確定性的輸出。當 Naman Bhalla 進一步向 GPT-4 問了這個問題，它很快就糾正了錯誤。

然而，當要求 GPT-4 實現對給定線程的密鑰請求的粘性，以確保沒有一致性問題。

GPT-4 答復道：“為了確保每個鍵的請求都進入同一個線程，你可以在 CacheNode 類中使用ExecutorService創建一個線程池。每個鍵將根據其散列代碼被散列到一個特定的線程，以確保對一個特定鍵的所有操作都由同一個線程執行?！?/p>

事實上，它提出了一個非最佳的 ExecutorService，但告訴 Naman Bhalla 最佳的解決方案是什么，并且也進行了編碼。

不知何故，GPT-4 在這里開始發狂了。開始不斷重復自己的代碼，而不是完成代碼。另外，ExecutorService 的實現是錯誤的。它沒有擴展超類，也沒有實現它的所有方法。

當 Naman Bhalla 要求 GPT-4 修復這個問題時，“它似乎已經瘋了”，Naman Bhalla 無奈地說道。

因為，GPT-4 不僅沒有修復上面的問題，反而又創建了一個新的 Cache 類，它基本上在做與 CacheNode 相同的工作。Naman Bhalla 稱，最初認為 GPT-4 這樣做可能是為了提高代碼質量。但似乎它已經開始忘記上文了，再次定義了許多先前已經定義的類。

為了讓 GPT-4 回歸正軌，Naman Bhalla 復制粘貼了它之前寫的 CacheNode 的代碼，并要求它為新的 ExecutorService 修改它。

最終，GPT-4 雖然犯了一些錯誤，但在提示下得到了修復。修復完成之后，Naman Bhalla 又要求 GPT-4 再寫一些測試用例來全面測試。特別是針對并發請求。但由于 GPT-4 已經開始失去上文背景，所以它不可避免地又犯了錯誤，Naman Bhalla 不得不告訴它之前寫的代碼。

幾經折騰，GPT-4 終于實現了正確的測試用例：

寫在最后

整體而言，GPT-4 提供了完整的分布式緩存系統代碼，其能力處于一個不錯的水平。不過，距離理想中的一鍵就能生成可用的代碼，還有很長的距離，仍然需要程序員從中不斷提供“提示語”，并優化糾錯。

那么，如果讓 GPT-4 作為工程師入職，你會支持還是拒絕？
責任編輯：彭菁