代碼生成交給機器，我們的工作將變成軟件概念的設計師 | 新程序員

【導讀】本文探討了軟件設計的本質和未來趨勢。作者通過分析三個爆款產品，提出了基於「概念」的軟件設計方法。他認為，真正的創新在於簡化應用場景，而非創造全新功能，創新往往不是創造新的東西，而是讓原本的事情做起來更加簡單。文章還討論了如何利用概念思維進行編程，並預測隨著 AI 代碼生成技術的發展，人類工作將更多地轉向概念設計和提示工程，而具體的代碼編寫則可能交給機器完成。

本文整理自 MIT 計算機與 AI 實驗室（CSAIL）副主任、ACM Fellow Daniel Jackson 教授在2024 全球軟件研發技術大會中的演講，同時收錄於《新程序員 008》。《新程序員 008》聚焦於大模型對軟件開發的全面支撐，囊括 Daniel Jackson 和 Daniel Povey 等研發專家的真知灼見與「AGI 技術 50 人」欄目的深度訪談內容，歡迎大家點擊訂閱年卡。

作者 | Daniel Jackson

責編 | 王啟隆

出品丨新程序員編輯部

縱觀軟件設計的歷史，可以見證這幾十年來我們取得的巨大成功。

如今，軟件具備了可用性，每天有數十億人在工作和娛樂中使用軟件。得益於編程技術、分佈式計算、網絡服務、數據庫等領域的成功，軟件具備了可擴展性。而且，由於人工智能技術的蓬勃發展，軟件變得越來越智能。

但與此同時，我們也面臨著一些巨大的挑戰。

由於在用戶界面、設計系統、以用戶為中心的計算方面取得了諸多進展，軟件逐漸變得可用了，但它仍然經常過於複雜，使用起來負擔很重。用戶經常需要花費大量時間去理解他們正在使用的軟件，而這一點在企業軟件中尤為明顯。我們的軟件或許是可擴展的，但它經常不安全，容易受到針對公司隱私和安全的攻擊。而且它也常常存在安全隱患，有引發災難的風險。還有個大家都很擔心的問題：儘管軟件正在變得更加智能，但也存在更加不可預測和不可靠的風險。

那我們該如何應對這些挑戰呢？我的建議是，回歸本源。作為工程師，不能僅僅通過發明新技術來解決這些基本的潛在問題，而是需要思考軟件的本質是什麼。特別是，工程師需要檢查軟件的功能，並提出問題：軟件應該做什麼？如何構建這種功能？

除此之外，軟件模塊化的問題可能比以往任何時候都更加重要。為了實現這點，還需要考慮用戶的心智模型，即讓用戶理解我們正在構建的系統。為了探討這些問題，我想分享三個所有人都很熟悉的成功產品案例。通過這些故事，再進一步思考：是什麼讓這些產品如此成功？

iPod 的成功之處：改變了人們聽音樂的渠道

iPod 誕生於 2001 年，可謂是相當有年頭的產品了。那麼，iPod 的創新之處在哪裡呢？顯然，它的創新並不在於工業設計。原因是，只要你看看 Dieter Rams 在 1958 年設計的口袋收音機，就很容易能發現它對 iPod 外觀設計的影響（如圖 1 所示）。iPod 無疑是具有標誌性的，但它在設計方面並不新穎。

在技術上，iPod 其實也沒什麼突破。史提芬·祖比斯在當年找到了東芝生產的一款異常小巧的 5GB 硬盤，從此縮小 iPod 的尺寸，取得了成功。而蘋果公司本身也有一個文件傳輸協議，使上傳音樂的速度變得更快。但這些都不是 iPod 真正必需的。因為數字設備公司（Digital Equipment Corporation, DEC）在 iPod 問世的幾年前就已經生產過一台 5GB 的個人點唱機，名叫 Personal Jukebox。

因此，我認為 iPod 的成功源於一個更簡單的原因。那就是 iPod 的基本應用場景簡化了人們以前必須做的事情。試想在 iPod 出現之前，人們使用 MP3 播放器時必須經歷的步驟：下載盜版音樂/轉錄 CD 光盤里的音樂 —— 上傳至個人的播放設備 —— 開始播放音樂。其中，前兩步的用戶體驗其實很差，因為用戶要麼只能偷偷盜版一些網絡上的非法音樂，要麼必須翻錄自己的 CD 光盤收藏，而無論是哪種選擇，操作都相當繁瑣。然後，他們還得想辦法弄清楚如何上傳曲目到自己的個人設備，最後才能播放。

