Latest

挖掘痛點深度研究

挖掘痛點深度研究

1.為何「痛點挖掘」與「用戶增長」是成功的核心 在當今競爭激烈的創業環境中,卓越的產品構想只是起點。真正的挑戰在於如何系統性地降低風險,將構想轉化為用戶願意付費、並願意分享的解決方案。本文將深入剖析多位成功創業者的真實歷程,從他們無數次的嘗試、失敗與突破中,提煉出「挖掘用戶痛點」與「實現用戶增長」的核心策略與實戰路徑。 這些見解的珍貴之處在於,它們並非源於空泛理論,而是來自殘酷市場中的實戰經驗。正如 Starter Story 創辦人 Pat Walls 所強調:「產品的傳播(distribution)與關注度勝過一切。」即使擁有全世界最優秀的產品,若無人知曉,其價值也等於零。 跟隨海博賽特將引導你走上一條從發現問題到規模化增長的清晰路徑,其核心始終圍繞「風險管理」。 2.發現高價值痛點 成功點子的起源與驗證 所有成功的商業模式皆建立在一個關鍵假設之上:市場存在一個值得被解決的痛點。本章的戰略核心在於風險管理,探討創業者如何在投入大量資源前,系統性地發現並驗證這一核心假設。我們將拆解創業者們如何透過三種主要路徑來降低點子失敗的風險,並在投入資源前,以最低成本驗證其商業潛力。
YI
Day  209 :我們如何把保養品成分分析變得可用、可信、可比較

Day 209 :我們如何把保養品成分分析變得可用、可信、可比較

回顧3月剛開始打造 Ingrelens 和 cosGlint 其實已經過了 209 天,時間其實過的很快,但總是不夠用。 * 03月:產品啟動完成了前後端大部分的基礎 * 04月:完成第一次測試上線,並且開始準備分離 llm 服務 * 05月:順利完成第二次測試上線 * 06月:開始開發 cosGlint * 08月:cosGlint 封測 * 09月:cosGlint iOS / Android 都上線!https://go.cosglint.com * 10月:cosGlint 1.2 版 現在我們正全力打造下一個版本 ... cosGlint 想解決的核心痛點很單純:面對密密麻麻的成分標示,絕大多數人既無法快速理解,也難以做出判斷。除非具備專業背景或長期練習,從這些標示中要得到有用答案,幾乎不可能。 為了把複雜變簡單,我們成立了 Ingrelens,
YI
Vibe coding 你該知道的 api key 知識

Vibe coding 你該知道的 api key 知識

有人把會計費的 API key 直接放到可分享的前端,誰用了都算你的錢。當事人用 Google AI Studio 的 Build/Canvas 做了一個可分享的 App,介面上叫使用者填「自己的」key,但流程其實鎖了開發者的 key。內容被大量轉傳,短期流量爆掉,帳單也跟著爆。後來她以「Google 設計不良、計費綁 GCP」為切點開砲,社群自然吵起來。 但如果把情緒抽掉,這件事談的是工程邏輯與金流控管: * 金鑰放前端本來就不行,這是入門級資安。可見即可複製,沒有懸念。 * 要讓使用者自己付費,就用後端代理或讓他綁自己的計費來源;別拿開發者金鑰去幫人刷。 * 沒做配額、速率、硬停,任何誤用或外洩都會直擊你的信用卡。 不同供應商的計費機制,風險邊界不一樣: * OpenAI / xAI / Anthropic 偏手動儲值或核發額度;不開自動儲值就不會無限衝。 * Google
YI

OpenAI GPT5 推出後大家真的在懷念 GPT-4o ?

相信這幾天大家對於 GPT-5 最多的討論是「GPT-4o 消失了,還我 GPT-4o!」 坦白說我一開始也愣了一下。GPT-4o 雖然一路有在迭代,但效能本質上還是上一代:愛唬爛、幻覺多、討好傾向重。平常圈內多數人都是這個評價。 But…就是這個 But。 GPT-5 上線後,系統改為自動選用最適合的模型來解題,手動挑模型的選項被收束,「還我 GPT-4o」的聲浪就出來了。這才再一次提醒我:世界不是非黑即白。你覺得不行的東西,換個用途就會有人把它當寶。GPT-4o 拿來做專業工作當然吃力,但作為「聊天與陪伴」它反而長成了許多人的情感支柱。多數人懷念的不是參數,而是互動的「感覺」。而且這波不是少數人喧嘩,Sam Altman 也出面回應,表示會讓付費用戶可以切回 4o,並觀察使用情況決定支援多久。 The VergeTechCrunch 我們懷念 4o 的三件事 語氣與默契感
YI

