?編輯 | 云昭

?出品 | 51CTO技術棧（微信號：blog51cto）

“現在是AI最糟糕的階段！”

如果你去翻看OpenAI、Anthropic這兩家的Top10 token 消耗的玩家排行榜、無一例外都會發現，各種 Code 工具都會名列前茅。如今各種AI Coding工具大行其道！

不管是開發者、還是“外行人”，都在這股洪流中親自給這個賽道做出了注解，這已經是不可逆轉的大趨勢。

不懂編程的“外行人”，難掩興奮：

大家問我怎么實現的，我也答不上來——只是想做一個“外星終端”，結果它真的跑起來了。

但身處企業之中，為成品負責、兜底的開發人員及高管們，卻無疑都在面臨這樣一個開發真相：

AI 工具確實把前 10% 的工作變成了 1%，但后面的 99%依舊是瓶頸。

“所以，我們現在處于AI最糟糕的階段！但以后會越來越好。”

近日，美國華盛頓特區一家AI初創公司Antithesis的CEO以及其現場首席技術官對于現在的Vibe Coding現狀，帶來了一手的實踐心得。

圖片

CEO Will Wilson 很直截了當的指出了大模型現在的弊端：LLM 其實還不夠“聰明”。它更像是個“記憶巨獸”。

它見過互聯網上所有的代碼示例。對于常見問題，比如 React demo 或主流框架，它能迅速給出好結果；但一旦遇到新問題或小眾技術棧，性能就會驟降。

它擅長“從 0 到 1”的生成，但不擅長在百萬行代碼庫里做有邏輯的修改。它不會像人那樣推理，只是在統計相似性。

但，可怕之處在于，并不是AI所帶來的這種快餐式但長期看卻有極大安全質量隱患的代碼如果沒有好的抵御措施，終將會釀成一場質量塌方的“公地悲劇”：

我常把它比作“公地悲劇”：一個人往湖里排點廢水沒關系，但大家都這么干，湖就完了。

同理，一個人用 AI 快速寫代碼、丟給同事改問題還好，但所有人都這么做，整個系統的質量就崩塌了。

不止如此，更令人擔憂的是，大模型不僅僅帶來的是減慢軟件交付的真相，它還為業界帶來了相當嚴重的隱形危險：AI代勞所帶來的團隊能力退化！

核心是別讓團隊的能力退化。

如果一個工程師長期讓 AI 代勞，過幾周不寫代碼，手感就會生疏。語言也是一樣，寫了一年 Python，就會忘了怎么寫 C。這些“解決問題的肌肉”如果不用，就會退化。

關鍵還是在于，我們對待AI如何融入自己工作流的問題。

這里，Wilson分享了自己團隊“使用AI不但不會阻礙交付速度、甚至真正加速”的兩個非常實用的方法：文檔和測試。

第一，文檔本身可以作為 LLM 的上下文輸入，幫助它輸出更優結果；第二，文檔能讓團隊保持對代碼意圖的共享理解——而這往往是“AI 寫代碼”環境下最先崩塌的東西。

另一個類似的關鍵點，是測試。有趣的是：那些最“保守”、最注重架構和測試規范的團隊，反而能從 AI 工具中獲得最大加速。

對于企業場景，現場首席技術官Shah認為，在軟件開發賽道，企業沒必要花費大力氣為大模型去部署、構建一套全自動的、逼著員工去使用、然后統計員工使用時長的基礎軟件平臺，反而不如直接幫員工訂閱一份Claude、Gemini更好些。

企業現在面臨的問題是，總想要在公司層面把 AI 部署成一種“大而全的自動化流水線”，并且真正提取價值，這其實很難。

反而，用當下這些工具，也許更好的做法是——干脆給每個員工一份 Claude、Gemini 或別的訂閱，讓他們自己決定怎么整合、怎么用得最順手。

除此之外，兩位還對于AI時代，針對AI輔助生成的代碼，應該做怎樣的測試給出了一個有意思的判斷：屬性測試又復興了！

比如不要寫 700 個測試去證明“在各種場景下機器人都不會殺我”，而是寫一條規則：“防御機器人在任何情況下都不得殺死創造者。”——這才是有用的測試。

ok，料還很多，篇幅關系，這里就先打住。

小編這就為各位奉上整理的采訪內容。密度很高，建議收藏細讀。

 外行人用AI做Demo，是一場結構性變化