iPod 的出現，把一個非常簡單的使用方式打包成了單一的應用場景。用戶從 iTunes 購買歌曲後，可以立即在電腦上播放，同步到 iPod 後也可以在上面播放。在這個應用場景中，iTunes 作為輔助角色至關重要。事實上，如果觀察 iPod 當年銷量的爆炸性增長，會發現這款產品真正主導市場的時刻是在 2006 年左右。那時，iPod 的銷量超過了任何其他 MP3 播放器。而在這一年，蘋果已經通過 iTunes 銷售了數億首歌曲。

所以，iTunes 對 iPod 來說是必不可少的，因為它使這個簡單的應用場景成為可能。現在，一個真正有趣的問題是：索尼為什麼沒能做到這一點？

你可能不知道，早在 1999 年，索尼就擁有成功所需的所有要素。索尼一直被視為全球最大的音樂集團之一，他們當時已經推出了一款出色的數字音頻播放器 Network Walkman，這是其經典產品 Walkman 的後代。它甚至在日本已經有一間名為 Bitmusic 的歌曲商店，但不知何故，索尼無法將旗下的頂級播放器和歌曲商店整合在一起。關於原因，也已經有很多討論，有人猜測可能是因為索尼使用了專有的壓縮方案（ATRAC），還有人猜測是因為索尼將商店限制在了日本本土發佈，更有甚者認為是數字版權管理（DRM）控制使軟件難以使用……但我認為，最關鍵的是，他們沒有一個簡單的應用場景。

當我們打開索尼 Network Walkman 的用戶手冊時，只需瀏覽一頁，就能立即感覺到這不是一個容易使用的設備（如圖 2 所示）。顯然，它缺乏一個簡單的應用場景。

WhatsApp 的成功之處：群聊

第二個案例是 WhatsApp。很多人認為 WhatsApp 的創新在於提供了免費短信服務。但實際上，在此之前已經有免費短信應用了，那就是比 WhatsApp 早了三年的 TextFree。如果回顧 WhatsApp 的發展歷程，我們會發現它從一開始就穩步增長，然後在 2011 年的某個時點突然出現爆髮式增長。那時發生了什麼？原來，WhatsApp 團隊當時發佈了一條推文（見圖 3）：「群聊功能現已上線。」

但在 2011 年的時候，其實有許多不同的公司都在爭相成為手機上運行群聊的首選應用程序，比如 GroupMe, Beluga 和 Yobongo。而 WhatsApp 最終在這場競爭中勝出。群組和群聊為什麼如此重要？我認為，這還是與簡化應用場景有關，並且還是一個非常簡單的創新。

仔細想想，在沒有群組的應用場景中，比如說電子郵件，每次你想擴大參與對話的人群時，新成員都必須被明確地添加為對話的接收者。這個過程和下載盜版音樂一樣，其實非常繁瑣。而通過群聊，你可以邀請人們，他們可以異步加入對話。這本質上是一種分佈式的負擔：每個人都以自己的節奏加入聊天，而不是由發起人一次性添加所有成員，讓人被迫接受對話。這樣，發送消息的人不會因為添加新成員而增加負擔，使得群組的擴展變得更加簡單和高效。

Zoom 的成功之處：會議鏈接

Zoom 的崛起是一個引人入勝的故事，它在疫情初期就取代了 Skype，而如果我們去查看那些預測 Skype 用戶增長的統計數據，會發現許多網站都認為 Skype 的用戶數量可以一直穩步增長到今年 —— 事實是，Zoom 的出現讓這些預測都化為了泡影。至少在美國，除了 Zoom 以外，幾乎每個影片會議平台基本上都逐漸衰落了，而 Zoom 則呈現爆髮式增長。

那麼，Zoom 的創新之處在哪裡？這裏有一個插曲：當時的英國首相鮑里斯·莊臣發了一條廣為人知的推文，宣佈他在 Zoom 上將舉行世界上首次「數字化內閣會議」。不幸的是，當他展示會議截圖時，無意中泄露了自己的會議鏈接（Meeting Link）。當時 Zoom 還沒有預設的安全控制，所以理論上任何人都可以通過輸入那個會議鏈接加入英國政府的內閣會議。

