我替他開心，也順口問了幾個問題：系統有權限設計嗎？API 有沒有限制呼叫次數？有把使用者的操作記錄下來嗎？

他愣了一下，說：「我聽不太懂你的問題？這些重要嗎？」

聽到這個回答，我不禁捏了把冷汗，並列出一個檢查清單給他參考。

這幾年用 AI 輔助開發，我最深的體會就是這句話：「看起來能動的東西，才是最危險的。」

AI 真的很強，簡單的指令就能完成功能，甚至建立系統、App。

但它不一定會主動幫你補上那些「沒要求、卻很關鍵」的東西 — — 權限控管、測試、錯誤處理、資訊安全、上線維護。

有開發經驗的人，知道這些很重要，所以發現 AI 沒設計會要求他補上。

但如果是完全 0 基礎的小白，其實會陷入「不知道自己其實需要的囧境」。

我拍過十幾支用 AI 寫程式的教學影片，也幫不少企業做過內訓。

一路下來我慢慢發現，大家真正卡住的地方，其實不是 Prompt 下得好不好、工具選得對不對。

而是 — — 不知道怎麼把學到的技巧，整合進一個真實的專案裡。

所以我把幾個最會拉開差距、卻最常被忽略的地方，整理給你 👇

1️⃣ 別再用「寫了幾行程式」衡量產出

→ AI 五分鐘能噴 5000 行，也很擅長自產自銷 Bug。真正該看的，是交付出去的良率，以及出事之後多快能修好。

2️⃣ AI 跟你鬼打牆，通常不是 AI 的錯

→ 很多時候是你給的資訊不夠。log 不完整、需求太模糊，AI 再聰明也只能用猜的。先把資訊補足，遠比燒 Token 有效。

3️⃣ 解過的問題，不要再解第二次

→ 把這次的做法整理成一個 Agent Skill，教會 AI 一次，它就永遠記得。下次遇到同樣的任務，直接複用。

我很常被問：「AI 工具幾乎每天都在變，現在學的東西，明天還有用嗎？」

老實說，如果課程只教你工具如何使用；那過不了幾個禮拜，你學到的知識就過期了。

所以我更喜歡分享「如何拆解需求、怎麼定義規格、怎麼驗證結果、怎麼為產出負責」的知識，因為這套底層邏輯，是可以跟著 AI 與自身經驗一起進化的。

在人人都能用一行指令生成系統的年代，「軟體工程」反而變得更重要。因為有了清楚的地基，AI 才知道要照什麼規格開發、用什麼標準驗收、依循什麼流程交付。

如果你想學的，不只是「AI 能不能幫我做點什麼」，而是「我該怎麼把它放進自己的開發工作流」，那這場免費直播，我會完整分享自己的實戰經驗。

👉 立即免費報名: https://tibame.tw/hI1Ks

今天要跟大家分享 Google 最新推出的 Antigravity 這款 AI 程式碼編輯器。

不管你電腦的作業系統是 Windows、Mac，還是 Linux，都可以安裝體驗。

這隻文章我會透過 Vibe Coding，手把手帶你完成一個輕量級的全端專案，透過實戰的方式，帶大家了解他有哪些特色。

如果你是剛接觸 Vibe Coding 的新手，可以了解有哪些實用技巧，能讓 AI 給你更精準的回覆，並根據你的需求進行功能調整、畫面優化。

最後告訴你，如何在確保資訊安全的前提下，把專案部署到線上環境。

完整的 Demo，可以觀看 YT 喔 👉

對 AI 應用感興趣的朋友，歡迎按下訂閱按鈕，未來我計畫分享一系列 AI 工具的應用教學。

【Google Antigravity 教學】把想法化為現實！用 Vibe Coding 完成輕量級全端專案

一、全端架構快速入門

以全端專案來說，通常會包含前端、後端、資料庫 3 個部分。

前端是給使用者瀏覽的畫面，我選擇了 React 這款知名框架，他有許多現成的元件素材可以讓 AI 使用。

而後端是處理邏輯判斷的部分，如果採用傳統的 Python、Node.js、PHP 等程式語言。

對新手來說，我認為難度太高了，就算真的把功能做出來也沒有掌控力。

所以我打算使用 Google Apps Script，這款打開瀏覽器就能使用的工具作為替代方案。

至於資料庫，我也不使用 MySQL、Postgres、Mongo；而是使用大家非常熟悉的 Google Sheets，打開就能看到並且編輯資料。

採用這套組合，你不需要伺服器、不用綁信用卡、不需要複雜的前置作業。

就能透過實作理解全端專案的架構，而且最後可以免費把專案放到 GitHub 公開部署。

不管你是要跟朋友炫耀，還是要直接應用到職場上都是可以的喔！

二、快速上手 Antigravity

如果使用過 VS Code 或是 Cusor，那他的介面你應該可以無障礙使用。

目前 Antigravity 只要登入 Google 帳號就可以免費使用，至於免費多久，就看 Google 的心情了。

這邊我先新增一個「pixel-game」的資料夾，然後把它拖曳到 Antigravity 中，這樣 AI 才知道他的工作區，在哪個資料夾底下。

接下來跟大家說明一下右側 Agent 可以做的設定。

這個 … 打開後有 3 個選項，分別是「客製化、MCP 伺服器，以及下載診斷」

設定 Rules，讓 AI 更懂你

建議大家可以選擇「Customizations」來設定一下自己的使用偏好，在 Rules 這個地方，我選擇 Global。

這邊我複製貼上一個 Cursor 內部員工的 Rules 範例，其實提示詞都是通用的：https://x.com/kayladotdev/status/1853272891023872450

DO NOT GIVE ME HIGH LEVEL SHIT, IF I ASK FOR FIX OR EXPLANATION, I WANT ACTUAL CODE OR EXPLANATION!!! I DON'T WANT "Here's how you can blablabla"

- Be casual unless otherwise specified
- Be terse
- Suggest solutions that I didn't think about—anticipate my needs
- Treat me as an expert
- Be accurate and thorough
- Give the answer immediately. Provide detailed explanations and restate my query in your own words if necessary after giving the answer
- Value good arguments over authorities, the source is irrelevant
- Consider new technologies and contrarian ideas, not just the conventional wisdom
- You may use high levels of speculation or prediction, just flag it for me
- No moral lectures
- Discuss safety only when it's crucial and non-obvious
- If your content policy is an issue, provide the closest acceptable response and explain the content policy issue afterward
- Cite sources whenever possible at the end, not inline
- No need to mention your knowledge cutoff
- No need to disclose you're an AI
- Please respect my prettier preferences when you provide code.
- Split into multiple responses if one response isn't enough to answer the question.

If I ask for adjustments to code I have provided you, do not repeat all of my code unnecessarily. Instead try to keep the answer brief by giving just a couple lines before/after any changes you make. Multiple code blocks are ok.

貼上後，這個規則就會在所有的專案中生效；另外大家可以再加上一個 Rules，告訴 AI 你習慣使用的語言。

- Always respond in 繁體中文

點擊刷新後，就可以看到自己設定好的 Rules。

另外如果你想給目前的專案設定特定的 Rules，比如程式碼規則這類的，也可以點擊 Workspace 來設定喔。

跨模型支援

在模型這塊，Google 除了自家的 Gemini 外，還提供了 Claude 與 GPT 的模型讓大家使用。

這邊要提醒一下，每個模型使用是有額度限制的，超過後需要換一個模型使用。

對話模式

在對話上，有分成 Planning 跟 Fast 兩種。

如果你今天要處理的是複雜任務，比如專案初始的規劃，就建議選擇 Planning。

假使你只是想要簡單快速的得到解答，那選擇 Fast 更省時喔。

不要完全賦權給 AI Agent

• Terminal Command Auto Execution 不建議用 Turbo 模式（此模式僅建議在獨立容器內執行）
• 編輯 Deny List Terminal Commands 放黑名單指令

三、引導 AI 生成專案

可以在右側的 Agent 對話框中，貼上我們的需求：

# 角色
你是一位資深的 React 前端工程師與遊戲設計師。請根據需求描述協助我設計一個網頁的「闖關問答遊戲」

# UI/UX 需求
- 前端框架：React Vite
- 風格：Pixel Art 像素風，像是 2000 年代的街機，樸實但是有設計感。
- 關主圖片處理：使用 DiceBear API 預先載入 100 張不同素材
- 關卡呈現：每一關皆配有一個 Pixel 風格的「關主」圖片

# 功能需求

## 操作流程
- 首頁：使用者需輸入「ID」才能開始遊戲，此 ID 是為了記錄到 Google Sheets
- 題目來源：透過 Google Apps Script 從指定 Google Sheets 的「題目」工作表隨機撈取 N 題（不包含解答欄位）
- 成績計算：將作答結果傳送到 Google Apps Script 計算成績，並記錄到 Google Sheets

## Google Sheets 配置
- 「題目」工作表：題號、題目、A、B、C、D、解答
- 「回答」工作表：ID、闖關次數、總分、最高分、第一次通關分數（若同 ID 已通關過，後續分數不覆蓋，僅在同列增加闖關次數）、花了幾次通關、最近遊玩時間
- Google Apps Script：是直接從這份 Google Sheet 擴充功能配置的

# 環境變數設定 (.env)
請將以下參數設計為可透過環境變數配置：
- GOOGLE_APP_SCRIPT_URL：Google Apps Script 的後端連結
- PASS_THRESHOLD：通過門檻（需要答對幾題才算通過）
- QUESTION_COUNT：每次遊戲的題目數量

這邊說明一下我是如何發想專案的。

最近在幫學校老師與企業的人資上課時，他們提到自己時常有出考題給學生，以及對員工有培訓考核的需求。

但市場上找不到可以免費亂數出題、自動批改、簡單操作的工具。

了解需求後，我就想：

那不如我嘗試用 Vibe Coding 設計一個簡易的闖關遊戲？

於是今天的影片就出來了，我希望大家 Vibe Coding 時，盡可能從「實際」的需求出發；如果只是複製貼上別人的提示詞，你是學不到什麼東西的。

下面跟大家說明一下我的提示詞架構：

前端風格

首先，我做了角色設定，讓他扮演資深的 React 前端工程師與遊戲設計師。

另外如果你是第一次接觸 React，會需要先安裝 Node.js，詳細安裝與設定步驟可以參考上方的資訊卡，我有特別錄一集影片，分享安裝哪些工具可以讓 Vibe Coding 效率加倍。

好，除了有角色設定與框架選擇外，我還跟他說了我期待的設計風格是 Pixel 像素風。

並且關主的圖片要先下載好，每一關都要配置一個。

前後端邏輯設計

接下來，我則是非常明確的規範專案的「功能需求」，這塊就是講解前後端的運作邏輯。

我告訴他使用者需輸入「ID」才能開始遊戲，此 ID 是為了讓 Google Sheets 紀錄分數時知道對方是誰。

另外遊戲一開始會透過 Google Apps Script 從 Google Sheets 撈取「題目」，這邊有特別交代不要包含解答欄位。

之所以不直接從 Google Sheets 抓題目，是為了保護資料來源。

另外作答完畢後，會把答題結果傳送到 Google Apps Script 計算成績，並記錄到 Google Sheets。

資料庫設計

然後為了要讓 AI 明白資料如何讀取與寫入，所以我提供了非常明確的 Google Sheets 配置，減少模糊地帶。

不管題目還是回答的工作表，我都有明確列出欄位。

