先日,我參加了 Zenn 的「第3回 AI Agent Hackathon with Google Cloud」,使用 Flutter 在三週內成功部署了一個應用程式「Vegitage」。
今天,我不打算談這個應用程式本身。
我想談談在這個開發過程中,我親身體驗的「編程行為的根本變化」,這可能會有點激烈,但我想如實分享我的感受。
結論是,過去的編程教育所奉為圭臬的「從基礎開始的累積學習」,不僅過時了,還可能成為扼殺才能的「詛咒」。
我擅長「設計」。
當我想要製作一個傳統蔬菜辭典時,透過與 AI 的對話,關於伺服器架構、數據管道和可持續商業模式等想法源源不斷湧出,描繪整個應用的架構對我來說是一件非常愉快的事情。
然而,同時我身上也存在一個大問題。
「記憶」這道牆。
首先,Flutter 擁有的數百、數千種 Widget 的名稱和用法。
我完全記不住。
Container
, Column
, Row
, Stack
, ListView
, GridView
, Card
, ListTile
...
每當我嘗試佈局時,「嗯,要把它居中,需要用哪個 Widget 圍住呢?」「排列成一行的是... Row
嗎?」我的手就會停下來。
而且,那些更複雜的「作法」在等待著我。
Riverpod 那些難解的 Provider 類型和命名規則?
build_runner
所需的那一套代碼生成儀式?
part '...g.dart';
或錯誤使用 extends _$ClassName
時,我都會向 AI 嚷著「哪裡出錯了?」。我之前已經在業餘時間寫過程式,也能製作出可執行的東西,但這花費了大量的時間。
在文檔和樣例代碼的海洋中徘徊,製作一個畫面可能花上幾天並不是稀罕事。
在我腦海中的「設計圖」和實際運行的「代碼」之間,總是矗立著一道高高而厚重的「記憶之牆」。
這次開發的合作夥伴是 AI。
我將我所描繪的設計圖用自然語言告訴 AI。
我: 「這個詳細頁面,即使向上滾動,標題也要保持可見。圖像則要隨著滾動而消失。」
AI: 「明白了。如果這樣,那麼使用 CustomScrollView
和 SliverAppBar
是最佳選擇。設置 AppBar
的 title
,並將圖像 Widget 放在 flexibleSpace
中。這是那段代碼。」
我甚至不知道 SliverAppBar
這個 Widget 的存在。
然而,AI 將我的「需求」翻譯成最適合的「Widget」。
AI 對我來說是擁有無限容量的「外部記憶裝置」,也是最佳的「實現夥伴」。
多虧了 AI,我無需再意識到苦手的「記憶之牆」,可以將所有時間都專注在擅長的「設計思考」上。
這次開發的合作夥伴是 AI。
我將我所描繪的設計圖用自然語言告訴 AI。
我: 「這個詳細頁面,當只有一張圖片時和多張圖片時,顯示需要分開。我不想讓使用者困惑。」
AI: 「明白了。那麼,可以使用 StatefulWidget
,在 initState
中先獲取圖片信息,根據結果在 build
方法中切換要顯示的 Widget。這是那段代碼。」
我對 Flutter 的語法幾乎一無所知,StatefulWidget
的生命週期也只是模糊的了解。
然而,應用的「設計理念」在我心中是完美存在的。
AI 將這些理念毫無偏差地翻譯成代碼,成為最佳的「語法補全工具」和「實現夥伴」。
得益於 AI,我完全擺脫了苦手的「逐步、程序化的工作」,可以專注於擅長的「概念性、設計性的思考」。
這次體驗為編程的學習方法提供了重大的啟示。
過去的學習是「語法→算法→設計」的金字塔。
然而,在 AI 時代,這個金字塔會顛倒過來。
未來,確實會有「只寫中級代碼的人」的工作消失。
因為這些工作是 AI 最擅長的領域。
但不必悲觀。
AI 並不是要奪走我們的工作。
AI 是在解放那些因為「對語法不擅長」而放棄創造性設計舞台的無數人們。
如果您擁有絕佳的應用想法,但因為「編程基礎…」而無法踏出第一步,
如果您因日常的編碼工作而陷入困境,開始懷疑「我為何要做這個?」的熱情,
放心吧。首先,從設計開始。
將您的最佳想法告訴 AI。
相信 AI 定能以您未曾想過的方式,協助您實現這些想法。
就像71歲的我做到了,您當然也能做到。
直播演示: https://aiseed.page/
專案連結:
技術棧: