周末來回一下
首先,姑且不論你一開始的假設就錯了──
你完全不需要把使用指南從頭到尾看完才開始用 Git,
我們就站在你的角度,從審視工具的立場看這件事好了。
一個工具若不想「抽象外溢」,那有個前提──使用方式必須合乎設計用途。
舉例來說,如果一個當代的使用者拿網頁瀏覽器瀏覽網頁,
那他其實不是很需要懂 HTML、HTTP、TCP/IP 或瀏覽器的架構,
他只需要知道網址以及加密的概念,然後看瀏覽器的指引就可以上手,
至於什麼開發者工具更是可能一輩子都沒打開來看過。
然而要是他看到這東西能發起網路連線、能上傳或下載東西,
而且還有個圖形介面,於是就想用瀏覽器從 FTP 伺服器抓東西,
那就要了解目前瀏覽器的運作原理和特性,
否則便無法讓它有這種連線功能,但這樣就抽象外溢了。
現在問題來了, LLM 以及建構在其上的一整套之設計初衷是當開發人員用嗎?
顯然不是,它是為了改善翻譯品質和效率而發展的工具。
人們看到湧現效果後覺得很驚豔,
於是用種種方法調試,讓它變得更有可能產出某些有意義的東西。
只是既然沒按用途使用,那有「抽象外溢」現象,
或者根本是刻意讓抽象外溢,這樣有什麼好令人意外呢?
相對來說,如果你是把人類開發人員當開發人員來用,那這件事情會怎樣處理?
你會變成像 PM 一樣未必要會用 Git,只是跟開發人員說:
「明天 12:00 前部署昨天傍晚 6:00 測的那一版到 UAT 環境」,然後附上版本號碼,
至於用 Git 保管原始碼並取得昨天版本的事情則讓開發人員自己去傷腦筋就好。
這才是真正的「高層次」以及「抽象不外溢」吧?
然而這些事情是始終在預測下一個字的 LLM 堆疊能做到的嗎?
顯然不是,你一定要額外嘗試一些提示內容或套用某些客戶端設定才可能做到,
再不然起碼也要使用專為複雜開發工作設計的 AI Agent 以便套上某些可能符合
個人需求設定,畢竟這東西的核心就是一個根據字詞關聯吐出更多字詞的系統。
它既無法像人類一樣負責,也無法像人類合作或交易那樣──
只要給定投入和產出就可以放手等理想結果,因此你就認了吧!
這就是一套操作介面不固定,產出內容也難事先確定的軟體。
它本就很難控制,而且除非用自動化測試這種多面向的回饋機制供 AI 檢討,
否則用它就像在賭博,只用一點輸入就得到完美輸出時,那就是賭贏了,你會爽歪歪,
但要是賭輸也別意外,只要是賭博哪有可能永遠不輸?
如果不希望變成賭博,那就要準備多面向的回饋機制,
但這樣你就要把手伸進黑箱搞懂裡面的運作原理和特性,那又如何能不抽象外溢?
作者:
yamakazi (大安吳彥祖)
2026-08-09 22:46:00明天十二點前部署….那句話,AI現在就做得到啊怎麼可能做不到,我都不知道叫AI做幾次了我是不知道你的LLM是指什麼,但現在的Claude code幾乎都辦得到你講的那些了更進一步講,AI現在已經比大部分開發人員來還厲害了,加上人類本身也是一個黑盒你怎麼會覺得人類只要給投入,就可以放手等理想結果?你也太相信人類了吧XDClaude code本身就是一個agent,所以不存在什麼要再去用什麼「專為複雜開發工作的AI agent 」,我真的懷疑你有用過嗎?Claude code基本上就是那個專為複雜開發工作的AI agent,其他還有codex,opencode,都是用人類也是賭博,賭博要講勝率和期望值,用AI的勝率比用人類勝率期望值不知道高多少倍了
作者: superpandal 2026-08-09 23:32:00
ai能處理這個問題是因為有人類寫的工具保證 不管是排程還是時間同步 ai如果要自己校對時間 花token不說還可能出錯 話說這問題ai確實也無法做 因為沒確切時間任務完成時間也不能保證
作者:
galic (嘎利)
2026-08-10 12:47:00https://zh.wikipedia.org/zh-tw/抽象泄漏/ 你也是第一個詞就用錯還搞錯意思 整篇直接白寫然後已經2026了還在把LLM當猜下一個字的語言模型 就拿來論證LLM什麼事情都幹不好 幹的比人類差???莫札特也只是在排列震動空氣的音符 沒什麼了不起你可以說他黑盒 但人類也是黑盒 你可以說他有機率性錯誤人類也是會機率性錯誤 今天會考慮這問題只有「承擔後果」拿抽象洩漏來論證要不要學git 是無效論證 因為AI寫出的bug不是靠你用git知識就能修的回來的
作者: superpandal 2026-08-10 18:28:00
當然不會是純猜下一字 但很不同的是 人類是別人對你來講是黑盒 自己對自己來講是黑盒嗎 如果是那也真神奇 個人的技樹可以外加對個人而言自己不是黑盒 不就可以保證產出 就算是他人 一個人相處久了也會熟悉 而ai在進化或在退化你是沒辦法不透過實際操作驗證的對已知變數來說用ai還不如純自動化 如果你懂的技樹能支撐你做好自動化任何時代都不缺異想天開想逆天的人 不屬於自己的力量終究不是自己的
有什麼力量是屬於自己的嗎? 拿拳頭打架才算 拿刀槍不算 用手劈木柴才算 用斧頭砍木柴不算一切不都是工具? 一切也不都是可以黑盒? 這叫做抽象化 以寫程式來說AI跟人類沒什麼不同只差在特性不同能掌握或能測試就沒有什麼問題一間軟體公司今天會因為走了一個比較會寫程式的老鳥來了一個菜鳥就倒了嗎企業能運作就是有架構有框架 而不是在於一個個體員工強不強 軟體工程也是怎樣回 dream的論述基礎也是在LLM是機率性的預測下個token不是設計來寫程式的 那很好笑 人類幾百萬年前出現在地球上也是來當猩猩吃飯打炮的 不是設計來發明原子彈 發明相對論跟當碼農的你對數學跟LLM的理解是不是有些問題? 誰說要永遠不會輸才能用? 偷天換日還是腦筋短路才會這樣想吧 叫你寫程式一口氣寫五百行你會有錯吧 那寫一百行呢?那寫十行一行呢? 一切不都是機率的問題 在這邊偷天換日變成LLM一定不會錯才行 我寫一行正確率99.99%然後重複這動作這樣不行嗎? 你對機率到底有沒有理解?為什麼賭博要不輸?我贏999次輸一次不行嗎?這系統就沒用了?
作者: superpandal 2026-08-13 23:05:00
ai這工具與刀槍性質是不一樣的 你們就是很喜歡拿些不是十分精確的類比說嘴 首先刀槍是買斷的 有人租刀槍嗎 ai除非自己架設否則就不是自己的 別人說停就可以停 再者ai你沒辦法如你所想100%完成你要的任務 本身複雜就是有很多不可控因素 你的力量你沒辦法自己掌控嗎? 比對特性再來類比 不然就是引人發笑的形容 只有不怎麼思考和耳根子弱的人才會被你們說服我說的是公司要掌握能支撐公司的技術 我從沒說過這些技術由一個還是多個人掌握至於樓主講的一個東西該有什麼用途這我不評論 因為選擇權在於人 而能不能有錯誤也是在於人 老闆能不能接受錯誤 而非表達永遠不錯才能用樓主講不確定性 而我講自動化相比ai確定性更高人類寫的排程工具久經驗證也都是確定性更高 看來有人在亂回 haha我發現這類人幾乎都有思考發散的問題 整天講笑 我很好奇他們寫code到底能不能寫好 還是可能因為不能所以才要靠ai...當然這樣的人人品未必就差 但真的蠻多為了贏為了整蠱別人的人
作者:
nashmvp ( )
2026-08-14 07:39:00推討論和推文
作者:
yamakazi (大安吳彥祖)
2026-08-14 10:53:00光是怎樣叫寫code寫得好不好,每個人定義都不盡相同了,懷疑別人寫code寫不好,首先要定義什麼叫好我可以肯定的是,不管你對好的定義是怎樣,AI目前寫的code比99趴的人還好
小知識,台灣軟體工程師的人口占比大約是全人口的 0.5% 左右,所以所謂的比 99% 的人還強的意思是被台灣所有軟體工程師壓著打 w
作者:
yamakazi (大安吳彥祖)
2026-08-14 11:40:00要挑語病喔,那我改一下,AI現在寫得比99趴的軟體工程師還要好
就算是業界評價最高的 Fable 我也是三不五時在 review code 的時候揪到一些爛結構、過度設計、邏輯溢出,Agent 就像個非常努力但不會反思的 junior 一樣埋頭苦幹,如果收斂順利還好、不順利 git 的紀錄看上去就會很精彩。只要 AI 那種頭痛醫頭腳痛醫腳的毛病還根深柢固我就不覺得程式碼品質能進從業人員的前5%,我自己都不敢說能進前5%了;AI 的優勢終究在它就算撞了五次牆才做好也比我一次寫完快 ww
作者:
yamakazi (大安吳彥祖)
2026-08-14 14:01:00爛不爛就跟我前面講的一樣,每個人定義不同,沒有PR看很難評論甚至你講的那些問題,交給另一個subagent去review應該也能看出,看得又快又好架構歸架構,coding歸coding,如果你要他架構好就是要用superpower,不然他只能猜測
作者: superpandal 2026-08-14 20:16:00
你要這樣算還可以再細分 不只每個人 每個時機 每個場合 每個職位 什麼叫好code字裡行間已經點出了 不就是我做出的定義...我還需要定義什麼?更詳盡? 一個人對某事物的評價與衡量不就是對該事物的定義... 至於superpowers我不看好
作者:
yamakazi (大安吳彥祖)
2026-08-14 23:40:00你是用過後不看好?還是壓根沒用過?
作者: superpandal 2026-08-15 04:08:00
這東西主要還是用skill skill我看過 很傻 寫那團我不如用模板 因為看來很傻所以當然是沒用過superpowers
作者:
yamakazi (大安吳彥祖)
2026-08-15 07:27:00所以只是單純看過沒用過,了解了XD
用過評論一下:brainstorming 還好。到生成spec的時候只會生一堆沒人想看的垃圾。夠精準,但review那個跟review code的差別在哪?我還不如叫他跑完後再review code。最後生成的品質也是一言難盡,還不是一堆地方要改。我覺得還不如就接受llm生成就是不確定的,spec生出來後請他直接實作,我review再細修比較省時間也比較省token。
其實要生成到那個「規格文件沒有問題」本身就已經是撞牆的過程了,我讓 AI 幫我寫 AI TRPG 用的行為循環時撞了不知道幾次牆,到最後我乾脆叫它去研究 github上的競品 XD那個「好的規格文件」其實差不多就已經很接近某種虛擬碼了當然還有一種情況是用 AI 處理的已經是某種有大量範本的常見工作,這種工作 AI 就能做的又快又好,但小眾需求基本上很難不撞牆
作者: superpandal 2026-08-15 18:39:00
不然我要繼續研究那團東西嗎 指令和腳本能做的事情比想像多很多 能開發也能管理
作者:
galic (嘎利)
2026-08-15 21:02:00不愧是腳本哥 用腳本走過整個開發宇宙的人你的作業系統也是腳本嗎 你的AI也是腳本嗎 還是你的電腦也是用腳本兜的? 什麼時候要展示一下?阿!我可能誤會了 這個留言也只是腳本寫的