並且針對特殊欄位有額外的說明，像是「回答」工作表的第一次通關分數，我就備注：「若同 ID 已通關過，後續分數不覆蓋，僅在同列增加闖關次數」。

還有特別補充一點，Google Apps Script 是直接從這份 Google Sheet 擴充功能配置的，這是表達工具間的相依性。

環境變數設計

最後考量到專案完成後的「易用性」，所以我把「Google Apps Script 連結、通過門檻、題目數量」等設計為環境變數。

這樣日後要換考題、改變評核標準，就不用打開程式，在網頁動動手指就好了。

通常第一次的結果都不會滿意的

不滿意的地方，你可以直接跟 AI 討論（可以參考影片）

四、部署前注意事項

確認功能都符合需求後，接下來我們就要準備將專案部署到 GitHub Pages。

但部署前，我先提醒一下要注意的事項：

設計 .gitignore

在這裡放不要加入 Git 版控的檔案、資料夾，比如：

• 套件資料夾（node_modules）
• 程式自動生成資料夾（dist）
• log 檔
• 暫存檔（.tmp）
• 隱私檔（.nev）

設計 .env.example

雖然 .env 不可以上傳，但為了讓其他人知道可以如何使用這個專案，我會設計一個 .env.example 的範例檔：

請幫我建立一個 .env.example 的範例檔

設計 Github Actions

另外因為我們想要在 GitHub 部署，所以這邊我也請 AI 協助設計對應的工作流

請設計能自動部署到 Github Pages 的 Action，會使用到的環境變數請參考 .env.exmaple 檔
並將操作流程更新到 README.md 文件

五、用 GitHub Pages 免費發布網頁

先點擊左側的 Source Control，點擊 Initialize Repository 可以初始化專案。

接著點擊 Generate，AI 就會辨識我們更新的內容，來產生 commit 訊息。

確認文字描述符合自己的預期後，點擊 commit，就會在自己的電腦記錄這個變更。

但如果想更新到雲端，你需要點擊 Push 才會正式上傳喔！

如果專案尚未存在於 GitHub，這邊會有彈窗出現，讓你輸入專案名稱。

另位因為我們的專案預計要發布到 GitHub Pages，所以選擇 Public Repository，完成後，點擊 Open GitHub 去看看是否部署順利。

如果能看到專案的內容，就代表你成功上傳專案了！

完成這些操作後，我們回到 GitHub 點擊「Actions」的分頁，查看部署的狀況。

成功的話會有綠色勾勾，失敗則是紅色叉叉，會需要點進去釐清具體的錯誤原因。

一開始部署失敗很正常，你可以把錯誤訊息複製起來，直接貼到與 AI 的對話視窗中，讓他幫忙解決

如果一切順利，點擊進去就會看到這個專案的網址嚕

之後這個專案都是使用這個網址，把它點開來，順利的話，就可以看到成品嚕～

但這個時候還不要高興的太早，因為我們還沒有設定這個專案的環境變數

這邊我們再回到 GitHub 頁面，選擇 Settings 分頁，選擇左側的「Secrets and variables」。

選擇「Actions」，這時你會發現環境變數的設定有分成兩種

Secrets，是放比較隱私的變數，而 Variables 則是放較不敏感的環境變數。

至於怎麼放，我們可以回到專案，點開「.github」資料夾底下的 deploy.yml 檔案。

在 .env 的地方就有跟我們說明了哪些環境變數使用 secrets，哪些使用 variables，這邊使用「New repository secret」來設定。

完成後，要記得到 Action 的分頁，找最後一個 deploy 的結果，選擇 Re-run all jobs，這樣環境變數的變更才會生效喔！

這邊提醒一下，這隻影片是先幫大家初步掌握「全端專案的核心概念」

讓你了解前端怎麼顯示、後端如何處理資料，以及資料庫如何存取

目前的專案架構，並不適合處理邏輯複雜與高流量的使用場景

但在了解這些概念後，未來後端想換成 Node.js，資料庫換成 MySQL 會輕鬆許多

六、結語：培養真正的工程思維

最近我拍了許多 AI 主題的影片，但主要目的不是要介紹工具如何使用，而是透過自己的經驗，從「實戰」的角度去深入分享。

這幾年來，我在學校、企業講過許多 AI 輔助撰寫程式的課程，也就是現在大家所說的 Vibe Coding。

很多學員都在問我，使用哪個工具才是最好的，我跟他們說：「選擇你最順手的主流工具就好，儘管工具間有差異；但完成專案的關鍵在於人，而不是工具。」

以程式編輯器來說，從 VSCode、Cursor，到今天介紹的 Antigravity。

工具永遠在更新、競爭，但我開發十幾年後，體悟到很重要的一件事：

「不管程式語言還是工具，他們的本質都是為了解決問題；

一直學新的程式語言、換新的工具，其實對個人的成長極其有限。」

因為你的精力被分散了，對新手來說，還不如選擇一門程式語言，好好去深入研究。雖然程式間的語法不同，但底層邏輯都是差不多的。

我不會特別崇拜某個程式語言，也不會非某個工具不用，因為現實世界只有「當下最合適」的選擇。

技術會一直迭代更新，但程式的底蘊可以持續累積。

在文章的最後，請大家在 AI 時代一定要保有自己的判斷力與行動力；就算你覺得這篇文章的內容很棒，那終究是「我的使用情境」。

動手將知識轉化成自己實際能用到的，那才會變成你的。

如果未來你打算用 Vibe Coding 開發更完整的全端專案，可以先看看這隻影片。

我有錄一隻影片分享 Vibe Coding 時，前端、後端、資料庫最常遇到的陷，他可以幫助你有系統地建立安全意識。

儘管 AI 工具會越來越強大，但他同時會給沒有相關知識背景的人帶來更大的幻覺。

過去 AI 寫錯程式會跑不動，你會知道他錯了。

可是他現在有能力寫出「看起來能動」的工具，畫面正常、功能正常；但可能背後的邏輯有問題，或者你看到的只是假資料。

如果沒有前後端概念，不了解資料庫如何運作，那你是沒有能力判斷 AI 給的資訊是否正確的。

記住！AI 是一個好幫手，但他並非萬能

如果這篇文章對你有幫助，可以順手按個讚，把文章分享給正在 Vibe Coding 的朋友們。

今天想跟大家聊兩個職涯議題～

一個是求職時「挑選工作」的技巧，如何用一樣的履歷談到更高薪水。

另一個是在職時如何透過「主動安排」工作，擴增舒適圈，累積與眾不同的履歷。

畢竟想在職涯中有好選擇，你得先讓自己有更多選擇。

如果想用「聽」的，可以觀看 YT 喔 👉

對職場故事感興趣的朋友，歡迎按下訂閱按鈕。

未來我會分享自己從工程師做到專案經理、技術主管，一直到現在外商工作的故事。

【程式碼外的戰場 EP2】去需要你的公司，累積最多的履歷

薪水，是環境決定的

面試的時候，每間公司開出來的薪水都不一樣。

但你還是你，你的能力不會在短短幾小時、幾天就發生巨大的變化。

我認為影響薪水的因素主要有兩點：

1. 這間公司是否賺錢：有賺錢的公司，你更有機會談到高於市場的價碼。
2. 你與這個職缺有多高的匹配度：匹配度高，就代表你可以在更短的時間成為即戰力。

在匹配度這塊，我以軟體工程師舉例，因為這個職稱下會有很多細分職位：

• 設計網頁視覺與互動體驗的是「前端工程師」
• 負責資料處理與系統邏輯的是「後端工程師」
• 確保系統穩定運作的是「維運工程師」

而我當年第一份工作是在一間軟體接案公司，因為人少，所以職位沒有劃分的那麼詳細。

換句話說，就是你什麼都要會，但這件事有好有壞。

如果我面試的是前端工程師、後端工程師，這些有明確劃分工作內容的職位，我無法談到理想的薪水 😭

因為以接案公司來說，在期限內交付專案是最重要的。

過去光是把功能完成，我就已經搞到天天加班，根本沒力氣深入研究技術細節與效能優化。

因此面試幾次碰壁後，我把目光轉移到全端工程師這個職位。

由於技能匹配度高，薪水相比於過去面試的前後端職位，保底就多了 2 成以上。

選需要你的公司，填不後悔的薪水

這邊分享一個印象深刻的面試經驗，當時面試官是公司的副總。

簡單聊幾句話後，他便起身跟我說：「接下來，我要帶領我們雲端部門的團隊來跟你面試。」

幾分鐘後，他帶一個人走進會議室，正當我疑惑的時候，他開口說道：「如果你選擇加入我們公司，你就是團隊的第一位工程師。」

儘管我面試的是一間業務範圍跨足全球，員工達數百人的硬體公司，但雲端部門才剛成立。

故事說到這裡，大家不妨思考一下，如果換作是你，會做出什麼決策 🤔

反正我當年聽到這個消息時，就知道自己的機會來了！

我拿出準備好的簡報，詳細說明自己是如何從零開始，獨自打造出一套系統的。

因為同時兼任專案經理、設計師、前後端工程師等多重角色，所以面試被問到的所有問題，我都能清楚說明背後的設計思維與實務經驗。

在技術面試結束後，我就知道自己是公司要的人 💪

所以最後與人資面談時，在期望薪水那欄，我寫了一個就算加班到爆也不會後悔的數字。

結果隔天就收到錄取通知了，恩…也許我當年可以填更高一點 😏

透過這個案例，大家應該可以感受到，你與職位的「匹配度」，會對薪水產生多大影響。

我會很多技能這件事，在有些公司看來是「樣樣通、樣樣鬆」。

但這個特質如果放到剛起步、需要全才的公司，我就是個難得一見的人才！

而且這份工作除了要從零建構一套系統外，還要與韌體、App 部門的同事溝通。

因此還需要具備跨部門溝通，以及資訊整合的能力。

剛好，我在上一份工作擁有與政府官員溝通，以及整合各單位需求的豐富經驗，這也讓面試官更相信我適合這個職位。

擴大舒適圈，成為更有價值的人

入職後，我做了很多別人眼中「自找麻煩」的事情。

但如果你只願意做份內的事，就不要期待未來會有不一樣的變化。

很多時候只要多做一點，你就能在公司建立自己的影響力！

這邊的「多做一點」並不是要你加班，而是要學會主動安排自己的工作。

這不但能給別人積極主動的印象，還可以讓履歷的素材更豐富，讓年資不再成為職涯的限制。

因為我是部門除主管外的第一位工程師，所以除了網頁前後端的開發外。

公司內部的伺服器架設、GitLab CI/CD 自動化、GCP 雲端部署⋯等 DevOps、MIS 的任務都跑到我頭上。

除了上述雜事要處理外，當時公司會成立雲端部門，是因為公司販售的硬體設備為了符合法規，需要搭配一些雲端支援的功能。

所以我們部門要提供 API 給韌體與 App 部門的同事使用。

但隔行如隔山，因為雙方的專業領域不同，所以初期也花了不少時間釐清規格，並把討論結果彙整成彼此有共識的開發文件，確保日後溝通不會雞同鴨講。

或許從工程師的角度來看，我做了很多「本職工作」以外的事情；但我覺得自己是在「擴大舒適圈」。

• 架設內部伺服器的過程，讓我對公司網路架構有更深刻的理解。
• 設計 Gitlab CI/CD 流程，讓我了解加入哪些步驟可以讓專案更穩定。
• 操作 GCP 雲端部署，則是我過去沒有接觸過的技能。
• 理解韌體與 APP 部門的需求後，我對公司的硬體產品有更全面的認識。