Chris Pirillo：大家好，我是Chris Pirillo，來自The NewStack。非常高興見到各位。

今天我們要聊的主題是——如何讓 AI 不再拖慢開發者的速度。我先自我聲明一下：我不是程序員，連電視劇里的程序員都沒演過。不過我算是一種“氛圍型程序員”（vibe coder）：我在開發軟件，但又不完全是傳統意義的開發者，這本身就是個哲學問題。沒人能回答我是不是“程序員”，不過這也沒關系，我們今天要聊的話題才是真正有意思的。

和我一起參與討論的有 Antithesis 的兩位嘉賓——現場首席技術官 Akshay Shah，以及 CEO Will Wilson。

Akshay Shah：這個問題挺好。我其實本職是工程師，也曾是 Antithesis 的客戶。當時我覺得他們的“來自未來的自動化測試技術”太驚人了，于是我就加入了。現在我的工作主要是和客戶交流、參加像這樣的討論，讓更多人理解這種技術，并讓它真正落地。

Chris Pirillo：說到這，我自己也做過一個“外星人計算機終端”的小項目，用各種奇怪的字符和動畫做出來，放到 GitHub 上后反響挺大。大家問我怎么實現的，我也答不上來——只是想做一個“外星終端”，結果它真的跑起來了。我知道有些人說這類東西只是個“潮流”，但我真心喜歡這種潮流。

Will Wilson：我覺得這不是潮流，而是個巨大的變化。它讓非程序員也能快速做出原型，把想法具象化。以前設計師要做線框圖、寫產品文檔，現在直接點個按鈕、運行個 demo 就能展示效果。這極大改善了技術人員和非技術人員之間的溝通。

Chris Pirillo：對，我能理解。Akshay 是 Field CTO，那 Will 你作為 CEO，我猜你也得什么都管一點？

Will Wilson：沒錯，我負責點披薩和倒垃圾（笑）。

Akshay Shah：那你說說你到底都干嘛？

Will Wilson：所有其他沒人干的事（笑）。

AI 把Demo開發提速 10%，但剩下的 90% 更難了，工程師來兜底

Chris Pirillo：哈哈，這就對了。我自己雖然懂點技術，但更多是站在產品經理的角度思考問題。我尊重代碼的復雜性，但也不會被它束縛。像“vibe coding”這種讓人用直覺和工具去創造技術的方式，真的挺迷人的。

Will Wilson：其實這種“原型和成品之間的差距”一直存在。你可以很快做個 demo，但要變成真正可用、可擴展、無 bug 的產品，那才是90% 的工作量。AI 工具確實把前 10% 的工作變成了 1%，但后面的 99%（也就是測試、健壯性、國際化、極端場景等）依然是瓶頸。

Chris Pirillo：我懂。AI 能加速早期階段，但復雜度總歸得有人來兜底。有人說：“現在是 AI 最糟糕的階段，以后只會更好。”當然，也許有一天機器真會吃掉我們（笑），但我愿意相信事情會朝好的方向發展。

Akshay Shah：也許吧，但要注意一點——雖然模型在不斷進步，但AI 對工程團隊的影響不一定總是變好。技術進步常常帶來意料之外的副作用，比如讓系統更復雜或增加隱性風險。

為什么LLM讓開發反而變慢了：公地悲劇

Chris Pirillo：那為什么很多公司用了 LLM 之后，開發反而變慢了？

Will Wilson：我覺得原因在于——LLM 其實還不夠“聰明”。它更像是個“記憶巨獸”：見過互聯網上所有的代碼示例。對于常見問題，比如 React demo 或主流框架，它能迅速給出好結果；但一旦遇到新問題或小眾技術棧，性能就會驟降。

它擅長“從 0 到 1”的生成，但不擅長在百萬行代碼庫里做有邏輯的修改。它不會像人那樣推理，只是在統計相似性。

Akshay Shah：對，而且還有個“次級效應”——過去我們把“寫代碼”當作一種“思考的證明”。但現在 LLM 可以幫你寫代碼，這個證明就消失了。團隊協作體系還沒適應這種變化。

這有點像自動駕駛汽車：當你以為它能完全接管時，其實它并不能。AI 寫代碼也一樣，你太容易“放松警惕”，讓它幫你開 Pull Request，然后你去問用戶“你試了嗎？”——這種行為模式破壞了原本工程師之間的信任契約。

