AI 是一面照妖鏡

2026/03/18

2022 年我開始自學前端,到 2026 年的現在,也擔任前端工程師將近兩年,經歷 Copilot、Cursor、推理模型、多模態、Agent 等工具陸續問世,行業生態的變化更加劇烈。如果你常看社群媒體,可能會感受到 FOMO 蔓延得越來越嚴重,甚至影響到自己的心情。

AI 是輔助決策還是麻痺思考

AI 搜尋功能還沒出現之前,我已經遇過不少將 AI 的回應「直接」拿來交付的案例,例如課堂作業、學生專題、發 PR、簡報摘要等。

善用 AI 沒什麼不好,我也愛用,而且確實減少很多自己搜集與彙整資料的時間。我自己不太擅長發想(唯一擅長的發想大概是講一些北七冷梗),比較擅長挑骨頭,AI 就能幫助我腦洞大開,在前期規劃中做一些發散性的探索。

「凡事都要過問 AI,對決策沒有把握」,職場上多少會感覺到越來越多這樣的人。

因此你最近常常:

  • 參加一場主講人也不知道自己簡報內容是什麼的會議
  • 認真地根據現況做分析、提出方案,但 3 秒就被一個 AI 臨時生成的答案回絕
  • 被不清楚你的專長的人拿著 AI 的回答質疑你

這種現象也讓我感到不少困擾,因為 AI 不但沒有讓溝通成本降低,反而讓人更頭痛了!

龍哥(高見龍)在演講中提到的放大器正是這種現象的寫照。願意認真思考自己需要什麼的人,AI 加速他們達成目的。不想思考的人,AI 膨脹了他們的災難

我認為 AI 是用來輔助決策的工具,而不是省略思考與溝通

團隊合作的糾紛,大多萌生於思考與溝通的過程。沒有共識、無法對齊的時候,團隊沒有選擇努力化解,反而還不想面對彼此,這時 AI 只會擴大這道鴻溝。

思考與溝通,就是身為人的責任,省略這個過程就是逃避責任,既然本來就不想面對,那要怎麼期待這個決策可以服眾呢?如果不能服眾,就更難期待 AI 吐出來的答案可以凝聚共識了。

「人」的問題沒有解決,就不可能交給 AI 解決。

寫 code 的時間本來就很少

在軟工行業打拼的朋友們,可能對以下現象略有耳聞或親身經歷:

  • 公司導入 AI 工具,但是大幅提前交付期限
  • 看 token 用量算 KPI
  • 非開發單位的人拿著 Vibe Coding 的成果問你「我都可以,你為什麼不行」

寫 code 其實只是工作的一部份,並不是一天工作 8 小時就真的 8 小時都在寫 code,不熟悉軟工職能的話,蠻容易產生這種誤解,所以才會有「反正 AI 寫 code 那麼快,多做一點事或縮短工期也蠻合理吧」的傳聞。

AI 讓過往寫 code 的壓力降低了,但其他的工作事項仍然存在,我們還是要討論需求、評估可行性與風險、系統架構等等。

AI 可以輔助我們發想、彙整這些規格,減少文書作業的勞動量,但同上一段說到的,倉促的決策卻從常態變成惡夢。

如果組織之間本來就存在溝通管理的問題,並不會因為導入 AI 後就憑空搞定,反而會更快凸顯這些問題衍伸的決策帶來的混亂。

AI 應該是可以理性地梳理這些我們感性上不想面對的麻煩事,根據現況提出一些可能性,讓大家誠實地面對這些問題,而不是用更糟糕的決策去補救上一個糟糕的決策。

保持思考,盡力溝通

AI 也在工作場域中帶出了多巴胺過載的現象,讓人沈浸在快速產出的快樂,漸漸沒有耐心來思考,彷彿只要夠快,決策與成果的品質就沒那麼重要。

但出錢的人才是衣食父母,業主期望的就是花了錢要看到效率跟效果。這不是我個人的消極看法,而是在資本世界中最純粹的供需原理。所以雖然我覺得頭痛,但不會拒絕合作,畢竟我一個打工仔馬洗愛炭吉 XD

當然,放棄溝通、人家要什麼就給什麼,也是一種應對方式!「只要我講得合理、舒服,就可以說服對方」並不是努力就可以達成的事,我們只能調適自己心態,告訴自己真的有努力溝通過了。

管理層面的問題需要大家討論出共識,建立規範與標準,但這個過程大多比較漫長,而企業有時候就是必須快速拿出成果的燃眉之急,暫時權衡不了這些事。

當大家都有各自的堅持時,還能保持思考、盡力溝通,才是難能可貴的,也是我認為面對問題應該要有的態度。AI 是科學的結晶,但不是機械降神的萬靈丹,只是一面照妖鏡。