我當然可以選擇裝死，讓主管去搞定與釐清這一切，但我選擇主動承接這些任務。

因為搞定這些「陌生」的事情，是在擴增我的舒適圈，讓我可以走到更遠的地方。

當然每個人的職涯規劃不同，有些人可能想把某項技術鑽研到極致。

而我選擇的是，從實務中學習需要的技術、從問題中找到解決的方法，所以技能樹非常的發散。

我認這沒有對錯，只是個人選擇。

導入專案系統，增加合作效率

隨著業務量增加，部門後續有找前端、後端、DevOps 工程師與 UI/UX 設計師加入團隊。

但其他部門遇到問題、有新需求時，第一個還是先想到我，除了寄信、傳訊息外，有些人會直接跑到我座位旁邊討論。

這導致我常常事情做到一半被打斷思路，而且訊息、郵件過多時，總是會有漏看、漏回的狀況發生；於是我心想，這樣不行啊！

所以開始思考如何優化部門間的溝通問題，與主管討論後，我在公司內部架設了開源的專案管理系統（ex：REDMINE、Zentao）讓大家使用。

並負責向各部門做系統的教育訓練、指派 Key man 協助推廣。

導入專案管理系統後，資訊就變得透明化，大家都可以更有效地掌握任務時程、討論過程、工作進度、負責人員等。

儘管其他部門一開始都還是把任務指派給我，但我可以等工作到一個段落後，再來統一處理；並轉移一些任務給同事，而不是自己一個人傻傻做到死。

在各部門同事熟悉專案管理系統的操作後，我就要回了自己的時間。

這邊要特別感謝主管與執行長的支持
這個故事表面看起來很輕鬆，但剛開始在內部推專案管理系統的阻礙超大，因為這是在改變所有人過去的做事流程。
而且專案管理系統會讓一切執行中的任務都「透明化」，讓混水摸魚的人原形畢露，所以部分資深員工的反對聲浪尤其大。
有時就算有更好的方案，大部分的人還是喜歡用自己習慣的流程。
所以推行初期，專案管理系統只在自己的部門內使用。
執行一段時間，主管將成效報告給執行長，執行長對結果很滿意，才下令各部門必須強制推動。
一個組織的改革，單靠員工的努力是不夠的；一定要有高層的協助，才會進行得順利。

建立文件系統，縮小資訊落差

隨著部門持續擴張，我發現自己一直在做重複的事：

• 設定電腦開發環境
• 介紹合作夥伴的工作執掌
• 講解系統架構與操作流程
• 說明技術框架與開發規範

而且這些資訊就算說過一遍，新進人員往往同一個問題還會問好幾遍。

為了改善這個狀況，與主管討論後，我便開始著手建立新人的教育訓練文件；並將專案使用到的技術、常遇到的問題、目前的開發流程，整理成有結構、方便查詢的技術文件。

這樣同事日後在遇到問題時，就可以先從文件找答案。

雖然寫文件很花時間，但只要建立好，他就具備「重用」的特性，不用浪費時間重複解釋。

而且人的記憶是不可靠的，就算是當事人，也可能在幾個月後就忘得一乾二淨，很多時候，建立文件是為了幫助未來的自己。

而且整理公司文件的過程中，發生一件有趣的事情！
我沈睡多年的作家魂突然甦醒了，所以把這些文件寫的鉅細彌遺、邏輯縝密。
寫完後覺得這些文件只給同事看太可惜，在把機敏資料移除後，我以技術分享文的形式發表在 Medium。
希望能幫助遇到相同問題的朋友們，從此開啟了自己的斜槓之路。
現在回頭來看，人生際遇真的很難說，但用盡全力的人肯定會有更多機會。

人生，是自己選擇而來的

有些人可能覺得做「份外」的事情很吃虧，公司又未必會幫你加薪升職。

但我認為這是在累積自己的底蘊，就算現在的公司看不懂你的價值，之後找一間懂你的就好了！

想進入優秀的團隊，你要先成為一個優秀的人！

另外找到自己職場的「定位」很重要，以我個人來說，比起深入研究單一領域，我更喜歡接觸不同領域的新知識。

「專才」也好，「通才」也罷，在有興趣與優勢的領域持續發展，定位就會自己出現。

我第二份工作做了 4 年多，今天的文章才講到一半而已。

在下一篇文章，我會分享自己是如何在一份工作中，從工程師做到專案經理，最後站上部門技術主管的位置。

以及如何透過談判，獲得超過 40% 的內部調薪。

今天的故事就分享到這邊，如果有給你啟發與幫助，可以順手按個讚，把文章分享給需要的朋友。

未來我會分享更多職場故事與生存技巧～

從《#工程師下班有約》出版那天起，我就一直想找個機會，把書裡說不完的故事，親口說給你聽。

👀 如果你也正在經歷

• 每天努力生活，卻不確定自己是不是走在對的路上
• 想離開現在的工作，卻遲遲不敢跨出第一步
• 想做點什麼不一樣的事，卻總被現實壓住夢想
• 覺得別人都很順利，只有自己還在原地打轉

那我想告訴你：「我懂，因為我也曾經這樣過！」

🎤 在這 90 分鐘，我會分享

一個技職科大體系出身的人，如何連滾帶爬、經過 15 年的努力，成為外商工程師、暢銷書作家、AI 講師。

這一路上，我做過哪些正確的決定，以及踩過哪些原本可以避開的坑。

我沒有要賣夢，只是想聊聊自己走過的路。

人生沒有標準答案，但或許我的經驗能給你帶來一些啟發。

7/26 我們不見不散

🖋️ 如果你有買書，歡迎帶來找我簽名。

如果你只是剛好感到迷惘，也很歡迎來聽我說說這一路的故事。

• 📅 時間: 7/26（六）13:30～15:00
• 📍 地點: 台北市中正區重慶南路一段 105 號 2 樓（天瓏書局 Coding Space）
• 💰 費用: 免費參加（名額有限，請儘早報名）
• 🔗 報名連結: https://reurl.cc/1KnDN8

如果你正在卡關、也在找路，我很想把這段路怎麼走過來的故事，親口說給你聽。到時現場見吧，我會在那邊等你。

《工程師下班有約》網路書店： 🐲天瓏書局

我是林鼎淵，如果覺得這邊文章對你有幫助，歡迎追蹤筆者的 Facebook 與 YouTube，我會持續分享實用的新知識 💡

我把出書當成一個專案，從選擇、策略、執行力等面向，解析自己是如何取得第一名的。

這個月的排行榜上，第二、三、四名全是 AI 主題的書。

而我這本《工程師下班有約》，卻是談職涯、談選擇、談那些沒人說出口的事實。

我知道這不是市場主流的選題，但我是個有點叛逆、又有點浪漫的人，總想嘗試和趨勢不一樣的事。

沒想到這次，我做到超乎原本預期的成果！

我不是為了「出書」，而是為了「說點什麼」

這是我出版的第七本書。

但這一次，我不再只是單純地「完成一本作品」，而是想把自己探索人生的過程，説給更多人聽。

我知道光靠自己是不夠的。

所以就算害怕麻煩別人，我還是選擇開口請求協助。

我把這次的出版，當成一場必須全力以赴的挑戰，並在心中默默設下一個 KPI：「要衝上排行榜，讓故事被更多人被看見。」

推薦序的背後，是我與每一位作者的連結

這次我邀請了 9 位曾陪我走過人生不同階段的人，幫我寫推薦序。

不是因為他們有名，而是因為他們和我有故事、有連結。

我相信，一段推薦如果沒有情感作為支撐，讀者是能感覺出來的。

我希望，這本書像一場接力，而每一位曾經幫過我的人，都是這本書的共同作者。

「時間」也能是一種策略

我選在月初開放預購，因為我知道要拼月排，就得讓每一筆銷售發揮最大的效益。

第一波，我沒有選擇大張旗鼓，而是從與我連結最深的 LINE 社群開始。

那些七八人、幾十人的群組，是我日常交流最多的地方。

人不多，但彼此熟悉、有信任感，這才是最有力量的起點。

多點曝光，讓陌生人也開始相信我

當週排有了成績後，我開始請寫推薦序的朋友們幫忙分享。

因為我們有很多共通朋友，有些人可能第一眼滑過沒感覺，但第二次、第三次看到來自不同人的推薦，就會開始好奇：「這本書，到底在說什麼？」

廣告不是一次打動人，而是一次次被看見後產生信任。

封面「不像科技書」的科技書

我找了圖文創作者「寶寶不說」來設計封面。

這個風格，有點可愛、有點彆扭，和主流科技書的冷調截然不同。

我相信，封面是讀者與書的第一次對話。

如果這對話足夠特別，也許能為這本書爭取一點「被打開」的機會。

利用直播活動，讓更多人「看見我」

書籍上市後，我接受《資料科學家的工作日常》邀請，上了一場直播。

這讓我可以在很多禁止貼商品的 FB 社團中，用「活動」的名義進行曝光。

直播不只是行銷，而是讓人對我有更多的理解。

這比一張單薄的廣告文案，更能讓人產生信任。

有了回放影片後，我還能再貼到社團、Dcard，讓自己再次被看見。

用一場發表會，說出我藏在書裡的話

最後一天，我同步宣傳了 7/26 即將舉辦的新書發表會。

我知道，有些情感是文字表達不出來的。

所以我想邀請你，來現場聽我說那些故事背後的故事。

如果你也正在思考職涯、懷疑自己是不是走在對的路上，

也許這 90 分鐘的對談，我們會在彼此的故事裡，看見答案的一角。

結語

我其實不是個擅長行銷的人，也常常在傳訊息、發文前，反覆斟酌字句，怕打擾，也怕讓人誤會我只想「賣東西」。

但我想，如果我連自己都不相信，那這本書就不會有機會被認真對待。

感謝所有曾經幫助、轉發、支持過我的人。

在 AI 書籍霸榜的世界裡，還能有一本談職涯的書被注意到，我知道這不是我一個人的功勞。

🧡 如果你對這本書、這場直播、這場發表會有興趣，下面是我整理好的連結：

• 📽️ 回顧影片: https://reurl.cc/7KZOzD
• 📖 書籍資訊: https://reurl.cc/dQdR4y
• 🎤 報名連結: https://reurl.cc/1KnDN8

歡迎你留言或私訊，和我說說你下班後的人生故事。

《工程師下班有約》網路書店： 🐲天瓏書局

我是林鼎淵，如果覺得這邊文章對你有幫助，歡迎追蹤筆者的 Facebook 與 YouTube，我會持續分享實用的新知識 💡

小弟出版《工程師下班有約》後，受「資料科學家的日常」邀請在直播分享自己的經驗。

👤 關於我

目前在外商公司擔任 Software Specialist，做過工程師、專案經理、技術主管等職位。

從 2020 年開始將經手過的問題與技術分享到部落格，至今已發表超過 400 篇科技專欄、技術文章，累計瀏覽數超過 4,000,000 次。

出版過 7 本書籍，主題橫跨網路爬蟲、工程師職涯、AI 工具應用等多個領域，並連續兩年入選年度百大暢銷榜。

同時也是一名講師，擁有超過 60 場企業內訓、校園講座的經驗（中華電信、精誠資訊、勞保局、臺藝大、北科大…）。

曾與商業周刊、遠見雜誌、T 客邦等多個平台合作，開過 10 堂線上課程與實體工作坊。

🎙️ 直播內容

工程師是我的職業，但不是我的人生。

💥 這場直播，你會聽到：