這個事故背後，其實隱藏著一個重要細節，且它恰恰揭示了 Zoom 成功的真正原因。

iPod 的創新之處不在於聽音樂，WhatsApp 的創新之處不在於聊天，所以 Zoom 的創新也不在於影片通話本身。影片通話技術可以追溯到 1960 年代，而後來的 Skype 也在影片通話這方面做得很好了。此外，Zoom 並沒有在設備上實現影片通話的技術創新，因為早在 1994 年，世界上首款商用網絡攝像頭 QuickCam 就已經很便宜了（當時售價 100 美元）。雖然 Zoom 確實有很好的影片質量，但它的核心創新也不是影片編碼技術，像 H.264 這樣的影片編解碼器（用於高效壓縮數字影片的標準）早已存在多年。

相反，Zoom 的創新在於它巧妙的「一鍵會議」應用場景。在 Zoom 之前，如果你使用 Skype 想邀請一群人開會，會遇到兩個麻煩。首先，你需要註冊應用程序，而且所有參會者也必須註冊。這意味著每個加入會議的人都必須是 Skype 用戶，並且擁有一個賬戶。其次，發起通話時，你必須逐個將所有參與者添加到通話中。

顯然，對於大型會議來說，這非常不便。誠然，Skype 確實有一個群組功能，使這個過程稍微簡化了一些。但它遠不如 Zoom 的「一鍵會議」應用場景那麼便捷。Zoom 的創意是，當你創建會議時，它會生成一個會議鏈接，你只需跟和別人分享這個鏈接，然後任何人都可以通過這個鏈接加入會議。這看似是個微小的創新，但實際上影響巨大。

我認為這正是 Zoom 成功的關鍵。縱觀其他影片會議平台的成功案例，沒有一個能真正與 Zoom 相提並論。而 Zoom 也並非首創者。事實上，幾年前就有一家名為 Join.me 的公司在其產品 Log Me In 中率先提出了會議鏈接的概念。Zoom 借鑒並完善了這個創意。這個創意如此成功，以至於隨後被其他所有競爭對手採用。特別是 Skype，在 2020 年 4 月才開始使用會議鏈接功能。但到那時，Zoom 已經擁有 3 億用戶，Skype 早被甩的遠遠落後了。這個創意之後還影響了其他平台，例如，Microsoft Teams 在幾年後也採用了會議鏈接的概念。

從場景（Scenario）到概念（Concept）

應用場景定義了產品，是關於如何使用產品的生動描述。

它既是一種社交協議（規定了用戶如何互動），同時也是一種 API（定義了技術層面的交互）。它揭示了產品將如何滿足用戶需求，代表了一種典型但並非唯一的使用方式。這種以應用場景為中心的產品思考方式不同於傳統的用例方法或多場景產品規劃。相反，它強調通過單一的核心應用場景來捕捉產品的設計理念。

現在，我想提出一個更具爭議的觀點：創新幾乎從來不會真正使全新的事物成為可能。仔細想想。回顧你所知道的所有創新發明，問問自己，「它們真的讓我能做任何全新的事情嗎？」 事實上，幾乎所有時候，創新所做的是讓你更容易完成你已經在做的事情，它是用一個新的應用場景來替代一個存在不便之處的舊應用場景。

現在我想將「場景」擴展到我稱之為「概念」的想法上。以 Zoom 為例，它的核心應用是提供會議鏈接服務，但除此之外，它還支持多種場景，比如在聊天會話中，用戶可以在聊天窗口發送文本消息。這些不同的場景交織並存，相互穿插，而每個場景都體現了我所說的「概念」（Concept），即一種獨立的功能單元。

概念是單個軟件、一類軟件以及各類軟件的特徵。概念可以讓開發者比較軟件，注意其必要的功能以及知道如何有效地使用這些功能。

因此，你可以將 Zoom 理解為由這些概念構建而成，包括會議鏈接、影片頻道（VideoChannel）等。其中一些概念是創新性的，如會議鏈接；有些是我們非常熟悉的，如在線聊天；還有一些是通用性的概念，幾乎在每個應用程序中都能見到，例如用戶身份驗證，這是最典型的通用性概念之一。

這些概念通過「交互+同步」的方式融合在一起。在使用 Zoom 時，你不需要特意開啟聊天功能；事實上，當你加入或啟動會議時，就已經自然而然地進入了聊天模式。這種自然過渡的方式就是概念如何巧妙地結合在一起的體現。

