Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
AI Coding的時代已經來臨，目前市面上有許多AI Coding的工具，大約從一年半前開始陸續浮現，而這一年則是快速發展，從IDE到IDE Extension/Plug in，到捨棄IDE直接在Browser使用Prompt Coding，各種方式都存在。
To read the English version, click the “ENGLISH” button at the top-right menu.
可以閱讀兩分鐘AI產生的語音，快速了解綱要與結論介紹。
對於Engineer來說一定是大幅的改變與新的工作型態建立，但對於產品經理、產品開發設計來說產生什麼變化呢？許多人認為有了一些新興的AI Coding Tool特別是捨棄IDE方式的，像是Lovable、Replit和Base 44 的出現，會甚至讓產品設計直接銜接到程式開發可以取代一些工程師，這會是真的嗎？或是產品經理真的能夠直接透過AI Coding產出產品的Code層面基礎而提交給下一階段工程銜接開發嗎？是產品經理會消失還是工程師會消失？
先前我們已經測試使用過Lovable、Base 44這類產品進行MVP，這次我們使用Gemini CLI完成一個side project，並從中得到一些想法、Insight。
1. AI Coding 時代來臨，各種工具
這一年半已經迎來爆炸式的AI Coding工具發展，從使用的定位或適合的情境去分類，我們可以嘗試分類以下幾種：
1. 既有 IDE AI Extension 或 Assistant — CodePilot, Google Code Assist ..
2. 通用型 AI 助理（可高度彈性整合既有IDE） — Claude code, Gemini CLI ..
3. 新一代 AI IDE — Cursor, Windsurf ..
4 .新一代 Vibe Coding產品(特別是捨棄專用IDE，基於Browser為介面的) — Lovable,Replit and Base44 ..
以上第1種，大部分工程師經歷過、使用過，第2種整合既有IDE就會如同第3種的效果，第4種我們稍早也體驗過(Lovable、Replit)
最近熱度最高的，就屬於 第2種與第4種，第2種不只在編程上高度合作，甚至可以超越編程，形成全方面的個人助理(multi agent, agent team..)。第4種則是消滅了IDE的Effort試圖為非工程以外的人提供更好的製作產品的手段。
2. 既有產品開發設計的工作流程被淘汰？
許多人討論新一代的產品開發流程有什麼變化？這裡我們探討以「產品經理」的角度，AI Coding的加入是否改變我們做產品開發、設計的工作流程？未來的工作流可能會是什麼樣子？是工程師被消滅或是產品經理被消滅？(AI真是讓人你死我活😔)
– 產品經理的職責與工作流程有什麼？
首先我們要知道，既有產品開發設計的工作，攤開全部來看可能有什麼。產品經理面對的工作並非只是開規格給工程師，或只是引導完成0–1的產品、功能開發，也並非任何功能的開發都是可視化的互動功能而已，以下職責或需求都是需要產品經理進行相關工作：
- 0–1的快速MVP設計
- 功能設計：聚焦UI/UX層面的(較專注在畫面上的設計與互動)
- 功能設計：非UI/UX層面(可能更多功能性、安全性、架構上的需求，例如API設計、WebHook設計、元件設計、系統之間交互作用整合)
- 性能、架構設計：可能是非功能性的調整(例如效能、安全性、結構處理)
- Legacy的開發(翻新或維護持續開發)
- 既有產品、專案的持續迭代變更(非AI Coding從頭發展的產品)
- …
以上還是比較關聯於程式開發的，而產品經理面臨的工作並非都100%關聯於程式開發，產品經理的工作還包含許多廣義的產品相關工作準備、研究與調查或是服務客戶：
- 新idea的brainstorming (新的功能、新的產品路線、新的活動..)
- 產品路線圖規劃
- 圖像上的優化、演進與更多提案 (平面、圖像、動態、品牌等優化提案)
- 競爭者調查(Competitor Survey)
- 市場調查(Market Survey)
- 需求訪談、使用者訪談(User Interview)
- 規格、需求文件撰寫、準備、整理(PRD、Spec Documentaion)
- 使用者操作文件撰寫、準備、整理(User Manual Documentaion)
- 使用者意見、回報處理(User Feedback Handling)
- 產品線上監督(Metrics Monitoring)
- 使用者案例研究(Case Study)
- 相關人的協調與管理(Stakeholder Management)
- 風險管理與識別(Risk Mangement)
- 營運管理(Operation management)
- 成長管理(Growth Management)
- …
– 產品經理的工作可能進化、整合，但不會消失
產品經理的職責不只這些，但已經可以看到有這麼多，那也代表整個產品開發設計與管理可能牽涉更多的工作，這些可以全部被另一個非產品經理的人只使用AI Tool就取代嗎？或是這些可以因為AI Tool的出現就不需要產品經理了嗎？可能不會。
那產品經理會取代工程師嗎？
| 大部分工作不會被消失，只會被效率化或整併
| AI時代，如果有取代你的人，大多數其實是拿著效率工具來做你的工作
3. 關於新的產品開發流程，他們在爭辯什麼？
我們假設目前的爭辯在於，藉由新一代的AI Tool來協助產品開發流程後，產品經理職位是否消失(被工程師取代)？或是反過來問工程師的職位是否削去(被產品經理取代)？
– 為什麼有這個爭辯？
我想之所以有這樣的爭辯是由於新一代的AI Tool讓本來沒有Coding能力的人具備了打造程式的能力，本來不具備產品畫面設計的人具備了直接描述產生出畫面的能力。
| AI Tool讓你擁有你原本沒有的能力，讓人們想像你能取代更多職責
| AI Tool具備廣泛的能力，讓人們想像AI Tool可以直接100%取代原本職責
爭論的人們在設想新一代的AI生產力上的產品開發流程可能是：
- 不需要產品經理，直接由工程師利用AI Tool取代了產品設計這段
- 不需要工程師，直接由產品經理生產程式碼到成品這段
– 引入AI後，實際情況可能是什麼？
以最近我們測試過的實際流程，以上情況都可能存在，但不會100%完全存在或替換現有狀況。也就是產品經理與工程師的職責可能被擴充、可能被整合，但牽涉的工作項目本身不會被消滅。
為什麼？往上檢視那些產品開發設計的工作與職責，既然工作與職責不會消失，他只會被一些角色效率填補，工程師如果來填補，實質上也只是讓工程師來做產品經理的職責。如果想用AI產出填補，試問任何一項工作你能讓AI產出而不需要人介入、調整方向或監督審查的可能嗎？既然不太可能，那很明白的就會回到「AI做的其實是效率提升而非職責取代」。
| AI時代，如果有取代你的人，大多數其實是拿著效率工具來做你的工作
| 工作本質不會被消滅，不代表工作崗位不會被減少。因為效率提升了。
4. 下一代產品發展的更實際狀況？
未來狀況會是什麼？未來可能會是：
- 藉由AI Tool的利用，任何職位的生產力都可能被大幅提升
- 無論是產品經理還是工程師，或是團隊其他角色，隨著AI產業演進，都已經出現了可以輔助工作的工具，最終就是提升效率的表現。
2. 藉由AI Tool的利用，會出現部分可跨職位的能力表現
- 受惠於AI的泛化能力發展，以及基於語言模型的基礎泛化發展出應用，很多因AI Tool跨職位能力的實現將會更容易。舉例：工程師可以下Prompt來畫UI再透過Figma MCP調度產出Figma、產品經理可以下Prompt產生Code專案、老闆可以請LLM提出商業競爭策略…
3. 產品經理與工程師的職責，多數不會消失，但可能大幅被提升效率
- 即使以上原因，更前面已經討論到產品經理與工程師的職責，基本不會消失。AI Tool的引用，本質上是「效率提升」「延伸能力的實現」，但在操控、審視把關或細膩控制上，還是需要一個理解的人才能完成最後的一步驟(我們將在後續Gemini CLI製作一個專案的範例上討論)
4. 新職位產生的可能性，在部分團隊可能出現Product Engineer，但不會全面性把工程師與產品經理都替換成Product Engineer
- 某些小型團隊有可能採用新的職位Product Engineer(AI時代的)，但其實他就是把這兩個職位的職責都集中給一個人，事實上以上職責與工作需求都不會消失，所以這種情況較有可能在小團隊或特定領域上實現，並不會全面的出現這個狀況，試想一個更極端的狀況，理論上AI Agent團隊可以製造任何角色，那是否一位CEO搭配一個AI Agent Team就可以運作原本需要100人的公司？也許不會這樣發生。
5. 職責雖然不會大量消失，但因為正介於剛引入AI的時代，又處於效率提升的階段，可能會短期1–2年，相關崗位的數量會持萎縮或持平狀況，直到大家習慣了這個效率工具。
- 顯然的產品開發、設計工作流程的未來，更像是混合各種AI Tool的情況進行效率提升，但依然進行現有的大部分工作項目。而效率工具的引進會讓各團隊體會到效率提升的效果，這也會使得公司在人員上可以保持不擴張甚至縮編，直到幾乎整個產業都效率化了。
- 畢竟10個人中1個人有錢，是有錢，但10個人中9個人有錢，就只是普通而已。回到剛剛說1人CEO領導100人公司的例子，有可能短時間發生原本100人公司減少為60人，之後再擴張。
5. AI Coding+Product Development：建置實例
上面我們已經先講述了結論，關於產品發展與產品經理的變化可能。現在我們回到 AI Coding+Product Development實際效用與問題，這一次我們使用了Gemini CLI與我們一起完成一個Side Project。透過完整的過程，從開始到開發，從開發到實際運作，有哪些優缺點被我們識別出來，以及從這裡看到可能的未來工作模式。
*另一個AI Coding的心得(使用Lovable)可以參考這篇：
AI Coding an MVP in 1 Day (with Lovable)
以下展示測試了完整使用VS Code+Gemini CLI與我一起完成一個Side Project的過程，遇到哪些狀況以及觀察。
– 需求背景：建個人專心日誌系統，支援各種統計
我自己有紀錄每日工作筆記的習慣，平常是使用AnyType跨手機與電腦共用一份編輯，純文字的方式記錄每天專心努力時間的項目，原本是自己肉眼檢視或偶爾心算計算加總時間來理解自己每天的安排是否需要調整或提醒自己更專心，於是在這個AnyType文字紀錄基礎上，我想建立更適用的統計分析紀錄平台。
– 需求規格建立(1h)：討論後由LLM Gemini建立
採用了Text Spec Driven 方式進行，先與Gemini CLI互動討論幾次後產生了「需求規格書.md」
– 雛形建立(0.5h)：依「需求規格書.md」建Code
請Gemini CLI直接依據「需求規格書.md」建構對應專案，這邊我指定使用React+NodeJS。大約1–2次Prompt後就具備合理雛形，符合需求規格書中提到的功能、版面合理性以及可執行，非常的陽春，但是合理。
– 視覺、功能、Debug、Code架構調整(10h)：
完成後的版本在Layout、UI/UX、使用者操作模式上都有一些不滿意，過程中進行反覆多次進行Prompt調整，無論使用中文、英文大部分都可以按照語意進行修改（大約每天花一點零碎時間進行）。這其中也有Gemini CLI自己造成的Bug，要協助他Debug（後面與大家列舉分享）。也有部分修改是我嘗試結構化的異動（與功能性無關）。
– 專案完成(總計12h)：總花費時間累積12 hours
最後完成後，根據自己這個小產品的專心日誌紀錄與統計功能，順手查看自己的工作時間成本 (我在這類工作的紀錄習慣類似為 “2230 — 生產/Producing — 寫程式/Coding — gemini — 0030”)
– 專案成果：各功能演示 (.gif)
6. AI Coding+Product Development：實際問題
– 幻覺1：這已經是完成產品經理的全部工作
雖然我們在短時間完成建構了一個工具，因為這個專案很小，檢視一下其中的工作內容，事實上只涉及了產品經理工作內的部分。當每次我們看到別人展示Vibe Coding的驚人效果的時候，你是否思考過這其實只是在規格確認後的執行階段（或是一邊做一邊產出規格）？事實上較大的產品公司還有很多產品工作要進行。
– 幻覺2：這已經是完成工程師的全部工作
相同的狀況也出現在你以為你能取代工程師的工作上，的確AI Coding加速生產Program的階段，但是工程師的處理範圍還包含很多你看不到的基礎部分，包含架構、效能、安全性、整合…你的確透過AI Coding加速完成了一部分，但那不是全部。
– 狀況1：AI Tool可能失敗，導致一團混亂
可能因為Token限制、費用狀況、網路狀況，或AI本身無法處理陷入Loop，都可能導致進行到一半的變更，停留許多檔案修改到一半且未完成的狀況，這個情況下你可能可以接續請他fix，但也可能一團亂必須人為收拾或協助。
– 狀況2：AI 不是萬能，簡易問題卻在處理範圍外
這裡顯現一個多餘字元導致語法錯誤，但一個肉眼可見的錯誤卻剛好在AI的處理能力外，多次請求進行修復都無理處理，最後自己去移除、對齊語法。
– 狀況3：AI 可能製造意外的垃圾
這個案例是AI製造了持續累積的comment垃圾，這個情況下不限於comment，code層面也可能有無意義的垃圾產生，偶爾需要自己巡視提醒。
– 狀況4：AI 可能語意理解錯誤，造成不預期結果
荒謬的語意理解在這個案例很好的展現，原本是想將一些元件對調位置，AI的確調整了位置，但他調整的是HTML檔案內的位置，而不是最終效果Layout上的渲染位置，最終也是透過提醒讓他修正。
– 狀況5：AI 可能語意理解錯誤，造成不預期結果
另一個荒謬的語意理解在這個案例很好的展現，原本是在基於批次新增日期的基礎下，請他新增完畢後選擇最新日期去呈現Daily Log，多次達不到效果下去看程式後發現，AI把「最新」理解為「最後」，而接而把「最後」理解為「檔案內的最後一筆」，這恰巧讓「最新」這個要求的效果被顛倒了。最終也是透過提醒讓他修正。
– 狀況6：AI 計算上的缺失可能，計算公式錯了
錯誤的計算邏輯導致錯誤的精度計算，呈現在這個案例。原本輸入的Duration格式為 xxH yym，在整日累計時間上，他選擇的方式是先將這個格式轉換為 x.xH。舉例而言0120按照他的轉換會變成1.33h，這裡就出現了精度問題，而如果選擇後者的加總，最後就會出現永遠非整數的分鐘數。如下圖可以看到 8.59h這種數據，這是屬於精度的損失而非原始數據有這種結果。最終也是透過提醒讓他修改計算邏輯。
– 狀況7：AI 的資料處理，可能不一致導致問題
如同上面提到原始數據Duration格式為 xxH yym，在資料識別上應該視為yy分鐘，但同樣的資料卻會出現部分識別正常，部分識別錯誤，把yy分鐘識別為yy小時。最終也是透過提醒讓他修改計算邏輯。無法理解的意外，相同資料卻有不同處理方式。
– 狀況8：AI 命名規則不一致，埋藏維護性問題
同樣都是存檔，AI在部分命名選擇使用「Save」，但部分命名卻另外選擇「Add」。也甚至整體命名規則也不統一的情況時常發生。
– 狀況9：AI 結構規則可能不佳，埋藏維護性問題
如下圖所看到AI不只對於結構性的安排、命名的選擇都沒有一致性，這可能累積更多的dirty legacy給後續，埋藏維護性問題。
– 狀況10：AI 的所及範圍有限時，需要人為協助
對於Gemini CLI來說我們把當下資料的權限交給了他，但是我們沒有把OS甚至特定Browser給他，所以很多時候他會需要人為協助的Debug，包含請你做一些測試與log蒐集。
– 狀況11：AI 的出錯可能，需要預防性版控
目前Gemini CLI是沒有復原功能，即使你要求他也做不到(未來是可實現的)，再考慮AI可能做出做的變更，基本上控制者要有敏感的版控意識(存擋復活大法)
– 狀況12：AI 可能變更範圍外的程式或檔案
在一些明顯的小修改要求中，可以遇到明明只是A檔案的修改，他卻連同B檔案改了，或是只要修改A功能，但是B功能也被異動了。當你把修改範圍這件事也交給AI你就要留意他不是100%正確。
7. 現在實際情況是什麼
– 那個百變的貪吃蛇遊戲
從一個貪吃蛇遊戲說起，很多人嘗試Vibe Coding可能是從一些簡單的經典遊戲開始，驚訝於AI Gen的能力與質感。但你有沒嘗試過一個指令建制同樣目標多次呢？
你會發現即使他們精美，但結果每次都不同。
有人會說這是AI的多元性，但其實這就是AI的機率遊戲，一個簡單的指令做出完整結果的概念是類似於Zero-Shot or One-Shot的道理，AI正在為妳匹配最可能的結果以及做大量的猜測(Guessing)以及填空白行為。
從各家大模型的每次Release演示中，他們也是在展示大量的Zero-Shot。
這雖然很美好，但是這個貪吃蛇是你要的樣式嗎？是你要的遊戲方式嗎？是你要的味道嗎？那可不一定。所以Zero-Shot(Or One-Shot)只是起了一個快速草稿，真正主要的工作在後面的不停調整產品到你要的功能、樣式、互動…
你也可以設想「那我把規格準備的很好」增加Zero-Shot(Or One-Shot)的準卻率，這也是可以的，但是你的實際工作時間就跑到「那我把規格準備的很好」這部分，而且也不是保證效果，很可能你準備很多的規格，產出不如1頁的規格好。
所以實際上在AI Coding的過程中，依然少不了「規格」這項工作，他可能是提前準備好的，也可能是過程中一道道Prompt去刻畫的慢慢形成規格。在你要做什麼產品前，依然需要目標、依然需要規格。
所以產品經理與工程師的工作誰也沒有消失，但的確是AI有幫助效率提升。
– AI Coding 能做什麼？
- 他能作為一種快速生產力工具(越來越多人能做自己的工具協助自己)
- 他能作為一種快速 prototype工具，讓你快速看到成果的想像
- 他能作為一種加速Coding工具，加速日常繁雜的修改或基礎工程事務
- 他能作為一種Peer Partner協作工具，不只幫你編程，也陪你思考
– AI Coding 不能做什麼？
- 不能僅幾個Prompt你的產品就上線了，產品還是需要經過打磨
- 不能預期完全沒有錯誤、漏洞、幻覺，你需要具備識別能力
- 不能預期產品經理或工程師的工作不見了，其實是效率提升
– AI Coding 需要注意什麼？
- AI相關的工作流內思考「Human in loop」的需要性與程度
- 建議有基本程式知識，你才能識別狀況(否則你只是看不見風險)
- 撰寫各種生產力應用非常方便，但真正產品還距離很遠(例如底層基礎)
- 建議同時建立相關 .md 檔案：需求規格、程式結構(思考文件驅動方向)
- AI Coding有可能導致不可恢復的災難，因為你將整個範圍內專案檔案與控制權交出去，他可能做出非你預期的操作、修改、刪除
- AI Coding不一定有良好的Coding或命名結構，需要特別控制
- 建議架構分層，保護好個別程式，局部指定修改
- 不一定要讓他改，嘗試跟他討論，你來改，或是討論後你決定要不要改
結果相當有趣。我們發現當產品經理透過AI Coding工具更可能具備編程的能力。但當你期望結果越完善，實務上你越需要工程師所需的知識，最後你會逐漸成為一位具備工程師相關知識的人。
8. 下一步是什麼？
我們最終需要的是將工作需求給予效率提升或有工具能發揮作用。產品經理的工作項目還有很多，也有非常多的模型工具可以協助。持續地尋找更多方式協助各類型產品工作。
在AI Coding這一塊我認為最基本的每個產品經理都可以打造自己的效率工具，以及快速測試技術或建造Prototype。
建造Prototype方面也不局限於AI Coding，在影像生成、想像生成的年代，可以探索更多的可能性來協助這個目標，例如Google stitch、veo3、nano都有可能協助展示場景或MVP。更多的可以去嘗試快速有效產生MRD, BRD, PRD, Wireframe, Mockup, Figma等日常所需。
在AI Coding這一塊，可以探索spec-driven AI coding，如同AWS的Kiro提出的，抑或是Calude Code與Git都有對應的服務或框架。
