AIGC 生成代碼正流行，對程式設計師是好還是壞？

body = f"不規範的代碼文件：{file_path}"msg.attach(MIMEText(body, 'plain'))

try:smtp_server = smtplib.SMTP(SMTP_SERVER, SMTP_PORT)smtp_server.starttls()smtp_server.login(SMTP_USERNAME, SMTP_PASSWORD)smtp_server.sendmail(SENDER_EMAIL, [recipient, cc], msg.as_string())smtp_server.quit()print("郵件通知已發送")exceptException ase:print(f"發送郵件時發生錯誤：{str(e)}")

# 主函數defmain():repo_path = '/path/to/your/git/repository'

forroot, dirs, files inos.walk(repo_path):forfile infiles:file_path = os.path.join(root, file)

# 檢查資料庫密碼ifcheck_database_password(file_path):send_email(file_path, RECIPIENT_EMAIL, CC_EMAIL)

# 使用 PyLint 檢查代碼是否符合規範pylint_output = check_code_conformance(file_path)if"Your code has been rated at"notinpylint_output:send_email(file_path, RECIPIENT_EMAIL, CC_EMAIL)

if__name__ == '__main__':main()

鄧明軒：這個問題實際上是對大型語言模型的 Prompt 描述，我認為這也是當前程式設計師需要學習的一項技能，你必須學會如何與大型語言模型進行交互，你可以告訴它代碼塊是什麼樣的，請它簡化或轉化為一個類或打包到一個類中完成任務。因此，Prompt 是一項非常重要的技能，我提醒大家要去學習，並在實際工作中不斷提升，這將決定了後續使用這種基於大型語言模型生成代碼工具的效率。Prompt 寫得越好，效率就會越高。

關於 Prompt，吳老師使用的是中文，我個人認為，在當前的環境中，如果你的英文水平能夠達到一定程度，最好開始使用一些英文的 Prompt。我們必須面對這個現實，即大型語言模型目前無論是國內還是國外訓練的，它從各種資源中獲取的數據更多是英文的，因此大型語言模型對於理解英文的偏好和能力要強得多。當然，我們希望中文的表現越來越好，但這之前，我們應儘量適應這種工具的發展。

可能有人問：有了大語言模型，我們是否還需要學習英語？根據我的個人使用體驗，雖然目前大型語言模型在翻譯等方面的表現已經相當出色，但用英語直接與它進行交互會有獲取更多信息的能力。因此，從短期來看，我仍然認為學習英語會有所助益，儘管對許多程式設計師來說英語一直是個難題。

就生成的這段代碼而言，總體結構非常完整，代碼看起來幾乎可以運行，但一些配置項可能需要進一步編寫。此外，它提到了 SMTP。在很多年前分析 SMTP 協議時，我們需要了解各種配置和埠等信息，如果現在要我突然寫這樣的代碼，可能要花很長的時間去檢查各種細節，不過有了這些工具就可以幫助生成相關代碼。

我之前與少傑討論過這個話題：如果你的基礎紮實，能力為 2，那這個工具就是一個倍增器，可以增加 40 倍，變成 80；但如果你的能力只有 1，那麼它只會增加 40。** 你的基礎能力在使用這個工具時會被放大。** 因此，我建議大家深入了解程式語言的本質以及底層技術等知識，你可能無需記住具體的欄位或 main 結構，因為現在大型語言模型可以幫助生成。

彭靖田：這個問題，我從兩個角度來考慮。首先，大型模型有能力生成代碼，但最終這段代碼要能運行才會成為有價值的交付物。因此，我們通常會將生成的代碼與開發人員編寫的代碼進行比較，包括代碼是否適合進入生產環境。這其中的一個重要方面是 Prompt 的應用，比如當我們討論一段代碼是否適合在生產環境中使用時，九要考慮我們的 Prompt 是否會檢查密碼以明文形式存儲。

現在，我們只進行了一輪的對話和詢問，目前的輸出結果已經足夠好，開發人員能提供這樣的代碼也相當不錯了。但這段代碼要投入生產環境，通常第一反應可能是是否需要一個配置管理器或將配置保存為 YAML 文件？例如在埠號和配置項中出現的用戶名和密碼，生成的代碼將密碼作為明文字符串放置在代碼文件中，這不是一個很好的做法。這個問題也在於在初始需求中沒有給大語言模型足夠詳細的信息，但通過進行多輪對話，大型模型可以更好地解決。

關於一個優秀的大型模型或使用大型模型生成良好代碼的最佳實踐，我認為有兩個關鍵點需要注意。第一是描述清楚需求細節，甚至可以將自己視為一名架構師，將大模型想像為擁有不同背景（例如前端、後端腳本等）的員工，作為架構師的你應該如何提出需求？第二是要多輪問詢、逐步完善。我做過一個小實驗，使用 GPT-4 完整地生成了一個開源項目，目標是進行完整的雙語電子書翻譯。這個項目的整體代碼庫可能有幾千行，完全是由 GPT-4 生成的，但是經過了許多輪的對話。

