我做產品的方式是先確認那個問題是真的,再決定哪些東西不要做。20 幾個產品裡,有的有真實用戶,有的我自己每天在用,也有幾個我後來把功能砍掉。下面每一個都寫了當時的判斷過程。 The way I build is to first check the problem is real, then decide what not to build. Of the 20+ products below, some have real users, some I use myself every day, and a few I later cut features from. Each one records the judgement I made at the time.
生醫工程背景,具備 AI 產品運營與數據驅動決策思維。從教育科技到心理健康,從 B2B SaaS 到 AI 原生應用,用產品解決真實問題。 Biomedical engineering foundation, with GCP certification (ICH E6(R2)). I combine clinical and lab methodology with product discovery to identify real problems, define requirements, and deliver working AI solutions.
我認為好的 AI PM 不只是「提需求的人」,而是要能深入理解技術邊界、設計可行的 AI 交互流程、並用數據驗證假設。A great AI PM isn't just someone who files requirements. They understand technical constraints, design usable AI interactions, and validate assumptions with data.
在炫圖 AI 實習期間,我定義北美市場短視頻內容策略,分析 TikTok/Instagram/YouTube 用戶行為模式,建立可量化的每日內容決策框架。During my internship at Xuantu AI, I drove international user acquisition through short-form video, producing ~20 TikToks and Instagram Reels monthly and building tracking systems that grew overseas reach to 5,000+ per week.
自己開發了 20 幾個產品,從 Flutter 到 FastAPI 到 Next.js,技術棧橫跨 Mobile、Web、Backend,多數已部署上線。這讓我能和工程師用同一種語言溝通。I've built 20+ products on my own across Flutter, FastAPI, Next.js, and React, most of them deployed and publicly accessible. That hands-on fluency lets me speak the same language as engineers.
每一個都是從我自己遇到的問題開始。下面寫的是那個問題是什麼、我做了什麼取捨,以及我怎麼知道有沒有用。 Every one of these started from a problem I ran into myself. What follows is the problem, the trade-off I made, and how I know whether it worked.
問題:每個人都幻想過自己是自己故事裡的主角,但真的要寫,常常想一想小說就胎死腹中了。難的不是想像,是把它變成一段讀得下去的文字。
取捨:不要求使用者會寫小說,只要求寫日記。日記本來就是很多人已經在做的事,門檻低到不需要建立新習慣,AI 再把累積的日記串成有情節的故事。使用者選風格和角色,但故事骨架來自他自己真實寫下的東西,這樣讀起來才是自己的人生。Problem: Everyone has imagined themselves as the protagonist of their own story, but the moment you try to write it the novel dies in your head. The hard part isn't the imagining, it's turning it into prose someone would read.
Trade-off: It doesn't ask you to write fiction, only to keep a diary. Journaling is something many people already do, so there's no new habit to build, and the AI weaves the accumulated entries into a plot. You pick the genre and the characters, but the skeleton comes from what you actually wrote, which is what makes it read like your life rather than a generated story.
問題:我們常常知道自己想做一件事,但就是不知道從哪裡開始,於是那件事一直放著。卡住的不是動力,是第一步太模糊。
取捨:市面上的工具是你丟一段模糊的話,它回一份很有自信的清單。但輸入本來就模糊,直接生成只會得到一份自信的錯答案,而且你不會照做。所以我讓它先反問,問夠了才拆,直到第一步變成今天就能動手的東西。
驗證:我自己拿它管開發排程,用到現在。會繼續用是因為它產出的東西我真的會照做。Problem: You often know what you want to do but not where to start, so it sits there. The blocker isn't motivation, it's that the first step is too vague to begin.
Trade-off: Most AI task tools take a vague brain-dump and hand back a confident list. The input was vague, so the output is a confident wrong answer you won't follow. Mine asks clarifying questions first and only generates once the first step is something you could start today.
How I know it works: I use it to plan my own build schedule and still do, because I actually follow what it produces.
問題:劇本殺很好玩,但每次都要湊人、喬時間、找場地。想玩的當下通常玩不到,等到大家有空,那個興致已經過了。看小說也一樣,結局爛了你只能吐槽。
取捨:讓大模型即時扮演所有嫌疑人,一個人隨時可以開一局,選擇不同結局就不同。但模型會憑空編造證據,把遊戲玩壞。我沒有靠事後過濾,而是給每個角色一份自己的設定:他是誰、知道什麼、要隱瞞什麼。約束寫在前面,比事後補救可靠。
驗證:回覆一直被截斷,最省事的解法是加錢提高輸出上限。我改去翻日誌,找到是模型內部的推理預算在吃掉輸出配額,關掉之後回覆完整、更快,零額外成本。Problem: Murder mystery games need a group, a shared calendar slot, and a place to sit, so you can never play when you actually want to. Reading a mystery has the same catch: if the ending is bad, all you can do is complain about it.
Trade-off: An LLM plays every suspect, so one person can start any time and different choices lead to different endings. But the model invented evidence, which breaks the game. Instead of filtering afterwards I gave each character its own brief: who they are, what they know, what they're hiding. Constraints up front beat cleanup after.
How I know it works: Replies kept getting truncated. The easy fix was paying for a bigger output limit. I read the logs instead, found a hidden reasoning budget eating the output, and switched it off. Complete replies, faster, at zero extra cost.
問題:一群人要約見面,最後都是約車站。不是因為那裡最公平,是因為沒有人想花力氣算,於是預設值就贏了。實際上總有人默默多花四十分鐘,而且不會抱怨。
取捨:用每個人的實際通勤時間去算最公平的地點,而不是地圖上的幾何中點,因為不公平的是時間不是距離。結果只給到行政區層級,不讓任何人的出發地被反推出來。
驗證:做到一半發現付費地圖 API 一超額整個功能就會掛,所以加了自動切換免費 OpenStreetMap 的備援。額度用完之後它仍然正常運作,長期零成本在線。這個備援不是加分功能,是它還活著的原因。Problem: When a group meets halfway, everyone ends up at the central station. Not because it's fairest, but because nobody wants to do the maths, so the default wins. Someone always quietly spends forty minutes more and never complains.
Trade-off: I compute the fairest point from each person's actual travel time rather than the geometric midpoint, because the unfairness is in time, not distance. Results stop at district level so nobody's starting address can be inferred.
How I know it works: Midway through I realised that when the paid maps API hits its quota the whole feature dies, so I added automatic fallback to free OpenStreetMap. It kept running after the quota ran out and has been online at zero cost since. The fallback isn't a nice-to-have, it's why the thing is still alive.
問題:兩件事。一是去過的店隔一陣子就忘了哪道菜好吃、哪道不要再點;二是選擇困難,光是想吃什麼就可以想很久,最後往往是餓到隨便吃。
取捨:記錄做到「單道菜」而不是「單間店」,因為同一家店有雷有寶,給整間店打一個分數等於沒記。另外放了一個直接幫你抽一家的按鈕,因為選擇困難的人要的不是更多選項,是有人幫他結束這個選擇。
驗證:我自己在用,而且用最多的功能是隨機那顆按鈕,不是評分。Problem: Two things. You forget which dish at a place was good and which one never to order again. And you can spend a long time just deciding where to eat, usually ending up somewhere random once you're too hungry to care.
Trade-off: Ratings attach to individual dishes rather than restaurants, because one place has both hits and misses and a single score for the whole venue records nothing useful. I also added a button that simply picks for you, because someone with decision paralysis doesn't need more options, they need someone to end the decision.
How I know it works: I use it myself, and the feature I use most is the random button, not the ratings.
有些人想每天進步一點,但不想要壓力。市面上的自我成長工具都建立在連續紀錄和進度條上,一旦斷了那天你就不想再打開了。所以這個刻意不做帳號、不做連續天數、不做任何進度追蹤,每天就是一則短內容,看了就走。沒有東西可以斷,就不會有放棄這件事。
註:原本的內容來源後端已下線,Demo 目前使用內建示範資料組,功能流程完整可操作。Some people want to get a little better each day without the pressure that usually comes with it. Self-improvement tools are built on streaks and progress bars, and the day you break one is the day you stop opening the app. So this one deliberately has no account, no streak, and no progress tracking: one short piece of content a day, read it and leave. Nothing can break, so there is nothing to give up on.
Note: the original content backend is offline, so the demo now runs on a built-in sample data set. The full flow is still operable.
問題:我同時帶 20 幾個學生,每個人卡的地方都不一樣。有人是計算粗心,有人是根本沒讀懂題目,但我能給的練習題是同一份。真正該做的是針對每個人的弱項出題,一個人手動做不到 20 份。
取捨:讓學生把答錯的題目丟進來,AI 判斷弱點在哪,再生成針對性的練習;老師端看得到每個人的進度和退步的科目。做成 LINE Bot 而不是 App,因為學生本來就在 LINE 上,多下載一個 App 就沒人用了。Problem: I tutor 20-odd students at once and every one of them is stuck somewhere different. One makes careless arithmetic errors, another never understood the question. But the practice set I can hand out is the same for all of them, and building 20 targeted sets by hand isn't possible.
Trade-off: Students submit the questions they got wrong, the AI works out where the weakness is, and generates practice aimed at it. Teachers see each student's progress and which subjects are slipping. I built it as a LINE bot rather than an app, because the students are already on LINE and one more download means nobody uses it.
問題:歷史課都是分開講的,中國史一條線、西洋史一條線。但這些人其實活在同一個時間軸上,有些甚至互相認識。你讀完會知道很多人名,卻不知道他們怎麼串在一起。
取捨:輸入兩個歷史人物,找出他們之間最短的關聯路徑,像六度分隔那樣。重點不是給你正確答案,是讓你看到原本以為毫無關係的兩個人中間隔著誰。Problem: History is taught in separate lanes: one for China, one for the West. But these people lived on the same timeline and some of them knew each other. You finish the course knowing a lot of names and no idea how they connect.
Trade-off: Enter two historical figures and it finds the shortest chain between them, six-degrees style. The point isn't to hand you a correct answer, it's to show you who stands between two people you assumed had nothing to do with each other.
問題:記帳軟體不缺功能,缺的是讓人願意每天打開的理由。多數人不是不會記帳,是記了三天就停了,因為過程一點都不有趣,也看不到即時回饋。
取捨:把每月預算做成血條,每一筆消費是一次受擊,再加一個 AI 同伴當場給反應。真正讓人持續的是這套比喻,不是那串數字。我也刻意控制回饋強度,因為提醒一旦變成罪惡感,人只會不想打開,那就徹底失去意義。
驗證:已上線可直接試用。我用它看自己的花費,血條掉太快的那幾天,我確實會停下來想一下。Problem: Budgeting apps don't lack features, they lack a reason to open them tomorrow. Most people can track spending fine, they just stop after three days because the process is joyless and the feedback is invisible.
Trade-off: I turned the monthly budget into an HP bar, made every purchase a hit, and added an AI companion that reacts on the spot. What keeps people coming back is the metaphor, not the figure. I kept the feedback gentle on purpose, because once a reminder feels like guilt people stop opening the app, and then it does nothing at all.
How I know it works: It's live and public. I use it on my own spending, and on the days the bar drops fast I do stop and think.
問題:B-Battle 是網頁版,我想知道同一個產品用 Flutter 重做一次會遇到什麼。這個純粹是我想練跨平台開發。
取捨:功能刻意做得跟網頁版一樣,不加新東西,這樣比較的才是框架本身而不是產品。
結論:原生手機體驗確實好很多,但開發速度慢下來的幅度超過我預期。Problem: B-Battle is a web app and I wanted to know what rebuilding the same product in Flutter would actually cost. This one is purely me practising cross-platform development.
Trade-off: I kept the feature set identical to the web version and added nothing new, so what I was comparing was the framework rather than the product.
What I concluded: The native mobile experience is meaningfully better, but the slowdown in development speed was larger than I expected.
問題:每天做一樣的事,腦袋會越來越僵。而且身體的緊繃自己通常不會發現,肩膀已經硬了一整天都沒感覺。
取捨:每天抽一個身體覺察的小挑戰,不重複、不累積、不用連續。設計成抽的而不是排的,因為固定順序做兩天就變成例行公事,那就失去讓腦袋轉個方向的意義了。Problem: Doing the same things every day makes your thinking rigid. Physical tension is even easier to miss: your shoulders can be locked up all day without you noticing.
Trade-off: One body-awareness challenge a day, drawn at random, never repeated, with no streak to maintain. Drawing rather than scheduling was the decision: a fixed order becomes routine within two days, and routine is exactly what this was meant to interrupt.
問題:讀紅樓夢的時候會想,如果我活在那個時代、那個身分,我撐得下去嗎。這個好奇心很難靠讀書滿足,因為書裡的人生不是你的選擇。
取捨:選一個時代和身分,用文字 RPG 活一遍,每個選擇都影響數值,活不下去就結束。用大模型生成事件而不是寫死劇本,因為固定劇本玩第二次就知道答案了。Problem: Reading a classical novel, you start wondering whether you would have survived that era in that social position. Reading can't answer it, because the life on the page isn't yours to choose.
Trade-off: Pick an era and a role and live through it as a text RPG, where every choice moves your stats and running out ends the run. Events are generated by an LLM rather than scripted, because a fixed script means you already know the answers on your second playthrough.
問題:上班想喘口氣,但螢幕隨時可能被看到。用手機太明顯,開網頁又怕被瞄到。
取捨:做成 PWA,可以偽裝成一般工作頁面,聊天內容加密,一鍵切換回「正在工作」的畫面。這個東西的價值全在被看到的那一秒,所以偽裝速度比功能豐富重要。Problem: You want a moment off at work, but your screen could be seen at any time. Reaching for your phone is obvious, and opening a browser tab risks someone glancing over.
Trade-off: A PWA that disguises itself as an ordinary work page, with encrypted chat and one-key switching back to a "currently working" screen. The entire value of this thing lives in the second you get looked at, so how fast the disguise lands matters more than how many features it has.
問題:東西越積越多,但「整理房間」這個目標大到永遠不會開始。而且真正讓人停下來的不是丟不掉,是丟完之後那股說不上來的後悔,久了就不想再開始。
取捨:任務切到兩分鐘一個、依居家/辦公/外出分場景,讓人隨時都能做一件。丟完之後不是給你打勾,而是問你現在什麼感覺,再記下釋放了多少壓力。累積下來你會知道自己丟哪一類東西會後悔、哪一類丟完是鬆一口氣,下次就有依據。
取捨之二:進度做成一片慢慢長出來的森林,不是待辦清單的完成率。清單會讓人覺得自己還差多少,森林讓人看到自己已經清掉多少。Problem: Clutter accumulates, but "tidy the whole room" is too big a goal to ever start. And what actually stops people isn't the letting go, it's the vague regret afterwards, which over time makes you avoid starting at all.
Trade-off: Tasks are cut down to two minutes each and split by setting (home / office / out), so there is always one you can do right now. Finishing one doesn't give you a checkmark, it asks how you feel and how much pressure that released. Over time you learn which categories you regret letting go of and which ones leave you lighter, so the next decision has something to stand on.
Second trade-off: Progress is a forest that slowly grows in, not a completion percentage. A checklist shows you how far you still are; the forest shows you how much you already cleared.
我每天要做的事其實固定:喝水、讀書、今天該完成什麼。但靠自己記,忙起來就全部漏掉;靠手機內建提醒又只會響一聲然後被滑掉。所以我把這些做成排程,準時推到我每天本來就在看的 Telegram,不用另外開任何 app。提醒我控制在一天幾則,因為推太多的下場一定是靜音,靜音之後這個系統就等於不存在。The things I need to do each day are fairly fixed: drink water, study, whatever today's task is. Remembering them myself means dropping all of them on a busy day, and a phone reminder pings once and gets swiped away. So I put them on a schedule that pushes to Telegram, which I'm already reading all day, so there's no extra app to open. I keep it to a few messages a day, because the outcome of pushing more is that it gets muted, and a muted reminder system may as well not exist.
相簿裡一半是資訊截圖:菜單、地址、螢幕畫面。它們把真正的回憶淹掉了,想刪又怕裡面有還沒抄下來的東西。所以我先用 OCR 把截圖裡的文字抽出來變成可搜尋的筆記,抽完才敢刪。資料全部存在瀏覽器本機,因為相簿是最私密的東西,上傳到別人的伺服器這件事本身就會讓人不想用。Half my camera roll is screenshots: menus, addresses, things off a screen. They bury the actual memories, and I can't delete them because some hold information I never wrote down. So I run OCR first, turn the text into searchable notes, and only then is deleting safe. Everything stays local in the browser, because a photo library is about as private as data gets, and uploading it to someone else's server is itself a reason people won't use the thing.
朋友講過想要什麼、喜歡什麼、家人生日是哪天,當下都記得,真的要送禮的時候完全想不起來。所以我做了一個只給自己看的人際筆記:每個人一份,可以丟截圖進去自動抽出興趣,要送禮的時候直接問它。我沒有做社群功能,因為這種東西一旦牽涉到別人看得到,就沒有人敢誠實記錄了。Someone mentions what they want, what they like, when their birthday is. You remember it in the moment and have nothing left when it's time to buy a gift. So I built a private notebook for people: one profile each, drop in a screenshot and it pulls out the interests, ask it when you need a gift. I deliberately built no social layer, because the moment other people can see these notes, nobody records anything honest.
問題:同一張命盤在不同系統下講的東西不一樣,八字一套、占星一套、人類圖又是另一套。網路上的工具一次只給一種說法,每換一個系統就要重填一次生日時辰,沒有人有耐心做完,也就沒辦法對照著看。
取捨:把五個系統放在同一個輸入之下,填一次,五種一起出。星曆走真實天文計算而不是查表,因為只要時辰算錯,五個系統會一起錯。
驗證:已上線,有真實用戶在用,回饋是「準」。這是我唯一一個不用我推、別人自己會回來用的作品。
註:後端跑在免費方案,閒置後首次開啟需等伺服器喚醒約 30 秒。Problem: The same birth chart says different things in different systems. Online tools give you one system at a time and make you re-enter your birth date and hour for each, so nobody finishes, and nobody ever reads them side by side.
Trade-off: I put all five systems behind a single input: fill it once, get five readings. The ephemeris is computed from real astronomy rather than lookup tables, because if the birth hour is off, all five are wrong together.
How I know it works: It's live with real users and the feedback is that the readings land. It's the one project people come back to without me promoting it.
Note: the backend runs on a free tier, so the first load after idle takes about 30 seconds to wake.
旅行完照片一堆,但遊記永遠沒寫,過兩年細節就全忘了。卡住的不是懶,是打開空白頁不知道從哪裡開始寫。所以我讓行程、照片、地圖軌跡先自動排成一份有版型的東西,你只要補文字,最後一鍵匯出 PDF。做成可以印出來是刻意的,因為存在雲端的遊記跟沒寫過差不多。After a trip you have hundreds of photos and never write the journal, and two years later the details are gone. The blocker isn't laziness, it's a blank page with no obvious starting point. So the itinerary, photos and map track lay themselves out first and you only fill in the words, then export to PDF in one click. Making it printable was deliberate: a travel journal that lives in the cloud is barely different from one you never wrote.
一句話:用 nearest neighbor 加 2-opt 算最短的景點順序,介面是刻意做成「特種兵旅遊」的軍事風格。
問題:我排行程的方式是先列一堆想去的點,然後卡在「今天先去哪」。人腦排順序排到五、六個點就開始亂,排出來的路線常常在同一區來回繞,走的路比實際需要的多。
取捨:把它當成旅行推銷員問題來解,直接算出最短路線並畫在地圖上。我沒有做行程建議或景點推薦,因為想去哪是使用者自己的事,這個工具只負責解決「順序」這一件他算不動的事。In one line: computes the shortest visiting order with nearest neighbour plus 2-opt. The military styling is a deliberate "special forces travel" theme.
Problem: I plan trips by listing everywhere I want to go and then getting stuck on where to start. Ordering more than five or six stops in your head falls apart quickly, and the route you come up with usually doubles back through the same area and walks further than it needs to.
Trade-off: I treated it as a travelling salesman problem, computed the shortest route and drew it on the map. I deliberately didn't add itinerary suggestions or attraction recommendations, because where you want to go is yours to decide. The tool solves only the ordering, which is the part a person can't do in their head.
問題:家事的問題從來不是誰不做,是沒有人想當那個一直開口提醒的人。誰記得誰就得說,說久了在家人聽起來就變成抱怨,於是大家乾脆都不講。
取捨:讓機器人來當那個開口的角色,家事變成點數、購物清單放在群組裡大家都看得到,提醒由它發不由人發。改成明確指令而不是自然語言對話,因為家人不會為了一個機器人學怎麼跟它聊天,指令醜一點但真的會被用。
驗證:已部署,有真實家庭在用。Problem: Chores are never really about who won't do them, they're about nobody wanting to be the person who keeps bringing it up. Whoever remembers has to say it, and said often enough it sounds like nagging to your own family, so everyone stops mentioning it.
Trade-off: The bot becomes the one that brings it up. Chores turn into points, the shopping list lives where everyone can see it, and reminders come from the bot rather than from a person. I went with explicit commands over natural-language chat, because family members won't learn how to converse with a bot; commands look uglier and actually get used.
How I know it works: Deployed and in use by a real family.
正在尋找產品相關職缺,歡迎聯繫。 I'm open to AI Product Manager roles — let's connect.
台北 · 可遠距、開放搬遷 Taipei · open to relocation and remote
vernessa0607@gmail.com