Will Wilson：是的，現在很多開源項目已經開始拒絕 AI 生成的提交代碼。除非貢獻者聲明“我看過每一行并理解它”，否則維護者不愿意審查。沒人想幫 AI 善后。

Chris Pirillo：這其實在觸及一個更深層的問題——速度的提升可能反而削弱了團隊的質量控制機制。

Will Wilson：對。LLM 不會消失，就像我們不會回到編譯器出現之前的時代。問題是，團隊必須發展出新的文化習慣和技術防御體系，防止這些工具的濫用。

我常把它比作“公地悲劇”：一個人往湖里排點廢水沒關系，但大家都這么干，湖就完了。同理，一個人用 AI 快速寫代碼、丟給同事改問題還好，但所有人都這么做，整個系統的質量就崩塌了。

Akshay Shah：沒錯。AI 的使用也要有“環保意識”。否則生產效率的提升會被維護成本吞噬。

如何確保LLM不拖慢團隊？最優秀的團隊，都在“用文檔與測試馴服 AI”

Chris Pirillo：說得好——那企業該怎么確保 LLM 真能提速，而不是拖慢團隊呢？

Will Wilson：我認為關鍵在于控制使用這類強大但不可靠工具的“二階后果”。AI 工具非常快、非常強大，但也非常容易出錯。解決方案其實已經在出現：我們發現，那些大量使用 AI 和 LLM 的最優秀團隊，都有極其完善的文檔體系。

這其實帶來雙重好處。第一，文檔本身可以作為 LLM 的上下文輸入，幫助它輸出更優結果；第二，文檔能讓團隊保持對代碼意圖的共享理解——而這往往是“AI 寫代碼”環境下最先崩塌的東西。

另一個類似的關鍵點，是測試。可以把它看作另一種形式的文檔。如果 LLM 寫了一堆代碼，而你有一套強大、健壯的自動化測試體系，能及時告訴你代碼是否破壞了邏輯——那就意味著你可以“放心大膽地飛”。

比如你可以說：“LLM 寫了這段代碼，我沒看完每一行，但測試全綠（通過）了，那我暫時允許它提交，之后再仔細審查。” 這樣的體系讓開發過程更輕松。有趣的是：那些最“保守”、最注重架構和測試規范的團隊，反而能從 AI 工具中獲得最大加速。

Chris Pirillo：Akshay，你怎么看？公司該怎么確保 LLM 真正提升速度？

Akshay Shah：Will 說得很到位。其實科技界很多問題早就有答案了。最優秀的團隊一直擅長建立自動化護欄，減少人工的反復檢查和收尾工作。AI 工具只是讓“頂尖團隊”與“普通團隊”之間的差距進一步擴大。

Chris Pirillo：Will 提到了一個讓人頭疼的詞：測試（Testing）。它到底為什么對 LLM 尤為重要？

Will Wilson：有兩個原因。第一個是顯而易見的：如果你信任自己的測試體系，知道它能覆蓋代碼的關鍵邏輯，那么即使你把部分思考交給一個“不會真正思考”的系統，也能放下負擔。第二個原因其實更深刻：測試本身就是“會反擊的文檔”。每個測試都記錄著開發者對系統行為的預期，這能有效防止在“高速協作”中出現的理解偏差和代碼漂移。

測試是“會反擊的文檔”，也是最強的 Prompt

Akshay Shah：而那些對 LLM 最持懷疑態度的“老派工程師”常說：這場爭論我們幾十年前就吵過——匯編程序員批評 C，C 的人批評 Lisp，如今又輪到 LLM。

本質上，一個 prompt 其實就像是一種“高層編程語言”或“奇特編譯器”中的規格說明。而最精確、最具可操作性的“規格說明”形式，就是測試套件（test suite）。

所以寫出一套完備的測試，其實就是給 LLM 提供最精確的 prompt，讓它不需要反復問“你想要這樣嗎？”，因為答案已經內嵌在測試中了。

Will Wilson：對，這正是一些團隊（比如使用 Claude Code 的團隊）已經在做的事：讓模型在循環中修改代碼、運行測試，直到通過所有檢查。有時候它甚至“聰明”到會直接刪掉測試（笑）——這可能是“機器人起義”的第一階段。但顯然，測試越多、定義越清晰，模型的效果越好、能力越強。

屬性測試的復興

