SolidWorks零組件機構設計
104學習
MicroStation
這是一款專業的電腦輔助設計（CAD）軟體，主要用於建築、土木工程和製造業的圖面繪製與設計。具備此技能代表能熟練製作精確的2D平面圖及3D模型，有助於提升設計效率和準確度，並方便與團隊協作和資料共享。在台灣的工程和建築相關職場中，掌握此技能能增加競爭力，尤其是參與大型基礎建設或精密設計專案時非常受重視。
提升你的實力，朝專業更進一步
精選課程
充實自己，讓能力持續成長
Substance Painter模型材質貼圖
BIM 實戰建築工程設計
Linux Socket網路程式設計【本課程為線上課，報名後專員會提供上課資訊】
資料庫設計原理
MCP Server讓AI走入實體世界：從零打造 MCP Server，一點都不難！
PMI-ACP 敏捷專案管理師認證暨實務課程
AI邊緣運算實作TensorFlowLite for MCU【本課程為線上課，報名後專員會提供上課資訊】
打造高投入團隊：遊戲化工作設計與激勵機制實作班【9/17】
精選證照
考取專業證照，讓能力被市場看見
Micro:bit程式設計應用認證
Micro:bit多元功能於日常生活中問題解決。從發現問題、解析問題、理解應用積木設計程式模擬解題。經過測驗實作全面理解Micro:bit運作原理以及連接Micro:bit設計程式應用。
TIPCI臺灣國際專業認證學會
微處理器與嵌入式系統應用
近年來，隨著發展，嵌入式嵌入式的應用不斷擴大。多設備設備設備設備需要嵌入式嵌入式系統來實現智能化智能化智能化，從而實現和模式系統的開發和應用帶來了更多的挑戰和機遇。
微處理器與嵌入式系統應用證照專注於培養專業人士在微處理器和嵌入式系統應用方面的技能和知識。通過這項證照的專業人士具備能夠設計、開發和應用微處理器和嵌入式系統的能力，並了解相關的硬體和軟體技術。
TIPCI臺灣國際專業認證學會
小微型企業人力資源管理師
小型企業的人資管理跟中大型企業有本質的不同！小型企業由於公司規模較小，通常沒有專職的人力資源人員，而是由行政助理甚至老闆自己兼任。加上小型企業的資源十分有限，造成公司在人事管理上觸犯法規而不自知，或是高度依賴人工作業造成人事資料的錯誤與低效。
獲得小微型企業人力資源管理師認證，代表您具備以下能力：
1. 了解人力資源管理的基本概念和目標，並能制定適合小微企業的人力資源策略。
2. 了解符合法令的基本要素，快速制定人資管理制度＆工作規則，避免勞資爭議。
3. 掌握適合小微企業的人力規劃與招募甄選方式
4. 掌握適合小微企業的目標設定與績效管理方法
5. 掌握適合小微企業的薪酬政策與獎勵制度
6. 掌握如何善用數位化系統工具使小微企業的人資管管理效率化
104資訊科技股份有限公司
MCSE
這是一項對於系統規劃的專業能力認證，取得MCSE表示您有能力鴐馭於Microsoft Windows 2000, XP, .NET 及其伺服器軟體的資訊系統，可以有效率的進行規劃、建立、管理、維護及支援工作。
Microsoft
丙級電腦輔助立體製圖
由於產業升級及製圖方法與設備的改進，為配合電腦繪圖軟體以立體方式從事輔助設計製圖工作及提升專業人員技能水準與研發工作之效率，特定本檢定規範。
丙級電腦輔助立體製圖技術士之工作內涵，是指擔任單件立體圖繪製及圖面管理等工作，包括應用磁碟作業系統、安裝軟體與使用電腦週邊設備、設定繪圖環境、控制圖形顯示幕、輸出圖形與管理圖面等基本工作及繪製單件立體圖、單件立體剖視圖等項。
勞動部勞動力發展署技能檢定中心
丙級電腦輔助機械設計製圖技術士
從事應用電腦輔助設計與製圖(Computer-Aided Design and Drafting，CADD)軟體及繪圖用具，繪製機械產品之零件圖、組合圖、等角立體圖及圖面整理等工作
勞動部勞動力發展署技能檢定中心
精選貼文，掌握第一手知識
如何成為後端工程師？精準掌握必備核心技能＆職涯精進攻略
你是否想轉職成為後端工程師，打造更穩定、具成長性的技術職涯？無論你是剛開始學習程式語言的新手，或正在尋找明確學習方向的職場工作者，這份後端學習地圖將幫助你掌握後端工程的核心技能、實戰經驗與職涯發展路徑。透過系統化的學習規劃與專案實作，你將更有信心地踏入後端領域，成為職場中真正被需要的技術人才。
文 /【104學習精靈】
本文目錄（點擊可快速前往）
後端工程師是什麼？和前端、全端工程師有什麼不同與優勢之處？掌握後端工程師的核心能力：必備工具技能 x 學習路徑 x 軟技能轉職後端工程師的學習策略後端工程師薪資行情與職涯發展後端工程師的挑戰與機會
後端工程師是什麼？和前端、全端工程師有什麼不同與優勢之處？
🎯 後端工程師工作內容
後端工程師（Backend Engineer）主要負責伺服器端的邏輯開發，包括資料庫管理、API 設計、伺服器架構以及系統效能優化。他們確保前端應用程式能夠順利與後端系統交互，並提供穩定的數據與服務。
🎯相近職類比較：DevOps、全端、前端、後端工程師差別
職位主要負責技術負責範圍後端工程師（Backend Engineer）伺服器架構、API 設計與串接、資料庫管理、效能優化負責後端邏輯、數據清理，確保前端能夠存取正確的資料前端工程師（Frontend Engineer）HTML、CSS、JavaScript、React、Vue負責 UI/UX 設計，開發與使用者互動的前端界面全端工程師（Full Stack Engineer）前端 + 後端技術能獨立開發完整應用，涵蓋 UI、後端 API、資料庫管理DevOps 工程師（DevOps Engineer）Docker、Kubernetes、CI/CD、自動化部署負責開發與運行環境的部署、監控與維護，提升開發效率
🎯 為什麼選擇後端開發？
後端開發是資訊產業中穩定且高度需求的領域，適合對邏輯、架構、系統思維有興趣的學習者投入：
就業市場穩定成長：隨著數位化轉型普及，後端開發職缺在各行各業皆有需求，從新創到大型企業都有穩定徵才。
強調邏輯與架構設計：後端工程著重資料儲存、伺服器溝通、API 設計等，適合喜歡系統設計與架構思考的人。
職涯彈性大：從初階後端工程師到系統架構師，甚至 DevOps、SRE、資安領域都有後續延伸路徑。
遠端與自由接案機會多：後端開發技能通用性高，較容易接國際案或轉為遠距工作者。
AI 與資料應用的基礎：資料庫管理、API 串接、運算效能等能力，也可延伸應用至 AI 系統部署或資料工程等新興領域。
🎯 誰適合轉職後端工程師？
後端開發適合各類背景者，關鍵在於邏輯思維、學習動機與持續投入：
✅ 設計/前端背景：具備良好使用者體驗與前端邏輯，轉後端可成為 Full-Stack 工程師，提升職涯彈性。
✅ 商管背景：邏輯能力佳且理解商業流程，適合轉後端結合業務邏輯，強化企業系統開發應用。
✅ 理工背景（如物理、數學）：邏輯與抽象能力強，容易掌握資料結構與演算法，是進入後端的優勢群體。
✅ 非資訊領域自學者：只要有堅強動機與自律力，透過系統性訓練與專題實作亦能成功轉職。
✅ 現職 IT 工程師（如測試、維運）：已具備技術背景，轉入開發領域有明顯加速效益。
✅ 資料分析師：熟悉資料處理與 Python，轉向後端可擴展資料處理與系統部署的完整技能鏈。
掌握後端工程師的核心能力：必備工具技能 x 學習路徑 x 軟技能
🧭 後端工程師技能、工具分類表
語言與工具資料處理與資料庫API 設計與架構DevOps 與部署基礎Python / JavaScript / Java / GoGit / GitHub / GitLabSQL（PostgreSQL / MySQL）資料庫基礎觀念REST APIHTTP 基礎了解部署概念核心*熟悉後端框(SpringBoot, Django, Express, Gin)*熟悉語言設計模式撰寫可讀性高的程式NoSQL（MongoDB / Redis）基本資料模型設計身分驗證（JWT / OAuth）API 文件設計（Swagger）*Docker 容器化*CI/CD 自動部署 進階*多語言協作力*程式效能優化*高效能資料庫設計*索引分片與備援策略GraphQL / gRPC微服務架構（CAP / CQRS / Event Sourcing）Kubernetes、服務網格（Service Mesh）監控與日誌系統認證*程式語言認證 (例如Python 程式設計證照PCAP）*個人作品集AWS Database SpecialtyMongoDB 認證*API 設計課程證*書專案開發經驗（如 Hackathon）*AWS Certified DevOps Engineer*CKA（Kubernetes Administrator）▲ 後端工程師應具備技能、工具能力、職涯指引表，點選不同技能會對應到相關課程。
後端工程師學習地圖與路徑（搭配AI工具）
🔰 初學者階段（0–6 個月）
✅ 目標：熟悉基礎程式語言與網路知識，能夠開發基本 API。
📌 學習內容：
選一門後端語言（Python / JavaScript / Java）：選一門主流語言打好程式基礎，進入開發世界。
Git 與版本控制（GitHub / GitLab）：讓你能有效保存、回朔與分享你的程式碼。
理解網路基礎與 HTTP 協議：理解網站如何運作與資料如何傳輸。
SQL 資料庫（PostgreSQL / MySQL）：學習資料查詢語言，管理網站背後的資料。
REST API 開發：學習建立網頁服務的後端接口。
Python 程式設計能力 - 線上免費檢測
📌 AI 工具應用：
ChatGPT 協助語法學習與除錯：快速解釋語法、找出 bug、提供程式碼建議。
GitHub Copilot 協助寫基礎 CRUD 程式碼：協助補上程式片段。
📌 備選學習：
Go 語言：效率高但語法嚴謹，對初學者略具挑戰。
Node.js（JavaScript 後端）：若未來想走全端路線可以學。
✅ 適合考取的證照：
Python 程式設計證照（PCAP）
ITS (Information Technology Specialist, IT 資訊科技專家認證
Oracle MySQL Database Developer
AWS Certified Cloud Practitioner（雲端基礎，有助於未來學 DevOps）
[course_plugin title='Python課程' keyword='Python 輕鬆上手學' amount=1]
[course_plugin title='後端工程師入門課程' keyword='成為後端工程師' amount=1]
🚀 中階階段（6–12 個月）
✅ 目標：熟悉進階 API 設計、資料庫優化，學習 DevOps 工具。
📌 學習內容：
學習後端框架 (Express、Spring Boot、Django、Gin) ：掌握常用的後端框架。
身份驗證與授權（JWT、OAuth）：幫使用者安全登入，讓資料不被偷看。
NoSQL 資料庫（MongoDB、Redis）：適合儲存彈性格式的資料或快取機制。
Docker 容器化：讓你的程式「打包好、帶著走」。
CI/CD 自動部署（GitHub Actions）：程式更新後自動上線，省時又省心。
📌 AI 工具應用：
使用 AI 幫你產生 Dockerfile 與 CI/CD 配置：不懂也能靠 AI 輔助上手。
協助設計 API 架構與資料庫 schema：加速設計與重構過程。
📌 備選學習：
GraphQL：適合複雜資料查詢，但非所有團隊使用。
gRPC：適合內部高效通訊場景，小型專案可暫不碰。
Jenkins（較舊型 CI/CD 工具）：學習成本高，可視需求使用。
HATEOAS（超媒體 API）：學術價值高，實務上較少見。
✅ 適合考取的證照：
MongoDB Developer Certification
Docker Certified Associate (DCA)
Microsoft Azure Fundamentals (AZ-900)
HashiCorp Terraform Associate（如學有餘力涉略基礎 IaC）
[course_plugin title='後端工程師中階課程' keyword='接案必學 ◆ 邁向更專業的App開發' amount=1]
🏆 進階階段（12 個月以上）
✅ 目標：學習架構設計，提升可擴展性與效能。
📌 學習內容：
微服務架構（CAP 理論、CQRS、Event Sourcing）：學會如何將大系統拆小管理，處理資料一致性問題。
Kubernetes 與服務網格（如 Istio）：讓多個服務能自動部署與協調運作。
高效能資料庫設計與分片策略：設計能承受高流量的資料系統。
系統監控與安全性實踐（如 Prometheus、Grafana）：確保系統穩定、安全運作。
📌 AI 工具應用：
AI 幫你設計 YAML 檔與架構圖：快速理解與部署分散式架構。
系統瓶頸分析助手：用 AI 分析 log 或效能資料，加快除錯與優化。
📌 備選學習：
Istio 等 Service Mesh 工具：適合大型微服務團隊，維護成本高。
Event Sourcing：較進階模式，建議有實務需求時再深入。
✅ 適合考取的證照：
Certified Kubernetes Administrator (CKA)
AWS Certified Solutions Architect – Associate
Google Cloud Professional Cloud Architect
DevOps Engineer Professional（AWS / Azure）
[course_plugin title='後端工程師進階課程' keyword='Java進階專業｜前後端整合開發與應用' amount=1]
5個後端工程師應具備的軟技能特質：
邏輯思維與問題解決能力
能夠理解業務需求並轉化為系統邏輯，並針對錯誤快速找到根本原因。
【小測驗】來測測看自己的問題解決技巧 👉 問題解決 - 職能檢測｜104學習精靈
溝通與跨部門協作能力
後端工程師需與前端、產品經理、DevOps 甚至業務單位協作，良好的溝通有助於準確理解需求與回報技術限制。
【小測驗】來測測看自己的溝通能力技巧 👉 溝通協調 - 職能檢測｜104學習精靈
學習與自我成長動能
後端技術（如框架、資料庫、API標準）快速演進，必須持續學習與更新知識。
細心與責任感
後端處理大量資料及邏輯，細節錯誤容易引發資安問題或系統錯誤。
時間管理與自我管理能力
在遠端工作日益普遍的環境下，自律與時程安排變得尤為重要。
轉職後端工程師的學習策略
🎯 初學者或轉職者的學習策略
轉職或初學後端工程，建議採取階段式、任務導向的學習策略，以下列點歸納：
設定明確學習階段：分為基礎語言（如 Python/JavaScript）、資料庫應用、框架學習（如 Django、Node.js）、部署維運。
專案導向學習：每學完一個階段，就進行小型專案驗證所學，例如 Todo List、部落格、會員系統等。
培養問題解決能力：鼓勵查文件、逛論壇、問 ChatGPT，建立獨立解決 bug 的習慣。
學習版本控制與團隊協作：掌握 Git、GitHub、簡單 CI/CD，增加求職競爭力。
善用 AI 工具輔助學習：例如用 ChatGPT 解釋程式碼、Copilot 寫樣板、Kaggle 或 LeetCode 練習邏輯。
參與社群與實戰活動：參加黑客松、Open Source 專案、小型 Freelancer 案，強化實務經驗與人脈。
建立個人學習履歷：記錄學習歷程、撰寫技術部落格、整理 GitHub 作品集。
🎯 不同領域的客製化學習策略對照表
學歷背景優勢可能挑戰調整建議資訊相關科系已具備基礎程式能力、學科知識缺乏實務經驗、專案規模小強化實作專案與部署經驗，參與社群或實習累積履歷非資訊理工（如數學、物理）邏輯與數學能力強，適應資料結構與演算法快缺乏開發環境熟悉度與應用場景理解著重環境建置、框架與資料庫應用，透過實作強化「業界語感」設計/前端背景了解 UI/UX 與前端邏輯，轉職成為全端潛力大對資料結構與後端語法較不熟悉從 API 串接、簡單後端框架入手，逐步學習資料庫與後端設計邏輯商管/人文背景商業邏輯與跨領域溝通力強，善於理解用戶需求技術門檻高、邏輯訓練少以高階語言（如 Python）為起點，結合專案題材（如 CRM、報表系統）學習效果更佳在職 IT 工程師（測試、維運）已熟悉技術工具與環境、具系統性思維缺乏開發流程與程式架構設計經驗透過轉任內部開發專案或小型 App 開發練習，搭配設計模式與框架學習資料分析/AI 轉職者熟悉資料邏輯與語言（如 Python）、了解資料流缺乏完整系統建構經驗補足後端架構設計與部署技巧，從資料處理串接 API、Flask、FastAPI 切入
後端工程師薪資行情與職涯發展
後端工程師薪資概況
📌台灣後端工程師薪資
初階（3年以下經驗）：月均薪約6.2萬。
中階（3- 5年經驗）：月均薪約 6.5 萬。
高階（5-10年經驗）：月均薪約7.3萬。（以上資料來源：104薪資情報）
📌影響薪資的因素
技術棧與專精程度熟悉高效能架構（如微服務、分散式系統）、熱門語言（如 Go、Rust）、或 DevOps/雲端技能者，薪資會更高。
產業領域與公司規模金融科技、AI、新創、外商薪資通常優於傳產與一般中小企業。
作品集與實戰經驗有實際上線專案、參與開源、或技術部落格者更具競爭力。
證照與專業認證（如 AWS Certified、Kubernetes、GCP）對某些企業或外商來說是加分項。
英語能力與跨國協作經驗能與國際團隊溝通的工程師更受青睞，也更容易爭取外派或海外遠端工作機會。
英文能力 - 線上免費檢測
後端工程師的職涯發展路徑
🔵 技術專精路線（Individual Contributor / IC Path）
從「後端工程師」起步，專注於技術深度與系統設計，逐步升級為具備橫向影響力的技術專家。
▶ 初階 / 中階後端工程師（Backend Engineer）
負責功能開發、資料庫操作、API串接與單元測試。
▶ 資深後端工程師（Senior Backend Engineer）
擁有跨模組開發與維護經驗，熟悉系統效能優化、API 設計規範。
✳️ 學習前端技術 → 全端工程師（Full-Stack Engineer）
技能補充： React/Vue、Node.js、前後端整合、RESTful/GraphQL。
應用情境： 適用於產品團隊需快速開發 MVP 或技術創業者。
✳️ 提升系統架構能力 → 系統架構師（Software/System Architect）
技能補充： 微服務設計、DDD、API Gateway、資料一致性、可觀測性（Observability）。
應用情境： 適用於中大型系統升級或技術重構專案。
✳️ 學習 DevOps → DevOps 工程師（DevOps Engineer）
技能補充： GitOps, Jenkins, GitHub Actions, Docker, Ansible。
應用情境：經由緊密的開發＋運營合作，使企業更高效推出高品質產品。
▶ 全端工程師（Full-Stack Engineer）
獨立開發從 UI 到 API 再到資料庫的完整功能。
▶ 系統架構師（System Architect）
負責設計全系統技術藍圖，定義模組邊界、資料流設計與技術選型。
✳️ 進階發展 → 技術總監 / Technical Director
職責： 統籌技術方向，領導技術專案與架構決策，跨部門協作。
技能補充： 領導力、溝通簡報、技術戰略思維、預算與風險管理。
▶ DevOps 工程師（DevOps Engineer）
專精於部署、CI/CD、環境自動化。
✳️ 進階發展 → 雲端工程師（Cloud Engineer）
職責： 能設計具備高可用性與彈性的雲端基礎架構。
技能補充： 深耕 AWS/GCP/Azure 架構與雲原生技術（如 K8s、Terraform）。
🟢 團隊管理路線（Team & People Management）
此路線適合有溝通、協調與人員培育熱情者，從帶小團隊到參與公司策略。
▶ 後端 Team Lead / 技術主管
同時參與開發與團隊管理，負責人力分配、專案交付與人員指導。
技能補充： Agile/Scrum、敏捷儀表板管理、1-on-1 輔導技巧。
▶ 技術經理（Engineering Manager）
管理多組技術團隊，協助產品規劃、技術優化與跨部門協作。
負責團隊招募、績效制度設計、技術資源管理。
▶ 技術總監（Technical Director）或 VP of Engineering
結合技術與策略視角，影響公司中長期技術方向。
需要具備技術深度 + 商業理解力。
🟠 技術轉職／橫向拓展路線（Cross-functional Path）
探索其他工程領域，發揮後端背景延伸價值，適合追求多元發展者。
▶ 資料工程師（Data Engineer）
優勢：
熟悉 API 設計＆模組化架構：資料平台的模組設計類似微服務設計邏輯。
熟悉系統效能：幫助處理大規模資料運算與資源調度。
熟練程式語言(如 Python、Java)：可快速上手資料工程工具
可有效打造 ETL 流程、管理資料倉儲、支援 AI/ML 任務。
技能補充：
資料處理：Spark、Kafka、Airflow、dbt
資料庫：PostgreSQL、ClickHouse、BigQuery、Snowflake
資料管線：ETL/ELT流程設計、Data Lake、Data Warehouse 架構
編程與基礎統計：Python、SQL、資料品質檢查
職涯發展路徑流程圖
🔹 總結路徑圖說明
(起點)
後端工程師
│
├── A. 學習前端 → 全端工程師
├── B. 提升架構能力 → 系統架構師
│ └── 技術決策 → 技術總監
└── C. 學習 DevOps → DevOps 工程師
└── 深入雲端架構 → 雲端工程師
哪些產業需要後端工程師？
後端工程師幾乎是「所有數位服務產業的基礎職位」，以下是常見產業範疇：
📌電商與零售：處理會員系統、購物流程、庫存管理、金流串接等核心後台邏輯。📌金融科技（FinTech）：開發支付、帳戶、交易、驗證等安全敏感的服務。📌社群與內容平台：如論壇、影音平台、交友 App，後端負責資料儲存、帳號系統與推薦演算法等。📌SaaS / B2B 企業服務：提供線上系統給其他企業使用，如 CRM、HR 系統。📌物流與運輸：如外送、倉儲、車隊派送，依賴大量 API 串接與資料即時處理。📌醫療與健康科技：處理病例、預約、穿戴裝置資料等，需高度資安與資料完整性。📌遊戲與娛樂產業：遊戲帳號、伺服器同步、排行榜、商城等核心功能皆由後端處理。📌政府與公部門資訊系統：如戶政、健保、交通資訊等數位服務。
後端工程師的挑戰與機會
🚀 6個常見的後端工程師挑戰
技術複雜度高：需同時掌握資料庫設計、系統效能、資安與架構邏輯。
看不見的貢獻：成果不如前端「有畫面」，但卻是維運的關鍵，常常被低估。
資安責任重大：系統若當機、資料異常，後端通常是第一個要排解問題的人，需確保數據安全，防止攻擊與資料洩漏。
需快速跟上技術演進：如容器化（Docker）、微服務架構、雲端部署等都不斷更新
高效能與擴展性要求：需設計能夠處理大量請求的系統，確保穩定性與效能。
跨團隊協作：需要與前端工程師、產品經理、DevOps 團隊密切合作，確保系統順利運行。
🌟 後端工程師4大機會
可轉職多種技術職：例如 DevOps、技術主管、架構師，或橫移到前端/全端。
全球需求穩定成長：任何需要「運作」的數位產品，都需要後端支撐。
遠端與海外機會多：因後端較少受地域限制，常見國際合作或海外招募。
進可攻、退可守：進可發展高階技術領域如 AI 後端、大數據平台，退可穩定就業於各類企業內部系統開發。
延伸閱讀：
產品經理 - 學習地圖(上)：技能養成篇
成為雲端工程師的攻略指南：核心技能＆職涯精進完整解析
轉職前端工程師│工作內容、技能、薪水與職涯發展指南
數據分析師工作內容是什麼？薪水高嗎？技術能力與職涯發展指南
想當資料工程師？工作內容、核心技能、薪水、職涯發展完整解析
[joblist_plugin title='更多104【後端工程師】工作機會' url='https://www.104.com.tw/jobs/search/?jobsource=index_s&keyword=%E5%BE%8C%E7%AB%AF%E5%B7%A5%E7%A8%8B%E5%B8%AB&mode=s&page=1' amount='3']
精選 一句話改完整份簡報！Gemini、Copilot、Canva 三家 AI 簡報新功能怎麼選？
簡報做到一半，主管說「整份換成公司品牌色」「第 5 到 7 頁濃縮成一頁」，你是不是又要一頁一頁慢慢改？
十月底，Google、Microsoft、Canva 都在 AI 改簡報上有新動作：不用從頭重做，打一句話就能改整份現有的簡報。
先看三家各推了什麼：
Gemini in Google Slides（10/29 開始推出）
在側邊欄下一句指令，Gemini 會自己判斷要改哪幾頁，直接改在可編輯的投影片上，改完列出修改摘要。
適合：統一整份字型和配色、照另一份簡報的風格改、引用雲端硬碟的檔案補內容。
限制：目前只支援英文指令；要 Workspace 商務／企業版或 Google AI Pro、Ultra 方案。
Copilot in PowerPoint（10 月持續更新）
在 Copilot 對話框用聊天的方式改簡報，可以新增和重組投影片、換圖、套公司品牌範本。10 月新增品牌套件技能，比較長的工作關掉檔案也能在背景繼續跑。
適合：公司已經用 Microsoft 365、要符合品牌規範的正式簡報。
限制：完整功能需要 Microsoft 365 Copilot 授權；簡報太大可能超出系統上限。
Canva Brush（10/29 推出）
Canva 自家訓練的設計編輯模型，看得懂版面結構，小到改一行字、大到改整份簡報都可以，也能把簡報頁直接改成 IG 尺寸。
適合：行銷素材、提案簡報，以及同一份內容要改成不同尺寸的情況。
限制：目前開放給 Canva Pro 訂閱者，在 Canva AI 的模型選單選 Brush。
那我該用哪一個？先問自己三個問題：
1. 簡報平常放在哪裡？
Google 雲端硬碟 → Gemini；公司用 Office 和 Teams → Copilot；行銷素材都在 Canva → Brush
換工具的成本，常常比功能差異還大。
2. 要改的是「內容」還是「外觀」？
補數據、濃縮頁數 → 挑能讀到你原始檔案的工具（Gemini 讀雲端硬碟、Copilot 讀公司檔案）
換風格、改尺寸 → Canva Brush 和 Gemini 的整份套風格最順手
3. 有沒有品牌規範要守？
要對外、要對客戶 → Copilot 搭配公司品牌套件最穩；個人或小團隊 → Canva 品牌工具組也夠用
三個好用的指令寫法（英文版是給 Gemini 用的）：
・「把所有頁面的標題改成同樣的字級和顏色」
Make the titles on all slides the same font size and color.
・「把第 5 到 7 頁整理成一頁重點摘要」
Summarize slides 5–7 into a single slide.
・「依照這份檔案的內容，補充第 3 頁的數據」
Update slide 3 with more details based on [檔案名稱].
最常見的三個錯誤：
・一句話塞太多要求，改壞了也不知道是哪一步出錯
・改完沒有逐頁檢查，數字和專有名詞被 AI 改掉都沒發現
・忘了 AI 會直接改原檔：先複製一份，或記得用版本記錄還原
小練習：下面三種情況，你會先打開哪個工具？
① 業務提案要套客戶指定的品牌色，公司全面使用 Microsoft 365
② 季報簡報放在 Google 雲端硬碟，要把三頁數據濃縮成一頁
③ 活動簡報要同時改成 IG 貼文和限動尺寸
（參考答案：① Copilot ② Gemini ③ Canva Brush）
想把 AI 用進簡報、文案、視覺到影音的完整企劃流程，推薦 104 獨家課程「AI內容企劃力實戰課｜高效文案創作 × 視覺設計 × 簡報製作 × 影音生成」：
https://nabi.104.com.tw/course/104nabi/51189062-5156-4dec-9153-8464c6732b13
也歡迎留言分享：你最常用哪一家改簡報？「一句話改整份」真的有省到時間嗎？
資料來源：
Google Workspace Updates〈Edit entire presentations with Gemini in Google Slides〉
https://workspaceupdates.googleblog.com/2026/10/edit-entire-presentations-with-gemini-in-Google-Slides.html
Microsoft Support〈Edit with Copilot in PowerPoint〉
https://support.microsoft.com/en-us/powerpoint/edit-with-copilot-in-powerpoint
Canva Newsroom〈Introducing Canva Brush, a vision-language model for design〉
https://www.canva.com/newsroom/news/canva-brush/
（功能、方案與開放範圍以 2026 年 11 月官方說明為準，各家都是分批開放，帳號不一定馬上看得到）
你適合當PM嗎？解析產品經理必備3種特質與溝通心法
產品經理（PM）扮演產品關鍵的橋樑角色，不僅要看懂全局、擬定策略，更需要與設計師、工程師高效溝通，協調各方需求並推動產品前進。哪些人適合PM工作？作者透過實務經驗分享，解析PM必備的3種核心特質，以及在與不同角色協作時應具備的溝通心法。
文／Michelle Chen（軟體業PM產品經理）
本文目錄：3個PM需要的核心特質（點擊可快速前往）
特質1：你是否習慣全局性思考，並以策略性規劃推動執行？特質2：你是否喜歡且習慣站在對方的角度，使用對方的語言溝通？PM與設計師溝通重點PM與前端工程師溝通重點PM與後端工程師溝通重點特質3：你是否接受甚至喜歡改變，且有隨時改變計劃的彈性？
我習慣定期把自己的職涯規劃拿出來review，問問自己對於「現在的狀態」是否還滿意。最近是我在現職公司任職滿一週年的日子，於是又把這個問題拿出來檢視一番。我發現對於做PM打造產品這件事（撇除外在條件，像是workload、手上的案子、公司策略、主管等），過了幾年我仍非常喜歡且享受其中。再往下探索，是什麼個性或是特質讓我喜歡且適合做產品經理呢？今天整理3個我認為最核心的特質，分享給有興趣往PM產品經理發展，或還在思考自己到底適不適合的朋友參考！
特質1：你是否習慣全局性思考，並以策略性規劃推動執行？
作為產品經理你每天要應對來自各方的利害關係人，需求從四面八方而來，每季的Product Roadmap規劃&執行，每月2~3次的Sprint（如果團隊跑Scrum），甚至每天的跨部門Support，PM的日常總是被滿滿的需求與會議轟炸，任務清單中的To-dos & Action Item似乎看不到盡頭。在這種「艱困」的處境下，能習慣「全局性思考」的PM就比較能從容應對，懂得從任務海中抽身，避免無謂地瞎忙。所謂全局性思考有點抽象，換個方式來說就是：從整體，更高維度視角看待事情，而不是深陷於眼前的問題。
舉個例子來說，假設你是一位部門主管，你發現某個專案快到截止日但離完成還有一大段距離，你可以選擇臨時外聘人力，或是給團隊成員加班獎勵鼓勵他們挪出更多的時間工作完成任務，這也許是最快能見效的暴力解法。但如果你採取全局性思考，你會先退一步思考，這個專案的規劃是否合理，是否有可以簡化的部分，或者是否團隊中有某個特定的人遇到瓶頸。如果能協助這位成員解決問題，整個團隊的運行會變得更加順暢，也許就能如期完成專案。
全局性思考的能力能幫助PM有效辨識什麼才是真正需要解決的「關鍵問題」，而不是像在大魯閣打棒球一樣，只是對每個問題隨著出現而進行反應。這種思考方式讓你從整體上把握問題的根源，不是只解決表面的問題。
找到問題後，接下來就要透過策略性規劃來實作，這時候一定要提到常見的80/20法則。
20%的因素，將導致80%的結果。找出那關鍵20%重要的事情並全心投入，往往能帶來大部分的成果。
首先找到那20%重要並值得花團隊全心投入的P0-重要且須馬上行動的事。並懂得拒絕或是取捨那些重要但不急，甚至根本不用解決的問題 。取捨決策是一個好PM必備能力。
另外，作為產品的代言人，PM一定要知道哪些任務可以被整合在一起（甚至延伸成一個epic）；又有哪些tasks可能會因為其他迭代而順勢被解決，因此現階段可以忽略不做；又有哪些可能看似有問題，但其實是故意為之的機制。
有策略、有條理的安排團隊資源，聚焦在關鍵20%重要的問題上，可以讓團隊更有效率且優雅的工作。（非常重要，誰會想要每天灰頭土臉工作，你說是吧）
特質2：你是否喜歡且習慣站在對方的角度，使用對方的語言溝通？
有這個特質的PM絕對會是團隊的寶，而不會變成大家避之唯恐不及的任務交差使者。習慣從對方的角度出發，用對方熟悉的用語溝通，不僅能提升理解效率，還能拉近彼此距離，建立良好互動。這有助於建立信任，讓未來的合作更順利愉快，形成正向循環，培養無敵默契。（每次遇到只是一兩句話一個眼神，團隊內的工程師和設計師就能馬上理解我的意思，就會覺得「哇，你們真的是神隊友，我好幸福啊！」）
這邊簡單舉例與設計師以及前後端工程師討論需求時應該著重的方向：
PM與設計師溝通重點
重視使用者體驗（UX/UI）：需要清楚描述使用者的需求（如果需要可以附上完整的user story），並在需求說明中「用戶使用流程」、「易用性」、「介面設計」以及「資訊呈現方式」等。
【溝通舉例】「我們希望這個功能的流程是：1.先點擊這個按鈕，2.展開選單，3.選單中會有幾個預設選項且我們會幫用戶進行預選，整個操作希望可以在3步內完成。」
特別注意！尊重設計師專業：作為PM一定要尊重團隊內設計師以及工程師的專業。對設計師，請保留讓他們自由發揮的空間。提出的需求絕對不會是硬性規定設計師只是把你想像中的畫面／流程畫出來而已，保留設計彈性通常得到的結果都會比自己發想的還要完整流暢！
【溝通舉例】如果需要做一個活動頁面：「這個頁面會包含A~C 3個大分類的資訊，其中A／B分類會另外連結到C／D頁面。這個主頁面的設計，希望能傳達出現代感，並保留畫面的簡潔性，方便用戶快速找到他們要的資訊。可以參考這個網站的設計風格，但具體的顏色／圖標，分類呈現可以自由發揮。」
PM與前端工程師溝通重點
重視介面與互動：前端工程師負責將設計轉換成可用的介面。他們關注的重點包含介面呈現方式、元件的設計與實現、與後端如何進行資料溝通、並且也要確保網頁可以各種大小的裝置和瀏覽器上都能順利運行。
【溝通舉例】PM：「我們希望在報名頁面上，使用者可以看到所有場次，點擊後展開場次詳細資訊，並透過一個動畫顯示出『點選報名』的CTA 按鈕。這部分在手機的 web view 上也需要保持操作流暢。」前端工程師：「這個顯示CTA的動畫在一些舊瀏覽器上可能無法支援，可能會出現卡頓或不顯示的情況。」PM：「如果確實有這個問題，我們可以考慮用彈出popup的方式替代，重點是整體操作要流暢，並且能有效吸引用戶點擊報名。」
特別注意！技術可行性＆永遠都要準備PlanB：有時PM以及設計師一起討論出的設計可能在技術實現上會有挑戰。作為一個好PM，一定要工程師們討論在技術上的可行，以及如果無法實現，可以被接受的PlanB是什麼，並從中找到最佳解決方案。
PM與後端工程師溝通重點
重視系統穩定性及資料處理：後端工程師主要關注系統的穩定性及資料處理。他們習慣使用「API」、「資料庫」、「伺服器」等術語。作為產品經理，你需要清楚描述系統需求，並確保資料流（information flow）和功能邏輯的合理性。
【溝通舉例】PM：「我們需要建立一個數據報表，數據需要即時更新，並支援查看過去30天和60天的時間範圍。這個報表主要用來追蹤使用者行為趨勢。報表中的欄位定義以是{明確定義數據背後的計算邏輯以及fallback機制}。」後端工程師：「要實現即時更新可能會對系統造成壓力，特別是在高峰期，伺服器負載會增加，影響穩定性。」PM：「那或許我們可以考慮設定一個更新的cutoff point，在該時間點做一次性更新，確保穩定性以及更好管理系統負載。」
特別注意！具體明確制定規則：跟後端工程師討論事情一定要具體明確（制定出規則），不能給模糊的「形容詞」。以要新增檢查用戶註冊時的密碼強度的功能為例：
模糊的需求：「我們需要在用戶註冊時，先檢查密碼是否夠強。如果不夠強就讓他重新設置，夠強就讓他繼續註冊。」
➞這時候工程師一定會問你：密碼強度怎麼樣算夠強？這個檢查是在用戶點擊註冊時還是輸入過程中即時檢查？
明確的需求：「如果密碼長度小於8位或不含大小寫字母和數字，則在用戶按下註冊時阻擋下一步，並顯示錯誤提示並要求用戶重新設置密碼。如果密碼符合這些條件，則允許用戶完成註冊。」
PM的工作內容和模式會隨著產品領域、團隊規模及系統架構等因素而有很大不同。然而，良好的溝通能力，尤其能根據不同溝通對象靈活切換用詞和表達方式，針對不同情境調整思考重點，是做好PM必須具備的。如果你發現這種角色切換對你來說有些困難，或是習慣從單一角度進行思考，那可能就不會那麼享受於PM的日常了。
特質3：你是否接受甚至喜歡改變，且有隨時改變計劃的彈性？
最後一點，「接受改變，且對已經計劃好的事情是否總是能保持隨時調整，甚至需要打掉重練的彈性？」是一個PM是否能樂在其工作中，蠻關鍵的特質。
有PM經驗的都知道（不管是Product or Project）都會面臨到原本說好的方向會需要來個大轉彎，產品策略可能因為市場的變化要做立即的調整（例如AI的快速崛起）。對於比較不喜歡變化，或是對於要臨機應變這件事情比較排斥的人，做PM會比較辛苦（心裡苦的部分）。
No two days are the same for a product manager
如果看到上面這句話，你感到興奮，那恭喜你！你一定能從PM的工作日常中找到許多樂趣！
以上就是我簡單從自己身上總結出為什麼就算有時候遇到再鳥的事情，或是有時候真的工作壓力很大，但終究我還是很享受做PM的3大特質與性格，希望能給還在摸索的人或是猶豫不太清楚自己到底適不適合的人一點小小分享。
（原文標題：你適合當產品經理嗎？3個PM需要的核心特質＆性格解析）
[joblist_plugin title='更多104【產品經理】工作機會' url='https://www.104.com.tw/jobs/search/?order=15&page=1&sctp=M&scmin=40000&scstrict=1&jobsource=joblist_search&jobcat=2004003005&keyword=%E7%94%A2%E5%93%81%E7%B6%93%E7%90%86' amount='4']
[course_plugin title='產品經理學習營｜學習推薦' keyword='產品經理學習營' amount=2]
軟體產品怎麼做才能賺錢？PM必懂的3大關鍵及能力解析
軟體產品開發能否成功，不只靠技術，更靠產品經理（PM）對市場、開發與用戶的全面掌握。從打造產品願景，到精準驗證需求、穩定落地技術，本文帶你解析軟體產品從開發到獲利的3大關鍵，並拆解PM對應的實戰能力。
文／Jason Lin（「在海邊數據行銷」負責人）
本文目錄（點擊可快速前往）
軟體產品從開發到獲利的3支腳1. 市場估值：打造讓市場買單的願景與價值主張2. 開發品質：讓產品願景落地的技術實現力3. 市場接觸：持續驗證市場與使用者需求的實戰力PM能力轉譯：3維度對應不同階段的產品策略焦點早期產品的PM：假設、快速驗證、打造MVP成熟產品的PM：持續與規模化打造賺錢產品，是市場×技術×運營的整合功夫
在軟體產品開發的歷程中，PM（產品經理）與開發團隊不只是技術執行者，更是影響產品能否賺錢的關鍵決策者。筆者根據先前工作經驗收斂，要打造一款真正具市場價值、能夠持續獲利的軟體產品，團隊需要從3個核心維度著手：市場估值、開發品質，以及市場接觸。
接下來，本篇將逐一解析這3個維度，及其對應所需的團隊能力，並說明不同階段產品所需聚焦的PM能力。
軟體產品從開發到獲利的3支腳
1. 市場估值：打造讓市場買單的願景與價值主張
為什麼市場估值如此關鍵？
產品的願景、價值主張、解決方案，是否能引發市場期待，是否能在使用者心中產生價值想像，這決定了它能否被市場買單。PM 必須以終為始，從價值主張開始構建整體產品架構，思考解決哪些真正存在的問題，如何讓使用者產生「非用不可」的情境。
PM與團隊需具備的能力&要能夠清楚回答的問題：
市場規模分析：具有一種或多種量化的方法論，能夠評估目標市場的潛力與規模，判斷產品是否值得投入資源開發。
痛點與需求分析：使用者痛點與痛點背後的原因，為何有這些需求？需求是暫時性還是持續性？使用者對痛點的付費意願與能力
目標客群（TA）研究：具體說明 Persona，並且熟悉哪些對 TA 的描述屬於假設，哪些已經透過何種方法或案例證實。使用者輪廓，包含人口維度（如年齡）、行為模式，以及動機情緒的洞察等。這群 TA 是否特別？佔整體市場的商機？是否有獨特的使用習慣或痛點尚未被洞察
解決方案創新能力：具備對於商業模式、產品創新切入點的敏感度與底層商業邏輯，有持續且大量蒐集創新案例的習慣，以便讓敏感度持續進化。
競爭者分析與差異化策略：分析既有產品缺口，建立自身的獨特競爭優勢。
構築護城河：建立產品的可持續優勢，例如網絡效應、資料優勢或使用者黏性。
2. 開發品質：讓產品願景落地的技術實現力
開發品質的重要性
即使擁有絕佳的市場想像力，若開發無法跟上商業需求，產品仍將無法落地。開發品質是確保產品快速成形、穩定運行並持續演進的核心。
團隊應具備的開發能力：
迭代思維：產品永遠有bug、洞察永遠可以更精準、功能永遠不足以滿足使用者。敏捷開發、快速實驗與調整，才能搶佔市場時機。
穩健的開發方法論：團隊具有共識的開發方法論，可以是Scrum、Kanban等流程管理工具，提升團隊效率。
人力素質與團隊協作：技能能力足夠，有品質的開發團隊
產品品質維護能力：包含測試自動化、版本控制、錯誤回報機制，確保產品穩定性。
開發管理能力：PM必須能與技術負責人協作，妥善安排時程與資源配置。
3. 市場接觸：持續驗證市場與使用者需求的實戰力
為什麼市場接觸不可或缺？
許多軟體產品的失敗，並不是因為技術不好、功能不夠，而是太晚與市場接觸、錯過關鍵回饋。產品規劃、開發到優化的過程中，必須持續與市場互動，以真實用戶回饋來調整方向。
PM與團隊需具備的能力&要能夠清楚回答的問題：
市場驗證實力：運用MVP（最小可行產品）、A/B測試、假設驗證來降低風險。
Go-to-Market（GTM）策略：從行銷通路、定價策略、早期使用者經營等角度，建立產品進入市場的路徑。
用戶關係管理（CRM）策略導入：追蹤使用者行為、反應與生命周期，進行精準迭代。
不同階段的成長策略規劃：從冷啟動到成長曲線，PM要懂得設計不同階段的用戶獲取策略。
延伸閱讀：PM產品經理核心競爭力是什麼？解析開發「好產品」的3重點
PM能力轉譯：3維度對應不同階段的產品策略焦點
產品的發展歷程分為早期探索期與成長穩定期，PM在不同階段應該有不同的重點與策略思維。
早期產品的PM：假設、快速驗證、打造MVP
市場估值：洞察與假設力
創新觀點：PM要能從使用者痛點中，看出尚未被解決的需求缺口。
TA觀察力：透過使用者訪談與數據觀察，擬定精準的市場假設。
開發品質：推進MVP的節奏與協作
快速建構初版產品：以低成本方式實作MVP，搶先測試市場回饋。
專案溝通能力：在高不確定性下，跨部門溝通成為成功關鍵。
市場接觸：進行實地驗證與啟動擴散
初期使用者經營：找到願意參與測試的目標用戶，觀察其使用習慣與反應。
小規模GTM執行：測試定價、訴求與通路效益，找出最有效的推廣方式。
成熟產品的PM：持續與規模化
市場估值：開啟第二成長曲線
持續探索新價值：當產品進入穩定期，PM要思考新的價值主張與市場定位。
市場再細分：透過功能擴充，服務不同層級的用戶，創造新的成長來源。
開發品質：穩定中提升效率
追蹤開發KPI：如bug數、部署頻率、系統穩定率，反映開發健康狀況。
架構重構與技術債處理：避免日後阻礙產品演進。
市場接觸：聚焦成效與ROI
精準預算運用：將資源投入在最具效益的通路與成長活動。
數據導向成長策略：透過行為分析、轉換率追蹤，優化整體成效。
延伸閱讀：初階PM如何提升專業能力？從Junior PM進化成Senior的4個職場指南
打造賺錢產品，是市場×技術×運營的整合功夫
好產品從不是單靠直覺或創意誕生，而是需要一支能同時掌握商業價值、技術品質與市場節奏的團隊。PM就是這支團隊的靈魂人物，需橫跨3個維度，掌握從「假設」到「驗證」、從「開發」到「獲利」的每個關鍵點。
唯有在這3個維度中持續優化與對齊，產品才能真正從一個idea，走向一門賺錢的好生意。
（原文標題：軟體產品從開發到獲利的三支腳 & PM 對應的能力：市場估值、開發品質與市場接觸）
[joblist_plugin title='更多【產品經理】工作機會' url='https://www.104.com.tw/jobs/search/?keyword=PM產品經理' amount='3']
推薦閱讀：
PM產品經理面試如何準備？沒經驗有機會錄取嗎？專家傳授必備5大面試題
「產品經理」要考證照嗎？NPDP與PMP差在哪？解析PM關鍵6大能力
轉職「PM產品經理」，研發背景較有優勢？過來人揭3類型轉職最易成功
[course_plugin title='產品經理學習營｜學習推薦' keyword='產品經理學習營' amount=2]
Meta 首款模型 Muse Spark Meta AI App 及 Meta.AI 網頁全面升級
2026-04-09 經濟日報記者彭慧明 由聯合新聞網授權轉載
Meta宣布，正式推出全新語言模型Muse Spark，是Meta Superintelligence Labs打造全新系列的大型語言模型中的第一個模型。
Muse Spark是Meta專為旗下產品量身打造的全新模型，也是迄今最強大的模型，有效提升Meta AI的效能及反應速度。目前已導入Meta AI App及Meta.AI網頁，支援進階邏輯推理與多模態任務處理。並預計於未來幾週內，陸續推展至Facebook、Instagram、Messenger、WhatsApp與AI眼鏡中。Meta也將透過API限定開放模式，提供給特定合作夥伴搶先體驗。
Meta在Muse Spark中導入強大的多模態感知能力，與其他AI需仰賴用戶逐一輸入描述不同，Meta AI不只能讀懂使用者輸入的文字，更能直接看見並理解大眾提供的視覺資訊。
例如，只要拍下機場零食架的照片，Meta AI就能辨識並排序出蛋白質含量最高的零食，無須費力查看營養標示，只要直接掃描商品，即可快速了解不同零食的成分差異。Meta AI應用於AI眼鏡時，AI助理將更清楚掌握並理解周遭環境。
健康資訊是大眾使用 AI 的主要需求之一，Meta AI透過Muse Spark的多模態感知能力，將可評估不同情境的影像與圖表，提供更細緻的回覆。Meta AI攜手臨床醫師專團隊，提升模型在常見的健康相關問題上，提供健康與醫療領域相關資訊，回應協助大家理解與健康有關的疑慮。
Muse Spark也擅長視覺化程式開發（visual coding），只需要輸入提示詞，就能建立客製化網站與小遊戲。未來可以請Meta AI製作一個用來規劃驚喜派對的儀表板、快速生成一款復古街機遊戲邀請朋友一起挑戰，或推出一個充滿想像的飛行模擬器，並將這些遊戲內容分享給朋友。
IC設計工程師、製程工程師與設備工程師一次搞懂！薪資、壓力與工作型態全面比較
在半導體產業中，不同角色的工程師雖然都在同一條產業鏈中工作，但無論從工作內容、工作場域，到薪資待遇，都存在明顯差異。本文整理前台積電營運效率部門主管—彭建文於104職涯診所EP482分享內容，從數位IC設計工程師與半導體設備工程師切入，並延伸探討數位IC設計工程師、類比IC設計工程師、製程工程師與設備工程師的不同。
文／104人力銀行小編整理
本文目錄（點擊可快速前往）
數位IC設計 vs. 半導體設備工程師：薪資差異從何而來？數位IC設計工程師：腦力密集的工作半導體設備工程師：與機台為伍的工廠守門人類比IC設計工程師：自然訊號的轉譯者半導體製程工程師 vs. 設備工程師 vs. 整合工程師：三者有何不同？結語：選擇工程職涯前，先了解你的生活型態與成就感來源
數位IC設計 vs. 半導體設備工程師：薪資差異從何而來？
以年薪中位數來看，數位IC設計工程師大約為 120萬，而半導體設備工程師則是 80萬。兩者都屬於半導體產業，但一個屬於上游的IC設計，一個則在中游與下游的製造階段。工作性質與壓力來源截然不同，也造就了薪資上的落差。
數位IC設計工程師：腦力密集的工作
數位IC設計工程師大多任職於聯發科、聯詠等IC設計公司，這些公司主要部門就是研發。工程師的日常工作幾乎都在辦公室內，負責用電腦設計與模擬IC電路，專注於專案的開發與時程控管。
這類工作強調「Time to Market」的壓力，意思是必須在限期內完成設計，趕上市場時機。例如原訂三個月完成的專案，可能會被要求一個月就得交出成果，因此需要極高的專注力與技術力。
尤其近年AI應用快速發展，帶動ASIC（特定應用IC）需求激增，讓IC設計研發的價值與重要性更上層樓。
[joblist_plugin title='【數位IC設計工程師】精選職缺' url='https://www.104.com.tw/jobs/search/?keyword=%E6%95%B8%E4%BD%8DIC%E8%A8%AD%E8%A8%88%E5%B7%A5%E7%A8%8B%E5%B8%AB+ic+design&isJobList=1&order=15&page=1' amount='3']
半導體設備工程師：與機台為伍的工廠守門人
設備工程師的工作地點大多在新竹、苗栗、台南等地的無塵室，需穿著無塵衣，確保生產設備穩定運作。他們的壓力並非來自「時程」，而是「即時反應」——設備一旦故障，就可能造成數百萬的晶圓產能損失。
這些工程師需隨時待命（on-call），半夜接到機台異常的電話是常態，甚至需即刻返廠處理。壓力來源包括：
設備異常時需快速判斷、拆解問題
無法獨立處理時還需聯繫供應商（vendor）協助排除故障
處理完後還要撰寫報告，向廠長說明原因與改善方式
即使設備看似「沒問題」，工程師也可能因產出未達預期數量而被追問，壓力不容小覷。
[joblist_plugin title='【半導體設備工程師】精選職缺' url='https://www.104.com.tw/jobs/search/?keyword=%E5%8D%8A%E5%B0%8E%E9%AB%94%E8%A8%AD%E5%82%99%E5%B7%A5%E7%A8%8B%E5%B8%AB&isJobList=1&order=15&page=1' amount='3']
類比IC設計工程師：自然訊號的轉譯者
與數位IC設計不同，類比IC設計工程師處理的是來自現實世界的連續訊號，如聲音、光線等，需將這些訊號轉換為IC可以處理的形式。這領域相對更貼近自然原理，也通常被視為IC設計的源頭之一。
數位與類比IC設計工程師在訓練與知識上有所區隔，前者強調邏輯與數位系統架構，後者則更重視訊號處理與電路模擬。
[joblist_plugin title='【類比IC設計工程師】精選職缺' url='https://www.104.com.tw/jobs/search/?keyword=%E9%A1%9E%E6%AF%94IC%E8%A8%AD%E8%A8%88%E5%B7%A5%E7%A8%8B%E5%B8%AB&isJobList=1&order=15&page=1' amount='3']
半導體製程工程師 vs. 設備工程師 vs. 整合工程師：三者有何不同？
有些人會將「半導體工程師」這個名詞與製程、設備混為一談，實際上這三者職責明確分工：
半導體設備工程師：專職維護與操作生產設備，確保機台穩定運作，避免停機、達預期數量產出。
半導體製程工程師：掌控整條生產流程，優化機台的設定，思考如何提升良率。
半導體工程師（整合工程師）：是較廣義的角色，需了解製程、設備等不同面向，具備跨領域協調與整合的能力。
年薪中位數方面也有些幅差距：
半導體工程師：約 93萬
製程工程師：約 88萬
設備工程師：約 80萬
[joblist_plugin title='【製程工程師】精選職缺' url='https://www.104.com.tw/jobs/search/?keyword=%E8%A3%BD%E7%A8%8B%E5%B7%A5%E7%A8%8B%E5%B8%AB&isJobList=1&order=15&page=1' amount='3']
結語：選擇工程職涯前，先了解你的生活型態與成就感來源
數位IC設計、類比IC設計、製程工程師與設備工程師，雖然都屬於工程領域，卻走向截然不同的職涯路徑：
喜歡坐在辦公室、用腦力解題、參與長期專案，有技術深入與產品成就感？ 你可能適合走向 IC設計，無論是數位還是類比。
喜歡實作、現場操作、面對機台與即時問題，從實體運作中找到成就感？ 那 設備工程師 會是你的舞台。
喜歡系統性思考、跨單位協作、關注製程穩定性與良率提升？ 那你或許適合走向 製程工程師，成為連結設計與現場的關鍵橋梁。
每個角色都不可或缺，在選擇工程職涯之前，不妨先了解產業分工、自己的性格與成就來源，再決定適合自己的未來方向。
前端離職交接計畫：軟體專案工作交接及心態準備
做好離職交接是職場專業的表現，尤其在軟體專案中，交接過程不僅影響PM的專案管理，也直接關係到RD能否順利接手執行。本文作者為前端工程師，分享從離職的心態準備到實際工作交接的實用建議，為離職劃下完美句點、與公司好聚好散！
文／林彥成｜前端三分鐘
本文目錄：前端工程師離職交接計畫（點擊可快速前往）
離職心態準備離職前離職準備離職工作交接離職遇過的5個交接鬼故事
離職最重要的事就是對自己的職涯負責，交接是雙方要一起跟專案走到哪裡，著重在接下來PM的專案管理和RD接手執行難易的程度。
談離職，除了心態準備之外，大致上會有3個過程：
離職前
離職準備
離職工作交接
【作者檔案】林彥成，資深前端工程師，網站前後端開發經驗9年。珍貴線上Q&A機會，直擊台積電工程師的真實生活！限時報名>>
離職心態準備
公司成長整體來看會是平均值，對個體來說成長的速度超過平均再正常不過，所以隨時面試和思考何時離職就是一個對自己職涯負責的方式。
能跟有能力的同事共事需要幸運，主管並不是阻礙我們離職的人，應該是職涯往前進步的助力。
交接心態上分成3點：
交接意識
認知落差
立場和回饋
重要的是要有共識，這樣前進的時候方向才會一致。
1. 離職交接意識
最重要的是有意識這件事，必須意識到在未來的某個時刻，任務就會交給你進行，對需要接手的人來說，就是需要創造這樣的意識。
對爬山來說，根據天候、路程、體力要做哪些準備。
對專案來說：
目前遇到了什麼問題？
狀態覺察，理解現在位置在哪裡，處在什麼樣的狀態？
2. 認知落差
資訊上的落差 ⮕ 認知差異
未來的走向是誰決定，接下來的策略走向和計畫？
為什麼會有這樣的功能？
知識上的落差 ⮕ 理解問題
規格、需求、其他文件資源。
開發、測試、跨部門合作流程上了解。
經驗上的落差 ⮕ 吸收和上手速度
整理FAQ文件。
提早把部分工作內容少量多次交給相關同事。
工作能力與基礎知識不同，會有吸收速度上的落差。
關鍵人物理解的落差 ⮕ 溝通成本
會不會找不到流程中常常需要接觸的人？
會不會找不到出問題可以問的人？
3. 立場和回饋
沒辦法用叫的讓人家怎麼做，只能讓大家知道該怎麼做，最後自己願意去做。
交接跟減重一樣只有一種方法有效，只有你願意堅持的那一種。
不知道自己不知道，可是也不會有人知道你不知道。
沒有人應該主動替你著想或是教會你職場上該會的事情。
離職前
離職前讓老闆理解你的職涯發展狀況，一開始就堂堂正正講真的理由。該好好反覆問自己是否在原來的公司沒有辦法得到任何的改善和進步了？
確認自己的計劃，反覆檢視是否需要離職。
提早和同事們、老闆聊聊可能會有想要異動的原因。
成長的速度是否被公司環境影響而變慢了。
離職會造成老闆的困擾會有幾個部分：
員工C/P值太高
接替的下一位難找
訓練的時間成本
延伸閱讀：離職預告期怎麼算？離職免預告、例假日試算等勞基法QA大解析
離職準備
決定要離開之後就提早做好相關準備，怎麼做交接就會怎麼留下自己在公司的印象。
越提早公開相關訊息，交接的時候就可以避免平常上班在逛網拍的同事打擾？大家過往在學校、職場都會遇到雷包隊友，讓透明度全開就可以讓目前專案或是團隊問題有機會顯化，相關公開訊息也可以在操作過程中留下紀錄。
只要把事實攤開來，當大老闆或主管知道後，有眼睛的人其實都會知道問題在哪裡。
最好的狀況是文件交付後，有問題再協助接任者 ⮕ 給對方需要的，對方才會感謝你。
提早讓各種問題透明且交代清楚 ⮕ 有事沒事就寄信、發群組訊息，留下真實的記錄與證據。
照三餐分享工作進度 ⮕ 讓全部有關的人都知道你在做什麼。
讓主管和同事知道：
為什麼你會選擇離職，而你又做了哪些努力
預告接下來的新人會怎麼死，至少知道哪裏有坑，能事先預防或繞路
離職工作交接
軟體專案操作上有3個重點：
地圖全開：不管懂或不懂都讓事實全貌呈現
寄信溝通：副本給想打擾的主管，不然就換主管打擾你
實體交接：好壞都要開會，相關主管務必在場
1. 地圖全開
這段時間的工作不是去理解，而是探索事實的全貌，就像玩世紀帝國遊戲剛開始會在初始建設後就使用速度最快的輕騎兵先把整個地圖跑過一遍，快速確認資源、敵方狀態和相對位置。
工作交接上：
用最快的速度看完專案全貌。
了解對方狀態、資源。
專案目前相對於短期目標完成所在的位置和未來發展的方向。
2. 寄信溝通
心虛的人通常不敢寄信，但建議還是留下證據，有雷被挖坑沒關係，但不需要讓未來整個團隊來背鍋，是之前的問題就該在離開前被顯示出來。
殷素素：「記住，別相信女人，越漂亮的女人越會騙人。」
不可考：「寧可相信世上有鬼，也不要相信男人那張嘴。」
寄信的好處有3點：
等交接時也可以原封不動將相關紀錄再交接
留下相關溝通紀錄，職場上推責任是必備技能，寄信是保護自己也保護部門
較方便將訊息同步給忙碌的高層主管，以前爛專案副本最高有給到副總
3. 實體交接
通常按照文件還是有機會跑不起來，實體的示範就相對重要。趁此機會對齊知識、文件、資源上的落差，像是如果步驟有少、檔案有少就需要快點請對方提供。
如果交接到有專案爛掉的情況，就在公開場合告知大家，並請示主管該如何處理，當然不期待可以修好，但至少讓對方協助在相關的位置補上註解，補註解就比較不會有時間不夠的藉口。
其他形式的交接就自己寫文件請對方確認或是請對方協助補相關說明。
離職遇過的5個交接鬼故事
工作這麼多年來，也交接10幾個專案跟不少同事交手過，底下簡單分享幾個鬼故事：
交接專案檔案有少給的情況，當然可能不小心沒有進版控或是認為這個檔案不需要進版控，所以不要天真單純的以為線上可以跑就可以跑了。
遇過專案會記憶體洩漏，由於伺服器都32G+在使用上並不會頻繁出現，經主管提醒用8G測試機開一整天測試才發現問題。
網頁在特定時段只要開著就會壞掉，這真的要感謝主管提醒，透過掛機也才能發現問題，不然得到說法是QC測過沒問題了。
同事背後被幾個部門抱怨仍沒優化做法，但可能沒有過受適當訓練無法解決問題，正常幾天做好的事拖到2週至1個月，只剩抱怨前任很爛的功能。
沒有任何交接文件，詢問主管時只說人還在直接問就好了。
（原文標題：離職交接計畫：軟體專案（被）交接的心態準備與踩坑鬼故事）
[joblist_plugin title='更多104【軟體工程師】工作機會' url='https://www.104.com.tw/jobs/search/?keyword=%E8%BB%9F%E9%AB%94%E5%B7%A5%E7%A8%8B%E5%B8%AB' amount='3']
軟體業Technical Writer工作在做什麼？技術文件為何不是由PM寫？
軟體產業的Technical Writer工作在做什麼？和PM產品經理工作有什麼差異？Technical Writer職位結合「內容寫作」和「技術寫作」的專業，可以將硬梆梆的技術內容、轉換成一般使用者也能好理解的技術＋商業內容。本文作者以自身經驗分享，解答包括Technical Writer工作內容及為什麼不由PM來寫技術文件。
文／朱麒
本文目錄（點擊可快速前往）
1. Technical Writer到底要幹嘛？2. 為什麼需要Technical Writer？3. 為什麼不由PM來寫技術文件？
我曾經擔任PM將近6年的時間、在新職位—Technical Writer工作也已經快9個月的時間，這篇文章想分享關於「寫文件」這件事情。
一開始有許多朋友和我討論說「為什麼不交給PM做就好？」在親身體驗與想過之後，我發現這兩者的定位與價值是完全不同的。這篇文章分享Technical Writer在做些什麼，以及簡單比較跟「產品經理（Product Manager）」的差異。
如果你對軟體產業有興趣、正在當PM的人、或是潛在想當Technical Writer的人看（有這樣的朋友嗎），一起來看看這篇文章吧。
備註：請留意此篇文章的脈絡都是以「軟體開發」的角度來談。
1. Technical Writer到底要幹嘛？
簡單說，就是替公司的產品寫一份「攻略本」。
攻略本是電玩產業的詞，能幫助新手玩家快速學會操作方法、了解遊戲目標，接著就可以比較開心的在遊戲的世界中玩耍。
而「技術寫作（Technical Writing）」就是替公司的產品寫使用文件，用來引導消費者更好地使用公司產品。技術寫作也可以視為公司品牌、產品使用體驗的一環，能影響消費者對於公司產品的整體觀感。
這就像「攻略本」會先告訴新手玩家基本的操作方法，讓玩家在別在超大的遊戲世界中不知所措的亂跑、被怪打死而感到挫折（可能一開始連「基礎戰鬥知識」都沒有就跑出新手村）。
好的技術文件，應該能夠把公司產品複雜的功能與規格，在適當的時間點、用適當的方式告訴使用者。
2. 為什麼需要Technical Writer？
對呀，為什麼不由最熟悉產品功能與規格的程式開發者或產品經理，來寫技術文件就好了呢？
先從「軟體開發者」的角度來說。由於技術文件（例如API Documentation）是技術含量相當高的文件，最好的寫作者當然是由開發者來寫。
然而多數的開發者在寫文件的時候，容易從非常技術的角度撰寫文件—多數狀況是「只解釋程式功能，但不解釋程式對於使用者的目的」。由於程式往往有自己的商業邏輯（例如建立訂單的流程、訂單對帳與請款的方式），使用者在不清楚商業邏輯的前提下直接閱讀，往往一頭霧水。
因此Technical Writier誕生了，這個職位結合「內容寫作（Content writing）」和「技術寫作（Technical Writing）」的專業，可以將硬梆梆的技術內容、轉換成一般使用者也能好理解的技術＋商業內容。
Technical writer像是一位翻譯員，要把「技術」國家的語言翻譯給「商業」國家的人理解。
3. 為什麼不由PM來寫技術文件？
行行好，放過PM吧！
PM的工作包山包海，要跟業務單位／客戶對需求、花時間整理規格、跟設計師／工程師／QA／營運團隊溝通。
PM職責範圍確實也包含寫產品的規格與規劃，例如：
使用者故事（User Story）： 即 As a（使用者）, I want（做什麼事情）, so that（得到什麼成果），讓產品團隊理解每個功能為誰而做、要做什麼、做完成果。
User Story Acceptance Criteria Test Cases：寫完User Story後，必須要進一步描述這個功能的細節，透過「Given（在什麼情況下），When（當使用者做了什麼），Then（會發生什麼事情）」才能讓工程師與QA（測試工程師）執行。
Product Roadmap：告訴C字輩的老闆接下來的產品發展，這一季要做什麼、為什麼要做、要打哪些用戶、如何衡量成效、成效好與不好的相對應措施是什麼。
可以看到，PM的寫作文件通常是「對內」，告訴團隊接下來要做些什麼、不做些什麼；但Technical Writer通常是「對外（外部使用者）」，告訴使用者產品從哪裡開始用、要完成對應的事情該怎麼做、技術細節要到哪裡去查……等。
PM和Technical Writer的技能樹不同，前者更多在溝通、後者更多在引導。更多文章分享，可至「朱騏部落格」閱讀。
（原文標題：軟體產業中的 Technical Writer 在做些什麼，為什麼「寫文件」這件事情不都交給 PM 做就好？）
[joblist_plugin title='更多104【Technical Writer】工作機會' url='https://www.104.com.tw/jobs/search/?keyword=Technical%20Writer' amount='4']
「接案作品集」怎麼準備？6大要素及不同客戶應對技巧
對自由接案工作者來說，「作品集」往往比履歷更能展現你的專業度與價值。一份好的接案作品集該怎麼準備？作者為軟體工作者，分享好作品集的6大必備要素，並用自身經驗解析技術型、設計導向、非技術型與綜合型客戶的關心重點，幫你打造更有說服力的作品集。本文節錄自《不想上班的勇氣：軟體工作者的第一本接案指南》。
文／陳泰銘（Taiming）
本文目錄（點擊可快速前往）
為什麼需要準備接案作品集？接案作品集準備方向：依照不同接案類型、客戶來調整好的作品集應該具備的6大要素沒有作品集怎麼辦？最好平時就累積Side Project
為什麼需要準備接案作品集？
作品集是接案者的「敲門磚」，能夠幫助潛在客戶快速了解你的能力、風格和經驗。有時候，你的作品集甚至比你的履歷還重要，因為它是最直觀的證明，展示你的專業度和價值。
客戶沒有時間細聊，先看作品決定是否聯繫你
比起履歷，作品集更能說明你的實力
客戶更信任有實際案例的接案者
降低溝通成本，幫助客戶確定風格與需求
讓你在競爭者中脫穎而出
當你在社群平台或論壇上看到有人發問：「有人可以幫我做插畫設計嗎？」如果你只是留言「我可以做」，很容易淹沒在眾多回覆中，客戶也不會特別關注你。但如果你直接附上作品集連結，讓對方點進去就能看到你的實力，成功機率就會大幅提升。這樣的方式不僅能讓你在競爭中脫穎而出，也能迅速抓住客戶的注意力。
接案作品集準備方向：依照不同接案類型、客戶來調整
一開始瞄準方向很重要，因為不同類型的客戶關心的重點不同，你的作品集應該根據你的目標市場來調整。例如：
技術型客戶：展示程式碼品質與技術細節
當你的目標客戶是開發公司或技術團隊時，他們更關心你的技術能力，而不只是表面的作品展示。例如，當一間軟體公司正在尋找後端開發者時，他們不會單純看UI設計，而是會評估你的程式碼品質、架構設計與API文檔。如果你的作品集包含GitHub專案連結、技術架構解析、程式碼片段或效能優化案例，將更能說服這類客戶，讓他們相信你具備專業的開發能力。
非技術型客戶：強調成果與商業價值
當你的客戶是中小企業或個人創業者時，他們通常不懂技術細節，而是關心你的工作能否為他們帶來實際價值。例如，一位餐飲業老闆希望建立線上訂餐系統，但他不懂技術，對「技術堆疊」也沒有興趣。他想知道的是這個系統能否提升業績、減少人工成本、讓顧客更方便。因此，針對這類客戶，你的作品集應該側重於案例說明，包含專案背景、解決的問題、最終成果與數據，例如「這個網站讓客戶下單率提升30%」，而不是單純列出技術細節。
設計導向的客戶：重視視覺呈現與品牌一致性
當你的客戶是品牌商、電商品牌或行銷團隊時，他們關心的是視覺美感與風格統一性，而不是技術實作的細節。例如，一位服飾品牌老闆希望找人設計一組社群貼文模板，他不會關心這些設計是用Photoshop還是Figma製作的，而是想知道你的設計是否符合品牌形象，能否吸引目標受眾。因此，你的作品集應該著重展示設計風格，提供高品質的圖片、完整的設計概念，並附Behance、Dribbble或Figma連結，讓客戶能夠直觀地評估你的視覺風格是否符合需求。
綜合型客戶：需要靈活調整作品集內容
有些客戶的需求涉及多個面向，例如，一家新創公司希望開發一款APP，他們既關心UI設計，也重視技術架構與開發能力。在這種情況下，若你的作品集過於單一，可能無法完整展現你的能力。最佳做法是針對不同領域準備不同版本的作品集，例如一份專注於UI/UX設計，另一份則強調技術架構與開發過程，這樣才能根據不同客戶的需求靈活調整，確保你的作品集能夠精準打動對方。
因此，一開始要明確你的目標客戶，這樣作品集才能精準打動對方，而不會顯得雜亂或無法吸引適合的機會。
好的作品集應該具備的6大要素
一份優秀的作品集，不只是展示你的能力，更應該幫助潛在客戶快速理解你的價值，並建立信任感。以下是作品集應該具備的關鍵要素：
1. 清楚的自我介紹與專業定位
你的作品集應該開門見山地說明你的專業領域，例如「專注於SaaS產品開發的全端工程師」或「專精品牌識別與UI設計的視覺設計師」，讓客戶一眼就能理解你的核心技能與市場定位。
2. 精選案例，而非堆砌大量作品
作品集不應該只是單純堆放所有作品，而是要精選最具代表性的案例，並確保這些案例與你的目標市場匹配。例如，如果你主要服務科技新創，那麼展示SaaS產品設計或開發案例會比一般電商網站更具說服力。
3. 案例背景與解決方案
單純的圖片或程式碼展示不足以吸引客戶，你應該為每個案例補充背景資訊，例如：「這是為某家新創公司開發的會員系統，目標是提升用戶留存率」，然後說明你的解決方案與貢獻，例如：「透過重新設計UI/UX，讓註冊轉換率提升20%。」這樣的敘述能讓客戶更容易理解你的價值。
4. 數據與成果驗證
如果可以的話，加入量化數據來證明你的工作成效，例如「重新設計後的網站，跳出率降低25%」、「API優化後，請求速度提升40%」，這樣的數據能讓你的作品更具說服力，提升客戶的信任度。
5. 直覺且專業的視覺呈現
作品集的排版應該簡潔清晰，避免雜亂無章的內容堆砌。如果你是設計師，這本身就是對你美感能力的考驗；如果你是工程師，也應該讓專案展示清晰易讀，像是使用卡片式設計來分類案例，或提供 GitHub 連結搭配摘要說明。
6. 聯絡方式與行動呼籲（CTA）
無論作品集是網站、PDF還是簡單的Notion頁面，都應該明確提供聯絡方式，例如Email、LinkedIn、或接案平台連結。此外，可以加上一些行動呼籲，例如「有興趣合作嗎？歡迎來信討論！」，讓客戶知道下一步該怎麼與你聯繫。
透過以上這些要素，你的作品集不僅能夠有效展示你的專業能力，也能提升轉換率，讓潛在客戶更容易做出決策，進而提高你的接案成功機會。
沒有作品集怎麼辦？最好平時就累積Side Project
其實，比起事到臨頭才急著找作品集，最有效的方法是平時就主動累積Side Project。不論是為了解決某個小問題、實現自己的點子，還是純粹為了學習新技術，只要能完成、有成果可展示，就能成為你的實戰證明。
Side Project不需要商業化，也不必太龐大，關鍵是能展現你的能力與風格。這些專案可以放在你的個人網站、GitHub、Behance、Notion或Medium等平台，讓潛在客戶在搜尋你的名字時就能看到。
以下是一些常見的發想與執行管道：
解決自己的痛點：把日常遇到的問題變成產品，例如排程工具、記帳App、小型自動化腳本等。
模仿與改造：挑一個你喜歡的網站或應用，試著重製、優化或加入新功能。
開源貢獻：參與GitHub上的開源專案，累積實戰經驗與人脈。
挑戰題目平台：參加如Frontend Mentor、Dribbble Weekly Warm-up、Kaggle等主題挑戰。
幫朋友或社群做東西：主動幫朋友設計海報、開發活動報名網站、製作社群 BOT 等。
紀錄學習歷程：把你學會的新技術或解法整理成部落格、教學影片或Notion範本。Side Project的價值，不只是讓你練功，更是你與客戶溝通時最有說服力的「非商業作品集」。尤其在你還沒太多實戰經驗時，它們能說明你的主動性、邏輯思維、執行力與品味。
節錄自：博碩《不想上班的勇氣：軟體工作者的第一本接案指南》／陳泰銘（Taiming） 著
獨家課程推薦：【設計師接案必修課】從作品集到報價，系統化讓專業變現
[joblist_plugin title='更多104【軟體工程類 接案】工作機會' url='https://www.104.com.tw/jobs/search/?jobcat=2007001000&mode=s&page=1&ro=2&keyword=%E6%8E%A5%E6%A1%88&order=15' amount='4']
更多【自由接案】分享：
上班族也掀「斜槓兼職」熱潮！高薪兼職時薪破千，兼職工作機會懶人包
接案族該如何報稅？一文搞懂「接案外包」的報稅技巧，趕快收藏！
設計接案合約必備5大要素！保護權益必知，終結客戶鬼打牆
接案報價不是憑感覺！給新手的基礎報價公式參考
2025 最完整免費接案平台、接案社群總整理（附設計、行銷外包接案工作機會）
從創意到實現──屏東高工製圖科打造設計落地的能力
一項產品誕生之前，需要先有一個想法；而一個好的想法，要真正成為看得見、摸得到的作品，還需要經過設計、繪圖、建模、驗證與修正等一連串過程。設計圖不只是產品的藍圖，更是串連創意與製造的重要橋梁。 屏東高工製圖科培養的，正是這種將創意轉化為現實的能力。許多人不清楚製圖科與機械科的差異與關聯性，其實兩者分別著重同一種專業中不同階段的能力：機械科著重於加工製造，特別擅長動手操作，而製圖科則站在製造流程的前端，負責將構想轉化為工程圖，再透過模型製作與實作驗證，讓一個想法逐步成為真正能被製造的產品。
（圖：學生操作電腦繪圖軟體完成圖面設計 ）
從想法開始，循序建立設計能力
把創意化為現實，並不是一蹴可幾，而是需要一步步累積專業能力。
屏東高工製圖科的課程安排，在高一時，讓學生先從工程字、三視圖等基礎開始，透過手繪建立空間概念與圖面表達能力，同時接觸機械加工基礎，認識不同材料、加工方式及機械原理。進入高二後，課程逐步導入 AutoCAD、Inventor 等電腦繪圖軟體，讓學生學習如何將平面圖轉換成立體模型；到了高三，則結合專題製作、3D列印等課程，讓設計真正從螢幕上的圖面走向實體作品。
看似是不同階段的課程，其實都圍繞著同一件事情──培養學生將想法具體表達、逐步實現的能力。從最初的一筆一畫，到完成立體模型，每一門課都不是獨立存在，而是在不同學習階段，引導學生建立完整的設計思維，也理解一件作品如何從概念走向成品。
（圖：學生運用尺規工具完成手繪製圖練習 ）
好的設計，建立在理解製造之上
不少人認為設計就是發揮創意，但在屏東高工製圖科，創意只是起點，更重要的是讓設計真正能夠被實現。
製圖科主任陳儀峻指出，學生除了學習繪圖之外，也必須接觸加工基礎與製造流程。因為一件產品是否可行，不只是取決於設計是否美觀，更需要考慮材料特性、加工方式及結構安排。如果不了解後端製造流程，再有創意的設計，也可能因為無法加工而停留在想像階段。
因此，製圖科希望培養的並非只是繪圖技巧，而是兼具創意與實務的設計能力。學生在學習設計的同時，也會實際接觸車床等加工設備，了解不同零件是如何製造出來，也理解設計圖上的每一條線、每一個尺寸，最後都會影響產品是否能夠順利完成。
換句話說，在製圖科，設計與製造並不是彼此獨立的兩件事情，而是不斷來回驗證、相互修正的過程。學生不只是學會使用繪圖軟體，更逐漸建立工程設計所需要的判斷能力，知道如何在創意與實際製造之間取得平衡，讓一個構想真正具備落地實現的可能。
（圖：學生操作車床設備進行金屬加工練習 ）
在一次次驗證與修正中，讓創意真正成形
如果說設計是一個把想法化為現實的過程，學生真正的學習，往往發生在作品第一次被做出來之後。受訪的方同學分享，自己最喜歡的課程之一，是結合 3D 列印的鑄造原理課。過去停留在圖面上的設計，透過電腦建模、3D列印與翻模製作，逐漸變成一件可以拿在手中的作品，讓他第一次真正感受到設計「從無到有」的過程，也因此對製圖產生更深的興趣。
然而，真正開始製作後，他才發現設計並不是把圖畫出來就結束了。尺寸是否正確、結構是否穩固、組裝是否順利，許多原本在螢幕上看不出的問題，都會在實際製作時一一浮現。有時需要重新修改尺寸，有時則必須重新思考整體設計方式，再重新列印、重新測試，才能完成一件真正符合需求的作品。對他而言，這些反覆修改的過程雖然花時間，卻也是學習最大的收穫，因為每一次修正，都讓他更理解設計背後需要考量的細節。這也讓他發現，好的設計並非一次完成，而是在一次次驗證與修正中逐漸成熟。
（圖：學生展示皮革散子包專題成果 ）
另一段讓他印象深刻的學習經驗，則來自第一次接觸大型加工設備。實際面對機械設備，剛開始難免因高速旋轉的刀具與飛散的鐵屑感到緊張，但隨著老師一步步指導，以及不斷練習與考取證照，他逐漸克服原本的害怕，也開始享受親手把設計完成的成就感。對他而言，製圖科帶來的不只是專業能力，更讓自己在一次次挑戰中建立起面對問題、解決問題的信心。
從生活中發現問題，再用設計提出解方
除了培養專業技術，課程設計上也希望學生理解，設計並不是為了完成一份作業，而是為了解決真實世界的問題。
因此，高三的專題製作不只是整合三年所學，更鼓勵學生從生活中尋找靈感，思考如何運用設計改善日常需求。有些作品源自生活中的小困擾，有些則結合機械結構與力學原理，希望透過設計讓使用更加便利。從問題發想、繪製圖面、建立模型，到最後完成實體作品，每一個環節都需要學生反覆討論、測試與修正，也讓他們體會設計並不是憑空想像，而是一個持續思考與解決問題的過程。
陳主任也提到，課堂上經常利用生活中的工具作為教材，引導學生從熟悉的事物理解工程原理，再思考如何運用設計讓產品更符合需求。透過這樣的學習方式，抽象的力學、結構與製圖知識，不再只是課本上的內容，而是逐漸與生活建立連結，也讓學生更理解設計真正存在的價值。
從創意到實現，培養讓設計落地的人才
設計，不只是天馬行空地發想，更重要的是讓一個想法真正被實現。
屏東高工製圖科透過手繪基礎、電腦繪圖、加工實作、3D列印與專題製作等完整課程，引導學生在一次次設計、驗證與修正的循環中，逐步建立空間思考、設計規劃與解決問題的能力，也理解設計與製造之間密不可分的關係。
在陳主任眼中，製圖更像是一種「工程語言」。它不只是畫出一張圖，而是一套讓設計者、工程師與製造端彼此溝通的共同語言。學生在三年的學習中所累積的，也不只是繪圖技巧，而是將創意轉化為現實、把想法真正落地的能力。這份能力，不僅是未來進入工程與設計領域的重要基礎，更是面對快速變化產業時，持續創新與解決問題的核心競爭力。
開箱製圖科的學習日常！更多科系探索，歡迎追蹤104高職生IG
在 Instagram 查看這則貼文 104高職生（@104v.hs）分享的貼文
前微軟人資：做對3件事，幫助遠離裁員名單、讓老闆看見你
如何讓自己「不在裁員名單上」？前微軟人資主管以40年實戰經驗，歸納出3個職場關鍵行動：即時記錄工作成果、不要羞於爭取功勞，以及主動協助主管。這不僅能提升能見度，更能為你的績效評估加分，職場不安期也能穩住位置！
文／樂羽嘉編譯 由天下雜誌授權轉載
本文目錄：做3件事遠離裁員名單（點擊可快速前往）
1. 隨時記錄你的工作成果2. 不要羞於爭取功勞3. 主動舉手幫主管的忙
曾經在微軟公司擔任人力資源副總裁的威廉斯（Chris Williams）有40多年管理經驗，他提出3點建議，幫助員工躲開被裁員的命運。
美國政府效率部（DOGE）寄給美國政府公務員、要求說明「你上星期做的5件事」的電子郵件，引發熱議。馬斯克（Elon Musk）揚言，沒有回信等同選擇辭職。但我們可以主動出擊，讓老闆不用寄信也知道我們上個星期完成了什麼工作，提高能見度。
威廉斯指出，提高能見度可以避免被質疑是冗員的狀況，也讓主管和你都能更輕鬆度過績效評估流程，讓你避免被貼上「表現欠佳」員工的標籤，從而避免被列入裁員名單，並獲得更多機會，也就是一種向上管理的好方法。
以下是3種讓老闆看見你、降低被裁員機率的方法：
1. 隨時記錄你的工作成果
無論你的老闆是寄出「請說明上星期5個成就」的電子郵件，還是只是隨口問一句「最近進度如何？」，你都應該時刻準備好回答。
這就是為什麼追蹤、記錄自己的成就很重要。你可以用多種方式來完成這件事。
有些人會寫「吹噓日誌」，也就是一份簡單文件，列出自己做過所有重要的事情。
也有人會用筆記本的應用程式，或是建立複雜的資料庫。
威廉斯則會建立一個簡單的4欄位excel表單，包括日期、事項、重要性和備註等4個欄位。每天或最少每個星期，都要添加幾行。在事項那一欄，他會寫上日期和一行短語，提醒自己事項內容。
而在重要性這一欄，威廉斯會放一個數字，標記當下這件事情有多重要，「5」代表最高等級。至於備註那一欄，他會加入個人註解，或是專案、文件的連結。
這樣一來，威廉斯隨時可以能整理過去一週、過去一個月、甚至過去一年內最重要的成就，當老闆要求進度報告時，他可以自信地回答：「很高興你問起這件事。」
你應該養成記錄的好習慣，每天花2分鐘更新這個清單，不只讓你的成就有據可循，對年終績效評估也有幫助。
2. 不要羞於爭取功勞
另一個保持能見度的重要方法，是確保你獲得應得的功勞，太多人因為害羞或謙虛，讓別人搶功。
在職場上，過度謙虛沒有用，反而會讓你被忽視。那些總是說「我只是做好份內的事」的人，往往最容易被邊緣化，因為他們「只是做好份內的事」。如果你想被看見，不要害怕爭取你應得的功勞。
如何確保你的努力被看見
確保你的名字出現在提案或簡報上。別害怕，在別人稱讚某個好點子時也不要羞於承認「是我的想法」。
也別讓他人偷走你的功勞，即使你沒搶到報告的機會也一樣。例如，若主管搶走功勞，下次你要讓他們知道你有注意到這件事。若你只是任憑別人搶功，他們永遠不會停下來。
3. 主動舉手幫主管的忙
最後一個保持能見度的方法，是當主管需要幫忙時，不要縮在角落當成耳邊風。老闆找人自願幫忙時，舉起你的手。
在主管心中一直加分的方法之一，就是幫助他們完成工作，尤其是他們不想或沒時間做的事情，告訴他們「別擔心，由我來」是非常重要的。
通常你很難知道他們需要你幫什麼忙，所以介入的時機可能很難判斷。當他們提出要求時，你就肯定可以幫忙了。
你不需要每次都舉手，也不用回應主管的每一個額外要求。你不應該為了留下好印象，工作到超負荷。
但你也不能當那個永遠不幫忙的人。老闆會注意到你永遠不負責報告，也不救同事，這樣你可能會給主管留下最壞的印象。
（資料來源：Business Insider、CBS NEWS）
（原文標題：前微軟人資：做3件事遠離裁員名單）
推薦閱讀：
怎麼申請失業補助？失業、就業、職訓津貼金額、資格、流程懶人包
被資遣後求職，新公司會知道嗎？4項面試準備，消除人資的疑慮
六、七十歲還能做7件事 代表你活得很成功
3200萬被動收入達成！現實感創業家3大致勝關鍵
退休後能怎麼賺？外資投信戰將：別再迷信保守固定配息
TPM是什麼職位？成為「技術PM」需要具備的6大能力
如何成為優秀的技術產品經理（Technical Product Manager, TPM）？本文透過工程師視角，解析成為TPM所需的6大關鍵能力，無論是想轉職技術PM，或是希望提升職場競爭力的PM，都值得參考。
文／朱麒
本文目錄（點擊可快速前往）
印度資深後端工程師對TPM的6個建議1. 了解基本的電腦科學（Computer Science）2. 注重細節3. 了解組織產品的軟體架構4. 開發排序5. 高度文件化6. 掌握大事總結：3個建議培養「專業」
印度資深後端工程師對TPM的6個建議
Arihant Kumar Jain是一位印度資深後端工程師，這篇文章摘要他在《An Ideal Technical Product Manager, Extract from an Engineer’s Diary》對於技術PM（Technical Product Manager，簡稱TPM）的建議。
「我們往往不會珍惜好的人或產出，直到體會到賽的。」這句話是我出社會後幾年的心得。
遇到神隊友不但可以把事情做得又快又好、甚至還可以偷學幾招；遇到雷隊友不但把事情做的又慢又鳥，甚至還可能被拖下水。
神隊友不見得跟我們是同職位的人，也不見得是同年資的人。但只要這個人夠厲害，我們就應該試著觀察與分析、甚至聽聽他們的建議（如果他還願意給建議的話），我有過太多次「聽君一席話，勝讀十年書」的工作場景，因此只要遇到就會特別珍惜。
這篇文章討論的雖然是技術PM，但內容值得其他PM職位的人學習。包含：
了解基本的電腦科學
注重細節
了解組織產品的軟體架構
掌握排序
高度文件化
掌握大事
1. 了解基本的電腦科學（Computer Science）
Product Manager依據專精的項目不同，可以再分成：
Business product manager
Marketing product manager
Technical product manager（TPM）
從字面上就可以看出，3個職位在專業上分別著重於商業、行銷、技術。
以TPM來說，至少對於技術討論、解決方案的構想、資訊架構都要有基本了解，例如設計API 時要知道REST, CRUD, HTTP status code……的觀念。
這就像對於UI設計，PM要了解公司目前的UI Library大概有哪些Componet，才不會鬧出像是「PM想這樣設計，但因公司的UI Library不支援，而要花更多時間成本客製化」的窘境。
要了解軟體技術，最基礎的學科就是電腦科學（Computer Science）。除了在職場上邊做邊學，也要定期補充學科知識，才能了解軟體技術的基本原理。
2. 注重細節
對於一個已經工作2-3年的PM來說，寫Spec應該算是駕輕就熟的事情。但決定「好」跟「專業」的Spec， 差別就在於文件的細節。
例如寫UI的User Story時，除了User Story、Functional Map、UI Flow之外，記得要規劃錯誤訊息（Error Message） 這種反面案例。如果PM不規劃，就會麻煩到QA、Developer甚至 Designer幫忙規劃，反而讓其他人有「PM是不是都沒先想這塊」的念頭。
如果是API的User Story，則要先跟Senior工程師或是主管確認是否有API文件（例如 Swagger），仔細考慮每個資料節點的收集與傳送。
「好」跟「專業」的一線之隔，在於細節。
3. 了解組織產品的軟體架構
軟體開發除了注重 Coding 的技術細節，設計完善的軟體架構也非常重要。
許多公司開發求快的結果，就是在產品上線後要不斷地花時間進行重構（refactor）。這就像是蓋一棟危樓，草草成案就動土開工，後續必須花大量時間進行修補工程才能支撐不倒。
TPM在整個過程中，可以協助當紀錄與畫圖的角色。
透過和工程師一起討論架構、整理結論、用繪圖工具畫成流程圖、系統架構圖，都能夠幫助自己對於組織的產品軟體結構更加了解，在設計產品時能夠更有Sense。
共同參與技術討論，協助紀錄與整理資訊讓自己更理解產品。
4. 開發排序
排序（Prioritization）是PM最重要的工作之一，這項技能也決定了一個PM是否有好的產品管理Sense。
排序其實是由多項子技能組成，包含產品決策、利害關係人管理、責任感、邏輯推理、成本與效益衡量……。對於TPM來說，還加入了技術方面的考量，除了考量商業利益，也必須考慮到系統是否會產生過多的技術債（Technical Debt）。
對於TPM來說，必須多分析技術方面的效益與成本，與商業決策作權衡後再做開發排序。
5. 高度文件化
不論是軟體開發還是其他領域的工作，都一定會有「問題-討論-決策-行動」的步驟，且都會面臨到「到底當初這個決策是怎麼做出來的？」問題。
場景通常會像是：一群人開始翻箱倒櫃，找Email、找線上文件區、找桌子旁的紙張、找通訊軟體的對話……這個現象你在公司中一定不陌生。
一個好的PM要非常重視「寫文件」這件事情，因為有事情別人第一個就是找PM確認。
對於TPM來說，還要多紀錄「功能技術決策」的原因。例如：
這個功能最後決定不多開資料庫欄位是因為……
前後台將透過這3隻 API 進行溝通，因為……
事實上公司中的每位角色都要有「寫文件」的意識，否則發生上述問題的時候，就只會有一句：「我不知道，那是xxx叫我做的。」
6. 掌握大事
身為PM，組織中的利益關係人有事沒事都會第一個想到你，因此重要的事情都必須要能大致掌握。舉例來說：
工程師會質疑你的決定還有產品需求細節
主管會確認產品開發進度
老闆會詢問這個專案的成本與效益
這麼多的事情，PM要做的就是Get shit done。這仰賴於對大局的理解、對資訊的掌握。
當然人的大腦也沒辦法記那麼多事情，因此我們只要知道需要的時候去哪裡查就好，這件事的前提是有做好「文件化」這件事。
「我不需要知道所有的事情，只要知道在我需要的時候去哪裡找到它。」— 愛因斯坦
( I don’t need to know everything, I just need to know where to find it, when I need it — Albert Einstein）
總結：3個建議培養「專業」
最後我將Arihant Kumar Jain提的6個建議，總結成下方3點：
1. 多跟不同職位的人學習，聽聽從他們的角度是怎麼需要你的
我們以為自己做到的，可能跟別人實際感受到的不同。一個有效的策略是跟不同職位的人聊天，問問他們：你覺得一位PM應該要能夠做到什麼事情？
2. 親自參與討論，才能培養專業的Sense
身為一個TPM要參與重要的技術決策、身為一個Marketing Product Manager要參與市場行銷的討論、身為一個Business Product Manager要參與公司商業策略的制定。
只有實際參與才能獲得深入的洞察。
3.注重細節，多想一點
「好」跟「專業」的一線之隔在於細節，細節來自於規劃時的多方面考量，多方面考量來自於過往經驗的總結。
定期做工作成果盤點，將收穫應用在下一次的規劃上。更多文章分享，可至「朱騏部落格」閱讀。
（原文標題：如何當一個技術 PM？從工程師角度來看 PM 需要具備的能力）
[joblist_plugin title='更多104【技術PM】工作機會' url='https://www.104.com.tw/jobs/search/?keyword=tpm+%E6%8A%80%E8%A1%93%E5%B0%88%E6%A1%88%E7%B6%93%E7%90%86&order=15&page=1' amount='3']
有任何收穫或想分享的，都來和大家一起聊聊吧！