站在架構師的角度，最初的問題可能不是具體的 100 行代碼程序，而是讓大模型理解你如何設計這段代碼，例如需要分成哪幾個模塊、資料庫密碼檢查是否只需要一個簡單的函數就夠了等，所有這些都可以通過架構設計來完成。總之，多輪對話、逐步完善並將自己視為架構師，用這種自上而下的設計讓中間節點和葉子節點的代碼變得更加友好。

鄧明軒：我完全同意彭老師提到的觀點。作為開發者，我們應該將自己視為架構師來思考這個問題。對於這些編程工具、AI 工具，我們可以稱之為 Copilot，輔助駕駛而非主駕駛。因此，我們真正使用的時候，不能期望只描述一個需求就可以迅速完成一個完整的軟體。相反，它為我們提供了代碼塊，我們有責任將這些組織起來，包括項目的工程時間規劃、項目管理等，只有通過自己的思考，我們才能更好地利用這個「副駕駛」。我們不能把方向盤交給它，讓它代替我們駕駛，這是不合適的做法。

另外，彭老師提到我們的任務是檢查安全性，而在生成的代碼中又涉及密碼等敏感信息，這引發了一個問題：當前的語言模型是基於 Transformer 架構的，而且大多數情況下是盲目生成的，它缺乏自省能力，如果直接向它提問，它會按照神經網絡的方式逐字生成結果。因此，我們需要進行多輪對話。也就是說，當我向它提問並生成了一段文本後，我可以將這段文本反饋給它，詢問是否符合要求或者提出其他的要求。這些都是與大型語言模型進行互動的良好實踐。

Michael Yuan：我很大程度上同意兩位老師的觀點，這裡只提出一點：當運行一個 Python 腳本時，很可能是在本地環境下進行分析，在這種情況下，使用明文密碼可能並不是一個問題。

那麼，這就涉及到 Prompt 工程師在做什麼的問題。Prompt 工程師是否會最終消失？我覺得不太可能，因為 Prompt 工程師是在應對需求並解決需求，就和人與人之間的對話一樣，需要經過多輪交流。

現在，我們公司里大約一半的開發者都在使用 Copilot，每個人每月支付大約 10 美元，因為有一些程式設計師非常依賴 Copilot。他們之前是這樣使用 Copilot 的：描述一個算法，然後讓它生成相應的代碼，而並不是像今天這個案例一樣，已經將業務需求分割好後再描述一個具體場景。比如我需要對一個向量進行排序，這都是已知的算法，但我懶得找，所以讓 Copilot 來幫忙，我寫一個簡短的提示，然後讓它生成代碼。這就是 Copilot 和 GPT-3 時代生成代碼的方法。

今天，我們生成代碼需要進行多輪對話。ChatGPT 令人驚訝的地方在於能夠跟隨對話，我們可以繼續提問，可以在對話中指代之前提到的內容，而它也能理解我在指代什麼。當我提供描述並生成代碼後，可以運行該代碼並將結果反饋給它，告訴它哪裡出錯了，然後它可以繼續生成下一輪代碼，通過多次疊代，生成的代碼會越來越符合預期。

我認識一個 CTO，他有大約 10 年沒有寫過代碼了，最近他想要創建一個 Discord 機器人，但對於如何使用 Python 處理他並不熟悉。於是，他向 ChatGPT 描述了想要實現的功能，然後 ChatGPT 生成了一段代碼。初次生成的代碼並不能正常工作，他就將錯誤信息反饋給了模型，然後重新生成了一段代碼。經過幾輪的交互，他花了大約半天的時間在一個不熟悉的領域中生成了大致能夠運行的代碼。我覺得這展示了 ChatGPT 的能力，儘管並不能完全理解需求，但通過不斷交互就能夠逐漸實現想要的結果。

這並不是說只需簡單的描述，大語言模型就能完全理解。實際上很多時候，我們自己都並不清楚究竟想要什麼，我們可能需要先看到一些代碼，然後逐漸明確自己的需求。這個過程可能需要花費相當長的時間。儘管如此，我仍然覺得這是一項令人印象深刻的技術。

這也給編程工具的用戶介面帶來了很大的挑戰。Copilot 的使用非常簡單，你只需在其中編寫注釋，然後讓它將注釋轉化為相應的代碼。這是一次性的代碼生成過程，然而要實現更複雜的功能，就需要一個能夠支持對話的用戶介面了。

生成代碼的質量與安全問題