因此，我們可以將應用程序視為概念的集合，並將其簡化為最核心的部分。例如，對於 Zoom 來說，基本的概念可能是會議鏈接和影片會議。對於像 Calendly 這樣的日程安排軟件，核心概念可能是自助預約和通知。而對於 iPod 來說，則是歌曲管理、音樂商店以及文件同步的概念。這些概念實際上混合在了我所描述的各種場景中，並且可以容易地分解為三個獨立的場景，進而理解為三個獨立的概念。

當我們設計概念時，我們不僅僅是在考慮場景。例如，對於我提到的聊天概念，設計這種概念首先要明確它的目的，而聊天概念的目的可能是為了在群組中分享簡短的消息。一個概念的目的應該是有說服力、以需求為中心、具體和可評估的。概念的目的很少能用比喻解釋清楚。

接下來，就可以定義場景，或者說定義一個操作原則（operational principle），這一術語源自哲學家米高·波藍尼的思想。操作原則用於展示如何通過操作實現目的，這是理解概念的關鍵。對於聊天概念來說，場景定義可以是：當兩個用戶加入聊天后，如果其中一個用戶發佈消息，另一個用戶就能閱讀它。

但是，我們可以進一步具體化這些規則，因為概念本質上是一個可以通過 API 來定義的服務。比方說，列出一系列動作。這些動作實際上是出現在場景中的行為，可以被視為 API 的組成部分。接著，我們可以思考支持這些動作所需的狀態。

例如，對於聊天概念，狀態可能包括聊天中的消息集合、每條消息的具體內容、消息發佈時間、用戶何時加入聊天等。實際上，當你深入研究概念的細節時，你會經常發現一些原本在場景中並未顯現出來的重要設計問題。在這個例子中，很多聊天概念的工作方式實際上存在一個顯著的設計缺陷，那就是用戶通常只能查看他們在加入聊天之後發佈的消息。

在 Zoom 中，這就是一個不小的困擾，因為它意味著如果有人在會議開始時發佈了一條聊天消息，比如會議議程，那麼任何晚一分鐘加入的人就無法看到這條消息。這對於那些想要獲取會議初始信息的遲到者來說是非常不方便的。

如何運用概念？

我們現在可以問另一個問題：有多少概念能使一個應用程序與眾不同？就像我描述的那些應用程序，有些我認為實際上只有一個關鍵概念。以 Zoom 為例，我認為它的核心就是會議鏈接這個概念。而對於 WhatsApp 來說，它的核心實際上是群聊的概念。

在另一個極端，有些應用程序真正引入了一整套複雜的概念。我認為最能代表這類應用的是你可能稱之為生產力應用（productivity apps）的那些軟件。想想像 Photoshop（Adobe 公司開發的圖像處理軟件）這樣的應用，以及所有遵循 QuarkXPress（一款專業的桌面排版軟件）模式的桌面出版應用，現在還包括像 Adobe InDesign（Adobe 公司的專業排版軟件）這樣的應用。

這些應用有一套非常精細的概念集合，說實話，這些概念相當難以學習。以 Photoshop 為例，它不僅僅是像素數組的概念，還有圖層、蒙版和通道這些關鍵概念。正是這些概念實際上使得 Photoshop 能夠擊敗如此多的競爭對手。

概念的組合為創造性設計提供了機會，即使其中的每個概念都是通用性概念。概念不像程序那樣，可以用較大的包含較小的。相反，每個概念對用戶來說都是平等的，軟件或系統就是一組串聯運行的概念組合。

但有趣的是，還有一些應用程序實際上沒有引入任何新的概念。比如 Gmail（Google的電子郵件服務）。Gmail 基本上只是結合了我們已經知道的兩個通用性概念，即電子郵件和搜索。又或者是 Arc 瀏覽器，它做了一件非常有趣的事情，將瀏覽器中的標籤概念與書籤概念巧妙地結合在一起。

當你心中有這樣的概念時，你可以會從一個不同的角度來思考設計和推理可用性。讓我們以 Zoom 為例。Zoom 有一個表情反應按鈕，如果點擊按鈕，你會看到如下圖 4 這樣的界面。