閱讀更多

軟體工程師一定要參與社群討論嗎

2025/11/11

某次面試時,技術主管向我問道:

「您有沒有參與過技術小聚或是一些研討會呢?」

雖然我不排斥參與社群活動,但過去一兩年下來,公開的活動也就去過兩三場,反而回去 bootcamp 分享心得的次數更多,可謂是窩在自己的小圈圈 XD

社群網路的討論都很熱絡,近年很多組織也都移駕到 Discord 進行管理、舉辦讀書會,或是這一兩年 Threads 也有很多串文被爆炸式傳播。

實體活動偶爾可以在寒暄的過程中交換一些純文字無法傳神表達的大瓜(?),社群網路則可以快速取得新知與新聞,無論哪種管道都能獲取資訊,所以參與社群討論絕對有實際效益,至少能刺激社交能量。

過濾資訊

實體互動中可以直接觀察到對方或是現場氛圍,因此多少可以透過肢體語言讓我們辨識到一些潛在資訊。

而社群網路大多是文字討論,所以很多內文難免會運用誇張的措辭來搏版面,像是「不能不會」、「必學」、「殺手級」、「核彈級」等等,試圖增加點擊率,同時也引起資訊焦慮。

當然,我自己看一看也會產生焦慮,這是正常的生理反應! 無論這些資訊對我有沒有幫助。所以我也在練習思考自己真正需要的資訊是什麼之後,再去查證資訊來源的可靠性。

查證的過程也會有所收穫,就像過去我們學習新的技能與技術,或是遇到 bug 時也會去查文件、爬論壇等等,慢慢養成剖析內容、明辨是非的習慣。

所以建立一套自己的視讀標準,就可以過濾掉一些不需要的資訊,像是近幾年流行的「多巴胺排毒」(不看社群媒體或短影音,減少電子設備的使用),現在獲取資訊的管道很多,絕對不會因為不滑手機就錯過什麼,你有疑惑、有需求的時候再去搜索就可以了!

接受衝突

有人的地方就有社會,人多了就容易因為立場不同而產生衝突,就像偶爾會聽到的「學校也是社會的縮影」。

社群網路的衝突更加頻繁,因為打字留言的成本和風險非常低,沒有什麼出來喬的肢體暴力危險。所以很多留言並非志在討論,只是在抒發情緒,故意讓人不舒服,就是那種特地跑到你家門口丟垃圾,丟了就跑,你想罵他還找不到人的感覺。

討論不出共識的時候,往往也會有像是「不懂哪裡難?」、「D能?」、「這種程度?」之類的言論 XD

和文學小說不同,我覺得蠻難判讀網路留言的情緒,有 emoji 也不代表我們想的是一樣的,所以經常也有見面之後反而覺得對方很和善的案例。

因此大部分的留言,我想不用帶著太多情緒去看,和 code review 一樣,只要過濾出對你有幫助的資訊就好,抽離情緒後再回來,我相信很快能辨認哪些留言是認真在討論的。

不要讓這些廉價的留言換取你的不開心!

小結

每天都有大大小小的情緒影響生活,例如衝動性購物、錯失恐懼症等等,在資訊發達的時代下,隨時都有多不勝數的東西在試圖挑起情緒,奪走我們寶貴的注意力。

所以焦慮的時候就行動吧!把我們的注意力慢慢從焦慮轉移到實際行動上,具體行動與行動帶來的成果,都會幫助我們更快化解焦慮的心情!

閱讀更多

小白接手前端專案

2025/05/16

轉眼間轉職也快滿一年了,想分享一下這一年來維護舊專案的心得!

軟體工程師一定會碰到沒有文件或註解的專案,如果商業邏輯繁重、過多的 workaround、沒有測試等等 ,蠻有可能一改就爆炸。

這時需要先分析現況,擬定短、中、長期的解決方案,但是否有時間分析,也會受限於公司給你多少時間處理手上的問題!短期盡量先以熟悉專案為主,之後再處理效能、架構的改善或是複雜議題。


短期

以前端來說,我認為短期可以聚焦在使用者操作直接相關的部分,包含:

  1. 操作回饋:給予使用者操作成功或失敗的提示
  2. 等待回饋:進度條、讀取動畫、按鈕禁用
  3. 頁面跳轉:閃爍、路由守衛、錯誤頁面、重載機制
  4. 點擊防禦:針對負載較重的功能設計防抖、節流、狀態鎖
  5. 樣式:如果有設計系統,通常不用去動它,主要處理一些樣式不一致的問題

這些功能都集中在展示層 (presentational),也是最容易改動的,不涉及太多資料管理,好改就會立竿見影。


中期

處理過展示層後就能更快辨認 issue 類型是偏向展示層還是邏輯層 (container)

