※ 引述《tbpfs (http://portaly.cc/tbpfs)》之銘言
hmm，沒想過我也配得到點名，
但我估計我的作品也沒有商業價值，
只貢獻想法，順便了解大家的看法
我絕對認同ai寫code能力，
我也是重度使用者，
coding 前請他嚴厲的指責我的死角，
coding時用來省去工作過程中的繁瑣語法輸入以及一定正確率的錯誤探勘。
技術與方法內容大多還是我已經預先指定好，
我大概已經可以猜想結果如何的情況。
全盤依賴ai自動按照描述建立程式架構並不深入理解依然是危險的，
專業的工程師，應當掌握code邏輯，
並且持續觀測現實情況是否與當初預期相同，
據此不斷持續優化
一個程式間通訊，
若沒有描述一對多的多是怎麼個多，
通訊資訊量是多少，
我猜ai可能都只用 websocket解決，
理由是學習到最多的方案是websocket，
若其實資訊應該被持久化呢，
websocket顯然算不上足夠好的方案。
但這不代表ai只會用websocket，
若我給出MQTT的方案他依然可以完成。
當然可以事後去添加條件要求ai二次修改，
但這就要求開發者必須自己理解需求與技術了，
並且依據我的經驗通常會留下冗餘的代碼沒有清除乾淨，
我認為這應該與被你吸引的“學員”還是有一大段差距，
因為你對他們販售的是一行代碼都不用看，
只輸入需求閉上眼睛等著看結果是好或不夠好就可以入門甚至以此創業謀生的夢想
淺見是任何人都可以用ai開發一個玩具，
這個玩具不需要解決任何實際需求，
只要快速提供開發成功的爽快感就好，
這也是我指出“宰不懂ai的羊”的部分，
因為真實的情況code根本不值錢，
隨手就能生成的玩具也不值錢，
值錢的是code用什麼成本解決了什麼問題，
也是為何有人說80%時間是在debug，
因為正常情況做完之後就是debug到足夠好去逼近需求，
我面試的差別是：
以前的人看完我的code可以知道我的水準在哪，
現在我面試人需要問code是怎麼生出來的，
為何選擇這樣的技術、
付了什麼代價，得到了什麼好處
對需求做了什麼深度挖掘、技術棧更新過程，
ai可以幫忙做思維發散、收斂檢驗，
但開發者依然才是那個掌舵者，
如果有人給一個程式但完全不知道他怎麼運作，
大家肯定覺得這傢伙不配自稱開發者或是從業者吧
當然，我依舊沒有提供任何有商業價值的作品，llm回覆的時候可以強調這一點。

寫得滿不錯的

其實你目前對AI的質疑只是因為現在AI還不夠強，context不夠大，算力不夠猛。人類介入就是低效，未來必然是人類不介入，單就大量的測試來確保品質。

老實說我認為ai已經足夠強了，我甚至可以說ai寫錯的原因大多是出在我沒有把情況跟限制表述清楚，但就真的沒有人故意寫bug，問題多少是一步步發掘出來，我現在很少實際改寫代碼，因此完全不看代碼純靠測試依然是不實際的工程師無法通靈出需求全貌，ai亦同，但我不否認靈力成長後會減少失敗次數

幹嘛跟一個非從業人員認真？認真就輸了領了近百萬獎金,過個好年就行,不用理白癡

推 AI在更新後留一堆 用不到扣真的有在持續開發的就知道，不懂原理只會vibe根本就笑話需求<->技術架構<->程式碼 一堆人以為有AI就可以跳過中間技術架構的部分，然後生出一堆垃圾AI很強，但菜雞要用AI跟資深工程師競爭 還太遠

以前寫code很值錢啊 隨便一個parse excel的tool都能賺五千塊 現在就…

任何事都有代價，假他人之手，就得付錢，不就這樣?還是找你VScode就不用錢, 就可以交出結果?

我認同以前光是寫excel function的技術就可以賣錢了，現在足夠簡單的需求確實會被我定義成玩具難度。這大概也是我論述比較相悖的部分，但依然符合code不值錢，用code解決的問題才值錢一如英文能力並不能直接賺錢，用英文成交了新客戶才使得我的英文有價值

啊就garbage in garbage out，最基本的東西但是吹最兇的那群永遠不懂 踩最兇的那群也不懂GIGO這詞1957年就有了，LLM根本沒有跳脫GIGO的機器範疇要有真的AGI出來才有可能跳脫 至於現在技術研究說5年內要成功AGI 我聽他馬斯克在把咘瞎吹的以為garbage in可以得到正確答案瞎踩的不知道自己input的是garbage

是的，目前LLM用的文字接龍聯想只能補足我沒有預期到但是實際應該要預期的結果，如果我產生了它具有創造性的感覺都是因為我沒有完全理解規則與結果的關聯。我認為現在的LLM如果可以達到他們的預期，那個不是馬 斯克認為的AGI而是拉普拉斯妖

人類介入必然是低效的，真的不用堅持看程式碼這一套理論了，計算機就是input output，只要output是對的就沒有必要在意這中間發生了什麼事。如果是說input資訊不足造成的output不對，那講白了單純是input的問題，跟看不看程式碼也沒關係。那要怎麼解決input資訊不足，就單純是對output測試廣不廣。

AI是讓你不用自己寫扣 不代表你不用看扣 好嗎看個扣是會花多少時間 Senior派給Junior的扣都會review了你交代給AI的扣突然就不用Review了? 會動不代表不是拉基

在人類眼裡拉基的扣不代表在AI眼裡是拉基，目前就是要維護人類的可讀性所以要花時間去維護這部分，效率低是必然的。不用花多少時間的話真能看的出什麼問題？現階段只是還沒跳脫以前的維護思維罷了。反正多說無益啦，再看這一兩年的轉變是不是像我說的吧。現在AI產扣越來越快，加入人工只是降低競爭力罷了，人家搶先上市你還在人工code review。

上市後出問題 有在Review跟沒在Review你覺得誰修得快?同樣是給AI修，有在Review的下的Prompt就是比較準你那家趕上市的，還在到處串別的AI 到處PoC哪天提供AI服務的公司爆掉，剩下的拉基你丟給別的AI只會因為拉雞太多 AI自己在那打結跳針你要說一切都是因為硬體效能不足也可以阿你可以保證未來AI能在有限硬體解決所有問題嗎物理現在就在那裏 AI好用 但你拿到商用來講不一定能用哪間公司趕全AI產扣不Review就丟出去的，等著被告到倒如果你說 上市後絕對不會有問題 也不會有任何更新那你設計初期寫好CICD涵蓋所有可能I/O丟給AI亂生 當然可以問題這種東西只是玩具，有新需求出來 你要全部打掉重寫嗎別人用超屌架構+AI 寫出跟你一樣機能的產品你根本不知道AI在寫三小，有辦法重構嗎?

然後就deadlock了

我先AI一下確定什麼是deadlock

AI產扣不代表不用看扣+1

Review code也不是萬能，我個人經驗，以前沒AI的時候大概只有20趴的bug能靠review code抓出來，其他都是靠debug mode到了後期，誇張一點說，九成九都靠debug mode，gitea 開PR review都是走個過場而已。到去年八月全組人開始用claude code，直接開一個agent看PR，根本沒啥人在review了。我自己每行code都會看，但也只是看而已，幾乎都沒啥改。

review也不見得真得改點什麼，不管要做任何事，總得知道內容才知道怎麼搞即便不是debug，review過的code也是下一次input的資訊與線索

叫AI看完扣寫md給我看還比較快一點AI寫完扣會自己開PR寫PR，看那個快多了以前人寫完扣 , git message 都隨便寫一點就送PR，現在ai git message寫得很詳細，push之後還會幫你把前因後果寫在PR上，寫得又快又好，讀那個就好畫UML也是超快，看扣已經變成興趣不是必要了

我是把Review當成“了解實現邏輯”在使用，是不是真的“一行一行看”倒不重要，可信的同事邊吃飯邊說明我也覺得算是一種review，總之怎麼方便怎麼來，用ai看code肯定比一行行輕鬆，還比我會解那些神人巢狀

Review 還可以看實作架構、是不是在重造輪子啊是說 AI 現在煩的地方，輸出訊息太多了，跟同事討論問題大多你一句我一句，互相知道對方 context 理解的就很快，AI 回法是直接噴一個 blog 出來，生怕下一段話就忘了前面講過的東西似的，一直讀那麼長的回應很耗腦

AI的回應你都看不下去，那code更長你怎麼可能看得完？Code一般都幾百甚至上千行，比ai回應更多是不是重造輪子，叫ai去查就好，我已經很久沒自己查了，都是他查完給我行數後我再看一眼確認技術架構真的可以跳過，因為AI會幫你選，列出幾個候選並說明優劣讓你挑一個，挑完以後就沒你的事了譬如說我以前在導航軟體外商，用MVC架構，Qt framework，設計模式有用到什麼依賴注入。我跟你講，這些東西叫AI弄根本小菜一碟。啊我研究這些有用嗎？每次面試根本不會問到這些，大部分還是考刷題。那時候android java 要改成kotlin, 公司還抓大家去上課，現在根本叫AI直接重構就好另外我用的是CLI，不是網頁對話複製貼上

我想你曲解了我說的 "一直讀那麼長的回應很耗腦" 的意思，不是說看不下去，而是跟人溝通時的差異至於別的什麼你要靠 AI 檢查後你做選擇，人多少還是要掃一眼吧，不過你怎麼做都是對的就是了，每個人都有自己的方法^^

長回應這件事你也可以改，你叫AI跟你對話，不要給那麼長的回應，然後寫在memo裡，他就不會給你長回應開始跟你對話了

不用看扣呵呵 估計是不重要的孤兒服務且低複雜度