• 如何讓自己成為一個「特別」的人
• 為什麼要把自己當「公司」在經營
• 怎麼讓「斜槓」成為職涯的助力
• 工程師在 AI 時代的「價值」在哪

✅ 如果有以下問題，千萬不能錯過這場直播：

• 帶著疑問想尋找職涯方向
• 受夠只會畫大餅的講座，想聽點實話
• 想知道失敗的共通點，不是只看成功範本
• 願意接受現實，想為下一次機會做好準備

現實生活就是金字塔結構，成長的路也許有捷徑，但絕對不會輕鬆。

直播回放:

「工作」≠「職涯」把自己當一間公司在經營 | 開箱 #第一線資料科學工作者 系列活動 #40 ft. @dlcorner

《工程師下班有約》網路書店： 🐲天瓏書局

我是林鼎淵，如果覺得這邊文章對你有幫助，歡迎追蹤筆者的 Facebook 與 YouTube，我會持續分享實用的新知識 💡

今天收到幾位朋友私訊，恭喜我新書《工程師下班有約》取得 #週排第一

但其實我心情很複雜，因為這是本差點就不存在的書。

今天，我想和你聊聊這個故事背後的故事。

如果很難超越過去的自己，你還會繼續挑戰嗎？

寫這本書前，我已經出版過 6 本專業書籍，涵蓋網路爬蟲、工程師職涯、AI 應用等領域。

並連續兩年入選年度百大暢銷書，於 2023 年在天瓏書局取得年度銷售第三的成績。

之所以能拿到這個成績，是因為我搭上了 AI 的順風車；但老實說，這個成績就像是一座山，在銷售量上，我很難超越過去的自己。

所以我原本打算就此封筆，讓成績停在最好的時刻。

我買了你所有的書，但沒一本有看完

不過人生總是充滿著「但是…」

在某個下班後的聚會上，朋友酒過三巡後問了我一個問題：「我們工作的年資差不多，我認為自己也很努力；但為什麼現在的差距這麼大？我好羨慕你的運氣！」

大多數人面對這類問題時，都會順著對方的話，謙虛的把成就歸功於「運氣」

但當時酒喝得有點上頭，所以我的回答是：「我這一路是怎麼走過來的，你應該也看在眼裡。中間也許有運氣的成分，但大部分人只要跟我做出相似的選擇，我不敢說能取得相同的成果，但肯定能獲得不凡的經歷。」

講完這段話後，我彷彿像是個喜歡「憶當年」的老兵，開始分享自己的故事。

那一晚，我們聊了很久。

回家前，朋友對我說：「就算一路看著你成長，我也不知道背後有這麼多的故事。你有沒有考慮把他寫成一本書？就叫下班有約之類的？」

頓了一下他繼續說：「為了支持你，過去你出的書我都有買；但老實講，我沒一本有看完。但你今天分享的故事太精彩了，橫跨人生、職涯到斜槓的議題。沒有要恭維你的意思，但這些故事給我很多啟發，所以聊到現在我的精神還是很亢奮，我很期待它變成書的那天。」

工具與方法會過時，但經驗永遠有參考的價值

聚會結束後，我就開始準備這本書的草稿了。

而出版社的編輯在冥冥中似乎跟我有種默契，才剛把大綱擬好，就收到編輯的出版邀請。

其實一開始出版社希望我繼續出版 AI 工具應用的書籍，但我跟編輯說：「雖然現在市場上 AI 主題的書籍賣得最好，但工具更新的速度太快了，把幾週前的最佳方案放到現在來看，可能已經過時了。下一本書，我更希望分享一些個人的經驗故事，畢竟現實世界發生的事沒有絕對的對錯，只有當下最合適的選擇。」然後將準備好的大綱傳給編輯。

編輯與總編討論後，我們對這本書的方向達成了共識：「以故事的形式，呈現每個決策背後的思維與掙扎；除了分享成功案例外，更著重於 #失敗後的檢討與成長。」

來自 12 年前的建議

動筆寫這本書時，我不禁回憶起 12 年前的自己。

其實早在 19 歲，我就完成了一本十萬字的小說；但投稿到各大出版社後，全都石沈大海。

儘管沒得到任何回覆，但我依然覺得自己的作品是個千里馬，只是欠缺一個伯樂而已。想當年哈利波特的作者 JK 羅琳，不也被出版社拒絕過 12 次嗎？

所以接下來我從網路搜集了許多知名人士的 Email，然後把小說稿件像是病毒郵件般的傳送給對方（厚臉皮與自信，在任何一個時代都很重要）。

經過不懈的努力後，終於有作家願意看我的作品，並給了建議：「你這本書的內容太淺了，而你現在做的事，就像個剛出生的寶寶想要證明自己一樣；如果真的想寫出好故事，先去累積自己的人生閱歷吧。」

這段話對我有很深的影響，因為他讓我領悟到：「這世界沒有那麼多的懷才不遇，更多的是自己沒有本事。」

這世界根本不存在輕鬆的路

翻開這本書，我的第一句話是：「我花了十五年證明自己，才累積了一本書的故事。」

不管過去累積了多少里程碑，直到現在的此時此刻，我都還走在證明自己的道路上。

近幾年「短影音」給了很多素人機會，「AI 工具」讓所有人可以加速效率。

但能把握這些機遇，創造收入的人，往往都已經是各領域的翹楚，而不是所謂的「0 基礎、人人都可」。

不要妄想靠一點小技巧就能翻轉人生，日積月累的實力才是你的靠山；因為機會永遠都有，但前提是你配得上它，技巧只是在關鍵時刻推你一把的臨門一腳。

《工程師下班有約》網路書店： 🐲天瓏書局

我是林鼎淵，如果覺得這邊文章對你有幫助，歡迎追蹤筆者的 Facebook 與 YouTube，我會持續分享實用的新知識 💡

如果你在尋找人生的「標準答案」，那這本書不適合你。

如果你在追求「快速成功」的秘訣，那這本書幫不了你。

如果你只能接受「正向思考」，那這本書會讓你玻璃心碎裂。

我不靠寫作賺錢，因此本書的內容不會討好任何人，甚至可能會得罪不少人（反正帳號被檢舉到停權這種事，我已經體驗過了）。

請不要用傳統的二元對錯觀來看這本書，因為善與惡是相對的，一切都是個人選擇。

雞湯文幫不了你，只能安慰你

如果用「出社會 8 年，年收成長 600% 的秘密」來當書名，或標榜「人人都能做到」能吸引更多受眾。

但任何成功的背後，往往存在嚴重的倖存者偏差，所謂的「秘密」，也未必適用於所有人。

現實世界沒有完美解答，只有當下最合適的選擇。我希望透過自己真實的故事，讓你看見我的困惑與掙扎，幫助你思考自己人生的選擇。

這本書適合這樣的你：

• 帶著疑問想要尋找人生方向（不是答案，因為只有你能為自己的人生負責）
• 比起成功的經驗，更想了解失敗的共同點
• 受夠畫大餅式的雞湯文，願意接受現實世界的殘酷
• 想在機會出現時，擁有決策的能力

人生際遇的隨機性太高，雖然你帶不走我的經歷，但可以參考我的「視角」，並思考如果換作是自己，你會怎麼做？有沒有更好的方案？

現實生活就是金字塔結構，成長的路也許有捷徑，但絕對不會輕鬆。

這世界沒有奇蹟，只有累積

我不會告訴你「快速成功」的秘訣，但會分享如何辨識自己的潛能，發掘與生俱來的「不公平優勢」，從而走出一條專屬於自己的道路。

我的本業是工程師，但同時也是講師、作家、魔術師、部落客。

「工作」不等於「職涯」，如果想獲得更多收入，提升專業能力只是其中一個方法。不要把自己侷限在特定角色，或認為自己「只能」做某些事。

活在同溫層中，我們容易誤以為自己看到的就是全世界。儘管無法去經歷別人的人生，但能透過故事看見不同的選擇。

一個人可以走得很快，但一群人能走得更遠

出版第一本書的時候，因為不想欠人情，所以沒請人幫我推薦。

但這次請了很多人寫推薦序，有指導過我的老師、對我影響深遠的學長、幫我很多的同學、時常交流的朋友、可靠的同事…

畢竟我能走到今天，離不開他人的支持與協助。

而且我想通了：「請對方幫忙， 是在創造下次對方找我幫忙的機會。」這樣一來二去，彼此的交情會更穩固。

這是一本既「世俗」又「誠懇」的書，畢竟我們生活在一個充滿「人」的世界。

了解如何借力，成為彼此的槓桿，人生才有更多選擇的自由。

結語

努力從來不是為了變成別人，而是為了成為更自在地自己。

『如果你正在尋找一種新的可能、一點向前的勇氣，或是一條從未想過的路，相信這本書能為你帶來靈感與啟發。』

《工程師下班有約》網路書店： 🐲天瓏書局

我是林鼎淵，如果覺得這邊文章對你有幫助，歡迎追蹤筆者的 Facebook 與 YouTube，我會持續分享實用的新知識 💡

因為經歷高度相似，所以我們遇到的選擇、機遇、困境也很雷同。

自認記憶能力有限，所以透過文字紀錄彼此的觀點。

珍惜願意與你分享真實資訊的朋友 💡

這次聚會讓我深刻體會到，能交換「真實」資訊的朋友是多麼珍貴。

隨著年紀增長，我們學會了保護自己；因此總是語帶保留、點到為止。

但很多時候，最重要的就是那些「被保留」的關鍵資訊。

有些人覺得網路這麼發達，什麼資訊都能找到；但實際上很多資訊都是碎片化，或是被人為美化的。

拿著片面資訊做決策，你可能會搞死自己。

定價策略與市場認知 📈

聊到課程接洽的經驗時，我們討論了與管顧公司合作的利弊。

如果是你自己跟企業洽談，可能收入為 8000 元/小時。

但如果改由管顧公司來接洽，也許收入會下降到 6000 元/小時。

從帳面上來看，每小時少賺 2000 元；但管理顧問公司的抽成往往有 4 成左右，也就是在企業眼中，你的價值是 10000 元/小時。

把時間拉長，這種合作能提升講師的市場價值與知名度；日後有企業來找你時，你也能很自然的提高報價。

不同窗口用不同的報價策略 🔄

企業可能透過內部的 HR、業務（特助）來邀請講師。

如果對話的窗口是 HR，那報完價後，可以詢問一下是否符合他們的預算。

因為 HR 找人時往往有多個名單，最後沒有選擇你有可能只是預算上的考量。

但如果對話的窗口是業務（特助），你可以放膽報高一點的價格。

因為他們來找你，通常不是因為這個主題需要一個講師，而是希望由「你」來當這個主題的講師。

即使報價超過預算也會與你商議，因此你有更高的機率爭取到不錯的講師費。

都會踩到坑，只是遲與早 🎯

講師的授課能力，基本上與授課次數成正比。

因為只有踩到足夠多的坑，才知道發生意外時要如何應對，或是向誰尋求協助。

像在這次聚會中我才知道，原來 Google Drive 上的檔案如果在短時間內被大量下載會卡死。

人生路上有很多坑，如果提早知道就能事先找出對策。

堅守品質與道德底線 🌟

我們一致認為，堅持自己的底線非常重要。

有些自媒體為了增加曝光度與收入，會透過誇張不實的標題與封面來吸引點閱率、促購。

但這種做法實際上是在損害讀者對你的信任（雖然總是有新的韭菜）。

因為自媒體對我們來說只是斜槓，所以我們更在意內容與標題的一致性，不想做出違反內心的決策。