吳少傑：AI 生成代碼的質量高低與哪些因素有關？如何消除 AI 生成代存在的安全隱患？

鄧明軒：這裡涉及兩個問題：質量和安全性。質量與我們對 Prompt 工程的學習和掌握有關。而安全性則有兩個方面需要考慮：首先是工具本身提供的安全輔助功能，另一方面是作為代碼使用者，我們如何考慮安全問題。

我想提一下亞馬遜雲科技推出的 Code Whisperer 工具，它實際上對代碼的安全性進行了檢查和提示。當然，儘管可以使用工具來輔助我們更好、更快速地發現安全問題，但我們仍然需要對項目的代碼負責。例如，我們需要考慮是否可能泄露敏感信息或者代碼是否可能被錯誤使用，尤其是在涉及對外服務的方面，我們還需要考慮這些服務是否會對其他系統造成重大損害。

大型語言模型的多輪對話會受限於容量，可能只有幾十 KB，因此檔面對複雜的項目，或者一個由 10 人或 20 人組成的團隊時，其容量可能遠遠不夠。此外，還有整個軟體環境，包括軟體設計和需求描述等方方面面的考慮。因此，作為程式設計師，我們需要對這個領域有全面了解，從頭到尾清楚了解相關結構。在這種情況下，我們會將其中的細微問題拆分出來，與大型語言模型進行交互，一定程度上避免由於容量限制而無法處理複雜的邏輯跟蹤。當然，這也涉及到安全性的問題。

回到質量問題，我認為質量同樣是程式設計師的責任。在這方面，工具也對我們提出了一些要求，如果你的代碼質量較高，那它將更容易理解，生成代碼的可用性也會更高。最終代碼質量的責任仍然在於代碼的擁有者，也就是我們自己，我們需要真正對此負責。

Michael Yuan：對於代碼質量，有一些簡單的方法可以採用，例如將代碼與編譯器進行連結，使生成的代碼立即進行自動編譯，並通過編譯器提供的錯誤信息進行修復。此外，還可以與資料庫等工具結合使用，自動掃描檢測常見的問題。所以，代碼質量並不是一個無法解決的科學問題，而是一個工程問題，我們可以通過各種工具的結合來不斷接近最優解。

不過，目前對代碼質量的控制問題可能會有一些爭議。目前，從個人角度來評判代碼質量的一個重要標準是可擴展性，也就是代碼編寫後是否容易修改。然而，現在有一些流派認為，未來尤其是對於前端框架而言，這種代碼質量可能並不重要。

可以設想一個未來的場景，整個應用程式都是由大型模型生成的，不存在需要人為修改的問題，如果需求發生變化，只需重新生成代碼即可。某些場景下，每次生成的代碼都只使用一次，不存在擴展代碼的問題。當然，現在可能還無法實現這一點，但這是一個可能出現的未來，如果成為現實，那麼會對代碼質量的評價產生重大影響。因此，我認為在架構上編寫可擴展且優雅的代碼並不重要，至少在某些場景中不重要。

我們再談談第二點，即安全問題。我認為，人類編寫的代碼在某種程度上也是相對安全的，否則就不會存在那麼多問題，也不會有像 Rust 這樣的語言出現。對於安全問題的解決，人們在編寫代碼時已經用了很多工具，例如 Rust 通過編譯器解決內存安全問題、Java 通過運行時方法解決內存安全問題等。

多輪對話的有趣之處在於，生成的代碼可以通過工具運行，然後將工具的結果反饋給模型，然後模型做進一步優化，這個過程可能比人類做得更好。

彭靖田：我最後補充一個我個人非常認同的觀點，即關於「我們今天應該如何解決 AI 生成代碼的安全隱患？」這個問題沒有太多可討論的，因為這與 AIGC 無關，代碼就是代碼，無論是誰生成的都存在安全隱患，所以我不想討論這個問題。

我更關注生成代碼的質量高低，也就是 AI 生成代碼的問題。目前，有兩種對此完全不同的觀點。有一類觀點認為，每個人都應該開發自己的大模型，因此出現了很多專注於大模型的創業公司。然而訓練語料庫是有限的，在 OpenAI 和其他國外大廠已經做了很多投入的情況下，是否值得從零開始開發一個大模型還需要探討。我們需要知道的是，一些大模型並沒有特別針對編寫代碼這一任務進行增強，特別是當我們要在生產環境中將其作為生產力工具替代選擇時。

我們招聘一個研發工程師時為什麼要寫招聘要求？為什麼要對研發工程師進行分類？因為他們花了很多時間進行自我訓練，他們的訓練來自各種類型的教程、框架手冊、項目實踐等。如果你的公司有自己的代碼庫，可能沒有開源，或者你正在進行一個特定領域的項目，有許多開源框架和基礎項目代碼，那麼是否應該進行 fine-tuning（微調）？是否可以提升模型的權重，使通過 fine-tuning 得到的模型能夠更好地解決代碼生成問題，而不是從零開始開發一個模型？我認為這可能是一個可以考慮的方向。

