優化人工智能的軟件工程 | 原創，AI翻譯
目錄
- 優化AI的軟體工程
- 針對AI優先開發的平面架構
- Python在AI驅動工作流程中的優勢
- 上下文工程與代幣優化
- 為AI協助而結構化代碼
- 作為手動AI代理的生存之道
- 在企業環境中使用AI工具
- 工具選擇與上下文管理
- 建立可重複使用的提示系統
- 利用Python輔助Java開發
- Python腳本輔助Java專案
- 跨語言開發策略
- AI輔助代碼生成
- AI時代的程式語言
- Python、Rust和Java的未來
- 效能與簡單性的權衡
- 語言演進與AI整合
優化AI的軟體工程
在這篇部落格中，我使用了數百個腳本來協助翻譯、遊樂場維護、前置資料維護和Telegram機器人。我相信這種開發方法可能代表了針對AI優化的軟體工程的未來。
我並不依賴Python模組的功能，也不想像大型Java Spring專案一樣結構化代碼。
我一生中參與了許多軟體專案。我見過令人印象深刻的銀行架構、微服務、有效的多國設計以最小化重複、基於Spring構建的堅固基礎框架，以及具有集中式配置的強大治理。
儘管這些銀行架構令人印象深刻，但如果我們今天重新開始，我會考慮優化LLM和AI。這將涉及更好的上下文工程、改進的關注點分離，並優先考慮AI優先思維而非以人為本的設計。儘管Spring提供了多層和良好的抽象，但對LLM和AI來說，導航可能具有挑戰性。
我認為我們應該追求更平坦的結構，類似於平面組織。這意味着使用兩個層級：第一層級調用第二層級。在函數中，調用另50個函數更好，而不是有50個嵌套層級或堆疊。AI/LLM難以判斷或推斷過於複雜的嵌套結構，但它們擅長處理100到200行代碼的較小函數。Python非常適合調用和從其他文件導入。
Python代碼比Java更容易的原因之一是其依賴管理簡單。您只需使用pip install添加依賴項。在Maven中，您需要在POM XML文件中編寫依賴項，然後使用mvn compile讓Maven下載依賴項。
Python簡單的另一個原因是其代碼可以直接運行而不會有麻煩。
儘管從Java 11開始，java命令可以直接執行單文件源代碼程序，而無需使用javac單獨編譯它們。但是，通常對於Java專案，它們很大，因此您必須使用mvn spring-boot:run以及一些屬性配置來運行它們。
第三個原因是Python的模組設計簡單；您可以使用from和import輕鬆地從其他文件導入代碼。
目前，許多AI聊天機器人可以直接在聊天機器人窗口中運行Python代碼，例如Grok。
當比較100個Java文件，每個文件約有1000行代碼，與一些簡單的Python腳本時，這不是一個公平的比較。對於這種專案，我更喜歡有1000個Python文件，每個文件約有100行代碼。
可以選擇代碼行或函數進行編輯是可以接受的。但是，您需要知道如何選擇。為什麼不讓AI處理這個任務，讓我們的生活更輕鬆呢？因此，我們只需要使用「選擇全部」選擇所有代碼，並告訴AI/LLM如何編輯。
對於Python來說，使用if __name__ == "__main__":運行和測試文件中的函數更容易。其他Python文件也更容易調用此文件中的函數，而無需運行測試。
這是針對AI優化的上下文工程。我們可以以其他方式實現嗎？AI/LLM是自回歸的。但是，當我們使用Copilot或Claude Code時，我們不知道AI軟體代理如何幫助我們。他們應該替我們考慮這些問題。
我們能否在用戶端將代碼特別排列以減少代幣使用？就此而言，擁有1000個Python文件，每個文件100行代碼的方法對此目的很有幫助。因為您可以在讓其他Python代碼調用它們之前輕鬆驗證函數和代碼文件。
但有一個問題是，如果您想同時更改幾個代碼文件，這並不容易。簡單的方法是將代碼複製到AI聊天機器人，並讓它們告訴您如何編輯這些文件中的代碼。
可能，我們不需要使用行數來分離函數或邏輯。但我們應該這樣做以將邏輯分離為小函數。我們可以通過自然地按邏輯類型分離它們來實現這一點，使它們看起來更短。
為什麼我們想要優化AI的軟體工程？因為AI很強大，我們應該優化一切以適應AI，然後讓AI盡可能幫助軟體工程。
這不僅適用於代碼，還適用於任何文本。假設我們是挑剔的編輯；我們不想讓AI一次編輯我們的大文本。我們想要逐段檢查。對於代碼，我們可以容忍輕微的錯誤或漏洞。對於文本，我們可以容忍它們，因為大多數讀者並不挑剔。
但代碼不同，因為有時候即使是輕微的錯誤也會導致大型專案完全失效。
對於XML或YAML文件，我們可能不需要過多分離，因為它們已經高度結構化。
對於HTML文件，我們應該進行一些分離。與其將數百個JavaScript文件與數百個HTML文件一起編寫，使其容易超過1000行代碼，不如使用import來管理JavaScript。對於JavaScript代碼，我們可以使用上述方法進行分離。
我們希望以讓AI輕鬆添加、編輯、刪除和運行代碼的方式結構化代碼。這是開始。想像一下，當所有代碼都可以輕鬆由AI生成或修復的那一天。世界將高度數位化。
想像我自己寫100個大型軟體專案，並提供API與他人連接。這包括我的日常日程；我自己就像一家擁有1000名員工的科技公司。它們是為我的需求定制的，以賺錢或花錢為我帶來好處。這真的很驚人。
作為手動AI代理的生存之道
AI代理應該自動運行代碼。現在，這篇文章的標題是「手動AI代理」。你可能以為我在開玩笑，但我不是。
我之所以說「手動AI代理」，是因為大公司的技術採用速度緩慢，原因是安全數據問題和長期考慮。
市場上有很多新技術；誰知道什麼會持久，什麼會迅速消失。
他們也有安全數據問題。通常，他們希望與數據政策嚴格且受公眾監管的大品牌合作。這解釋了為什麼微軟成為《財富》500強公司中的頂級合作夥伴。其他公司使用他們的Teams、Microsoft Office 365、Azure和Copilot。
但是，如果大公司不向員工提供LLM API使用權限呢？我們需要考慮如何作為手動AI代理工作。
這意味着我們將使用許多工具來工作，類似於API中使用的工具或函數調用。我們將自己進行提示工程或上下文工程。
與其使用Claude Code或Manus執行複雜任務，我們可能會自己使用普通AI聊天機器人執行任務。
AspectJ很好，因為它使用AOP編程攔截方法。Spring中的過濾器也很好，可以捕獲HTTP請求的日誌。Log4j中的日誌器很好，因為它可以將特定日誌重定向到文件。IntelliJ IDEA很好，因為它有一個功能可以將對象導出為文本。
SQL客戶端很好，因為它們可以輕鬆地將行導出為CSV或Excel文件。Git diff很好，因為它可以給出比較文本。
它們都幫助您為AI聊天機器人提供更好的上下文。AI聊天機器人也可以幫助許多Python腳本執行任務。
要成為有效的AI代理，您需要使用許多有效的工具來幫助您完成任務，無論是簡單還是複雜的。
沒有LLM/AI聊天機器人的API，您需要將文本複製到聊天機器人中。這比直接調用AI稍微繁瑣一些，但好消息是您可以更仔細地選擇上下文或提示。
因此，您不需要像那些自動AI代理一樣多次詢問AI聊天機器人。您可以仔細選擇您將使用的工具。
因此，作為手動AI代理工作有其優勢。然而，AI代理技術發展迅速，並向世界展示其潛力。
如果它們非常有用，大公司將像AI聊天機器人一樣採用它們。否則，它們將無法與採用它們的公司競爭——不僅是其他大公司，還有小型初創公司。因為AI現在如此強大，一家僅有數十名員工的初創公司可能擊敗擁有1,000名員工的公司。
作為手動AI代理的工作有時是不可避免的。這份工作除了缺乏先進的AI技術外，還有其他好處。找到好的工作也不容易。因此，在这种情况下，它給了我们空间利用传统智慧最大化利用AI聊天机器人。
这意味着我们可以组织和积累我们的提示，为AI聊天机器人创建系统提示，类似于Claude或Grok所使用的那些已公开的提示。这样，我们就不需要反复编写提示。我们可以使用Python脚本帮助我们编写提示。我们可以获取HTTP请求的日志并编写提示以生成API测试用例。
编程的魔力在于其无限的抽象层次。这类似于函数，您可以有100层函数调用。例如，微信是基于iOS构建的，微信小程序是基于微信构建的。iOS本身是基于Objective-C或Swift构建的，而它们又是基于LLVM和苹果ARM芯片的指令集构建的。
利用Python輔助Java開發
如何在AI時代利用Python幫助Java開發？我喜歡Python。在過去約3年裡，我最常使用Python，自從ChatGPT在2022年11月底發布以來。
一種幫助的方式是使用Python編寫SQL輔助腳本、測試腳本和日誌搜索腳本，用於Java專案。
使用Python分析Java的POM文件和套件依賴項。使用Python檢查Java中的數據一致性。有很多事情我們可以用Python來做，而不是用Java。
但Java沒有PyTorch。Python可以幫助任何在200行代碼中完成的事情，這在Java中需要500行。但通過使用AI工具，您也無法輕鬆獲得自己的PyTorch版本。即使像TinyGrad這樣的東西也需要時間來構建。
為什麼要先寫自己的腳本？一個原因是它非常可定制。沒有公開的軟體或開源專案可以直接幫助我們在專案中，特別是大公司的專案。
大公司的大型專案已開發十年或更久。它們已經有很多定制。
因此，未來將有許多圍繞大公司大型專案的周邊專案。大公司內部編碼代理工具中將有更多類似Claude的代碼路由器。將有更多定制的Postman、SQL客戶端和編譯器供大公司使用。
使用Python代碼可以連接到Java代理。
這意味着我需要學好Python和Java，以便知道如何使用其中一個來幫助另一個。
我可以使用AI的幫助，用Python為自己和企業專案創造許多東西。Java似乎不是障礙。Java、Spring、數據庫，以及Angular、Vue或React作為前端，不應該成為Python大量幫助的障礙。
編程是一件非常靈活的事情。極限在於我們的想像力。
因此，AI正在快速發展。我們可以通過測量AI幫助我們編寫代碼和學習的程度和容易程度來衡量AI的進步。
我們是否有朝一日可以編寫一些AI代理，然後這些代理幫助創建一個完整的TikTok，包括其大量微服務和大型iOS或Android專案？
如果AI如此強大，我們今天該做什麼？可能什麼都不做，因為我們今天所做的事情在AI的幫助下很容易實現。在2025年，我們一年的工作在AI的幫助下可能在2030年的AI能力下一個月就能完成。
這引出了我們的核心問題：我們的生命目的是什麼？這一切是關於什麼？如何過上好生活？
AI像其他技術一樣出現，為我們帶來自由。但看起來在這個資本社會中，每個人都像機器一樣忙碌。
回到主題。因此，Python也可以幫助編寫Java代碼。您可以使用Python獲取編寫代碼的上下文，並讓Copilot為您編寫代碼，以便一次就能做對。
AI關於提示工程和上下文工程。提示和上下文幫助AI聊天機器人的回應。
Python可以幫助上下文；Python可以幫助生成提示。
因此，這不僅僅是關於Java，而是關於其他所有編程語言。Python可以深入幫助它們。因此，我們為什麼還需要使用其他編程語言？
正是Python的內在設計使其性能不如其他編程語言，如C、C++或Rust。
AI時代的程式語言
AI現在如此強大，我們不得不從AI的角度重新思考一切。未來10年，哪些程式語言會流行？
Python肯定會。許多AI聊天機器人使用Python在瀏覽器中執行代碼，例如Grok。Python以其簡單性、易學性和不錯的性能而聞名。它被許多軟體專案採用。
Python比C++、Java和Rust慢。Java擁有龐大的社群。Rust基於C構建。
我好奇是否有許多專案會被Rust重寫或取代。被重寫在Rust中意味着參考舊專案並使用Rust實現相同功能。被取代意味着用其他語言編寫的軟體現在被相似的用Rust編寫的軟體取代。
Rust的語法相對複雜。但在AI時代，這不是什麼大問題，因為AI會幫助編寫代碼。對於複雜的語法，人類也不會有太多困難。
我認為印地語或泰米爾語相當複雜。但對於北印度人來說，印地語不是問題，對於南印度人來說，泰米爾語也不是問題。
但對於像我這樣的中國公民來說，我認為學習它是一個大問題。
乍看之下，印地語中的所有字符對我來說都相似。我認為印地語和阿拉伯語之間的差異就像中文和日語之間的差異，或者英語和西班牙語之間的差異。
程式語言之間的差異比自然語言之間的差異小。一個主要原因是程式語言僅在字符外觀上有所不同，而自然語言還包括發音。自然語言在兩個方面有所不同：字符集和發音。
程式語言只有約一個世紀的歷史，但自然語言有超過100個世紀。人們在某件事上花的時間越多，差異就越大。意見稍有不同的人會創造自己的版本。
這解釋了英語口音。在一些TikTok視頻中，人們說最差的英語口音是伯明翰。
因此，實際上，Rust沒有太多問題。它的性能相當好，因為它是基於C/C++構建的。
性能對許多應用程序至關重要。如今，許多應用程序被數十億人使用。對於底層雲計算基礎設施，它們的服務被多次調用。因此，即使是微小的性能增益也能節省大量金錢。
Rust有很多缺點嗎？人們抱怨的一件事是它難以學習。學習曲線陡峭。AI帶來了好消息，因為它幫助學習很多。
作為擁有10年經驗的軟體工程師，我無需了解太多關於Rust的知識。我可以使用AI幫助編寫許多簡單的Rust應用程序。我只需要知道基本的Rust編譯命令，如cargo和cargo build。我甚至不需要了解太多Rust語法本身。
對於Rust，可變性或借用模型不會給我帶來麻煩。對於少於200行代碼的簡單應用程序，我可以直接通過提供錯誤消息讓AI修復錯誤。
但為什麼人們還在大量使用Python，如果Rust這麼好？因為Python在另一個方面很好。它非常容易使用和學習。它擁有龐大的社群和許多庫。
Python仍然有足夠的性能，並可以支援數百萬，甚至數千萬用戶的產品。大多數產品沒有那麼多用戶。如果您有那麼多用戶，您可以聘請Rust或Java程式師來優化性能。
Python適合許多開發：機器學習、網頁開發、數學、教學和腳本。雖然Python不適合桌面應用程序，但MicroPython用於Raspberry Pi。
Java在AI時代會怎樣？它也會很好，因為它擁有龐大的用戶基礎和社群。AI在這方面幫助很大。它被許多大公司使用。它們傾向於不更改主要程式語言。對於它們的一些大型遺留專案，使用新程式語言重寫專案可能需要十年的努力。AI會幫助這個過程，但過程仍然會很緩慢。
通常，大公司中的理性人不會考慮更改主要程式語言。它們的主要業務在其他領域。它們不太關心技術。如果它們關心，它們會成為軟體或互聯網公司，並在開源社群中領先。然而，並非許多《財富》500強公司關心這一點。
由於AI，將會有許多初創公司。初創公司喜歡做新事物，因此它們會嘗試新程式語言。在AI時代，敏捷程式語言將在中小企業中獲勝。
在演算法競賽中，最喜歡的程式語言會改變嗎？C++已經主導這個領域幾十年了。在實際的演算法競賽中，您不能使用AI。但我想，在AI時代，將會有更少的人參加。
既然這些人在編程方面非常出色，而且由於AI，有這麼多機會，為什麼不更多的人建立實際產品供用戶使用，而不是練習演算法問題？即使是演算法競賽的GOAT，Gennady Korotkevich，也選擇加入Devin。
但演算法競賽可以是聰明程式員的放鬆或退休愛好。這就像下棋或打籃球。人們做這些事是因為他們喜歡或需要它們，而不是出於其他原因。許多人在30歲或40歲時打籃球。他們可能是為了健康或讓生活更有趣。
對於iOS和Android，它們是Java、Kotlin、Swift和Objective-C。由於AI，不會有重大變化，因為選擇有限。在用戶端，性能要求並不高。Google和Apple對它們的平台有很高的控制權。如果Google和Apple不改變，程式員也不會改變。
但對於服務器，有很多選擇。更適合AI的語言將獲勝。
程序化程式語言將比物件導向程式語言更受歡迎。程序化語言直接且容易被AI生成，而OOP語言有許多嵌套層級或設計模式。
AI會導致更多程式語言嗎？我認為會。Zed和OCaml將有更多用戶。LLMs/AI非常擅長學習模式，因此很容易將專案重寫為其他語言。
程式語言將面臨未來更多的競爭。那些在性能、語法和編譯器質量方面表現良好的語言將固有地更受歡迎。競爭就像LLMs。那些固有優秀的，如Claude和DeepSeek，變得流行。
如果AI變得如此強大，以至於我們不再需要學習編程，那還需要很長時間。假設我們有一個非常大的專案，有1,000個Java文件。AI可能需要10年才能輕鬆完成這個任務。