編輯 | 聽雨
出品 | 51CTO技術棧（微信號：blog51cto）
別急著寫代碼，先教AI怎么干活。
這是 Google Cloud Platform 開發(fā)者體驗部門副總裁Keith Ballinger 最近在《The New Stack Agents》節(jié)目上說的一句話，也是一針見血地指出了當下AI開發(fā)的最大誤區(qū)。
Ballinger 是少數(shù)依然親自寫代碼的高管之一，同時深度參與了最新的 “智能體化” 編程工具的研發(fā)與使用。他目前負責的核心產(chǎn)品——Gemini CLI，是 Google 直接對標 Claude Code 與 Codex 的競爭者。
很多程序員沉迷于讓 AI 寫更多的代碼，但Ballinger 認為，目前的智能體工具仍處于“初期階段”，要真正發(fā)揮潛力，就別急著寫代碼，先寫好文檔：
要真正讓 AI 成為高效開發(fā)者，人類開發(fā)者需要放慢速度、寫清楚文檔、規(guī)劃項目、描述架構。AI 不會讀心，它需要你告訴它要干什么。
他指出，開發(fā)者太常使用“一次性嘗試”的方式，這無法向模型提供足夠的信息，了解開發(fā)者的意圖以及問題的整體上下文。
圖片
Ballinger 還認為，從長遠來看，未來大部分開發(fā)者甚至可能不再需要查看代碼，而只需要寫下意圖（intent）。
他透露，未來 Gemini CLI 將支持子智能體（sub-agents）協(xié)作；自動監(jiān)控代碼測試、CI/CD 部署、日志與運行狀態(tài)；具備“AI-aware shell”，讓命令行本身成為一個智能環(huán)境。
小編為大家整理了這期播客的精華內(nèi)容，干貨滿滿，你將了解到：
- Google 開發(fā)者體驗部的工作內(nèi)容
- Ballinger的早期AI編程經(jīng)歷
- Gemini CLI 與 Agentic 編程理念
- AI 編程最佳實踐（寫文檔、寫計劃、架構驅動）
- 編程語言的未來與自然語言交互
- Ballinger 關于 AI、CLI、科研工具的觀點
建議收藏細讀，enjoy!
Google 開發(fā)者體驗部的工作
主持人：
谷歌開發(fā)者體驗部聽起來包含很多內(nèi)容，能先簡單介紹一下嗎？
Keith Ballinger ：
嗯，G 實際上代表 GCP（谷歌云平臺），但有趣的是，它也包括很多非 GCP 的項目，所以我可能應該重命名它。GDE（Google Developer Experience）組織負責一系列開發(fā)者工具和服務，包括一些經(jīng)典的 GCP 工具和服務，比如 Cloud Build 或 Cloud Deploy。同時我們也做很多 AI 代理式編碼工具，比如 Gemini CLI，這其實不是 GCP 獨有的產(chǎn)品。還有 Go 團隊，他們?yōu)槲夜ぷ鳎撠熼_源世界的項目，以及 Flutter、Dart 等谷歌開發(fā)者項目，每個人都應該注冊這些項目。總之，涵蓋了谷歌開發(fā)者相關的主要內(nèi)容。現(xiàn)在我們重點關注的，是代理式編碼，也就是如何讓開發(fā)者更有趣地使用 AI。
主持人：
你是怎么把這些工作理清楚的？在推動 AI 的同時，如何平衡 Go、Flutter、Dart 等其他項目？
Keith Ballinger ：
這是個好問題。我覺得最重要的是，AI 并不是完全獨立的東西，它能輔助代碼的各個環(huán)節(jié)。所以即使你在投資 Go 團隊，你其實也在支持代理式編碼。例如 Go 團隊有很多出色的靜態(tài)分析工具和 LSP（語言服務器協(xié)議），在這些基礎上，我們又建立了 MCP，使得在使用 Gemini CLI 編碼 Go 更加方便。這些工具已經(jīng)存在多年，它們對 AI 編碼依然非常有用。所以不必總是糾結于“這是不是純 AI 投資”，每項投資在很多方面都能兼顧 AI 編碼。
早期的AI編程經(jīng)歷
主持人：
在聊這個之前，我想了解一下你的職業(yè)經(jīng)歷。你曾在 Xamarin 工作，大約十年前，是個重要的開源項目。后來 Xamarin 被微軟收購，你去了 GitHub，現(xiàn)在在谷歌。能談談你的職業(yè)路徑嗎？
Keith Ballinger ：
我第一份開發(fā)工作是在 Intel，90 年代末在那里待了幾年。然后 1999 年我加入微軟，八年里一半時間做 .NET 和 C#，Andrew Salzberg（C# 的創(chuàng)造者）就在我隔壁辦公室。所以從那時起我一直在做開發(fā)工具。
離開微軟后，我做了很多創(chuàng)業(yè)項目，想積累各種經(jīng)驗，但最享受的還是面向開發(fā)者的項目。比如，我是 Standard Treasury 的首位工程師，這家公司為銀行構建 API，面向開發(fā)者，后來被硅谷銀行收購。至于 Xamarin，這很有趣，CEO Nat Friedman 曾聘我做顧問幫他找產(chǎn)品副總裁，最后我被邀請直接擔任 VP 產(chǎn)品，這對我來說有點意外，因為我以前主要是工程師，管理經(jīng)驗有限，但我就接受了，并自學了相關管理書籍。
后來 Xamarin 被微軟收購，我在微軟成為開發(fā)者服務的總經(jīng)理，負責 Azure DevOps 和內(nèi)部工程系統(tǒng)。之后我促成了微軟收購 GitHub，順利地加入了 GitHub，成為 CEO 和工程高級副總裁。
主持人：
這很契合。我曾參加 GitHub Universe 大會，看到很多創(chuàng)業(yè)公司，也看到 Google Jules，但它不屬于你的組織，對嗎？
Keith Ballinger ：沒錯，Jules 是實驗室項目。Google Labs 做前沿服務和應用，嘗試一些風險較高的想法。如果某個項目效果好，會轉入產(chǎn)品團隊。Jules 是例子，它與 GitHub（尤其是 Issues）關聯(lián)，可半匿名使用。這種方法論和技術也應用到其他免費或企業(yè)付費產(chǎn)品上。
主持人：
是的，Jules 類似 OpenAI Codex 之類的項目。
Keith Ballinger ：Anthropic 的 Spot Code 也是類似思路。我覺得 Jules 與其他項目有不同，它有更具體的 GitHub 工作流，而 Gemini CLI 是獨立的項目，也會有 Web 界面。Codex Web 和 Claude Code 做的是更通用的功能。
主持人：你提到很多人只會“單次調(diào)用”式使用 AI，你最初是怎么開始使用AI的？
Keith Ballinger ：我從小就對開發(fā)工具和技術感興趣，甚至是 Marvin Minsky 的郵件筆友，很早就對 AI 有興趣。2012 年我組建過 Bayes Hack 團隊，用 ML 為非營利組織服務。
在 GitHub，我們開始做 Copilot。當時 OpenAI 有了比較好的模型（Codex），能處理編程任務。最初我們做的只是代碼補全，非常互動，幫助用戶熟悉 AI。之后人們開始使用聊天功能，如 ChatGPT 或 Gemini 做 AI 編碼。再后來，出現(xiàn)了代理（agent），模型能代表用戶使用工具，這帶來了行業(yè)的有趣變化。大約去年中，工具使用型模型開始流行，人們不僅僅做代碼補全或聊天，而是能執(zhí)行半自動任務。
之前，我自己充當工具，把 Gemini 提供的代碼復制到項目中，還跑測試并反饋結果。CLI 出現(xiàn)后，這個過程自動化了，效率大大提高。
現(xiàn)在，我看到行業(yè)中大家對最佳實踐理解差異很大。要高效使用 AI，需要像對待同事一樣協(xié)作，遵循開發(fā)中的基本流程：寫用戶指南、技術設計、項目計劃等。這能顯著提升 AI 的成果。我有一個開源項目能演示這個方法。
主持人：
那展示一下吧。
Keith Ballinger ：
好的，我共享屏幕。這是我的桌面，你能看到一個叫 Line Counter 的文件嗎？
主持人：
看到了。
Keith Ballinger ：很好。你可以在我的 GitHub 上找到 Conductor 倉庫。我用它來設置項目，其中包括計劃文件、代碼風格指南、工作流、狀態(tài)文件、啟動 AI 的提示、用戶指南、架構等。
圖片
主持人：
看起來很詳細，這是你親自寫的，對嗎？
Keith Ballinger ：是的，但主要是 Markdown 文件。
主持人：
我想說的是，這種方法還是很冗長。未來會不會簡化？
Keith Ballinger ：我希望不會。我喜歡創(chuàng)作過程，參與思考問題和解決方案。AI 可以幫助，但仍需要我提供足夠的信息。
（然后 Keith 演示了如何用 Conductor 文件指引 AI 創(chuàng)建“智能行計數(shù)器”工具，生成項目結構、用戶指南、架構文檔等。通過這種迭代方法，可以完成復雜項目，例如他開發(fā)的針對 LLM 的編程語言 aether。）
圖片
主持人：
那你如何保證輸出正確？很多時候 prompt 的結果應用到開發(fā)環(huán)境可能不準確。
Keith Ballinger ：我用 AI 幫助驗證。我使用 TDD 方法，讓 AI 寫測試，逐步實現(xiàn)功能。主要通過測試和示例驗證，而不逐行檢查代碼。
主持人：
你在這個過程中發(fā)現(xiàn)了新的開發(fā)體驗嗎？
Keith Ballinger ：
是的。很多最好的軟件來自工程師的痛點。我的很多項目也是為了好玩，同時確保工具質(zhì)量。比如我開發(fā)了 Dev Sense，用于分析 Git 歷史。靈感也來自生活，比如為我制作的生日漫畫，讓我想到如何用 AI 創(chuàng)建漫畫生成器。
主持人：
在使用這些代理時，你遇到過哪些問題？
Keith Ballinger ：
最早 CLI 出現(xiàn)之前，我必須充當工具，操作繁瑣。CLI 出現(xiàn)后，這個問題得到解決，更高效、更自然。
CLI 的復興與“AI終端”
主持人：
為什么 CLI （命令行界面）最近又流行了？現(xiàn)在幾乎所有代理都有 CLI。
Keith Ballinger ：因為我們從未放棄終端。終端給開發(fā)者很大控制權，專注任務，不受復雜 UI 干擾。終端使用自然，與現(xiàn)代開發(fā)、開源生態(tài)契合，所以成為很理想的界面。
主持人：
CLI 現(xiàn)在在 AI 世界里是一個很有意思的話題，因為 Frederick 已經(jīng)完成了。我很好奇你怎么看終端本身的演進，Gemini CLI 是不是直接把 AI 帶進了終端？
Keith Ballinger ：是的，我覺得這是一個非常有趣的問題——終端本身會不會變得更具 AI 能力，或者會不會出現(xiàn)越來越多在終端里具備 AI 功能或受 AI 影響的命令工具？
大約一年前，我做了一個原型，為 Cube Cuddle 寫了一個擴展叫做 Cube Cuddle AI，當時代碼很糟糕，團隊后來重寫了它。現(xiàn)在它是 Cube Cuddle 的一部分，你可以用自然語言查詢，然后 Cube Cuddle 就能執(zhí)行操作，比如“現(xiàn)在哪些節(jié)點出問題了”。這是一個例子，說明工具可能越來越多地具備這種能力。另外，你也可以看到終端本身變得更 AI 化，Warp 就是一個例子。當然，現(xiàn)在最常見的 shell，除了終端之外，是 bash 和 zsh。
我一直在思考的一件事，我之前做過一個原型，我的團隊又做了一個更好的原型，就是——我們能不能創(chuàng)建一個“AI 感知的 shell”？每種交互方式都是一種可能性，就像你可以有一個理解你操作的桌面應用，或者網(wǎng)頁。我的猜測是，這些趨勢都會發(fā)生，因為它們都有很有意思的用例。
主持人：
你如何看 CLI 和 IDE，以及其他可能使用這些工具的場景之間的交接？上次我們談過 Gemini CLI 和 Z 的集成。
Keith Ballinger ：如果我沒記錯的話，是的。讓我再分享一下屏幕，我展示給你看。這種情況在所有工具中越來越多，非常有意思。
圖片
比如我在 VS Code 里，可以直接在 VS Code 的終端里啟動 CLI，它可以工作。而且，現(xiàn)在越來越多的 IDE 都能用它。我可以問：“這個文件是干什么的？”它知道我打開了哪些文件，比如我打開了 mod Dors，它會讀取并告訴我內(nèi)容。所以你不必在不同工具之間切換，你可以讓它們深度協(xié)作。我認為這可能會成為開發(fā)者喜歡的工作流。
編程語言的未來：從代碼到意圖
主持人：
我很好奇關于編程語言的演進。如果我們談終端的演進，也涉及很多相關內(nèi)容。你剛才說，通過生成式 AI，你不需要非常精通 Rust，可以讓機器幫你生成正確代碼。那么，我們對代碼本身的思考會有變化嗎？新的編程語言會因此產(chǎn)生變化嗎？
Keith Ballinger ：這是一個非常有趣的問題，因為存在很多不同觀點，沒有人能確定。我個人相對樂觀，這可能是少數(shù)觀點。宏碁就是一個例子。
我認為我們應該設計針對 LLM的編程語言，讓我們作為開發(fā)者“基本不用看代碼”。換句話說，開發(fā)者關注系統(tǒng)設計、架構、用戶界面等，代碼本身成為黑箱。這是抽象的自然進化。
我們從穿孔卡開始，逐步到 C 這種緊貼匯編的語言，再到 Java、C# 等更高抽象的語言。我認為下一步的抽象是——我的意圖，想做什么，以及如何組合出一個體驗或應用。在這種情況下，可能不需要手寫代碼。當然，總會有人熱愛寫代碼，他們在某些場景下仍然有競爭優(yōu)勢。
我希望他們享受編程，但我認為未來更多人不需要深入寫代碼。
還有一個有趣的現(xiàn)象——有人做過實驗，把兩個智能體放在一起通信，隨著時間推移，它們發(fā)明了一種非常緊湊的“自造語言”互相交流。非常有意思，我很想看到它的發(fā)展。
主持人：
這種抽象層是自然語言嗎？還是一種元編程語言？自然語言不夠精確吧。
Keith Ballinger ：
我也不確定。但我以前反對自然語言，覺得會有更精確的交互方式。但隨著經(jīng)驗增加，我認為自然語言其實可以很精確，比如教科書或非虛構類作品，寫得很清楚。只要具備良好的表達能力和問題分解能力，就能有效與 AI 交互。
你可以訓練人們學習新的語法或視覺語言，但那需要額外學習。我認為重點是提升人的寫作和問題分解能力，這是核心技能。
主持人：
這和今天程序員的技能不同嗎？
Keith Ballinger ：
我不這么認為。偉大的程序員本身就是優(yōu)秀的寫作者，他們記錄問題、方案、設計，然后把業(yè)務問題轉化為技術解決方案。未來，在 AI 編程世界，可能寫代碼不再是核心技能。
主持人：
那依賴推理的系統(tǒng)有什么權衡嗎？因為你依賴機器做結論，它可能有限制。
Keith Ballinger ：你能具體說說嗎，我沒完全明白。
主持人：
AI 本質(zhì)上是黑箱，我們不能追蹤它內(nèi)部邏輯。如何確保推理準確？現(xiàn)在代理嘗試做推理，但需要完整系統(tǒng)來驗證結果。
Keith Ballinger ：我理解了。一方面，研究者正在做類似“AI MRI”的工作，分析模型在生成 token 時的內(nèi)部電路。另一方面，和人類程序員一樣，我不必了解他們的大腦細節(jié)，只需有效溝通即可。
同時，我們需要方法評估 AI 系統(tǒng)的表現(xiàn)，比如它是否偏離預期。很多技術正在開發(fā)中，包括 CI/CD 測試和生產(chǎn)環(huán)境監(jiān)控。總體上，模型的可靠性越來越高，但我們?nèi)孕鑴?chuàng)新方法。
Gemini CLI 將支持子代理協(xié)作
主持人：
回到 CLI，談談 Gemini CLI 的現(xiàn)狀吧。CLI 和 Gemini 的交互是現(xiàn)在的主要模式嗎？這是最終形態(tài)嗎？
Keith Ballinger ：
絕對不是終點。我覺得我們還在第一局，或者剛熱身。基本功能已經(jīng)能用，比如和 Gemini 對話、使用工具、進行推理，但還有很多優(yōu)化空間。
模型會越來越智能，有人認為未來只需薄薄的代理代碼封裝，但我認為我們總會有更多功能可以加入封裝中，有些功能最終會并入模型。
關鍵方向有幾類：一是 UX/UI，比如在 CLI 或 AI 應用中，如何與 AI 交互、批準工具或生成子代理等；二是處理更大問題，比如子代理、問題分解、監(jiān)控運行時系統(tǒng)、收集數(shù)據(jù)反饋。
舉個例子，我希望用 Gemini CLI 寫代碼、提交、運行 CI/CD、部署到 Cloud Run，然后監(jiān)控數(shù)據(jù)反饋。比如告訴 Gemini CLI 用 GitHub CLI 監(jiān)控 PR 的 Actions，如果失敗就自動修復，需要時詢問我，直到 PR 成功。接下來可以從 Cloud Run 下載日志、發(fā)請求、判斷是否正常并調(diào)整。
這些都是工作流優(yōu)化問題，Gemini CLI 在 UX、工作流、性能優(yōu)化等方面正在投入很多。
主持人：
那 Gemini CLI 和后臺代理怎么配合？在 CLI 中，我可以觀察 Gemini 的操作。
Keith Ballinger ：
很快就可以。我們有子代理功能，你可以啟動它們。CLI 本身也能作為后臺代理，我經(jīng)常啟動另一個 CLI 實例并監(jiān)控它。
主持人：
你怎么監(jiān)控子代理？
Keith Ballinger ：每個 CLI 都在構建基礎設施，比如命令查看聊天記錄等。我之前的系統(tǒng)是自定義方式——給子代理一個狀態(tài)文件，父 CLI 定期檢查它。Gemini CLI 是開源項目，可以從社區(qū) PR 和討論中獲得很多創(chuàng)意。
主持人：
Gemini CLI 很大一部分代碼是由 Gemini CLI 自己寫的嗎？
Keith Ballinger ：
是的，我們早期就開始用它開發(fā)它自己。整個團隊經(jīng)常用 CLI 來開發(fā) CLI。
主持人：
CLI 能理解代碼上下文嗎？
Keith Ballinger ：
可以。你可以手動給 CLI 提供上下文，比如某個文件名，它會讀取并生成單元測試。Gemini 有很大的上下文窗口，也會自己決定讀取哪些文件構建上下文。
行業(yè)上還需要改進上下文管理。上下文越大，出錯概率越高。子代理可以接收特定任務的精確上下文，這也是一個創(chuàng)新方向。
主持人：
這會涉及狀態(tài)管理問題，對嗎？如何管理分布式環(huán)境中的狀態(tài)？
Keith Ballinger ：
是的，項目有整個 SDLC，需要管理狀態(tài)。我通常用狀態(tài) markdown 文件存儲信息。大團隊使用 AI 時，也需要協(xié)調(diào)各代理，讓它們知道所需信息。可能會有“主代理”掌握整體情況。我們在這個方向上仍在探索，但進展很快。AI 生成和 AI 消費的文檔能幫助很多，但這是靜態(tài)的。
還需要理解部署拓撲、服務負載等信息。這些都是 Gemini CLI 早期發(fā)展階段需要迭代的地方。
主持人：
這也涉及處理能力問題，每個代理可能有自己的狀態(tài)，這需要強大基礎設施。像 Google 這樣的云服務提供商幾乎是必須的，因為誰能提供足夠計算能力管理這些代理？
Keith Ballinger ：
你說得對，我在 Google，可能有偏見，但我來這里的原因之一就是 Google 有所有這些資源，TPU 能提供強大支持。
主持人：
其他云服務商呢？
Keith Ballinger ：當然有其他，但你說得對。GCP 有 Cloud Assist，其中有 Investigations 功能，它可以分析日志，收集運行時環(huán)境信息，幫助診斷問題。
這種狀態(tài)管理和 AI 代理結合的用例非常有效，可能比其他用例都要好。
與AI共寫論文
主持人：
我知道你之前在節(jié)目開始前聊到過，用這些模型做科學和數(shù)學類的問題，有些人可能會說它們還不夠好，但顯然它們越來越強。你對這方面的興趣從何而來？
Keith Ballinger ：
嗯，我其實不是特別專業(yè)，但我非常喜歡數(shù)學和科學，總是想嘗試新的方法。過去幾個月，我花了很多時間用 Gemini 來做數(shù)學和科學相關的論文寫作、研究、形式化驗證等。我并不是專家，但這邊有很多科學家可以幫我。事實上，我可以給你展示一個例子，我來分享我的屏幕。看看我是否打開了它。是的，這是我用 Gemini 寫的一篇論文示例，我用了一個叫 Coauthor 的工具，我稍后會介紹。它主要做 LaTeX 管理，還有代碼建模和繪圖等。
主持人：
你覺得可能不在科學出版領域的人，也能用它嗎？
Keith Ballinger ：正是如此。最終，我這里有一篇論文——研究黑洞的誤差校正效應。雖然這篇論文不是我自己編碼完成的，但它是通過 Gemini 迭代構建的，同時做了實驗和形式化驗證。
圖片
我創(chuàng)建的工具叫 Coauthor。我來給你演示一下。它基本上是一套提示和操作手冊，包括 LaTeX、Lean 使用指南，還有用戶指南和代碼風格指南，非常類似于 Conductor。我還有一個安裝腳本，安裝后它會調(diào)用 Gemini CLI 來控制整個過程。相比我直接在 Gemini CLI 里操作，Coauthor 會先收集上下文信息，再啟動 CLI，幫我管理整個流程。
圖片
我覺得這是一個非常有趣的思路。在科學和數(shù)學領域，人們一直在研究如何實現(xiàn)自主操作，比如“自主科學家”，這是很有趣的。但在編程世界，我們起步時不是從這里開始的。科學、數(shù)學和編程有很多相似之處。在編程領域，我們是從代碼補全、聊天、帶工具的聊天，然后是半自主，最終逐步實現(xiàn)更自主的代理。科學和數(shù)學領域也是逐步累積的。很明顯，Gemini CLI 在這類工作中非常有用，因為它是互動的，只有在互動之后，才可能發(fā)展到完全自主的一次性操作。
主持人：
你提交過基于 Coauthor 的論文，并通過同行評審了嗎？
Keith Ballinger ：我不認為自己是科學家。我關注的是流程，而不是去發(fā)明新的科學或數(shù)學知識。
主持人：
將來可能會有一個學術研討會，所有參會者都是 Agent，所有演講者也是 Agent，它們代表自己生成的論文。
Keith Ballinger ：我一點都不意外。現(xiàn)在不同期刊對 AI 參與論文寫作的接受程度不一樣。一般來說，你必須說明在論文中使用 AI 的情況。有些期刊只允許 AI 對寫作進行潤色，有些期刊則更開放。我相信未來會越來越寬松。
我展示的那篇論文，基本上是 AI 完成的，我沿途提供指導，就像我做 Ether 編程語言時一樣。但過程是互動的。我現(xiàn)在合作的物理學家和數(shù)學家，也會用這些工具加速工作，而不是完全交給 AI。未來或許會出現(xiàn)自主科研的代理，但現(xiàn)在讓科學家更高效，就已經(jīng)非常有價值。
主持人：
那場景會不會是我們在 AI 學術會議上喝啤酒，機器人給我們講解論文？
Keith Ballinger ：
我等不及了，真的有太多有趣的可能。
主持人：
然后它們會喝機油。機器人團隊總說，機器人經(jīng)常出故障，所以進展沒有預期那么快。
Keith Ballinger ：娛樂產(chǎn)業(yè)已經(jīng)高度依賴 AI，因為我們喜歡娛樂。你會看到更多這種情況，比如漫畫創(chuàng)作、視頻內(nèi)容、音頻內(nèi)容等。隨著依賴增加，系統(tǒng)的可靠性也必須更高。
完全 vibe coding對未來的影響
主持人：
時間差不多了，我們看看是否有觀眾提問。
來自 Joshua 的問題，關于你之前提到的“不可能計算”（impossible computing），你覺得“完全 vibe coding”在未來一年會有多大影響？
圖片
Keith Ballinger ：好問題。我提到“impossible coding”是有些理想化的意思，我希望大家覺得沒什么不可能，通過編碼幾乎可以實現(xiàn)一切。
具體影響取決于“完全 vibe coding”的定義。我認為，知識工作者和普通用戶都可能用 vibe 編程，比如為單次生日派對創(chuàng)建網(wǎng)站，RSVP 后就消失。對知識工作者尤其如此，他們可以為自己創(chuàng)建業(yè)務應用。
例如，營銷人員用 Gemini Enterprise 創(chuàng)建輔助文案寫作的應用。這類工具能極大提升效率，因為軟件需求遠超供應。
關鍵是要保證交接順暢。如果營銷人員做了一個應用，內(nèi)部工程團隊之后需要接手。AI 可以在第一步就捕捉到開發(fā)意圖。
像 Excel 或 Access 數(shù)據(jù)庫那樣，90 年代人們沒有技術背景也能做復雜工具，但后來往往得重寫。未來或許無需每次都重寫。
主持人：
也可能每次都重新創(chuàng)建應用，而不需要保存，只是即時生成界面。
Keith Ballinger ：
是的，未來的桌面操作系統(tǒng)可能會實時動態(tài)生成用戶界面。但我認為我們正在進入一個既奇怪又激動人心的世界。
最近閱讀的書籍
主持人：
最后一個問題，我看到你十年前的博客，總是有閱讀推薦。你現(xiàn)在在讀哪些科學或數(shù)學書籍，有推薦嗎？
Keith Ballinger ：我用 Kindle。最近在讀 Adrian Tchaikovsky 的《地球的碎片》，讀到一半，非常喜歡。
主持人：
我沒怎么讀過他的書。
Keith Ballinger ：
這是我第一次讀他的小說。最近我讀了《大腦的7.5堂課》，非常好。還有 Scott Myers 的作品，以及《第四個時代》，去年重讀了 John Rawls 的《正義論》，都很有趣。最精彩的是最近兩年讀的《明天，明天，明天》。
主持人：
太棒了，我也喜歡那本書。
Keith Ballinger ：
去年圣誕節(jié)我送給員工，作為創(chuàng)作者，這本書完美捕捉了創(chuàng)作精神。
這是我十年來讀過的最好的書之一，我推薦給每個人。它完美呈現(xiàn)了團隊合作和創(chuàng)作的精神。還有人際關系、人與人的互動及其變化，很酷。
主持人：
今天就到這里吧，時間超了，但討論非常精彩。
Keith Ballinger ：
當然，我很享受這次對話，謝謝邀請。