關於 AI 輔助編程工具的使用建議

吳少傑：三位老師平時會 AI 輔助編程工具來做些什麼？是否可以提供一些使用建議？

Michael Yuan：我們團隊主要使用 Copilot 來生成代碼，因為它與 GitHub 的 IDE 結合非常緊密，我認為這一點非常重要。如果你要在其他地方使用它，你就需要打開另一個用戶介面（UI），這將增加工作量。然而，剛才提到的多輪對話生成應用並且使用人工工具進行檢查，這是一個很好的方向。比如，我可以將它集成到問題跟蹤（Issues）或討論（Discussion）中。

關於代碼質量本身，有很多工具可供選擇。今天代碼中的許多問題都源自所謂的供應鏈問題，這意味著你依賴於其他人的代碼，如果其他人的代碼出了問題，你的代碼就會受到影響。另外，複製、粘貼的代碼可能會在大型模型中帶來更多問題。這段代碼可能不是在 NPM 或 Cargo 的包管理器中引入的，而是來自 Apache 或其他許可證的，如果出了問題或者上游進行了修復，開發者可能並不知道，這種情況下就需要更深層次的代碼檢查器。

在 AIGC 中，這種代碼檢查器也特別有用，其實就是用同一個工具解決可以兩個問題：一個是解決代碼來源和許可證不兼容的問題；另一個是，如果上游代碼出了問題，有工具可以跟蹤並通知開發者，然後對下游代碼進行相應的更改。

當然在編寫代碼後的測試是必不可少的。我們在用的 Rust 有很多工具選擇，如快速測試（fast testing）。實際上，快速測試也是一種機器學習方法，它不斷測試輸入和輸出邊界，然後看代碼是否出錯。在這方面，我認為大型開源項目會提供這種專門的服務。我們的項目為什麼加入 CNCF，主要是因為 CNCF 與 Google 合作提供了這樣的服務。但這需要大量的機器時間不斷地進行編譯和測試。

另外，每個項目的情況可能都不一樣。我們使用的是 Rust，因此我們有一套特定類型的工具。而對於使用 Python 的項目，可能要用其他不同的工具，因為它沒有內存安全的問題，但有其他要解決的問題。

彭靖田：我覺得目前最好用的工具還是 AI 輔助編程工具本身。大部分工作仍然是基於大模型進行的，開發框架的遷移還不夠成熟。

我認為從安全的角度考慮是非常重要的。比如，對於我們要與 Autodesk 工業設計軟體（如 AuthCD 和 Rivet）競爭開發的 SaaS 產品，如果接入 AI 生成的代碼，需要如何處理呢？實際上，傳統的軟體工程方法仍然非常有用。軟體工程告訴我們需要進行環境劃分、編寫良好的測試用例、採用不同的測試方法，並在各個環境中有測試人員關注一些邊界情況和使用場景。

舉個例子，我們有個環節是將用戶上傳的 CAD 圖紙通過計算機視覺和深度學習算法轉換為三維模型。但建築設計師繪製的 CAD 圖紙也存在很多問題，他們沒有編譯器，也沒有測試環境，只能依靠施工現場的人逐個解決。這其中有兩類測試問題：一種是代碼確實存在問題，這類問題可以通過軟體工程的方法解決；還有一類問題更偏向於算法和領域場景，即輸入數據本身就不夠健壯和穩定，這種設計上的問題需要進行降級處理，捕捉異常。

鄧明軒：現在的大語言模型在架構上有多種路線，但是現在有一種觀點認為，模型的架構本身並不重要，只要我們有充足的連接，即非線性的連接，並提供足夠多的數據給模型進行訓練，它就能夠產生很好的效果。因為這些模型內嵌了大量人類知識，儘管不是全部但可以通過使用足夠大的模型將文本輸入其中，進而實現預期的效果。因此我個人認為，底層的算法結構可能並不會對上層的應用產生太大影響。

關於代碼質量檢查工具的使用，我同意兩位老師提到的觀點，即最好的評估方法就是運行它。現在普遍使用的是解釋型語言和編譯型語言。在這種情況下，解釋型語言具有一定的優勢，因為可以直接將生成的代碼輸入語言環境中進行解釋和運行，捕捉可能的錯誤，然後返回給大語言模型。對於編譯型語言如 Rust，需要設置額外的運行時環境來進行編譯和運行。總之，對於代碼質量來說，「無論是白貓還是黑貓」，只要能夠滿足需求就是好的。

