![]()
一個人開發Android應用,從蹲在馬桶上冒出的想法,到代碼合并進主分支自動發布,中間要經歷多少步驟?這位開發者數了數:打開IDE、寫需求文檔、建GitHub工單、規劃實現方案、編碼、跑測試、修bug、發版——每一步都是摩擦,每一步都可能讓那個靈感爛在待辦清單里。
他用LLM(大語言模型)把摩擦系數降到了接近零。不是用市面上那些"智能體框架",而是自己焊了一套流水線:Telegram聊天窗口當入口,Docker容器當工人,CI/CD當質檢員。整個流程跑通后,他從動念頭到功能上線,手指幾乎不用碰代碼庫。
這聽起來像極客炫技,但他自己說得很實在:「我就是那種會花半天寫腳本、只為省3分鐘重復勞動的瘋子。」現在有了LLM,連寫腳本這半天都省了。
第一階段:從瀏覽器到IDE的往返跑
他的AI輔助開發史,起點相當狼狽。最早是開著ChatGPT網頁版,把IDE里的代碼復制粘貼進去,問怎么修bug,再把答案粘回來。數據庫結構也要手動貼進去,才能讓模型生成SQL。
「像動物一樣,」他這樣形容。但這段狼狽期讓他確認了一件事:LLM能把他從「教程地獄」里撈出來。以前卡在某個愚蠢的報錯上,可能耗掉一整天翻Stack Overflow;現在直接問,幾分鐘就能繼續推進。
當時他正在做一個寵物項目:Android客戶端配Golang后端。核心代碼還是手寫,「精釀啤酒和精釀披薩催生的手工代碼」。但填充重復樣板時,他開始讓ChatGPT代勞——畢竟沒人喜歡把同一個模式寫第十遍。
那是Claude Code出現之前的日子。IDE里的AI插件只會 inline 補全,沒法真正「操作」代碼。體驗很糟,復制粘貼來回跳,但總比手寫boilerplate強。
第二階段:給LLM發員工工牌
![]()
轉折點是他意識到一件事:LLM不該只是「高級自動補全」,而該是個能執行完整任務的代理。他開始重新設計交互方式——不是問「這段代碼怎么寫」,而是說「我要這個功能,你去搞定」。
具體實現上,他選了Telegram當入口。理由很個人化:手機常駐、通知及時、支持長文本和代碼塊。蹲在廁所時冒出的產品靈感,當場就能發出去,不用等回到電腦前。
Telegram消息觸發后,后端服務會做幾件事:把模糊的自然語言需求,結構化成一個GitHub issue;同時生成實現方案的技術草案。這一步用到了他反復調教的prompt模板,確保輸出格式穩定、可被下游消費。
GitHub issue創建后,真正的自動化才開始。一個預裝了開發環境的Docker鏡像被拉起,里面跑著定制化的「開發者代理」。這個代理會讀取issue,規劃代碼變更,實施修改,跑測試套件,甚至做自我審查。
質量門禁是硬性的:測試必須全綠,lint不能報錯,CI構建必須成功。全部通過才會自動合并到主分支,觸發發版流程。
他特意把「發版」稱為無聊的部分——因為一旦前面 pipeline 跑通,最后推送到應用商店只是機械動作。真正花心思的,是讓前面每一步都可靠。
為什么不用現成的「智能體框架」
市面上不是沒有類似方案。一些產品主打「輸入prompt,自動拆解成看板任務,并行開多個worktree開發,再用某框架生成技術規格書」。他試過,不滿意。
核心問題是通用性陷阱。這些框架用同一套方法論對付TypeScript后端、React前端、原生移動和GoLang——燒掉大量token,產出卻平庸。不同技術棧的痛點完全不同:Android要處理版本號和商店審核,Go項目關心模塊依賴,前端糾結構建產物體積。統一框架只能給平均答案,而平均答案對具體項目往往是錯的。
![]()
他的自建系統則深度綁定自己的技術棧。Docker鏡像里預裝了Android SDK、Go工具鏈、特定的lint規則集。Telegram的prompt模板針對他的產品領域調教過,生成的GitHub issue包含他團隊慣用的標簽和字段。整個 pipeline 是「毛刺」的,但毛刺對準了他的實際痛點。
一個細節:代理輸出的bash日志里,LLM會自動插入可愛的Unicode圖標。這沒什么實用價值,但他喜歡。這種個人趣味在通用產品里很難保留。
從「輔助」到「外包」的心態遷移
他把這個過程稱為「AI增強開發的成熟化」。早期是工具層面的——用LLM加速某個環節。現在變成流程層面的——把完整工作流委托給系統,人只在關鍵節點介入。
這種遷移需要信任積累。他花了大量時間調整質量門禁的敏感度:太松會合并垃圾代碼,太緊則頻繁卡死需要人工解救。測試覆蓋率、lint規則、CI超時閾值,這些參數沒有通用最優解,只能在自己的代碼庫上試錯。
目前的版本他仍在迭代。Telegram的交互還可以更流暢,Docker鏡像的啟動速度還能優化,代理處理復雜重構時的規劃能力也有提升空間。但核心循環已經跑通:想法→結構化需求→自動實現→自動驗證→自動發布。
他提到一個具體場景:以前發Android版本前,必須記得手動改版本號。否則CI跑完構建、測試、lint,推到商店最后一步才報錯拒絕,還不會主動通知。這種「差點就忘了」的焦慮,現在完全消除——版本號檢查寫進了 pipeline 的硬性前置條件。
這就是他所說的「itch」(癢點)。不是省下的那幾分鐘,而是心理負擔的解除。自動化最大的回報從來不是時間,而是認知資源的釋放。
這套系統會取代程序員嗎?他的態度很務實:「你可能想直接跳到最后一章,但那樣會錯過重點。」重點不是某個終局狀態,而是這個漸進馴化LLM的過程——從瀏覽器里的聊天對象,到IDE里的補全插件,再到能獨立完成閉環任務的代理。每一步都建立在對工具邊界的清醒認知上。
下一步他打算讓Telegram支持語音輸入,這樣連打字都省了。但那個蹲在廁所里、對著手機喃喃自語說出產品需求的畫面,究竟是更高效的工作方式,還是另一種形式的異化——這個問題,他留給了讀者自己判斷。
特別聲明:以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布,本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.