希望大家遇到能與自己深度交流的朋友 🤝

希望這篇文章能讓更多人意識到，並珍惜生活中那些寶貴的連結。

透過真誠的分享和交流，彼此都能共同進步和成長 ✨

推薦大家追蹤資安大佬 HackerCat，不定時會分享很棒的文章！

如果你對目前的職涯感到迷茫，想從不同視角檢視自己的選擇，相信《工程師下班有約》這本書能為你帶來靈感與啟發：

對不了解系統上線流程的人來說，他們會覺得這不過就是個小調整，為什麼每次都要我三催四請的？

對開發的工程師來說，他們會覺得這些人有完沒完啊？這些文字不是都已經討論過了，為什麼每隔幾天，甚至幾小時就要改一次？

實際上，改動文字對工程師來說可能花不到 1 分鐘的時間。

但對有上版流程的公司來說，每次更新可能都要花 1 小時以上（就算只有改一個字）。

今天這篇文章不是要談誰對誰錯，或是如何用技巧來迴避問題；而是要分享面對問題時，可以如何一步步「解決」他。

文章寫完後，感覺自己在寫技術發展史；另外，這是朋友向我分享的經驗，絕對不是我自己的。

石器時代：寫死在程式碼

在最遠古的時期，網頁上的文字是寫死在程式碼的。

雖然直觀，但維護性極低。

因為面對「修改文字」的需求變更，開發人員可能改了 A 頁面，卻忘了還有 B、C、D 等頁面也用到一樣的詞彙。

大航海時代：建立語言包維護

如果系統只用同一種語言，那寫死在程式還勉強能維護。

但如果接下來要進軍國際市場，有中、日、英、法等多國語系的需求時，我想工程師就會崩潰了。

因為寫死在程式碼是完全行不通的，雖然很痛苦，但開發人員會需要把系統中所有的文字抽出來，建立「語言包」來維護才能解決這個需求。

這樣未來在面對「修改文字」的需求變更時，開發人員只要在單一檔案處理，透過模組化的管理，可以大幅降低遺漏的可能性。

工業時代：提供 Google Sheet 讓產品方填寫

把文字集中到語言包維護後，其實面對修改文字的需求就很容易處理了。

但…接下來要討論的是「人」的問題。

因為產品方會一直看系統的文字，看著看著可能就覺得哪裡不順眼，不順眼就要改！

所以在新版本上線後，可能一週內會收到多次文字變更的需求。

在這樣的狀況下，現實生活中最容易遇到的就是「漏訊息」；當訊息有前後因果關係、重複資訊的時候，失誤在所難免。

為了減少產品方打擾 PM 與工程師的頻率，以及減少訊息遺漏的問題。

提供一份格式律定好的 Google Sheet，讓產品方在線上「修改文字」是一個不錯的方案。

這樣雙方約定一個時間一次性更新即可（會跑一個將 Google Sheet 轉成語言包的腳本）。

科技時代：直接透過管理介面修改文字

改成 Google Sheet 後，雙方和平了好一段時間。

但還有一個問題，那就是這種修改沒有「即時性」。

因為程式每次上版都需要 Build Docker Image、跑回歸測試、上多個環境確認…

你可以理解為這些步驟至少要花費一小時以上的時間，而且會涉及到不同團隊的人（開發、QA、PM…）。

如果今天只是要修改文字，這樣的操作完全不符合成本效益。

所以目前的最新方案，就是在後台管理介面中，新增修改文字的功能，讓產品方可以依照自己的需求即時進行調整（搭配預覽頁）。

總結

修改文字是一個常見的需求變更，而且很多時候是在系統上線後才發生。

對工程師來說，修改文字這件事的確很簡單，但背後所需花費的時間與人力成本其實很高。

相信看完這篇文章後，大家可以理解為什麼有些小變更需要等一段時間才能更新。

儘管這篇不是純粹的技術文，但還是提醒一下讀者，每個時代的演進都需要不少時間成本。

這些改進所用到的技術並不困難，但問題在於：

• 有足夠多的時間來做優化嗎？
• 這個問題真的有優化的必要性嗎？
• 優化帶來的效益符合成本嗎？

因此千萬不要看完這篇文章後，就拿他去跟工程師吵架，我可不背這個黑鍋。

也許最後的方案在不久後會遇到其他挑戰，但這不就是「有問題我才有工作嗎？」

是因為 AI 不紅了嗎？不！是因為大家已經逐漸「習慣」AI 的存在🤖。

AI 對你的幫助愈大，你愈要警惕 🚨

前陣子聚會時，有個工程師朋友問到：「你未來職涯規劃會持續寫程式嗎？還是有別的打算呢？如果只會寫程式，感覺撐不過下個世代。」

面對這個問題，其實我深有感觸；因為這一年來，AI 給我的工作帶來非常大的幫助💡。

甚至可以這麼說，在演算法優化、程式重構、SQL 撰寫、DB 規劃、Unit Test、變數命名等任務上，AI 已經做得比絕大多數的工程師更好👍。

AI 對你的幫助愈大，其實你愈應該去想：「我會不會哪一天就被 AI 取代？我會不會被其他更擅長使用 AI 的人取代 🤔」

如果高度專業的技能也被 AI 取代 🔄

下面舉一個朋友的案例，他是一個年薪近 300 的工程師，之所以可以領到這個薪水，除了熟悉產業外，另一個重點是他非常熟悉組合語言💰。

如果你不知道什麼是組合語言，就把它想成 20 個人努力去學，最多就 1 個人能夠理解並掌握的技術。因為人才稀有，所以都是高薪職位。

原本朋友覺得自己可以靠這個稀有技能爽爽做到退休，但今年 3 月時，他開始焦慮了，因為他發現過去只有少數人能掌握的組合語言，對 AI 來說根本沒有難度🤯。

也就是說，如果公司意識到這件事，基於人力成本考量很有可能把他給 Fire；然後請一個熟悉這個領域，並對組合語言有基礎理解的人來取代他。

解決問題的能力會更加重要 💪

也許在 3 年內，現有的開發生態會被 AI 顛覆。

對過去的工程師來說，寫出優秀的演算法、易讀性高的程式非常重要；但現在，能夠判斷出演算法的好壞、程式的可執行性會更加重要。

而在未來，也許工程師的價值會變成解決複雜的商業邏輯、分析多個系統的資料流，有能力判斷不同方案的 Trade-off（權衡）；而撰寫程式這件事的比重會下降非常多。

因為新手工程師較難判斷 AI 答案的品質與正確性，所以未來企業在徵才時，與其僱傭新手工程師，不如僱傭會用 AI 輔助開發的資深工程師（純屬個人猜想）。

要對本質有更深刻的理解 🤓

下面分享一段朋友說的話。

前幾年 Golang 很火，相關職位的薪水都比其他程式語言來得更高，所以就有人一窩蜂地跑去學 Golang。

不過朋友是這麼說的：「這份專案用 Golang 寫，是因為面對這個需求時，Golang 的效能比較好而已；我花一個禮拜寫完這個專案，而 Golang 我才接觸兩個禮拜。」

這段話要表達的不是 Golang 很好學，而是當你對程式的本質有深刻的理解時，程式語言只是一種工具而已。

想要讓 AI 給你最大的幫助，你本身就需要具備對應的知識水平。

選擇比努力重要 🎯

這篇文章要傳遞的並不是「工程師已死、工程師將被 AI 取代」這類訊息。

而是想表達「是時候思考自己的下一步了」，因為人的時間有限，只有分配到對的位置才會有最大效益。

過去只要會寫程式就能混口飯吃，但在 AI 的時代，你還需要具備其他重要的多元化技能（團隊合作、溝通表達、產品思維…），讓自己更難被取代。

這篇文章僅是我對產業的粗淺了解，歡迎大家交流彼此的想法，有不同的聲音，才有更全面的觀點，謝謝🙏。

想將 AI 導入自己的職場與生活嗎？歡迎購買筆者出版的新書，幫助您在 AI 的浪潮中站穩腳步，並在未來的職場競爭中佔據優勢！

在上完「設計思考全方位」的第一堂課後，我發現，設計的理念超越了技能和背景，它更像是一種生活方式。

設計思考：解決問題的新策略

大部分的人都依賴直覺和經驗來應對生活和職場的挑戰，但設計思考提供了一種更加系統化、深入的策略。以一個日常例子來說，當家中的雞蛋用完，你如何計劃購買？

➤ 釐清需求：選擇雞蛋的類型 — 追求經濟還是品質？

➤ 定義問題：選擇購買地點和交通方式 — 市場還是超市？步行還是開車？

➤ 附加價值：除了雞蛋，還需要購買哪些食材或生活用品？

🥹 如果沒有想清楚，你可能會把事情拆成好幾次來做，比如：

➤ 在超市買完雞蛋後發現需要買肉，然後再跑一趟大賣場，隔天發現衛生紙用完了，需要再跑一趟超商。

但上述任務是可以「一次性」解決的。透過「設計思考」，我們不僅能解決問題，還能進一步優化流程，讓日常生活更加合理。

用「同理」來平衡商業與創作

出社會後，你的創作不能只考慮到「自己」，還要考量到「客戶」與「消費者」。

站在自我成長、自我實現的角度，你可能會想使用最新的技術、時下流行的設計；但可能會遇到題材不適合，或是想法太前衛客戶無法接受。

為你設計買單的是「客戶」，帶來商業價值的是「消費者」，但這兩者的想法可能有很大的衝突。以電影的廣告來說，滿足導演期待的內容可能太過深奧、無聊，滿足消費者的又太沒氣質、商業。

「自己 VS 客戶 VS 消費者」是一個商業與創作的三角，如果想做到「同理」，你就要跳出這個三角，從旁觀者去思考會更明白自己應該要去做的事，正所謂「當局者迷，旁觀者清」。

即使主題相同，也都有各自的風格

像「憤怒」這個情緒，他在每個人身上呈現的方式是不同的。有些人使用暴力、有些人選擇沈默、有些人笑的讓你發慌。

所以我們不妨思考一下，我的憤怒跟別人的憤怒差在哪裡？如果用顏色、線條來表現，會長什麼樣子？

這個道理可以套用在不同的領域中，如果你常逛「購物網站」就會發現，儘管 PCHome、MOMO、蝦皮都是購物網站，但彼此的風格有很大的差異；因為 TA 的年齡層、性別、喜好都不一樣。

在面對需求時，如果能快速判別出這些與競爭對手不同的點，就更有機會取得成果。

回答「我覺得這樣比較好看」很不專業

如果問設計師為何這樣設計，而他只回你：「我覺得這樣比較好看。」

如果繼續細問還是無法給出具體邏輯時，設計師可能根本沒搞清楚自己在做什麼東西。

以網頁設計來說，每個元件的大小、顏色、間距、位置、層級，都有它背後代表的含義，而不會只是「我覺得這樣比較好看」。

如果遇到沒有 Sense 的客戶

不要期待客戶擁有跟你一樣的專業，不會表達自己需求的客戶才是大多數。

為了減少分歧，你要先了解客戶對作品的期待，而不是先入為主的認為這個主題應該要怎麼做。

如果遇到意見衝突，可以從三個面向來嘗試溝通：

• 客戶對作品的期待：有些案子的時程比較長，客戶根本忘記當初自己說了些什麼，你可以把情境再來回來一次。
• 消費者的想法：嘗試讓客戶扮演消費者，用不同的角度來看規劃的合理性。
• 設計師本身的專業：說明自己設計的邏輯、理由，以及可以帶來的效果。

