Re: [討論] 寫程式的追求?
: → qwer338859: 跟stackoverflow差多了好嗎 前者看完還要自己寫 ai 05/05 15:44: → qwer338859: 直接把所有功能做完還寫測試 05/05 15:44
OK,你說得很有道理,AI 會產測試。
假設你要實作的邏輯不複雜,不罕見,
因此 AI 可以讓你用少少的口語產出字數更多的程式碼及測試好了,
那我就想問,是什麼樣的測試程式?
姑且不論常常被忽略的非用途面驗證好了,光是用途面的驗證就有很多種。
程序內部有單元測試,程序外部有自己的功能測試。
這還可以視情況在測試過程中直接向資料來源查詢資料真偽。
許多業務要運用多個系統協力完成,
因此往往要從業務的角度聯合多個系統一起跑端對端測試。
這種測試本身就複雜,又常常要配合各系統的設計不斷調整測試方式,
而且容易受開發時程影響,於是難做又難自動化。
這樣看下來,我很好奇你的 AI 是有多神,
在收下少少的自然語言指令後,居然能產出這麼多的測試程式?
這可是連資深同事都不一定能快速搞定的事欸……
還是說,其實 AI 也只會做其中一小塊?
這樣的話,其他沒做的部分不就是你可以發揮的地方? 你怎麼會「被取代」呢?
以前老是說沒空寫的測試現在有空做了,這樣不是很棒嗎?
更何況,我都還沒講非用途面的測試。
這部分常常是大片的空白,只靠少數人偶爾測一下。
舉例來說,每次更新時都有很多測試可以做:
系統從內部元件到整體的例外處理機制都正常嗎?
更新錯誤可以倒回嗎? 不管是用途面還是非用途面的功能都要正常還原喔~
(升級或倒回過程的承載量是否不變?)
可以正確擴展與收縮嗎?
負載到頂時,系統能正確處理超量的請求而不會當掉嗎?
各元件有無高可用性? 若有災難復元計劃,有驗證更新後依然有效嗎?
備援機制有正常運作嗎?
認證或安全防護機制都正常運作嗎?
可傳送運作指標及日誌紀錄嗎? 與用途有關無關的資料都要送喔~
如果有指標,那警報正常嗎?可響嗎? 響了有通知到正確對象嗎? 通知內容正常嗎?
監控看板正常嗎? 有列了新增的監控對象嗎?
如果有進一步分析日誌,那分析功能正常嗎?
最後,業務流程的例外處理機制正常嗎?
假設上述測完都有做,那你有把這些工作交給程式去做嗎?
若沒有做,AI 也不會的話,這不就是你可以表現的地方?
除非公司把系統的開發與監管事務分拆給績效指標不同的部門負責
(這種情況無論是否採用 DevOps 工具都容易衍生團隊之間的矛盾),
,否則既然 AI 做掉一部分的事,那為什麼不去做其他還不完善的工作呢?
這不就是你能貢獻心力的地方?
工具只是讓你事半功倍的,從古至今皆是如此。
--
ai讓工程師m形化倒是真的,強的更強,爛的更爛
老實說,很多流程性的東西,拆解完會發現可以用n8n配
合ai agent ,慢慢累積變自動化。
沒人說不能搭配 AI 啊 只是回到原本的命題,用 AI 輔助也能叫作取代嗎? 那你眼前的手機和電腦為什麼沒有取代你? 畢竟是他們在發推文的不是嗎?
每個人都事半功倍,那是要業界擴大一倍,還是人要裁掉一
半?
沒人能知道,否則不必工作,通通炒股票就好。 不管怎麼變,放棄投資自己的人都會最快倒下。
現在是會用ai的調高效率,之後就是淘汰掉盲從ai的
寫得不錯
痾 我說的是單元測試捏 老哥
我覺得你跟我講的東西差的遠了
我知道啊 寫這篇只是想告訴你:還有很多事要做啊~ 別看別人講 stackoverflow 就急著替 AI 辯護。 更何況我不覺得 AI 是在取代 stackoverflow。 stackoverflow 的文章常常會提供好幾種解決問題的策略供你參考, 而且會重現思辯過程供你剖析該怎麼做才合適,至於 AI 則要特別指定才有, 兩者的設計大不相同,其實不能相提並論。 兩種工具我都有用。
公司哪天發生SEV1,還不是得由人類工程師負責on call
負責修復,AI能做得到這點,再來說AI取代工程師的問題
。
要說stackoverflow有他的優點當然可以 但是他的流量明顯下降
也是事實
不是有他的優點,stackoverflow是「分享、討論」的地方,本
來就不是純粹給人抄的,太基礎的問題和只是要抄的流量減少
有什麼不好? 把資源留給更有意義的討論不是剛好? 反而是現
在AI還該改進遇到不會的東西別亂掰,自己去發問才好
> 用 AI 輔助也能叫作取代嗎
能啊,原本要更多人才能做的事,現在不用,取代了原本需
要現在不用的人
大家看看,這就是典型 AI 信徒的思維。好多板都會看到這樣的人。 就算職場中操作工具的還是相同的人,而非變成移工等具備自我意識且能自主的東西, 他們仍會認為「生產力的提升」等同於「取代」。 雖然我覺得這樣看事情視角太窄, 這種思維把組織乃至於世界上的工作總量與內容想成某種不隨時勢而變的常數, 接著再斷定事情被機器做掉後,人能做的就會變少,於是得出「被取代」的結論, 但真要這樣想也不是不行,只是這樣我會建議你不要拜 AI 神, 畢竟它當下的影響力還不夠大,而我們是憑事實而非想像論理。 你應該先把汽油、瓦斯、發電機、電線、電腦、硬碟、網路等科技供俸到神廟裡面, 搞不好把 git、洗碗機、洗衣機入廟都更合適, 畢竟提高太多生產力,把人從原本的工作解放出來做其他事。
> 在收下少少的自然語言指令後
你自己這篇不就在示範要如何收到少少的指令之後舉例有多
少東西要測?看不出來有什麼理由是你寫地出來但 ai 不可
能寫出來的
我從頭到尾有在強調 AI 生不了其他方面的程式碼嗎? 這是我的文章主旨嗎? 你沒深入看前後的思考脈絡,急著擷取幾個段落出來戰我也沒辦法。
> 工具只是讓你事半功倍的,從古至今皆是如此。
看不懂這句想要說明什麼?本來就是讓你事半功倍,怎麼了
嗎?和你前面想要證明的點有關嗎?
這是因為你根本沒有深入看我在向那幾個人傳達什麼。 依我看這就是被少數不肯定 AI 的評論戳到,急著跳出來捍衛信仰。
※ 編輯: dream1124 (36.227.216.39 臺灣), 05/06/2025 13:46:49講取代的怎麼不去跟他媽講洗衣機取代她了
不是AI取代人類 是會用AI的人類取代不會用AI的人類
建議樓主可以去研究一下ai agent ,再複雜的測試不也
是一步步的測試堆疊起來,只要步驟流程都是固定的,
就有自動化的可能。兩百字的system prompt不行,就砸
兩千字或是兩萬字,token 費用跟人事費相比,根本差
太多了
洗衣機真的神器,用手洗過衣服的就知道XD(重點誤)
如果有很多人的工作都是洗衣服,洗衣機確實取代很多人的
工作啊
當然還是會需要有人把衣服拿去給洗衣機洗,但洗衣服這個
產業(如果有的話)再也不需要那麼多人工作了
那你有沒有想過,也有可能沒有任何工作崗位不見, 只是工廠用一樣的人操作機器洗更多的衣服,讓客戶能用更便宜的價格更頻繁的洗衣服, 或者把人分散到更多分店讓更多地方有人能洗衣服? 如果是這樣,那又取代在哪? 我說你視角太窄就是這樣。
這有什麼好爭的?機器取代人是戳到你的痛處?和機器有沒
有意識請問有毛關係?和入不入廟有毛關係?
你整篇有超過一半都在舉例"你認為" AI 做不到的的事情(
先不論是否真的做不到),否定你這點叫做斷章取義?
現在(加拿大)大學資工畢業的學生幾乎都找不到工作,幾
年前還是一出來就至少年薪 80k,你去和那些畢業生說他們
沒有被 AI 取代啊
影響就業市場的因素很多。 你要拿這種事來說,那我也可以說印度寫程式的人更多了, 只能說生產力提升,看不出真的取代在哪。
這問題不是看客觀事實就知道了嗎,科技業有沒有停止徵
人、大公司有沒有正在裁員。看個新聞就知道的事情,打
千字長文也不會改變現實世界
你愛用什麼奇怪的世界觀去看 LLM 這個工具,看到連拜神入
廟都出來了是你自己的事情,事實就是這個工具已經取代很
多職位了
ai是某些人的浮木沒錯 妄想一步登天
流程固定有自動化可能的東西本來就用不著ai 只是多數
吹ai的多半也不會傳統工具做法
打工人本身也不會想丟自己飯碗
科技業狀況與經濟關係更大 公司當然想要用最低成本完
成事情 但很多忽略了與自己有同樣資源的人很可能成為
競爭對手的情況
外加不用請多人意味著此人不可替代性會提高 甚至還有
法律糾紛的可能
使用ai順便加料還可以推給ai亂寫
當然本人身為一個好人肯定是不會這麼做的 其它人不知
有prompt log吧
生產力提升->不需要這麼多人->取代某部份人 不然勒
取代兩個字有完全取代跟部份取代 不要雞同鴨講喔
原來現在「部分取代」是人類使用的工具之代名詞喔? 那你大概早就被汽機車、電腦、洗衣機等東西「部分取代」了吧~ 取代就是取代,沒有分什麼部分不部分的。 如果這些「東西」有自主意識能跟老闆討論需求,能決定怎麼做, 不需要你操作,那或許可以叫取代,但現在就是不行,需要你操作。
千萬不要小看AI 現在講AI都是在講未來 兩年前誰想得到現在
工程師人手一個AI視窗?誰想得到stackoverflow流量腰斬?
當然工程師不會幾年內就完全消失 但肯定是越來越難找工作
才兩年 AI就可以是一個高級版的autocomplete了
再兩年 完全不需工程師介入維護一個不太複雜的應用 很合理
呃…測試case還是要人提供的,讓他自己產case是不
會有什麼好結果的
不要小看ai但不要高估人性 ai明顯是對多數從業者弊大
於利的 對開源也是殺傷力極強
喔 你爽就好
第一個淘汰的一定是沒料還堅持不用AI的那群
AI要取代,現階段是真的還早啦,但這不代表他以後沒辦
法啦,怕的是認為現階段AI無法取代工程師就不去用AI,
這種觀念反而更容易使你被淘汰,因為用AI開發產出就擺
在那邊,一樓講M型化很好,強的用越強,弱的不用越弱,
中間的不用就是慢慢被歸類到弱的那邊,要用啦 ai agent
function calling 工作流都碰碰,有在跟新技術就不太
會被淘汰
32
首Po寫程式不知不覺也一年半了 看著公司龐大的老舊程式 前人寫的實在雜亂 造成了維護上有一定難度 最近有心想要嘗試從簡單的地方開始試著重構4
程式人最重要的追求 應該是創造良好就業環境 本來一個人的工作 變成三個人做 三個人的工作要一個部門做![Re: [討論] 寫程式的追求? Re: [討論] 寫程式的追求?](https://i.imgur.com/JAcuIOSb.jpeg)
這幾年AI流行 只要你訂好條件,清楚流程,然後約束修改窗口──你清楚你在做什麼 AI幾乎能產出100%正確的程式碼 並且功能清晰,命名合理,還加上一堆註釋 工作流程幾乎就是讓AI生成程式碼,閱讀程式碼,對一些細節做修改4
: : 這幾年AI流行 : 只要你訂好條件,清楚流程,然後約束修改窗口──你清楚你在做什麼 : AI幾乎能產出100%正確的程式碼 : 並且功能清晰,命名合理,還加上一堆註釋3
你會這樣想只有幾種可能 1.過太爽 2.年輕人認為可以學的到東西 3.單身 基本上重構對公司是沒產值的 不知道你有沒有看過一張圖3
純粹對工作上來說 好抽換,好接手(易閱讀),好維護(包含升級,測試) 工作,這樣就很夠了阿,大家一起輕輕鬆鬆,工作之餘聚餐風花雪月。 回家,陪老婆,陪女兒不好嗎? 工作又不是人生的全部![Re: [討論] 寫程式的追求? Re: [討論] 寫程式的追求?](https://i.imgur.com/KDk3kmpb.jpeg)
4
嗯,這三點很因人、因時、因事、因心情而異。 就像李白好還是杜甫好? 金庸好還是古龍好? Chaos 好? --39
好接手,易閱讀… 我想到一個故事 幾年前有個同事,號稱國中時期就開始接案寫代碼 clean code,DDD滾瓜爛熟,對coding極度潔癖 印象比較深的是入職時說了句:我看到不規範的代碼會非常生氣6
我應該也算軟體工程師吧 在電子廠專門用LabVIEW幫實驗室寫自動測試程式。連續寫了十六年。 體驗所謂人生三階段。 看山是山,看山不是山,看山還是山。 第一階段,只追程式會動,能用就好。就算有問題,硬解。遇到什麼不會,就去學什麼。23
看到你的故事,讓我想起好多當年犯過的錯誤 : 幾年前有個同事,號稱國中時期就開始接案寫代碼 : clean code,DDD滾瓜爛熟,對coding極度潔癖 : 印象比較深的是入職時說了句:我看到不規範的代碼會非常生氣 我年輕的時候也這樣,但做久了慢慢可以理解凡事都是 trade-off
52
Re: [問題] 遊戲試玩員是不是很爽?小弟進入遊戲業的第一份工作剛好就是遊戲測試工讀生, 當時,很多人聽到我工作是遊戲工讀生時,都會說:好爽喔,玩遊戲還有錢拿, 但實際真的沒有大家想像地那麼開心,讓我來分享一下QA部門的日常。 1. 首先,一般玩家玩到的是已經完成的遊戲,![Re: [問題] 遊戲試玩員是不是很爽? Re: [問題] 遊戲試玩員是不是很爽?](https://img.youtube.com/vi/g5xVg0iNmWI/mqdefault.jpg)
38
[心得] LabVIEW工作面試心得各位百萬年薪大大安安~ 先感謝本版許多資訊的幫忙 小弟畢業於中央物理所 這是第二份工作的求職心得 主要鎖定LabVIEW相關工作18
[請益] 超豐電子各位版上前輩先進好 想請問一下 超豐電子 測試系統開發工程師及測試軟體工程師 有沒有前輩在這兩個單位裡面 方便分享一下內部工作風氣嗎18
Re: [心得] 我在科技業遇到的鬼故事之一單純經驗交流一下 我遇到正常的軟體UT與品質驗證流程吧: 1.開發者寫完程式碼與UT。 2.在自己電腦上跑UT。 在自己電腦上跑UT,是部門不認的UT。14
[心得] 以技術分析做程式交易操作(Part.4)前文的連結![[心得] 以技術分析做程式交易操作(Part.4) [心得] 以技術分析做程式交易操作(Part.4)](https://i.imgur.com/PZ4S21vb.png)
9
Re: [閒聊] AI現階段對於獨立遊戲開發者的效率提升很大家好,我是開發遊戲的板友 KO(kkll7952) (開發中steam遊戲 : AirBoost:天空機士) 本身我是多年經驗的遊戲程式工程師 對於AI也很好奇 每當AI有一些突破時 也會摸魚測試一下7
[心得] ChatGPT協助軟體開發的指令集近來寫程式時大量試用ChatGPT 剛好使用golang開發side project, 所以在各種情況下遇到的問題,都試著問ChatGPT 真的覺得超好用的! 網頁好讀版:附上心智圖、完整範例(有些範例太長,PPT沒有辦法完整呈現)4
Re: [閒聊] 為什麼會對遊戲開發者不會玩感到失望下班前來回一篇, 首先,遊戲開發者包含很多專業的人, 個人認為大部分的專業並不需要很會玩遊戲(程式、美術、行政...等), 你很會玩是加分,但工作上只需要知道自己參與的內容會怎麼被用在遊戲中就夠了。 可是,遊戲設計相關的人就必須要很會玩遊戲了,為什麼呢?![Re: [閒聊] 為什麼會對遊戲開發者不會玩感到失望 Re: [閒聊] 為什麼會對遊戲開發者不會玩感到失望](https://img.youtube.com/vi/g5xVg0iNmWI/mqdefault.jpg)
2
Re: [討論] 工作上寫單元測試的比例因為大家的討論都很基於心法 實作上相對很模糊 利用這個機會也跟大家請教實作上的方式 因為最近工作被指派要針對公司產品的程式做整理,其實運作都還好 只是大家功能是一層疊一層,一堆巢狀邏輯,跟依賴中的依賴![Re: [討論] 工作上寫單元測試的比例 Re: [討論] 工作上寫單元測試的比例](https://tdd.best/wp-content/uploads/2021/01/play-for-fun-scaled.jpeg)
[心得] 使用 pyroscope adhoc 加速找到效能瓶頸部落格: Youtube: 大家在開發軟體時,會快速迭代專案時程跟需求,功能越多,系統就會開始出現效能上的 瓶頸,而最快的解決方式就是先垂直擴展,把 CPU 跟記憶體先往上加,但是這是治標不 治本,所以之前有推薦大家一套如何在服務執行時,快速找到哪個地方執行較慢,請參考![[心得] 使用 pyroscope adhoc 加速找到效能瓶頸 [心得] 使用 pyroscope adhoc 加速找到效能瓶頸](https://img.youtube.com/vi/3WfR46Q_9Kk/mqdefault.jpg)
![[請益] 中年求職困境 [請益] 中年求職困境](https://i.ibb.co/230tZgNr/sssss.jpg)