DevProduct
Day:292 NEXT
第 292 天的年度檢討：從 Ingrelens 與 cosGlint 的基礎建設到架構解耦，LLM 與後端分離、Orchestrator 上線；經歷 11 月大流量的佇列塞車與 48 小時救火，補齊觀測與調度，cosGlint 用戶破兩千、內建 13k+ 商品，1.3.0 推出全方位部位檢測，持續迭代。
Tag
AI
LLM、模型選型與 AI 產品化相關內容
ResearchAI
算力政治的三條主線：美國管制、企業分流與中國的變通
從華盛頓的法案到印尼機房的機架，再到中國數據中心的電費補貼，整個局面其實由三條主線拉動：政策、企業、技術現實。理解這三條主線，能幫我們預判接下來兩年算力市場的供需、價格、可用性，以及你我這種做產品的人會遇到的具體限制。
ResearchAI
OpenAI 十月風暴：改制綁定、監管壓力與系統性風險全解析
以下整理 2025 年 10 月間 OpenAI 的核心爭議：改制與融資綁定、反壟斷與監管壓力、內容政策（成人情色）、安全與法律風險，以及「過度互聯、可能太大而不能倒」的系統性風險討論。
EngineeringAI
Day :234 cosGlint 1.2.4 上線，成分分析＋10 種膚質檢測，保養選品更精準
cosGlint 1.2.4 上線：Findskin 核心演算法重設、膚質細分至 10 種，搭配全新相機介面與「計算權重」報告，讓拍照更順、結果更準。Ingrelens 以 AI 成分解讀、膚況檢測與個人化保養建議，把複雜資訊變簡單，提升選品決策的把握。
EngineeringAI
AWS DNS 失準的一夜：US‑EAST‑1 的連鎖反應與產品韌性
在凌晨的屏幕上，雲變得具象。不是抽象的 SLA 或彈性架構，而是每一次重試、每一條延遲訊息、每一個因「Insufficient Capacity」停住的部署。10/20，美東一區 US‑EAST‑1，AWS 多項服務因 DNS 解析異常引發連鎖反應：DynamoDB API 錯誤
DevUI/UX
快與深同路：把「不打擾」與「有話想說」設計成同一個動作
cosGlint 的回饋介面最佳實踐：以「點分數即排程、30 秒自動送出」不打擾完成，同時保留文字框與清楚動效、撤回入口；透過時間感、因果感、掌控感的微交互與 A/B 測試，在單一路徑上兼顧效率與深度。
ResearchEngineering
從「多」到「深」：社群新一代的轉向
演算法平台讓內容越多、喜悅越少：停留時間被最大化，連結感被最小化。新一代『利基社群／垂直產品』用工具把社群做厚——從 Lore、Spill、Blacksky 到 Fediverse，以語境理解、動態策展、可治理的去中心化，把『參與』與『親密』做成系統能力
EngineeringAI
面試也不能掉以輕心的資安風險
面試作業也可能是攻擊入口：一次 Node/React 測試倉庫的伺服端惡意載入與防護重點
ResearchAI
openAI 即將放寬色情內容是一種妥協嗎？
Altman 宣布 12 月起把成人內容（含 erotica）置於「已驗證成人」的自選開關後面；與其說向流量妥協，不如說是向市場調整。ChatGPT 4.1 仍相對寬鬆、5.0 多委婉迴避；真正影響體感的是驗證流程、地區法規與安全層邊界。Tumblr 的前車之鑑說明：一刀切不但傷體驗，也難以挽回信任。
DevEngineering
cosGlint 打造可信的「天氣×保養」系統機制
把高溫、濕度、風速、UV 指數轉成可執行的日常保養：從保養品分析到成分分析，cosGlint 以可被解釋的訊號給出白天防曬、夜間修護、隔日預防的具體指引。
ResearchEngineering
成功創辦人的人格特質與做事方法深度解析
通過對多位成功創辦人的深度剖析，我們可以看到儘管他們的產品和市場千差萬別，但其成功的底層邏輯卻驚人地一致。這些共通的特質與做事方法並非天賦，而是可以被有志創業者學習和複製的思維模式與行為準則。
ResearchEngineering
挖掘痛點深度研究 - 2
我們剖析了四種挖掘使用者痛點的核心途徑，但它們並非各自獨立的選項，而是一個整合的、可循環操作的策略系統。關鍵在於根據您的具體情境，採用最具策略性的順序與組合。成功的創新始於深刻的同理心，而系統化的痛點挖掘，正是將同理心轉化為商業價值的最佳路徑。
ResearchEngineering
顧客回饋與互動的終極指南：從成功創業者身上學到的實戰策略
前言：將顧客回饋轉化為成長引擎 對於每一位自力更生的創業者和早期新創公司而言，最寶貴的資產並非程式碼或商業計畫書，而是與市場的真實連結。在這場充滿不確定性的旅程中，顧客回饋不是冰冷的數據，而是指引方向的羅盤、驅動產品迭代的燃料，更是點燃可持續成長的核心動力。許多創業者埋首於打造
ResearchEngineering
挖掘痛點深度研究
聚焦創業「風險管理」：先驗證高價值痛點，再用分發驅動增長。內容涵蓋三大點子來源（自用痛點、複製優化、利基與平台）、低成本驗證方法（MVP、預售訂金、社群回饋），以及有機增長引擎（內容行銷、社群運營、SEO、短影音）與啟動擴張（生命週期優惠、影響者與付費投放）。強調創業者心態：專注一個問題、以速度迭代、韌性面對失敗。結論提出增長飛輪：洞察痛點→分發獲客→現金流迭代→深化價值。
DevResearch
Termdock
Termdock：以終端為核心的開發環境，整合多工作區與多終端、AST深度搜尋與檔案/Prompt管理，提供不干擾終端的Git輔助與智能拖放，減少上下文切換、提升產出
EngineeringAI
Day 209 ：我們如何把保養品成分分析變得可用、可信、可比較
回顧3月剛開始打造 Ingrelens 和 cosGlint 其實已經過了 209 天，時間其實過的很快，但總是不夠用。 * 03月：產品啟動完成了前後端大部分的基礎，推出網頁版 MVP * 04月：完成第一次測試上線，並且開始準備分離 llm 服務 * 05月：順利完
DevEngineering
Vibe coding 你該知道的 api key 知識
有人把會計費的 API key 直接放到可分享的前端，誰用了都算你的錢。當事人用 Google AI Studio 的 Build/Canvas 做了一個可分享的 App，介面上叫使用者填「自己的」key，但流程其實鎖了開發者的 key。內容被大量轉傳，短期流量爆掉，帳單也跟著爆
DevAI
OpenAI GPT5 推出後大家真的在懷念 GPT-4o ？
相信這幾天大家對於 GPT-5 最多的討論是「GPT-4o 消失了，還我 GPT-4o！」 坦白說我一開始也愣了一下。GPT-4o 雖然一路有在迭代，但效能本質上還是上一代：愛唬爛、幻覺多、討好傾向重。平常圈內多數人都是這個評價。 But…就是這個 But。 GPT-5 上線
DevEngineering
從技術債到戰略投資
這週從 SEO、Dockerfile/Supervisor、狀態管理、Tiptap + AI 到 環境變數，每天都有新坑。與其把它們當救火，我選擇把舊債系統性轉成投資，讓產品基礎穩固。 * SEO不是小事。重新設計 JSON‑LD 和 metadata，短期流量未必動，但可預
EngineeringAI
技術債與彈性之間：我把 LLM 微服務拆出來了
這週幾乎都在跟 LLM 微服務搏鬥：為了彈性、金鑰池、供應商切換、逃生門到 fallback 機制的完善，再到 Sentry 與 Redis 限流的整合。這些改動使用者不一定看得到，但對穩定性與後續擴充很關鍵。 本週進展 * LLM 微服務成功從 Ingrelens 主專
EngineeringAI
OAuth 解除綁定的取捨：那些看起來很小、其實很難的決定
OAuth 解除綁定的取捨：那些看起來很小、其實很難的決定 早上打開昨天調完的 UI，間距問題總算舒服多了。從 Clarity session 看，滑動速度降了一些，心情小小被安慰。結果沒高興多久，Google OAuth 解除綁定流程又跳出來提醒我：直覺跟安全，要怎麼一起兼顧
DevAI
SEO 跟使用者體驗的拔河
昨天猶豫了半天要不要接 Microsoft Clarity，今天早上看了幾段 session 錄影，心裡總算鬆一口氣——問題一目了然：搜尋輸入體驗太糟。輸入法組字的時機一錯，搜尋建議就瘋狂跳，整段流程像在考驗用戶耐心。 第一件事，我把搜尋輸入的 debounce 重寫：組字期間
DevEngineering
軟刪除這件小事，背後的細節卻不小
軟刪除這件小事，背後的細節卻不小 原本只想補一個產品刪除 API。硬刪除直覺又乾脆，但總會有人手滑、客服就會來敲門。最後還是加了 deletedAt 欄位，用軟刪除留個回頭路。 一做下去才發現沒那麼單純：所有產品查詢都要顧到「未刪除」的狀態，沒有 WHERE deletedA
DevEngineering
為體驗與準確性重構一切
圖片輪播的坑，比我想的深得多。昨天把 .gitignore 的怪事整理完，今天回到產品開發，把待辦清單裡的圖片輪播放進度。原本估半小時的小元件，結果一做就發現邊界狀況一堆。 先是圖片 URL 的檢查，避免破圖。寫到載入狀態才真正頭痛——使用者網路慢，圖片還沒載好，輪播就先動，那
DevEngineering
中文用語統一大作戰：從小細節到底層穩定，這週我修了哪些坑
本來計畫把時間放在核心功能的優化，結果一打開產品分析服務的介面，先被一堆不一致的中文用詞刺了一下。看似微小的「上傳」「提交」「新增」差異，對品牌商用戶的專業感和信任度卻是很實在的扣分。想到我們的客群特別在乎質感，我還是把今天的重心從新功能挪開，展開一場用語清掃。 原本只想改幾個
DevEngineering
AI 分類越做越複雜，是在挖坑還是填坑？
AI 分類越做越複雜，是在挖坑還是填坑？ 這幾天把重心放在兩件事：產品分類的 AI 自動化，以及安全檢查服務的重構。原本以為只是把 API 接上、模型升級一下，結果一路從資料結構、路由、日誌，到架構設計全被牽出來重整。 先談分類。 起手式很直接：把產品名稱與描述丟給模型，取
DevEngineering
FindSkin：從命名到體驗，把混亂收回來
Ingrelens 這次整理 FindSkin，我不只做功能，而是回到產品要解決什麼：先扎實研究文獻、設計情境題，再用權重公式準確定位膚質類型，最後把結果落到五維雷達圖的可視化呈現。 命名統一為 FindSkin：語意是一切互動的入口 過去「膚質檢測／肌膚分析／問卷調查」
DevEngineering
看不見的細節，為什麼值得？
今天的開發原本很單純：做一個訪客帳號。實作後卻發現，真正的難題不在「能不能用」，而在「用起來是否一致、可信」。這一整天的折返，讓我更確定：產品的差異，往往來自那些用戶不會主動說出口、卻一直被感受到的細節。 一、身分與名稱的一致性不是錦上添花 一開始我以為 localStorag
DevEngineering
重構永遠不是「只是改一下」的事
今天原本只打算把產品頁改成 client-side component，改善 SSR 時卡卡的效能與 UX。結果一碰到 loading 與 error 處理，才發現 API 根本沒涵蓋這些情境，只好連同整包一起重整。有人會問：「真的有必要動 API？用戶會在意嗎？」我很確定，這種
DevEngineering
API 重構後的幾點實話：技術債、產品判斷與下一步
API 重構後的幾點實話：技術債、產品判斷與下一步 這週把 Ingrelens 的幾個老問題一次整起來：API 架構統一、環境變數管理自動化、會員系統與帳號刪除流程重構，還把 HTTP 全面升級到 HTTPS。Dockerfile 重新整理、部署腳本補上該有的保險，過去半年累積
DevEngineering
Email 驗證、會員系統與那些「看似簡單」的更新紀錄
今天幾乎都在跟會員系統纏鬥。Ingrelens 一開始只是做「註冊、登入」這種基本功能，結果一路長出資料更新、密碼修改、guest 升級成正式會員……每加一個需求，整體邏輯就再複雜一點。 先處理 email 驗證。以前的流程只是寄信、點連結，直到要支援 guest 升級與 em
DevEngineering
把炸彈拆完，才有力氣往前走
游標分頁、環境變數與 API 統一大作戰：把炸彈拆完，才有力氣往前走 有些技術債務不會自己消失，換個環境就原形畢露。這兩天我乾脆把 API URL 的處理邏輯整個抽出來，用環境變數統一管理，再加上 trim，免得前後多了空白符號害人抓狂。順手把散落各處的 console.log
DevEngineering
Dockerfile、環境變數與 API endpoint：一次把坑補齊的週記
這兩天主要在補技術債、梳理架構，過程當然少不了自我懷疑，但也總算把幾個老問題收斂了。 先是 Dockerfile。昨晚就覺得哪裡怪，早上看 deployment log 才確認——前端 CORS 一直叫，後端 API 的 domain whitelist 根本沒吃到。追了半天發
DevEngineering
成分搜尋與 API 整合的兩天修補：從資料庫到前端的連鎖反應
成分搜尋與 API 整合的兩天修補：從資料庫到前端的連鎖反應 這兩天主要在處理兩件事：把成分搜尋做對、把 API 整合拉回穩定。結果一路從資料庫 schema、ORM、到前端路由和狀態管理，全都被牽出來重整了一遍。 先說成分搜尋。之前後端只有陽春 CRUD，前端要找成分時不是
DevEngineering
當重構像多米諾骨牌：從小修到整體優化的一週
延續昨天的 AI 整合反思，我原本只想讓產品分析結果更好讀。沒想到下去動了一個顯示細節，整個渲染邏輯就像多米諾骨牌一樣一路倒下：從前端元件、狀態流到資料處理方式，都被迫重新梳理。雖然頭疼，但結果讓我滿意。 先從「觀察互動」著手。我加了一個專門顯示成分的區塊，原本擔心資訊太細，使
DevEngineering
條碼的幽靈：安全與現實的角力
昨天把產品管理的 CRUD 骨架穩住後，今天直接把精力放在條碼掃描的擴展。理由很簡單：如果輸入數據不可靠，後面的分析再巧都只是表面工夫。 先整理了幾個後端細節，把多餘的 SQL 彈性收斂，移除那些看似靈活、實則增加風險的參數，順手解了一些依賴問題。結論很直白：簡化後更安全，查詢
DevEngineering
穩住掃描，補強地基：今天我為 IngreLens 做的兩件事
提升掃描可靠性、夯實產品管理
DevEngineering
做減法的 API 決策：把模型切換藏進產品分析，專注真實場景
關鍵調整是把「AI 模型切換」端點併入產品分析 API，回到穩定、準確的核心價值。處理 OpenAI 模型更新的封裝、補齊 FastAPI middleware 與錯誤處理；下週目標為完整整合測試與前後端聯調，並以監控與快速回滾機制降低風險。
DevEngineering
Day1 : 把 AI 成分分析的後端雛形搭起來
打造「保養品成分分析」後端原型：選用 FastAPI，以異步處理應對 AI 延遲，並設計可在多模型間安全切換的「逃生門」（含 Grok）。重點放在錯誤處理與降級邏輯，確保故障時介面穩定。下一步：基準測試冷啟動與延遲、明確 SLA/降級策略、補齊觀測性（metrics、tracing、告警）。