有些客戶可能需求是：「我想要做獨一而二，沒有人做過的嘗試！」

遇到願意讓自己隨意發揮的客戶很幸運，但站在設計師的角度來講，應該把他拉回來，畢竟產品是需要賣錢的（如果不在乎錢的客戶當我沒說）。

而且設計也不要完全按造自己的喜好，以平面設計來說，假如要設計一個 Logo、圖案；在配色、線條上可能要思考它是可以在不同媒材上可以展現的嗎？

因為活動、品牌時常會出一些周邊產品，他在毛巾、扇子、瓶子上面都是可以呈現的嗎？會有需要特殊印刷導致增加的成本嗎？

如果到最後生產時才突然多出這些成本，是會 GG 的。

設計合約時，先設想最差的狀況

建議簽約時要有附加條款：「在產生初稿後，如果有巨大的修改，可以有 N 次修改的機會；若超過則會需要增加多少錢。」

設計合約時，要先思考的不是這個專案會完美結案，要去思考最糟糕的狀況可以如何處理、自己犯錯的時候怎麼辦。把所有最壞的情境都考慮到後，我們更有可能完美的完成專案。

PS. 如果特殊情境沒時間簽約，那請在 Email 留下紀錄，不要在 FB、LINE 這類可以移除訊息的軟體上溝通。

容許失敗、面對失敗、持續試錯

為什麼研發會很貴？因為研發就是不斷地試錯！

好的作品背後往往有無數次的失敗經驗，與其去研究成功作品有哪些元素，不如探討他背後經歷了哪些失敗。

面對失敗的心態很重要，我們不需要自我否定。 先承認自己是一個人，而絕大多數人都是一般人，犯錯是難免的事，很少有發生一個失誤人生就直接完蛋的情境（除非按到核彈發射按鈕）。

不要妄想去建立一個完美人設，不然遲早會翻車。不要想把每個作品都做到淋漓盡致，那只會逼死自己。

以上就是「設計思考全方位」第一單元的心得筆記，如果覺得我的分享對你有幫助，歡迎 Follow 我吸收更多知識。

我希望可以跟著興趣走，一開始的打算，是去出版社或魔術公司。

會想去出版社，是因為我對文創產業充滿嚮往，甚至在大四時，為了瞭解這份工作需要面對的事物與技能，我還在天下文化當了一個學期的志工；不過在退伍後，當我詢問編輯是否有合適的職缺時，他語重心長的勸我：「我強烈建議你選擇工程師的職涯，因為出版社有很多事情跟你想的並不一樣，即使在這裡幫忙過一段時間，也只能看到非常片面的資訊；你曾說過自己有出版的夢想，那我更不建議你來這個產業。」

而魔術公司，則是因為我對魔術充滿熱情，覺得能透過教學、表演來賺錢，是一個將興趣融入工作的方式，去應徵時甚至還獲得了 Offer；但最終因為家庭經濟因素而放棄了這個機會，繞了一圈還是選擇了老本行 — — 工程師。

如果把時間軸拉到現在，我會很慶幸自己當年有必須面對的經濟問題，讓我不得不選擇工程師這份工作；但在當時，我是很心不甘情不願踏上工程師這條路的。

我們對產業的認知，比自己想像的還要更少

因為不確定讀者是否會看到最後，所以我把總結放在文章開頭。

年輕有摸索未知事物的本錢，但這並不代表我們可以隨意揮霍自己的青春。

人會對一個陌生的產業感到嚮往，通常是因為看到一些成功案例，然後覺得自己有機會跟他們一樣；但實際上我們對產業的理解非常片面，而且通常只注意到好的那一面。

如果在認知不足、缺乏專業技能的狀態下，跳進一個自以為熟悉的產業，那往往會以悲劇收場；因為在進去後，你會發現事情遠沒自己想的那麼簡單，跟周遭有專業能力的人相比，自己就像是另一個世界的人。此時，高壓、高工時、挫折、自我懷疑等負面情緒，會如潮水般席捲而來。

絕大多數人都挺不過這個時期，但少數挺過的人會被當作「成功案例」來炒作、宣傳，這容易讓人誤以為跳進這個產業沒什麼風險。

筆者不是要打擊大家的信心，但凡事不能只看成功案例。

如果想嘗試一個產業，其實沒必要賭上身家辭職去做，那些沒給自己留後路的人，通常最後都過得很辛苦；至少筆者是沒有那種背水一戰的勇氣，所以都是用斜槓的方式，來探索自己感興趣的產業。

沒成為職業魔術師，但辦過公演，發表過產品

有些人會好奇：「工作都這麼累了，怎麼還有力氣做其他事情？」

從筆者的角度來看，如果下班後沒力氣研究自己感興趣的產業，那你應該先思考自己是不是真的對它感興趣。

說實話，連下班時間都不願意投入了，要背水一戰時真的有辦法全力以赴嗎？

就拿自己當範例，在成為工程師後，儘管工作極度繁忙；但我在每個月加班超過 40 小時的狀態下，還是持續錘煉自己的魔術技能，甚至在花式切牌領域達到相當高的水平。

Dean Lin/花式切牌/Cardistry/Playing Card/紙牌藝術/XCM/極限紙牌

為了提升自己的魔術水平，我加入了由愛好者組成的魔術社團。這個社團的成員以社會人士為主，儘管每個人入社的理由不同，但都是因為魔術而聚在一起；如果你想進步，在「合適的環境」中能得到很多的建議與幫助。

我在這個社團參與過 3 次成果發表，並擔任過 1 年的社長。加入這個社團應該是我魔術成長最快速的時期，如果能與興趣相符的人定期交流，你的成長會超乎想像。

隨著魔術水平的提升，我的表演也逐漸從「模仿」成長為「創造」。

在 2019 年，我與職業魔術師合作，發表了一款心靈魔術 App；我想如果沒有工程師的背景，就算有魔術領域的人脈與知識，也很難孵化出這個產品。