長久以來，Zoom 用戶界面基本的底層功能是一直不變的。例如，用戶一直可以點擊「鼓掌」按鈕，為演講者喝彩；點擊「對」和「錯」的按鈕，表示讚同或反對；然後還有兩個按鈕，用於示意演講者放慢或加快說話速度；右側的「咖啡杯」按鈕，則可以表示你想喝杯咖啡緩緩；或者是界面下方的「舉手」按鈕，點擊之後可以像現實的會議一樣舉手示意。

有趣的是，點擊這些按鈕的反饋效果卻有所不同。例如，點擊「愛心」按鈕，冒出來的愛心表情會在 10 秒後自動消失 —— 這可能是 Zoom 設計中的一個遺憾之處。奇怪的是，如果我們點擊「舉手」按鈕，出現的表情並不會在 10 秒後消失，而是一直停留在界面上。經常使用 Zoom 的人都知道，人們經常會忘記放下舉起的手，這導致了各種混亂。

此外，頂部的這些按鈕其實是互斥的，這意味著你不能在「鼓掌」的同時發送「愛心」，這似乎不太合理。更奇怪的是，點擊按鈕的反饋效果也是互斥的。這意味著如果你先點擊「讚同」按鈕，再要求演講者放慢或加快速度，最後去「喝一杯咖啡」，後點擊的按鈕往往會取消前一個按鈕的效果。更奇怪的是，有些按鈕會被計數，你點擊之後屏幕上會顯示「xN」，代表點擊了 N 次，而有些按鈕則不會。

因此，Zoom 的界面存在很多不一致的設計。如果我們想解決這些不一致的問題，並思考如何以更系統的方式設計 Zoom，可以嘗試識別其底層概念，並將它們分離成更健壯、更簡單、更引人注目的概念。我可能會將其 Zoom 的底層概念分解為以下四種：

1. 反應概念：這本質上就像發送一個小的情感反應。那些使用 Slack 的人會對此很熟悉。

2. 投票概念：當有人提出一個問題，我們用讚同或反對來回答。

3. 反饋概念：你可以告訴演講者加快或放慢速度。

4. 在線狀態概念：將咖啡杯（表示我離開）按鈕和舉手按鈕整合在一起。

如果讓我重新設計這些功能，可能會這樣做：在屏幕左下角放置一個單選按鈕，讓用戶可以選擇幾種狀態之一。

• 最基礎的狀態，適用於打開馬克風交流的情況：「正在發言」。

• 「正在觀看和聆聽」。當用戶選擇這種狀態之後，可以保持視聽，但會自動靜音終端音頻。

• 「離開」。選擇這個狀態時，讓軟件直接靜音。

• 在用戶點擊「舉手」按鈕時，它將表示用戶正在請求發言，所以需要先將用戶靜音。

• 只要演講者反饋了點擊「舉手」按鈕的用戶，該用戶舉手狀態將消失，並進入「正在發言」狀態。

因此，我相信有可能圍繞一個更連貫的在線狀態概念，對所有這些不同的動作進行很好的重新設計。同樣，我認為反饋按鈕可以被組織成一個單獨的概念，其用戶界面控件甚至可能不需要總是顯示，除非演講者決定他們想接收反饋。這就是使用概念來思考應用程序用戶體驗的想法。

用概念驅動編程

如今，我們甚至可以運用概念設計的思維進行編程。2023 年有一份關於 GitHub Copilot（AI 編程輔助工具）的報告指出，當前大約一半的代碼是由使用 Copilot 的開發者自動生成的。至少在 Python 基準測試上，大模型編碼似乎變得非常出色，在許多簡單函數上達到了約 92% 的準確率。

但關鍵是，這些數字都是針對單個函數的，是一種自動補全形式的代碼生成——即要求大模型推導出一個單一的函數。當你考慮整個應用程序時，情況就大不相同了。GitHub 的首席執行官 Thomas Dohmke 就說過：「開發者的關鍵技能在於，‘我需要細化到什麼程度才能用 AI 自動生成代碼？’」

我認為，是時候重新思考軟件的結構來解決這個問題了。

舉例來說，Hacker News（一個著名的科技新聞聚合網站）和許多應用程序一樣，它完全由熟悉的功能組成：點讚、評論、發帖、板塊還有「聲望值」（karma）系統。

不同的網站或論壇對於這個「聲望值」有不同的叫法和用途，比如在 Reddit 里這就是一個可以通過良好行為積累的積分點數，而在某些資源網站中可以設置「聲望值」的門檻讓資源更難被下載。而 Hacker News 的用戶聲望值只要達到一定水平，就可以對帖子進行點踩（downvote）。

