AI 時代，PM 競爭力正在被重新定義
近期在和 CEO Aaron 的 1-on-1 對談中，他提到一個深刻的觀點：「如何將 Customer Insights 轉化為可驗證、能卡位市場的產品原型，才是現在這個世代的競爭力。」
當 AI 大幅降低寫程式與分析資料的門檻後，執行力已逐漸成為標配，真正的競爭力在於判斷力。而在這個階段，誰能夠在還沒 fully spec 之前，就快速把市場訊號轉成可驗證的 Prototype 與 Insight，就是勝出的關鍵。因此 PM 比以往更需要具備三個能力：
- 精煉問題
- 把模糊訊號轉成結構化輸入
- 設計可以反覆驗證與累積洞察的系統
我想應該就是又快又準，同時能反覆驗證，對我來說就是個跟時間賽跑的階段。於是我開啟 VS Code，透過與 AI 協作的方式，用 Python、 Streamlit、Gemini AI 搭建一個競品監控儀表板，專門用來分析發票 App 的市場訊號，今天想跟大家分享在深度體驗後的試錯與迭代 🥲
從 GitHub 版控到本地開發
我在 VS Code 環境中構建了整個系統，再用 GitHub 進行版控，產生幾個 Insights
- 在本機運行 Streamlit 並管理 .env 或 requirements.txt 時，我意識到產品穩定性並非只在程式碼本身，而在於「環境的一致性」。有點像是產品的基礎設施，如果 staging 與 production 的規格不一，就會產生盲點。
- 使用 Github 版控的過程，我理解了迭代思維，並把每一項決策的演進過程建立在「可追蹤、可回溯、可持續演進」的基礎上。
- 撰寫 Commit 記錄的過程，其實是將複雜的 PRD（產品需求文件）拆解為迷你級任務的練習。當我能將一個複雜功能拆解成細小的開發單元時，這代表我能更精確地掌握開發進度，並在開發過程中降低整合測試的複雜度。
- 在優化 AI 分析邏輯時，頻繁重啟系統是巨大的時間浪費。透過實作 importlib.reload，我將「修改邏輯」到「看見結果」的反饋循環縮短到只需要幾秒即可完成。
導入 LLM 語義分析
為了更快速的識別用戶痛點與自身產品機會點，我整合了 Google Gemini-2.5-flash 模組，讓它自動識別用戶的「痛點」與「期待」，並將其轉化為結構化的分析報告。同時思考如何優化傳遞給 Gemini AI 的數據結構，確保在分析精準度高的前提下，減少 Token 的浪費。
具體分析面向如下：
- 用戶在抱怨什麼？
- 哪些是重複出現的痛點？
- 哪些其實是被忽略的機會？
補充：這裡我只用 2.5-flash 作為第一層模組，是因為它的核心特色是速度快、低延遲，且 token 成本低。據官方文件說明，gemini-2.5-flash 適合結構化摘要、分類、整理，最適合處理大量用戶雜訊。但當目標從「分析」轉向「產品決策」時，我會引入更強的推理模型，只用在已經被濾過的高價值輸入上！
數據落地與追蹤
將分析結果即時寫入 Google Sheets，將 AI 產出的 Insight 轉化為可追蹤的 Backlog 資料庫，達成可回看、可比較、可用來支持 Roadmap 與決策的結果。
Trial and Error：程式碼背後的產品決策
在開發這個監控 App Store 與 Google Play 評論的工具時，我面臨的挑戰遠不只是語法，更多的是技術權衡：
- 爬蟲 vs API 的穩定性：面對 App Store 並無公開官方 API 的現狀，我必須評估爬蟲邏輯的維護成本。原先也想過要使用 Low-Code 方案，然後 Make 裡 RSS 模組只讀得懂「標準格式」的欄位（如標題、描述、時間）。但 Apple 的星等
im:開頭），標準 RSS 模組會把它當作雜訊直接過濾掉，導致你看到一片空白。
- 例外處理的 UX 意義：當爬蟲遇到錯誤或數據異常時，如何透過
try-except配合st.toast提供優雅的報錯訊息，這不只是 Code，更是 PM 對用戶體驗的堅持。
- LLM 成本與效能：如上述提到，我該如何優化傳遞給 Gemini AI 的數據結構，確保在分析精準度的前提下，避免浪費我的 Token。
這次親自動手開發讓我學會的最重要一課，是理解開發者的摩擦力。當我學會使用 VS Code 調試環境、使用 Git 管理迭代、甚至優化動態重載邏輯時，我不再只是定義功能，而是能與工程團隊站在一起，從技術底層出發去優化產品的交付效能。更重要的是，有了這個儀表板，我即可快速整合所有產品的 user feedback 並且整理出我的見解，下一步就是將這些 Insights 轉化為可驗證、能卡位市場的產品原型，來展現 AI 世代的 PM 競爭力 ❤️ 我們下次再見～～～✋