此外，現在許多與大語言模型相關的接口使用的都是 Python，在神經網絡和機器學習領域，Python 是主流語言之一，具有動態解析和良好的語言支持。我認為，未來可能會進一步推動 Python 的發展，比如在大語言模型中生成一段代碼後，直接在 Python 的運行環境中進行評估和調試，然後返回結果給大語言模型。

現在有許多與語言相關的 LangChain 或其他外圍框架，這可能是未來的發展方向之一。通過額外的框架配合，可以在語言的運行環境中進行多輪對話，自動檢查代碼質量，無需人工干預，我們只需要描述要完成的任務，然後讓系統開始運行即可。如果出現錯誤，系統會自動進行修改，並再次運行。

關於代碼安全性，實際上在我了解 CodeWhisper 時，也思考過版權問題。我們使用大語言模型生成的代碼，但對於它的版權關係並不確定，比如它使用了什麼開源許可證，如果你的代碼在結構上與某個開源許可證中的代碼完全一致，那根據過去的案例，你可能會被訴訟。這對於使用這些工具的程式設計師來說是一個挑戰。

零基礎如何使用 AIGC 工具

吳少傑：這裡有個觀眾問題道，「零基礎學員如何使用好這些工具，需要提升哪些點？比如大模型給出幾段代碼，但是我卻不懂，很好的調試可以達到執行。」

鄧明軒：如果是零基礎，那麼了解一些編程概念是有必要的。如果有一些基礎，只是不夠深的話，那與大語言模型進行互動是一個不錯的方法。

可以從簡單的例子開始，比如我們之前寫代碼時常用的「Hello World」。現在你可以要求模型給你一個 Rust 版本的「Hello World」，雖然可能一開始看不懂，但可以直接運行這段代碼，如果出現錯誤了就把錯誤信息反饋給模型，詢問出了什麼問題，這樣的交互循環可以讓你快速學習新技術。另外，還可以選擇一段代碼並要求模型解釋它是做什麼的。然後進一步問，比如要在其中添加一個循環或者一個條件分支該如何實現？總之，你可以慢慢學習，逐漸形成對編程的基本理解，關注在代碼的運行邏輯上，而不是語法結構。

每種語言都不同，你並不需要詳細研究每種語言的具體細節，只需要理解基本的概念，例如循環、分支，包括遞歸以及更複雜的數據結構等。關鍵時通過交互的方式逐步構建這些概念。我認為，有了這些工具之後，學習編程會更快速，而不是有些人擔心的那樣「程式設計師會失業，不需要學習了」，這實際上降低了編程和與計算機對話的門檻。

Michael Yuan：「有了更好的工具後，程式設計師就要失業了。」這種話我聽了二十多年了。我還記得過去有種說法，「大家都不要學計算機了，因為都要印度人去做了，你們沒有機會了。」但事實證明並非如此。我對大語言模型的理解是，它是程式設計師的工具，程式設計師會用它來輔助其他人工作，這就是我不同意 OpenAI 那篇報告的原因。

OpenAI 的報告聲稱洗碗和刷房子不會失業，但實際上洗碗也會失業，因為程式設計師會有更多的時間開發出洗碗機器人，取代所有洗碗的人，所以程式設計師也是可以捲走其他人工作的。大模型可以大幅提高程式設計師的能力，有了大模型後可以很快地學習和理解。

回到之前的問題，之前計算機科學的書籍和教育對我們有很大的影響，我自己也寫過幾本書，寫書的時候通常會從背景開始、介紹概念開始。有些語言容易有些就難，有些語言概念非常多，比如 Rust 概念很多，學習起來比較困難。但使用大模型後，它可以解釋很多東西，還可以完全根據你的學習需求進行定製。

為什麼很多人的編程學得不好？因為編程不是一種立竿見影的事情，你需要從一些沒有意義的事情開始做起，比如寫一個「Hello World」能有什麼用？它解決不了實際問題。但就像我之前提到的，有了大模型後，我朋友花了半天時間寫了一個 Discord 機器人，你也可以輕鬆地寫出類似的東西。你可能並不完全理解為什麼這樣寫，但你可以逐步改進，通過自己的努力學習快速掌握它的用法。

鄧明軒：我當年學習程式語言的時候，買了一本書，還要去機房上課，然後我們敲了一些代碼卻出現了錯誤，我們不知道什麼意思，老師也不懂，甚至書上也沒有解釋。我們只能自己摸索和嘗試。在那個年代，學習計算機編程是非常困難的。我不知道提問的觀眾是多大年紀，可能年齡較小。你們非常幸運，生活在這個時代，有機會接觸到不斷發展和提升的技術。我鼓勵你們充分利用這項技術，因為未來可能會有各種驚人的可能性出現。

