這個月報名參加了，2025 IT鐵人賽的日日發文活動，挑戰自己每天發文的能耐，有一點硬，但還可以承受，所以這一期和下期的電子報，都會把每日發文的內容，做一個摘要，讓各位有興趣的內容，可以再深入閱讀。
過去一年，我試了不少 AI應用方式。有些方式剛開始看起來很炫，但實際上用不到幾次，就被打入沒再用了，可能在目前PM工作日常中，暫時還用不到；而有一些目前還是會應用的方式，變成每天都少不了的小助理。
藉著參加IT鐵人賽，順勢把自己的使用方式整理出來，整理對工作、生活有幫助，並且到現在還在用的做法。這樣一來，未來我要回頭檢視，或者想跟別人分享我的 AI 使用心得時，就有一個清楚的脈絡可依循。
如果你也對這些應用有興趣，可以直接點下面的連結，裡面會有每一則內容的完整介紹。
01_PM不加班的AI便利貼_Index
這次鐵人賽，我不談技術理論，而是整理一年來在 PM 日常中與 AI 工具的「應用心得」。
從心態轉變、提示詞技巧、日常工作到圖像應用，每個小小方法都替我省下零碎時間。
累積起來，就是兩三小時的效率紅利。
30 天，把這些便利貼般的經驗，整理成清晰版本。
02_PM不加班的AI便利貼_豐餘與匱乏
AI工具正在加速改變我們的工作與生活，資訊與內容進入「豐餘」時代：任何影集、影片或應用程式，幾乎隨手可得。與一位工程師朋友討論時，他提出對職涯的焦慮——如果AI逐漸取代基礎任務，那還發展什麼能力立足？
這問題指向一個更深層的觀察：在極度豐盈的時代，真正稀缺的不是資訊或技能，而是「美」。音樂就是一個例子，雖然底層結構相同，但透過不同的詮釋，持續創造出無法複製的經典。
技術會迭代，但創意和「美」的價值，卻從未被取代。這或許也是我們在AI浪潮中，最值得思考的核心競爭力。
03_PM不加班的AI便利貼_無用之用，重視程度越來越高
在 AI 工具快速演進的今天，我們更需要反思「不可被取代的能力」。莊子的「無用之用」提醒我們，不要只用功利的眼光看待事物。藝術與美感雖無法直接提升效率，卻讓我們的存在更有深度。
未來，AI 將能協助完成大量專業與技術層面的任務，但真正的關鍵能力仍在於人：理解需求、建立信任、傳遞情感。唐鳳也提到，獨特性來自於「你關心的領域」。這份獨特的視角，將是你在 AI 時代最重要的競爭力。
04_PM不加班的AI便利貼_用高效的AI實現想法，但用低效方式維護情感
AI 極大縮短了「想法到現實」的距離，讓文章、網站、影片都能在幾秒內完成。然而，這種高效率卻引發了另一個矛盾：創作與意義的鴻溝逐漸拉大。
標準化的內容容易規模化，卻難以打動人心；相反，低效、非標準化的事物雖不便，卻更能留下深刻體驗。這提醒我們：AI 是強大的工具，但情感與靈魂仍需要人類去守護。
05_PM不加班的AI便利貼_AI coding流程，跟真人開發流程一樣
AI codeing多數專案的卡點，不全部是「不會寫」，而是「寫太快」。
Vibe Coding 提倡在動手之前，先用 AI 模擬並驗證完整流程：BA→PM→Architect→PO→Scrum Master→Developer。透過視角輪替，把需求澄清、技術可行性、風險評估、故事拆解與迭代節奏做好，讓開發成為思考後的自然延伸，而非邊寫邊猜。
為每個角色準備最小可用產物（需求摘要、PRD、架構草圖、User Stories、Sprint 計畫），用 AI 反覆「挑戰與補齊」，直到建立清晰的規格和進程後，再寫程式，速度與品質會較佳。
06_PM不加班的AI便利貼_AI工具是提案者，不是決策者
AI 的角色正在改變我們的工作方式。它不該被視為「最終答案」，而是像一位「提案員」：提供方向、建議與解法，最後的決策仍在我們手裡。
過去，我們從圖書館、Google 收集資料，如今 AI 幫助我們跳過「從零開始」的步驟，直接加速到「0.1」或「0.2」，縮短到達「1」的時間。
在實務操作中，幾個方法能讓 AI 真正融入工作流程：
- 定義清楚任務，避免混用對話框。
- 提供基礎資料，確保輸出結果更貼近需求。
- 維護專案資料的純淨，保持穩定輸出。
- 利用角色扮演（GPTs）建立長期助手。
AI 不只是工具，而是個人系統的一環，這樣才能發揮最大效益。
07_PM不加班的AI便利貼_準備開始不加班
導入 AI 的成敗，多半不是技術，而是流程設計與分工邏輯。
- 流程盤點：標出「AI 可介入」與「必須人把關」的節點，先界定責任邊界。
- 先輸出再修正：用 LLM 作為「仲介者／草稿機」，透過往返對話把需求、脈絡、限制具體化。
- 導入三前置：資料數位化 → SOP 明確（誰／何時／完成標準）→ 優先自動化穩定、可重用環節。
與傳統搜尋不同，LLM 合作從「模糊」起步，在對話中收斂成明確結論與建議。結論：把人放在對的節點，AI 的價值才會被放大，而不是把風險外包。
08_PM不加班的AI便利貼_分析任務，讓你不加班
把 AI 納入流程而非靈感賭注，關鍵在三步：盤點→處理→標準化。
盤點：列出日常任務，區分「不想做」與「不熟悉」，優先自動化「會做但不想做」的例行項。
治理：以目標為中心撰寫動詞型需求（列點、摘要、分析），建立錯誤與偏見的警示清單，要求所有關鍵輸出附來源。
標準化：思考輸入輸出中會有那些事項， Input（材料/限制/範例/評分）、Process（步驟/判準/人工審核點）、Output（格式/品質/語氣/受眾/截止）。
迭代與後設反思讓團隊逐輪提升提示品質與決策判準。結果：更可重複、更可審計的 AI 協作。
09_PM不加班的AI便利貼_分類任務設計新工作流程
當我們評估 AI 是否值得導入時，可以透過三個面向建立客觀依據：
可執行性：任務是否能數位化、是否依賴人為判斷。
效益分析：透過 FTE 換算出人力成本，讓決策更有數據支撐。
複雜度：完成任務需跨越多少平台，判斷人類是否仍須介入。
將這三個面向放到定位圖上，能迅速判斷優先順序，找到最佳的 AI 導入場景。
這樣的框架，讓 AI 不是單純「能不能做」，而是「怎麼做最值得」。
10_PM不加班的AI便利貼_運營維護AI Native的新型工作流
在傳統運營中，重複與規律往往耗費大量時間與精力。但這些特性，恰好適合讓AI來協助處理。
AI Native的重點，不在功能，而在「互動」。就像訓練工讀生：清楚指令、建立默契、傳遞文化。AI 只有在吸收了價值觀與判斷標準後，才能真正代表我們。
目前調整的方式：
- 用自然語言與AI工具溝通，像與同事合作般釐清需求，直接用口說。
- 將任務拆解為核心判斷與批次處理，交由人與 AI 各自發揮。
結果不只是效率提升，更是工作節奏的重塑。
11_PM不加班的AI便利貼_小小指令也可加速
AI 工具帶來驚人效率，但在日常工作中，仍可用一些「傳統技巧」。例如 Google Sheet的語法，往往能以一行指令快速完成任務，而不必透過 AI 建議的冗長步驟。
這提醒我們：AI 適合處理複雜、抽象的任務，但簡單、明確的工作，靠既有的方法更能直擊要點。真正的效率來自於兩者搭配，而非單一依賴。
12_PM不加班的AI便利貼_Context Engineering
過去我們談 Prompt Engineering，像是追求「指令要寫得漂亮」。但當 AI 進入真實場景，需求變複雜，單一提示已經不足。
現在Context Engineering 成為關鍵，Context 是系統而非字串。它包含長期記憶、專案文件、檢索結果、工具回覆、結構化輸出，這些共同影響模型能否產生有用的答案。LangChain 的方法論甚至將它拆解為四步：寫入、選擇、壓縮、隔離。
Prompt 不會消失，但已融入更大的 Context 設計，讓 AI 工具走向專業生產力的必經之路。
13_PM不加班的AI便利貼_提示詞用法
在內容與知識工作中，「清楚定義提示詞」正成為核心能力。模板只能提供框架，真正提升品質的是：明確列出需要的寫作要素與可觀察的行為，並讓模型理解任務邊界。
實務上可分兩層：
— 基本5個項目：角色與任務、動態資料、詳細規則、範例、重點複誦。
— 擴充10個項目：加入語調、背景知識、對話歷史、當前請求、逐步思考提示、輸出格式，必要時用預填回應（限 Claude）。
把這些元素嵌入 Context Engineering 流程，便能系統性地降低隨機性、提升一致性與可維護性。建議從既有流程挑一個高頻任務，先寫基本項目，再視需求複雜度遞增至10項，衡量成本與收益，逐步擴散。
14_PM不加班的AI便利貼_AI助理群_Business Analyst (BA)
在優化流程時，我會將每個節點角色化。這意味著每個階段不僅是步驟拆解，而是角色轉換：思維方式與行動準則都隨之切換。長期下來，任務的速度與精準度都能顯著提升。
以產品開發為例：第一步不該是馬上打開 Confluence 寫規格，而是扮演「商業分析師」。這個角色的重點在於：將模糊的點子理清，辨識風險，轉化為可行的業務模式，甚至利用大型語言模型進行驗證。
15_PM不加班的AI便利貼_AI助理群_數位產品顧問Product Manager (PM)
從想法到落地，產品經理的價值在於「拆解」。
一個點子初步成形後，不能只停留在構想階段，而需要進入更務實的規劃：
- 做市場分析，理解競爭格局
- 撰寫符合目標的 PRD
- 切分任務，挑出最小可行產品（MVP）
Roadmap 並不是一開始就完全固定，而是伴隨驗證與學習持續調整。這也是專案經理與產品經理在產品開發初期最重要的工作之一。
16_PM不加班的AI便利貼_AI助理群_Architect (Arch)產品架構手
再拿到PRD和Roadmap後，接下來就可以跟Arch架構師討論，把 BA 的想法、PM 的 PRD，轉換成具體的架構文件(Architecture Document)。
這份文件包含：
- 技術選型（程式語言、程式庫、框架）
- 系統架構（Web App、前後端設計、流程過渡transitions）
- 安全性(Security)與基礎設施(infrastructure)
- 部署方式(Deployment)
- 資料庫設計（schemas、data models）
這階段確定的是：要用什麼工具，怎麼蓋這棟「大樓」。
17_PM不加班的AI便利貼_AI助理群_需求與工程之間的翻譯機-PO(Product Owner)
常聽人問：「PO（Product Owner）不就是寫需求、排排進度表的人嗎？」
但實際上的 PO，更像一台翻譯機，把「看似完整」的功能設計，拆成團隊能逐步完成的任務。
例如：從「設計登入頁面」到「建立 API」、「驗證流程」、「錯誤訊息」，每一步都要拆得夠細，才能真正執行。
所以，PO 不是單靠一項技能，而是靠一整套能力：
- 分析與拆解力
- 表達與文件力
- 資源分配敏感度
- 領導與協作力
PO 的價值，不是寫下需求，而是讓需求真正落地。
18_PM不加班的AI便利貼_AI助理群_Scrum Master開發指揮官
在敏捷開發流程中，PM 丟出 PRD、PO 完成需求拆解後，Scrum Master 的角色往往被誤解為「任務分派」。事實上，Scrum Master 更重要的任務是「建構專案地圖」。
這份地圖包含從 Epics 到 Stories 的拆解，但重點在於：
- 文件可存取性：資訊必須能被快速找到，避免團隊浪費時間。
- 專案結構：確立共同的討論基準，確保團隊溝通一致。
- 上下文脈絡：讓開發人員理解「為什麼做」，而不只是「做什麼」。
當任務承載背景與方向，團隊能更清晰地定位自己在產品全局中的價值。這是 Scrum Master 讓敏捷真正落地的關鍵。
以上，是這一期的電子報內容，持續還有半個月，持續日更增加中，下期電子報再彙整給各位參考！～