所以重點在於，Hacker News 並沒有創造性的變化，卻帶來了一些創造性的變化。這就是 Margaret Boden 在她的一篇著名論文中所稱的「組合性創造力」（Combinatorial Creativity），即將熟悉的元素以新的方式組合在一起。

對於 Hacker News 來說，它是標準概念的一些變體。例如，一個帖子只能包含標題、ID 作為鏈接，或者一個問題，但不能同時擁有兩者。又如，評論在兩小時後不能被編輯，兩週後就不能對帖子進行評論。這些聰明的小規則確保了網站的時效性和新鮮度。然後是特有的聲望值規則，例如說，用戶需要 501 點聲望值才能踩一條評論，或者 30 點才能標記一個評論。

在我看來，這其實是構建 Web 應用程序的新型框架（如圖 5 所示）。

圖 5  構建 Web 應用程序的新型框架

每個概念都將是一個小型後端堆棧，包含了概念的行為。這些都是構成應用場景的用戶操作的程序。然後是一個數據庫來支持概念的狀態。

關鍵點是，所有這些概念之間沒有依賴關係，因為概念是完全獨立的，並且以獨立的方式定義。這真的是概念中的大想法。概念之間的連接只發生在路由中，H湯臣P 端點通過我稱之為行為同步的方式連接到概念。這恰好對應於我展示的不同概念的應用場景之間的這些鏈接。

有了這個想法之後，實際上還可以用它生成代碼（如圖 6 所示）。

關鍵在於，我們將採用提示詞（Prompt），為每個概念生成代碼，完全獨立於其他每個概念。這意味著我們不必擔心隨著應用程序變大而增長的上下文。但每個概念都可以獨立實現。然後要做的是，為路由編寫一個提示，將再次獨立地為每個路由生成路由代碼。

當然，正如我先前提到的，路由需要做的是調用概念的行為。所以還需要使用大模型從生成的代碼中提取每個概念的 API。然後路由將使用這些概念 API 來合成路由代碼 —— 最後，記得對前端也故技重施一遍，把它包裝起來，進行部署。

代碼生成將成為可以交給機器完成的工作

總結來說，我第一個想法是創新簡化應用場景。例如，在群聊的概念中，場景的簡化體現在發送消息的人不必添加所有收件人。如果我們回顧軟件領域的所有創新，你會發現幾乎所有的創新都涉及這種應用場景的簡化。

其次，雖然我們經常從用戶界面的角度思考，但軟件設計實際上是從功能開始的，而概念幫助我們構建它。比如說 Zoom，我認為會議鏈接的概念對 Zoom 的本質和成功真的至關重要。

再比如說網絡，我認為 URL 的概念可能比任何其他概念更能解釋它的成功。我相信 Tim Berners-Lee（萬維網的發明者）也認為 URL 比其他任何概念都重要。

最後，我想強調三個要點：

• 第一，模塊化是關鍵，正是因為概念是完全獨立的，我才能夠獨立地討論這些概念。正是因為它們是獨立的，我們才能理解應用程序，

• 第二，提取出熟悉的概念。許多概念是通用的，在我們進行的代碼生成中，根路由和同步是需要定製的部分。當你進行概念設計時，一個重大創新是它允許你將熟悉的部分與真正新穎的地方分開。

• 第三，告別敏捷開發。多年來，很多人一直相信代碼就是王道，規範其實並不重要，前期的大規模設計是個壞主意。但我認為，既然大模型真的很擅長生成代碼，那人類的工作將更多地集中在編寫提示、進行設計和塑造概念等方面。代碼生成將成為可以交給機器完成的工作。

大模型刷新一切，讓我們有著諸多的迷茫，AI 這股熱潮究竟會推著我們走向何方？面對時不時一夜變天，焦慮感油然而生，開發者怎麼能夠更快、更系統地擁抱大模型？《新程序員 007》以「大模型時代，開發者的成長指南」為核心，希望撥開層層迷霧，讓開發者定下心地看到及擁抱未來。

讀過本書的開發者這樣感慨道：「讓我驚喜的是，中國還有這種高質量、貼近開發者的雜誌，我感到非常激動。最吸引我的是裡面有很多人對 AI 的看法和經驗和一些採訪的內容，這些內容既真實又有價值。」