一個人開發(fā)Android應用，從蹲在馬桶上冒出的想法，到代碼合并進主分支自動發(fā)布，中間要經(jīng)歷多少步驟？這位開發(fā)者數(shù)了數(shù)：打開IDE、寫需求文檔、建GitHub工單、規(guī)劃實現(xiàn)方案、編碼、跑測試、修bug、發(fā)版——每一步都是摩擦，每一步都可能讓那個靈感爛在待辦清單里。

他用LLM（大語言模型）把摩擦系數(shù)降到了接近零。不是用市面上那些"智能體框架"，而是自己焊了一套流水線：Telegram聊天窗口當入口，Docker容器當工人，CI/CD當質檢員。整個流程跑通后，他從動念頭到功能上線，手指幾乎不用碰代碼庫。

這聽起來像極客炫技，但他自己說得很實在：「我就是那種會花半天寫腳本、只為省3分鐘重復勞動的瘋子?！宫F(xiàn)在有了LLM，連寫腳本這半天都省了。

第一階段：從瀏覽器到IDE的往返跑

他的AI輔助開發(fā)史，起點相當狼狽。最早是開著ChatGPT網(wǎng)頁版，把IDE里的代碼復制粘貼進去，問怎么修bug，再把答案粘回來。數(shù)據(jù)庫結構也要手動貼進去，才能讓模型生成SQL。

「像動物一樣，」他這樣形容。但這段狼狽期讓他確認了一件事：LLM能把他從「教程地獄」里撈出來。以前卡在某個愚蠢的報錯上，可能耗掉一整天翻Stack Overflow；現(xiàn)在直接問，幾分鐘就能繼續(xù)推進。

當時他正在做一個寵物項目：Android客戶端配Golang后端。核心代碼還是手寫，「精釀啤酒和精釀披薩催生的手工代碼」。但填充重復樣板時，他開始讓ChatGPT代勞——畢竟沒人喜歡把同一個模式寫第十遍。

那是Claude Code出現(xiàn)之前的日子。IDE里的AI插件只會 inline 補全，沒法真正「操作」代碼。體驗很糟，復制粘貼來回跳，但總比手寫boilerplate強。

第二階段：給LLM發(fā)員工工牌

轉折點是他意識到一件事：LLM不該只是「高級自動補全」，而該是個能執(zhí)行完整任務的代理。他開始重新設計交互方式——不是問「這段代碼怎么寫」，而是說「我要這個功能，你去搞定」。

具體實現(xiàn)上，他選了Telegram當入口。理由很個人化：手機常駐、通知及時、支持長文本和代碼塊。蹲在廁所時冒出的產品靈感，當場就能發(fā)出去，不用等回到電腦前。

Telegram消息觸發(fā)后，后端服務會做幾件事：把模糊的自然語言需求，結構化成一個GitHub issue；同時生成實現(xiàn)方案的技術草案。這一步用到了他反復調教的prompt模板，確保輸出格式穩(wěn)定、可被下游消費。

GitHub issue創(chuàng)建后，真正的自動化才開始。一個預裝了開發(fā)環(huán)境的Docker鏡像被拉起，里面跑著定制化的「開發(fā)者代理」。這個代理會讀取issue，規(guī)劃代碼變更，實施修改，跑測試套件，甚至做自我審查。

質量門禁是硬性的：測試必須全綠，lint不能報錯，CI構建必須成功。全部通過才會自動合并到主分支，觸發(fā)發(fā)版流程。

他特意把「發(fā)版」稱為無聊的部分——因為一旦前面 pipeline 跑通，最后推送到應用商店只是機械動作。真正花心思的，是讓前面每一步都可靠。

為什么不用現(xiàn)成的「智能體框架」

市面上不是沒有類似方案。一些產品主打「輸入prompt，自動拆解成看板任務，并行開多個worktree開發(fā)，再用某框架生成技術規(guī)格書」。他試過，不滿意。

核心問題是通用性陷阱。這些框架用同一套方法論對付TypeScript后端、React前端、原生移動和GoLang——燒掉大量token，產出卻平庸。不同技術棧的痛點完全不同：Android要處理版本號和商店審核，Go項目關心模塊依賴，前端糾結構建產物體積。統(tǒng)一框架只能給平均答案，而平均答案對具體項目往往是錯的。

他的自建系統(tǒng)則深度綁定自己的技術棧。Docker鏡像里預裝了Android SDK、Go工具鏈、特定的lint規(guī)則集。Telegram的prompt模板針對他的產品領域調教過，生成的GitHub issue包含他團隊慣用的標簽和字段。整個 pipeline 是「毛刺」的，但毛刺對準了他的實際痛點。

一個細節(jié)：代理輸出的bash日志里，LLM會自動插入可愛的Unicode圖標。這沒什么實用價值，但他喜歡。這種個人趣味在通用產品里很難保留。

從「輔助」到「外包」的心態(tài)遷移

他把這個過程稱為「AI增強開發(fā)的成熟化」。早期是工具層面的——用LLM加速某個環(huán)節(jié)?，F(xiàn)在變成流程層面的——把完整工作流委托給系統(tǒng)，人只在關鍵節(jié)點介入。

這種遷移需要信任積累。他花了大量時間調整質量門禁的敏感度：太松會合并垃圾代碼，太緊則頻繁卡死需要人工解救。測試覆蓋率、lint規(guī)則、CI超時閾值，這些參數(shù)沒有通用最優(yōu)解，只能在自己的代碼庫上試錯。

目前的版本他仍在迭代。Telegram的交互還可以更流暢，Docker鏡像的啟動速度還能優(yōu)化，代理處理復雜重構時的規(guī)劃能力也有提升空間。但核心循環(huán)已經(jīng)跑通：想法→結構化需求→自動實現(xiàn)→自動驗證→自動發(fā)布。

他提到一個具體場景：以前發(fā)Android版本前，必須記得手動改版本號。否則CI跑完構建、測試、lint，推到商店最后一步才報錯拒絕，還不會主動通知。這種「差點就忘了」的焦慮，現(xiàn)在完全消除——版本號檢查寫進了 pipeline 的硬性前置條件。

這就是他所說的「itch」（癢點）。不是省下的那幾分鐘，而是心理負擔的解除。自動化最大的回報從來不是時間，而是認知資源的釋放。

這套系統(tǒng)會取代程序員嗎？他的態(tài)度很務實：「你可能想直接跳到最后一章，但那樣會錯過重點。」重點不是某個終局狀態(tài)，而是這個漸進馴化LLM的過程——從瀏覽器里的聊天對象，到IDE里的補全插件，再到能獨立完成閉環(huán)任務的代理。每一步都建立在對工具邊界的清醒認知上。

下一步他打算讓Telegram支持語音輸入，這樣連打字都省了。但那個蹲在廁所里、對著手機喃喃自語說出產品需求的畫面，究竟是更高效的工作方式，還是另一種形式的異化——這個問題，他留給了讀者自己判斷。