彭靖田：之前，我將評估一個優秀開發者技能的維度分為四個部分：首先，編程和調試技能，也就是實際操作的能力，占比 40%；其次，項目管理和協作能力，占據 30% 的權重，這意味著作為一個獨立的開發者，你能夠交付代碼，並且能夠與團隊、需求方、測試方以及其他開發團隊成員進行協作；接下來，算法和數據結構，占據 20% 的權重。計算機科學專業的人可能對數據結構和算法會有更深入的理解；最後的 10% 留給軟體工程經驗，也就是在實踐中積累的最佳實踐經驗以及對優秀軟體工程師的觀察和學習。

但是現在，我有了不同的看法。關於那 40% 的技能，我會進一步抽象為大模型的應用實戰能力。這意味著你有更多的最佳實踐，而不是僅僅學習某種程式語言，浪費大量時間和精力去學習每一個知識點。正如這位提問者提到，前後學了 QBasic、Basic、Java、C++、Python、Go 和 Java 的派生版本等多種程式語言，這些語言都介紹了基本的數據類型，這可能會帶來一些困擾和混亂。但實際上，數據類型並不是很重要。

一個沒有學習過程式語言的人應該如何做？以前我們會從基礎語法開始學起，但現在語法並不那麼重要了，重要的是對程式語言的理解。比如理解編譯型語言和解釋型語言的區別，為什麼自 Python 3 以來一直在強調類型標註？為什麼一個本來應該非常靈活的語言現在越來越強調類型，並且推出了許多相關庫？事實上，這就是所謂的 Prompt 實際上變成了與英語一樣重要的語言技能。

還有 20% 我留給了人機和團隊協作。現在我們可以與人工智慧和大型模型進行協作，它們不會抱怨、不會說我們蠢，也不會在背後說壞話。如果你無法與這樣的一個合作夥伴進行有效協作，那肯定是你自己的問題。

這些工具還有哪些問題

吳少傑：現在的輔助編程工具還存在哪些問題？提供廠商需要做哪些改進才能更好滿足程式設計師的需要？

鄧明軒：目前工具的交互模式和發展都處於不斷演進的過程中，還有很多空間可以探索。近一年來，我們經歷了一個技術爆炸，整個行業也在思考這些工具應該具備怎樣的形態。因此，過多地關注當前工具的局限性可能並不是非常有益。也許三五年後回頭來看，我們會發現現在的情況非常有意思。

不同的廠商推出了自己的工具，但他們並不是要將這些工具作為盈利手段，而是通過這些新的交互模式將用戶引入到某個平台上。對於如何將這種能力更多地擴展到用戶手中，大家應該有相對一致的想法。我個人的體驗是，我真的很希望有一個像《鋼鐵俠》中的賈維斯那樣的助手，我可以用自然語言與他進行溝通，他能理解並幫助我完成許多任務。這種輔助性工具確實是我非常期待的東西。

Michael Yuan：我覺得投資人可能更加焦慮，因為他們可能會發現某個工具很好，但過幾天就被 OpenAI 或其他公司幹掉了，甚至有些簡單的工具已經被別人複製了。目前工具方面有很多創新。例如 OpenAI 最近發布的 Function Core 可以直接從大模型生成數據結構，然後與核心函數結合。

工具創新的領域很多，甚至比底層大模型的創新和疊代速度都要快。為什麼會這樣呢？因為底層大模型需要耗費大量資金和時間進行訓練，而現在正是一個百花齊放的時代，有大量不同的想法和方向。對我們來說，一個特別有用的工具是如何讓多輪對話生成代碼的介面更加友好，能夠吸引更多人參與。以前的研發管理工具中並沒有考慮到這一點。

吳少傑：三位老師觀察，周圍使用 AI 工具來生成代碼的人多還是不用的比較多？各自團隊的研發效率大概能提多少？20% 還是 30%？

Michael Yuan：實際上我們有自己的數據，但我認為還不足以進行直接比較。Twitter 上有很多比較。實際上，一些經驗豐富的人更不願意使用 AIGC，因為他們認為自己可以寫得比 AIGC 更好。而那些比較初級的或者經驗較少的程式設計師願意使用 AIGC，他們代碼編寫速度和完成度要比那些資深程式設計師高得多，這不是兩倍的差距，而是幾十倍的差距。當然，也可以說經驗豐富的開發者寫出來的代碼更容易擴展。但是如果有了幾十倍的差距，那麼下次直接重寫就好了。

鄧明軒：我觀察到，小型初創公司在技術選型上會更快一些，因為他們可能更加靈活。對於一些大型企業，特別是傳統企業，開發部門可能比較龐大、流程也比較複雜，目前找到合適的方法將這些納入到整個軟體工程流程中仍是一個問題，所以我認為還需要觀察。

