一個(gè)Android開發(fā)者每天花多少時(shí)間在"非編碼"事務(wù)上？版本號檢查、CI配置、合并前的代碼審查——這些瑣事像洗碗一樣必要，又像洗碗一樣讓人想逃避?，F(xiàn)在有人用LLM（大語言模型）搭了一條流水線：蹲在馬桶上聊幾句Telegram，回來代碼已經(jīng)合并到主分支。

這不是某個(gè)創(chuàng)業(yè)公司的PR稿，是一個(gè)叫hotspot-4的開發(fā)者在自己博客曬出的個(gè)人工作流。從"對著ChatGPT復(fù)制粘貼"到"全自動 toilet-to-prod（馬桶到生產(chǎn)環(huán)境）"，他花了多長時(shí)間迭代？答案可能會讓還在手動調(diào)CI的你感到一絲荒唐。

階段一：從"動物式復(fù)制粘貼"到發(fā)現(xiàn)新大陸

和所有2013年的開發(fā)者一樣，他最初的使用方式堪稱原始：把IDE里的代碼復(fù)制到瀏覽器對話框，讓ChatGPT修bug或生成SQL，再復(fù)制回來。數(shù)據(jù)庫表結(jié)構(gòu)要手動貼進(jìn)去，上下文全靠打字描述。

但即便如此，這種交互已經(jīng)讓他擺脫了"教程地獄"——以前為了改一個(gè)函數(shù)，要在Stack Overflow翻十幾篇帖子，現(xiàn)在幾分鐘搞定。他形容這是"發(fā)現(xiàn)了工具的力量"，盡管當(dāng)時(shí)的體驗(yàn)"像動物一樣"笨拙。

他當(dāng)時(shí)的項(xiàng)目是一個(gè)寵物Android應(yīng)用，配Golang后端。核心代碼還是手寫，"精釀啤酒和精釀披薩澆灌出來的手工代碼"。但遇到重復(fù)模板時(shí)，他開始讓ChatGPT代勞——畢竟"討厭寫重復(fù)代碼"是他過度工程化的根源。

那時(shí)Claude Code還沒出現(xiàn)，IDE里的AI插件只能做行內(nèi)補(bǔ)全，遠(yuǎn)談不上"與代碼交互"。復(fù)制粘貼的體驗(yàn)很差，但已經(jīng)夠用了。

階段二：Docker里的"規(guī)劃-實(shí)現(xiàn)-審查"閉環(huán)

真正的轉(zhuǎn)折點(diǎn)是他不再滿足于"生成代碼片段"，而是想要一個(gè)完整的開發(fā)閉環(huán)。他造了一個(gè)Docker鏡像，里面跑的不是簡單的代碼生成，而是分階段的工作流：規(guī)劃變更→實(shí)現(xiàn)代碼→運(yùn)行審查→質(zhì)量門檢測→自動合并。

這個(gè)設(shè)計(jì)的狠之處在于：LLM不再只是"寫代碼的實(shí)習(xí)生"，而是被嵌入到工程流程的每個(gè)環(huán)節(jié)。規(guī)劃階段輸出技術(shù)方案，實(shí)現(xiàn)階段寫具體代碼，審查階段自己給自己找茬，最后CI通過才放行。

他承認(rèn)市面上已有現(xiàn)成的Agent系統(tǒng)——那種"輸入提示詞就自動在看板排期、用worktree并行開發(fā)、拿markdown文件當(dāng)框架"的工具。他試過，不喜歡。理由是：它們燒token燒得太兇，卻給所有項(xiàng)目喂同一套方案，不管是TypeScript后端、React前端還是原生移動端，" bold name for a markdown file（給markdown文件起個(gè)浮夸名字就叫框架）"。

換句話說，通用等于平庸。他的Android+Golang組合有特定節(jié)奏，需要定制。

階段三：Telegram成為需求入口的魔幻現(xiàn)實(shí)

最騷的操作是把Telegram聊天作為整個(gè)流程的起點(diǎn)。不是Slack，不是Discord，是Telegram——因?yàn)槭謾C(jī)常駐、通知可靠、語音輸入方便。

場景是這樣的：他在馬桶上想到一個(gè)功能，對著手機(jī)說幾句，Telegram bot幫他整理成結(jié)構(gòu)化需求，自動轉(zhuǎn)成GitHub issue。Docker里的LLM agent讀到issue，開始執(zhí)行規(guī)劃-實(shí)現(xiàn)-審查-合并的循環(huán)。CI最后推一個(gè)新版本到應(yīng)用商店。

整個(gè)過程他" unhealthy amount of fun（不健康地樂在其中）"，到現(xiàn)在還在微調(diào)。那些他以前寧愿花半天寫腳本、只為省3分鐘或省點(diǎn)腦力的"怪癖"，現(xiàn)在LLM替他干了，還附帶"可愛的Unicode圖標(biāo)"在bash消息里。

他特別提到一個(gè)具體痛點(diǎn)：以前發(fā)Android版本時(shí)，版本號如果沒提前 bump（遞增），CI跑完構(gòu)建、測試、lint、推送到商店，最后一步部署失敗，還不會通知他。現(xiàn)在這條流水線把版本檢查也包了進(jìn)去。

為什么他不買現(xiàn)成的？

這個(gè)選擇本身就有產(chǎn)品經(jīng)理思維。他拆解了現(xiàn)有Agent系統(tǒng)的成本結(jié)構(gòu)：token消耗是顯性成本，"通用體驗(yàn)"是隱性成本——為所有技術(shù)棧做妥協(xié)，意味著對任何特定棧都不夠好。

他的Android+Golang組合有明確的邊界：Kotlin協(xié)程、Jetpack Compose、Gin框架、特定的CI配置。自建系統(tǒng)可以把LLM的上下文窗口全砸在這些細(xì)節(jié)上，而不是浪費(fèi)在"如何同時(shí)討好React和Vue開發(fā)者"的抽象層上。

另一個(gè)細(xì)節(jié)：他堅(jiān)持用GitHub issue作為中間態(tài)，而不是直接讓LLM操作代碼庫。這是留給人介入的斷點(diǎn)，也是工程紀(jì)律的體現(xiàn)——需求需要被顯式記錄，而不是消失在某個(gè)對話線程里。

他博客的標(biāo)題叫"My Toilet-to-Prod Pipeline"，toilet不是隱喻，是字面意思。這種自嘲式的命名風(fēng)格，和他在Telegram里用語音輸入需求的隨意感，形成了一種奇怪的和諧：最嚴(yán)肅的工程自動化，從最不嚴(yán)肅的入口啟動。

他還在迭代這個(gè)系統(tǒng)。下一步是什么？他沒說。但一個(gè)能把"洗碗級瑣事"自動化到這種程度的人，清單上應(yīng)該還有別的 itch（癢點(diǎn)）等著被撓。