Will Wilson：我認為接下來會復興一種很特別的測試方式——屬性測試（Property-Based Testing）。傳統測試給出幾個輸入輸出示例，比如“輸入 1 輸出 2，輸入 2 輸出 4”；而屬性測試則定義抽象規則，比如：“無論輸入什么數，輸出都應是它的兩倍。”這種方式既是更高維度的文檔，也能更好地防止 LLM“鉆空子”，讓系統保持穩定。

Akshay Shah：對，最早的屬性測試框架叫QuickCheck，發布于 1999 年。幾乎同時，IETF 也確立了規范性用語：“MUST / MUST NOT / MAY”等大寫關鍵字，用來表達開發者對規則的確定程度。

我覺得這兩件事在今天都特別有意義：我們的測試應該像規范文檔一樣，直接、明確地表達人類對軟件行為的期望。不要寫成“例子堆砌”，而要寫出“鐵律”。

比如不要寫 700 個測試去證明“在各種場景下機器人都不會殺我”，而是寫一條規則：“防御機器人在任何情況下都不得殺死創造者。”——這才是有用的測試。

如何讓AI重寫舊系統，我們將處于一個“永久測試版本”時代

Chris Pirillo：我們收到一個現場觀眾提問。他問：未來的工作流將如何應對系統廢棄（deprecation）的問題？

Will Wilson：好問題。我們沒有時間機器，但確實可以“預見未來”。我理解你的意思是：當我們想重寫或替換舊系統時，AI 工具和測試體系會如何幫忙？

其實這正是 LLM 特別擅長的場景。它非常擅長處理“遷移”類任務，比如：“請將這個系統重寫為另一種語言”或“請改用新框架實現同樣功能”。當然，它仍需要一定的指導和人工修正，但往往能幫你完成 80% 的工作。

而我們剛提到的屬性測試在這里非常關鍵——你可以直接定義：‘新系統應與舊系統行為一致，但性能更好。’這樣就能精確檢測 AI 或工程師是否覆蓋了所有邊緣情況。我認為未來我們將更頻繁地“拆掉舊系統、重建新系統”。

Akshay Shah：沒錯。這其實也是老生常談。Michael Feathers 在那本經典著作《Working Effectively with Legacy Code》中早就說過：“所謂遺留代碼，就是缺乏測試的代碼。”

如今我們依然處在同樣的境地，只是我們對軟件演化速度的期望越來越高，因此我們必須寫得更清晰、更可驗證。

Chris Pirillo：我想到一個詞——我們似乎正處在“永久測試版（Perpetual Beta）”的狀態，沒有任何東西是最終版。

Akshay Shah：我更樂觀一點。這不是“半成品時代”，而是“迭代加速時代”。我們仍然能發布 1.0，但從 1.0 到 2.0 不該再等兩年，而是兩個月。

Vibe的價值，在于降低門檻，與其構建自動化流水線，不如給員工訂閱Claude

Chris Pirillo：我同意。順便，我提到過我那個“外星人終端”的 vibe coding 項目——我現在給大家展示下。

Akshay Shah：在 GitHub 上那個？

Chris Pirillo：對，就是那個。刷新一下就能換一組不同的小部件和顏色，全是“即興 vibe coding”做出來的。不是嚴肅項目，就是好玩。雖然有一個 bug 我一直沒修掉（笑）。

Akshay Shah：但這其實挺重要的。編程應該是一種游戲，一種探索。這世界上最棒的“樂高”就是軟件，你可以靠它謀生。如果有一代人能從這種輕松好玩的方式入門，那未來的創新者就會更多。

Will Wilson：完全同意。有些人喜歡從零開始、純手寫代碼；但對大多數人來說，從一個“能跑”的東西開始修改，更容易上手。而 vibe coding 的價值就在這里——它降低了進入門檻。

比如我小時候做游戲，全是文本界面，因為我畫畫太差。但今天，我可以讓 Midjourney 給我畫概念圖，生成角色素材。AI 幫我補齊短板，這就是新一代創造者的力量所在。

Akshay Shah：這就回到我們一開始討論的那個核心點——把 AI 整合進你的工作流程、讓大模型真正幫你提速的最佳方式，并不是把整項任務全權交給它然后轉身走人。而是把它當作一個“共創伙伴”，幫你補短板，在你卡住時給你提示。

我桌上擺著一只橡皮小黃鴨，每當我卡殼時，我就會跟它說話。它當然不會回我話，但 Claude 會。

圖片

Akshay Shah：Claude 就像一個更聰明的“小黃鴨”，能在你陷入困境時幫你理清思路，這太神奇了。當然，這并不是一個“適合企業推廣的故事”——它不是那種買來、部署、統計使用率、然后逼著工程師用的企業軟件。