如果你的定位是寫一些膠水代碼或者試驗性代碼，那可以快速適應。另外，如果你所在的公司比較靈活，我建議大家去嘗試。如果你有一個由 5 個或 10 個人組成的團隊，並且你們的效率是巨大公司的 30～40 倍，那麼你就可以與這些大型公司競爭了。

當然，對於傳統的大型軟體開發公司或大型 IT 部門來說，短期內將這些融入到開發流程中具有挑戰性，大家可能還沒有完全明白該怎麼做。我們可以稍微放慢一些節奏，在比如半年或一年後，再來看看如何將這些納入整個團隊中。

彭靖田：這是一個趨勢性的事情。拿我們團隊來說，我們目前沒有專門的運維人員，只有一個後端同事兼任運維工作，如果是一個大公司就會需要一個團隊。他需要管理華為、亞馬遜雲科技以及位元組的雲平台，每個雲平台都有自己的 Kubernets 集群，這意味著他需要管理 7～8 個集群。一個雲平台上可能會有多個環境，而且不同環境之間的命名空間和優先級可能也不同。七八年前剛接觸 Kubernets 時，我就覺得這是一項非常複雜的工作，包括今天的 Kubernets 生態社區中，很多人就在做調度策略、HPA 等各種工作。

但實際上，大多數團隊只使用了容器雲的一些基礎功能，特別是在運維方面，大部分工作都可以自動化。比如 GitLab 現在強調 DevSecOps。整個 CI/CD 流程實際上由許多腳本組成，以前這些腳本被認為是運維專家的特殊技能，但實際上並沒有那麼神秘，也沒有那麼多技巧，大模型可以解決這些問題。

我們那位後端同事使用了很多自動化技術，但還沒有將 GPT-4 作為日常工具，最近兩個月里他一直沒有解決一個偶發性問題。我們一直使用較大的節點，最小的節點大約都有 32 個核心和近 200GB 內存的資源池。在這樣的一個節點上，我們通常部署 200-400 個應用程式，而這些應用程式的請求資源可能只占用 0.5 個 CPU 核心和 2GB 內存，但這時候，他們的請求已經接近我們的資源上限。但它是一個流水線，不斷地在消耗資源，以至於有的應用程式剛啟動，另一批應用程式可能已經關閉了。

這裡的問題在於，多雲環境中的底層硬碟共享有一個閾值限制。當應用程式特別多時，這個默認閾值可能會被打破，導致應用程式無法啟動。他發現應用程式無法啟動，但 CPU、內存資源都足夠。因為多雲在虛擬化存儲時，借用了一部分硬碟來進行虛擬化存儲，但實際上用不滿。他無法解決這個問題，我獲得權限後把那個節點上的日誌原封不動地交給 GPT-4，它告訴我只需重啟一個命令，將閾值改為合適的值就可以了。起初，後端同事還不相信，他去 Stack Overflow 上查找，但結果各不相同。最後他按照指示執行了命令，問題解決了。

對我們這個同事來說，這個問題只是一種認知上的偏差，但提升的效率是非常顯著的。對於那些 1～3 年裡都在寫 SQL 和編寫 CRUD 業務邏輯的開發工程師來說，未來的代碼效率也會大大提升。

AIGC 對程式設計師的影響

吳少傑：當大規模使用 AI 輔助編程工具時，企業對程式設計師的要求會發生哪些變化？

鄧明軒：我認為，現在網際網路降本增效和技術變革可能不處在同一個趨勢上。技術變革主要受疫情和國際經濟關係等因素的影響，個體很難改變，我們只能在這種情況下盡力發揮自己的價值，比如在降本增效的壓力下如何展現自己的能力。

作為個體，我們應該如何適應這個新環境？首先，我們需要在心態上保持開放，接受這種新事物，迅速了解並進行實踐。正如剛才提到的，實際上事情變得更容易了，而不是更難了。

另外，要學會學習的方法，這非常重要。未來，具體程式語言的語法結構等可能並不那麼重要，重要的是如何具備良好的學習能力、快速適應新環境。我認為這是一項非常重要的技能，這次的技術變革就給我們提出了新的挑戰。希望大家保持積極樂觀，因為工具也帶來了很多機會。

Michael Yuan：程式設計師有一個優良傳統，就是喜歡親自動手去做，而不是空談。在技術領域，那些只會談論卻無實際行動的人會讓人感到厭煩。大型模型特別好的一點就是，它們可以讓人立即動手嘗試，我其實很喜歡這一點。

彭老師也講他的整個項目都是通過 AIGC 完成的，包括項目的推廣和市場營銷都是由模型生成的。這個過程中有很多工具可以用，一旦嘗試了這些，你就會知道這個東西的大致邊界在哪裡，因此也會有正確的預期。最難的一步可能是邁出第一步。