從技術債到戰略投資

這週從 SEO、Dockerfile/Supervisor、狀態管理、Tiptap + AI 到 環境變數,每天都有新坑。與其把它們當救火,我選擇把舊債系統性轉成投資,讓產品基礎穩固。 * SEO不是小事。重新設計 JSON‑LD 和 metadata,短期流量未必動,但可預期的可見性與索引品質會提升,這是曝光的基本盤。 * 狀態管理從 useState 換到 Zustand,複雜度上升時的維護性與擴展性顯著改善。結論很直接:架構要在早期就為未來功能留接口,別在爆炸後再補強。 * Tiptap 圖片 resize 與語意優化,核心是把「操作阻力」降到最低。功能開發若只從工程視角出發,體驗會打折;流程要以使用者感受為主,技術實作跟著適配。 * 環境變數與設定抽離,為部署與擴容打通動脈。硬編碼在初期快,但規模化時成本高到不合理。 本週方向正確:問題每天冒,但底座在變厚,未來的節點會更穩。 下週重點(
YI

技術債與彈性之間:我把 LLM 微服務拆出來了

這週幾乎都在跟 LLM 微服務搏鬥:為了彈性、金鑰池、供應商切換、逃生門到 fallback 機制的完善,再到 Sentry 與 Redis 限流的整合。這些改動使用者不一定看得到,但對穩定性與後續擴充很關鍵。 本週進展 * LLM 微服務成功從 Ingrelens 主專案抽離,架構變得清晰,API 調用與 fallback 逐步穩定。 * 資料庫改用 JSONB。短期有 schema 管理的負擔,但彈性更高,能更貼近未來需求。 * 大幅清理程式碼與統一術語。捨棄舊碼雖不捨,但維護成本明顯下降。 * 錯誤監控與限流整合完成:Sentry 分環境配置讓追蹤更有信心;Redis 限流避免流量暴增時崩潰。意外的是,幾萬筆資料僅佔 100 多 MB,我卻給了 8G 記憶體,算是有餘裕。
YI

OAuth 解除綁定的取捨:那些看起來很小、其實很難的決定

OAuth 解除綁定的取捨:那些看起來很小、其實很難的決定 早上打開昨天調完的 UI,間距問題總算舒服多了。從 Clarity session 看,滑動速度降了一些,心情小小被安慰。結果沒高興多久,Google OAuth 解除綁定流程又跳出來提醒我:直覺跟安全,要怎麼一起兼顧? 一開始以為不難:按個按鈕、呼叫 API、revoke token,收工。真的動手後才發現,OAuth 的麻煩全在細節。曾經寫了 revoke Google token 的邏輯,想說乾淨一點,避免用戶下次登入被多問授權。仔細想想其實沒必要 access token 本來就會過期,主動撤銷意義不大,還平白增加 API 呼叫與錯誤處理。最後我把這段整個拔掉,回到「只更新本地綁定狀態」的做法;流程更直覺,延遲也少了。
YI

SEO 跟使用者體驗的拔河

昨天猶豫了半天要不要接 Microsoft Clarity,今天早上看了幾段 session 錄影,心裡總算鬆一口氣——問題一目了然:搜尋輸入體驗太糟。輸入法組字的時機一錯,搜尋建議就瘋狂跳,整段流程像在考驗用戶耐心。 第一件事,我把搜尋輸入的 debounce 重寫:組字期間不觸發建議,等用戶完成再一次更新。順手加了清除按鈕,免得大家一直狂按退格。這些瑣碎的小事做完,我自己測起來順很多,心裡稍微安定。 真正麻煩的是 SEO。Next.js 升級到 App Router 之後,目錄結構整個換掉,原本的 Tailwind 設定和 SEO metadata 也得跟著改。我不愛花時間在看不見的細節,但 SEO 偏偏是曝光的基礎。於是我花了兩個小時,重整 Tailwind config,並把 metadataBase 交給 DefaultSEO
YI

把專案清乾淨,讓產品走得動

今天把幾件拖很久的事一次處理掉,專案也順了不少。 先把不用的 sitemap.ts 和相關邏輯清掉。本來以為是單純刪檔,結果測試掛了——有個測試竟然跟 sitemap 的生成耦在一起。把測試拆乾淨、舊案例順手整理後,CI 回到綠燈。像清掉房間的舊雜物,空出腦袋。 真正影響使用者的是條碼掃描。我當初只管「先跑起來」,沒考慮糊圖、掃不出或想手動輸入。後台回報顯示不少人卡在掃描直接棄坑。下午把掃描邏輯重構,加圖片上傳與手動輸入的備案,API 回應改成 ‎`{ barcodeExists: boolean, productId?: string }`,前端判斷更穩。猶豫了一下「會不會太複雜」,但看著用戶回饋,只能說:給選擇,才不會卡住。 順著把 FAQ 和 About Us 也更新。FAQ 去掉過度技術的描述,用白話把重點講清;About Us 調整產品展望,
YI

軟刪除這件小事,背後的細節卻不小

軟刪除這件小事,背後的細節卻不小 原本只想補一個產品刪除 API。硬刪除直覺又乾脆,但總會有人手滑、客服就會來敲門。最後還是加了 deletedAt 欄位,用軟刪除留個回頭路。 一做下去才發現沒那麼單純:所有產品查詢都要顧到「未刪除」的狀態,沒有 WHERE deletedAt IS NULL 就會漏風。服務層邏輯跟 API 文件也都得跟著調,免得前端看到回傳數量不對又一臉問號。 刪除做完,回頭補分類查詢。前一晚還在想:「分類過濾真的有人用嗎?」如果首頁只放「最近分析的產品」,確實沒什麼意思。乾脆把首頁改成分類區塊,產品頁也補上分類過濾。React 端只是狀態篩選,沒太多問題;後端就麻煩了。 一開始用判斷 categoryId 的單層過濾,寫到一半才想到還有子分類。只好改成遞迴,把子分類的產品一併撈進來,測試也補齊,避免邊界情境漏掉。 今天接前端馬上踩坑:原本只有一層下拉,後端已經支援子分類,前端卻還是平面結構。
YI

為體驗與準確性重構一切

圖片輪播的坑,比我想的深得多。昨天把 .gitignore 的怪事整理完,今天回到產品開發,把待辦清單裡的圖片輪播放進度。原本估半小時的小元件,結果一做就發現邊界狀況一堆。 先是圖片 URL 的檢查,避免破圖。寫到載入狀態才真正頭痛——使用者網路慢,圖片還沒載好,輪播就先動,那體驗直接崩。我改成所有圖片載完再開始輪播,空檔用 placeholder 撐住。以為穩了,接著又遇到載入失敗要怎麼處理?最後還是每張都加 onError,統一顯示 fallback 圖。不浪漫,但必要。因為破圖看起來不只像 bug,更像品牌管理失敗。 前端收尾後回到 API。產品分類查詢本來是簡單的 CRUD,結果分頁+子分類一上場,原本的產品資料模型就不夠用了,查詢邏輯整個打結。只好重構模型,補上子分類結構,連產品分析服務的主要功能也一起調整,讓「產品質地描述」的提取跟新架構對齊。這種調整就是牽一髮動全身,漏一角,
YI

中文用語統一大作戰:從小細節到底層穩定,這週我修了哪些坑

本來計畫把時間放在核心功能的優化,結果一打開產品分析服務的介面,先被一堆不一致的中文用詞刺了一下。看似微小的「上傳」「提交」「新增」差異,對品牌商用戶的專業感和信任度卻是很實在的扣分。想到我們的客群特別在乎質感,我還是把今天的重心從新功能挪開,展開一場用語清掃。 原本只想改幾個明顯錯誤,一搜 repo 才發現同一概念居然有十幾種搭配方式。最後我從使用情境與用戶習慣出發,整理了一份用語表,將「提交資料」「新增商品」一律統一為「上傳產品」。順手檢查之前的 log,也驚覺開發初期為了快,留下了 test.log、debug.log、temp.log 等臨時檔,甚至沒被 .gitignore 排除。這些東西被 commit 進 repo,真的不行。於是我把怪異的日誌檔案全數加入忽略規則,清乾淨殘留檔案,整個專案視覺與結構都清爽許多。 如果說這天的成果看起來不炫炮,那這週整體就是一場「挖坑與填坑」的連續劇:AI
YI