邏輯層通常涉及比較多外部資料的整合,必須先梳理好資料流才能進行改善,例如我在工作上常遇到的案例有:

  1. 重複打出 API
  2. 多個頁面依賴同個 API 資料
  3. 狀態管理器將 UI 狀態跟資料狀態包在一起

這階段偏向資料流與邏輯邊界的重構,搭配防抖和節流,可以預防很多效能問題。

但「正確地」梳理不是簡單的事,如果能夠初步區分出展示層與邏輯層,相信勝過毫無準則地濫用工具。

資訊

展示層與邏輯層的概念可以參考:Container/Presentational Pattern


長期

現職 9 個月以來,我持續在做:

  1. 寫註解:補了一些比較難懂的 side effect,註記各個元件的功能
  2. 導入 TypeScript:但也就是先導入,至少讓新功能可以跟進 TS
  3. 改善專案架構:東西雖然不是非常難找,但缺乏一些分類準則,目前持續參考 FSD、原子設計等等的架構,用破壞性最小的方式慢慢改善`
  4. 導入單元測試: 針對資料重組或新加入的函式去測,我也沒有寫測試的經驗,所以後續還要研究元件的測試
  5. 可讀性改善:Code Spell Checker 先裝上去再說 XD 我會一塊一塊讀程式碼,所以看到很多黏在一起沒有空行,實在蠻痛苦的

接下來也預計嘗試我在培訓時期還沒有做過的事,像是整合測試、E2E 測試等等。

升版本要做比較縝密的手動測試,雖然專案可以 build 成功,但不能保證完全沒有地方壞掉!所以還是要好好評估升級後有多少餘力可以馬上處理掉沒測到的問題。

祝大家寫 code 快樂 🤣

閱讀更多

如果不做工程師

2025/03/18

縱使不在了也必然會留下什麼

看到廖老大的串文,也讓我開始回顧過去半年多的生涯, 去年上岸不久後有收到一個工作邀約:帶學生做專題。

比較特別的是,工作內容不會幫學生處理任何程式寫作的問題, 而是以分享經驗、提供資源的方式,引導學生去摸索與思考。

這份工作比較像是在訓練多方對齊的管理與溝通能力, 也可以透過學生想做的主題方向,刺激自己去研究一些沒碰過的知識。

一開始會自我懷疑:我一個轉職仔能勝任這份工作嗎? 但仔細想想,以前在 bootcamp 不也都是學長姐在引導我們嗎? 我們只要盡我們所能,讓學生有信心能繼續前進就可以了。

過去的記憶會慢慢串連

之前會覺得自己一直都沒有專精在一個領域, 不論美術、設計、遊戲開發等,都沒做出什麼令人滿意的成果。

「和自己比較」也是洧杰老師最常跟我們說的雞湯(?

得失心往往會讓人忽略: 雖然努力不一定能得到盡善盡美的成果,但過程會累積很多記憶, 不論是情緒的記憶、還是知識的記憶等等, 它們都會串聯成往後人生的一部分,這也是我開始擔任教練後,慢慢理解到的。 因此我相信,如果離開這個環境,未來的生活也會將這些記憶延續下去。

閱讀更多

轉職前端工程師需要刷題嗎

2025/02/22

先說結論,不確定現在求職市場的要求如何,但以我去年的求職經驗來說,轉職可能需要一點點,但不多。

我前期學習只靠 Huli 大大的網站教材,也有試著做 LeetCode 大概十幾題,喚回一點演算法的記憶。刷題除了可以建立寫程式的邏輯基礎與流程思路外,對我目前工作上幫助最多的應該是效能和可讀性的改善。

以入門好朋友 Two Sum 為例,剛開始通常會直覺地用迴圈裡面再執行迴圈來解決,但當我們照它的建議,試著把時間複雜度降到 O(n) 的話,如果沒有資料結構實作的經驗,有點難馬上聯想到 hash table 的概念。

我剛入職時發現專案內有很多地方都可以用 hash table 解決,像是各種 findincludes 等等的陣列查詢、靜態資料的格式轉來轉去等等,如果有映射查值的概念,可讀性可以改善很多。

網站開發需要不同領域的知識串聯,一開始感覺會很離散,像是迴圈、閉包、設計模式, 好像跟刻畫面、接 API 一點關係也沒有,但是接觸的業務邏輯越來越多之後,會發現很多東西是環環相扣的。

所以不知道也沒關係,遇到的時候再補起來就好,畢竟寫程式的目的除了賺錢,還是要解決問題 💪

LeetCode 的題目可能有點生硬,可以先從 Codewar 開始培養語感,情境題或手寫題也是求職必考的!

刷題參考網站:

閱讀更多