彭靖田：企業對程式設計師的要求會有哪些變化？實際上，我認為這個問題並不是從甲方的角度提出的，因為甲方對程式設計師的要求一直都是一樣的：快速、高質量、低成本，就是要多快好省。從這個角度看，無論是程式設計師、開發人員還是內容生產者，作為提供服務的人，我們需要解決的問題就是如何更快、更好地完成工作。

我們和動物的區別在於我們懂得利用工具，而且我們的工具變得越來越巧妙、易用，我們也越來越擅長改造工具，使其更適合人類的需求。從這個視角來看，我們每個人都應該迅速擁抱這些新工具。想像一下，如果你的老闆讓你打車，你會站在路上等計程車嗎？不會吧，你會使用滴滴、高德地圖、美團打車，這個邏輯很簡單明了。

嘉賓們的自我介紹：

吳少傑（特邀主持）：

我之前在 58 集團、新浪微博負責過推薦算法相關的工作，現在在垂直行業做智能算法，給業務賦能。

鄧明軒：

我已經從事編程工作 23 年了。我 2000 年畢業，陸續加入了 IBM 和蘋果等公司。目前我在亞馬遜擔任首席架構師。個人而言，我對編程非常感興趣。事實上，從我畢業至今的 20 多年間，我一直都在編寫代碼。儘管最近一兩年由於工作中的事務性任務增多，我編寫代碼的機會相對較少，但我仍然對此感興趣並願意自己去寫代碼。在當前通用人工智慧大語言模型的發展中，我注意到它對整個編程技術產生了巨大影響。我很高興能夠在有生之年經歷這一切。

彭靖田：

我從中學開始接觸編程，有大約 15 年左右的編程經驗了，至今我一直在程式語言和算法一線。2015 年，我在大三時開始接觸創業，跟著浙大學長拿到了真格徐小平老師的天使輪融資，做了一個輔助診療的 APP，是基於 NLP 和深度學習的 AI 系統。從加州大學訪學結束後，我加入了華為 2012 實驗室，從零到一參與了華為深度學習平台 ModelArts 的設計和研發工作。之後我作為技術合伙人加入了才雲科技（2020 年被位元組跳動收購後，整合為了位元組火山雲）。現在這家公司——品覽是我的第三段創業經歷，我是公司的聯合創始人和 CTO。我們致力於用 AIGC 賦能建築設計，彎道超車 AutoDesk 的產品。

除了創業外，我也非常喜歡開源。從上一輪深度學習的火熱時期開始，我在很早期參與了 Tensorflow 項目的開源貢獻，2017 年與華為兩位同事一起合作出版了國內首本深度剖析 TensorFlow 框架的熱銷書《深入理解 TensorFlow》。在才雲時期，我們與谷歌雲團隊共同發起了了一個 Kubeflow 的開源項目，它現在已經成為 MLOps 領域的事實標準之一。現在我積極擁抱大模型，也在極客時間開設了《AI 大模型應用開發實戰營》課程，歡迎訂閱和交流。

Michael Yuan：

相比大家，我的編程起步比較晚，因為我是在博士畢業後才正式開始編程的。當時找不到工作，於是決定嘗試尋找程式設計師的職位。我發現大廠不願意僱傭沒有實際編程經驗的人，所以我決定從開源項目入手。那是很多年前，當時 Java 剛剛在服務端起步，所以我早期參與了 JBoss 這個開源項目，我們開發了當時也是現在最流行的 Java application server。後來我們將公司賣給了紅帽軟體公司。之後，我一直在開源社區中進行項目開發，也在公司工作過，還做過投資人，一直與開源社區和開發人員保持密切聯繫。期間，我出版了 5 本書。

我目前有一個開源項目叫做 WasmEdge，它是 CNCF 的一個項目。我們主要開發 Rust 和 WebAssembly (Wasm) 在雲原生與 AI 的應用框架與運行環境，大家可能會覺得 Rust 語言很受歡迎，但也有很多人認為它很難學。我們現在認為，使用大型語言模型來教授人們學習 Rust 是一件非常有趣的事情。另外，因為我從事研發管理工作已經很多年了，我發現使用大型語言模型，確實可以提高開發效率。

點擊底部閱讀原文訪問 InfoQ 官網，獲取更多精彩內容！

今日好文推薦

LLM對程式設計師的衝擊和影響

阿里轉崗先離職：清空司齡裁員不給錢？馬斯克作死推特，對手小扎社交平台喜獲3000萬用戶；美國或限制中國用戶使用美雲服務｜Q資訊

用計算機視覺識別模型種生菜？「科技+農業」還能這麼玩！

對話賈揚清、關濤、張伯翰：AI 平民化趨勢下，數據架構將被徹底顛覆？