DL Note by 寶哥Baogo &林鼎淵 國際版(int'l)

這幾年的疫情重創了表演藝術產業，許多朋友在疫情期間幾乎接不到 Case，迫於經濟壓力，不少人選擇轉行；好在最近有逐步好轉，街頭藝人也開始上街表演，如果覺得表演精彩，在經濟能力許可的前提下，不要吝嗇自己的打賞。

沒進出版社，但出版過兩本書籍

從高中開始，出書這件事就一直待在我的夢想清單。

為了這個夢想，我從 19 歲開始積極投稿各大文學獎，嘗試過短篇小說、長篇小說、散文等各式題材，但 3 年 23 場比賽下來，從未斬獲任何獎項。

當工程師後，我以為這個夢想已經沒有實現的機會了；但有時命運的羅盤還是要靠自己掌握。

2020 年 6 月，我奉命撰寫交接文件，一般人對交接文件的態度就是交差了事😏；但當時的我竟燃起了作家魂，把這些交接文件寫的鉅細彌遺、邏輯鎮密。

寫完後覺得這些文件只給同事看真的太可惜，所以把機敏資料移除後，我以技術分享文的形式發表在 Medium，希望能幫助遇到相同問題的朋友們；不過儘管我寫得很認真，但實際上根本沒什麼瀏覽量。

中間甚至有一年半的時間，我 Medium 帳號的追蹤人數比發文的數量還要少…這段期間我真的極度崩潰，懷疑是不是因為內容不夠好所以才沒人看。

創作者要的不多，只是希望有人可以認同他的付出；你的「Follow」與「👏🏻」能給我們帶來非常大的鼓勵。

但在懷疑的過程中我從未放棄，而是不停嘗試新方向，下面這張是今年 11 月的截圖，儘管這個瀏覽量跟大神比起來還是差很多，但跟 2 年前的自己相比，已經成長了 100 倍。

我這兩年來做過如下嘗試：

1. 調整發文頻率，一個月發表十幾篇文章。
2. 擴增主題豐富性，除了技術文外，我還撰寫了「講座心得、職場經驗、個人感悟、產業研究」等不同面向的文章。
3. 參加 iT邦幫忙鐵人賽。

前兩項主要是在鍛鍊寫作的基本功，真正讓我獲得實質回饋的是「參加 iT邦幫忙鐵人賽」，iT 邦幫忙是一個以工程師為主的社群，而這是一個需要連續 30 天發表技術文的比賽；如果文章受評審肯定得獎，就有機會與出版社合作，將比賽作品出版成書。

衝著「得獎出書」的賣點，我連續參加了 2020、2021 年的鐵人賽，並獲得 AI & Data、Software Develop 組的獎項；而得獎的作品也於 2021、2022 年出版，皆獲得不錯的銷售成績。

這些里程碑花不到 1 分鐘就能說完，但背後都需要付出海量的努力；我在每一屆的比賽都至少投入了 3 個月的時間，每天下班都在寫稿與測試程式，甚至假日還要反覆審稿確認內容是否有誤；而每本書都至少花費了 4 個月的時間，重新對內容編排、勘誤、擴增，盡可能讓讀者能從書中獲益。

但在出過書後，我便體悟到想單靠書籍的版稅過活，是一個幾乎不可能的任務；與編輯合作的過程中，我也了解到過去對出版社的理解過於片面。
喜歡一個產業，跟進入一個產業是兩件事。

機會是給準備好的人

在「機會」真正降臨到你的身上前，大多數人都不會認同這句話。

筆者原本以為出了兩本書，登上暢銷排行榜，已經算是自己人生的高光時刻；沒想到後續會收到「科技島」的邀請，讓我去擔任他們的駐站專家，每週發表自己的觀點。

講實話，過去我覺得這應該是業界的成功人士才會獲得的機會，我何德何能有這個榮幸；但遇到機會從不退縮的我，還是跟他們合作了，在合作後我便深刻體會到「資源」的重要性。

打個比方，我過去在 FB 宣傳自己的文章，觸及人數最多也就幾十個；但在科技島的幫助下，觸及人數在短短幾天就能達到幾百上千，有時甚至破萬，這個數據對過去的我來說是簡直是天方夜譚。

不過第一次獲得如此大的宣傳，也讓我對文章的內容更加謹慎，深怕傳遞不適合或錯誤的知識給大眾；因此每篇文章都花費了大量的時間反覆打磨，以保證文章在一定的品質之上。

寫文章給我稿費，又下廣告幫我宣傳；獲得這個機會時，我真的覺得是天上掉餡餅。

結語

這篇文章不是要炫耀自己的經歷，而是想告訴讀者，「工作」只是「職涯」的一部分。

筆者覺得透過「斜槓」去接觸一個產業，比辭去工作背水一戰更為合適；而且有時斜槓累積的經驗＆成果，能幫你在職涯的道路走得更遠。

當然我認為自己是比較幸運的人，畢竟有不少人經營了更長的時間，卻始終沒看到回報；有時是時機未到，但也可能是自己真的沒有這個天賦。

其實前期的顆粒無收，也側面說明了做自己感興趣產業所需要面對的風險；如果是斜槓，你可以繼續努力，但假使當全職做，一但放棄就幾乎不可能再繼續了。

希望今天的故事有讓大家看到職涯更多的可能性，下一篇文章就讓我們聊聊職涯規劃的議題吧！

筆者的第一份工作是專門接案的純軟公司，主要承接政府單位的案件；剛開始工作的第一年還可以正常上下班，加班也只是偶爾發生；但自從公司接到一個大案子後…

讓你當專案的主導者，是相信你，還是…

這份工作剛滿一年時，我便被指派擔任大型專案的主力開發工程師；一開始我以為這是主管對自己能力的信任，但與客戶開會後，我發現並不是這麼一回事。

這是一個總價超過千萬的專案，原本政府官員以為會有 10 人的團隊一起參與開發；但實際上，這片天我要一個人撐起（不過開會時會多找一點人充場面）。

我在這份專案中要十項全能，所負責的職務涵蓋：

1. 專案經理
2. UI/UX 設計師
3. 前端工程師
4. 後端工程師
5. 客服人員

基本上從一開始的需求訪談、Wireframe 設計、MVP 規劃、易用性測試…到上線後的教育訓練都由我來主導；負責這個專案時，我每個月的平均加班時數在 40 小時起跳。

但加班沒有加班費，在公司待太晚，老闆路過時還會跟你說：「公司給你筆電，就是希望你把工作帶回家，你不知道留在公司加班很浪費冷氣嗎？」
為了避免大家誤以為不給加班費很正常，筆者特別提醒一下，加班不給加班費是違反勞基法的！

客戶不滿意，就叫你立刻到現場給他罵

辛苦未必會獲得回報，記得當時客戶對我完成的 Prototype 不太滿意；不只打電話來公司罵人，甚至叫我立刻到現場給他罵才解氣。

面對這種客戶，你覺得公司會怎麼面對？當然是讓我馬上動身到客戶面前挨罵啊！

因為前期規格頻繁變更，導致專案進度不如預期；所以官員叫我直接到政府單位駐點，他想在背後盯著我開發；也許有讀者好奇：「政府官員看得懂程式嗎？」恩…他的確看不懂，但就是希望我在他的眼皮底下做事。

面對這種無理的要求，想當然的，公司當然是舉雙手同意我去政府單位駐點！

不過駐點並不是政府單位的極限，他們還導入了變形的敏捷開發；每天早上 9:30 跟下午 4:30 都要開 Scrum meeting 來檢視專案進度，並實際操作系統確認功能符合他們的需求，然後排定後續任務。

相信一天開兩次 Scrum meeting 這件事會讓人感到疑惑，不過也許有人已經猜到了，他們下午 4:30 所訂下的任務，是要在隔天早上 9:30 驗收的。

現在回想起來，我還是覺得這段日子極其荒唐。

我需要一個有代表性的作品

相信看到這裡，應該很多人對筆者為何沒離職感到困惑，職場又不是軍營，面對不合理的環境根本沒有待下去的理由啊！

其實筆者在接到這個專案後，無時無刻都想著離職；畢竟無論自己多努力、加多少班，公司不但沒給加班費，連調薪的幅度都讓人覺得是一種羞辱。

但我還是把離職的衝動給克制住了，因為我很清楚這份專案的價值，它是一個全國性的專案，如果能把它做好，那是一個很難得的履歷。

市場上的工程師這麼多，光靠技術與努力是很難脫穎而出的；你需要一些更「實際」的東西來證明自己的價值，一個代表性的專案，能讓你在跳槽時把自己賣到一個好價格。

讓原本看不起你的人認同你

專案剛開始時，政府官員是瞧不起我的，甚至把我當狗罵；但隨著合作進行到尾聲，政府官員主動向主管稱讚我，並希望能幫我加薪、給予加班費（But…裝睡的人叫不醒）。

讓原本看不起你的人認同你，這對筆者來說是一件值得自豪的事情，因為這側面說明了自己的成長。

系統最後在 3 次全國範圍的易用性測試後正式上線，在上線後不久我便遞出辭呈；因為我已經完成階段性任務，並拿到這份履歷了，沒必要繼續委屈自己待在一個不合理的環境。

政府官員在得知我離職的消息後，馬上提供一個薪水還不錯的職缺，希望我可以繼續維護系統；不過剛脫離這個環境的我，怎麼可能會再主動跳進去呢？

結語

無論是工程師還是其他職業，筆者認為有一個代表性的作品是非常重要的，因為它能快速讓人對你產生記憶點。

很多行業都要加班，但要認清自己加班是為了什麼；如果加班只是在做一些重複、瑣碎的事情，那這對職涯並沒有多大幫助，只是證明自己很有奴性而已。

即使清楚加班是為了更好的未來，筆者還是建議量力而為；畢竟身體只有一個，長時間加班帶來的疲倦與壓力，不僅會降低你的睡眠品質，還容易導致易怒、情緒失控、健康亮紅燈。

經歷過這份工作的殘害後，未來面試新工作時，筆者都一定會詢問：「公司是否有加班文化？如果需要加班，是否有加班費？」如果公司連基本的勞基法都無法做到，那無論這份工作多吸引人，我都不會考慮。

不過從結果來看，我還是很感謝這份工作帶給我的歷練；畢竟只有一年經驗的菜鳥工程師，很少有機會能代表公司與客戶接觸，並親身經歷專案完整的流程，這裡我很感謝主管給我的信任。

最後筆者在給社會新鮮人一點建議，大部分的人在找第一份工作時，通常手上沒有太多的談判資本，如果你想盡可能避免地雷職缺，可以從以下幾點判斷：

• 與面試官聊的愉快：至少基本的磁場要合，如果連面試都不愉快了，那進去基本上只會更痛苦。
• 公司符合勞基法：責任制跟有沒有加班費是兩件事，就算面試官說公司基本上不會加班，還是建議問清楚，否則到時痛苦的是自己（除非你喜歡給老闆做功德）。
• 在意的點都要問清楚：新鮮人最常犯的錯誤，就是怕講實話公司就不錄用自己（ex：不接受博弈工作、常態加班、下班 On Call），但試想一下，若到職才發現彼此不合適豈不是更浪費時間？請務必要釐清彼此的需求。

當然以上建議會讓工作變得更難找，請讀者依自身情況調整。

第一份工作的故事就分享到這邊，下一篇文章我會分享如何用「斜槓」打破職涯框架，為自己爭取更多機會。

選擇比努力重要，而環境就像個導師，不斷影響著我們的選擇。

找到你的學習對象 or 想要成為的人

人在沒有具體目標的時候缺乏方向。

就像職場新鮮人在遇到問題時連答案都不知道去哪裡找，如果起步時沒有可以詢問與模仿的對象，那很容易在初期受到挫折就直接放棄。

而我非常幸運，因為身旁就有一位經營部落格多年的朋友 ── 朱騏，我有許多行文風格與排版方式都他身上學習而來的。

感謝大大在我遇到瓶頸時，給我許多可以改善的建議。

從朋友身上獲得回饋與靈感

每個人都是從新手開始的。

除非天資聰穎，否則初期的作品往往差強人意；此時你需要朋友回饋，他們是這個階段最能給你真心建議的人。

這邊我要感謝願意看我文章，並給予建議的朋友們 ── 從高中開始就一路給予支持及專業建議的 Kellly 學長、連續兩年給我書名靈感的同學 CP、每次詢問意見總是超認真回覆的超哥及 JL 前同事們…

一個人的靈感總是有限，當我想不到題材時，Ray 往往能提供許多新奇有趣的想法，我第一本書就是從他的靈感延伸而來。

「人」這個字一撇一捺，象徵彼此相互扶持、互相幫助。

創造一個讓自己覺得放棄很丟臉的情境

透過群體壓力來克服惰性。

上班已經很累了，比起持續精進，我更想躺平刷手機。面對自己的劣根性，我選擇做下面兩件事情：
1. 告訴身旁朋友我今年要實現的目標（ex：完成比賽、發表50篇文章）
2. 參賽的時候多拉幾個人下水

做完上面這兩件事時，你在完成目標時會多一份「責任感」，當升起放棄的念頭時會多出一個「愧疚感」；為了面子，我會盡全力完成！

自己選擇的路，跪著也要走完！

自律的朋友會激勵自己

有這些人當朋友，會更有前進的動力。

以去年的 iT 邦幫忙鐵人賽為例，其實在開賽前一個月，我還沒有決定參賽，但在超優秀學弟 ── 陳毅 的大力推坑下，我還是參賽了；並很幸運地認識一群對技術充滿熱誠的自虐狂，且成功在各自的主題中完成了連續 30 天發表技術文章的里程碑。

有時身旁的朋友，會帶領我們達成原本辦不到的事情！

理解並給予支持的家人與女友

無論是創作還是出版，都需要花費大量的時間。

而這些時間，原本是可以用來與家人相處、女友約會；大家都知道「努力」本身就違反人性，如果在這之上還有更多的阻力，我真的無法保證自己有「逆天而行」的意志力。

在這特別感謝他們願意犧牲休息時間幫我校稿，讓我的書能以錯誤較少的狀況下順利出版。

感恩家人！讚嘆女友！

總結

每個里程碑的達成，都需要許多人的協助。

僅靠自己的努力是很難獨自完成這些事情的，我們需要有人指出盲點、給予壓力、提供建議。

再次感謝一路陪伴、幫助我的朋友們。

文章的最後為自己的新書打個廣告，如果你最近有轉職的需求，或是對現在的職涯感到迷茫，可以參考看看喔～

天瓏網路書店 | 給全端工程師的職涯生存筆記：從履歷×面試×職場打造無可取代的軟實力 (ChatGPT加強版) (iThome鐵人賽系列書) 出版商: 博碩文化 出版日期: 2023-05-04 定價: $650 售價: 7.8 折 $507 語言: 繁體中文 頁數: 416 裝訂: 平裝 ISBN: 6263334576 ISBN-13: 9786263334571… www.tenlong.com.tw

今天筆者想用這篇文章，作為經營自媒體 2 週年的回顧；裡面有我努力的過程、獲得的榮譽、不同時期的數據；儘管距離大神還很遙遠，但我會努力做到自己能力範圍內的最好，並持續提高。

大綱
ㄧ、自媒體的初期真的只有「自己」
二、文章發了個寂寞後，我嘗試過哪些方法？
三、「經營」需要時間
四、需要一些成果，來證明自己的努力是有意義的
五、在細分市場獲得更多瀏覽人數
六、永遠有需要你知識的讀者

ㄧ、自媒體的初期真的只有「自己」

與其分享光鮮亮麗的經歷，不如先放上過去悲慘的數據。

一開始只是想找個平台來炫耀自己的 Side Project

我在 2020/06/03 發表了第一篇部落格：「免費打造專屬於您的問卷程式」

發文後我覺得自己寫的這麼認真，肯定會收到很多迴響，但實際上這篇文章直到今天還沒有任何一筆留言 😭。

發現 Side Project 沒人看後，改發表自己在工作、技術上遇到的問題

在發表幾篇 Side Project 沒有得到迴響後，我決定改變寫文的策略！

再跟朋友討論後，推測可能是因為 Side Project 的內容太過小眾，因此無法獲得讀者共鳴；於是我改為分享自己工作中使用到的技術、經驗。

在發表一系列的技術文後（ex：Gitlab 安裝以及我曾經遇到的坑、Nginx — 你網頁的好夥伴、0難度讓你在Server安裝設定MySQL…），想說這樣總會有人看了吧？

但遺憾的是，瀏覽人數依舊超低，並且依舊沒有人給文章留言 😭。

想透過發表大量的文章來增加點閱率，但…

我想沒有什麼互動，可能是因為文章的數量太少了，所以我在接下來的一個月發表了十幾篇文章；但就如同標題所述，結果依舊石沉大海 😱，我都懷疑自己的帳號是不是被 Medium 給 Ban 掉了 😥

才經營自媒體不到 2 個月，我就已經萌生放棄的念頭 😰

就算你是抱著做個人筆記的心情發表部落格，但在心裡面還是希望有讀者可以跟你互動；在連續十幾篇沒有獲得任何迴響後，真的很難不陷入自我懷疑（也可能是筆者比較玻璃心）。

這邊要特別感謝我的好友 — 朱騏，他的建議讓我在迷茫與自我懷疑時繼續堅持。

二、文章發了個寂寞後，我嘗試過哪些方法？

儘管開局失敗，但我並沒有直接放棄，而是去思考幾個問題：

1. 是不是因為 Medium 的讀者對我發表的主題不感興趣？
2. 如果我今天是在以技術為主的平台分享文章，是否能獲得更多的迴響？
3. 我要如何證明自己寫的文章對讀者是有用的？

根據上面幾個問題，我做了如下努力：

參加 iT 邦幫忙鐵人賽

這是一場要連續 30 天發表技術文章的比賽，我透過這個比賽錘煉自己的文字表達能力，並透過「組隊」認識一群對技術同樣有熱情的朋友們。

為了避免中間有人斷賽，我們彼此鼓勵與監督，在各自的主題中完成了連續 30 天發表技術文章的里程碑。

同時因為這個平台主要的受眾都是工程師，所以在文章發表後，更容易收到讀者的反饋。

下面是我參加兩屆 iT 邦幫忙鐵人賽的系列文，有興趣的朋友可以參考看看：

• AI & Data 組：行銷廣告、電商小編的武器，FB & IG 爬蟲專案從零開始
• Software Development 組：全端工程師生存筆記

如果你在 iT 邦幫忙鐵人賽得獎，除了技術受到肯定外，還有機會將作品出版成書。

出版個人專業書籍

出書是筆者的夢想之一，衝著這個點我非常認真的準備比賽，並不斷優化自己的內容；而最後很幸運的，在獲獎後筆者受到博碩出版社的邀約，將系列文改寫成實體書籍。

往往我們在發表文章後，就很少有機會去回顧舊的文章；而出版剛好是一個回顧舊文的機會，在這個過程你會發現過去寫文時沒察覺到的總總問題，比如：

1. 程式碼邏輯不夠完善、排版不一致、命名不夠好…
2. 有些文字表達的不知所云，不知當時怎麼會這樣寫。
3. 只給出解答，沒有解釋為什麼選擇這樣做。

因為書籍印刷出版後就沒辨法變更文字，所以你會用更仔細的態度去檢查你所想傳遞的知識。

持續在 Medium 平台發表文章

儘管 iT 邦幫忙能獲的較多的迴響，但我仍然有持續經營 Medium，因為我認為兩個平台的性質與目標不同。

• iT 邦幫忙：比較偏向一年一度的參與，走短期爆發，一次參與就需要連續發表 30 篇文章。
• Medium：分享平日學到的新技術、職場經驗，長期有紀律的執行，用來維持寫文的習慣與手感。

這兩個平台我在文章的結尾處也有互相導流，期許獲得更多讀者。

三、「經營」需要時間

除非你有廣大的群眾基礎、逆天的強大氣運、謫仙般的文采，否則作為一個「普通人」經營自媒體，是很難在短時間內看到成效的。

如果你是為了某個功利性很強的目的來經營自媒體，那麼有非常高的機率在半年內退隱江湖；因為在前期幾乎看不到任何收益，也不知道什麼時候才會有收益，我們看到剛開始就一砲而紅的只是個案。

如果有經營自媒體的打算，筆者建議「選擇自己感興趣的事情」，這樣你才有可能在毫無收穫的狀態下持續堅持。

堅持執行一件事情未必可以給你帶來財富，但絕對能給人留下深刻的印象，讓別人在第一次認識你的時候，知道你擁有「堅持、努力」的人格特質

四、需要一些成果，來證明自己的努力是有意義的

持續做一件事，至少會讓你留下努力痕跡；有時，甚至會獲得意想不到的收穫。

下面筆者分享自己這兩年來所收穫的成果：

關鍵字搜尋

下面列出幾個 SEO 排名較高的搜尋結果：

書籍銷售成績

JavaScript 爬蟲新思路在預購時獲得週排行榜 TOP 2

給全端工程師的職涯生存筆記在預購時獲得週行榜 TOP 1

FB 廣告

我從來沒想過自己的書籍會出現 FB 的廣告當中，儘管我是精準 TA，但看到的時候還是非常感動

比賽得獎

部落格瀏覽人次

截至今日(2022/06/29)，在 Medium(93)、iT 邦幫忙(62) 這兩個平台上合計發表 155 篇文章，總計瀏覽人數破 20 萬。

「20 萬」這個數字對很多大神來說只是一篇文章的點閱數，但對筆者來講卻是一個值得紀念的里程碑。

隨著時間的推移，開始有周圍的朋友、同事跟我說他們在 Google 找資料的時候查到我的文章，並順利解決他們的問題；收到這些訊息時，就會感覺到當初的努力沒有白費。

五、在細分市場獲得更多瀏覽人數

老實說，我有埋關鍵字的文章大多瀏覽人數都很慘，反而是一些隨手寫的技術文有比較多的人看。

SEO 的優化我也還在努力學習，但我發現如果使用「常用的關鍵字」，儘管被搜尋到的機率更高，但因為 SEO 的排名太低，所以對瀏覽人數反而沒有太大幫助。

回頭看自己寫的文章，在沒有特別做社群媒體行銷，純粹靠 Google 關鍵字搜尋的狀態下，瀏覽數多的文章往往是使用「專業技術的關鍵字」，這個結果自己當下撰寫時沒有想到的：

這讓我回想起過去上的社群經營課程，裡面的講師曾說過：「你文章的目標讀者要越精確越好，不要老想著讓所有人都來看你寫的文章；如果你分享的內容，別人也能輕易寫出來，那你就要去思考如何讓自己的文章有獨特性。」

六、永遠有需要你知識的讀者

我剛開始寫文章的時候也會想，市場上已經有這麼多大神了，還有誰要看我這種小咖寫的文章。

但實際上，正因為我是小咖，所以我更明白初學者會卡關的點；小咖也有小咖的市場，我的文章是服務更入門的族群，讓他們用更低的門檻去學習、度過目前遇到的瓶頸。

相反的，儘管大神寫的文章很棒，但可能因為涉及的知識面太廣，對初學者而言太過艱澀，在不具備足夠的知識儲量時，常常會有看沒有懂。

如果你也有經營自媒體的打算，不要擔心自己分享的內容會不會太過基礎，有時市場欠缺的正是這些基礎知識。

後記

2 週年的回顧到這裡就告一個段落了，希望裡面的資訊能給讀者帶來一點勇氣和啟發（如果對你有幫助的話可以留言讓我知道喔 🥺）。

文章的最後為自己的新書打個廣告，如果你最近有轉職的需求，或是對現在的職涯感到迷茫，可以參考看看喔（歡迎路過按讚）～

天瓏網路書店 | 給全端工程師的職涯生存筆記：從履歷×面試×職場打造無可取代的軟實力 (ChatGPT加強版) (iThome鐵人賽系列書) 出版商: 博碩文化 出版日期: 2023-05-04 定價: $650 售價: 7.8 折 $507 語言: 繁體中文 頁數: 416 裝訂: 平裝 ISBN: 6263334576 ISBN-13: 9786263334571… www.tenlong.com.tw

大綱
ㄧ、認識職位象限
二、公司的做事文化
  ➤ 會議上話語權過度集中
  ➤ 每個人捍衛自己的想法
三、工程師的話語權
  ➤ 工程師真的有話語權嗎？
  ➤ 工程師適合有話語權嗎？
  ➤ 工程師只要當個程式設計師嗎？
  ➤ 資深工程師是一個很特殊的角色

ㄧ、認識職位象限

一個人可以走得很快，但一群人才能走得更遠；如果公司只有其中一個類型的人才，那在運營上面就很容易侷限在某個思維中。

二、公司的做事文化

在看完上面的象限後，我們回過頭來思考自己的公司是如何推出一個產品的。

會議上話語權過度集中

有些會議僅管邀請大家出席，但大多數的話語權還是掌握在「產品經理」身上，大家都是依照他的意志去完成任務。

這樣的做法會非常有「效率」，如果產品目標明確且沒有太多需要「思考」的地方是真的很棒。

但這樣的做法很容易會有盲點，因為「一個大腦」在面臨複雜需求時肯定會有考慮不周全的地方。

每個人捍衛自己的想法

在不同角色下，面對同一個問題，每個人可能都有自己的答案；這個答案站在各自的立場上可能「全部都是正確的」。

如果組織中缺乏一個有決斷力的角色將這些「創意」整合，往往會造成非常多的無效會議，或是專案過度設計。

所以要如何平衡兩者，真的就是看每間公司的智慧與業務取向了。

三、工程師的話語權

因為筆者與朋友都是工程師，所以會分享從現實生活中看到，工程師天生話語權較弱的問題。

工程師真的有話語權嗎？

因為曾經兼任過產品經理、專案經理，所以對這塊真的很有感受；當你提出的需求被工程師質疑時，在心理上會產生一種防衛狀態，這種狀態可能會刺激你堅持自己的主見，想辦法用其他證據說明自己是對的，卻忽略對方提出的可能也是對的。

大部分的工程師在自己提出的想法被拒絕後，絕大多數以後就不太會再提出想法了，因為他們會覺得反正都會被打槍，我為什麼還要沒事找事做，做好公司認為我的「本分」就好了。

工程師適合有話語權嗎？

工程師在收到奇耙的需求時，會覺得這個天馬行空的需求真的做下去肯定會出事，有責任心的工程師會跟產品經理反應這個需求不妥當，但大多數的狀況下，他們最容易收到的回覆是：「你不懂用戶跟數據，做就對了。」

有些需求是源自於用戶與數據，但並不是每個產品經理都會將這些來龍去脈都寫在需求文件上，大部分只是希望工程師按造自己的想法做事。

的確大部分的工程師光是開發就需要消耗非常多的時間，他們不了解用戶與數據是很正常的，但這塊的「資訊不對等」造就他們就算提出想法，也很容易被冠以「無知」做為結局。

工程師只要當個程式設計師嗎？

工程師（Engineer）跟程式設計師（Programmer）乍看之下非常像，但筆者認為兩者的職責是有差異的。

工程師（Engineer）更具備對於一個專案的宏觀思維，他會參與討論與規劃，別人也願意聽取他的意見來做分析；而程式設計師（Programmer）更像是聽命辦事，做好自己份內的工作，不具備組織內影響力。

資深工程師是一個很特殊的角色

不過如果你是一個對用戶、數據、產品都有深刻理解的「資深工程師」，很有可能擁有與眾不同的話語權，你的「江湖地位」讓其他人願意花更多的時間來聽你說話。

我覺得這就像是軍中的士官長僅管階級比軍官低，但軍官還是願意聽取士官長給的建議。

如果你對目前的職涯感到迷茫，想從不同視角檢視自己的選擇，相信《工程師下班有約》這本書能為你帶來靈感與啟發：

下班有約系列文
▋ [前端]新手工程師容易卡住的問題
▋ [前端＆後端]工程師常犯的錯誤
▋ 讓開發團隊更好協作的方式
▋ 談談 Pair Programing
▋ 談談工程師的話語權(本篇)
▋ 出社會後，新鮮人要及早知道的 5 件事
▋ 面試的性向測驗竟然準到讓人心裡發寒？
▋ 反其道而行的任務分配
▋ 現在的 Daily Scrum 真的適合團隊嗎？
▋ 用低成本也能請到好員工？資深 HR 不想告訴你的秘密！