這更像是一種“個人選擇”，就像我自己的 vim 配置，是讓我變得更快、更高效的私人物品。

而這其實也是企業現在面臨的問題——要在公司層面把 AI 部署成一種“大而全的自動化流水線”，并且真正提取價值，其實很難。反而，用當下這些工具，也許更好的做法是——干脆給每個員工一份 Claude、Gemini 或別的訂閱，讓他們自己決定怎么整合、怎么用得最順手。

Chris Pirillo：是啊。

Will Wilson：我也有小黃鴨，我有好幾只。

Akshay Shah：我不會和它們說話，我的是達斯·維達款小黃鴨。

VibeCoding的理解債和技術債

Chris Pirillo：哈哈，我喜歡這個。其實我也有幾只維達鴨，它們也不會回我話。我最近在 3D 打印鴨子，這已經成了我日常的一部分。不過說回主題——我覺得我已經成了“vibe coding”的粉絲，這對我來說不僅是個愛好。那么，從長遠來看，vibe coding 會帶來哪些潛在問題？

Will Wilson：有人提出一個詞，叫“理解債”（comprehension debt）。每次你用 vibe coding 寫點東西，如果你沒有認真 review 到“仿佛這段代碼就是你親手寫的”這種程度，你其實就在代碼庫里放進了一段你并不真正理解的東西。如果這樣做的次數太多，你最終就不知道整個程序是怎么運作的了。

Will Wilson：一旦出現一個 AI 解決不了的問題，你就徹底陷進去了。這個問題不僅會在個人層面出現，也會在團隊層面蔓延。比如我和我的同事 Bob 一起寫代碼，有一塊是 Bob 的專長，我自然會依賴他回答那部分的問題。但如果 Bob 都用 vibe coding 在寫代碼，而他自己也不清楚那部分到底怎么運作，那事情就會變得非常危險。

Will Wilson：如果你希望你的軟件是長期存在、可維護、能持續交付的，那你必須非常警惕這種情況——最后也許沒人知道系統是怎么跑的。還有一個更具體的版本，就是“技術債”——我們都很熟悉。它指的是你寫的代碼“眼下能跑”，但無法擴展、不能復用、將來不好改。

團隊通常會嚴肅地管理技術債，但 AI 的動機跟團隊的不一樣——如果你不小心，它可能在幫你增加理解債的同時，也在瘋狂制造技術債。

開發范式被大模型鎖死在2024

Akshay Shah：完全同意。而且我覺得 AI 還有另一個結構性影響——它會強化行業里的“既得贏家”。

比如你在做一個前端應用，AI 模型在生成 React 代碼方面會比 Svelte 強，這不是因為它“偏好 React”，而是因為它訓練過的 React 代碼實在太多了。這讓我很擔心——未來新技術要怎么推廣？

Will Wilson：這是個特別好的問題。

Akshay Shah：我最近在寫 Zig 語言，發現讓大模型寫 Zig 幾乎不可能。它會生成一些看起來像 Zig、但根本過不了編譯的奇怪代碼。原因很簡單——Zig 太新了，世界上可供學習的 Zig 代碼太少，而且版本變化快。

這不意味著 Zig 不好，雖然有些人覺得它不好，但也有很多聰明人認為它是系統編程的一大進步。但現實是：我現在寫 C 比寫 Zig 還輕松，因為模型在 C 語言上能替我扛掉更多工作。

Chris Pirillo：因為你對 C 足夠熟，能提供更好的上下文。

Akshay Shah：對，一方面是這個，另一方面就是——世界上實在有太多 C 代碼，模型對它的“第一反應”就更準。

Will Wilson：沒錯，所以人們擔心這會造成技術停滯。LLM 就像那個“學不會新花樣的老頑固”，它需要無數示例才能學點新東西。

Akshay Shah：這話有點傷人（笑）。

Will Wilson：哈哈，但這是個真問題。如果我們真的被鎖死在 2024 年的開發范式里，那就糟了。

別讓AI帶頭，一定要讓團隊保持鋒芒

Chris Pirillo：那你覺得該怎么在工程實踐中整合 AI 編碼，才能避免這些問題？

Akshay Shah：這是個好問題。簡單的答案是——“謹慎，并視情況而定”。我現在的做法是：在寫一些新東西、風險較低、或只是探索新思路時，我會讓大模型承擔更多實現層面的工作。這時我會把注意力放在測試和驗證上，因為這樣我能更放心地讓模型寫更多實現代碼。

Will Wilson：我同意。核心是別讓團隊的能力退化。如果一個工程師長期讓 AI 代勞，過幾周不寫代碼，手感就會生疏。語言也是一樣，寫了一年 Python，就會忘了怎么寫 C。這些“問題解決的肌肉”如果不用，就會退化。未來的挑戰是：如何在用好 AI 的同時，讓團隊保持鋒芒。

Chris Pirillo：有觀眾在聊天室留言說：當我 vibe coding 時，我往往會沿著 LLM 給的方向去構建，哪怕那不是最好的思路。因為一旦模型給出答案，我的腦子就被那個答案“固化”了，除非后來被證明錯誤，否則我就會一直沿著那條路走。

Akshay Shah：這其實和人與人協作也很像。正常情況下，我們不會走過去就說“你告訴我該怎么做”。更常見的是對話：我會問，“這里我有哪些選項？”、“有哪幾種可能的做法？”AI 如果被這樣使用——作為一個思路擴展器、方案生成器——其實會很有價值。

Will Wilson：對，我認識的一個最熱衷于 AI 編碼的人說得很好——“我是老板，AI 不是老板。”他說，關鍵是：我先想清楚要怎么做，再讓 AI 去執行。這樣我就能判斷它做得對不對。如果反過來——我讓 AI 帶頭，而我再去判斷它做得對不對，那我就完蛋了。

Akshay Shah：喬布斯說過一句話：“個人電腦是人類思維的自行車。”AI 也一樣——它是一種“智力倍增器”，能讓我們以更快速度、更大范圍去解決問題。但它是一輛自行車，不是一個人。

Chris Pirillo：對，它是工具。你們說的其實讓我想到我自己的體驗——哪怕我不是你們那種技術專家，當我用這些工具時，我得先明確我要什么，再去告訴它“不，這不是我要的，應該是這樣。”這樣最后得到的成果才“完整、正確”。哪怕有缺陷，也比之前更接近目標。

AI時代，新手何去何從？

Chris Pirillo：順便說一句，我沒在假裝喝咖啡（笑）。我手邊真的有兩只杯子，都是無咖啡因的，一只是濃縮的，一只是大杯。別以為我是在做 AI 視頻特效（笑）。

Chris Pirillo：這是真人、真對話、真影響的討論。最后一個問題：你們對剛入行的軟件工程師，有什么建議？

Will Wilson：我有兩個方向建議。第一種：如果你天生喜歡鉆研、善于思考底層機制，那么未來永遠需要這樣的人。不管是 CPU、操作系統、運行時、語言、編譯器……每一層都有極難的問題，AI 暫時都替代不了這些深度開發者。

第二種：掌握足夠的編程技能，但別止步于此。去深挖一個具體領域，比如金融、化工、稅務、能源……成為那個能把軟件與領域結合的專家。未來 AI 會讓這種“跨界專家”的價值大幅提升，因為你能更高效地運用軟件能力深入行業內部。

Akshay Shah：不論你走哪條路，現在都是令人興奮的時代。從第一臺 ENIAC 到現在，也才五十多年。如果你現在剛開始職業生涯，你的一生將覆蓋計算機史的一半。作為技術人，我們的使命就是活在一點點未來里。我相信那個未來更廣闊、更充滿希望。還有什么職業能比這更讓人激動？

Chris Pirillo：沒錯。我來自愛荷華州，好像 ENIAC 最初就在那建造的？

Akshay Shah：沒錯。

Chris Pirillo：從填滿一整間屋子的電腦，到現在手掌里能運行上億倍計算力的設備，真是驚人。未來軟件開發的形態也一樣令人期待。現在已經有人能在手機上“vibe code”，直接寫應用、造組件，這種“技術民主化”的趨勢太棒了。

Akshay Shah：完全同意。

Chris Pirillo：是的，這是一個很積極的結尾（笑）。我希望未來真是這樣。謝謝 Will，謝謝兩位的分享——我真心享受這場對談，即使沒在直播，我也會樂在其中。

Will Wilson：謝謝邀請，這真的很有意思。

Akshay Shah：謝謝。

Chris Pirillo：我只是希望能讓過程更有趣。再次感謝各位的收看。

本文轉載自??51CTO技術棧??，作者：云昭